SDN Use Cases

Rapid service provisioning: To speed up service creation and activation/deactivation times from weeks to minutes, SDN analytics are a must. For example, if a customer requests more bandwidth via a self-service portal, using path computation technology will automatically generate optimized network configuration recommendations, based on the supplied constraints, to the SDN controller.  

Data sovereignty: Many organizations cannot have their data leave their country’s physical borders. This requires service providers to create policies that specify the devices and links that traffic can traverse. They must know which paths should be used and have recovery options. This is normally a very labor-intensive process. SDN makes automating data sovereignty protection possible, if service providers have the intelligence needed to drive automated path provisioning.

Run networks hotter: To reduce costs, SDN can make it possible to run service provider networks at around 70 percent or greater link utilizations. However, keeping utilizations high requires real-time and predictive analytics that drive automated network configuration to accommodate changing demands. 

Hybrid Cloud Use Cases: Bandwidth on demand and calendaring capabilities are required to efficiently use WAN resources and support new services such as cloud backup and data-center disaster recovery needs. These use cases require the ability to record and baseline network routing, traffic, and performance data to feed machine-learning algorithms that calculate optimum network configurations.

Where Should Analytics Reside?

For analytics to be viable, they must reside in the right place in SDN architectures. A few years ago the industry thought that analytics would be in the controller. This did not happen. First, the controllers became a commodity. Vendors viewed analytics as a value-add and kept them in their offerings. 

Second, the controller is a control plane device. Doing big data analytics in the controller is not advisable. Analytics could be put in applications (such as traffic engineering), but not all applications may have access to the same telemetry. One application does not know what is happening with another one, and so forth.

This is why a new layer is being introduced into the SDN architecture: An analytics and automation layer. Given the importance of SDN analytics, therefore, the traditional two-tier SDN architecture needs to be expanded to include an analytics-based orchestration layer, as shown in Figure 2. This new layer delivers both management visibility and intelligence to SDN applications.

                                                Figure 2 — Three-tier WAN-SDN architecture

The Bottom Line

When software is making decisions that engineers traditionally have made, that software needs to be powered by the same expertise and deliver transparency to human operators. SDN analytics, fed by real-time and historical telemetry, projections, and algorithms, make it possible to manage a much larger sized network and satisfy customer demands quickly via automation. These analytics should be delivered via a management layer between the SDN controller and SDN applications. Only then can service providers effectively manage their multi-service networks to increase business agility, optimally use their capital investments, and add revenue opportunities.