DO NOT PANIC: Autonomic Networking is on the Horizon!

By looking at the sheer amount of Breakouts and technical sessions here at Cisco Live London, it isn’t hard to understand why networks are becoming more and more complex.  Networks are converging onto single infrastructures, more and more business processes are becoming more network centric and this translates into more functionality and more dependencies between functions and network layers, and thus more complexity.  It becomes very hard for a single human being to understand these dependencies and layer interactions in order to do per-box configuration.  Typically this problem is attempted to be ‘solved’ by moving some of these dependencies and layer interactions into a central place, but that just moves the problem.  Wouldn’t it be cool to allow networks to become self-aware, such that they can learn from their neighboring nodes ? Think routing protocols such as OSPF, which does this for packet forwarding , but extend this idea to other network functions such as security and QoS.   And wouldn’t it be cool to express what you want the network to do via a network wide interface , rather than having to configure individual elements ?  This is exactly what Autonomic Networking is trying to achieve!  And again : DON’T PANIC.  Autonomic Networking is a vision: the vision of the self-configuring, self-healing, self-protecting and self-optimizing network.  But just like the man on the moon was a vision, the journey that got us there yielded amazing results.  Teflon Pans e.g. J.  The road towards 100% Autonomic networks will be paved with incremental simplification efforts, making networks easier to manage and operate, feature by feature, while reducing dependencies on human operators and central NMS systems.

In short, an Autonomic Network wil be enabled by Autonomic functionality that creates state or configuration onto network devices such as switches, routers and hosts.  This autonomic functionality uses discovery techniques to gather information from other autonomic devices through network based control loops.  Based on self-knowledge and network based knowledge it will form a fully functional ‘base’ network.  Then the operator can create services using a high level language, which we refer to as ‘Intent’.  Also the network is able to aggregate information across all nodes, and can correlate that information before making it visible to the operator, yielding a ‘network status’ overview rather than a ‘node by node’ status overview.

I can hear you thinking: when can I have this?? Today Autonomic Networking is a concept, and we are actively soliciting input from customers as to which use-cases they would like to see solved.  But we do know that, in order for a network to become Autonomic, it will have to display the following fundamental concepts:

• Domain Identity: defines which domain a device belongs to , much like a passport or badge.  Obviously the domain identity should be verifiable by strong, cryptographic algorythms.  Each node can adapt its behavior based on the domain of the node it is interacting with.
• Discovery: a node will be able to automatically discover neighbours and its attributes, discover the network topology, and discover network services such as NTP, DNS and AAA.
• Abstraction through Intent: a way to configure the network as a whole.  It is high level and expresses business level network wide objectives i.e it expresses what you want the network to do, not HOW you want the network to do it. Examples are : “Prioritize TelePresence Video” or “Secure Links”.
• Network Wide reporting: instead of having every network element pass statistics or syslogs up to the NMS, you want the network  to aggregate statistics or correlate events before you send the information upstream.  And you want to send it only once.
• Objection Enablement: There needs to be a way to signal back whether intent cannot be executed end to end.  It is then up to the operator choice to accept the result of roll-back.
• Distribution of intelligence:  Just like OSPF is an autonomic process for ‘forwarding of IP packets’, a similar approach can be done for other ‘Autonomic Service Agents’.
• Incremental and Modular Autonomicity: we can ‘autonomize’ existing functions one by one by leveraging the underlying Autonomic Foundation (such as discovery), without giving up on node by node configuration for other features.  This also allows us to solve specific customer use cases one by one.
• Full Life Cycle support: Autonomics should  not only apply to configuration, but also to verification (is the service performing as needed  ?), monitoring (give me the aggregated throughput of a given service), and troubleshooting and optimization (troubleshooting should be done through the same ‘network wide’ view.
• Safe and Stable: Autonomics need to be supported both in Greenfield as well as Brownfield deployments.

How does this all fit with the Cisco SDN/ONE strategy ? Most beautifully I would say!  The ONE framework allows operators to interwork with a rich set of network services via the OnePK API’s, (rather than just ‘forwarding’ , i.e. OpenFlow).  The Cisco ONE framework also allows decoupling of ‘network’ orchestration versus ‘service’ orchestration.  The ‘service orchestration’ can leverage a centralized controller across a simpler ‘network wide interface’ (see also Eric’s post on this subject) , while the network orchestration piece is an excellent use case for … Autonomic Networking.

Is all of this going to happen in one go? For sure not.  Will this be for everybody? Maybe not!  Is this controversial? Perhaps! But again ‘DON’T PANIC’ 😀

Share