Software-defined networking holds a lot of interest for cloud and network providers, but many of them are frustrated by the state of SDN technology. Most large providers have been able to run at least small-scale SDN pilot tests or trials, but they have encountered barriers to large-scale deployments. What's missing in SDN, and how can providers identify these missing elements so they can fully take advantage of the technology?
1. Lack of standards for full device control
One of the most significant and obvious issues hindering SDN adoption is its lack of standards for full device control. The OpenFlow framework -- the de facto SDN standard used today -- is a unidirectional forwarding-table update protocol that doesn't provide a mechanism for determining the status of devices and doesn't allow for programming port or trunk interfaces. It also doesn't handle non-packet flows, such as wavelength flows. One could argue that the framework of OpenFlow today is a byproduct of some limited experiments, rather than a mechanism designed to support generalized network service creation.
Many have pointed out that OpenFlow cannot accomplish basic device setup, which would mean that more traditional management standards, such as simple network management protocol (SNMP), would have to be used to achieve this goal. The problem there is that the traditional management standards require full connectivity to address the devices. That begs the question: How should they be used when every route has to be established individually?
2. Service control software is missing
The next-largest gap in SDN technology is in the area of service control software, the technology that actually builds routes and controls traffic in a software-defined network. No matter what SDN models providers are considering, they will need software to link application services to SDN infrastructure. For cloud computing, this is often a plug-in associated with cloud virtual-network control (as in OpenStack's Quantum) or DevOps tools used to provision cloud resources.
Even with OpenFlow and an SDN controller, every SDN implementation will need service control software to create virtual networks. This is because SDN controllers only translate route requests into a series of forwarding table changes; they cannot create the routes themselves. However, SDN controller vendors sometimes offer northbound application programming interfaces through which this service control software can be connected, and some vendors even provide at least basic versions of the software. For SDN implementations that aren't based on OpenFlow, each network equipment vendor would have to provide the necessary service control software. Some of the work in this area by the Internet Engineering Task Force (IETF) is represented in the development of the Application Layer Traffic Optimization, or ALTO, protocol.
3. Multivendor network control a barrier to adoption
This brings us to the third barrier to SDN adoption: multivendor network control. Service control software can exercise control over multivendor networks through such standards as OpenFlow, Border Gateway Patrol (BGP) and Multiprotocol Label Switching, provided that the software knows about network conditions and can adjust routing and policies as needed.
For both the centralized and distributed SDN models, it's critical that control software knows the status of all network devices and trunks, no matter what equipment is involved. Protocols and specifications like SNMP and remote network monitoring, or RMON, can help gather some information, and there are IETF enhancements (BGP-LS) to BGP and initiatives like Infrastructure to Application Information Exposure , or i2aex, that will provide alternative resources. In some cases, probes deployed in the network and linked to a central monitoring software tool can provide more data. The need for telemetry on network status in SDN implementations has driven a wave of mergers and acquisitions, so SDN vendors are likely to beef up their offerings in this area.
4. Managing control traffic in centralized networks
The combination of service control software and multivendor network telemetry illustrates the fourth missing link for SDN: management of control traffic in centralized networks. Network operators such as Verizon have already noted that the telemetry traffic from network probes for some applications threatens to overwhelm the actual application traffic. In any SDN model where information is collected to support central oversight of network behavior, there's a balance between the value of knowing enough and the cost of delivering too much information to that central point.
Network operators have proposed virtualizing network functions, which could further increase the amount of control traffic on the network. But network functions virtualization could also create an alternative architecture for SDN -- something that's a mixture of hierarchical distributed processes that focus decisions without centralizing traffic and failure points.
5. Boundary functions are needed
The final SDN missing link is perhaps the most insidious, because it's likely to affect all real SDN deployments. Enterprises and network operators are most likely to launch SDN in isolated areas of the network rather than globally. Without specific models for service control software, it's not clear just how far software-defined networks could hope to scale. If there are SDN enclaves connected within legacy networks, how are the boundary functions handled? An SDN implementation inside an IP network, for example, would have to provide the IP network with discovery information, and it would have to obtain reachability and topology data from the legacy network for service control software to manage SDN routes. How does the network provide that information? And how would multiple SDN enclaves be interconnected? The IETF is considering the latter question in a draft for its proposed SDN interconnect, or SDNi, protocol, and again, BGP enhancements are also on the table.
Filling the gaps in SDN
The consequences of these missing links have been somewhat limited by the early focus of SDN applications: the data center. If SDN replaces data center Ethernet switching, it's practical to provision each route explicitly and even to create a separate "control network" to link device-management connections. As its adoption expands beyond the data center, SDN needs both a means of supporting adjacent legacy network components and an architectural framework that describes its own services. Providing for that expansion will demand resolutions for all of SDN's missing links.
Providers that want to fix these missing links will find the best path depends on the SDN model they've selected. For those interested in the centralized, OpenFlow-based SDN model, the best source of information about standards, trials and demonstrations is the Open Networking Foundation website and the conferences built around it. White papers and presentations are available on the site that will outline at least some approaches to a real SDN deployment, and of course, the standards themselves are available there. For now, the best source for information about the distributed SDN model is the vendors themselves, but evolving IETF standards are likely to create a cohesive framework in the future. In either case, be prepared to do some research to make SDN pay off.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecom and data communications since 1982.
Find out why SDN could be the solution to hybrid cloud networking issues
Survey: Where are service providers on SDN adoption?
The role of SDN and OpenFlow in cloud automation