SDN Is Business, OpenFlow Is Technology

Many people don't understand the difference between OpenFlow and software-defined networking (SDN). This isn't surprising because the two technologies are closely related. However, they aren't interchangeable. OpenFlow is protocol that configures network switches using a process like an API. SDN is a term that describes providing programmable interfaces within a network infrastructure to enable a high degree of automation in provisioning network services. The SDN term is being abused by marketers who want to apply it to a wide range of technologies.

In fact, SDN can be explicitly defined. There are three architectural layers to an SDN network: the physical network, the SDN applications and the SDN controller. Let's look at each.

Physical Network. The lowest layer consists of the physical devices in your network that form the foundation of all IT infrastructure. We use the term "switch" because OpenFlow changes the way Ethernet switches work. For this article, you can also consider virtual switches part of the physical infrastructure.

SDN Applications. The most visible layer in an SDN design is the applications that deliver services, such as switch/network virtualization, firewalls and flow balancers. (Note that OpenFlow-based load balancers are called flow balancers. They aren't traditional load balancers because they can't read packet contents.) These applications are similar to or the same as those in use today where the software runs on dedicated hardware. Most of the coming innovation in networking will occur in SDN applications.

SDN Controller. The SDN controller is the middleware that serves as the linchpin of the entire architecture. The controller must integrate with all the physical and virtual devices in the network. The controller abstracts the physical network devices from the SDN software that works with those devices. There is a high degree of integration between the controller and network devices. In an OpenFlow environment, the controller will use the OpenFlow protocol and the NETCONF protocol to communicate with switches. (OpenFlow is the API for sending flow data to the switch, and NETCONF is the network configuration API).

SDN: Basic Architecture

In current SDN approaches, vendors provide applications and a controller in a single product. For example, Nicira/VMware packages its applications and controller into a single proprietary application stack. Cisco will package its controller into the OnePK product by embedding the controller in IOS software on the devices. I also expect Cisco to deliver a master controller in the near future. Big Switch Networks, which recently launched the commercial version of its SDN controller, offers two applications that run on the controller: Big Virtual Switch and Big Tap.

Clearly the controller is a key element in the network architecture. It must present APIs to the applications that represents usable functions, and it's here that the battle for SDN dominance will be fiercest among the vendors.

SDN APIs: The New Battleground

An SDN architecture has two distinct networking APIs: northbound and southbound. OpenFlow is a southbound API. OpenFlow describes an industry-standard API that configures the frame-forwarding silicon in an Ethernet switch and defines the flow path through a network. In addition, the Open Networking Foundation (ONF), the standards body overseeing the OpenFlow protocol, announced an API for device configuration called OF-CONFIG. OF-CONFIG uses the NETCONF XML data format to define the language.

Cisco's OnePK is also a southbound API. There is much discussion around whether OpenFlow is enough to meet all the needs of networking, especially with regards to migrating from a packet-based network to a flow-based network. There are unresolved issues that will hinder that migration, such as the need for interoperability with existing protocols such as STP and OSPF.

Northbound and Southbound APIs

The northbound API provides a mechanism in an SDN architecture to present services or applications to the business. Each application will develop a view of the flow tables for network devices and then send requests to the controller for distribution to the network devices.

For example, a virtual switching application would build a network graph/database of all points in the network of physical and virtual switches. In a multitenant Ethernet network, the app would develop a set of flow rules that emulate Ethernet VLANs while maintaining full isolation for each tenant's flows. The flow rules would consist of values based on ingress and egress ports, plus the source and destination MAC address.

Next page: API uncertaintyThe northbound APIs from the services to the controller aren't defined yet. I see three reasons. First, big vendors haven't been able to hit on use cases that are substantial enough for them to invest in. Second, only a few controllers have come to market, and they have yet to be proven as robust platforms for production traffic. Third, different applications may need different APIs to the controller depending on their requirements. For example, a firewall application may need a high-performance, low-latency, low-complexity data exchange, while a monitoring application might only need to read flows as they pass.

The industry is working on different options. It seems likely that there are forums within the ONF that will start to deliver some guidelines in the near future, and the IETF has published a draft from the Network Working Group on the topic.

The lack of a standard API means software developers have to decide which platform they will develop for. Does F5 develop for a Cisco or a Big Switch controller? What about a security company developing a firewall for OpenFlow? Would they choose the HP OpenFlow controller or the IBM version? The northbound API must be standardized at some point, but the format, performance and data structures are probably not well understood. There will be more to come on this topic.

Where the Pieces Fit

When examining the difference between OpenFlow and SDN, consider their position in the infrastructure. OpenFlow is a technical-to-technical service because it links the controller and network devices. It's not visible to users or to the business. By contrast, SDN is a business-to-technology interface. SDN presents services to users and the business before transforming them into abstractions that the controller can translate into network actions.

And now we have reached the point where we can talk about the revolution in networking. We don't have SDN in today's networks. Today's "network management" platforms are insufficient and fail to provide visibility and control to network owners. Most of this failure is due to the limitations of the SNMP protocol, which is the only standard method for extracting data from the network (although some tools have attempted to extract data from the command line interfaces).

Business and Technology Platforms

SDN has a complete set of abstractions from the physical and virtual networks. The southbound APIs have a well defined basis in OpenFlow and NETCONF that gives developers confidence that products are not limited to just a single vendor. And the market is moving to converge on northbound APIs in the next few months. Look for a lot of marketing and innovation from SDN vendors. This innovation will take the form of controllers and applications.

Vendors have announced OpenFlow supports in their physical devices and virtual switches such as Open vSwitch and Cisco Nexus 1000V. The next move in the market place is to identify OpenFlow controllers and applications that will deliver services to the business. That's already started to happen. As mentioned earlier, Big Switch Networks announced two applications along with its OpenFlow controller. HP has announced applications that should be available in 2013. As more applications start to arrive, SDN adoption will grow.