ANIMA L. Ciavaglia
Internet-Draft P. Peloso
Intended status: Informational Nokia
Expires: September 22, 2016 March 21, 2016

Knowledge Exchange in Autonomic Networks


This document describes a solution to manage the exchange and processing of information and knowledge between autonomic functions. The objective is to provide a unified interface to enable an interoperable management of information flows among autonomic functions by insuring the use common mechanisms. The protocol negotiate and automatically adapt to the communication and information capabilities, requirements and constraints of the participating entities.

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

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.

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

The ANIMA autonomic management framework addresses the growing management complexity of the highly decentralized and dynamic environment of service provider networks. The ANIMA autonomic management framework will help to produce the unification, governance, and “plug and play” for autonomic networking solutions within existing and future management ecosystems. Three main functional blocks namely the Governance, Coordination and Knowledge functionalities are essential to ensure a proper management and interworking of Autonomic Service Agents (ASAs). This document describes a solution to manage the exchange and processing of information and knowledge between autonomic functions. The objective is to provide a unified interface to enable an interoperable management of information flows among autonomic functions by insuring the use common mechanisms. The protocol negotiate and automatically adapt to the communication and information capabilities, requirements and constraints of the participating entities. The Knowledge functionality plays the role of information / knowledge collection, aggregation, storage/registry, knowledge production and distribution across all the ANIMA functional components (i.e. ANI and ASAs).

The Knowledge block is composed of the following functions:

The Knowledge Block offers basic information/knowledge manipulation functionalities to the ANIMA entities through the Knowledge Exchange Interface. A second interface, the Knowledge Management Interface, handles information flow management that includes configuration actions towards the optimal handling of the information/knowledge in the management system.

2. Knowledge Exchange Interface

An Autonomic Service Agent needs two different types of interfaces to deal with the exchange of knowledge.

The most important concept is the knowledge exchange flow, which is being set between two knowledge exchange interfaces. It is determined by the two endpoints of the flow and by the type of information that is being conveyed over the flow. Some additional parameters define the way the information are being exchanged (Push or Pull mode plus additional parameters to determine the frequency and conditions of the actual information exchange).

The features of the knowledge exchange flow are being negotiated by Knowledge Management Interfaces and possibly a third party in charge of optimizing the information flows over the whole system. The objective of this negotiation is to determine the characteristics of the exchange flow, which will then be enforced between two/multiple knowledge exchange interfaces.

2.1. Information Collection and Dissemination - ICD

The Information Collection and Dissemination (ICD) function is responsible for information collection, sharing, retrieval and dissemination. The ASAs can act as sources or sinks of information. The sources subscribe to the Information Catalog by exposing the type of information they can produce. On the one hand, each information source should subscribe information availability and the equivalent collection constraints (e.g., the supported granularity of collection). On the other hand, each information sink should subscribe information retrieval requirements with a similar process. The subscription process takes place during the ASA bootstrapping. The matching of constraints with requirements takes place during an equivalent negotiation process.

Information can be directly retrieved from or shared with a dedicated Knowledge Sharing system (a sort of ASA which roles is limited to be used as a store and sharing entity at the service of other ASAs). As an information collection process is triggered by a component requesting the information, a catalog of the available information has to be built and kept. This catalog indexes which ASA can produce which information. Then upon a bootstrapping ASA requesting a given information to work, the entity in charge of this catalog would then inform requesting ASA of the source ASA. This process could be supported by GRASP discovery mechanism.

The information collection process may be optimized by the Information Flow Establishment and Optimization - IFEO or another utility ASA in charge of optimizing the flows. This ASA acts as the third party during the negotiation phase between an information source and an information sink. If many information sink need the same information, the negotiation entity, is liable to enforce the use of an intermediate Knowledge Sharing system that would collect the information from the source before flooding to sinks according to their requirements.

The collected information may either be directed to the Information Processing and Knowledge Production function for a further processing (e.g., aggregation or knowledge production) and then optionally stored/indexed to the Information Storage and Indexing - ISI function. The storage option may be provided or demanded based on the nature of the information, ASA demands, optimization goals, etc. After this stage, the information or produced knowledge could be passed back to the ICD function for dissemination.

2.2. Information Storage and Indexing - ISI

The Information Storage and Indexing (ISI) function is a logical construct representing a distributed repository for registering ASAs, indexing (and optionally storing) information/knowledge. The ISI function stores information, such as ASA registration information and knowledge. The ISI functionality includes methods and functions for keeping track of information sources, including information registration and naming, constraints of information sources, information directory and indexing. An important storage aspect, which can assist the knowledge production handled by the Information Processing and Knowledge Production function, is the inherent support of historical capabilities. For example, an ASA could request information and/or knowledge that was stored in the past using an appropriate time stamp. It should be noted that knowledge production functionality is not part of the ISI function, but it supports the storing of knowledge derived due to some earlier calculations. The ISI optionally stores knowledge produced from the Information Processing and Knowledge Production function (for extended-scoped knowledge) or Knowledge Building ASAs (for locally-scoped knowledge). The different ANIMA entities either requesting or storing information to the Knowledge block, do not directly communicate with the ISI. The ICD function handles information collection or dissemination between the storage points and the ASAs. Furthermore, ISI supports: (i) publish/subscribe information dissemination capabilities, (ii) alternative storage structures (i.e., centralized versus distributed or hierarchical) and database technologies based on the context, and (iii) information and knowledge caching.

2.3. Information Processing and Knowledge Production - IPKP

The Information Processing and Knowledge Production function (IPKP) is responsible for operations related to information processing (i.e., aggregation) and knowledge production. The IPKP provides to ASAs and the ANIMA management functions the necessary tool kit to produce different information abstractions, including processed information and extended-scoped knowledge. The Knowledge Production (KP) operation handles and produces knowledge that may be extended-scoped. The latter type of knowledge is being produced out of aggregated information or locally-scoped knowledge. Locally-scoped knowledge can be built from the Knowledge Building ASAs out of data/information directly collected from the managed entities, i.e., its scope is limited to those entities. In all cases of knowledge production, reasoning and inference mechanisms are required. These mechanisms are based on different techniques depending on the exact problem addressed, the type of inputs used and the type of output that needs to be acquired. Such techniques come from scientific areas like statistics, clustering, reasoning, Fuzzy or machine learning (including supervised, unsupervised and reinforcement learning techniques). All the above information (e.g., problem addressed, type of inputs / outputs, inference/reasoning mechanisms etc) must be described in a proper ontology, ready to be looked up from the IPKP function when such a demand appears. An ASA or ANIMA management function that requires the IPKP functionalities requests to utilize either an Information Aggregation (IA) or a Knowledge Production (KP) operation. The ICD function handles the communication of the ANIMA management component with the internal IPKP functionalities and the IPKP controller is responsible to control the internal IPKP components. The two IPKP operations (i.e., information aggregation and knowledge production) require a number of basic steps:

2.4. Information Flow Establishment and Optimization - IFEO

The information flow negotiation and optimization aspects are crucial processes overseen from the Information Flow Establishment and Optimization (IFEO) function. The IFEO function, besides organizing internal optimization aspects (e.g., setting filtering or information accuracy objectives), also regulates the information flow based on the current state and the locations of the participating ANIMA components (e.g., the ASAs producing or requiring information). All relevant communication between the knowledge functions and the ANIMA components takes place through the Knowledge Management interface, unless it is otherwise stated.

For clarity purposes, we define the specifications of the IFEO function along with a representative example. We assume the following two ASAs: (a) the Virtual Infrastructure Management (VIM) ASA that provides management and control facilities for virtual infrastructures, including support of traffic monitoring; and (b) the Placement Optimization (PO) ASA that optimizes the data flow over a virtual network through adapting the positioning of communicating nodes (e.g., data servers) in response to the dynamic network conditions. In this example, the VIM ASA provides traffic monitoring information from a particular virtual network to the PO ASA. The PO ASA takes optimization decisions for the network based on this information, i.e., repositions communicating nodes in order to optimize network communication. The information flow negotiation and optimization processes include a number of basic phases, elaborated below:

These policies are considering the requirements/constraints of the participating entities and the global performance objective coming from the operator (e.g. via the ANIMA Intent Policy). The knowledge establishes the information flow using a set flow method of the Knowledge Management Interface, that takes as an input the decided Information Flow Exchange Policies, represented as a flow data structure.

The decided Information Exchange Policies are being applied to the network through the respective ASAs or communicated to the knowledge functions they are associated with. Since the appropriate context environment for the new information flow is prepared, a suitable path between the participating nodes is established next. This process considers the locations of the entities producing and requiring information and the required knowledge nodes (e.g., aggregation points, storage points etc) as well as the potential traffic characteristics. After that, the Knowledge Exchange interface can be accessed anytime from the information sink entity to receive the needed information/knowledge. In our reference scenario, the knowledge block matches the information flow constraints (e.g., supported monitoring rate) of the VIM ASA with the information flow requirements from the PO ASA. Then it selects the most appropriate Knowledge Exchange interfaces to communicate the information from the VIM to the PO ASA. A new information flow contract is established and communicated to the two ASAs and stored in the knowledge block. The information flow is established and the PO ASA can retrieve the required information from the VIM ASA via the appropriate Knowledge Exchange interface. The PO ASA can now begin taking network optimization decisions using that information.

Knowledge-level Optimization: Furthermore, knowledge supports a global optimization process that is triggered periodically or when a global performance objective change is requested from the GOV. This process takes optimization decisions using the aggregated information from the configuration of all established information flows and is related with a restructuring of the knowledge functions themselves. In other words, global-optimization algorithms may discard or update Knowledge Exchange Policies enforced for established information flows. It takes as an input the global picture of all the established information flow contacts and provides as an output different contracts aligned better to the new updated demands (e.g., a new received global objective). This process may initiate re-negotiations that include requesting again from the entities what their requirements and capabilities are. For example, the distributed knowledge nodes may be increased, decreased or repositioned in order to accommodate all established information flows and the global optimization goal better. The optimization process is triggered by the IFEO function and regulates the information flow based on the current state and the locations of the participating ANIMA components. In particular, the IFEO controls information collection handled from the ICD function, information aggregation, and aggregation node placement. Furthermore, it guides a filtering system for information collection and aggregation points that can significantly reduce the communication overhead.

3. Acknowledgments

This draft was written using the xml2rfc project.

The content of this draft builds upon work achieved during the EU FP7 UniverSelf project (

4. IANA Considerations

This memo includes no request to IANA.

5. Security Considerations


6. References

6.1. Normative References

[I-D.ciavaglia-anima-coordination] Ciavaglia, L. and P. Peloso, "Autonomic Functions Coordination", Internet-Draft draft-ciavaglia-anima-coordination-00, July 2015.
[I-D.peloso-anima-autonomic-function] Pierre, P. and L. Ciavaglia, "A Day in the Life of an Autonomic Function", Internet-Draft draft-peloso-anima-autonomic-function-01, March 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

6.2. Informative References

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

Authors' Addresses

Laurent Ciavaglia Nokia Villarceaux Nozay, 91460 FR EMail:
Pierre Peloso Nokia Villarceaux Nozay, 91460 FR EMail: