Management Plane

Previously I introduced the concepts of the Virtualisation Plane in AutoI which describes the virtual network resources. Above this plane, you will find the Management Plane, a self-managed management resource overlay based on the system’s business goals. The management system, or Autonomic Management System (AMS) incorporates both a Management Plane and a Knowledge Plane. An AMS is responsible for managing all the Virtual Resources within its own domain.

An AMS collects monitoring information from the virtual devices and services that it is managing making necessary decisions for the resources and services that it governs, either by itself or in collaboration with other AMSs. Therefore an AMS can act as independent entity responsible for managing its own resources and management services, capable of adapting automatically to changing network conditions and send status messages to other AMSs that it federates with. This is achieved by an autonomic control loop that support the basic operations of information collection, information analysis, decision-making and decision enforcement. The AMS is a policy-based AMS where control decisions are based on policies where control decisions are made based on desired versus current states of managed resources. As an AMS is expected to federate with peer AMSs in addition to being orchestrated by the Orchestration Plane therefore reasoning and learning processes must take into consideration historical data, experiences and inferred
information so that policies can be adapted according to this learning when necessary.

This briefly summarises the research carried out in the first year of the project. More information about the Management Plane can be found in D4.1 Management and Knowledge Planes Functions and Initial Design: Initial Policy-based System.
Next I will take a closer look at the Knowledge Plane.

Presentation at the UCL Autonomic Workshop

Located in UCL, the Autonomics Workshop was a forum for industry and academia to discuss ongoing research and future challenges associated to realising Autonomic inspired network management solutions.
As part of WP3, a presentation was given by Steven Davy describing the experience gained during the project concerning the usage of the Information Model results of task 3.1. The presentation given is located here.
The objective of the presentation was to instill in the audience an appreciation of using a rich information model, in our case DEN-ng, to provide input to autonomic decision making algorithms. This tutorial style presentation raised some interesting discussion among the audience and provided some very useful feedback to the task partners.
Feedback:
Q: Can a complete Ontology driven approach be taken as opposed to a model driven approach?
A: The answer is no, because both UML based models and Ontology graphs are required to develop a rounded solution that takes into account software processes (UML) and reasoning/learning processes (Ontology).
Q: Is UML too restrictive a modelling tool to support evolution of the Information model once the system is built?
A: Evolution of the information model is a difficult challenge and is currently still a challenge. Supporting model changes depend on the application being supported, for example in database systems, a database schema migration process must be developed to map the old data into the new schema. In Ruby on Rails application this process in builtin. Interestingly, OWL based ontologies have support for versioning; however, this is not very elegant and mappings are still required.
Q: How do you support the learning of new relationships that may invalidate some relationships defined in the model?
A: Again this is a future challenge, and the solution lies in augmenting the information model with ontologies that can be readily modified and extended at runtime should new relationships need to be supported.

Virtualisation Plane

The AutoI architecture can be described logically in terms of a layered architecture where each layer, or plane, describes what functionality the plane is responsible for.
Here I will focus on the Virtualisation Plane that provides a layer of abstraction from the underlying hardware. In the context of AutoI, the hardware in question are routers and the virtualisation of routers where several virtual routers can co-exist sharing the same physical hardware. This would support the concept of virtual networks and virtual topologies which can co-exist and yet differ from the actual physical network topology. Additionally, Virtual Routers can be configured independently such as CPU, memory, network interfaces, storage capacity for example. The Virtual Routers can easily be started, stopped, suspended, resumed and cloned. In the case of hardware failure, the Virtual Routers can even be deployed on alternative hardware.
In AutoI, XEN (http://www.xen.org/) has been chosen for the implementation of virtualised networks. The Virtualisation Plane can be managed by two different interfaces: vCPI and vSPI. These interfaces allow functions within other planes of the AutoI architecture, especially the Management Plane, to manage the virtual resources autonomically. The virtual Component Programming Interface (vCPI) provides a way for the AutoI Management Plane to configure the components and start new Virtual Routers forming Virtual Networks including the management of Virtual Links. The virtualisation System Programmability Interface (vSPI) performs a higher-level management of virtual resources than vCPI allowing the Management and Orchestration Planes to control groups of virtual resources, including components and whole topologies.
This briefly summarises the research carried out in the first year of the project. More information about the Virtualisation Plane can be found in D6.1 Initial AutoI Framework
Next I will take a closer look at the Management Plane.

Quick update

AutoI has been in progress for well over a year now and its well overdue an update on its progress. So in the coming weeks and months I plan to provide a summary of specific areas of research carried out throughout the first year of the project. The first topic will cover the work performed in the area of Virtualisation of Resources. Look out for this soon.