One document matched: draft-quittek-power-monitoring-requirements-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
<!ENTITY rfc4133 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4133.xml">
<!ENTITY rfc4268 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4268.xml">
<!ENTITY rfc3621 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3621.xml">
<!ENTITY rfc1628 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1628.xml">
<!ENTITY rfc3433 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3433.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY rfc5101 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5101.xml">
<!ENTITY rfc5102 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5102.xml">
<!ENTITY rfc5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY rfc5424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.xml">
<!ENTITY rfc5675 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5675.xml">
]>
<!--<?rfc strict="yes"?>-->
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<!--<?rfc footer="draft-quittek-power-monitoring-requirements-02"?>-->
<?rfc compact="yes"?>
<!--<?rfc subcompact="compact"?>-->
<?rfc symrefs="yes"?>
<rfc category="info" docName="draft-quittek-power-monitoring-requirements-02" ipr="trust200902">
<front>
<title>Requirements for Power Monitoring</title>
<author fullname="Jürgen Quittek" initials="J." role="editor"
surname="Quittek">
<organization>NEC Europe Ltd.</organization>
<address>
<postal>
<street>NEC Laboratories Europe</street>
<street>Network Research Division</street>
<street>Kurfuersten-Anlage 36</street>
<code>69115</code>
<city>Heidelberg</city>
<country>DE</country>
</postal>
<phone>+49 6221 4342-115</phone>
<email>quittek@neclab.eu</email>
</address>
</author>
<author fullname="Rolf Winter" initials="R." surname="Winter">
<organization>NEC Europe Ltd.</organization>
<address>
<postal>
<street>NEC Laboratories Europe</street>
<street>Network Research Division</street>
<street>Kurfuersten-Anlage 36</street>
<code>69115</code>
<city>Heidelberg</city>
<country>DE</country>
</postal>
<phone>+49 6221 4342-121</phone>
<email>Rolf.Winter@neclab.eu</email>
</address>
</author>
<author fullname="Thomas Dietz" initials="T." surname="Dietz">
<organization>NEC Europe Ltd.</organization>
<address>
<postal>
<street>NEC Laboratories Europe</street>
<street>Network Research Division</street>
<street>Kurfuersten-Anlage 36</street>
<code>69115</code>
<city>Heidelberg</city>
<country>DE</country>
</postal>
<phone>+49 6221 4342-128</phone>
<email>Thomas.Dietz@neclab.eu</email>
</address>
</author>
<author fullname="Benoit Claise" initials="B." surname="Claise">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>De Kleetlaan 6a b1</street>
<city>Degem</city>
<code>1831</code>
<country>BE</country>
</postal>
<phone>+32 2 704 5622</phone>
<email>bclaise@cisco.com</email>
</address>
</author>
<author fullname="Mouli Chandramouli" initials="M." surname="Chandramouli">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Sarjapur Outer Ring Road</street>
<city>Bangalore</city>
<region></region>
<code></code>
<country>IN</country>
</postal>
<phone>+91 80 4426 3947</phone>
<email>moulchan@cisco.com</email>
</address>
</author>
<date month="October" year="2010" />
<abstract>
<t>This memo discusses requirements for energy management,
particularly for monitoring energy consumption and controlling
power states of managed devices. This memo further shows that
existing IETF standards are not sufficient for energy management
and that energy management requires architectural considerations
that are diffenrent from common other management functions.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>With rising energy cost and with an increasing awareness of the
ecological impact of running IT and networking equipment, energy
management is becoming an additional basic requirement for network
management frameworks and systems.</t>
<t>Different to other typical network management functions, energy
management often extends its scope beyond devices with IP network
interfaces. Requirements in this document do not fully cover
all these networks, but they cover means for opening IP network
management towards them.</t>
<t>In general, IETF Standards for energy management should be defined
in such a way that they can be applied to several areas including
<list style="symbols">
<t>Communication networks and IT systems</t>
<t>Building networks</t>
<t>Home networks</t>
<t>Smart (power) grids</t>
</list></t>
<section title="Energy management functions">
<t>The basic objective of energy management is operating communication
networks and other equipment with a minimal amount of energy. An energy
management system should provide means for reducing the power consumption
of individual components of a network as well as of the whole network.</t>
<t>One approach to achieve this goal is setting all components to an
operational state that results in lower energy consumption but still
meets service level performance objectives. The sufficient performance
level may vary over time and can depend on several factors.
In principle, there are four basic types of power states for a
component or for a whole system:
<list style="symbols">
<t>full power state</t>
<t>reduced power states (lower clock rate for processor, lower
data rate on a link, etc.)</t>
<t>stand-by/sleep state (not functional, but immediately available)</t>
<t>power-off state (requiring significant time for becoming
operational)</t>
</list>
In actual implementations the number of power
states and their properties vary a lot. Very simple devices may just
have a full power and a power off state, while other devices may
have a high number of different reduced power and sleep states.</t>
<t>While the general objective of energy management is quite clear,
the way to attain that goal is often difficult. In many cases there
is no way of reducing power consumption without the consequence of
a potential performance degradation. Then a trade-off needs to be
dealt with between service level objectives and energy efficiency.
In other cases a reduction
of energy consumption can easily be achieved while still maintaining
sufficient service level performance, for example, by switching
components to lower power states when higher performance is not needed.
</t>
<t>Network management systems can control such situations by implementing
policies to achieve a certain degree of energy efficiency. In order to
make policy decisions properly, information about the energy consumption
of network components and sub-components in different power states is
required. Often this information is acquired best through monitoring.</t>
<t>Monitoring operational power states and energy consumption is also
useful for other energy management purposes including but not limited to
<list style="symbols">
<t>investigating power saving potential</t>
<t>evaluating the effectiveness of energy saving policies and
measures</t>
<t>deriving, implementing, and testing power management
strategies</t>
<t>accounting the total power consumption of a network element,
a network, a service, or subcomponents of those</t>
</list></t>
<t>From the considerations described above the following basic
management functions appear to be required for energy management:
<list style="symbols">
<t>monitoring power states of network elements and their
subcomponents</t>
<t>monitoring actual power (energy consumption rate) of network
elements and their subcomponents</t>
<t>monitoring (accumulated) energy consumption of network
elements and their subcomponents</t>
<t>setting power states of network elements and their subcomponents</t>
<t>setting and enforcing power saving policies</t>
</list></t>
<t>Editorial note: With the extension to power state control and
policy enforcement, the title of the draft does not anymore match
the scope well. The name of the draft will be updated in a future
revision.</t>
<t>It should be noted that monitoring energy consumption and power
states itself is obviously not in itself a means to reduce the energy
consumption of a device. In fact, it is likely to increase the power
consumption of a device slightly. However, the acquired energy
consumption and power state information is essential fordefining
energy saving policies and can be used as input to power state
control loops that in total can lead to energy savings.</t>
<t>It should further be noted that active power control is complementary
(but essential) to other energy savings measures such as low power
electronics, energy saving protocols (e.g. IEEE 802.3az), and
energy-efficient device design (for example, stand-by and low-power
modes for individual components of a device), and energy-efficient
network architectures. Measurement of energy consumption may also provide
input for developing these technologies.</t>
</section>
<section title="Specific aspects of energy management">
<t>There are two aspects of energy management that make it different
from other common network management functions. The first difference
is that energy consumption is often measured remotely to the device
under consideration.
A reason for this is that today very few devices are instrumented with
the hardware and software for measuring their own current power and
accumulated energy consumption. Often power and energy for such devices
is measured by other devices.</t>
<t>A common example is a Power over Ethernet (PoE) sourcing device
that provides means for measuring provided power per port.
If the device connected to a port is known, power and energy
measurements for that device can be conducted by the PoE sourcing
device. Another example is a smart power strip. Again, if it is known
which devices are plugged into which outlets of the smart power strip,
then the power strip can provide measured values for these devices.</t>
<t>The second difference is that often it is desirable to apply
energy management also
to networks and devices that do not communicate via IP, for example, in
building networks where besides IP several other communication protocols
are used. In these networks, it may be desirable that devices with IP
interfaces report energy and power values for other devices. Reports
may be based on measurements at the reporting device, similar to the
PoE sourcing device and the smart strip. But reports may also be just
relayed from non-IP communication to IP communication.</t>
</section>
</section>
<section anchor="scenarios" title="Scenarios and target devices">
<t>This section describes a selection of scenarios for the application
of energy management. For each scenario a list of target devices
is given in the headline, for which IETF energy management standards
are needed.</t>
<section title="Scenario 1: Routers, switches, middleboxes, and hosts">
<t>Power management of network devices is considered as a
fundamental (basic first step) requirement. The devices listed
in this scenario are some of the components of a communication
network. For these network devices, the chassis draws power
from an outlet and feeds all its internal sub-components.</t>
</section>
<section title="Scenario 2: PoE sourcing equipment and PoE powered devices">
<t>This scenario covers devices using Power over Ethernet (PoE).
A PoE Power Sourcing Equipment (PSE), for example, a PoE switch,
provices power to a PoW Powered Device (PD), for example, a PoE
desktop phone. Here, the PSE provides means for controlling power
supply (switching it on and off) and for monitoring actual power
provided at a port to a specific PD.</t>
</section>
<section title="Scenario 3: Power probes and Smart meters">
<t>Today, very few devices are equipped with sufficient
instrumentation to measure their own actual power and accumulated
energy consumption. Often external probes are connected to the
power supply for measuring these properties for a single device
or for a set of devices.</t>
<t>Homes, buildings, and data centers have smart meters that
monitor and report accumulated power consumption of an entire home,
a set of offices or a set of devices in data centers.</t>
<t>Power Distribution Unit (PDUs) attached to racks in data center
and other smart power strips are evolving with smart meters
and remote controllable power switches embedded for each socket.</t>
</section>
<section title="Scenario 4: Mid-level managers">
<t>Sometimes it is useful to have mid-level managers that provide
energy management functions not just for themselves but also for
a set of associated devices. For example, a switch can provide
energy management functions for all devices connected to its ports,
even if these devices are not PoE PDs, but have their own power
supply as, for example, PCs connected to the switch.</t>
</section>
<section title="Scenario 5: Gateways to building networks">
<t>Due to the potential energy savings, energy management of
buildings has received significant attention. There are
gateway network elements to manage the multiple components of
a building energy management network Heating Ventilating Air
Conditioning (HVAC), lighting, electrical, fire and emergency
systems, elevators etc. The gateway device provides power
monitoring and control function for other devices in the
building network.</t>
</section>
<section title="Scenario 6: Home energy gateways">
<t>Home energy gateway can be used for energy management of a
home. This gateway can manage the appliances (refrigerator,
heating/cooling, washing machine etc.) and interface with the
electrical grid. The gateway can implement policies based on
demand and energy pricing from the grid.</t>
</section>
<section title="Scenario 7: Data center devices">
<t>Energy efficiency of data centers has become a fundamental
challenges of data center operation. Energy management is conducted
on different aggregation levels, such as network level,
Power Distribution Unit (PDU) level, and server level.</t>
</section>
<section title="Scenario 8: Battery powered devices">
<t>Some devices have a battery as a back-up source of power.
Given the finite capacity and lifetime of a battery, means for
reporting the actual charge, age, and state of a battery are
required.</t>
</section>
</section>
<section anchor="requirements" title="Monitoring Requirements">
<t></t>
<section title="Granularity of monitoring and control">
<t>Often it is desirable to switch off individual components of a device
but not the entire device. The switch may need to continue serving a few
ports (for example, the ports serving an email server or needed for
server backup), but most other ports could be entirely switched off
under some policies (for example at night or the weekend in an office).</t>
<t>As illustrated by this example, it is often desirable to monitor
power state and energy consumption on a granularity level that is finer
than just the device level. Monitoring should be available for
individual components of devices, such as line cards, processor cards,
hard drives, etc. For example, for IP routers the following list of
views of a router gives an idea of components that potentially
could be monitored and controlled individually:
<list style="symbols">
<t>Physical view: chassis (or stack), central control engine, line
cards, service cards, etc. </t>
<t>Component view: CPU, ASICs, fans, power supply, ports (single ports
and port groups), storage and memory</t>
<t>Feature view: L2 forwarding, L3 routing, security features, load
balancing features, network management, etc.</t>
<t>Logical view: system, data-plane, control-plane, etc.</t>
<t>Relationship view: line cards, ports and the correlation between
transmission speed and power consumption, relationship of system load
and total power consumption</t>
</list></t>
<t>Instrumentation for measuring energy consumption of a
device is typically more expensive than instrumentation for
retrieving the devices power state. It may be a reasonable compromise
in many cases to provide power state information for all individually
switchable components of a device separately, while the energy
consumption is only measured for the entire device.</t>
</section>
<section anchor="remote" title="Remote and Aggregated Monitoring">
<t>There are several ways power and energy consumption can be
measured and reported. Measurements can be performed locally at
the device that consumes energy or remotely by a device that has
access to the power supply of another device.</t>
<t>Instrumentation for power and energy measurements at a device
requires additional hardware.
A cost-efficient alternative is measuring power and energy
consumption aggregated for a set of devices, for example a PoE
PSE reporting these values per port group instead of per port,
or a power distribution unit that reports the values for all
connected devices instead of per socket.</t>
<t>If aggregated measurement is conducted, it is obvious that
reporting provides aggregated values. but aggregated reporting can
also be combined with local measurements. A managed node may act as
mid-level manager or protocol converter for several devices that
measure power consumption by themselves, for example a home gateway
or a gateway to building networks. In this case, the reporting node
may choose to report for each device individual values or aggregated
values from groups of devices that transmitted their power and
energy consumption values to the reporting node.</t>
<t>Often it is sufficient and more cost efficient having a single device
measuring and providing power state and energy consumption information
not just for itself but also for several further devices that are in
some way attached to it. If the measuring and reporting device has
access to individual power supply lines for each device, then it can
measure energy consumption per device. If it only has access to a joint
power supply for several devices, then it will measure aggregated
values. </t>
<t>One example for the first case is a switch acting as power sourcing
equipment for several IP phones using Power over Ethernet (PoE). The
switch can measure the power consumption for each phone individually
at the port the phone is connected to or it measures aggregated values
per port group for a set of devices.. The phones do not need to provide
means for energy consumption measurement and reporting by themselves.
</t>
<t>Another example is a smart meter that just measures and reports the
energy transmitted through attached electric cables. Such a smart meter
can be used to monitor energy consumption of an individual device if
connected to the devices' individual power supply. But in many common
cases it measures the aggregated energy consumption of several devices,
for example, as part of an uninterruptible power supply (UPS) that
serves several devices at a single power cord, or as a smart electric
meter for a set of machines in a rack, in an office building or at a
residence.</t>
</section>
<section title="Accuracy">
<t>Depending on how power and energy consumption values are obtained
the confidence in the reported value and its accuracy may vary.
Managed nodes reporting values concerning themselves or other devices
should qualify the confidence in reported values and quantify the
accuracy of measurements. For
accuracy reporting, the accuracy classes specified in IEC 61850
should be considered.</t>
</section>
<section title="Required Information">
<t>This section lists requirements for information to be retrieved.
Because of the different nature of power state monitoring and energy
consumption monitoring, these are discussed separately. In addition,
a section on battery monitoring is included which again comes
with a set of very different requirements.</t>
<t>Not all of the individual requirements listed in subsections
below are equally relevant. A classification into 'required' and
'optional' is still in progress.</t>
<section title="Power State Monitoring">
<t>The power state of a device or component typically can only have a
small number of discrete values such as, for example, full power, low
power, standby, hibernating, off. However, some of these states may
have one or more sub-states or state parameters. For example, in low
power state, a reduced clock rate may be set to a large number of
different values. For the device power state, the following
information is considered to be relevant:</t>
<t><list style="symbols">
<t>the current state - the time of the last change</t>
<t>the cause for the last transition</t>
<t>time to transit from one stage to another</t>
<t>the total time spent in each state</t>
<t>the duration of the last period spent in each state</t>
<t>the number of transitions to each state</t>
<t>the current power source</t>
</list></t>
<t>For some network management tasks it may be desirable to receive
notifications from devices when components or the entire device
change their power state.</t>
</section>
<section title="Energy Consumption Monitoring">
<t>Independent of the power state, energy consumption of a device or a
device's component is a quantity for which the value may change
continuously. Therefore, the information that needs to be retrieved
concerning this quantity is quite different:
<list style="symbols">
<t>the current real power (energy consumption rate) averaged
over a short time interval</t>
<t>total energy consumption</t>
<t>energy consumption since the last report or for the last
configured time interval</t>
<t>total energy consumption per power state</t>
<t>energy consumption per power state since the last report</t>
</list>
For some network management tasks it may be desirable to
receive notifications from devices when the current power
consumption of a component or of the entire device exceeds or falls
below certain thresholds.</t>
<t>Energy consumption of a device or a device's component
is a quantity for which the value may change continuously.
For some network management tasks it is required to measure the
power over time with a relatively high time resolution. In such a
case not just single values for the current power of a component is
needed, but a series of power values reporting on consecutive time
intervals.</t>
<t>In order to put measured data into perspective, the precision of
the measured data, i.e. the potential error in the measured data,
needs to be known as well. </t>
</section>
<section title="Power Quality">
<t>In addition to the quantity of power or energy, also power
quality should be reported according to IEC 62053-22 and
IEC 60044-1.</t>
</section>
<section title="Battery State Monitoring">
<t>An increasing number of networked devices are expected to be
battery powered. This includes e.g. smart meters that report
meter readings and are installed in places where external power
supply is not always possible or costly. But also other devices
might have internal/external batteries to power devices for short
periods of time when the main power fails, to power parts of the device
when the main device is switches off etc. Knowing the state of these
batteries is important for the operation of these devices and includes
information such as:
<list style="symbols">
<t>the current charge of the battery</t>
<t>the age of the battery</t>
<t>the state of the battery (e.g. being re-charged)</t>
<t>last usage of the battery</t>
<t>maximum energy provided by the battery</t>
</list>It is possible for devices that are only battery-powered to
send notifications when the current battery charge has dropped below a
certain threshold in order to inform the management system of needed
replacement. The same applies for the age of a battery.
</t>
</section>
</section>
</section>
<section anchor="models" title="Monitoring Models">
<t>Monitoring of power states and energy consumption can be performed in
pull mode (for example, SNMP GET <xref target="RFC3410"/>) or in push mode
(for example SNMP notification <xref target="RFC3410"/>, Syslog <xref
target="RFC5424"/>, or IPFIX <xref target="RFC5101"/>).</t>
<t>Pull mode monitoring is often easier to handle for a network management
systems, because it can determine when it gets certain information from
a certain device. However, the overhead of pull model monitoring is
typically higher than for push model monitoring, particularly when large
numbers of values are to be collected, such as time series of power
values.</t>
<t>In such cases, push model monitoring may be preferable with a device
sending a data stream of values without explicit request for each value
from the network management system. For notifications on events, only the
push model is considered to be appropriate.</t>
<t>Applying these considerations to the required information leads to the
conclusion that most of the information can appropriately be reported
using the pull model. The only exceptions are notifications on power state
changes and high volume time series of energy consumption values.</t>
</section>
<section anchor="control" title="Control Requirements">
<t>To realize the envisioned benefits of energy savings,
just monitoring power states and energy consumption would not be
sufficient. Energy efficiency can be realized only by setting the
network entities or components to energy saving power states when
appropriate.</t>
<t>With means for power state control, energy saving policies and
control loops can be realized. Policies may, for example, define
different power state settings based on the time-of-day. Control
loops may, for example, change power states based on actual
network load.</t>
<t>Trivially, all entities being subject of energy management
should have at least two power states, such as "on" and "off"
or "on" and "sleep" to be set.
In many cases, it may be desirable to have more operational
("on" mode") and non-operational ("off"/"sleep" mode) power states.
This applies particularly to devices with a lot of configuration
parameters that influence their energy consumption. Examples for
specifications of power states of managed devices can be found in
the
<xref target="ACPI.R30b">Advanced Configuration and Power Interface (ACPI)</xref>
or the
<xref target="DMTF.DSP1027">DMTF Power State Management Profile</xref>.</t>
</section>
<section anchor="standards" title="Existing Standards">
<t>This section analyzes existing standards for energy consumption and
power state monitoring. It shows that there are already several standards
that cover some part of the requirements listed above, but even all
together they do not cover all of the requirements for energy
management.</t>
<section title="Existing IETF Standards">
<t>There are already RFCs available that address a subset of the
requirements.</t>
<section title="ENTITY STATE MIB">
<t><xref target="RFC4268">RFC 4268</xref> defines the ENTITY STATE
MIB module. Implementations of this module provide information on
entities including the standby status (hotStandby, coldStandby,
providingService), the operational status (disabled, enabled,
testing), the alarm status (underRepair, critical, major, minor,
warning), and the usage status (idle, active, busy). This
information is already useful as input to policy decisions and for
other network monitoring tasks. However, the number of states would
cover only a small
subset of the requirements for power state monitoring and it does
not provide means for energy consumption monitoring. For associating
the provided information to specific components of a device,
the ENTITY STATE MIB module makes use of the means provided by the
<xref target="RFC4133">ENTITY MIB module</xref>. Particularly, it
uses the entPhysicalIndex for identifying entities.</t>
<t>The standby status provided by the ENTITY STATE MIB module is
related to power states required for energy management, but the
number of states is too restricted for meeting all energy management
requirements.
For energy management several more power states are required,
such as different sleep and operational states as defined by
the
<xref target="ACPI.R30b">Advanced Configuration and Power Interface (ACPI)</xref>
or the
<xref target="DMTF.DSP1027">DMTF Power State Management Profile</xref>.</t>
</section>
<section title="ENTITY SENSOR MIB">
<t><xref target="RFC3433">RFC 3433</xref> defines the ENTITY SENSOR
MIB module. Implementations of this module offer a generic way to
provide data collected by a sensor. A sensor could be an energy
consumption meter delivering measured values in Watt. This could be
used for reporting current power of a device and its components.
Furthermore, the ENTITY SENSOR MIB can be used to retrieve the
precision of the used power meter.</t>
<t>Similar to the ENTITY STATE MIB module, the ENTITY SENSOR MIB
module makes use of the means provided by the <xref
target="RFC4133">ENTITY MIB module</xref> for relating provided
information to components of a device. </t>
<t>However, there is no unit available for reporting energy
quantities, such as, for example, watt seconds or kilowatt hours,
and the ENTITY SENSOR MIB module does not support reporting
accuracy of measurements according to the IEC / ANSI accuracy
classes, which are commonly in use for electric power and energy
measurements. The ENTITY SENSOR MIB modules only provides a
coarse-grained method for indicating accuracy by stating the
number of correct digits of fixed point values.</t>
</section>
<section title="UPS MIB">
<t><xref target="RFC1628">RFC 1628</xref> defines the UPS MIB
module. Implementations of this module provide information on the
current real power of devices attached to an uninterruptible power
supply (UPS) device. This application would require identifying
which device is attached to which port of the UPS device.</t>
<t>UPS MIB provides information on the state of the UPS network.
The MIB module contains several variables identify the UPS
entity (name, model,..), the battery state, to characterize
the input load to the UPS, to characterize the output from
the UPS, to indicate the various alarm events. The
measurements of power in UPS MIB are in Volts, Amperes and Watts.
The units of power measurement are RMS volts, RMS Amperes and
are not based on Entity-Sensor MIB [RFC3433].</t>
</section>
<section title="POWER ETHERNET MIB">
<t>Similar to the UPS MIB, implementations of the POWER ETHERNET MIB
module defined in <xref target="RFC3621">RFC3621</xref> provide
information on the current energy consumption of the devices that
receive Power over Ethernet (PoE). This information can be retrieved
at the power sourcing equipment. Analogous to the UPS MIB, it is
required to identify which devices are attached to which port
of the power sourcing equipment.</t>
<t>The POWER ETHERNET MIB does not report power and energy
consumption on a per port basis, but can report aggregated values
for groups of ports. It does not use objects of the ENTITY MIB
module for identifying entities, although this module existed
already when the POWER ETHERNET MIB modules was standardized.</t>
</section>
<section title="LLDP MED MIB">
<t>The Link Layer Discovery Protocol (LLDP) defined in IEEE
802.1ab is a data link layer protocol used by network devices
for advertising of their identities, capabilities, and
interconnections on a LAN network.
The Media Endpoint Discovery (MED) (ANSI/TIA-1057) is an enhancement
of LLDP known as LLDP-MED. The LLDP-MED enhancements specifically
address voice applications. LLDP-MED covers 6 basic areas:
capabilities discovery, LAN speed and duplex discovery,
network policy discovery, location identification discovery,
inventory discovery, and power discovery.</t>
</section>
</section>
<section title="Existing standards of other bodies">
<t></t>
<section title="DMTF">
<t>The DMTF has defined a <xref target="DMTF.DSP1027">power state
management profile</xref> that is targeted at computer systems.
It is based on the DMTF's Common Information Model (CIM) and rather
a device profile than an actual energy consumption monitoring
standard.</t>
<t>The power state management profile is used to describe and to
manage the power state of computer systems. This includes e.g. means
to change the power state of a device (e.g. to shutdown the device)
which is an aspect of but not sufficient for active energy management.
</t>
</section>
</section>
</section>
<section title="Suggested Actions">
<t>Based on the analysis of requirements in <xref
target="requirements"/> and the discussion of monitoring models in
<xref target="models"/> this memo proposes to develop a standard for
pull-based monitoring of power states, energy consumption, and battery
states. The analysis of existing
MIB modules in the previous section shows that they are not sufficient
to meet the requirements discussed in <xref target="requirements"/>.</t>
<t>As a consequence, it suggested to develop one or more MIB modules
for this purpose. Such MIB modules could also cover push-based reporting
of power state changes using SNMP notifications. The only aspect that
would not be covered well by a MIB/SNMP solution is the
reporting of large time series of energy consumption values. For this
purpose SNMP does not appear to be an optimal choice. Particularly for
supporting smart meter functionality, a push-based protocol appears to be
more appropriate. Within the IP protocol family the Syslog and IPFIX
protocols seem to be the most suitable candidates. There are more standard
protocols with the capability to transfer measurement series, for example,
DIAMETER, but these protocols are designed and well suited for other
application areas than network monitoring.</t>
<t>Comparing the two candidates (Syslog and IPFIX), IPFIX seems to be the
better suited one. While Syslog is optimized for the transmission of text
messages, IPFIX is better equipped for transmitting sequences of numerical
values. Encoding numerical values into syslog is well feasible, see, for
example, the mapping of SNMP notifications to Syslog messages in <xref
target="RFC5675"/>, but IPFIX provides better means.
With the extensible IPFIX information model <xref target="RFC5102"/> no
protocol extension would be required for transmitting energy consumption
information. Only a set of new information elements would need to be
registered at IANA. However, this memo suggests that the definition of such
information elements should be conducted within the IETF and they should
be documented in a standards track RFC.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Ralf Wolter, for his first essay on
this draft.</t>
</section>
<section title="Security Considerations">
<t>This memo currently does not impose any security
considerations.</t>
</section>
<section title="IANA Considerations">
<t>This memo has no actions for IANA..</t>
</section>
</middle>
<back>
<references title="Informative References">
&rfc4268;
&rfc3621;
&rfc1628;
&rfc3433;
&rfc4133;
&rfc5101;
&rfc5102;
&rfc3410;
&rfc5424;
&rfc5675;
<reference anchor="ACPI.R30b">
<front>
<title>Advanced Configuration and Power Interface Specification, Revision 3.0b</title>
<author initials="" surname="Hewlett-Packard Corporation" fullname="Hewlett-Packard Corporation"></author>
<author initials="" surname="Intel Corporation" fullname="Intel Corporation"></author>
<author initials="" surname="Microsoft Corporation" fullname="Microsoft Corporation"></author>
<author initials="" surname="Phoenix Corporation" fullname="Phoenix Corporation"></author>
<author initials="" surname="Toshiba Corporation" fullname="Toshiba Corporation"></author>
<date year="2006" month="October" />
</front>
</reference>
<reference anchor="DMTF.DSP1027">
<front>
<title>Power State Management Profile</title>
<author initials="R.R." surname="Dasari (ed.)" fullname="RadhaKrishna R. Dasari (ed.)"></author>
<author initials="J." surname="Davis (ed.)" fullname="Jim Davis (ed.)"></author>
<author initials="J." surname="Hilland (ed.)" fullname="Jeff Hilland (ed.)"></author>
<date year="2008" month="September" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 11:02:39 |