INTERNET-DRAFT Mingui Zhang
Intended Status: Proposed Standard Jie Dong
Expires: April 15, 2014 Huawei
Beichuan Zhang
The University of Arizona
Bithika Khargharia
Extreme Networks
October 12, 2013
Use Cases for Power-Aware Networks
draft-zhang-panet-use-cases-03.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 April 15, 2014 [Page 1]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 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
2.3. Coordinating L2 and L3 Sleeping Links . . . . . . . . . . . 8
3. Power Aware in Data Center Networks . . . . . . . . . . . . . . 9
3.1. Use Case 3: Server Consolidation . . . . . . . . . . . . . 9
3.2. Use Case 4: Elastic Infrastructure . . . . . . . . . . . . 11
3.3. Use Case 5: Job Scheduling Among Multiple Sites . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Mingui Zhang Expires April 15, 2014 [Page 2]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 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 April 15, 2014 [Page 3]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 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 April 15, 2014 [Page 4]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 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 April 15, 2014 [Page 5]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 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 [RFC6976].
The mechanism defined in [RFC6976] 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 April 15, 2014 [Page 6]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 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 April 15, 2014 [Page 7]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 2013
achieve more energy saving.
2.3. Coordinating L2 and L3 Sleeping Links
Networks devices are usually redundantly provided. However, they may
spend a lot of time operating at its full rate while caring few or no
traffic, especially at the edge of the network. Manufactures have put
a lot of effort to produce energy efficient network devices. However,
fully power proportional network devices are hard, even impossible,
to be implemented. Take switches of the day for example, when they
are left idle, there is only a low teens of power reduction compared
to the peak power [Sx700]. This means a considerable amount of energy
is being wasted when no traffic is being delivered. Modern processors
support a number of states, which enables various network components
to sleep [C-Sleep]. When a network component becomes idle, it's
reasonable for them to enter the sleep mode to save energy.
Energy Efficient Ethernet (EEE) provides a mechanism and standard for
Ethernet links to operate in an energy-efficient way [802.3az]. The
PHY connecting an Ethernet link can enter Low Power Idle mode (i.e.,
sleep mode) to reduce the energy consumption when no data packet is
being sent on the link. Normally, PHY need be refreshed periodically
during the LPI. When the signaling protocol indicates the PHY to wake
up, it SHOULD resume in a pre-defined delay (Time to Wake, Tw). This
pre-defined delay is the time the transmitter transmitting a maximum
length Ethernet frame. For example, Tw for 1000BASE-T is 16.5uS,
which is the same time that it takes to transmit a 2000-byte Ethernet
frame [C.I.EEE]. The transmitter can buffer packets during the time
that the receiver transiting from the LPI mode to the active mode.
This Wake on Arrival mechanism guarantees that EEE does not interfere
with upper layer application protocols (e.g., ISIS). Beyond PHY,
other network equipments (such as NPUs, line-cards, or whole
switches/routers) may also enter sleep mode, which usually means a
much longer time to wake up but a much higher energy saving. The EEE
standard also supports PHYs to enter a deep sleep mode through
negotiating a larger value of Tw using the link-layer discovery
protocol (LLDP) [802.1ab].
Energy Efficient Ethernet (EEE) protocol makes use of gaps in the
data stream to put transceivers attached to an Ethernet link into
sleep state to save energy consumption [802.3az]. Without expectation
of the arrival of packets, the L2 sleeping is actually an
opportunistic sleeping. This kind of opportunistic sleeping is
performed locally without coordination of nodes across the network
wide. At L3, we can plan the sleeping which help to achieve energy
savings beyond physical layer transceiver (PHY) of Ethernet links.
With traffic aggregation realized through network-wide green routing
Mingui Zhang Expires April 15, 2014 [Page 8]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 2013
and traffic engineering, idle links of an L3 network can be scheduled
to enter sleep mode for a while to save energy consumption. If a link
is scheduled to sleep at L3, no packets will be sent on this link for
a longer time (minutes or hours) [GreenTE]. It's feasible for this
link to negotiate a longer value of Tw at L2 and enter the deep sleep
mode to save more energy. Compared to a normal L2 link, the scheduled
sleeping link has a longer LPI and less wake up actions, which also
leads to more energy savings.
On the other hand, if a link is scheduled to be active at L3, the
opportunity for this link to enter LPI mode may become slim. It may
be better to disable the sleep mode of this link at L2 to avoid the
frequent transitioning between LPI and active mode, therefore avoids
extra energy consumption and instability of the network.
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
Mingui Zhang Expires April 15, 2014 [Page 9]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 2013
________ ________
| | | |
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.
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.
Mingui Zhang Expires April 15, 2014 [Page 10]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 2013
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.
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.
Mingui Zhang Expires April 15, 2014 [Page 11]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 2013
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
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
Mingui Zhang Expires April 15, 2014 [Page 12]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 2013
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.
9. References
9.1. Normative References
[PANET-problem] B. Zhang, J. Shi, J. Dong and M. Zhang, "draft-zhang-
panet-problem-statement-02.txt", work in progress.
Mingui Zhang Expires April 15, 2014 [Page 13]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 2013
[PANET-requirements] J. Dong, M. Zhang and B. Zhang, "draft-dong-
panet-requirement-02.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-01.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,
<http://datatracker.ietf.org/wg/eman/charter/>.
[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-11.txt,
work in progress.
[Orchestration] Dalela, A. and M. Hammer, "Service Orchestration
Protocol (SOP) Requirements", draft-dalela-orchestration-
00.txt, work in progress.
[oFIB] M. Shand, S. Bryant, S. Previdi, C. Filsfils, P. Francois, O.
Bonaventure, "Framework for Loop-Free Convergence Using the
Ordered Forwarding Information Base (oFIB) Approach", RFC
6976, July 2013.
9.2. Informative References
[GreenTE] Zhang, M. and et al. , "GreenTE: Power-Aware Traffic
Engineering", ICNP 2010.
[Sx700] "Huawei Enterprise Sx700 Series Switch Product", 2013.
http://enterprise.huawei.com/ilink/enenterprise/
download/HW_200802.
[C-Sleep] "Power and Thermal Management in the Intel Core Duo
Processor". Intel Technology May, 15, 2006.
[C.I.EEE] "IEEE 802.3az Energy Efficient Ethernet: Build Greener
Networks", 2011.
http://www.cisco.com/en/US/prod/collateral/switches/
ps5718/ps4324/white_paper_c11-676336.pdf.
Mingui Zhang Expires April 15, 2014 [Page 14]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 2013
[802.1ab] IEEE P802.1ab, "Station and Media Access Control
Connectivity Discovery", 2005.
http://www.ieee802.org/1/pages/802.1ab.html
[802.3az] IEEE P802.3az, "Energy Efficient Ethernet Task Force",
2010. http://grouper.ieee.org/groups/802/3/az.
[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.
[nvo3usecase] L. Yong, M. Toy, and et at., "Use Cases for DC Network
Virtualization Overlays", draft-ietf-nvo3-use-case-02.txt,
work in progress.
[VMmove] Y. Rekhter, W. Henderickx and et al, "Network-related VM
Mobility Issues", draft-ietf-nvo3-vm-mobility-issues-
01.txt, work in progress.
[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 April 15, 2014 [Page 15]
INTERNET-DRAFT Use Cases for Power-Aware Networks October 12, 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 April 15, 2014 [Page 16]