As is somewhat typical of emerging technologies, there isn't a universally agreed to definition of what is meant by software defined networking (SDN). Over the last year or two most of the definitions have focused on the decoupling of the network control plane from the network forwarding plane.
Decoupling of the network control and forwarding planes isn't a new concept. It's a key feature of MPLS and it is also a characteristic of many contemporary WiFi networks. However, if SDN is looked at strictly as the decoupling of the network control plane from the network forwarding plane, then its value is limited to features like reducing network latency.
The definition of SDN that is currently emerging focuses somewhat less on decoupling and more on providing programmatic interfaces into network equipment, whether or not there is a separation of the control and forwarding planes. A minor reason for this shift in focus is because Cisco recently announced that as part of its SDN offerings, it will provide APIs into multiple platforms that they provide.
This is not a Cisco-only approach, as other vendors; including Arista, Extreme and Juniper currently provide direct access to their products. One advantage of this approach is that it enables very detailed access into, and control over, network elements. This approach, however, doesn't provide a central point of control and is vendor specific. While some network service providers may adopt this approach in the near term, it is unlikely to gain much traction in the enterprise market for the foreseeable future.
A more powerful reason for the shift in focus of the definition of SDN is that if SDN is looked at as providing programmatic interfaces into network equipment, then its value is much broader. Looked at this way, SDN allows IT organizations to replace a manual interface into networking equipment with a programmatic interface that can enable the automation of tasks such as configuration and policy management and can also enable the network to dynamically respond to application requirements.
With the more common definition of an SDN, global control of the network is achieved by the logical centralization of the control plane function, and the network operations organization can deal with a pool of network devices as a single entity. With an SDN, network flows are controlled at the level of the global network abstraction, rather than at the level of the individual devices, usually, but not always, with the aid of the OpenFlow protocol.
The group most associated with the development of a standards based SDN is the Open Networking Foundation (ONF). The ONF was launched in 2011 and has as its vision to make OpenFlow-based SDN the new norm for networks. To help achieve that vision, the ONF has taken on the responsibility to drive the standardization of the OpenFlow protocol. The breadth of the SDN ecosystem is reflected in the fact that the ONF currently has over 70 members of varying types including vendors that provide the enabling silicon as well as the switches, network appliances, controllers, test equipment, telecommunications services, hyper-scale data center services and smart phones.
A layered architecture for an SDN is shown in Figure 1. In that architecture, the control plane functionality is centralized in the SDN controller's software. Most of the time that SDN is being discussed, the OpenFlow protocol is used to program the forwarding behavior of the switch. There are, however alternatives to the use of OpenFlow, including the Extensible Messaging and Presence Protocol (XMPP), the Network Configuration Protocol (Netcong) and OpenStack® from Rackspace and NASA.
In this model, applications are written to a set of APIs that are provided by the SDN controller. Unfortunately, these APIs are not standardized, so an application that runs on a given SDN controller would have to be modified to run on another SDN controller. Examples of network centric applications that could run on an SDN controller are given below.
The SDN controller supports a number of drivers that control the behavior of the underlying network elements, so that the network will provide the desired network services. The controller provides management plane functionality such as performance and fault management via SNMP and other standard protocols, and it typically handles configuration management of OpenFlow compliant devices in order to provide network topology, forwarding, QoS, and link management.
Most modern Ethernet switches and routers contain flow-tables (typically supported by Ternary Content Addressable Memory) that run at line-rate and are used to perform forwarding functions based on Layer 2,3, and 4 packet headers. While each vendor's flow-table is different, there is a common set of functions supported by a wide variety of switches and routers. This common set of functions is leveraged by OpenFlow, which is an open protocol between a central OpenFlow controller and an OpenFlow switch and which, as noted, can be used to program the forwarding behavior of the switch.
With OpenFlow, a single central controller can program all the physical and virtual switches in a network. While it is possible to implement SDN with a single controller, vendors such as Big Switch and NEC have announced either a production high availability cluster, or their intention to implement such a cluster of controllers. It is likely that IBM will follow suit.
The OpenFlow protocol was developed at Stanford, with v1.0 published at the end of 2009 and v1.1 at the beginning of 2011. In March of 2011, the ONF was created and the intellectual property rights of OpenFlow were transitioned to it. Part of the ONF charter is to control and commercialize OpenFlow. With that goal in mind, the ONF recently released OpenFlow v1.3 and in March 2012 the ONF sponsored an interoperability event that was open to all of the members of the ONF. A total of 14 companies and two research institutions participated in the event which focused on the OpenFlow v1.0 standard. Information on the testing that was done and the lessons that were learned can be found at ONF Interoperability Event White Paper.
In an OpenFlow-only switch, all of the control functions of a traditional switch (e.g. the routing protocols that are used to build forwarding information bases (FIB)) are run in the central OpenFlow controller. An OpenFlow-enabled switch (dubbed a OpenFlow-hybrid switch in V1.1) supports both OpenFlow flow forwarding and traditional Ethernet switch bridging and routing. Hybrid switches allow OpenFlow and traditional bridge/routing to share the same Ethernet infrastructure.
Many existing high functionality Layer2/3 switches can be converted to be OpenFlow-hybrid switches by the relatively simple addition of an OpenFlow agent in firmware supported by the native switch Network Operating System (NOS). Alternatively, once the semiconductor vendors have produced chips that effectively process the OpenFlow protocol, an OpenFlow-only switch would be extremely simple and inexpensive to build because it would have very little resident software and would not require a powerful CPU or large memory to support the extensive control functionality typically packaged in a traditional NOS.
There are a number of possible ways that the centralization of control, the programmability, and the flow forwarding characteristics of OpenFlow can be leveraged to provide value to IT organizations. For example, one of the primary benefits of OpenFlow is the centralized nature of the FIB. Centralization allows optimum routes to be calculated deterministically for each flow, leveraging a complete model of the end-to-end topology of the network. Based on an understanding of the service levels required for each type of flow, the centralized OpenFlow controller can apply traffic engineering principles to ensure each flow is properly serviced. One advantage of this capability is that it enables the network to dynamically respond to application requirements. It also enables notably better utilization of the network without sacrificing service quality.
Another benefit is that OpenFlow switches can filter packets as they enter the network, and hence these switches can act as simple firewalls at the edge of the network. With OpenFlow switches that support the modification of packet headers, an optional feature in OpenFlow v1.0, the OpenFlow controller will also be able to have the switch redirect certain suspicious traffic flows to higher-layer security controls, such as IDS/IPS systems, application firewalls, and Data Loss Prevention (DLP) devices.
OpenFlow switches that support the modification of packet headers will also be able to function as a simple, cost-effective load-balancing device. With modification functionality, a new flow can result in a new flow table entry that is directed to a server selected by the OpenFlow controller's load balancing policies. In order to create load-balancing policies based on server load, the OpenFlow controller would have to monitor the pool of servers as they report current load levels.
Call to Action
There is no doubt that SDN can potentially provide very significant value to IT organizations. There is also no doubt that in the current environment SDN is only appropriate for early adopters. Given the immaturity of the current products, standards and APIs, any IT organization that is looking to implement SDN in the near term should only do so in a somewhat limited manner, such as implementing SDN for a very specific use case. In addition, given the embryonic state of the market, the interoperability of products that claim to support the same SDN related standards cannot be assumed so IT organizations should only work with vendors that have demonstrated a high level of interoperability.
However, given the combination of the huge investments that vendors are making, combined with the ongoing spate of acquisitions, the SDN landscape will likely change notably over the next 12 to 18 months. IT organizations can expect an ongoing series of announcements both in terms of new products, new or enhanced protocols and further proof of interoperability. IT organizations can also expect that the basic building blocks of an SDN, such as the enabling protocols and APIs, will stabilize. Assuming that all of that happens, there are two events that have to occur in order for SDN to go from being strictly for early adopters to being ready for the mainstream market. One is the availability of functionality that enables IT organizations to effectively manage this new form of networking. The second is the availability of a wide range of applications that leverage the centralized control inherent in most forms of an SDN and which answer the question that all senior IT managers will ask: "Why should we spend our resources on SDN? What exactly are the benefits?"
Metzler heads Ashton, Metzler Associates. He can be reached at email@example.com