Network Autonomy: Feedback Defined Networking
Network Autonomy: Feedback Defined Networking
Join the DZone community and get the full member experience.Join For Free
This article was originally written by Marten Terpstra at the Plexxi blog.
About 8 years ago at my previous employer we started a project related to Autonomic Networking. Autonomic Networking is modeled after Autonomic Computing, an IBM initiative from the early 2000s, targeted at creating self managing computing elements. The network version intends to create a framework by which network elements become largely self managed. It does so by defining discovery, awareness and analytics that build some sense of state. Once a network has a sense of its expected state, anything that alters that state can be reacted to following a set of defined or even learned rules.
Autonomic Networking can be as simple as reacting to threshold alarms. In many of our network switches today, there are basic reactions to error conditions. Loop detection mechanisms shut off ports when a loop is detected. Specific error conditions may lead to pre-emptive switchover to alternate links or paths. Many of the protocols we use that govern connectivity and patching have autonomic capabilities, they react to error conditions and link failures and attempt to keep the disruption to the network to an absolute minimum.
True Autonomic Networking takes this many levels further, it tries to define the network as inputs, outputs and expected behaviors, almost something you would want to describe using process algebra (which was my favorite Computer Science class way back). But it’s the moment you actually start to automatically modify the state of the network based on a derived model of “normal” that people start to freak. It’s human nature to not like to relinquish control. And that is extremely visible in networking. Even the most simple threshold alarm based actions are met with a reaction from customers that sounds like “I only want you to tell me what has happened and what I should do about it, but I do not want you to automatically do it”.
Get Over It
And it is that attitude that we need to collectively get over. Large portions of the systems we use each and every day are more autonomic than the network we cuddle and cherish. When you land in SFO, the monorail has no driver but no one hesitates getting in to pick up their rental car. Technology advanced as we believe we are, that simple monorail has more autonomy than most networks today.
The good news is that we are slowly started to get used to more autonomy for our network. The folks at network heresy.com a while ago wrote about automatic ways to detect elephant flows and adjusting the network behavior as a result. Purist may say they only changed the priority of these packets, but in the end, the entire network system behaved different before and after. Without operator intervention.
Whether you like the actual methodology or not, the lossless capabilities added to ethernet create a sense of autonomy. Switches monitor a state of “normal” by looking at queue utilization, and react autonomously when needed by telling neighbors to stop sending traffic, and telling high volume users to slow down.
Most vendors have tools that monitor VMWare’s vCenter, looking for moving VMs and ensure that network and policy configuration specific to that VM is applied to the switch and port this VM happens to be moving to.
The larger web companies, the ones with their own networking stuff, have embraced some of this methodology for a while now. It is pretty common knowledge that Google uses analytics and utilization feedback to adjust its use of wide area network capacity by moving traffic around.
Feedback Defined Networking
If nothing else, SDN in whatever definition you like, is giving us the concept of a programmable network. And what use is programming a network if all you use it for is to automate basic configuration information? A huge portion of the value of SDN is the ability to create autonomy for the network. We can now actually take feedback from the network and use it to change its behavior. Or change the behavior of those that use the network. Having a programmable interface to the network allows us to get beyond manual interventions.
I call it Feedback Defined Networking. I know that term will stick for about an hour at best, but that’s ok. The point is that we have only scratched the surface of what we can do with the network, its users and the surrounding systems once we collectively get over our desire to manually control the network.
Published at DZone with permission of Mike Bushong , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.