Autonomic Networking is well understood in theory, but real, consistent and extensible implementations don’t exist. In this post I suggest a reason for the lack in execution, and our vision to provide a working, implementable Autonomic Networking Architecture.
Wipe off the dust…
When asking a researcher about autonomic systems, (s)he might blow the dust off a stack of papers, or proudly pull a couple of old books off his shelf. Or point to IBM’s IEEE paper from 2003. From a research perspective, autonomics is well understood. It’s this self-management thing, with all those self-* properties. Self-configuration and self-optimisation for example. Distribution, control loops, and so on. Even the Wikipedia articles are written. So, we’re done, aren’t we?
No we’re not.
Ask your friendly neighbourhood network engineers about Autonomic Networking. The one that proudly hacks expect scripts at night to make his admin database talk to his routers. Or the front line engineer who applies a network service class to one of his customers. Likely, both of them would look at you with big eyes, and after explaining that the network manages itself, intelligently, you’d hear back: “That’s like Skynet, isn’t it?”
No it’s not.
Autonomics is Everywhere
The fact that few network operators have heard about Autonomic Networking doesn’t mean it’s not there. In fact, I would argue, our networks are full of autonomic or at least partially autonomic functionalities. Look at your favourite interior routing protocol: You tell the router “go do OSPF”. Maybe give it a couple of parameters (it wouldn’t feel right if you couldn’t enter some, right?) . And – magic happens. Actually, we’ve forgotten what that magic is in detail, so used are we to those processes. But after a handful of hellos and link state updates in all directions, all routers in that network have a common, consistent view on the network topology. That is autonomic! The operator essentially just enables a function, and the network elements sort out the rest between themselves.
Like this, if you dig a bit deeper, you find many functions in today’s networks that display properties of self-management, self-optimisation or self-healing. Take HSRP or VRRP: You enable the function on an interface, define a virtual IP address (which really, could be figured out automatically, too), and the network has become self-healing in this spot. Or think about STP, VTP, Etherchannel, LDP, IS-IS, EIGRP, DLNA, SEND, WPS, or even simple things like the speed auto-negotiation on Ethernet interfaces. They all display some autonomic properties. So – Autonomics is everywhere. We’re done then, aren’t we?
No, we’re not.
Today’s autonomic functions are completely independent and isolated from each other. Each of these functions has its own way to talk to other network elements, find network resources, negotiate parameters, or distribute a policy. And each has its own security mechanism. Only to identify another network element securely, we have a whole range of methods in use today, from passwords, shared keys, to AAA, certificates, PINs, etc. Between two routers in a service provider network there is a shared key for BGP authentication, one for IGP authentication, another one for LDP, BFD, etc. Plus a bunch of them for SNMP, telnet, SSH, etc. And we’re surprised that people are reluctant to configure security? Or that they use the same key everywhere?
Making Autonomic Networking Work
To make networks smarter and less complex, a network element needs a common way to identify another element, for all its functions. It needs a single way to distribute policy, and of course, a common policy language. It needs one way to do service discovery in a network and a single message bus to allow autonomic functions to talk to each other across the network. The benefit is two-fold: It is all about code-reuse for developers and ease of use for operators.
There are a number of efforts to do just that, to create an autonomic network architecture. There is the Autonomic Network Architecture (ANA), the Generic Autonomic Networking Architecture (GANA), and some others. There are dozens of projects in the networking sector to define or prototype some form of autonomic networking, for example the EFIPSANS project, the SOCRATES or the UniverSELF project. However, if you are the architect with the job to create a network today, how can you create an architecturally consistent autonomic network today?
You can’t.
The problem with those frameworks is that they are either very specific for a single technology (e.g, SON in radio networks), or very generic, covering all aspects of the final architecture. But it’s hard to see how you can move from your network today to that vision. What’s missing is the step-by-step guide to autonomic networking. Where in the early stages you as the architect understand what the new mechanism does, can control it, and can judge the risk you’re taking. Where you can trouble-shoot, and if needed, roll back; with the end goal of finally trusting the automation and simplifying operations.
Small Steps
We’ve been working for four years on Autonomic Networking (see also Yves’ post). And the hardest question was indeed what the first, evolutionary step should be. It is amazing to see how everyone agrees on a high level vision, and how hard it can still be to find that first, manageable, digestible, implementable, operable step; the bit of autonomic functionality that’s just right, which is important enough to get done, but not too complex to be scary. Our first step was to solve the problem of secure device identities in a secure zero-touch, manageable way; such that network elements can talk to each other securely, for all protocols.
All this may sound like we’re competing with this approach with the SDN world, with its mostly centralised architecture. In fact, the opposite is true: For an SDN controller to control the network elements, the network underneath MUST be self-managing to some extent. Or do you as the operator want to bootstrap each network element manually with a device identity? No, the network should be self-forming, so that a controller can focus on its actual job: to define high-level policy and services.
Before you ask, standardisation of the approach is of course of paramount importance. You cannot introduce such an important concept without standardisation. We have taken our overall architectural vision as well as the proposed solution to bootstrapping device identities to the IETF. And we have seen a lot of interest, from all sides. As long as we follow a small-step bottom-up approach, we can make progress.
A Great Vision
When network devices are empowered and intelligent, most processes that are today human controlled can be made autonomic. Take for example a network wide image upgrade. Most network operators today would bluntly refuse to even consider automation of this critical task. But a router can communicate with its peers: “I saw there is a new image, and we’re in the maintenance window – can you take my load while I reload?” – “Sure, I’m only 20% loaded, go ahead” – “all right everybody, I’m reloading to release x, if I’m not back within 5 minutes, alert the boss and don’t upgrade yourself. ;-)” Yes I do believe that even tasks like this one can be made autonomic. With the right autonomic infrastructure, the network elements can be much more intelligent than today. And the overall network can be significantly easier to manage.
More Information / Feedback
You may want to read and comment on our architectural vision and our approach to bootstrapping device identities. At Cisco Live Milan we have a general session on Autonomic Networking, one that explains how we use it to bootstrap SP access networks, and a Panel Session.
Come to Cisco Live and meet us there! Book a “meet the engineer”; discuss with us at the Panel! And of course, share your thoughts and ideas right here on the blog. What would YOU like to be more autonomic in your network?
Working on perfecting this as we speak.
Thanks for the insight.
Darby Weaver