Internet DRAFT - draft-ciavaglia-anima-coordination
draft-ciavaglia-anima-coordination
ANIMA L. Ciavaglia
Internet-Draft P. Peloso
Intended status: Standards Track Alcatel-Lucent
Expires: September 22, 2016 March 21, 2016
Autonomic Functions Coordination
draft-ciavaglia-anima-coordination-01.txt
Abstract
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.
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.
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 September 22, 2016.
Ciavaglia & Peloso Expires September 22, 2016 [Page 1]
Internet-Draft Autonomic Functions Coordination March 2016
Copyright Notice
Copyright (c) 2016 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Guiding principles . . . . . . . . . . . . . . . . . . . . . 4
4. Initial sketch of a Coordination Function . . . . . . . . . . 6
4.1. Preliminary assumptions . . . . . . . . . . . . . . . . . 6
4.2. Algorithms for coordination . . . . . . . . . . . . . . . 7
4.3. Behavior of the coordination function . . . . . . . . . . 7
4.3.1. Times of the identification of interactions between
AF . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.2. Times of the coordination of AF . . . . . . . . . . . 9
4.4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 9
5. External Requirements . . . . . . . . . . . . . . . . . . . . 10
5.1. Autonomic Function Descriptor (AFD) . . . . . . . . . . . 10
5.2. control/command interface of AF . . . . . . . . . . . . . 10
5.3. Interaction/Information Maps . . . . . . . . . . . . . . 11
6. Specifications . . . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The document Autonomic Networking: Definitions and Design Goals
[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.
Ciavaglia & Peloso Expires September 22, 2016 [Page 2]
Internet-Draft Autonomic Functions Coordination March 2016
An Autonomic Function is characterized by its implementing a closed
control-loop, which we can summarize as successively:
1. Gathers metrics monitored by network equipments (that could be
Autonomic Nodes, but not limited to)
2. Determines/computes new actions out of these inputs plus possibly
some of the additional elements: e.g. contextual inputs, provided
intents and gathered experience,
3. Set the computed parameters values (from the previous actions)
inside the appropriate network equipments,
4. These new parameters values influence the network behavior, such
that the metrics gathered by the autonomic function will evolve,
(Section 7.5 of [I-D.behringer-anima-reference-model] details more
the control loops).
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.
The document A Reference Model for Autonomic Networking
[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 [I-D.behringer-anima-reference-model] (Coordination
between Autonomic Functions) provides a brief introduction to this
functionality.
This document tackles this topic by successively:
1. Explaining why such a functionality is needed,
2. Detailing which objectives such a functionality should reach,
3. Sketching a simple behavior of this function,
4. Providing requirements on autonomic functions (a tentative list
in this document version),
Ciavaglia & Peloso Expires September 22, 2016 [Page 3]
Internet-Draft Autonomic Functions Coordination March 2016
5. Providing some specifications items (in this preliminary version,
while future versions would provide specifications),
2. Problem Statement
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.
Several interaction types exist among autonomic functions such as
cooperation, dependency, or conflict (and possibly others [TBD]).
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.
Dependency happens when an autonomic function cannot work without
another one being present or accessible in the autonomic network.
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).
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.
3. Guiding principles
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.
As guiding principles, the ANIMA coordination function should:
o Maximize the autonomic network utility, i.e. mitigate the
(observed or inferred) detrimental effects of conflicting
autonomic functions (Efficiency property).
Ciavaglia & Peloso Expires September 22, 2016 [Page 4]
Internet-Draft Autonomic Functions Coordination March 2016
o Balance the autonomic network goal(s) and autonomic functions
individual goal(s) (Congruence and Coherence properties).
o 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).
o Deviate the least possible autonomic functions from their design
objective(s) and individual goal(s) (Liberality property).
o 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).
o Not impose any requirement on the internal specifications of
autonomic functions (Independence property).
o Support multiple coordination mechanism types (Plurality
property).
o Enable coordination mechanisms to be plugged in at deploy- and
run-time (Modularity property).
o 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).
o 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).
o 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).
o Be able to operate equally well in a distributed or centralized
manner (Distributivity property).
o Be able to cope with several thousands of simultaneous
interactions (Performance and scalability property).
Ciavaglia & Peloso Expires September 22, 2016 [Page 5]
Internet-Draft Autonomic Functions Coordination March 2016
4. Initial sketch of a Coordination Function
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.
4.1. Preliminary assumptions
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
High level view of an Autonomic Network which is depicted in Figure 1
of [I-D.behringer-anima-reference-model], which Figure is copied
below:
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: : 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 |
+--------+ : +--------+ : +--------+ : +--------+
Figure 1: High level view of an Autonomic Network
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.
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
Ciavaglia & Peloso Expires September 22, 2016 [Page 6]
Internet-Draft Autonomic Functions Coordination March 2016
which receive instructions from one of the ASA gathered in the
Autonomic Function.
Running - In this state, the autonomic function is deployed and is
executing its closed control loop, hence acting on network, by
modifying Nodes parameters.
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.
4.2. Algorithms for coordination
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:
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.
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).
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.
4.3. Behavior of the coordination function
This function is expected to steer the network towards a better
"operating" point, by avoiding/mitigating detrimental interactions
between Autonomic Functions.
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).
Ciavaglia & Peloso Expires September 22, 2016 [Page 7]
Internet-Draft Autonomic Functions Coordination March 2016
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.
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.
4.3.1. Times of the identification of interactions between AF
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:
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.
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.
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.
Ciavaglia & Peloso Expires September 22, 2016 [Page 8]
Internet-Draft Autonomic Functions Coordination March 2016
4.3.2. Times of the coordination of AF
TBC
4.4. Conclusions
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:
Requirements onto the AF -
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.
a life-cycle: to match the process of the coordination (shortly
stated, interaction identification and then conflict solving).
a common command interface of the autonomic functions: for the
coordination to control the pace at which an autonomic function
executes its control loop.
Requirements onto the ACP -
a common representation of information and knowledge: a
function used to build the interactions maps.
Requirements onto the Coordination Function -
interaction identification: a function in charge of identifying
interactions
interaction grouping: a function coping with grouping the
previously identified interactions, in bundles that can be
managed independently (for scalability concerns)
supporting various coordination mechanisms: to have the freedom
of picking the most appropriate one.
interaction solving: a function capable of handling an
independent bundle of interactions by controling the implied
autonomic functions according to the picked algorithms.
Ciavaglia & Peloso Expires September 22, 2016 [Page 9]
Internet-Draft Autonomic Functions Coordination March 2016
5. External Requirements
At this stage of the document, this section is merely providing a
structure of its content.
In order to achieve the aforementioned goals (detailed in section
Section 3) a Coordination Functional Block should bring the following
features:
a common description of autonomic functions attributes and its
life-cycle.
a common command interface between the coordination "agent" and
the autonomic functions.
a common representation of information and knowledge (cf.
interaction maps).
Guidelines, recommendations or BCPs can also be provided for the
aspects pertaining to the coordination strategies and mechanisms.
The coordination function requires a certain set of elements to work
properly such as the autonomic function descriptor and the
interaction map(s).
5.1. Autonomic Function Descriptor (AFD)
The Autonomic Function Descriptor (AFD) should contain the following
elements:
actions, metrics, parameters, controlled resources.
5.2. control/command interface of AF
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).
This section can be expanded in conjunction with Section 7.5 of
[I-D.behringer-anima-reference-model] details more the control loops.
Ciavaglia & Peloso Expires September 22, 2016 [Page 10]
Internet-Draft Autonomic Functions Coordination March 2016
5.3. Interaction/Information Maps
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.
6. Specifications
The coordination function can be decomposed in the following sub-
functions:
interaction identification: in charge of identifying interactions
interaction grouping: coping with assigning the interactions to
instances of cooperation mechanisms
interaction solving: coping with various algorithms
TBC.
7. Acknowledgements
This draft was written using the xml2rfc project.
This draft content builds upon work achieved during UniverSelf FP7 EU
project.
The authors thank Dimitri Papadimitriou for his valuable comments.
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
TBC
10. References
10.1. Normative References
[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>.
Ciavaglia & Peloso Expires September 22, 2016 [Page 11]
Internet-Draft Autonomic Functions Coordination March 2016
10.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-04 (work in progress), October 2015.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015,
<http://www.rfc-editor.org/info/rfc7575>.
Authors' Addresses
Laurent Ciavaglia
Alcatel-Lucent
Villarceaux
Nozay 91460
FR
Email: laurent.ciavaglia@alcatel-lucent.com
Peloso Pierre
Alcatel-Lucent
Villarceaux
Nozay 91460
FR
Email: pierre.peloso@alcatel-lucent.com
Ciavaglia & Peloso Expires September 22, 2016 [Page 12]
