One document matched: draft-ciavaglia-anima-coordination-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 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-ciavaglia-anima-coordination-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>Autonomic Functions Coordination</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author
fullname="Laurent Ciavaglia"
initials="L."
surname="Ciavaglia">
<!-- abbrev not needed but can be used for the header
if the full organization name is too long -->
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Villarceaux</street>
<code>91460</code>
<city>Nozay</city>
<region/>
<country>FR</country>
</postal>
<email>laurent.ciavaglia@alcatel-lucent.com</email>
<!--
If I had a phone, fax machine, and a URI, I could add the following:
<phone>+1-408-555-1234</phone>
<facsimile>+1-555-911-9111</facsimile>
<uri>http://www.example.com/</uri>
-->
</address>
</author>
<author fullname="Peloso Pierre"
initials="P."
surname="Peloso">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Villarceaux</street>
<code>91460</code>
<city>Nozay</city>
<region/>
<country>FR</country>
</postal>
<email>pierre.peloso@alcatel-lucent.com</email>
<uri/>
</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> This document describes a management solution capable
of avoiding conflicts between autonomic functions. The objective of such a solution
is to avoid network instabilities, by insuring that the autonomic functions pursuing
different goals will cooperate instead of antagonize each other. This document provides both requirements and specifications for such a solution.</t>
<t> Disclaimer: the version -01 of the draft has been issued to reactivate the document in order to allow discussion within the ANIMA WG about the coordination of autonomic functions. </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 title="Introduction">
<t>The document <xref target="RFC7575" format="title"/>
<xref target="RFC7575"/> explains the fundamental
concepts behind Autonomic Networking, and defines the relevant terms in this space.
The central concepts are Autonomic Nodes and Autonomic Functions.</t>
<t>An Autonomic Function is characterized by its implementing a closed control-loop, which we can summarize as successively:
<list style="numbers">
<t>Gathers metrics monitored by network equipments (that could be Autonomic Nodes, but not limited to)</t>
<t>Determines/computes new actions out of these inputs plus possibly some of the additional elements: e.g. contextual inputs, provided intents and gathered experience,</t>
<t>Set the computed parameters values (from the previous actions) inside the appropriate network equipments,</t>
<t>These new parameters values influence the network behavior, such that the metrics gathered by the autonomic function will evolve,</t>
</list>
(Section 7.5 of <xref target="I-D.behringer-anima-reference-model"/> details more the control loops).
</t>
<t>
The Autonomic Functions are normally designed to stabilize (converge), at least when the network conditions are themselves stable. However, conflicting interactions among Autonomic Functions can create instabilities even when the network conditions have not varied.
</t>
<t>The document <xref target="I-D.behringer-anima-reference-model" format="title"/>
<xref target="I-D.behringer-anima-reference-model"/> describes the reference model of
autonomic networks, by describing the architecture and enumerating fundamental blocks (either infrastructure
pieces or enabling functionalities). One of these functionalities pertains to the concomitant execution of
multiple autonomic functions in a safe way (i.e. avoiding conflicts between these different autonomic loops).
Section 8 of <xref target="I-D.behringer-anima-reference-model"/> (Coordination between Autonomic Functions)
provides a brief introduction to this functionality.</t>
<t>This document tackles this topic by successively:
<list style="numbers">
<t>Explaining why such a functionality is needed,</t>
<t>Detailing which objectives such a functionality should reach,</t>
<t>Sketching a simple behavior of this function,</t>
<t>Providing requirements on autonomic functions (a tentative list in this document version),</t>
<t>Providing some specifications items (in this preliminary version, while future versions would provide specifications),</t>
</list>
</t>
</section>
<section anchor="Sec_PbStatement" title="Problem Statement">
<t>The need to coordinate the joint behavior of autonomic functions arises from the need to cope with conflicting situations and to provide the operator with the ability to steer autonomic network performance to a given (intended) operational point.</t>
<t>Several interaction types exist among autonomic functions such as cooperation, dependency, or conflict (and possibly others [TBD]).</t>
<t>Cooperation happens when an autonomic function can improve the behavior or performance of another autonomic function, such as a traffic forecasting function used by a traffic allocation function.</t>
<t>Dependency happens when an autonomic function cannot work without another one being present or accessible in the autonomic network.</t>
<t>Conflicts among autonomic functions emerges from direct and indirect interactions. A metric value conflict is a conflict where one metric is influenced by parameters of different autonomic functions. A parameter value conflict is a conflict where one parameter is modified by different autonomic functions. A simple example of conflicting interaction between autonomic functions is the oscillations caused by an energy-saving function (which switches-off interfaces to reduce power consumption) and a load-balancing function (which switches-on interfaces to reduce link load).</t>
<t>Solving the coordination problem beyond one-by-one cases can rapidly become intractable if one considers networks composed of tens, hundreds or thousands of simultaneously interacting functions. Specifying a common functional block on coordination is a first step to address the problem in a systemic way.</t>
</section>
<section anchor="Sec_GuidingPrinciples" title="Guiding principles">
<t>A coordination function appears as an essential component of the ANIMA reference model in order to achieve better control on the performance, stability and convergence of autonomic networks.</t>
<t>As guiding principles, the ANIMA coordination function should:
<list style="symbols">
<t>Maximize the autonomic network utility, i.e. mitigate the (observed or inferred) detrimental effects of conflicting autonomic functions (Efficiency property).</t>
<t>Balance the autonomic network goal(s) and autonomic functions individual goal(s) (Congruence and Coherence properties).</t>
<t>Inform the autonomic network operator (being a human or a machine) with processed and aggregated "call(s) for governance" in case the goals are incompatible and no satisfactory solution can be found (i.e. compliant with the intent).</t>
<t>Deviate the least possible autonomic functions from their design objective(s) and individual goal(s) (Liberality property).</t>
<t>Impose minimal additional requirements on the external specifications of autonomic functions, such as the format and content of the autonomic function descriptor(s)/capabilities (Economy property).</t>
<t>Not impose any requirement on the internal specifications of autonomic functions (Independence property).</t>
<t>Support multiple coordination mechanism types (Plurality property).</t>
<t>Enable coordination mechanisms to be plugged in at deploy- and run-time (Modularity property).</t>
<t>Determine the most suitable coordination mechanism(s) to apply according to contexts (e.g. change in autonomic functions, change in intents/goals, change in coordination mechanisms available) (Dynamicity property).</t>
<t>Develop a long-term vision of the autonomic functions interactions and devise the most suitable plan to address the conflicting cases, based on available coordination mechanisms and mission(s) set by the intent (Adaptivity property).</t>
<t>Be able to fully or partially suspend/stop one or multiple autonomic functions, temporarily or an undetermined amount of time until the situation evolves (Authority property).</t>
<t>Be able to operate equally well in a distributed or centralized manner (Distributivity property).</t>
<t>Be able to cope with several thousands of simultaneous interactions (Performance and scalability property).</t>
</list>
</t>
</section>
<section anchor="Sec_Skecth" title="Initial sketch of a Coordination Function">
<t>For the sake of the following sections, this section is providing a rough description of the functioning of a coordination function, and how it organizes itself along the network time.</t>
<section anchor="Sec_Sketch_Preliminary" title="Preliminary assumptions">
<t>Autonomic functions do exist in different states corresponding to different steps in their life-cycle.
The description of some of these steps is better understood by referring to the <xref target="Fig_HighLevelArchi" format="title"/> which is depicted in Figure 1 of <xref target="I-D.behringer-anima-reference-model"/>, which Figure is copied below:</t>
<figure anchor="Fig_HighLevelArchi" title="High level view of an Autonomic Network">
<artwork>
<![CDATA[
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: : Autonomic Function 1 : :
: ASA 1 : ASA 1 : ASA 1 : ASA 1 :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: : :
: +- - - - - - - - - - - - - - + :
: : Autonomic Function 2 : :
: : ASA 2 : ASA 2 : :
: +- - - - - - - - - - - - - - + :
: : :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: Autonomic Networking Infrastructure :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
+--------+ : +--------+ : +--------+ : +--------+
| Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n |
+--------+ : +--------+ : +--------+ : +--------+
]]>
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Undeployed - ">In this state, the Autonomic Function is a mere piece of software, which may not even be copied on any node,
but which may well be the code of the Autonomic Service Agents (ASA) corresponding to this Autonomic Function.</t>
<t hangText="Instantiated/Deployed - ">In this state the Autonomic Function is deployed, which means the ASA are available in the Nodes and
gathered together into an Autonomic Function. In this state the autonomic function is bind to a scope which is the part of the network
on which the autonomic function is meant to perform its duties. As a first approximation, the scope matches the Nodes which receive
instructions from one of the ASA gathered in the Autonomic Function.</t>
<t hangText="Running - ">In this state, the autonomic function is deployed and is executing its closed control loop,
hence acting on network, by modifying Nodes parameters.</t>
</list>
The above list of states is not meant to be exhaustive, and would be better expanded in a document dedicated to Autonomic Functions,
nevertheless the distinctions between the three above states are unavoidable.
</t>
</section>
<section anchor="Sec_Skecth_Mechanisms" title="Algorithms for coordination">
<t>This sub-section does not intend to specify algorithms capable of achieving coordination between autonomic functions,
but means to illustrate different ways of avoiding conflicts, we can briefly list the following families of algorithms:
<list style="hanging">
<t hangText="Random token - ">This algorithm is insuring that each autonomic function is executing its control-loop the one after the other, the sequence is following a random pattern.</t>
<t hangText="Time separation - ">This algorithm is insuring that each autonomic function is executing its control-loop at different rates, e.g. for 2 functions: one is running fast enough to have time to converge in between two iterations of the slower one (this algorithm requires proper settings with regards of the autonomic functions to coordinate).</t>
<t hangText="Efficiency bids - ">In this algorithm, each autonomic function predicts which improvement its executing of its control-loop would bring, hence the coordination algorithms, picks the autonomic function promising the "best" improvement, and grants it the right to execute.</t>
</list>
</t>
</section>
<section anchor="Sec_Skecth_Behavior" title="Behavior of the coordination function">
<t>This function is expected to steer the network towards a better "operating" point, by
avoiding/mitigating detrimental interactions between Autonomic Functions.</t>
<t>The first step of such a process is the identification of these interactions and their classification in order to determine which ones have to be handled (at least the problematic ones i.e. conflicting ones).</t>
<t>The second step is the gathering of the identified interactions in groups that can be handled together while insuring the proper behavior of the network. This step intends to avoid handling all the interactions in one raw, but possibly to split the whole problem in smaller pieces, easier to handle.</t>
<t>The third step is the instantiation of coordination mechanisms well suited to handle each groups of interactions previously identified. Hence these coordination mechanisms would control the autonomic functions in order to insure a network behavior matching the intents of the network operator.</t>
<section title="Times of the identification of interactions between AF">
<t>As the coordination function handles autonomic functions, its working is related to the different states of autonomic functions, namely, build-time, deploy-time and run-time. Hence the coordination function also present a life-cycle consisting in these 3 different states , in which the coordination function behaves according to the following descriptions:</t>
<t>At build-time, a common description of the autonomic function attributes (metrics, parameters, actions, capabilities...) allows to construct a "static interaction map" from the a-priori knowledge that can be derived/inferred from the functions attributes relationship. The static interaction map can be used as a first element by the operator (or mechanism) to (pre-)define policies and priorities as coordination strategies to manage the a-priori conflicts identified.</t>
<t>At deploy-time, autonomic functions are deployed on the network (i.e. installed, configured, instantiated...) but are not yet active/acting on the network. At this stage, for each instance of the autonomic functions and on a per resource basis, an inventory of the metrics monitored, of the actions performed and their relationships can be realized, resulting in a "dynamic interaction map".
The dynamic interaction map provides the basis to identify conflicts that will happen at run-time, categorize them and plan for the appropriate coordination strategies/mechanisms.</t>
<t>At run-time, conflicts happens and arbitration is driven by the coordination strategies and available mechanisms. This is also the stage where new dependencies can be observed and inferred, ultimately resulting in update of the dynamic interaction map and possible adaptation of the coordination strategies and mechanisms.</t>
</section>
<section title="Times of the coordination of AF">
<t>TBC</t>
</section>
</section>
<section anchor="Sec_Sketch_Conclusions" title="Conclusions">
<t>Some of the previous elements impact directly the coordination function, some other imply capacities of external elements such as Autonomic Functions and the Autonomic Control Plane. This conclusion is briefly categorizing and summarizing those:
<list style="hanging">
<t hangText="Requirements onto the AF - ">
<list>
<t>a descriptor of metrics and parameters/actions: a generic way of describing the inputs and outputs of the closed control loop, in order to identify the interactions.</t>
<t>a life-cycle: to match the process of the coordination (shortly stated, interaction identification and then conflict solving).</t>
<t>a common command interface of the autonomic functions: for the coordination to control the pace at which an autonomic function executes its control loop.</t>
</list>
</t>
<t hangText="Requirements onto the ACP - ">
<list>
<t>a common representation of information and knowledge: a function used to build the interactions maps.</t>
</list>
</t>
<t hangText="Requirements onto the Coordination Function - ">
<list>
<t> interaction identification: a function in charge of identifying interactions</t>
<t> interaction grouping: a function coping with grouping the previously identified interactions, in bundles that can be managed independently (for scalability concerns)</t>
<t> supporting various coordination mechanisms: to have the freedom of picking the most appropriate one.</t>
<t> interaction solving: a function capable of handling an independent bundle of interactions by controling the implied autonomic functions according to the picked algorithms.</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section anchor="Sec_Req_Ext" title="External Requirements">
<t>At this stage of the document, this section is merely providing a structure of its content.</t>
<t>In order to achieve the aforementioned goals (detailed in section <xref target="Sec_GuidingPrinciples"/>) a Coordination Functional Block should bring the following features:
<list>
<t>a common description of autonomic functions attributes and its life-cycle.</t>
<t>a common command interface between the coordination "agent" and the autonomic functions.</t>
<t>a common representation of information and knowledge (cf. interaction maps).</t>
</list>
Guidelines, recommendations or BCPs can also be provided for the aspects pertaining to the coordination strategies and mechanisms.</t>
<t>The coordination function requires a certain set of elements to work properly such as the autonomic function descriptor and the interaction map(s).</t>
<section anchor="Sec_Reqs_AFD" title="Autonomic Function Descriptor (AFD)">
<t>The Autonomic Function Descriptor (AFD) should contain the following elements:
<list>
<t>actions, metrics, parameters, controlled resources.</t>
</list>
</t>
</section>
<section anchor="Sec_Reqs_ControlIfc" title="control/command interface of AF">
<t/>
<t>The Autonomic Function could be guided in its executing of its control-loop by the coordination mechanism. The guidance could range from preventing the executing of the control loop, to letting run on its own. In the middle of the range, coordination mechanism could restrain the actions, halt the control-loop at a given state of the execution (before enforcement).</t>
<t>This section can be expanded in conjunction with Section 7.5 of <xref target="I-D.behringer-anima-reference-model"/> details more the control loops.
</t>
</section>
<section anchor="Sec_Reqs_Interaction_Map" title="Interaction/Information Maps">
<t/>
<t>The Autonomic Control Plane(ACP) should be able to provide a view of the interactions between metrics in order to build the interaction maps.
This functionality is needed to identify that metrics are coupled. E.g. the capacity of a link and its load ratio are intimately coupled, and to identify interactions between autonomic function, having this knowledge may prove instrumental.
</t>
</section>
</section>
<section anchor="Sec_Spec" title="Specifications">
<t>The coordination function can be decomposed in the following sub-functions:
<list>
<t> interaction identification: in charge of identifying interactions</t>
<t> interaction grouping: coping with assigning the interactions to instances of cooperation mechanisms</t>
<t> interaction solving: coping with various algorithms</t>
</list>
TBC.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This draft was written using the xml2rfc project.</t>
<t>This draft content builds upon work achieved during UniverSelf FP7 EU project.</t>
<t>The authors thank Dimitri Papadimitriou for his valuable comments.</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> TBC
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split to informative and normative -->
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC7575;
&ID-AUTO-MOD;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 10:10:14 |