SDN Automation: Not as Simple as You Might Think

Automation and SDN seem to go hand in hand, but several challenges still need to be solved before automation is automatic in software defined networks.

By Arthur Cole | Posted Jul 1, 2014
Page of   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Rarely does a technology come along that is as much of a slam dunk as software defined networking. Even the vaunted server virtualization movement had a pretty big downside: namely, the need to provision additional storage and physical/virtual controllers to accommodate all those VMs.

SDN, on the other hand, provides net gains across the data environment. It helps to streamline traffic flows and, by extension, networking infrastructure. It enables broad scalability and on-demand provisioning, allowing users to finally get the resources they require to fulfill their tasks. And it provides the last component in the drive toward the fully virtual data environment where compute, storage and networking can finally relate to one another and scale accordingly, on an abstract footing.

SDN automation: OpenFlow is only the first step

The problem (there's always a problem, isn't there?) is that not all of the magical properties of a software defined network appear at your fingertips just because you've separated the control plane from the data plane. In fact, deployment of a basic SDN protocol like OpenFlow on key networking devices is only the first step in what is likely to be a lengthy transition, and there is so far little consensus as to what qualifies as a true SDN architecture once all is said and done.

The automation side of SDN is a prime example. The simple fact is that, whether you employ OpenFlow or another method, the basic protocol only provides the basic abstraction. You'll still need to implement the actual automation stack to institute things like automated configuration, real-time load balancing and on-demand resource allocation.

"There is a lot of focus on the separation of the control and forwarding (data) planes in SDN, and there are certainly advantages to that," said Sunil Khandekar, CEO of Nuage Networks. "But that is not all there is to SDN. It is in fact about automation, abstraction, control and visibility. What's important for app developers and network administrators to know is not whether they are using OpenFlow or SNMP, but what are they doing to help automate the data center, to ensure that the private cloud is as agile and responsive and programmable as AWS."

What SDN automation requires, what it can do, and what it can't

But once we have decided that we want not just a software defined network but an automated software defined network, what does that really mean? Today's 7-layer OSI network model requires more than one solution if you plan to drive automation up to the application level (Layer 7). Layer 2 and 3 functions, and perhaps a few basic Layer 4s, can be handled by OpenFlow or one of its alternatives. Higher up, you'll need a policy engine that sits outside the data path to oversee things like transport and session management, but it will also have to coordinate directly with the SDN controller so as not to produce critical failures on the network. The ONF and other groups are actively working on methods to extend OpenFlow capabilities to Layers 4 through 7, but we're not there yet.

Still, to hear some boosters describe it, this fully automated SDN environment will remove human control in its entirety, allowing applications themselves to define their ideal network parameters and then instruct the automation stack to deliver. Naturally, that leaves many network administrators a little cold, haunted by visions of endless resource conflicts, policy disputes and serious downtime should traffic conditions fail to mirror the assumptions used to build the governing architecture.

In short, don't expect your automated SDN environment to function on a "set-it-and-forget-it" basis.

"Automation does not bring with it the notion of accountability," said Lori MacVittie, principal technical evangelist at F5 Networks. "If you ask someone if they want the automation system to be able to make a change on the corporate firewall, the answer is a resounding ‘No.' In the end, automation isn't about doing everything, it's about more efficient processes."

In other words, eliminating all of the manual steps in the provisioning process is probably not warranted, but perhaps removing 95 percent of them will do the trick, as long as there is a human operator at the end to give the all-clear.

MacVittie also contends that a key factor in an automated network environment is not so much control, but visibility. Placing network architecture on an abstract, software footing offers an unprecedented ability to drill into data flows and network patterns. This allows administrators to not only to keep an eye on network loads and conditions, but to accurately plan changes to existing models and predict the impact they will have on the overall data stack.

"Half of what SDN is intended to do is on the operations side," she said, "but a critical piece is being able to authoritatively view the state of the network at any given point. Once you pull that state back, you can start the automation process because you now know what the network looks like and it becomes easier to alter routes and make other changes. But there still needs to be rules governing all that."

But in a practical sense, how is any of this different from the automation that exists for today's physical networks? SDN provides a more elegant approach to automation, to be sure, but today's scripts and embedded commands are highly adept at reconfiguring data pathways already.

What makes SDN automation special

The key difference, says Prayson Pate, CTO of network solutions developer Overture Networks, is that SDN allows you to automate for the future, rather than the present.

"Traditional automation is all about building a service and then automating it," he said. "If you think about the layers of abstraction in SDN, you're building automation into the API and then using that as a base to develop new services. You're no longer defining the API based on one existing service, but creating a generic toolbox to create new services."

This is similar to the approach used by today's smartphone developers, in which open APIs spawn new applications from a wide range of independent developers, giving us everything from Angry Birds to Twitter. This also allows new services to be introduced without making any fundamental changes to network infrastructure and management systems.

Ultimately, SDN will improve the lot of the workaday network administrator, albeit only the ones who are adept with higher-level, policy-driven questions. The level of automation may vary from SDN to SDN, but the end result should be a more adaptive and responsive network environment that is better suited to the dynamic workloads of 21st Century data environments.

But the journey is just beginning, and the challenges are not fully known at this point. And it is very possible that the ideal, automated abstract network will forever remain an elusive goal.

Photo courtesy of Shutterstock.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter