INTERNET-DRAFT Mingui Zhang Intended Status: Proposed Standard Jie Dong Expires: August 12, 2013 Huawei Beichuan Zhang The University of Arizona Bithika Khargharia Extreme Networks February 8, 2013 Use Cases for Power-Aware Networks draft-zhang-panet-use-cases-02.txt Abstract Power Aware NETwork (PANET) has attracted strong interest from both carriers and vendors. Several use cases are investigated in this document to exhibit the potential usage of PANET in both backbone and data center networks. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Mingui Zhang Expires August 12, 2013 [Page 1] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Power Awareness in Backbone Networks . . . . . . . . . . . . . 3 2.1. Use Case 1: Sleeping Links . . . . . . . . . . . . . . . . 4 2.1.1 Aware of Sleeping Links at the Management Plane . . . . 5 2.1.2 Gathering Information for Decision Making . . . . . . . 6 2.2. Use Case 2: Composite Links . . . . . . . . . . . . . . . . 7 3. Power Aware in Data Center Networks . . . . . . . . . . . . . . 8 3.1. Use Case 3: Server Consolidation . . . . . . . . . . . . . 8 3.2. Use Case 4: Elastic Infrastructure . . . . . . . . . . . . 9 3.3. Use Case 5: Job Scheduling Among Multiple Sites . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Mingui Zhang Expires August 12, 2013 [Page 2] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 1. Introduction Networks are usually provisioned for peak hours and potential network failures. Network devices are powered on all the time without consideration on energy efficient. In practice, however, the traffic load of a network is low most of the time and redundant network equipments are used for failure recovery occasionally. In the past years, vendors had paid a great effort on improving the network energy efficiency at the device level: when the traffic load is low, a network equipment should accordingly operate with less power draw. However, network equipments have never become fully power proportional. Even few or no traffic is carried, a powered-on network device draws a considerable amount of power, which means energy is being wasted. There is an explicit gap that idle network devices are shut down or put into sleeping state to save more energy. In order to fill this gap, the network control plane and management system should become power aware (i.e., Power Aware NETwork, PANET) to coordinate network devices therefore the sleeping or powered-off network devices do not bring service disruption to the network. The design space and problem areas of PANET is outlined in [PANET- problem]. The requirements for PANET is given in [PANET- requirements]. This documents investigated use cases on PANET which include both backbone networks and data center networks. As for the energy efficiency of backbone networks, only intra-domain use cases are considered. Trying to be energy efficient in the inter-domain scale seems technically feasible. But currently, energy efficient solutions can easily end up with lack of business motivation. This document leaves them for future study. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Terminology PANET: Power Aware NETwork 2. Power Awareness in Backbone Networks The IETF Energy Management (eman) Working Group works on the management of power-aware network devices. Basically, the power states of power-aware network devices are reported and recorded in MIB. However, there is a gap on how to make use of this kind of data to achieve energy efficient networks. With energy aware control plane Mingui Zhang Expires August 12, 2013 [Page 3] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 [power-control], it becomes possible to make use of these measurements and power control ability to achieve the energy efficiency of a whole network. This section lists several use cases for backbone networks. Take a router system as an example, the start-up of it may take several minutes and the stabilization of it may takes much longer time. It is unrealistic to switch off and on a whole node in backbone networks frequently to achieve energy efficient, so this document only investigates the cases in which links (i.e., links' attached components) are shut-down or put into sleeping state for energy conservation. 2.1. Use Case 1: Sleeping Links The power draw on line-cards occupies a great portion in the total power consumption of a whole routing system. For high-end routers, this portion may be higher than 50%. Network devices and their processing capacity are provisioned for worst cases such as traffic burst and busy hours. Most of the time, the network is lightly loaded. Unfortunately, the power consumption of network devices is not proportional to the traffic load on them. An extreme case is that even there is no load on them, there is still a considerable base power consumption. Unlike personal PCs which can be shut down or enter power saving modes (such as sleeping), network devices are powered on and running even there is no load on them. This reality means that the network is wasting lots of power. The conception that "a link is put into sleep state" is frequently mentioned in various technical documents. In this document, this conception is formalized as follows. The coupled end-points (such as interfaces, NPU or whole line-cards) attached to a idle link enter the sleeping mode to save energy. Similarly, the wake up of a link also means the wake of of those coupled end-points. Mingui Zhang Expires August 12, 2013 [Page 4] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 ............... <.............. +----+ +----+. +----+ +----+. ^| R1 |-----| R2 |. | R1 |-----| R2 |. .+----+ +----+. +----+ +----+. . |........>| . | ^| . . |. .| . | .| . . |. .| . | .| . . |<........| . |<........| . .+----+ +----+. +----+ +----+. .| R4 |-----| R3 |v | R4 |-----| R3 |v .+----+ +----+ +----+ +----+ ............... (a) No sleeping opportunity; (b) link R1-R4 can sleep Figure 2.1: Aggregate traffic to create opportunities for link sleeping Traffic aggregation are used to create the opportunity for more links to become idle. This process can be automated through the control plane [power-control]. Traffic Engineering technique is able to achieve this kind of traffic aggregation [GreenTE]. Take Figure 2.1 as an example, suppose R1, R2, R3 and R4 is sending traffic to R3, R4, R1 and R2 and R4 respectively. In Figure 2.1 (a), paths R1-R2-R3, R2-R3-R4, R3-R4-R1 and R4-R1-R2 are being used. All links are active. In Figure (b), paths R1-R2-R3, R2-R3-R4, R3-R2-R1 and R4-R3-R2 are being used. Link R1-R4 is idle, therefore it can be put into sleeping state to save energy. Different from traditional Traffic Engineering techniques which aim to balance traffic load around the whole network to avoid hot spots, green Traffic Engineering try to create more idle links which can be put into sleeping state. However, this kind of traffic aggregation should be restricted. At least, green Traffic Engineering SHOULD NOT achieve energy conservation at the expense of apparently downgrade the network performance. It is recommended that the QoS metric should be take into consideration as constraints of green Traffic Engineering. The traffic aggregation which can violate these constraints should be avoid. With the traffic load fluctuating, the green Traffic Engineering should be periodically performed. When the network is lightly loaded, the GreenTE should be able to put more links to be idle. When the network is heavily loaded, GreenTE should remain more links in active state to absorb more traffic in order to avoid traffic jam. 2.1.1 Aware of Sleeping Links at the Management Plane Mingui Zhang Expires August 12, 2013 [Page 5] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 1 2 / \ / \ / \ / \ 2 4 1 3 | | | | 3 4 (a) Tree Affected (b) Tree Not Affected Figure 2.2: Multicast Forwarding Plane It's possible to wake up a link or put it into sleeping sate at the management plane by operators. However, the state change impacts the data plane of the network. Take Figure 2.1 as an example, if link R1- R4 is sleeping, it will cut off the path R3-R4-R1 and R4-R1-R2. Therefore, the paths in Figure 2.1 (b) should be used. Data plane for multicast traffic may also be affected. Take Figure 2.2 as an example, in order to avoid being affected by the sleeping link, the multicast tree in Figure 2.2 (b) should be used rather than that in Figure 2.2 (a). It requires a knob to achieve the adjustment of data plane via the control plane. Before a link is to be put in to sleep state, operators may increase its link metric to disperse the traffic load on it. This will cause the update of FIBs of routers [oFIB]. The mechanism of "loop-free convergence using oFIB" can be adopted. Sleeping links are different from failed links since they can be waken up to relieve the traffic jam when it becomes necessary. This difference creates the necessity for the network to remember these links in order to make decision to wake them up at a proper time. 2.1.2 Gathering Information for Decision Making The decision of the Traffic Engineering may be centrally made on a NOC (Network Operation Center) or distributedly carried out by each router. However, when decisions are distributedly made, the consistence of decisions MUST be guaranteed. It requires that the algorithm of the Traffic Engineering always generate the same result. Where ever the decision point locates, the traffic demand of the network is the necessary input for Traffic Engineering. This information should be measured and maintained. For example, network elements (routers and switches) can gather flow data and export it to the collectors using Netflow [RFC3954]. For another example, a cyclic number of bytes transmitted and received on each of those interfaces of a line-card in maintained in the Management Information Base (MIB) via Simple Network Management Protocol (SNMP). The Network Management System (NMS) may periodically poll these numbers to compute the Mingui Zhang Expires August 12, 2013 [Page 6] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 links' load. The traffic matrix of the network can be further estimated from those links' load [TMEstimated]. Compared to traditional Traffic Engineering, power aware Traffic Engineering additionally requires the information about the power consumption of network devices of the network. It is requires a MIB module for monitoring energy consumption and power states of energy- aware devices [eman]. The essentials of this use case: o Devices to be Power Aware: Routers, NOC, etc. o What actions to take: NMS (Network Management System) polls the traffic load and power consumption profile of each link; Routers execute the green TE algorithm; Routers send out signals to trigger the sleeping/wake-up transition of a NPU on a line card. 2.2. Use Case 2: Composite Links A composite link is a logical link composed of multiple physical [I- D.ietf-rtgwg-cl-requirement] links. The composite link attached end- points are responsible to map traffic onto the component links and maintain the state of the composite link. Power awareness can be applied to composite links as well. When the traffic volume on a composite link is low, some component links can be shut down to conserve energy consumption. When the traffic volume becomes high, the sleeping component links can be waken up to absorb the traffic load. Compared to use case 1, the advantage of executing energy saving for composite link is that the connectivity of the composite link does not suffer unless all the component links are sleeping. In this way, the control plane of the component link is not disrupted. When the end points of the composite link execute the energy conservation action, they can do it in a distributed way and decisions are made locally. The essentials of this use case: o Devices to be Power Aware: Composite links attached end-points. o What actions to take: NMS measures the traffic load and power profile of component links; Attached end-points adaptively put component links into sleeping state or wake them up according to the traffic load on the composite link. Use case 1 and use case 2 may be combined in a real network to Mingui Zhang Expires August 12, 2013 [Page 7] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 achieve more energy saving. 3. Power Aware in Data Center Networks Servers and network devices (ICT equipments) are intensively placed in Data Centers. In comparison with ISP backbone networks, the operating of Data Center Networks are more power hungry. The growing amount of energy consumed by a Data Center has led to high operating costs. The work load of a data center varies due to the effect of "follow-the-sun". There is a significant opportunity to conserve the energy consumption through right-sizing the ICT infrastructure when the work load is low. Although non-ICT equipments, such as lighting and air conditioners, in a Data Center consumes a notable large amount of energy as well, this section concentrate on talking about right-sizing the ICT infrastructure for energy conservation. Energy conservation of non- ICT equipments are out of the scope of this document. 3.1. Use Case 3: Server Consolidation ________ ________ | | | | v | | v +------+ +--|---+ +---|--+ +------+ | +--+ | | | | | | | | +--+ | | |VM| | | | | | | | | |VM| | | +--+ | | | | | | | | +--+ | | +--+ | | | | | | | | +--+ | | |VM| | | | | | | | | |VM| | | +--+ | | | | | | +--+ | | +--+ | | | | | | +--+ | | |VM| | | | | | | |VM| | | +--+ | | | | | | +--+ | +------+ +------+ +------+ +------+ server 1 server 2 server 3 server 4 Figure 3.1: VM Placement and Consolidation With Operating System virtualization, one physical server can provide tens of Virtual Machines (VM) at the same time. Network Virtualization technology makes the placement and migration easy for VMs [nvo3usecase]. With live migration, VM can change its host server (location) without disruption of services running on it [VMmove]. As shown in Figure 3.1, VMs migrate out from server 2, server 3 to server 1, server 4 respectively. When Server 2 and server 3 are idled, they can be put into sleep state to save energy consumption. Mingui Zhang Expires August 12, 2013 [Page 8] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 With virtualization technology, VMs of a Data Center or multiple Data Centers can be consolidated to fewer physical servers while idled servers can be put into power saving mode or turned off to achieve energy conservation. Virtualization technology allows the administration of a Data Center Network respond rapidly to the fluctuating capacity requirements. Through monitoring of the work load and power profile, the Data Center Network Management System (Orchestrator) can judge in which hours workload is high and in which hours workload is low. For example, nights are generally off-peak hours in which workload is at low level. Virtual machines can be moved to fewer servers therefore idle servers can powered off or put into sleep to save energy. Before peak hours (e.g., in the morning), sleeping or powered off servers should be waken up to accommodate more active virtual machines (VMs). The essentials of this use case: o Devices to be Power Aware: All servers in a data center. o What actions to take: NMS measures the work load and power profile of servers; The orchestrator of a Data Center Network adaptively triggers the actions of VM migration, the power-off and power-on of servers according to the workload. 3.2. Use Case 4: Elastic Infrastructure Traffic load of a data center is generated by the work load on servers and applied on the network infrastructure. The changing work load determines that the traffic load varies as time goes on. However, network devices are always powered on even though the traffic load fluctuates, which wastes energy inevitably when the traffic load is low. Ideally, the network infrastructure is elastic and can fit the traffic pattern with minimum subset to minimize the energy consumption of the network infrastructure. For now, Data Center Networks generally work at layer 2. So this use case should be realized through manipulating switching paths, in comparison with the power aware routing at layer 3. Openflow switches may be utilized to achieve this goal [ElasticTree]. The essentials of this use case: o Devices to be Power Aware: All network equipments in a data center. Mingui Zhang Expires August 12, 2013 [Page 9] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 o What actions to take: Network devices report their traffic load and power consumption profile to the NMS. The orchestrator (NMS) of a Data Center Network adaptively build the switching paths upon the network infrastructure. The idled links are put into power saving mode (e.g., sleeping), so that the network infrastructure becomes energy efficient. O / \ ............ \ . O . O . / \ . / \ . O O . O O . | | . | | . +--+ +--+.+--+ +--+ . | | | |.|vm| |vm| . +--+ +--+.+--+ +--+ . | | | |.|vm| |vm| . +--+ +--+.+--+ +--+ . | | | |.|vm| |vm| . +--+ +--+.+--+ +--+ . | | | |.|vm| |vm| . +--+ +--+.+--+ +--+ ............ Figure 3.2: Elastic Data Center ICT Infrastructure As shown in Figure 3.2, when servers are idled and put into sleeping state, their up connected switches may also become idle. Therefore, use case 3 and use case 4 can be combined to achieve more energy saving. 3.3. Use Case 5: Job Scheduling Among Multiple Sites +-------+ | DC | {{^^^^^^^^^^^)) |Site A |{ Internet ) +--- ---+ ) | { ) Orchestrator IP/MPLS <-)-+User Access | { ) +--- ---+ ) | DC |{ ) |Site B | {{vvvvvvvvvvv)) +-------+ Figure 3.3: Adaptive Job Scheduling Mingui Zhang Expires August 12, 2013 [Page 10] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 An cloud service provider may have multiple data centers which spread out in different geographic locations. Generally, the ICT resources in these data centers are well replicated and a job can be directed to any of them for execution. These data centers form a large distributed Internet scale systems and the price of power supply for them varies between two different locations. The operating cost of such a system highly depends on the load scheduling scheme. Being power aware, the system can map requests to locations where energy price is cheaper. This use case makes use of the difference of the prices of power draw in different locations. The orchestrator of data centers (the NMS) is responsible for monitoring the power profile and work load of the ICT devices located in different data centers, and adaptively schedule the jobs among these data centers. Orchestration protocols are necessary to support the job scheduling [Orchestration]. As shown in Figure 3.3, the orchestrator map the user request (job) to with an economic attachment to either Site A or Site B, while the user is unaware of the executing point of the job. In this way, the job scheduling becomes a trade-off between OPEX and performance. The orchestrator should guaranteed that there is no apparent service performance degradation. Complex SLA fulfillment may be designed to embody the response time, throughput, latency, etc. The essentials of this use case: o Devices to be Power Aware: All ICT-equipments in a data center. o What actions to take: ICT devices report their work load and power consumption profile to NMS. The orchestrator (NMS) of the Data Center Networks adaptively map the request onto sites in consideration of reducing the overall power bill of the system. 6. Security Considerations This document raises no new security issues. 7. Summary The document describes some basic potential use cases of Power Aware NETwork. 8. IANA Considerations No new registry is requested to be assigned by IANA. RFC Editor: please remove this section before publication. Mingui Zhang Expires August 12, 2013 [Page 11] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 9. References 9.1. Normative References [PANET-problem] B. Zhang, J. Shi, J. Dong and M. Zhang, "draft-zhang- panet-problem-statement-01.txt", work in progress. [PANET-requirements] J. Dong, M. Zhang and B. Zhang, "draft-dong- panet-requirement-00.txt", work in progress. [power-control] A. Retana, R. White, M. Paul, "A Framework and Requirements for Energy Aware Control Planes", draft- retana-rtgwg-eacp-00.txt, work in progress. [TMEstimate] Y. Zhang, M. Roughan, N. Duffield and A. Greenberg, "Fast Accurate Computation of Large-Scale IP Traffic Matrices from Link Loads", SIGMETRICS 2003. [RFC3954] Siemborski, R., Ed., and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, July 2007. [eman] IETF, "Energy Management Working Group Charter", 2012, . [I-D.ietf-rtgwg-cl-requirement] Villamizar, C., McDysan, D., Ning, S., Malis, A., and L. Yong, "Requirements for MPLS Over a Composite Link", draft-ietf-rtgwg-cl-requirement-07 (work in progress), June 2012. [Orchestration] Dalela, A. and M. Hammer, "Service Orchestration Protocol (SOP) Requirements", draft-dalela-orchestration- 00.txt (work in progress), January 2012. [oFIB] Pierre Francois, Olivier Bonaventure, Mike Shand, Stewart Bryant and Stefano Previdi. Loop-free convergence using oFIB. Internet Draft, draft-ietf-rtgwg-ordered-fib-01.txt, (work in progress), July 2007. 9.2. Informative References [GreenTE] Zhang, M. and et al. , "GreenTE: Power-Aware Traffic Engineering", ICNP 2010. [Rate-Adaptation] S. Nedevschi, L. Popa, G. Iannaccone, S. Ratnasamy, and D. Wetherall, "Reducing Network Energy Consumption via Sleeping and Rate-Adaptation," in Proceedings of USENIX NSDI, 2008. Mingui Zhang Expires August 12, 2013 [Page 12] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 [nvo3usecase] L. Yong, M. Toy, and et at., "Use Cases for DC Network Virtualization Overlays", draft-mity-nvo3-use-case-04.txt, (work in progress), October 2012. [VMmove] Y. Rekhter, W. Henderickx and et al, "Network-related VM Mobility Issues", draft-ietf-nvo3-vm-mobility-issues- 00.txt, (work in progress), December 2012. [ElasticTree] B. Heller, S. Seetharaman, P. Mahadevan, Y. Yiakoumis, P. Sharma, S. Banerjee, and N. McKeown, "ElasticTree: Saving Energy in Data Center Networks," in Proceedings of USENIX NSDI, 2010. Mingui Zhang Expires August 12, 2013 [Page 13] INTERNET-DRAFT Use Cases for Power-Aware Networks February 8, 2013 Author's Addresses Mingui Zhang Huawei Technologies Co.,Ltd Huawei Building, No.156 Beiqing Rd. Beijing 100095 P.R. China Email: zhangmingui@huawei.com Jie Dong Huawei Technologies Co.,Ltd Huawei Building, No.156 Beiqing Rd. Beijing 100095 P.R. China Email: jie.dong@huawei.com Beichuan Zhang The University of Arizona Email: bzhang@cs.arizona.edu Bithika Khargharia Extreme Networks bithika@gmail.com Mingui Zhang Expires August 12, 2013 [Page 14]