Autonomic Networking Integrated Model and Approach

The information below is for an older proposed charter
Document Proposed charter Autonomic Networking Integrated Model and Approach WG (anima) Snapshot
Title Autonomic Networking Integrated Model and Approach
Last updated 2014-10-07
State Start Chartering/Rechartering (Internal Steering Group/IAB Review) Rechartering
WG State BOF
IESG Responsible AD Robert Wilton
Charter Edit AD BenoƮt Claise
Send notices to


Autonomic networking refers to the self-managing characteristics
(configuration, protection, healing, and optimization) of distributed network
elements, adapting to unpredictable changes while hiding intrinsic complexity
from operators and users. Autonomic Networking, which often involves
closed-loop control, is applicable to the complete network (functions)
lifecycle (e.g. installation, commissioning, operating, etc). An autonomic
function works in a distributed way across various network elements, but
allowing central guidance and reporting, and co-existence with non-autonomic
methods of management. The general objective of this working group is to enable
the progressive introduction of autonomic functions into operational networks,
as well as reusable autonomic network infrastructure, in order to reduce the

This work build on definitions and design goals, as well as a simple
architecture model undertaken in the Network Management Research Group (NMRG)
of the IRTF.

Elements of autonomic functions already exist today. However, all such
functions today have their own discovery, node identification, negotiation,
transport, messaging and security mechanisms as well as non-autonomic
management interfaces. There is no common infrastructure for distributed
functions. This leads to inefficiencies. Additionally, central configuration,
management and optimisation of operational device configurations is expensive,
tedious, and prone to human error.  A simple example is assigning address
prefixes to network segments in a large and constantly changing network.
Similarly, repair or bypassing of faults requires human intervention and causes
significant down time.

This WG is intended to mitigate this duplication of similar mechanisms and
heavy dependency on human actions, in particular by facilitating secure
closed-loop interaction directly between network elements to satisfy management
intent. This motivates the introduction of a control paradigm where network
processes, driven by objectives (or intent), coordinate their local decisions,
autonomically translate them into local actions, and adapt them automatically
according to various sources of information including external information and
protocol information bases.

While a complete solution for full autonomic networking is an ambitious goal,
the initial scope of this working group's effort is much more modest: the
specification of  a minimum set of specific reusable infrastructure components
to support autonomic interactions between devices, and to specify the
application of these components to one or two elementary use cases of general
value. Practically, these components should be capable of providing the
following services to those distributed functions: o a common way to identify
nodes o a common security model o a discovery mechanism o a negotiation
mechanism to enable closed-loop interaction o a secure and logically separated
communications channel o a consistent autonomic management model

Where suitable protocols, models or methods exist, they will be preferred over
creating new ones.

It is preferred that autonomic functions would co-exist with traditional
methods of management and configuration, and the initial focus would be on
self-configuration. Future work may include a more detailed systems
architecture to support the development of autonomic service agents. The ANIMA
working group will initially focus on enterprise, ISP networks and IoT. Like
traditional network management, the topological scope of autonomic functions is
expected to be limited by administrative boundaries.

The goals of this working group are below. The were selected to according to
the analyzed technical gaps in draft-irtf-nmrg-an-gap-analysis: o Definition of
a discovery protocol for autonomic nodes o Definition of a negotiation protocol
for autonomic functions
   Starting point: draft-jiang-config-negotiation-protocol
o Definition of a solution to bootstrap a trust infrastructure
   Starting point: draft-pritikin-bootstrapping-keyinfrastructures
o Definition of a solution for a separated Autonomic Control Plane
   Starting point: draft-behringer-autonomic-control-plane

Each proposal should have its own motivation and complete workflow as autonomic
process. The design of these proposals should clearly target reusability in
other use cases.

In addition, the WG will develop solutions for the following two use cases:
o A solution for distributed IPv6 prefix management within a network.
Although prefix delegation is currently supported, it relies on human
action to subdivide and assign prefixes according to local requirements,
and this process could become autonomic.
o A solution for always-on, data plane independent connectivity between network
elements (i.e., stable in the case of mis-configurations), which can be used
for call home, network  provisioning, or simply trouble-shooting.

It is essential that these components and solutions fit together as an
integrated whole. For this reason, an overview document will be developed in
parallel with the individual specifications.

The initial set of work items is limited to the above list to stay focused and
avoid "boiling the ocean". Additional documents concerning other
autonomic infrastructure components, policy intent, use cases or autonomic
service agents are strongly encouraged, as individual submissions, or as
submissions to the IRTF Network Network Management Research Group. Additional
work items may only be added with approval from the responsible Area Director
or by re-chartering.


Nov 2014 - WG formation and adoption of initial drafts (see "specific
           - Mar IETF 92nd -
Apr 2015 - adoption of solution draft(s) (see "use cases")
Jun 2015 - WGLC for discovery and negotiation protocol
           - Jul IETF 93rd -
Aug 2015 - submit discovery and negotiation protocol to IESG (standards track)
Aug 2015 - adoption of overview draft
Oct 2015 - WGLC for trust bootstrap draft
Oct 2015 - WGLC for solution draft
           - Nov IETF 94th -
Dec 2015 - submit trust bootstrap draft to IESG as Proposed Standard
Dec 2015 - submit solution draft(s) to IESG as Proposed Standard
Jan 2016 - WGLC for autonomic control plane draft
Jan 2016 - WGLC for overview draft
           - Mar IETF 95th -
Apr 2016 - submit autonomic control plane draft to IESG as Proposed Standard
Apr 2016 - submit overview draft to IESG as Informational RFC
Jul 2016 - recharter if needed, or close