One document matched: draft-peloso-anima-autonomic-function-00.txt
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.
Peloso & Ciavaglia Expires April 21, 2016 [Page 1]
Internet-Draft Autonomic Function October 2015
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 . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivations from an operator viewpoint . . . . . . . . . . . 4
2.1. Illustration of increasingly constraining operator's
objectives . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Deployment scenarios of autonomic functions . . . . . . . 5
2.3. Operator's requirements with regards to autonomic
functions . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Installation phase . . . . . . . . . . . . . . . . . . . . . 10
3.1. Operator's goal . . . . . . . . . . . . . . . . . . . . . 10
3.2. Installation phase inputs and outputs . . . . . . . . . . 11
4. Instantiation phase . . . . . . . . . . . . . . . . . . . . . 12
4.1. Operator's goal . . . . . . . . . . . . . . . . . . . . . 12
4.2. Instantiation phase inputs and outputs . . . . . . . . . 13
4.3. Instantiation phase requirements . . . . . . . . . . . . 13
5. Operation phase . . . . . . . . . . . . . . . . . . . . . . . 14
6. Autonomic Function Agent specifications . . . . . . . . . . . 15
6.1. Life-cycle . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. AFA Class Manifest . . . . . . . . . . . . . . . . . . . 16
6.3. AFA Instance Mandate . . . . . . . . . . . . . . . . . . 17
6.4. AFA Instance Manifest . . . . . . . . . . . . . . . . . . 18
7. Implication for other ANIMA components . . . . . . . . . . . 19
7.1. Additional entities for ANIMA ecosystem . . . . . . . . . 19
7.2. Requirements for GRASP and ACP messages . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Peloso & Ciavaglia Expires April 21, 2016 [Page 2]
Internet-Draft Autonomic Function October 2015
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.
Peloso & Ciavaglia Expires April 21, 2016 [Page 3]
Internet-Draft Autonomic Function October 2015
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.
Peloso & Ciavaglia Expires April 21, 2016 [Page 4]
Internet-Draft Autonomic Function October 2015
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.
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:
Peloso & Ciavaglia Expires April 21, 2016 [Page 5]
Internet-Draft Autonomic Function October 2015
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| : 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
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,
each may be either an Unconstrained Autonomic Node, a Constrained
Autonomic Node (or even a legacy one?),
they may well be of different models (or having different software
versions),
they may well be of different equipment vendors,
they may well be of different technologies (some may be IP
routers, some may be Ethernet switches or OTN switches...).
Pursuing with Autonomic Functions,
they may well have different objectives (one could target
automatic configuration of OSPF-TE, while another one is
optimizing traffic load), but they may well have identical
Peloso & Ciavaglia Expires April 21, 2016 [Page 6]
Internet-Draft Autonomic Function October 2015
objectives as two could optimize energy consumption (possibly on
different areas as function 3 and function 4),
each may be composed of no more than one AFA (either because the
function is responsible for a single node or because the function
relies on a centralized implementation),
each may well be composed of different sort of AFAs, meaning the
software is different (either because their version number is
different, or because the software provider is different, or
because their respective nodes/equipments differ or because the
role of each agent is different),
[Observation] Depending on the implementation the same piece of
software may fulfil different roles or each role may come from a
different from a different piece of code,
[Observation] Depending on the implementation the same piece of
software may fulfil different roles or each role may provide from
a different piece of code,
each has reached a given organization, meaning an organized set of
AFAs in charge of a set of nodes ()whether formalized or not),
this organization may either come from the piece of software
itself (e.g. embedding a self-organization process) or come from
directions of the network operator (e.g. through intents/policies,
or through deployment instructions)
each may work internally in a peer to peer fashion (where every
agents have the same prerogatives) or in hierarchical fashion
(where some agents have some prerogatives over other) [this option
is a good example of role differences],
each having its scope of work in terms of objective to reach and
area/space/part of the network to manage.
Completing with individual Autonomic Function Agents, those are
pieces of software:
embedded inside the node/equipment OS (hence present since the
bootstrap or OS update of the equipment),
running in a machine different than the node (this could be a node
controller or any other host or virtual machine)
[Observation] In the latter case, the AFA would likely require
external credentials to interact with the node,
Peloso & Ciavaglia Expires April 21, 2016 [Page 7]
Internet-Draft Autonomic Function October 2015
directly monitoring and configuring the equipment (likely requires
the AFA to be embedded) or through a management interface of the
equipment (e.g. SNMP, TL1, Q3, NetConf) or through an equipment
controller (e.g. SDN paradigm) or through a network manager (e.g.
using the north interface of the manager)
either activated at start-up or as the result of a management
action,
may be installed (either inside the equipment or on a different
machine) when requested by an operator from a software origin
(e.g. a repository in the ACP, a media)
provided by the same vendor as the equipment it manages or by any
third party (like another equipment vendor, a management software
vendor, an open-source initiative or the operator software team),
sharing a technical objective with the other AFAs of the Autonomic
Function they belong, (or at least a similar one)?
can it contains multiple technical objective?
must the technical objective be intrinsic or can it be set by a
managing entity (a network operator or a management system)?
The last three points being largely questionable are marked as
questions.
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.
Peloso & Ciavaglia Expires April 21, 2016 [Page 8]
Internet-Draft Autonomic Function October 2015
+ - - - + +-------------+
| AFA |------>| NMS *<--*
+ - - - + +------^------+ |
| | | |
| | +------V------+ |
| +-------->| Controller | |
| +------^------+ | +---------------------+
| | | | + - - - + |
| +------V------+ | | | AFA | Node OS |
+------------>| Node OS *<--* | + - - - + |
+------^------+ +--------------*------+
| |
+------V------+ +-----*------+
| Node | | Node |
+-------------+ +------------+
Figure 2: Interaction possibilities between AFA and Resources
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.
Peloso & Ciavaglia Expires April 21, 2016 [Page 9]
Internet-Draft Autonomic Function October 2015
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
Peloso & Ciavaglia Expires April 21, 2016 [Page 10]
Internet-Draft Autonomic Function October 2015
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,
Peloso & Ciavaglia Expires April 21, 2016 [Page 11]
Internet-Draft Autonomic Function October 2015
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:
Peloso & Ciavaglia Expires April 21, 2016 [Page 12]
Internet-Draft Autonomic Function October 2015
[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
Peloso & Ciavaglia Expires April 21, 2016 [Page 13]
Internet-Draft Autonomic Function October 2015
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:
o the coordination entities (see [I-D.ciavaglia-anima-coordination]
- Autonomic Functions Coordination)
o 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)
Peloso & Ciavaglia Expires April 21, 2016 [Page 14]
Internet-Draft Autonomic Function October 2015
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.
Peloso & Ciavaglia Expires April 21, 2016 [Page 15]
Internet-Draft Autonomic Function October 2015
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.
+--------------+---------------+------------------------------------+
| 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 | 3 Booleans | Whether the AFA is dynamically |
Peloso & Ciavaglia Expires April 21, 2016 [Page 16]
Internet-Draft Autonomic Function October 2015
| properties | | installable, can be decoupled from |
| | | the NE and can manage multiple |
| | | resources from a single instance |
| | | (see Section 1 - Problem |
| | | statement). |
| Possible | OS... | Lists the OS/Machines on which the |
| Hosts | | AFA can be executed. [Only if AFA |
| | | is dynamically installable] |
| Network | NetSegment... | Lists the network segments on |
| Segment | | which the autonomic function is |
| | | applicable (e.g. IP backbone |
| | | versus RAN). |
| Manageable | Equipments... | Lists the nodes/resources that |
| Equipments | | this piece of code can manage |
| | | (e.g. ALU 77x routers, Cisco CRS-x |
| | | routers, Huawei NEXE routers). |
| Autonomic | Enum | States what is the type of loop |
| Loop Type | | MAPE-K and whether this loop can |
| | | be halted in the course of its |
| | | execution. |
| Acquired | Raw | Lists the nature of information |
| Inputs | InfoSpec... | that an AFA agent may acquire from |
| | | the managed resource(s) (e.g. the |
| | | links load). |
| External | Raw | Lists the nature of information |
| Inputs | InfoSpec... | that an AFA agent may require/wish |
| | | from other AFA in the ecosystem |
| | | that could provide such |
| | | information/knowledge. |
| Possible | Raw | Lists the nature of actions that |
| Actions | ActionSpec | an AFA agent may enforce on AFA |
| | | the managed resource(s) (e.g. |
| | | modify the links metrics). |
| Technical | Technical | Lists the type of technical |
| Objectives | Objective | objectives that can be |
| Description | Spec... | handled/received by the AFA (e.g. |
| | | a max load of links). |
+--------------+---------------+------------------------------------+
Table 1: Fields of AFA class manifest
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.
Peloso & Ciavaglia Expires April 21, 2016 [Page 17]
Internet-Draft Autonomic Function October 2015
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.
+-----------+----------------+--------------------------------------+
| Field | Type | Description |
| Name | | |
+-----------+----------------+--------------------------------------+
| AFA class | Struct | A pattern matching the ID (or part |
| Pattern | | of it) of AFAs being the target of |
| | | the Mandate. This field makes sense |
| | | only for broadcast mandates (see end |
| | | of this section). |
| Managed | ResourcesId... | The list of resources to be managed |
| Resources | | by the AFA (e.g. their IP@ or MAC@ |
| | | or any other relevant ID). |
| ID of | Interface Id | The interface to the coordination |
| Coord | | system in charge of this autonomic |
| | | function. |
| Reporting | Policy | A policy describing which entities |
| Policy | | expect report from AFA, and which |
| | | are the conditions of these reports |
| | | (e.g. time wise and content wise) |
+-----------+----------------+--------------------------------------+
Table 2: Fields of AFA instance mandate
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.
Peloso & Ciavaglia Expires April 21, 2016 [Page 18]
Internet-Draft Autonomic Function October 2015
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.
+-----------+----------------+--------------------------------------+
| Field | Type | Description |
| Name | | |
+-----------+----------------+--------------------------------------+
| AFA Class | Struct | A unique identifier made out of at |
| ID | | least a Function Name, Version and |
| | | Provider Name (and Release Date). |
| AFA | Long | A unique Id of the AFA instance (if |
| Instance | | the AFA instance manifest gathers |
| ID | | multiple AFAs working together, this |
| | | would be a list). |
| Hosts | Resource ID | ID of the Machines on which the AFA |
| | | executes. |
| Managed | ResourcesId... | The list of resources effectively |
| Resources | | managed by the AFA (e.g. their IP@ |
| | | or MAC@ or any other relevant ID). |
| Acquired | Instance | Lists information that this AFA |
| Inputs | InfoSpec... | agent may acquire from the managed |
| | | resource(s) (e.g. the links load |
| | | over links with ID x and y). |
| External | Instance | Lists information that this AFA |
| Inputs | InfoSpec... | agent requires from the ecosystem |
| | | (e.g. the links load prediction over |
| | | links with ID x and y). |
| Possible | Instance | Lists actions that this AFA agent |
| Actions | ActionSpec | may enforce on its managed |
| | | resource(s) (e.g. modify the links |
| | | metrics over links x and y). |
+-----------+----------------+--------------------------------------+
Table 3: Fields of AFA instance manifest
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
Peloso & Ciavaglia Expires April 21, 2016 [Page 19]
Internet-Draft Autonomic Function October 2015
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.
Peloso & Ciavaglia Expires April 21, 2016 [Page 20]
Internet-Draft Autonomic Function October 2015
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", draft-ciavaglia-anima-coordination-00 (work
in progress), 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,
<http://www.rfc-editor.org/info/rfc2119>.
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", draft-behringer-anima-
reference-model-03 (work in progress), June 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,
<http://www.rfc-editor.org/info/rfc7575>.
Authors' Addresses
Peloso Pierre
Alcatel-Lucent
Villarceaux
Nozay 91460
FR
Email: pierre.peloso@alcatel-lucent.com
Peloso & Ciavaglia Expires April 21, 2016 [Page 21]
Internet-Draft Autonomic Function October 2015
Laurent Ciavaglia
Alcatel-Lucent
Villarceaux
Nozay 91460
FR
Email: laurent.ciavaglia@alcatel-lucent.com
Peloso & Ciavaglia Expires April 21, 2016 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-24 10:13:39 |