+ - - - +       +-------------+
|  AFA  |------>|     NMS     *<--*
+ - - - +       +------^------+   |
  |   |                |          |  
  |   |         +------V------+   |
  |   +-------->| Controller  |   | 
  |             +------^------+   |  +---------------------+
  |                    |          |  | + - - - +           |
  |             +------V------+   |  | |  AFA  |  Node OS  |
  +------------>|   Node OS   *<--*  | + - - - +           |
                +------^------+      +--------------*------+
                       |                            |
                +------V------+               +-----*------+
                |     Node    |               |    Node    |
                +-------------+               +------------+

						

Figure 2: Interaction possibilities between AFA and Resources

The figure below illustrates how an AFA interacts with a node that the AFA manages. The left side depicts external interactions, through exchange of commands towards interfaces either to the node OS (e.g. via SNMP or NetConf), or to the controller (e.g. (G)MPLS, SDN, ...), or to the NMS. The right side depicts the case of the AFA embedded inside the Node OS.

2.3. Operator's requirements with regards to autonomic functions

Regarding the operators, at this point we can try to list few requirements they may have with regards with the Autonomic Functions and their management...

• Being capable to set those functions a scope of work in term of area of duty,
• Being capable to monitor the actions taken by the autonomic functions, and which are its results (performance with regards to the function KPIs)
• Being capable to halt/suspend the execution of an Autonomic function (either because the function is untrusted, or because an operation on the network is to be conducted without interference from the autonomic functions, etc...)
• Being capable to configure the autonomic functions by adjusting the parameters of the function (e.g. a Traffic Engineering autonomic function may achieve a trade-off between congestion avoidance and electrical power consumption, hence this function may be more or less aggressive on the link load ratio, and the network operator certainly has his word to say in setting this cursor.

3. Installation phase

Before being able to instantiate and run AFAs, the operator must first provision the infrastructure with the sets of AFA software corresponding to its needs and objectives. The provisioning of the infrastructure is realized in the installation phase and consists in installing (or checking the availability of) the pieces of software of the different AFA classes in a set of Installation Hosts.

As mentioned in the Problem statement section, an Autonomic Function Agent (AFA) controls resources of one or multiple Network Elements (NE), e.g. the interfaces of a router for a Load Balancing AFA. An AFA is a software, thus an AFA need first to be installed and to execute on a host machine in order to control resources.

There are 3 properties applicable to the installation of AFAs:

The dynamic installation property

allows installing an AFA on demand, on any hosts compatible with the AFA.

The decoupling property

allows controlling resources of a NE from a remote AFA, i.e. an AFA installed on a host machine different from the resources' NE.

The multiplicity property

allows controlling multiple sets of resources from a single AFA.

These three properties are very important in the context of the installation phase as their variations condition how the AFA class could be installed on the infrastructure.

3.1. Operator's goal

In the installation phase, the operator's goal is to install AFA classes on Installation Hosts such that, at the moment of instantiation, the corresponding AFAs can control the sets of target resources. The complexity of the installation phase come from the number of possible configurations for the matching between the AFA classes capabilities (e.g. what types of resources it can control, what types of hosts it can be installed on...), the Installation Hosts capabilities (e.g. support dynamic installation, location and reachability...) and the operator's needs (what deployment schemes are favoured, functionality coverage vs. cost trade-off...).

For example, in the coupled mode, the AFA host machine and the network element are the same. The AFA is installed on the network element and control the resources via interfaces and mechanisms internal to the network element. An AFA MUST be installed on the network element of every resource controlled by the AFA. The identification of the resources controlled by an AFA is straightforward: the resources are the ones of the network element.

In the decoupled mode, the AFA host machine is different from the network element. The AFA is installed on the host machine and control the resources via interfaces and mechanisms external to the network element. An AFA can be installed on an arbitrary set of candidate Installation hosts, which can be defined explicitly by the network operator or according to a cost function. A key benefit of the decoupled mode is to allow an easier introduction of autonomic functions on existing (legacy) infrastructure. The decoupled mode also allows de-correlating the installation requirements (compatible host machines) from the infrastructure evolution (NEs addition and removal, change of NE technology/version...).

The operator's goal may be defined as a special type of intent, called the Installation phase intent. The details of the content and format of this proposed intent are left open and for further study.

3.2. Installation phase inputs and outputs

Inputs are:

[AFA class of type_x]

that specifies which classes AFAs to install,

[Installation_target_Infrastructure]

that specifies the candidate Installation Hosts,

[AFA class placement function]

e.g. under which criteria/constraints as defined by the operator that specifies how the installation phase shall meet the operator's needs and objectives for the provision of the infrastructure. In the coupled mode, the placement function is not necessary, whereas in the decoupled mode, the placement function is mandatory, even though it can be as simple as an explicit list of Installation hosts.

The main output of the installation phase is an up-to-date directory of installed AFAs which corresponds to [list of AFA classes] installed on [list of installation Hosts]. This output is also useful for the coordination function and corresponds to the static interaction map.

The condition to validate in order to pass to next phase is to ensure that [list of AFA classes] are well installed on [list of installation Hosts]. The state of the AFA at the end of the installation phase is: installed. (not instantiated). The following commands or messages are foreseen: install(list of AFA classes, Installation_target_Infrastructure, AFA class placement function), and un-install (list of AFA classes).

4. Instantiation phase

Once the AFAs are installed on the appropriate hosts in the network, these AFA may start to operate. From the operator viewpoint, an operating AFA means the AFA manages the network resources as per the objectives given. At the AFA local level, operating means executing their control loop/algorithm.

But right before that, there are two things to take into consideration. First, there is a difference between 1. having a piece of code available to run on a host and 2. having an agent based on this piece of code running inside the host. Second, in a coupled case, determining which resources are controlled by an AFA is straightforward (the determination is embedded), in a decoupled mode determining this is a bit more complex (hence a starting agent will have to either discover or be taught it).

The instantiation phase of an AFA covers both these aspects: starting the agent piece of code (when this does not start automatically) and determining which resources have to be controlled (when this is not obvious).

4.1. Operator's goal

Through this phase, the operator wants to control its autonomic network in two things:

1

determine the scope of autonomic functions by instructing which of the network resources have to be managed by which autonomic function (and more precisely which class e.g. 1. version X or version Y or 2. provider A or provider B),

2

determine how the autonomic functions are organized by instructing which AFAs have to interact with which other AFAs (or more precisely which set of network resources have to be handled as an autonomous group by their managing AFAs).

Additionally in this phase, the operator may want to set objectives to autonomic functions, by configuring the AFAs technical objectives.

The operator's goal can be summarized in an instruction to the ANIMA ecosystem matching the following pattern:

• [AFA of type_x instances] ready to control [Instantiation_target_Infrastructure] with [Instantiation_target_parameters]

4.2. Instantiation phase inputs and outputs

Inputs are:

[AFA of type_x instances]

that specifies which are the AFAs to be targeted (and more precisely which class e.g. 1. version X or version Y or 2. provider A or provider B),

[Instantiation_target_Infrastructure]

that specifies which are the resources to be managed by the autonomic function, this can be the whole network or a subset of it like a domain a technology segment or even a specific list of resources,

[Instantiation_target_parameters]

that specifies which are the technical objectives to be set to AFAs (e.g. an optimization target)

Outputs are:

[Set of AFAs - Resources relations]

describing which resources are managed by which AFA instances, this is not a formal message, but a resulting configuration of a set of AFAs,

4.3. Instantiation phase requirements

The instructions described in section 4.2 could be either:

sent to a targeted AFA

In which case, the receiving Agent will have to manage the specified list of [Instantiation_target_Infrastructure], with the [Instantiation_target_parameters].

broadcast to all AFAs

In which case, the AFAs would collectively determine from the list which Agent(s) would handle which [Instantiation_target_Infrastructure], with the [Instantiation_target_parameters].

This set of instructions can be materialized through a message that is named an Instance Mandate. Instance Mandates are described in the requirements part of this document, which lists the needed fields of such a message (see Section 6.3 - AFA Instance Mandate).

The conclusion of this instantiation phase is a ready to operate AFA (or interacting set of AFAs), then this (or those) AFA(s) can describe themselves by depicting which are the resources they manage and what this means in terms of metrics being monitored and in terms of actions that can be executed (like modifying the parameters values). A message conveying such a self description is named an Instance Manifest. Instance Manifests are described in the requirements part of this document, which lists the needed fields of such a message (see Section 6.4 - AFA Instance Manifest).

Though the operator may well use such a self-description "per se", the final goal of such a description is to be shared with other ANIMA entities like:

• the coordination entities (see [I-D.ciavaglia-anima-coordination] - Autonomic Functions Coordination)
• collaborative entities in the purpose of establishing knowledge exchanges (some AFAs may produce knowledge or even monitor metrics that other AFAs cannot make by themselves why those would be useful for their execution) (see knowledge exchange items in Section 5 - Operation phase)

5. Operation phase

Note: This section is to be further developed in future revisions of the document.

During the Operation phase, the operator can:

• Activate/Deactivate AFA: meaning enabling those to execute their autonomic loop or not.
• Modify AFAs targets: meaning setting them different objectives.
• Modify AFAs managed resources: by updating the instance mandate which would specify different set of resources to manage (only applicable to decouples AFAs).

During the Operation phase, running AFAs can interact the one with the other:

• in order to exchange knowledge (e.g. an AFA providing traffic predictions to load balancing AFA)
• in order to collaboratively reach an objective (e.g. AFAs pertaining to the same autonomic function targeted to manage a network domain, these AFA will collaborate - in the case of a load balancing one, by modifying the links metrics according to the neighbouring resources loads)

During the Operation phase, running AFAs are expected to apply coordination schemes

• then execute their control loop under coordination supervision/instructions

6. Autonomic Function Agent specifications

6.1. Life-cycle

Based on the phases described above, this section defines formally the different states experienced by Autonomic Function Agents during their complete life-cycle.

The drawing of the life-cycle presented below shows both the states and the events/messages triggering the state changes. For simplification purposes, this sketch does not display the transitory states which correspond to the handling of the messages.

The installation and Instantiation phase will be concluded by AFA reaching respectively Installed and Instantiated states.

	
                  +--------------+
Undeployed ------>|              |------> Undeployed
                  |  Installed   | 
              +-->|              |---+
     Mandate  |   +--------------+   | Receives a
   is revoked |   +--------------+   |  Mandate               			  
              +---|              |<--+
                  | Instantiated | 
              +-->|              |---+
          set |   +--------------+   | set
         down |   +--------------+   | up             			  
              +---|              |<--+
                  |  Operational | 
                  |              |
                  +--------------+