One document matched: draft-peloso-anima-autonomic-function-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7575.xml">
<!ENTITY ID-AUTO-MOD SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.behringer-anima-reference-model">
<!ENTITY ID-AUTO-COORD SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ciavaglia-anima-coordination">
<!ENTITY nbsp " ">
]>
<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc category="std"
ipr="noModificationTrust200811"
docName="draft-peloso-anima-autonomic-function-01.txt" >
<!-- Processing Instructions- PIs (for a complete list and description,
see file http://xml.resource.org/authoring/README.html and below... -->
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="yes" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="yes" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 42 characters -->
<title abbrev="Autonomic Function">A Day in the Life of an Autonomic Function</title>
<author fullname="Peloso Pierre"
initials="P."
surname="Peloso">
<organization>Nokia</organization>
<address>
<postal>
<street>Villarceaux</street>
<code>91460</code>
<city>Nozay</city>
<region/>
<country>FR</country>
</postal>
<email>pierre.peloso@nokia.com</email>
<uri/>
</address>
</author>
<author
fullname="Laurent Ciavaglia"
initials="L."
surname="Ciavaglia">
<organization>Nokia</organization>
<address>
<postal>
<street>Villarceaux</street>
<code>91460</code>
<city>Nozay</city>
<region/>
<country>FR</country>
</postal>
<email>laurent.ciavaglia@nokia.com</email>
</address>
</author>
<date year="2016" month="March" day="21"/>
<!-- Meta-data Declarations -->
<!-- Notice the use of & as an escape for & which would otherwise
start an entity declaration, whereas we want a literal &. -->
<area>Operations & Management</area>
<workgroup>ANIMA</workgroup>
<abstract>
<t>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, inter-operable autonomic functions with homogeneous operations and superior quality, and will have more freedom in their deployment scenarios.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section anchor="Sec_PbStatement" title="Problem statement">
<t>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.</t>
<t>An Autonomic Service 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.</t>
<t>There are 3 properties applicable to the installation of ASAs:
<list style="hanging">
<t hangText="The dynamic installation property"> allows installing an ASA on demand, on any hosts compatible with the ASA.</t>
<t hangText="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.</t>
<t hangText="The multiplicity property">allows controlling multiple sets of resources from a single ASA.</t>
</list>
</t>
<t>These three properties provide the operator a great variety of ASA 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.</t>
<t>Based on the above definitions, the ASA deployment process can be formulated as a multi-level/criteria matching problem.</t>
<t>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 these three phases.</t>
<t>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-cycle of ASAs. Beforehand, the following section will deal with the network operator's point of view with regards of autonomic networks.</t>
</section>
<section anchor="Sec_OperatorPoW" title="Motivations from an operator viewpoint">
<t>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.</t>
<t>To manage the networks according to the above variations, ASAs 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 ASA behavior according to its objectives. This step allows the network operator to determine which ASAs should execute on which domains of its network, with appropriate settings. At this stage, thanks to the intent-policy setting objectives to groups of ASAs, the network management should become far simpler (and less error-prone) than setting low-level configurations for each individual network resources.</t>
<section anchor="Sec_OpePoW_Example" title="Illustration of increasingly constraining operator's objectives">
<t>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:
<list style="hanging">
<t hangText="Step 1">The operator operates its network and benefits from the autonomic function on the nodes which have the installed ASAs.</t>
<t hangText="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%.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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 ASAs 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.</t>
<t hangText="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.</t>
</list>
</t>
<t>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.</t>
</section>
<section anchor="Sec_OpePoW_DeployScenar" title="Deployment scenarios of autonomic functions">
<t>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.</t>
<t>These various deployment scenarios are better understood by referring to the <xref target="Fig_HighLevelArchi" format="title"/>, Figure 1 of <xref target="I-D.behringer-anima-reference-model"/>. The figure is slightly extended for the purpose of the demonstration as follows:
<figure anchor="Fig_HighLevelArchi" title="High level view of an Autonomic Network">
<artwork>
<![CDATA[
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| : Autonomic Function 1 : |
| ASA 1.1 : ASA 1.2 : ASA 1.3 : ASA 1.4 |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: : :
: + - - - - - - - - - - - - - + :
: | Autonomic Function 2 | :
: | ASA 2.2 : ASA 2.3 | :
: + - - - - - - - - - - - - - + :
: : :
+ - - - - - - - - - - - - - + : + - - - - - - - - - - - - - +
| Autonomic Function 3 | : | Autonomic Function 4 |
| ASA 3.1 : ASA 3.2 | : | ASA 4.3 : ASA 4.4 |
+ - - - - - - - - - - - - - + : + - - - - - - - - - - - - - +
: : :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Autonomic Networking Infrastructure |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
+--------+ : +--------+ : +--------+ : +--------+
| Node 1 |-------| Node 2 |-------| Node 3 |-------| Node 4 |
+--------+ : +--------+ : +--------+ : +--------+
]]>
</artwork>
</figure>
</t>
<t><xref target="Fig_HighLevelArchi"/> depicts 4 Nodes, 4 Autonomic Functions and 10 Autonomic Service Agents. Let's list assumptions with regards of these elements.</t>
<t>Starting with nodes,
<list>
<t>each may be either an Unconstrained Autonomic Node, a Constrained Autonomic Node (or even a legacy one?),</t>
<t>they may well be of different models (or having different software versions),</t>
<t>they may well be of different equipment vendors,</t>
<t>they may well be of different technologies (some may be IP routers, some may be Ethernet switches or OTN switches...).</t>
</list>
</t>
<t>Pursuing with Autonomic Functions,
<list>
<t>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 objectives as two could optimize energy consumption (possibly on different areas as function 3 and function 4),</t>
<t>each may be composed of no more than one ASA (either because the function is responsible for a single node or because the function relies on a centralized implementation),</t>
<t>each may well be composed of different sort of ASAs, 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),</t>
<t>[Observation] Depending on the implementation the same piece of software may fulfill different roles or each role may come from a different from a different piece of code,</t>
<t>each has reached a given organization, meaning an organized set of ASAs 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)</t>
<t>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],</t>
<t>each having its scope of work in terms of objective to reach and area/space/part of the network to manage.</t>
</list>
</t>
<t>Completing with individual Autonomic Service Agents, those are pieces of software:
<list>
<t>embedded inside the node/equipment OS (hence present since the bootstrap or OS update of the equipment),</t>
<t>running in a machine different than the node (this could be a node controller or any other host or virtual machine)</t>
<t>[Observation] In the latter case, the ASA would likely require external credentials to interact with the node,</t>
<t>directly monitoring and configuring the equipment (likely requires the ASA 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)</t>
<t>either activated at start-up or as the result of a management action,</t>
<t>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)</t>
<t>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),</t>
<t>sharing a technical objective with the other ASAs of the Autonomic Function they belong, (or at least a similar one)?</t>
<t>can it contains multiple technical objective?</t>
<t>must the technical objective be intrinsic or can it be set by a managing entity (a network operator or a management system)?</t>
</list>
</t>
<t>The last three points being largely questionable are marked as questions.</t>
<t>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.
<figure anchor="Fig_AFAandHW" title="Interaction possibilities between ASA and Resources">
<artwork>
<![CDATA[
+ - - - + +-------------+
| ASA |------>| NMS *<--*
+ - - - + +------^------+ |
| | | |
| | +------V------+ |
| +-------->| Controller | |
| +------^------+ | +---------------------+
| | | | + - - - + |
| +------V------+ | | | ASA | Node OS |
+------------>| Node OS *<--* | + - - - + |
+------^------+ +--------------*------+
| |
+------V------+ +-----*------+
| Node | | Node |
+-------------+ +------------+
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="Sec_OpePoW_Requirements" title="Operator's requirements with regards to autonomic functions">
<t>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...
<list>
<t>Being capable to set those functions a scope of work in term of area of duty,</t>
<t>Being capable to monitor the actions taken by the autonomic functions, and which are its results (performance with regards to the function KPIs)</t>
<t>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...)</t>
<t>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.</t>
</list>
</t>
</section>
</section>
<section title="Installation phase">
<t>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.</t>
<t>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.</t>
<t>There are 3 properties applicable to the installation of ASAs:
<list style="hanging">
<t hangText="The dynamic installation property"> allows installing an ASA on demand, on any hosts compatible with the ASA.</t>
<t hangText="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.</t>
<t hangText="The multiplicity property">allows controlling multiple sets of resources from a single ASA.</t>
</list>
</t>
<t>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.</t>
<section title="Operator's goal">
<t>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...).</t>
<t>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.</t>
<t>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...).</t>
<t>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.</t>
</section>
<section title="Installation phase inputs and outputs">
<t>Inputs are:
<list style="hanging">
<t hangText="[ASA class of type_x]">that specifies which classes ASAs to install,</t>
<t hangText="[Installation_target_Infrastructure]">that specifies the candidate Installation Hosts,</t>
<t hangText="[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.</t>
</list>
</t>
<t>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.</t>
<t>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).</t>
</section>
</section>
<section anchor="Sec_Inst" title="Instantiation phase">
<!--
Operator's goal: [ASA of type_x instances] ready to control [Instantiation_target_Infrastructure] with [Instantiation_target_parameters].
Input: [ASA of type_x], [Instantiation_target_Infrastructure], [Instantiation_target_parameters]. mandate?
- in the decoupled mode, additional input needed for the ASA instances placement function, e.g. under which criteria/constraints.
Output: up-to-date instantiated ASA directory == [list of ASA of type_x instances] configured with [Instantiation_target_parameters], running on [list of hosts], ready to control [Instantiation_target_Infrastructure] ; output useful also for coordination function (interactions dynamic map).
Describe the steps to achieve operator's goal, highlighting the elements to specify in ANIMA and if relevant possible usage of existing ANIMA components (e.g. GRASP, ACP...).
Define an instantiation phase Intent? (mandate)
Condition to pass to next phase: validate [ASA of type_x instances] ready to control [Instantiation_target_Infrastructure] with [Instantiation_target_parameters].
State of ASA: ready. (not running/operating).
Commands: start (enter operation phase under operation phase policy/mandate). delete (revert to installation phase).
-->
<t>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.</t>
<t>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).</t>
<t>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).</t>
<section anchor="Sec_Inst_Goal" title="Operator's goal">
<t>Through this phase, the operator wants to control its autonomic network in two things:
<list style="format %d">
<t>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),</t>
<t>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).</t>
</list>
Additionally in this phase, the operator may want to set objectives to autonomic functions, by configuring the ASAs technical objectives.
</t>
<t>The operator's goal can be summarized in an instruction to the ANIMA ecosystem matching the following pattern:
<list>
<t>[ASA of type_x instances] ready to control [Instantiation_target_Infrastructure] with [Instantiation_target_parameters]</t>
</list>
</t>
<!--t>
<list style="symbols">
<t>Every sort of ASA is not meant to work on its own. E.g. some ASA may be designed to interact with similar ASAs controlling neighboring nodes. Under such conditions, identifying and establishing these interactions is a prerequisite to running.</t>
<t>Every sort of ASA is not meant to work configuration-less. E.g. some ASA may have configuration settings, let this be illustrated by a Load-Balancing ASA, which configuration setting could be the maximum load of links. Under such conditions, having configuration set is a prerequisite to running.</t>
<t>Some operators may want to get ASA to run coherently over domains with regards to the 2 previous points, i.e. establish ASA interactions inside each domain, and have a consistent configuration over each domain (e.g. with a per domain value of maximum link load).</t>
<t>Every operator may not trust enough ASAs (or some sorts of ASAs) to let them run out of control, hence these operators may stipulate when they are willing some ASAs to execute, while safeguarding the capacity to halt the execution. Even further the operator may be willing to let some ASA under trial, forbidding them to execute their actions without having received a human approval...</t>
</list>
</t-->
</section>
<section anchor="Sec_Inst_InOut" title="Instantiation phase inputs and outputs">
<t>Inputs are:
<list style="hanging">
<t hangText="[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),</t>
<t hangText="[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,</t>
<t hangText="[Instantiation_target_parameters]">that specifies which are the technical objectives to be set to ASAs (e.g. an optimization target)</t>
</list>
</t>
<t>Outputs are:
<list style="hanging">
<t hangText="[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,</t>
</list>
</t>
</section>
<section anchor="Sec_Inst_Reqs" title="Instantiation phase requirements">
<t></t>
<t>The instructions described in section 4.2 could be either:
<list style="hanging">
<t hangText="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].</t>
<t hangText="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].</t>
</list>
</t>
<t>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 <xref target="Sec_Specs_Mandate"/> - <xref target="Sec_Specs_Mandate" format="title"/>).</t>
<t>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 <xref target="Sec_Specs_InstanceManifest"/> - <xref target="Sec_Specs_InstanceManifest" format="title"/>).</t>
<t>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:
<list style="symbols">
<t>the coordination entities (see <xref target="I-D.ciavaglia-anima-coordination"/> - <xref target="I-D.ciavaglia-anima-coordination" format="title"/>)</t>
<t>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 <xref target="Sec_Operation"/> - <xref target="Sec_Operation" format="title"/>)</t>
</list>
</t>
</section>
</section>
<section anchor="Sec_Operation" title="Operation phase">
<t>Note: This section is to be further developed in future revisions of the document.</t>
<t>During the Operation phase, the operator can:
<list>
<t>Activate/Deactivate ASA: meaning enabling those to execute their autonomic loop or not.</t>
<t>Modify ASAs targets: meaning setting them different objectives.</t>
<t>Modify ASAs managed resources: by updating the instance mandate which would specify different set of resources to manage (only applicable to decouples ASAs).</t>
</list>
</t>
<t>During the Operation phase, running ASAs can interact the one with the other:
<list>
<t>in order to exchange knowledge (e.g. an ASA providing traffic predictions to load balancing ASA)</t>
<t>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)</t>
</list>
</t>
<t>During the Operation phase, running ASAs are expected to apply coordination schemes
<list>
<t>then execute their control loop under coordination supervision/instructions</t>
</list>
</t>
<!--section anchor="Sec_Op_Goal" title="Operator's goal">
<t></t>
</section>
<section anchor="Sec_Op_InOut" title="Operation phase Input/Outputs">
<t></t>
</section>
<section anchor="Sec_Op_Reqs" title="Operation phase requirements">
<t></t>
</section-->
<!--t>
Operator's goal:
-for ASA (1..n): [ASA of type_x instances] operate in [performance envelope]. If breach, inform [management (TBD) or ?]; more actions could be envisaged on breach event (halt [all,M,A,P,E,K], change parameters, inspect logs, start analysis of behavior, go into test/trust building mode, change reporting frequency).
-for ASA (1..n): [ASA of type_x instances] [reporting policy][knowledge policy e.g. "cost of information"][coordination policy].
-for group(s) of ASA / network as a whole: operate in [stability envelope], [performance envelope], relative to / link with service level (i.e. ASAs contribute to deliver service x,y,z [service level envelope])(FFS).
aspects of cost of operation (
Input: mandate/operation phase policy describing behavior, performance envelope, reporting, knowledge optim., coordination related aspects...
Output: green / red lights? ; performance indicators, reporting, generated knowledge, interacting groups of ASA instances,
Define an operation phase Intent? (mandate or operation phase policy cf UMF control policy?)
Including interactions among ASAs: intra/inter-AF, behaving as a group, dependency, correlation, cooperation, coordination, knowledge. composition of ASA of different AF type ("chaining AF / ASA).
Discuss about operating regimes(?), aspects of coordination, knowledge...
Condition to start: operating policy based: by default, on start command, partial start (e.g. only sense), on event? e.g. threshold passed, timeout expiration (e.g. test phase), internal/external event e.g. enough knowledge acquired, dependent ASA ready, coordination command.
State of ASA: operational. + other sub-states (cf commands).
Commands: change regime, change parameters, start [all, M,A,P,E, K], halt [all, M,A,P,E, K], stop (revert to instantiation phase in ready-not-checked state), test...
Examples: change in instantiation == if change in coverage of ASA or type of ASA ; change in operation == if (only) parameters change (cf UMF control policy.
(put example of GRASP message?)
-ACK of LB ASAs when policy received and understood ?
-How ASAs know and verify that the coverage zone is complete and correct ?
Alternative: not GRASP to get and communicate/disseminate the Intent. Instead, TBD mechanism/function to generate/translate the input operator policy in proper policy/Intent format.
And TBD mechanism/function to communicate the policy/Intent message to the target/all ASAs. (if target list of ASAs (e.g. the LB ones), how determined? e.g. ASA function exposed/discovered, when, to whom, stored/indexed...?)
</t-->
</section>
<section anchor="Sec_ASASpecs" title="Autonomic Function Agent specifications">
<section anchor="Sec_Specs_LC" title="Life-cycle">
<t>Based on the phases described above, this section defines formally the different states experienced by Autonomic Function Agents during their complete life-cycle.</t>
<t>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.</t>
<t>The installation and Instantiation phase will be concluded by ASA reaching respectively Installed and Instantiated states.</t>
<figure anchor="Fig_LC" title="Life cycle of an Autonomic Function Agent" align='center'>
<artwork align='center'>
<![CDATA[
+--------------+
Undeployed ------>| |------> Undeployed
| Installed |
+-->| |---+
Mandate | +--------------+ | Receives a
is revoked | +--------------+ | Mandate
+---| |<--+
| Instantiated |
+-->| |---+
set | +--------------+ | set
down | +--------------+ | up
+---| |<--+
| Operational |
| |
+--------------+
]]>
</artwork>
</figure> <!--
list of commands: with definitions, parameters, conditions...
list of states: with definitions -->
<t>Here are described the successive states of ASA.
<list style="hanging">
<t hangText="Undeployed - ">In this "state", the Autonomic Function Agent is a mere piece of software, which may not even be available on any host.</t>
<t hangText="Installed - ">In this state, the Autonomic Function Agent is available on a (/multiple) host(s), and after having shared its ASA class Manifest (which describes in a generic way independently of the deployment how the ASA would work). In this state the ASA is waiting for an ASA Instance Mandate, to determine which resources ti manage (when the ASA 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).</t>
<t hangText="Instantiated - ">In this state the Autonomic Function Agent has the knowledge of which resources it is meant to manage. In this state the ASA is expecting a set Up message in order to start executing its autonomic loop. From this state on the ASA can share an Instance Manifest (which describes how the ASA instance is going to work).</t>
<t hangText="Operational - ">In this state, ASAs are executing their autonomic loop, hence acting on network, by modifying resources parameters. A set down message will turn back the ASA in an Instantiated state.</t>
</list>
The messages are described in the following sections.
</t>
</section>
<section anchor="Sec_Specs_ClassManifest" title="ASA Class Manifest">
<t>An ASA class is a piece of software that contains the computer program of an Autonomic Function Agent.</t>
<t>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.</t>
<t>This section details a format for an ASA class manifest, which is (a machine-readable) description of both the autonomic function and the piece of code that executes the function.</t>
<texttable anchor="Tab_Class_Manifest" title="Fields of ASA class manifest">
<ttcol align='center'>Field Name</ttcol>
<ttcol align='center'>Type</ttcol>
<ttcol align='left'>Description</ttcol>
<c>ID</c>
<c>Struct</c>
<c>A unique identifier made out of at least a Function Name, Version and Provider Name (and Release Date).</c>
<c>Description</c>
<c>Struct</c>
<c>A multi-field description of the function performed by the ASA, it is meant to be read by the operator and can point to URLs, user-guides, feature descriptions.</c>
<c>Installation properties</c>
<c>3 Booleans</c>
<c>Whether the ASA is dynamically installable, can be decoupled from the NE and can manage multiple resources from a single instance (see <xref target="Sec_PbStatement"/> - <xref target="Sec_PbStatement" format="title"/>).</c>
<c>Possible Hosts</c>
<c>OS...</c>
<c>Lists the OS/Machines on which the ASA can be executed. [Only if ASA is dynamically installable]</c>
<c>Network Segment</c>
<c>NetSegment...</c>
<c>Lists the network segments on which the autonomic function is applicable (e.g. IP backbone versus RAN).</c>
<c>Manageable Equipments</c>
<c>Equipments...</c>
<c>Lists the nodes/resources that this piece of code can manage (e.g. ALU 77x routers, Cisco CRS-x routers, Huawei NEXE routers).</c>
<c>Autonomic Loop Type</c>
<c>Enum</c>
<c>States what is the type of loop MAPE-K and whether this loop can be halted in the course of its execution.</c>
<c>Acquired Inputs</c>
<c>Raw InfoSpec...</c>
<c>Lists the nature of information that an ASA agent may acquire from the managed resource(s) (e.g. the links load).</c>
<c>External Inputs</c>
<c>Raw InfoSpec...</c>
<c>Lists the nature of information that an ASA agent may require/wish from other ASA in the ecosystem that could provide such information/knowledge.</c>
<c>Possible Actions</c>
<c>Raw ActionSpec</c>
<c>Lists the nature of actions that an ASA agent may enforce on ASA the managed resource(s) (e.g. modify the links metrics).</c>
<c>Technical Objectives Description</c>
<c>Technical Objective Spec...</c>
<c>Lists the type of technical objectives that can be handled/received by the ASA (e.g. a max load of links).</c>
</texttable>
</section>
<section anchor="Sec_Specs_Mandate" title="ASA Instance Mandate">
<t>An ASA instance is the ASA agent: a running piece of software of an ASA class. A software agent is a persistent, goal-oriented computer program that reacts to its environment and interacts with other elements of the network.</t>
<t>In order to install and instantiate appropriately an autonomic function in its network, the operator may specify to ASA instances what they are supposed to do: in term of which resources to manage and which objective to reach.</t>
<t>This section details a format for an ASA Instance Mandate, which is (a machine-readable) set of instructions sent to create autonomic functions out of ASA.</t>
<texttable anchor="Tab_Inst_Mandate" title="Fields of ASA instance mandate">
<ttcol align='center'>Field Name</ttcol>
<ttcol align='center'>Type</ttcol>
<ttcol align='left'>Description</ttcol>
<c>ASA class Pattern</c>
<c>Struct</c>
<c>A pattern matching the ID (or part of it) of ASAs being the target of the Mandate. This field makes sense only for broadcast mandates (see end of this section).</c>
<c>Managed Resources</c>
<c>ResourcesId...</c>
<c>The list of resources to be managed by the ASA (e.g. their IP@ or MAC@ or any other relevant ID).</c>
<c>ID of Coord</c>
<c>Interface Id</c>
<c>The interface to the coordination system in charge of this autonomic function.</c>
<c>Reporting Policy</c>
<c>Policy</c>
<c>A policy describing which entities expect report from ASA, and which are the conditions of these reports (e.g. time wise and content wise)</c>
</texttable>
<t>An ASA instance mandate could be either:
<list style="hanging">
<t hangText="sent to a targeted ASA">In which case, the receiving Agent will have to manage the specified list of resources,</t>
<t hangText="broadcast to all ASA">In which case, the ASAs 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).</t>
</list>
</t>
</section>
<section anchor="Sec_Specs_InstanceManifest" title="ASA Instance Manifest">
<t>Once the ASAs are properly instantiated, the operator and its managing system need to know which are the characteristics of these ASAs.</t>
<t>This section details a format for an ASA instance manifest, which is (a machine-readable) description of either an ASA or a set of ASAs gathered into an autonomic function.</t>
<texttable anchor="Tab_Inst_Manifest" title="Fields of ASA instance manifest">
<ttcol align='center'>Field Name</ttcol>
<ttcol align='center'>Type</ttcol>
<ttcol align='left'>Description</ttcol>
<c>ASA Class ID</c>
<c>Struct</c>
<c>A unique identifier made out of at least a Function Name, Version and Provider Name (and Release Date).</c>
<c>ASA Instance ID</c>
<c>Long</c>
<c>A unique Id of the ASA instance (if the ASA instance manifest gathers multiple ASAs working together, this would be a list).</c>
<c>Hosts</c>
<c>Resource ID</c>
<c>ID of the Machines on which the ASA executes.</c>
<c>Managed Resources</c>
<c>ResourcesId...</c>
<c>The list of resources effectively managed by the ASA (e.g. their IP@ or MAC@ or any other relevant ID).</c>
<c>Acquired Inputs</c>
<c>Instance InfoSpec...</c>
<c>Lists information that this ASA agent may acquire from the managed resource(s) (e.g. the links load over links with ID x and y).</c>
<c>External Inputs</c>
<c>Instance InfoSpec...</c>
<c>Lists information that this ASA agent requires from the ecosystem (e.g. the links load prediction over links with ID x and y).</c>
<c>Possible Actions</c>
<c>Instance ActionSpec</c>
<c>Lists actions that this ASA agent may enforce on its managed resource(s) (e.g. modify the links metrics over links x and y).</c>
</texttable>
</section>
</section>
<section anchor="Sec_Implication" title="Implication for other ANIMA components">
<section anchor="Sec_Impl_MoreEntities" title="Additional entities for ANIMA ecosystem">
<t>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 ASAs, the ASA Hosts and the ASA Management function. This function serves as the interface between the network operator and its managed infrastructure (i.e. the autonomic network). The ASA management function distributes instructions to the ASAs such as the ASA Instance Mandate, ASA set up/set down commands and also trigger the ASA installation inside ASA Hosts. This function is likely to be co-located or integrated with the function responsible for the management of the Intents.</t>
<t>In this first version, we do not prescribe any requirements on the way the ASA 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 analyzed by the working group.</t>
<t></t>
</section>
<section anchor="Sec_Impl_GRASPandACP" title="Requirements for GRASP and ACP messages">
<t>GRASP and ACP seems to be the best (and currently only) candidates to convey the following messages between the ASA Management function and the ASAs:
<list>
<t>ASA Class Manifest</t>
<t>ASA Instance Mandate (and Revoke Mandate)</t>
<t>ASA Instance Manifest</t>
<t>Set Up and Set Down messages</t>
</list>
These section concludes with requests to GRASP protocol designers in order to handle the 3 last messages of the list above. These 3 messages form the minimal set of features needed to guarantee some control on the behavior of ASAs to network operators.
</t>
<t>A mechanism similar to the bootstrapping one would usefully achieve discovery of pre-installed ASAs, and possibly provide those with a default Instance Mandate.</t>
<t>A mechanism to achieve dynamic installation of ASAs compatible with ACP and GRASP remains to be identified.</t>
<t>In the case of decoupled ASAs, 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 ASAs 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.</t>
<section title="Control when an ASA runs">
<t>To control when an ASA runs (and possibly how it runs), the operator needs the capacity to start and stop ASAs. That is why an imperative command type of message is requested from GRASP.</t>
<t>Additionally this type of message could also be used to specify how the ASA is meant to run, e.g. whether its control loop is subdued to some constraints in terms of pace of execution or rhythm of execution (once a second, once a minute, once a day...)</t>
<t>Below a suggestion for GRASP:</t>
<t>In fragmentary CDDL, an Imperative message follows the pattern:</t>
<t>imperative-message = [M_IMPERATIVE, session-id, initiator, objective]</t>
<t>...</t>
</section>
<section title="Know what an ASA does to the network">
<t>To know what an ASA does to the network, the operator needs to have the information of the elements either monitored or modified by the ASA, hence this ASA should disclose those.</t>
<t>The disclosing should take the form of a ASA Instance Manifest (see <xref target="Sec_Specs_InstanceManifest"/> - <xref target="Sec_Specs_InstanceManifest" format="title"/>), which could be conveyed inside a GRASP discovery message, hence the fields of the ASA Instance Manifest would be conveyed inside the objective.</t>
<t>At this stage there are two options:
<list style="number">
<t>The whole manifest is conveyed as an objective.</t>
<t>Each field of the manifest is conveyed as an individual objective, more precisely, the acquired inputs would appear as discovery only, and the modifiable parameters would appear as negotiation objective. The unclear part is the expression of requested fields (when the ASA claims being a client for such objective). Could one of the already existing objective options a good match or should a new one be created.</t>
</list>
</t>
<t>...</t>
</section>
<section title="Decide which ASA control which equipment">
<t>To determine which ASA controls which equipment (or vice-versa which equipments are controlled by which ASAs), the operators needs to be able to instruct ASA before the end of their bootstrap procedure.</t>
<t>These instructions sent to ASA during bootstrapping should take the format of an ASA Instance Mandate (see <xref target="Sec_Specs_Mandate"/> - <xref target="Sec_Specs_Mandate" format="title"/>). This ASA Instance Mandate are sorts of Intents, and as GRASP is meant to handle Intents in a near future, it would be beneficial to already identify which sort of GRASP message are meant to be used by Intent in order to already define those. An option could be to reuse the Imperative messages defined above.</t>
<t>...</t>
</section>
</section>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>This draft was written using the xml2rfc project.</t>
<t>This draft content builds upon work achieved during UniverSelf FP7 EU project.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t> TBD
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split to informative and normative -->
<references title="Normative References">
&RFC2119;
&ID-AUTO-COORD;
</references>
<references title="Informative References">
&RFC7575;
&ID-AUTO-MOD;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 10:04:26 |