A Unifying Framework Design for the Management of Autonomic Network Functions

A Unifying Framework Design for the Management of Autonomic Network Functions

Laurent Ciavaglia (Nokia Bell Labs, France) and Pierre Peloso (Nokia Bell Labs, France)
Copyright: © 2019 |Pages: 45
DOI: 10.4018/978-1-5225-7146-9.ch003
OnDemand PDF Download:
No Current Special Offers


The increased use of software-driven and virtualization techniques enables more versatile network infrastructures. Realizing the full potential of such large and dynamic systems requires advanced automation and adaptation capabilities. In this chapter, the authors review recent development of so-called self-driving networks combining cognitive techniques and autonomic behaviors. In particular, the authors provide insights on a set of core mechanisms for the operation of self-driving networks: (1) a governance function to help operators deploy, pilot, control, and track run-time behaviors and performance of self-driving functions; (2) a coordination function to ensure stability and performance when several self-driving functions are running together; (3) a knowledge function to share relevant information to empowering their actions; and (4) common workflows, lifecycles, and APIs to enable deployment and interoperability of autonomic functions. The analysis connects with reference work in scientific literature and the most recent developments in standards (e.g., IETF/IRTF and ETSI).
Chapter Preview


Networks evolve constantly because of recurring factors such as the steady increase in the traffic volume, number of devices and their interactions (e.g., machine-to-machine type communications). In parallel other characteristics of networks endure: technology heterogeneity, and silos (technological and administrative) despite the continuous progress in techniques, computing, and storage capacity.

The above combination impacts negatively the complexity of distributed systems and their control and management; the scalability, speed, and human–dependency of their operations; and contributes to network capabilities under-utilization. As a result, networks operate in worst-case or over-provisioning scenarios, advanced features are not used because of lack of knowledge how to configure them properly or by fear to make the network unstable.

Furthermore, network operations are typically human-driven and thus time-consuming, expensive, and error-prone. Complexity and costs hinder network innovation and the deployment of new enriched service.

The ultimate goal of self-managing networks is to overcome these limits by providing intelligent, adaptive, modular, and automated carrier-grade control functions for seamless, end-to-end, and cross-technology interworking. This overarching goal can be derived into the following objectives:

  • Objective 1: Multi-facet unification, consisting in the federation of existing architectures and unification management principles across multiple technologies.

  • Objective 2: Network empowerment, consisting in the embedding of network intelligence to achieve true self-managing networks.

  • Objective 3: Industry readiness, consisting in the demonstration of deployability and developing migration strategies for large adoption by the industry.

  • Objective 4: Trust and confidence, consisting in demonstrating the reliability of every autonomic solution and developing standard testing and certification procedures.

Coping With Network Ecosystem Diversity

As illustrated in Figure 1, the network ecosystem is composed of multiple types of autonomic functions (AFs) using diverse technologies, and generating multiple roles, interactions, and relationships.

Figure 1.

Diversity of autonomic functions in the network ecosystem


In this context an autonomic function can be defined as: designed and deployed for a specific purpose, An AF uses a relevant method to solve an operational problem with a given performance objective, within a specific network (or service) technology domain and controls network resources. For example, an autonomic function performing load balancing in core IP/MPLS network is described in (Fotenios, Tsagkaris, Peloso, Ciavaglia, & Demestichas, 2014).

There can be as many autonomic functions as they are problems to solve and variations of autonomic functions as designers to implement them. Therefore, to cope with the natural diversity of the networks’ ecosystem and potentially large amount of autonomic function versions, certain levels of commonalities should be defined. Two primary levels of such commonalities emerge (Figure 2): a common model for autonomic functions and common framework for the management of those autonomic functions.

Both levels aim at providing: (1) uniform representation of the respective entities and; (2) uniform operation and control means.

Figure 2.

Autonomic functions (AFs) and their management framework (MF)


The AF Application Programming Interface (API) consists in a unified abstraction of the AF external behavior, exposed via a set of interfaces to connect and interact with functions of the management framework, other AFs, and AF-controlled resources (e.g., network elements). As such, the AF API is an important element of AF standardization.

Key Terms in this Chapter

AF Mandate Format: Is a subset of MF specifications describing which information must and may be provided by the MF system to the AF.

AF Instance Description Grammar: A subset of MF specifications describing which information must and may be provided by the AF instance when starting (and when its settings are changed) so as to register to the MF system the 1) capabilities of this AF instance regarding information/knowledge sharing, 2) requirements of this AF instance regarding knowledge inputs, and 3) conflicts of this AF instance with already running AF instances of any AF class.

AF Mandate: Is issued by the MF system to an AF instance. This AF Mandate is a set of instructions telling which devices must be handled by this AF instance and which settings this AF instance must work with.

AF Instance Description: Describes a given instance of a given AF Class. This description is issued by the AF instance towards MF system, it is used for the registration of the AF and it tells which information is monitored and which actions are taken.

Autonomic Function (AF): A functional grouping of objective(s), context and method(s) where “method” is a general procedure for solving a problem. An AF is (a priori) implemented as a piece of software that can be deployed in a network to enhance or simplify its control and management (e.g., take over some operations). An intrinsic capability of an AF is to be deployable and interoperable in a MF context (in a MF-compliant network).

Governance Function: A core MF component that aims to provide a human operator with a mechanism for controlling the network from a high-level business point of view, that is, without the need for having a deep technical knowledge of the network.

Management Framework (MF): A framework that will help produce the unification, governance, and “plug & play” of autonomic networking solutions within existing and future management ecosystems. The objective of the MF is to facilitate the seamless and trustworthy deployment of AFs.

AF API: A software component to provide the AF developer with the MF interfaces and the skeleton for AF behavior (i.e., registration, configuration, knowledge-exchange and management) needed for interacting with the MF core and compliance with the MF specification.

AF (Class) Instance: Allows performing a given autonomic function onto a given subset of a network. This is achieved by binding the code of an AF Class to a set of identified network resources/devices. This AF instance is identified by an instance ID and its unique interface with the MF. This AF instance at any given time handles a set of identified network resources (this set can evolve over time). Hence, there may be multiple instances of a given AF Class inside the same network e.g., one per area. An AF instance is created by the MF system it is being deployed in.

AF Manifest Grammar: A subset of MF specifications describing which information must and may be provided by the AF developers in order to describe their AF class.

AF Manifest: Describes a given AF Class. This description provides guidance to the network operator in order to install and configure an instance of this AF Class – the goal of an AF manifest is similar to a datasheet. This description is issued by the AF designer towards network operators.

Coordination Function: A core management framework (MF) component that aims to ensure the proper sequence in triggering of autonomic functions (AFs) and the conditions under which they will be invoked (i.e., produce their output), taking into account operator services and scenario requirements and at the same time the needs for conflict avoidance, stability control, and joint optimization through the corresponding functions.

AF Class: It is a piece of software that contains the logic achieving a specific autonomic function. Such class is deployed in a network running a MF system and requires being instantiated on a set of concrete network elements to effectively perform its autonomic function.

Knowledge Function: An infrastructure that uses and/or manipulates information and knowledge, including information/knowledge flow optimization within the network.

AF Specifications: They constrain the behavior of AFs and define the generic part of their interfaces with MF elements, as the specifications of these MF elements.

Complete Chapter List

Search this Book: