Putting the “Software” in Software Defined Networking
3 min read
One of the biggest concerns I see with the SDN “buzz” that is happening in the industry at the moment, is the broadening perspective on what “Software Defined” means, and the confusion this is causing for my customers. As I discussed in my previous blog, it is good that different customers can apply SDN in different ways, but that in turn makes it hard for some customers to see the benefit for them.
In this post, I’ll outline some of the possibilities I see for SDN, and how it may benefit you in your day-to-day business. I’ll also discuss where the SDN hype may exceed your current requirements.
In my last post, I shared that there are three main forms of SDN in common discussion today: standards based “true” SDN, proprietary APIs and overlay networks. Today, I want to look at how each of these may offer benefits to your business.
One important point to remember is that SDN was intended to be a “lifecycle”, not just a configuration tool. The intention is that applications can both push intent as well as receive information, as seen in this lifecycle diagram.
However, most SDN deployments today focus on the bottom left part of the lifecycle, using service orchestration to program the network, or to overcome the restrictions the network may put in place. However, this is just one example of SDN’s power. By allowing the application to set intent, driving orchestration, using real-time performance feedback, analyzing that feedback, and providing useful data to the application, we can change how applications and the network interact.
Standards Based SDN
OpenFlow’s SDN started the discussion, and is still the most anticipated and widely leveraged form of SDN. SDN was designed to provide a new way to manage traffic traversing the network, allowing software to change the “rules” of data forwarding, away from a relatively static set of configurations and policies hard-coded into the switch itself.
The uses for this are as wide as your imagination, but obvious examples include automation, cloud provisioning, traffic path selection, policy control, and so on. But there’s a catch … all of this needs someone to develop the rules, policies and applications before it can be implemented. This is where the most interesting developments in SDN are happening now.
Tools like Cisco eXtensible Network Controller (XNC), offers both the SDN Framework for managing the network, but adds key applications that customers can take advantage of immediately, such as “slicing” a network into multiple tenants, or providing tuned traffic paths across the network for different uses.
Additionally we see direct integration of network awareness being developed for applications in the future. An application will eventually be able to ask for specific bandwidth per transaction, or specific latency requirements to be met, or for a report on the delivery of critical data.
Proprietary SDN
As mentioned in my previous blog, vendors have been developing proprietary means of configuring the network for many years (you may remember our Application-Oriented Network “AON” solution). What these capabilities will provide is a means to take advantage of vendor-specific features in your network, which are not otherwise supported in the standards.
The Cisco XNC takes advantage of some of our features to provide a virtual “Matrix Switch” that can receive data from various network “taps” and “span ports” and send data to the necessary analysis tool, without the need for operators to configure each switch or device in the path.
Overlay Networks
Finally overlay networks provide a means to move workload anywhere, anytime. Cisco’s Nexus 1000v InterCloud offers the freedom to move workload from a corporate network to a public cloud infrastructure, while retaining the network policy from the source network.
This in turn will lead to applications being able to ask for more resources and relocate their workload with no operator intervention being required. Of course the telemetry and performance criteria will need to be carefully monitored and assured before this becomes a mainstream technique.
Making it Simple
As these tools are now being developed post haste, it’s now up to the vendors to make SDN attainable. Today’s solutions are complex, with many moving parts, and this is preventing real world deployment of SDN.
In my next post I will discuss how the Application Centric Infrastructure makes both the network and application integration components of SDN significantly easier.
Join the conversation @CiscoCanada or leave a comment in the section below.
Authors
