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

						

Figure 2: Interaction possibilities between ASA and Resources

The figure below illustrates how an ASA interacts with a node that the ASA 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 ASA 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 ASAs, the operator must first provision the infrastructure with the sets of ASA 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 ASA classes in a set of Installation Hosts.

As mentioned in the Problem statement section, an Autonomic Function Agent (ASA) controls resources of one or multiple Network Elements (NE), e.g. the interfaces of a router for a Load Balancing ASA. An ASA is a software, thus an ASA 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 ASAs:

The dynamic installation property

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

The decoupling property

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

The multiplicity property

allows controlling multiple sets of resources from a single ASA.

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

3.1. Operator's goal

In the installation phase, the operator's goal is to install ASA classes on Installation Hosts such that, at the moment of instantiation, the corresponding ASAs 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 ASA 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 favored, functionality coverage vs. cost trade-off...).

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

In the decoupled mode, the ASA host machine is different from the network element. The ASA is installed on the host machine and control the resources via interfaces and mechanisms external to the network element. An ASA 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:

[ASA class of type_x]

that specifies which classes ASAs to install,

[Installation_target_Infrastructure]

that specifies the candidate Installation Hosts,

[ASA 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 ASAs which corresponds to [list of ASA 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 ASA classes] are well installed on [list of installation Hosts]. The state of the ASA at the end of the installation phase is: installed. (not instantiated). The following commands or messages are foreseen: install(list of ASA classes, Installation_target_Infrastructure, ASA class placement function), and un-install (list of ASA classes).

4. Instantiation phase

Once the ASAs are installed on the appropriate hosts in the network, these ASA may start to operate. From the operator viewpoint, an operating ASA means the ASA manages the network resources as per the objectives given. At the ASA 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 ASA 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 ASA 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 ASAs have to interact with which other ASAs (or more precisely which set of network resources have to be handled as an autonomous group by their managing ASAs).

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

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

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

4.2. Instantiation phase inputs and outputs

Inputs are:

[ASA of type_x instances]

that specifies which are the ASAs 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 ASAs (e.g. an optimization target)

Outputs are:

[Set of ASAs - Resources relations]

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

4.3. Instantiation phase requirements

The instructions described in section 4.2 could be either:

sent to a targeted ASA

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 ASAs

In which case, the ASAs 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 - ASA Instance Mandate).

The conclusion of this instantiation phase is a ready to operate ASA (or interacting set of ASAs), then this (or those) ASA(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 - ASA 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 ASAs may produce knowledge or even monitor metrics that other ASAs 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 ASA: meaning enabling those to execute their autonomic loop or not.
• Modify ASAs targets: meaning setting them different objectives.
• Modify ASAs managed resources: by updating the instance mandate which would specify different set of resources to manage (only applicable to decouples ASAs).

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

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

During the Operation phase, running ASAs 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 ASA reaching respectively Installed and Instantiated states.

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