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
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
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
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
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).