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.