Software-Defined Networking: A No-Hype FAQ

The biggest buzzword at this year's Interop conference in Las Vegas was software-defined networking. Not only did NEC's ProgrammableFlow PF6800 Controller win the best of show award, but also, SDN in general and OpenFlow in particular caused near constant debate in the convention center. IT analysts spread the fervor last week, with IDC estimating SDN to be a $2 billion market in four years.

With all of this hoopla, it's easy to forget that just a couple years ago, OpenFlow was a Stanford research project and SDN was an unchristened buzzword.

But at this early stage in this buzzword's hype cycle, many IT practitioners are still wondering what all the excitement (and yes, some disdain) is about. Let's examine the key facts about SDN.

1. Just what is SDN?

SDN is nothing more than the separation of network data traffic processing from the logic and rules controlling the flow, inspection, and modification of that data. Traditional network hardware, i.e. switches and routers, implement these functions in proprietary firmware partitioned respectively into what is known as the data and control planes.

SDN, the OpenFlow project being the most famous example, pulls these apart, such that the traffic-handling features are executed as a distinct software application. The packet processing, i.e. data movement and forwarding, is still handled in hardware, but SDN-optimized switches can be relatively simple and are often built out of commodity ASICs, so-called merchant silicon, not proprietary designs.

Some call this 'virtualizing the network', in the sense that each individual hardware switch may be part of multiple Layer 2 and Layer 3 networks and have its configuration and traffic management policies dynamically changed by the master network controller.

2. Why all the excitement now?

Part of the buzz is just the natural tendency for the IT community to create and subsequently jump on technology bandwagons. Just like server virtualization, network fabrics and clouds, SDN is a new approach to solving real problems. However, like all emerging technologies, SDN is immature and so amorphous as to serve as a convenient panacea for all that ails network engineers these days.

Whether it's VM proliferation and the accompanying rise of largely opaque virtual NICs and switches, the increase in server-to-server (so-called 'east-west') network traffic and the resultant need for flat, multipath edge networks, or the consolidation of data and storage traffic onto a common Ethernet, you name it, SDN is the (latest) answer.

Add in the fact that major equipment vendors from Arista to VMware have been amping up the SDN public relations volume, and you have a combustible mix.

3. How does SDN change my network? What's different?

From a topological standpoint, SDN needn't change your network at all, although it can make wiring up very wide, non-blocking, flat, two-tier "fat tree" networks replete with VMs and virtual NICs much easier, since you don't have to worry about the alphabet soup of multipath networking standards like SPB,TRILL, MC-LAG, VEPA, or EVB.

SDN networks look more like FAA-controlled airline traffic rather than autonomous cars and trucks on the Interstate. As such, SDN networks are completely dependent on the controller; if it goes down, traffic can still flow over previously established paths (switches will remember their prior instructions,) but new clients or link failures will wreak havoc.

4. Is SDN just a switching technology, or is there more to it?

The initial focus of OpenFlow has been on software-controlled switching, because the network controller is essentially a server-based application; for example, the Big Switch Floodlight controller is a Java application that runs on Linux or Mac OS X. But SDN enables other forms of application-controlled network traffic.

In one example cited in the original OpenFlow research paper (PDF), the controller is used to define and enforce network-wide application usage and client admission policies, acting as a sort of a combination application firewall and NAC appliance.

Sketching out one usage scenario, the authors write that the controller could check each "new flow against a set of rules, such as 'Guests can communicate using HTTP, but only via a web proxy,' or 'VoIP phones are not allowed to communicate with laptops.'" Thus, the controller not only makes decisions about packet flows based on source and destination port and address, but also can modify flow behavior by user (or group) and application type. Another example that NEC demonstrated at its Interop booth was detecting video requests and automatically redirecting clients from a remote video server to local caching proxy.

5. What vendors are pushing SDN?

The most visible SDN advocates are members of the Open Networking Foundation (ONF), a consortium of organizations founded in March, 2011 and chartered with the development of SDN standards based on OpenFlow. There are currently more than 60 companies in the ONF, everyone from cloud services like Facebook and Google to networking heavyweights like Cisco and Juniper.

Of course, OpenFlow, which can use relatively dumb switches built from commodity components, seems to present a threat to the incumbent network providers' fat profit margins, so their membership in the ONF could presage their taking a page from Microsoft's playbook to "embrace, extend and extinguish".

In fact, Cisco's CTO Padmasree Warrior hinted at Cisco's long term SDN vision in her Interop keynote which described its notion of an "Open, Programmable Environment" that brings API, programmability, and control to multiple network devices, applications, and layers, not just switches and flow control. That strategy could be the heart of what Cisco's super-secret spin-in company, Insieme, is developing.