The AutoI Information Model (AIM) has been defined so that, in conjunction with other knowledge representations (such as ontologies), it provides a common language to represent the concepts, characteristics and behaviour required for the self-management of the virtualised networks. It serves to capture all necessary concepts concerned with service-oriented virtual resource orchestration and their relationships. An information model can be defined as a “representation of the characteristics and behaviour of a component or system independent of vendor, platform, language, and repository”. The use of a single information model will enable multiple platform- and language-specific data models to be built that each have a common understanding of shared data. The AutoI Information Model uses a set of abstractions and software patterns that enable services to express their needs to the management overlay, which translates those needs into a form that the network can understand.
The DEN-ng Information Model was chosen as the core for the AutoI Information Model extending it as required to support aspects such as support for virtualised network support. By complementing the model with a set of domain-specific ontologies that then can be used as a common language to advance interoperability and understanding across the disparate components of the AutoI architecture. In the same way, the common language enables network resources to be defined in such a way that the services can work with and use them. This common language becomes the base for a set of Domain Specific Languages (DSL) which addresses the specific tasks of the framework while still enabling interoperability.

This briefly summarises why AutoI defined an Information Model in the first year of the project. As this work is main activity of TSSG within the project, I will look at the IM in more depth in the future. More information about the Information Model can be found in D3.1 Information Model.

AutoI defines a Service Enablers Plane that consists of the design of programmatic enablers for dynamic service driven configuration of communication resources. The AutoI’s Service Enablers Plane (SP) consists of:
• Functions for the automatic (re) deployment or activation of new management services, protocols as well as resource-facing and consumer-facing service.
• Programmatic enablers to allow code to be executed or activated on the network entities and a safe and controlled deployment of new services on demand.

This approach has the following advantages:

• Service deployment is taking place automatically and allows a significant number of new services to be offered on demand.

• Offers new flexible ways to configure network entities that are not based on strict configuration sets.

• Special management functions and services can be easily enabled locally for testing purposes before they are automatically deployed network-wide.

• Services that are not used can be automatically disabled. These services can be enabled again on demand, in case it is needed to.

• Eases the deployment of network-wide protocol stacks and management services.

This briefly summarises the research carried out in the first year of the project. More information about the Knowledge Plane can be found in D5.1 Initial Service Infrastructure Design.
Next I will take a closer look at the Information Model defined in AutoI.

AutoI defines a Knowledge Plane that consists of models and ontologies in order to provide increased analysis and inference capabilities. The key functional entity of the Knowledge Plane is the Context Information Service Platform responsible for the collection, processing and dissemination of context information specifically for network context, service context and policies. The consumers of context information are context-aware services including both user-facing services and network services whereas a context source is an entity that provides context information; examples include context sensors or virtual network resources.

The AutoI approach distributes context in local and remote databases, based on their
context associations and characteristics (such as granularity of context change). For
example, context that needs to be collected/disseminated from/to a specific part of an
infrastructure network may be stored in a local database inside this specific network
cluster.

This briefly summarises the research carried out in the first year of the project. More information about the Knowledge 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 Service Enabler 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.

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.

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.

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.

The objective of AUTOI is to create a communication resource overlay with autonomic characteristics for the purposes of fast and guaranteed service delivery. Given this objective, AutoI will design and develop, based on a well-defined methodologies, an open software infrastructure and tools that enables the composition of better (fast and guaranteed) services in an efficient manner and the execution of these services in an adaptive (Autonomic form) way. To this end, we introduce Virtualisation of network resources and Policy-Based Management technique to describe and control the internal logic of the services, utilising Ontology-based information and data models to facilitate the Internet service deployment in terms of programmable networks facilities supporting the next generation of internet (NGN).
This resource overlay would support the following features:
1.Continuing service delivery in a dynamically changing resource environment and context (Resource context)
2.Resource support for changes in service requirements or introduction of new services (service context)
3.Seamless service mobility across multi-domain (technology, operator) (inter-/intra- domain) resource environments
4.Mechanism for unification and separation of the virtual resources at the management level
5.Exhibit self-* functions in terms of supporting autonomic communications.
6.Ensuring secure, fast and guaranteed services delivery
AUTOI is funded by the FP7 Programme.
The project has been running since January 2008, and will be completed January 2010.
For more information contact cfahy@tssg.org or visit the TSSG website at http://www.tssg.org.
Tel: +353 51 302966
Fax: + 353 51 341100