ANIMA P. Peloso
Internet-Draft L. Ciavaglia
Intended status: Standards Track Alcatel-Lucent
Expires: April 21, 2016 October 19, 2015

A Day in the Life of an Autonomic Function
draft-peloso-anima-autonomic-function-00

Abstract

While autonomic functions are often pre-installed and integrated with the network elements they manage, this is not a mandatory condition. Allowing autonomic functions to be dynamically installed and to control resources remotely enables more versatile deployment approaches and enlarges the application scope to virtually any legacy equipment. The analysis of autonomic functions deployment schemes through the installation, instantiation and operation phases allows constructing a unified life-cycle and identifying new required functionality. Thus, the introduction of autonomic technologies will be facilitated, the adoption much more rapid and broad. Operators will benefit from multi-vendor, interoperable autonomic functions with homogeneous operations and superior quality, and will have more freedom in their deployment scenarios.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 21, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.


Table of Contents

1. Problem statement

While autonomic functions are often pre-installed and integrated with the network elements they manage, this is not a mandatory condition. Allowing autonomic functions to be dynamically installed and to control resources remotely enables more versatile deployment approaches and enlarges the application scope to virtually any legacy equipment. The analysis of autonomic functions deployment schemes through the installation, instantiation and operation phases allows constructing a unified life-cycle and identifying new required functionality.

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 provide the operator a great variety of AFA deployment schemes as they decorrelate the evolution of the infrastructure layer from the evolution of the autonomic function layer. Depending on the capabilities (and constraints) of the infrastructure and of the autonomic functions, the operator can devise the schemes that will better fit to its deployment objectives and practices.

Based on the above definitions, the AFA deployment process can be formulated as a multi-level/criteria matching problem.

The primary level, present in the three phases, consists in matching the objectives of the operator and the capabilities of the infrastructure. The secondary level criteria may vary from phase to phase. One goal of the document is thus to identify the specific and common functionality among three phases.

This draft will explore the implications of these properties along each of the 3 phases namely Installation, Instantiation and Operation. This draft will then provide a synthesis of these implications in requirements for functionalities and life-cyle of AFAs. Beforehand, the following section will deal with the network operator's point of view with regards of autonomic networks.

2. Motivations from an operator viewpoint

Only few operators would dare relying on a pure autonomic network, without setting objectives to it. From an operator to the other, the strategy of network management vary, as much for historical reasons (experience, best-practice, tools in-place, organization), as much for differences in the operators goals (business, trade agreements, politics, risk policy). Additionally, network operators do not necessarily perform a uniform network management across the different domains composing their network infrastructure. Hence their objectives in terms of availability, load, and dynamics vary depending on the nature of the domains and of the types of services running over each of those domains.

To manage the networks according to the above variations, AFAs need to capture the underlying objectives implied by the operators. The instantiation phase is the step in-between installation and operation, where the network operator determine the initial AFA behavior according to its objectives. This step allows the network operator to determine which AFAs should execute on which domains of its network, with appropriate settings. At this stage, thanks to the intent-policy setting objectives to groups of AFAs, the network management should become far simpler (and less error-prone) than setting low-level configurations for each individual network resources.

2.1. Illustration of increasingly constraining operator's objectives

This paragraph describes the following example of operator intents with regards to deployments of autonomic functions. The autonomic function involved is a load balancing function, which uses monitoring results of links load to autonomously modify the links metrics in order to balance the load over the network. The example is divided into steps corresponding to an increasing implication of the operator in the definition of objectives/intents to the deployment of autonomic functions:

Step 1
The operator operates its network and benefits from the autonomic function on the nodes which have the installed AFAs.
Step 2
Then the operator, specifies to the autonomic function an objective which is to achieve the maximum number of links with a load below 6O%.
Step 3
The network is composed of five domains, a core transport network and four metropolitan networks, each interconnected through the core network, the operator sets a different objective to the autonomic function for each of the five domain.
Step 4
As inside metropolitan domains the traffic variations are steeper and happen in a periodic fashion contrary to the traffic in the core domain, the network operators installs an additional autonomic function inside each of these domains. This autonomic function is learning the traffic demands in order to predict traffic variations. The operators instructs the load balancing function to augment its monitored input with the traffic predictions issued by the newly installed autonomic function.
Step 5
As the algorithm of the load balancing autonomic function is relying on interactions between autonomic function agents, the operator expects the interactions to happen in-between AFAs of each domain, hence the load will be balanced inside each of the domain, while previously it would have been balanced over the whole network uniformly.
Step 6
Finally, the network operator has purchased a new piece of software corresponding to an autonomic function achieving load balancing with a more powerful algorithm. For trial sake, he decides to deploy this new load balancing function instead of the previous one on one of its four metropolitan domains.

This short example illustrates some specificities of deployment scenarios, the sub-section below sets itself at providing a more exhaustive view of the different deployment scenarios.

2.2. Deployment scenarios of autonomic functions

The following scenarios illustrate the different ways the autonomic functions could be deployed in an ANIMA context. Subsequently, requirements for the autonomic functions and requirements these autonomic functions impose on other components of the ANIMA ecosystem are listed.


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|            :      Autonomic Function 1       :            |
|  AFA 1.1   :      AFA 1.2   :   AFA 1.3      :   AFA 1.4  |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
             :                :                :
             :  + - - - - - - - - - - - - - +  :
             :  |   Autonomic Function 2    |  :
             :  |   AFA 2.2   :   AFA 2.3   |  :
             :  + - - - - - - - - - - - - - +  :
             :                :                :
+ - - - - - - - - - - - - - + : + - - - - - - - - - - - - - + 
|   Autonomic Function 3    | : |   Autonomic Function 4    |
|   AFA 3.1  :    AFA 3.2   | : |   AFA 4.3    :  AFA 4.4   |
+ - - - - - - - - - - - - - + : + - - - - - - - - - - - - - +
             :                :                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|              Autonomic Networking Infrastructure          |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
+--------+   :   +--------+   :   +--------+   :   +--------+
| Node 1 |-------| Node 2 |-------| Node 3 |-------| Node 4 |
+--------+   :   +--------+   :   +--------+   :   +--------+

						

Figure 1: High level view of an Autonomic Network

These various deployment scenarios are better understood by referring to the High level view of an Autonomic Network, Figure 1 of [I-D.behringer-anima-reference-model]. The figure is slightly extended for the purpose of the demonstration as follows:

Figure 1 depicts 4 Nodes, 4 Autonomic Functions and 10 Autonomic Function Agents. Let's list assumptions with regards of these elements.

Starting with nodes,

Pursuing with Autonomic Functions,

Completing with individual Autonomic Function Agents, those are pieces of software:

The last three points being largely questionable are marked as questions.

	
+ - - - +       +-------------+
|  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:

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 | 
                  |              |
                  +--------------+

						

Figure 3: Life cycle of an Autonomic Function Agent

Here are described the successive states of AFA.

Undeployed -
In this "state", the Autonomic Function Agent is a mere piece of software, which may not even be available on any host.
Installed -
In this state, the Autonomic Function Agent is available on a (/multiple) host(s), and after having shared its AFA class Manifest (which describes in a generic way independently of the deployment how the AFA would work). In this state the AFA is waiting for an AFA Instance Mandate, to determine which resources it manage (when the AFA is strictly coupled to resources [e.g. part of a Node OS], there is no need to wait for an instance mandate, the target resources being intrinsically known).
Instantiated -
In this state the Autonomic Function Agent has the knowledge of which resources it is meant to manage. In this state the AFA is expecting a set Up message in order to start executing its autonomic loop. From this state on the AFA can share an Instance Manifest (which describes how the AFA instance is going to work).
Operational -
In this state, AFAs are executing their autonomic loop, hence acting on network, by modifying resources parameters. A set down message will turn back the AFA in an Instantiated state.

The messages are described in the following sections.

6.2. AFA Class Manifest

An AFA class is a piece of software that contains the computer program of an Autonomic Function Agent.

In order to install and instantiate appropriately an autonomic function in its network, the operator needs to know which are the characteristics of this piece of software.

This section details a format for an AFA class manifest, which is (a machine-readable) description of both the autonomic function and the piece of code that executes the function.

Fields of AFA class manifest
Field Name Type Description
ID Struct A unique identifier made out of at least a Function Name, Version and Provider Name (and Release Date).
Description Struct A multi-field description of the function performed by the AFA, it is meant to be read by the operator and can point to URLs, user-guides, feature descriptions.
Installation properties 3 Booleans Whether the AFA is dynamically installable, can be decoupled from the NE and can manage multiple resources from a single instance (see Section 1 - Problem statement).
Possible Hosts OS... Lists the OS/Machines on which the AFA can be executed. [Only if AFA is dynamically installable]
Network Segment NetSegment... Lists the network segments on which the autonomic function is applicable (e.g. IP backbone versus RAN).
Manageable Equipments Equipments... Lists the nodes/resources that this piece of code can manage (e.g. ALU 77x routers, Cisco CRS-x routers, Huawei NEXE routers).
Autonomic Loop Type Enum States what is the type of loop MAPE-K and whether this loop can be halted in the course of its execution.
Acquired Inputs Raw InfoSpec... Lists the nature of information that an AFA agent may acquire from the managed resource(s) (e.g. the links load).
External Inputs Raw InfoSpec... Lists the nature of information that an AFA agent may require/wish from other AFA in the ecosystem that could provide such information/knowledge.
Possible Actions Raw ActionSpec Lists the nature of actions that an AFA agent may enforce on AFA the managed resource(s) (e.g. modify the links metrics).
Technical Objectives Description Technical Objective Spec... Lists the type of technical objectives that can be handled/received by the AFA (e.g. a max load of links).

6.3. AFA Instance Mandate

An AFA instance is the AFA agent: a running piece of software of an AFA class. A software agent is a persistent, goal-oriented computer program that reacts to its environment and interacts with other elements of the network.

In order to install and instantiate appropriately an autonomic function in its network, the operator may specify to AFA instances what they are supposed to do: in term of which resources to manage and which objective to reach.

This section details a format for an AFA Instance Mandate, which is (a machine-readable) set of instructions sent to create autonomic functions out of AFA.

Fields of AFA instance mandate
Field Name Type Description
AFA class Pattern Struct A pattern matching the ID (or part of it) of AFAs being the target of the Mandate. This field makes sense only for broadcast mandates (see end of this section).
Managed Resources ResourcesId... The list of resources to be managed by the AFA (e.g. their IP@ or MAC@ or any other relevant ID).
ID of Coord Interface Id The interface to the coordination system in charge of this autonomic function.
Reporting Policy Policy A policy describing which entities expect report from AFA, and which are the conditions of these reports (e.g. time wise and content wise)

An AFA instance mandate could be either:

sent to a targeted AFA
In which case, the receiving Agent will have to manage the specified list of resources,
broadcast to all AFA
In which case, the AFAs would collectively determine which agent would handle which resources from the list, and if needed (and feasible) this could also trigger the dynamic installation/instantiation of new agents (ACP should be capable of bearing such scenarios).

6.4. AFA Instance Manifest

Once the AFAs are properly instantiated, the operator and its managing system need to know which are the characteristics of these AFAs.

This section details a format for an AFA instance manifest, which is (a machine-readable) description of either an AFA or a set of AFAs gathered into an autonomic function.

Fields of AFA instance manifest
Field Name Type Description
AFA Class ID Struct A unique identifier made out of at least a Function Name, Version and Provider Name (and Release Date).
AFA Instance ID Long A unique Id of the AFA instance (if the AFA instance manifest gathers multiple AFAs working together, this would be a list).
Hosts Resource ID ID of the Machines on which the AFA executes.
Managed Resources ResourcesId... The list of resources effectively managed by the AFA (e.g. their IP@ or MAC@ or any other relevant ID).
Acquired Inputs Instance InfoSpec... Lists information that this AFA agent may acquire from the managed resource(s) (e.g. the links load over links with ID x and y).
External Inputs Instance InfoSpec... Lists information that this AFA agent requires from the ecosystem (e.g. the links load prediction over links with ID x and y).
Possible Actions Instance ActionSpec Lists actions that this AFA agent may enforce on its managed resource(s) (e.g. modify the links metrics over links x and y).

7. Implication for other ANIMA components

7.1. Additional entities for ANIMA ecosystem

In the previous parts of this document, we have seen successive operations pertaining to the management of autonomic functions. These phases involve different entities such as the AFAs, the AFA Hosts and the AFA Management function. This function serves as the interface between the network operator and its managed infrastructure (i.e. the autonomic network). The AFA management function distributes instructions to the AFAs such as the AFA Instance Mandate, AFA set up/set down commands and also trigger the AFA installation inside AFA Hosts. This function is likely to be co-located or integrated with the function responsible for the management of the Intents.

In this first version, we do not prescribe any requirements on the way the AFA Management function should be implemented, neither the various deployment options of such a function and neither on the way ACP or GRASP could be extended to interact with this function. We believe these design and specifications work should be first discussed and analysed by the working group.

7.2. Requirements for GRASP and ACP messages

GRASP and ACP seems to be the best (and currently only) candidates to convey the following messages between the AFA Management function and the AFAs:

  • AFA Class Manifest
  • AFA Instance Mandate (and Revoke Mandate)
  • AFA Instance Mandate
  • Set Up and Set Down messages

The way to convey these messages is to be handled by working group and protocol authors.

A mechanism similar to the bootstrapping one would usefully achieve discovery of pre-installed AFAs, and possibly provide those with a default Instance Mandate.

A mechanism to achieve dynamic installation of AFAs compatible with ACP and GRASP remains to be identified.

In the case of decoupled AFAs, even more for the ones supporting multiplicity, when a Mandate is broadcast (i.e. requesting the Instantiation of an autonomic function to manage a bunch of resources), these AFAs require synchronization to determine which agent(s) will manage which resources. Proper ACP/GRASP messages supporting such a mechanism have to be identified together with protocol authors.

8. Acknowledgements

This draft was written using the xml2rfc project.

This draft content builds upon work achieved during UniverSelf FP7 EU project.

9. IANA Considerations

This memo includes no request to IANA.

10. Security Considerations

TBD

11. References

11.1. Normative References

[I-D.ciavaglia-anima-coordination] Ciavaglia, L. and P. Peloso, "Autonomic Functions Coordination", Internet-Draft draft-ciavaglia-anima-coordination-00, July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

11.2. Informative References

[I-D.behringer-anima-reference-model] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Liu, B., Jeff, J. and J. Strassner, "A Reference Model for Autonomic Networking", Internet-Draft draft-behringer-anima-reference-model-04, October 2015.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S. and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015.

Authors' Addresses

Peloso Pierre Alcatel-Lucent Villarceaux Nozay, 91460 FR EMail: pierre.peloso@alcatel-lucent.com
Laurent Ciavaglia Alcatel-Lucent Villarceaux Nozay, 91460 FR EMail: laurent.ciavaglia@alcatel-lucent.com