A Northbound Interface for Power Management in Next Generation Network Devices

Transcription

1 A Northbound Interface for Power Management in Next Generation Network Devices Raffaele Bolla 1, Roberto Bruschi 1, Franco Davoli 1, Pasquale Donadio 2, Leonardo Fialho 3, Martin Collier 3, Alfio Lombardo 4, Diego Reforgiato 4, Vincenzo Riccobene 4, Tivadar Szemethy CNIT, Genoa, Italy 2- Alcatel-Lucent, Italy 3- Dublin City University, Dublin, Ireland 4- Lightcomm, Catania, Italy 5- Netvisor, Budapest, Hungary Abstract Recently, a number of approaches based on dynamic power management techniques have been proposed to reduce the energy consumption of telecommunication networks and devices. They are able to optimize the tradeoff between network performance and energy requirements. It is possible to execute and extend these techniques to the whole network, by using local control policies together with energy-aware routing and traffic engineering. However, the lack of a standardized representation of the energy-aware capabilities of heterogeneous networking equipment makes their deployment confusing and impractical. To this aim, we have proposed a novel framework, the Green Abstraction Layer (), whose purpose is to define a multi-layered abstraction interface for the hardware and physical resources, where energy management actions are directly performed. Therefore, the syntax can be exposed to the platform-independent logical representation commonly used in network control protocols. Given the internal architectural complexity and heterogeneity of many network devices, the approach is based on a hierarchical decomposition, where each level provides an abstract and aggregated representation of internal components. 1 Introduction Network energy efficiency has become an aspect of paramount importance for Telco operators and Internet Service Providers (ISPs) across all network segments (wired and wireless), owing to the increasing power consumption exhibited over the years [1] and to the increasing cost of energy. Estimates of public organizations [2] provide alarming figures in the Business-As-Usual case; for the European Telecommunication companies only, the estimated energy requirement in 2020 is 35.8 TWh, which represents an increase of over 67% in a decade. The increasing user traffic and router capacities are two of the main reasons for such high power consumption. They are not compensated for by a corresponding increase in silicon energy efficiency. Moreover, the vast majority of currently deployed network links and devices are designed to operate (and, consequently, to consume energy) constantly at their maximum capacity, even though their average utilization lies far below the maximum [1,3]. These observations have motivated the choice of adapting The work described in this paper was performed with the support of the ECONET project (low Energy Consumption NETworks), funded by the EU in FP7 call 5 (grant agreement no ). Homepage:

2 network energy requirements to the actual traffic profiles [4,5]. This can be realized by providing Power Management Primitives (PMPs) into the hardware of networking devices, where energy absorption physically happens. PMPs allow aggressively reducing the energy consumption of networking devices (or some parts of them) by putting them into standby states when not in use, or by decreasing their maximum performance in the presence of low traffic volumes. The reader may notice that, on the one hand, it is obvious that the maximal power saving is obtained when the equipment is turned off; however, under such a condition the performance is actually zero, as well. On the other hand, it is also clear that the best performance is obtained when the device operates with no power constraint. Therefore, power-managed devices need control loops able to dynamically tune hardware capabilities to provide the required Quality of Service (QoS) level to the incoming traffic with the minimal power consumption. It is also worth noting that PMPs are features locally available in network nodes, and their efficiency may heavily depend on the specific implementation and low-level details of the hardware platforms of devices. Actually, providing each network device with its own independent control loop or Local Control Policy () would appear straightforward. According to the specific features of the local device, the control loop may dynamically orchestrate the configuration of internal components (e.g., line-cards, network processors, etc.) to meet the desired QoS with the minimum consumption. However, should each device independently perform energy optimizations, then the overall network consumption might result much higher than in the case of cooperation among nodes, the satisfaction of end-to-end network QoS requirements might not be guaranteed. Along this direction, several approaches [6-8] have been recently proposed in order to extend current routing, traffic engineering and network management policies beyond classical network QoS metrics, and to explicitly consider also the energy consumption of the whole network. For instance, moving traffic flows towards alternative network paths may either reduce the load of some nodes (or part of them), by putting them into standby mode [6-7], or trigger Power Scaling (PS) primitives in a more effective way. Typical examples of these kinds of processes that can be extended to deal with green metrics are management protocols (e.g., TMF in metropolitan networks, or OpenFlow in datacenters), or traffic engineering and routing algorithms/protocols (e.g., OSPF-TE/RSVP-TE). We will refer to these approaches as Network-wide Control Policies (NCP). Even if potentially much more effective than s, NCPs suffer from some drawbacks. First, the NCPs can exhibit much higher feedback/convergence delays. Secondly, a further problem in interfacing NCPs and the power management of physical entities lies in the fact that network control protocols generally work on top of logical resources, often losing the details on how they can be mapped on devices internal hardware, where power consumption and management physically happen. Thus, NCPs may drive power configurations of network devices only by means of such logical resources, but they would need to know the mapping between logical resources and internal device components, in order to understand the effects of their action. Finally, NCPs often represent a network device simply as a node in a graph, whose edges are the (virtual/physical) network links. Such simplistic representation does not allow maintaining the knowledge of some hardware peculiarities that may be crucial for reducing consumption. For example, let us consider a device with some line-cards, each one with multiple ports: putting all the links of the

3 same line-card to sleep is much more profitable than other configurations, since an entire line-card can enter sleep mode. All these points suggest the possibility of jointly adopting s and NCPs in order to optimize the device energy consumption in a hierarchical way. It is easy to conclude that there is still a significant gap between hardware power management and NCPs, as well as some open issues on which control loops should be adopted, and on how to effectively manage the relationships among multiple (local and/or network-wide) control loops. Moreover, an abstract representation is needed, independently of the details of the specific manufacturers implementations. With all this in mind, the main contribution of this paper consists in the specification and initial experimental characterization of a layer that provides a way to expose green networking capabilities of devices toward the network control plane. Such a layer consists of a novel standard interface, the Green Abstraction Layer () [9], conceived by the ECONET consortium ( The specific goal of the is not to directly provide additional energy gains to energy-aware devices, but rather to offer a simple and well-defined substrate that presents the following peculiar aspects: (i) (ii) (iii) a common and simple way for representing power management capabilities available in heterogeneous data plane hardware, a framework for mapping the capabilities of power-managed physical entities at the data-plane with the logical resources used by control processes, a reference control chain allowing a consistent hierarchical organization of multiple local and network-wide control loops. As such, the target of this paper is to define a complete control interface that will allow the management of the trade-off between power and network performance at the system level. In other words, the is meant to make control loops able to acquire information on which power management settings are available at the data-plane and on their potential effect in terms of consumption and network performance metrics, in order to choose the most suitable configuration. Similarly to other standards in the same field, like the IETF Energy MANagement (EMAN these types of information are formalized through the concept of energy-aware states. However, the power state description and characterization that existing standards provide is clearly insufficient for any remote control decisions (e.g., lack of network-specific performance tradeoff indications in power state descriptions). The remainder of this paper is organized as follows: Section 2 describes the general architecture and structure of the. Section 3 introduces the representation of power management primitives. Section 4 defines energy-aware states and their relevant parameters. Section 5 ends the paper with conclusions and future research directions where we are heading. 2 The architecture In order to map the energy consumption of physical components with the performance and the functionalities at the network logical level, the is provided with a hierarchical layered view of devices internal organization, which represents the components at the various levels as a tree of entities (Figure 1.a). Since this kind of representation is already largely adopted in the forwarding and configuration information databases of network devices, the does not explicitly define various aspects (e.g., the entity identifiers, the maximum depth of the tree, etc.), in order to favor its integration with these existing device-internal databases.

4 The root entity populates layer 1 and corresponds to the entire node. Layer 0 includes multiple entities representing the device logical resources, which are functional objects/instances (e.g., IP links, tunnel/vlan virtual interfaces, etc.) commonly used for representing local protocol configurations, and exposing them toward control and management processes. Since the nature, the number, and the relationship among logical resources may vary a lot depending on the network protocols implemented, layer 0 was designed to handle these resources as a simple flat list. The role of layer 0 is then simply representing logical resources to the Control Plane in the syntax, as a means to allow the mediation between Control Plane processes and hardware specific characteristics. The mapping of logical resources representing per-resource management logic, the managed objects and their s is specific to the each given device architecture. For instance, as shown in Figure 1.b, the logical resources in a router correspond to the IP interfaces configured on both physical and virtual (e.g., VLAN) ports. The presence of layers 0 and 1 is mandatory; layers 2,, n are optional, and are meant to represent the internal hardware organization of the device at various levels of aggregation. For instance, as shown in Fig. 1.b, the hardware architecture of the router prototype to be described in Section 5 can be decomposed in 2 further layers namely, the and Hardware Components. A similar breakdown is also adopted in reference [9] (which also contains the definition of the methods). In more details, the may even represent as entities only those hardware components/subsystems able to trade off their power consumption and their performance, available functionalities, and responsiveness levels. In such a case, every node of the tree corresponds to a. As power management primitives reside at the lowest levels of the hierarchy, every leaf of the tree connects with a Convergence Layer, which includes all the needed means (e.g., drivers/agents, etc.) to interface the with PMPs of hardware objects. Leaf nodes may reside at different layers of the hierarchy for two main reasons: some hardware elements may need to be accessible from higher hierarchical levels (e.g., fans in a chassis); some manufacturers might prefer not to expose the internal organization and the subcomponents of a composite part of the device. Starting from the n-th layer, the is hierarchically applied in order to give the possibility to control policies at the i-th layer to orchestrate the configurations of the underlying entities in order to aggregate their operating behaviors, and to expose them as a single energy-aware entity at the upper layer. It is worth noting that the role of the interface does not depend on the hierarchical level where it is applied, but it simply allows acquiring information from or setting a configuration to an entity with PMPs.

5 Layer 3: HW Components Layer 2: Layer 1: Device Layer 0: Logical Resources Network Control and Management Processes (e.g., Signalling Protocols) Layer 0: Logical Resources Layer 1: Device Root Layer 2: 1 st level HW Res. Layer 3: 2 nd level HW Res a Entity 1.1 DROP data-plane FE1 CLI/Routing Protocols eth1 eth2 eth40 Entity 1.2 FE2 Entity 1 Entity 1.3 FE3 Layer n: (n-1) th level HW Res m Convergence Layer 1...m (a) Figure 1: Abstract view of the hierarchical architecture (a), and its instantiation when applied to the prototype introduced in section 5 (b). This process terminates at layer 1, where the highest handles the high-level configuration of the device, and needs to expose a simplified view of it, by mapping and decomposing the impact of possible power settings to the device logical resources residing at layer 0, which are meant to provide per-resource management logic through the syntax. For instance, with reference to Figure 1.b, logical resources of the router prototype correspond to the available IP (virtual/physical) ports. The role of the layer-1 in this case is to map/decompose the power management configurations of layer-2 elements on a per IP-port basis at level 0, with criteria that obviously depend on the specific device architecture. The possibility of referring to logical resources to acquire and set information regarding energy configurations is a key aspect of the entire architecture, since it allows: - Accessing and/or modifying the device energy-aware configuration on the part of NCPs or even a simple command line interface, by working on the same logical/functional objects, which are listed in the forwarding and configuration databases; - Hiding how a functional/logical resource of the device is implemented in the hardware, and which subsystems it involves or shares with other resources. It is also worth noting that the was specifically designed to be agnostic according to the nature of NCP processes and related signalling protocols, since they may vary significantly with respect to the specific network technologies and deployment scenarios. For instance, the does not specify/impose which kind of information needs to be handled by the management plane or by the network control. Rather, the main goal of the is to provide a common substrate for such control and management processes and signalling protocols, which may make the mapping of hardware PMPs to the logical network level easier and uniform across heterogeneous network technologies and architectures. For this (b)

6 reason, the presence of the does not provide any additional energy saving to network devices, but can foster a complete and explicit support to power management operations in network infrastructures. 3 Power Management Primitives PMPs allow dynamically trading off energy consumption and processing performance of hardware components, and they can be classified on the basis of their effect on the working behavior of the managed component. According to [5] and to Figure 2.a, a basic classification is the following: Standby primitives, which consist of PMPs that allow devices or parts of them entering very low energy states, where most of their functionalities are frozen. PS primitives, which allow dynamically reducing the working rate of the component. This is usually accomplished by adopting two basic techniques: Adaptive Rate (AR) and Low Power Idle (LPI). The former deals with the dynamic modulation of the processing capacity of the component. The latter forces links or processing engines to enter low power states when not sending/processing packets, and to quickly switch to a higher power state when sending one or more packets. LPI and AR can be adopted jointly, in order to adapt components performance to current workload requirements, and have different impacts on packet forwarding performance and QoS. As shown in Figure 2.b, AR obviously causes the stretching of packet service times, while the adoption of LPI only introduces an additional delay in packet service, due to the wake-up times. Although PMPs are all built upon the basic hardware techniques cited above, they can be exposed with different operational behaviours. At the generic i-th level of the hierarchy, an entity may provide the management of some aspects/settings to the above /NCP (see Figure 2.b); some other aspects/settings may be operated by the entity itself in an autonomic way (see Figure 2.c). In this case, the entity might already include s internally in lower-level components or directly in the hardware. Starting from these considerations, the operational behaviours of such capabilities can be summarized as follows: Autonomic: the same entity manages (part of) its energy configuration in an autonomic way; Controllable: the modification of the energy configuration (or part of it) requires an explicit action from the upper-layer control process. In this sense, we can classify entities as Autonomic Entities and Controllable Entities (AE and CE). As shown in Figure 2.c, an AE drives its operational behaviour without any explicit actions/configurations from the upper layer control process, which only knows the aggregated characterization of the operational behaviour in terms of energy profile against the traffic offered load. When one or more PMP settings are configurable by the upper layer control process through the, the entity is a CE. Figure 2.b shows the case of a CE, where all PMP settings are explicitly operated by the upper layer, which decides when and how to change the configuration of AR and LPI. Between the two limit operating behaviours in Figures 2.b and 2.c, a number of variants can be identified and traced back to the considerations above. In more detail, an entity may be designed to autonomically throttle between two AR settings (ARi and ARj), which must be configured by controlplane processes. In such a case, each available power profile (e.g., a pair of i and j indexes for the limit AR settings) represents an independent autonomic profile that may be set (and then controlled) by the. Under such assumption the entity has to be considered as a CE.

7 Consumption Consumption Consumption Consumption Consumption Consumption Standby Power Scaling Low Power Idle (LPI) Adaptive Rate (AR) AR 2 AR 1 AR z AR z-1 S k S 1 LPI v LPI 1 (a) Wake-up time Wake-up time Max Rate time (b) AR 1 AR z LPI v AR z AR 2 LPI 1 AR AR 1 zarz-1 AR 2 Offered Load time AR 1 AR z LPI v AR z AR 2 LPI 1 AR AR 1 (c) zarz-1 AR 2 Figure 2: Hardware Power Management Primitives and their trade-off between energy consumption and performance (a), their operating behavior in controlled mode, where the transition among LPI and AR states is explicitly driven by the (b), and in autonomic mode, where no direct interaction with the is needed (c). 4 Energy-Aware States An EAS is an operational power profile mode implemented by the entity that can be configured by upper-layer control processes. According to section 3, under autonomic operations AEs can expose only one EAS describing their aggregate performance/consumption profile, while CEs have two or more available EASs, which may still contain autonomic operations. From a general point of view, all the aspects configurable from the upper-layer control process are translated into EASs, and autonomic behaviours are represented as descriptive parameters of EASs.

8 To assure the correct exchange of information between the entity and control plane processes, the EAS must be represented as a complex data type, which contains information about power consumption, performance, available functionalities, and responsiveness of the entity when working in such a configuration. This information is obviously necessary to s and NCPs in order to decide which EAS provides the desired trade-off between power consumption and network performance. Owing to the adaptive and autonomic nature of some PMP realizations of EASs described in section 3, the overall energy saving and the network performance may heavily depend on incoming traffic volumes and statistical features (traffic burstiness levels, etc.). For this reason, it would be quite hard to precisely know a-priori the overall entity performance when working in an EAS. Therefore, such characterization indexes must be expressed in an objective (and easily measurable) form that may suit different incoming traffic patterns, and may help binding the maximum energy consumption and/or the worst possible level of network performance. The most intuitive solution is to make such indexes describing the high-level effects introduced by power management techniques (i.e., speed reduction, wake-up times, etc.), which do not depend on the system dynamics. We modelled the EAS as a couple of energy-aware Primitive sub-states (PsSs) related to the configuration of Standby and Power Scaling mechanisms: where EAS jk={p j, S k} with 0 j J and 0 k K Sk represents the k-th PsS related to the standby techniques (S-PsS); S0 is the active state, in Sk, with k>0, the entity is sleeping, in SK the device is completely off. Pj represents the j-th PsS related to the Power Scaling techniques; P0 is the PsS for the highest device network performance (it also consumes the highest power), PJ is the PsS with the lowest performance level for the device while still being active (it consumes the least power for the device in active state). See Figure 4 for the definition of PsSs composing EASs. Given the exclusive use of power scaling and standby capabilities, the j-th Power Scaling Primitive sub-states (P-PsS) can be adopted only when the entity is active (S0). When the entity is in standby modes (Sk with k>0), Pj only represents the power scaling configuration that will be used after wakeup. Figure 3: Organization of the Power Scaling and Standby PsSs composing EASs. PsSs are represented by means of a set of parameters that address the following aspects (see Table I): the entity power consumption when working in such a PsS, its performance level and which other EAS

9 (and how) the entity can move to. While the number of attributes needed for S-PsSs is relatively low, and their meaning is quite intuitive, a more complex representation of P-PsSs is required in order to take into account both AR and LPI primitives and their operational behavior. In detail, P-PsSs attributes have been divided into five main categories, as follows. General attributes are meant to provide a snapshot on the considered P-PsS: some performance and maximum power consumption bounds are defined to summarize the aggregated behavior of the entity. Then, more precise data on non-autonomic AR and LPI primitives are given in the AR and LPI attribute categories. The fourth category, related to autonomic attributes, aims at describing the performance of the autonomic energy-aware behavior of the entity. This is done by describing the performance and the consumption of the entity for a number of offered load levels. Finally, state transition attributes give indications on which other P-PsSs the entity can move to from the current one, and the related possible performance decays. S-PsS attributes. Parameter Description Table I: EAS attributes. k Standby Power Saving Maximum Wake-Up time Maximum Sleeping time Wakeup Triggers Sleeping Timer P-PsS attributes. Parameter Identifier number of the current S-PsS. The power gain for being at S k with respect to the maximum power draw of the entity. The maximum time that is needed to wake-up from S k to S 0. The maximum time that is needed to go into S-PsS S k from active S 0. Set of flags that represents which triggers can be used to wake-up the entity. Bit 0: ; Bit 1: wake-onpacket; Bit 2: WoL. Other flags will be defined. Time of inactivity before the entity enters into S k in an autonomic way. Description General attr. AR Specific attr. LPI Specific attr. Autonomic attr. State Trans. attr. j Minimum Gain Maximum Throughput Maximum Throughput LPI Power Gain Power Packet LPI Wakeup Time LPI Sleeping Time LPI Power Autonomic Steps Autonomic Profile Curves Bit Transition PS PS Autonomic PS Service Interruption P-PsS Times Transition P-PsS Transition Service Interruption Times Identifier number of the current Power Scaling PsS. The minimum power gain in P j. with respect to the maximum power draw of the entity. This value is usually reached when the entity works at the maximum throughput in P j. The maximum throughput provided by the entity when working in P j. This value is expressed in packets per second. The maximum throughput provided by the entity when working in P j. This value is expressed in bits per second. The average power gain when the entity is idle in P j with respect to the maximum power draw of the entity. The maximum time that is needed to wake-up from the LPI mode upon packet arrival. The maximum time that is needed to enter into the LPI mode. The average power needed in P j when moving from idle to active modes and vice versa. Granularity used for describing the power and performance profile in autonomic power scaling primitives. This parameter represents the behavior of autonomic PS solutions. It is an array of depth STEPS (i.e., Throttling steps). Each array cell is composed by three values, indicating the offered load, the maximum consumption and the maximum packet service time at that load. Maximum service interruption time that may be incurred when the autonomic power scaling mechanisms switches the entity capacity. Array containing the maximum time intervals needed to move from P j to other P-PsS. The infinity value is used for indicating that a direct transition is not possible. Array containing the maximum service interruption times that may incur while moving from P j to other Power Scaling PsS. The infinity value is used for indicating that a direct transition is not possible.

10 5 A -enabled prototype In the context of the ECONET project, seven prototypes of heterogeneous -enabled devices (spanning from home gateways to high-end switches and routers) have been developed, and their capabilities successfully demonstrated ( In this section, we report some of the results and architectural details that have been experimented with the DROP router, an open-source software router with a modular architecture based on Linux and commercial off-the-shelf hardware. This selection was mainly driven from the openness of the prototype that may help the reader to deepen later on further aspects on the design architecture of this reference implementation. In any case, it is worth remarking here that the functionalities of the are not conceived to provide further gains in energy or performance (a task of control policies), but rather to simplify the interworking between Control and Data planes, to isolate device-specific characteristics, and to ease the task of designers and system developers. All these goals have been achieved in the ECONET prototypes, of which the DROP router described below is a paradigmatic example. As shown in Figure 4, the data-plane of the DROP router is composed by: Three forwarding elements devoted to perform IP layer operations on incoming packets. These elements were realized with Linux software running on commodity servers and Broadcom XLP 832 evaluation boards. An interconnection element - an Openflow switch balancing the incoming traffic among the forwarding elements. An additional Linux server is used as control element of the DROP router, and runs all the control and management signalling protocols. In our experimental setup only forwarding elements provide PMPs in terms of both AR and LPI at network adapters and at processors, where packets are elaborated. elements based on commodity servers also provide standby capabilities. As shown in Figure 1.b, the was realized with a 4 layer-hierarchy: besides the mandatory layers 0 and 1, layer 2 was devoted to manage the forwarding elements, and layer 3 represents the processors and the adapters in the elements. Load Balancing IP routing Demultiplexing Interconnection (RX side) Interconnection (TX side) Figure 4: The DROP architecture.

11 Power Consumption [W] Power Consumption [W] Power Consumption [W] The s at layers 1 and 2 drive the power management of the node, by resulting for each configured IP link in two available EASs with autonomic capabilities. s at layer 2 orchestrate the AR and LPI configurations of both network adapters and processor cores with the strategy developed in [10]. Then, as shown in Figure 5, the at the device level modulates the number of forwarding elements in CLI eth1 eth2 eth40 Entity Autonomic 1 5 Autonomic 2 0 BAU Traffic Load [%] ) Control the number of FEs in standby & move traffic flows among FEs Autonomic Autonomic ) Decompose the energy Standby profiles from hardware 30 BAU entities to logical ones Traffic Load [%] 150 Autonomic 1 Autonomic 2 BAU Traffic Load [%] Entity 1.1 Entity 1.2 Entity 1.3 Interconnection (RX side) Interconnection (TX side) Figure 5: Overview on the role of s in the DROP prototype and of the management of EASs at different hierarchical layers of the. The s at the level of the forwarding elements orchestrate the AR and LPI capabilities to obtain two autonomic P-PsSs and one S-PsS (available only on commoditybased platforms). On its turn, depending on the incoming traffic volume, the at the device level autonomously manages the EASs exposed by lower layer entities and the traffic share sent to each forwarding element, in order to obtain two autonomic P-PsSs, which are then decomposed into a couple of available EASs for each logical link configured on the device. In the autonomic profile graphs, the Business as Usual (BAU) energy consumption has been also reported.

12 standby depending on both the traffic offered load and the EAS configured by the system administrator for each logical resource. 6 Conclusions We have proposed a novel framework, the Green Abstraction Layer, to represent energy-aware capabilities of networking devices. Owing to the heterogeneity of networking equipment by different vendors and to the necessity of deploying energy management policies into existing networks, the definition of a multi-layered abstraction is a key issue to ease the task of manufacturers and network managers, and to close the gap between hardware power management and logical aspects of network control. In this work, we have outlined the definition of such multi-layered abstraction interface from the hardware and physical resources, where energy management actions are directly exerted, to the platformindependent logical representation commonly used in network control protocols. We have described the hierarchical architecture of the, and we have provided the definition of energy-aware states of devices and of their component parts. Finally, we have outlined one of the experimental realizations of the already implemented in the framework of the ECONET project. We are currently further developing the on several network hardware platforms. Moreover, the framework is currently being discussed for standardization within the ETSI Environmental Engineering Technical Committee under Work Item DES/EE References [1] R. Bolla, R. Bruschi, A. Carrega, F. Davoli, D. Suino, C. Vassilakis, A. Zafeiropoulos, Cutting the Energy Bills of Internet Service Providers and Telecoms through Power Management: An Impact Analysis, Computer Networks, vol. 56, no. 10, pp , July [2] Global e-sustainibility Initiative (GeSI), SMART 2020: Enabling the Low Carbon Economy in the Information Age, Smart2020Report.pdf. [3] S. Nedevschi, L. Popa, G. Iannaccone, D. Wetherall, S. Ratnasamy, Reducing Network Energy Consumption via Sleeping and Rate-Adaptation, Proc. 5th USENIX Symp. on Networked Systems Design and Implementation, San Francisco, CA, April 2008, pp [4] R. Bolla, R. Bruschi, K. Christensen., F. Cucchietti, F. Davoli, S. Singh, The Potential Impact of Green Technologies in Next Generation Wireline Networks - Is There Room for Energy Saving Optimization?, IEEE Communications Magazine, vol. 49, no. 8, pp , Aug [5] R. Bolla, R. Bruschi, F. Davoli, F. Cucchietti, Energy Efficiency in the Future Internet: A Survey of Existing Approaches and Trends in Energy-Aware Fixed Network Infrastructures, IEEE Communications Surveys & Tutorials, vol. 13, no. 2, pp , 2nd Qr [6] L. Chiaraviglio, M. Mellia, F. Neri, Minimizing ISP Network Energy Cost: Formulation and Solutions, IEEE/ACM Transactions on Networking, vol. 20, no. 2, pp , April [7] A. Cianfrani, V. Eramo, M. Listanti, M. Polverini, An OSPF Enhancement for Energy Saving in IP Networks, Proc. IEEE INFOCOM 2011 Workshop on Green Communications and Networking, Shanghai China, April 2011, pp [8] J. C. Cardona Restrepo, C. G. Gruber, C. Mas Machuca, Energy Profile Aware Routing, Proc. GreenComm ICC Workshop, Dresden, Germany, June 2009.

13 [9] R. Bolla, R. Bruschi, F. Davoli, L. Di Gregorio, P. Donadio, L. Fialho, M. Collier, A. Lombardo, D. Reforgiato, T. Szemethy, "The Green Abstraction Layer: A Standard Power Management Interface for Next- Generation Network Device," IEEE Internet Computing, vol. 17, no. 2, pp March-April [10] R. Bolla, R. Bruschi, A. Carrega, F. Davoli, Green Networking with Packet Processing Engines: Modeling and Optimization", IEEE/ACM Transactions on Networking, 2013 (to appear); doi: /TNET Biographies Raffaele Bolla is a full professor of telecommunication networks at the University of Genoa, Italy, and principal investigator for the ECONET (low Energy COnsumption NETworks) project. raffaele.bolla@unige.it. Roberto Bruschi is a researcher with the National Inter-University Consortium for Telecommunications (CNIT), Genoa, Italy, the coordination assistant of the ECONET project, and the principal investigator of the GreenNet project. roberto.bruschi@cnit.it. Franco Davoli is a full professor of telecommunication networks at the University of Genoa, Italy, and is a member of the CNIT Scientific Board. franco.davoli@cnit.it. Pasquale Donadio is a system engineer at Alcatel-Lucent Italia, where he manages several research programs funded by the European Community. pasquale.donadio@alcatel-lucent.com Leonardo Fialho is a postdoctoral researcher in network energy efficiency at Dublin City University, Ireland. leonardofialho@gmail.com Martin Collier is a senior lecturer at Dublin City University, Ireland, where he runs the Switching and Systems Laboratory. martin.collier@dcu.ie. Alfio Lombardo is a full professor of telematics at the University of Catania, Italy, where he s responsible for the OpenLab. alfio.lombardo@dieei.unict.it. Diego Reforgiato Recupero is a postdoctoral researcher in network energy efficiency at the University of Catania, Italy. diegoref@dieei.unict.it. Vincenzo Riccobene is a Ph.D. student in network energy efficiency at the University of Catania, Italy. vincenzo.riccobene@dieei.unict.it. Tivadar Szemethy is chief architect for Netvisor in Hungary, which focuses on network and systems operation and management. tivadar.szemethy@netvisor.hu.

14 Network Control and Management Processes (e.g., Signalling Protocols) Layer 0: Logical Resources Layer 1: Device Root Layer 2: 1 st level HW Res. Layer 3: 2 nd level HW Res a Layer n: (n-1) th level HW Res m Convergence Layer 1...m

15 Layer 3: HW Components Layer 2: Layer 1: Device Layer 0: Logical Resources CLI/Routing Protocols eth1 eth2 eth40 DROP data-plane Entity 1 Entity 1.1 FE1 Entity 1.2 FE2 Entity 1.3 FE3

16 Consumption Consumption Consumption Standby Power Scaling Low Power Idle (LPI) AR z AR z-1 Adaptive Rate (AR) AR 2 AR 1 S k S 1 LPI v LPI 1 Wake-up time Wake-up time Max Rate

17 Consumption time AR 1 AR z LPI v AR z AR 2 LPI 1 AR AR 1 zarz-1 AR 2

18 Consumption Consumption Offered Load time AR 1 AR z LPI v AR z AR 2 LPI 1 AR AR 1 zarz-1 AR 2

19

20 Load Balancing IP routing Demultiplexing Interconnection (RX side) Interconnection (TX side)

21 Power Consumption [W] Power Consumption [W] Power Consumption [W] CLI eth1 eth2 eth40 Entity Autonomic 1 5 Autonomic 2 0 BAU Traffic Load [%] ) Control the number of FEs in standby & move traffic flows among FEs Autonomic Autonomic ) Decompose the energy Standby profiles from hardware 30 BAU entities to logical ones Traffic Load [%] 150 Autonomic 1 Autonomic 2 BAU Traffic Load [%] Entity 1.1 Entity 1.2 Entity 1.3 Interconnection (RX side) Interconnection (TX side)

22 S-PsS attributes. Parameter k Standby Power Saving Maximum Wake-Up time Maximum Sleeping time Wakeup Triggers Sleeping Timer P-PsS attributes. Parameter Description Identifier number of the current S-PsS. The power gain for being at S k with respect to the maximum power draw of the entity. The maximum time that is needed to wake-up from S k to S 0. The maximum time that is needed to go into S-PsS S k from active S 0. Set of flags that represents which triggers can be used to wake-up the entity. Bit 0: ; Bit 1: wake-onpacket; Bit 2: WoL. Other flags will be defined. Time of inactivity before the entity enters into S k in an autonomic way. Description General attr. AR Specific attr. LPI Specific attr. Autonomic attr. State Trans. attr. j Minimum Gain Maximum Throughput Maximum Throughput LPI Power Gain Power Packet LPI Wakeup Time LPI Sleeping Time LPI Power Autonomic Steps Autonomic Profile Curves Bit Transition PS PS Autonomic PS Service Interruption P-PsS Times Transition P-PsS Transition Service Interruption Times Identifier number of the current Power Scaling PsS. The minimum power gain in P j. with respect to the maximum power draw of the entity. This value is usually reached when the entity works at the maximum throughput in P j. The maximum throughput provided by the entity when working in P j. This value is expressed in packets per second. The maximum throughput provided by the entity when working in P j. This value is expressed in bits per second. The average power gain when the entity is idle in P j with respect to the maximum power draw of the entity. The maximum time that is needed to wake-up from the LPI mode upon packet arrival. The maximum time that is needed to enter into the LPI mode. The average power needed in P j when moving from idle to active modes and vice versa. Granularity used for describing the power and performance profile in autonomic power scaling primitives. This parameter represents the behavior of autonomic PS solutions. It is an array of depth STEPS (i.e., Throttling steps). Each array cell is composed by three values, indicating the offered load, the maximum consumption and the maximum packet service time at that load. Maximum service interruption time that may be incurred when the autonomic power scaling mechanisms switches the entity capacity. Array containing the maximum time intervals needed to move from P j to other P-PsS. The infinity value is used for indicating that a direct transition is not possible. Array containing the maximum service interruption times that may incur while moving from P j to other Power Scaling PsS. The infinity value is used for indicating that a direct transition is not possible.