The Project

Duration: October 2010 – December 2013

Funding scheme: Collaborative Project

Total cost: € 9.96 m

EC Contribution: € 6.16 m

Contract number: INFSO-ICT-258454

The Partners
ECOnet social

Green Abstraction Layer


The third research axis will be devoted to the study and the development of an Abstraction Layer to expose and to control the novel energy-aware capabilities introduced.
The Green Abstraction Layer is specifically conceived to hide the implementation details of energy-saving approaches, as well as to provide standard interfaces and methodologies for interactions between heterogeneous green capabilities and HW technologies, on one hand, and energy-aware control and monitoring frameworks, on the other hand.

To this purpose, the ECONET project will involve all partners working at the device data-plane and control-plane to accurately define a synthetic set of energy- aware and performance-aware profiles (i.e., states) and parameters, able to logically represent the different approaches and requirements of such green capabilities. Here, the specific goal is to extend and re-engineer the ACPI standard for computing systems, and adapt it to network equipment architectures, functionalities and paradigms

Then, a special effort will be devoted to design and to develop the Green Abstraction Layer as a modular and easily extendable SW framework.
At this early stage, no precise architectures and design modalities for the Green Abstraction Layer can be proposed here, since this definition and development is a specific part of the project activities, and, above all, it needs to receive inputs from the development and design of both data-plane capabilities and control-plane frameworks. Although, with the aim of better explaining its base concepts and objectives, an example of possible reference architecture is introduced in the following.
Green Abstraction Layer
Fig 1: Example of a possible structure for the Green Abstraction Layer.


As shown in Fig. 1, the Green Abstraction Layer is envisaged to include a certain number of modules working at three different sub-layers, which can be summarized as follows:
  • The hardware abstraction sub-layer;
  • The functional abstraction sub-layer;
  • The control-plane interface sub-layer.


The control-plane interfaces sub-layer should be composed by a single SW module realizing the standard interfaces towards the control-plane applications. Through these standard interfaces, such applications will be able to bi-directionally exchange high-level information with any energy-aware hardware elements in a same device, independently from the specific implementation/technological details at lower levels.

For example, the standard interfaces will allow control applications knowing the energy-aware capabilities (in terms of power scaling, smart standby and consumption monitoring) available for each data-plane element, and how these can be configured.

Thus, for each capability supported by the element, control application will be able to request further parameters. For example, focusing on power scaling, control applications will be allowed to retrieve:
  • the number of possible energy states for each HW element,
  • for each energy state, a synthetic set of high-level descriptive parameters (e.g., the minimum and the maximum power consumptions, the maximum element forwarding capacity, the maximum wakeup time (or delay jitter), etc.).

Moreover, control applications will use the standard interfaces also for:
  • setting the desiderated energy-aware state,
  • enabling different optional features and/or working behaviours (e.g., the capability of automatically propagating wake-up signals to other elements).

Passing to the middle sub-layer, the functional abstraction will be the core element of the entire Green Abstraction.
In fact, this sub-layer is thought to be composed by multiple SW modules, each one devoted to model one typology of green data-plane capabilities. In this respect, we can envisage the presence of three modules at this layer, devoted to the management of power-scaling, standby and monitoring capabilities, respectively. In more detail, the main objectives of such modules consist of:
  • Hiding the implementation details and low-level features through a comprehensive modelling/abstraction of the targeted capability, which have to result in the same set of high-level parameters exposed by the control-plane interface sub-layer;
  • Providing a reference architecture to heterogeneous HW dependent drivers, by defining standard data structures, functions and handlers to make the development and the linking of such drivers easier and more homogeneous.
For example, let we focus again on the power scaling capability. Such module must:
  • Hide the specific solution that is used by the energy-aware HW element to trade energy for performance, e.g., to vary the clock frequency, to switch off one or more HW pipelines, to put part the HW in low power idle modes;
  • Model the impact of such low-level solutions on packet forwarding performance and power consumption by considering also eventual presence of traffic handling policies and queuing/shaping disciplines, able to effectively exploit active/idle HW transitions;
  • Extract from these models a unique set of high-level parameters (e.g., minimum and maximum power consumptions, maximum forwarding rate, wakeup delays, etc.), which can represent the different operational behaviour in a synthetic and comprehensive way.

Finally, the HW abstraction sub-layer will include all the driver for the supported energy-aware HW elements (network interfaces, processing engines, etc.). Such drivers will be obviously devoted to explicitly manage the low-level functionalities provided by the elements through the access to registers and tables dependent on the specific HW development. Moreover, a generic driver of a HW element will be linked with the data structures, functions and handles of only those functional modules representing capabilities available at the HW (i.e., if a HW element does not support monitoring capabilities, its driver will not be linked with the “monitoring” functional module).

back
Private area
  • GAL definitely approved as ETSI standard
  • Memberhip voting phase and publication of the GAL standardization
  • ETSI EE Technical Board (TB) approval for GAL standardization
  • ECOnet contributed with the official code of conduct on energy consumption of broadband equipment version 5.0