Autonomic Networking: Where Do We Go From Here?

It’s great to be back at another Cisco Live event, this time in the great city of San Francisco.  This is the last day of the event, and if you have some time, please do stop over at the World of Solutions, where you can see Autonomic Networking in action.  We have set up a live demo of the Autonomic Networking Infrastructure (ANI) at the Service Provider area!  The following figure shows a summary of the functionality, and i’d like to refer you to a previous blog for a more thorough explanation.

Summarising, the ANI allows networks to grow and self-organize organically, merely by  devices at the edge of the Autonomic Domain joining the Autonomic Control Plane.  A new device is cabled up and powered up and will be discovered by a  device at the edge of the Autonomic Domain/Network through the Channel Discovery Process.  The new device offers its identity to the Network, and the Network, after successful authentication, will deliver a Domain Certificate to the New Device as a result, and this is achieved using the Adjacency Discovery Process.  The New Device can then leverage this Domain Certificate to join the Autonomic Control Plane (ACP), which is essentially an IPv6 based, routed IP infrastructure that is secure/encrypted, self-organising and self-healing, and which cannot be de-configured and is not prone to mis-configurations.

Obviously the ACP is already pretty cool: a self-configured IPv6 network that is always up and always available: A ‘Virtual’ Out of Band Channel.  But it is clear that this is just the tip of the iceberg.  The ACP can be leveraged by external servers such as Syslog, AAA and TFTP as a communication channel across which they can announce their presence to all of the devices which have joined the domain, we call this Service Discovery.  Devices will use e.g. the AAA server to authenticate incoming SSH requests, will start sending syslogs automatically to the discovered syslog server, and will pull their (initial) configuration from the discovered TFTP server.

The current functionality can be used by any customer, although the beachhead platforms were SP platforms.  This and next year we’ll see platform proliferation beyond the ASR9xx and ME36xx platforms , namely the ASR9000 but also Enterprise platforms such as the Catalyst switches, the ISR routers, the ASR1000 and the CSR1kv (this would be an excellent platform to host the Autonomic Registrar function we believe!), as well as the IE family of Industrial Switches.

We can extend the Service Discovery idea to allow management servers and controllers to be plugged into the ACP and announce their Services.  As a matter of fact we are working with the APIC-EM Controller team and the Plug-and-Play (PnP) team to create a unified solution for Full Lifecycle Management for the Enterprise.  The ACP will allow new devices to bootstrap into the network.  PnP clients in those routers and switches can leverage the ACP to communicate securely with the PnP server component that is collocated with the APIC EM Controller, which will also function as the Autonomic Registrar. Applications can leverage the APIC EM Controller to offer secure and network wide configuration of policies, abstracted away from the network.  A similar idea is being pursued for the Open Day Light (ODL) Controller.  We plan to open-source our ACP implementation as a plug-in for ODL btw!

But things get really cool when we take these ideas to the next level, and that next level is ‘Intent’.  Intent is an expression of a certain  policy internal to the network, without worrying about what that means to individual devices.  Think of it as ‘network wide configuration’.  Actual services overlaid on the network are difficult to be expressed by Intent as they are user/location/identity specific, and hence these will always be done by an SDN controller such as ODL or APIC.  But the underlying network across which these services will be overlaid  is an ideal candidate for Intent.

Lets give an example: imagine that you can express for the entire network (i.e. the entire Autonomic Domain) the following things:

• what IP address family and prefix pool you’ll use for Loopback Interfaces (and potentially for inter-device-links, although ip unnumbered/link locals can be used here as well)
• what IGP you’d like to run for the underlying network, and some network wide attributes associated with them
• what transport layer you’d like to run (IP and/or MPLS) and the necessary network wide attributes associated with them.
• whether you’d want all IGPs and other control planes to automatically authenticate (by leveraging the Autonomic Certificates).
• The DiffServ settings for all internal links

On top of that , Autonomic Service Discovery can be leveraged by A Controller or by Network Devices to announce their roles and identities.

This results into a self-organising underlying network that adapts to changes and additions, just by ingesting a few simple network-wide hints i.e. Intent.  The Intent, once ingested, ‘lives’ in the network and is not relying on a central component.  New devices will immediately learn the Intent and do the right thing in order to become part of the underlying network.  And they will be able to communicate securely with a central component like an SDN controller , making the configuration  of overlay services a breeze!

As you can see we have exiting times ahead where networks WILL be intelligent and distributed while network services will be fully programmable through the use of SDN.  Autonomic Networking and SDN: the whole will be greater than the sum of its parts!