One document matched: draft-quittek-eman-reference-model-03.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!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 rfc6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY rfc6021 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6021.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY rfc6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY rfc5101 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5101.xml">
<!ENTITY rfc5675 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5675.xml">
<!ENTITY id.draft-ietf-eman-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eman-framework-02.xml">
]>
<!--<?rfc strict="yes"?>-->
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocompact="no"?>
<!--<?rfc footer="draft-quittek-eman-reference-model-03"?>-->
<?rfc compact="yes"?>
<!--<?rfc subcompact="compact"?>-->
<?rfc symrefs="yes"?>
<rfc category="info"
docName="draft-quittek-eman-reference-model-03"
ipr="trust200902">
<front>
<title>Reference Model for Energy Management</title>
<author fullname="Jürgen Quittek" initials="J."
surname="Quittek">
<organization>NEC Europe Ltd.</organization>
<address>
<postal>
<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="Bruce Nordman" initials="B."
surname="Nordman">
<organization>Lawrence Berkeley National Laboratory</organization>
<address>
<postal>
<street>1 Cyclotron Road</street>
<code>94720</code>
<city>Berkeley</city>
<country>US</country>
</postal>
<phone>+1 510 486 7089</phone>
<email>bnordman@lbl.gov</email>
</address>
</author>
<author fullname="Rolf Winter" initials="R."
surname="Winter">
<organization>NEC Europe Ltd.</organization>
<address>
<postal>
<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>
<date month="October" year="2011" />
<abstract>
<t>Managing energy consumption of devices is different from
several well understood network management functions because of
the special nature of energy supply and use. This document
explains issues of energy management arising from its special
nature and proposes a layered reference model for energy
management addressing these issues.
<!--
This memo proposes a reference model for energy consumption
monitoring and control. It claims that the only basic extension
of conventional network management models is the concept of
power interfaces of managed entities. Power interfaces can be
treated similarly to network interfaces. They have different
modes (outlet, inlet, probe) and their connections to transmission
media (lines) define a power supply topology among the involved
managed entities. This memo elaborates an information model
for power interfaces that meets the requirements for energy
management.
-->
</t>
</abstract>
</front>
<middle>
<!-- ####################### Intro ##################### -->
<section title="Introduction">
<t>Managing energy consumption of devices is different from
several well understood network management functions because of
the special nature of energy supply and use. This memo explains
issues of energy management arising from its special nature and
proposes a reference model for energy management addressing these
issues.</t>
<t>Defining a suitable reference model for energy management has
proven to be explorative work that cannot be done in a single
step because the area is rather new to people at the IETF.
Ideas for a reference model have been
elaborated in <xref target="I-D.ietf-eman-framework"/> and previous
versions of this draft.</t>
<t>This revision is an attempt to combine the relationship model
proposed in the last version (-02) of <xref target="I-D.ietf-eman-framework"/>
with the concept of power interfaces proposed in the previous
version (-02) of this draft. The result is a four layer model of energy
management. </t>
<t>This draft starts with identifying and describing in
<xref target="issues"/> the special issues of energy management
that require the development of a new reference model.
The issues concern power supply, power and energy metering,
and the reporting of low-power states.</t>
<t><xref target="reference-model"/> addresses these issues and
proposed a new four layer model for energy management,
see <xref target="fig-layers-intro"/>.</t>
<figure anchor="fig-layers-intro"
title="Layers of the Energy Management Reference Model">
<artwork><![CDATA[
+----------------------------------------------+
| energy management system (EnMS) |
+----------------------------------------------+
||| |||
+---------------------+ |||
| energy management | |||
| mediation (EMM) | |||
+---------------------+ |||
|| |||
+----------------------------------------------+
| local energy management interface (LMI) |
+----------------------------------------------+
|
+----------------------------------------------+
| power supply and use (PSU) |
+----------------------------------------------+
]]></artwork>
</figure>
<t><list style="symbols">
<t>Power supply and use (PSU) layer<vspace/>
At the lowest layer electrical objects
are physically connected by power supply
lines, and these connections constitute an electric supply
topology.</t>
<t>Local energy management interface (LMI) layer<vspace/>
This layer provides access to local information and to local
control functions at managed electrical devices.</t>
<t>Energy management mediation (EMM) layer<vspace/>
At this layer management functions use topology information
from the PSU layer to infer information on remote devices and
to realize control functions for remote devices.</t>
<t>Energy management system layer<vspace/>
This layer contains a centralized or distributed energy management
system that manages powered devices.</t>
</list></t>
<t>All communication with the energy management system (drawn
with three parallel lines) in <xref target="fig-layers-intro"/>
is subject of standardization in the EMAN working group. Communication
between the EMM layer and the LMI layer (drawn with two parallel
lines) is an application area of standards developed in the EMAN WG,
but here also proprietary protocols may be used. Communication
between the LMI layer and the PSU layer (drawn with a single line)
is not subject of standardization by EMAN.</t>
<t>At the core of this framework are just a few key concepts.
Energy is used by Powered Devices, some of which supply power
to other devices and so are a subset called a Power Supply.
Devices have power interfaces, which are like network interfaces,
through which power is transferred into (an "inlet") or out of
(an "outlet") a device.
Measurement occurs at interfaces so that the total or net
consumption of a device can be determined.</t>
</section>
<!-- ####################### Issues ##################### -->
<section anchor="issues" title="Energy Management Issues">
<t>This section explains special issues of energy management
particularly concerning power supply, power and energy metering,
and the reporting of low-power states.</t>
<t>To illustrate the issues we start with a simple and basic
scenario with a single powered device that consumes energy and
that reports energy-related information about itself to an energy
management system, see <xref target="fig-basicexample"/>.</t>
<figure anchor="fig-basicexample"
title="Basic energy management scenario">
<artwork><![CDATA[
+--------------------------+
| energy management system |
+--------------------------+
^ ^
monitoring | | control
v v
+-----------------+
| powered device |
+-----------------+
]]></artwork>
</figure>
<t>The device may have local energy control mechanisms,
for example putting itself into a sleep mode when appropriate,
and it may receive energy control commands for similar purposes
from a management system.
Information reported from a powered device to the energy
management system includes at least the power state of the
device (on, sleep, off, etc.).</t>
<t>This and similar cases are well understood and likely to become
very common for energy management. They can be handled with well
established and standardized management procedures.
The only missing components today are standardized information
and data models for reporting and configuration, such as,
for example, energy-specific MIB modules <xref target="RFC2578"/>
and YANG modules <xref target="RFC6020"/>.</t>
<t>However, the nature of energy supply and use introduces some
issues that are special to energy management. The following
subsections address these issues and illustrate them by extending
the basic scenario in <xref target="fig-basicexample"/>.</t>
<section anchor="powersupply" title="Power Supply">
<t>A powered device may supply itself with power. Sensors,
for example, commonly have batteries or harvest energy.
However, most powered devices that are managed by an energy
management system receive external power.</t>
<t>While a huge number of devices receive power from unmanaged
supply systems, the number of manageable power supply devices
is increasing. In datacenters, many Power Distribution Units
(PDUs) allow the network management system to switch
power individually for each socket and also to measure the
provided power. Here there is a big difference to many other
network management tasks: In such and similar cases, switching
power supply for a powered device or monitoring its power is not
done by communicating with the actual powered device, but with
an external power supply device (which may be an external power meter).</t>
<t>Consequently, a standard for energy management must not
just cover the powered devices that provide services for users,
but also the power supply devices (which are powered devices
as well) that monitor or control the power supply for
other powered devices.</t>
<t>A very simple device such as a plain light bulb can be
switched on or off only by switching its power supply. More
complex devices may have the ability to switch off themselves
or to bring themselves to states in which they consume very
little power.
For these devices as well it is desirable to monitor and control
their power supply.</t>
<t>This extends our basic scenario from
<xref target="fig-basicexample"/> by a power supply device,
see <xref target="fig-powersupply"/>.</t>
<figure anchor="fig-powersupply" title="Power Supply">
<artwork><![CDATA[
+-----------------------------------------+
| energy management system |
+-----------------------------------------+
^ ^ ^ ^
monitoring | | control monitoring | | control
v v v v
+--------------+ +-----------------+
| power supply |########| powered device |
+--------------+ +-----------------+
######## power supply line
]]></artwork>
</figure>
<t>The power supply device can be as simple as a plain power
switch. It may offer interfaces to the energy management system
to monitor and to control the status of its power outlets,
as with PDUs and
<xref target="IEEE-802.3at">Power over Ethernet (PoE)</xref>
switches.</t>
<t>The relationship between
supply devices and the powered devices they serve creates several problems
for managing power supply:
<list style ="symbols">
<t>Identification of corresponding devices
<list style="symbols">
<t>A given powered device may be need to
identify the supplying power supply device.</t>
<t>A given power supply device may need
to identify the corresponding supplied powered device(s).</t>
</list></t>
<t>Aggregation of monitoring and control for multiple
powered devices
<list style="symbols">
<t>A power supply device may supply multiple powered
devices with a single power supply line.</t>
</list></t>
<t>Coordination of power control for devices with multiple
power inlets
<list style="symbols">
<t>A powered device may receive power via multiple power
lines controlled by the same or different power supply devices.</t>
</list></t>
</list></t>
<section anchor="powersupply-identification"
title="Identification of Power Supply and Powered Devices">
<t>When a power supply device controls or monitors power supply
at one of its power outlets, the effect on other devices
is not always clear without knowledge about wiring
of power lines. The same holds for monitoring.
The power supplying device can report that a particular socket
is powered, and
it may even be able to measure power
and conclude that there is a consumer drawing power at that
socket, but it may not know which powered device
receives the provided power.</t>
<t>In many cases it is obvious which other device is supplied
by a certain outlet, but this always requires
additional (reliable) information about power line wiring.
Without knowing which device(s) are powered via a certain outlet,
monitoring data are of limited value and switching on the
consequences of switching power on or off may be hard to predict.</t>
<t>Even in well organized operations, powered
devices' power lines get plugged into the wrong socket, or
wiring plans are changed without updating the energy management system
accordingly.</t>
<t>For reliable monitoring and control of power supply devices,
additional information is needed to identify the device(s)
that receive power provided at a particular monitored and
controlled socket.</t>
<t>This problem also occurs in the opposite direction. If power
supply control or monitoring for a certain device is needed,
then the supplying power supply device has to be identified.</t>
<t>To conduct energy management tasks for both power supply
devices and other powered devices,
sufficiently unique identities are needed, and knowledge of
their power supply
relationship is required.</t>
</section>
<section anchor="multiplesupplieddevices"
title="Multiple Devices Supplied by a Single Power Line">
<t>The second fundamental problem is the aggregation of monitoring
and control that occurs when multiple powered devices are supplied
by a single power supply line. It is often required
that the energy management system has the full list of
powered devices connected to a single outlet as in
<xref target="fig-multiplesupplieddevices"/>.</t>
<figure anchor="fig-multiplesupplieddevices"
title="Multiple Powered Devices Supplied by Single Power Line">
<artwork><![CDATA[
+---------------------------------------+
| energy management system |
+---------------------------------------+
^ ^ ^ ^
monitoring | | control monitoring | | control
v v v v
+--------+ +------------------+
| power |########| powered device 1 |
| supply | # +------------------+-+
+--------+ #######| powered device 2 |
# +------------------+-+
#######| powered device 3 |
+------------------+
]]></artwork>
</figure>
<t>With this list, the single status value has clear meaning
and is the sum of all powered devices.
Control functions are limited by the fact that supply for
the concerned devices can only be switched on or off for all
of them at once. Individual control at the supply is not possible.</t>
<t>If the full list of powered devices powered by a single supply
line is not known for the controlling power supply device, then
control of power supply is problematic, because the consequences
of control actions can only be partially known.
</t>
</section>
<section anchor="multiplesupplies"
title="Multiple Power Supply for a Single Powered Device">
<t>The third problem arises from the fact that there are devices
with multiple power supplies. Some have this for redundancy of
power supply, some for just making internal power converters
(for example, from AC mains power to DC internal power) redundant,
and some because the capacity of a single supply line is insufficient.
</t>
<figure anchor="fig-multiplesupplies"
title="Multiple Power Supply for Single Powered Device">
<artwork><![CDATA[
+----------------------------------------------+
| energy management system |
+----------------------------------------------+
^ ^ ^ ^ ^ ^
mon. | | ctrl. mon. | | ctrl. mon. | | ctrl.
v v v v v v
+----------+ +----------+ +----------+
| power |######| powered |######| power |
| supply 1 |######| device | | supply 2 |
+----------+ +----------+ +----------+
]]></artwork>
</figure>
<t>The example in <xref target="fig-multiplesupplies"/>
does not necessarily show a real world scenario, but it shows
the two cases to consider:
<list style="symbols">
<t>multiple power supply lines between a single power supply device
and a powered device</t>
<t>different power supply devices supplying a single powered
device</t>
</list>
In any such case there may be a need to identify the supplying
power supply device individually for each power inlet of a
powered device. Without this information, monitoring
and control of power supply for the powered device may be
limited.</t>
</section>
<section anchor="powersupplyrelevance"
title="Relevance of Power Supply Issues">
<t>In some scenarios, the problems with power supply
do not exist or can be sufficiently solved. With
<xref target="IEEE-802.3at">Power over Ethernet (PoE)</xref>
there is always a one-to-one relationship between
a Power Sourcing Equipment (PSE) and a Powered Device (PD).
Also, the Ethernet link on the line used for
powering can be used to identify the two connected devices.
</t>
<t>For supply of AC mains power, the three
problems described above cannot be solved in general. There
is no commonly available protocol or automatic mechanism for
identifying endpoints of a power line. And, AC power lines
support supplying multiple powered devices with a single line
and commonly do.
</t>
</section>
<section anchor="remotecontrol" title="Remote Power Supply Control">
<t>There are three ways for an energy management system to change
the power state of a managed entity. First is for a management
system to provide policy or other useful information (like
the electricity price) to the powered device for it to use in determining
its power state. The second is sending the entity a command
to switch to another state. The third is to utilize an upstream
device (to the powered device) that has capabilities to
switch on and off power at its outlet.</t>
<t>Some entities do not have capabilities for receiving commands
or changing their power states by themselves. Such devices may
be controlled by switching on and off the power supply for them
and so have particular need for the third method.</t>
<t>In <xref target="fig-powersupply"/> the power supply
can switch on and off power at its power outlet
and thereby switch on and off power supply for the
connected powered device.</t>
</section>
</section>
<section title="Power and Energy Measurement">
<t>Some devices include hardware to directly measure their power
and energy consumption. However, most
common networked devices do not provide an interface that
gives access to energy and power measurements for the device.
Hardware instrumentation for this kind of measurements is typically
not in place and adding it incurs an additional cost.</t>
<t>With the increasing cost of energy and the growing importance
of energy monitoring, it is expected that in future more devices
will include instrumentation for power and energy measurements, but
this may take quite some time.</t>
<section title="Local Estimates">
<t>One solution to this problem is for the device to estimate
its own power and
consumed energy. For many energy management tasks, getting an
estimate is much better than not getting any information at all.
Estimates can be based on actual measured activity level of a device or
it can just depend on the power state (on, sleep, off, etc.).
</t>
<t>The advantage of estimates is that they can be realized locally
and with much lower cost than hardware instrumentation. Local
estimates can be dealt with in traditional ways. They don't need
an extension of the basic example above. However, the powered device
needs an energy model of itself to make estimates.</t>
</section>
<section title="Management System Estimates">
<t>Another approach to the lack of instrumentation
is estimation by the energy management system. The
management system can estimate power based on basic
information on the powered device, such as the type of device,
or also its brand/model and functional characteristics.
Energy estimates can combine the typical power level by power state with
reported data about the power state.</t>
<t>If the energy management system has a detailed energy model
of the device, it can produce better estimates including the actual
power state and actual activity level of the device. Such information
can be obtained by monitoring the device with conventional means
of performance monitoring.</t>
</section>
</section>
<section title="Reporting Sleep and Off States">
<t>Low power modes pose special challenges for energy reporting
because they may preclude a device from listening to and responding
to network requests.
Devices may still be able to reliably track energy use in
these modes, as power levels are usually static and
internal clocks can track elapsed time in these modes. </t>
<t>Some devices do have out-of-band or proxy abilities to
respond to network requests in low-power modes.
Others could use proxy abilities in an energy management
protocol to improve this reporting, particularly if the
device sends out notifications of power state changes.</t>
</section>
<section title="Entities">
<t>The primary focus of energy management is entire devices,
but in some applications it is necessary or desirable to also
have visibility into energy use of internal components such as
line cards, fans, disks, etc. Components lack some of the
features of devices, such as having power interfaces; instead,
they simply have a net total consumption from the pool
of power available within a device.
Note that a device need not have an AC power cord. For example,
a DC-powered blade server in a chassis has its own identity on
the network and reports for itself, and so is a separate device,
not a component of the chassis.</t>
</section>
</section>
<!-- ##################### Reference Model ################# -->
<section anchor="reference-model" title="Energy Management Reference Model">
<t>This section specifies a reference model for energy monitoring
and explains how it solves the problems outlined above.
It is structured into four layers:</t>
<figure anchor="fig-layers"
title="Layers of the Energy Management Reference Model">
<artwork><![CDATA[
+----------------------------------------------+
| energy management system (EnMS) |
+----------------------------------------------+
||| |||
+---------------------+ |||
| energy management | |||
| mediation (EMM) | |||
+---------------------+ |||
|| |||
+----------------------------------------------+
| local energy management interface (LMI) |
+----------------------------------------------+
|
+----------------------------------------------+
| power supply and use (PSU) |
+----------------------------------------------+
]]></artwork>
</figure>
<t>At the power supply and use (PSU) layer electrical objects
(powered entities) are physically
connected by power supply lines. Their connections constitute
an electric supply and metering topology.</t>
<t>The local energy management interface (LMI) layer provides a
set of functions for monitoring and controlling individual powered
entities. These functions are local to the entity and restricted
to only report properties and states of the entity, as with most
common network management functions on managed entities
today.</t>
<t>The energy management mediation (EMM) layer provides 'convenience'
functions to the energy management system. It performs functions
specific to energy management by utilizing information
from the PSU layer to infer information on Electrical Objects (EOs)
and to bundle control
functions concerning the same EO. It also offers some more general
functions such as proxying and aggregation on monitored information.
</t>
<t>The energy management system (EnMS) layer contains a centralized or
distributed energy management system that manages a set of powered
devices.</t>
<section anchor="psu-layer" title="Power Supply and Use (PSU) Layer">
<t>This layer models the electrical connections between electrical
objects. "Electrical object" (EO) is used as general term for
three kinds of objects. An EO is a powered entity (PE).
Connections between them are made with power supply lines.</t>
<t>According to the general issues identified in Section <xref
format="counter" target="powersupply"/> the following specific issues are
addressed at this layer:</t>
<t><list style ="symbols">
<t>Identification of electrical connection endpoints</t>
<t>Supply relationships between connected EOs</t>
<t>Aggregation of power supply for multiple PEs</t>
<t>Metering at connection endpoints</t>
<t>Metering relationships between connected EOs</t>
<t>Aggregation of metering for multiple PEs</t>
</list></t>
<t>For the general problem of identifying EOs, there are
many methods already in use by network management
systems. Such methods include identification by IP addresses,
by MAC addresses, by serial numbers, by assigned UUIDs, etc.
Those can be re-used for
identifying EOs.</t>
<t>There does not yet exist a commonly used way to address
different power interfaces of the same device. There are power
distribution units that enumerate their power outlets and Power
over Ethernet switches that enumerate their ports and port groups.
</t>
<t>The reference model for the PSU layer uses the concept of a
power interface to address the identification of individual
connection endpoints of power supply lines at EOs.</t>
<t>This term is not new. It is already used similarly
by the IEEE standard for <xref target="IEEE-802.3af">Power over Ethernet
(PoE)</xref> and <xref target="IEEE-802.3at"/> where a power interface
denotes the interface between a device and the Ethernet transmission
medium. The following terms
for components of the PSU layer are derived from PoE terminology.</t>
<section anchor="psu-components" title="Components of the PSU Layer">
<t><list style="symbols">
<t>Power Interface (PI) <vspace/>
A power interface is the interface
between an EO and a power transmission medium. There are some
similarities between power interfaces and network interfaces.
A network interface can be used in different modes, such as sending
or receiving on an attached line. A power interface (PI) has
an attribute indicating its mode that can be one of the following:
<vspace blankLines="1"/>
<list style="symbols">
<t>inlet: receiving power</t>
<t>outlet: providing power</t>
<!-- <t>attached: neither receiving nor providing power</t> -->
</list>
<!-- <vspace blankLines="1"/>
Attached mode is used by some kinds of power meters that do not
have inlets or outlets, but conduct measurements at an attached
power supply line. -->
<vspace blankLines="1"/>
Most power interfaces never change their mode, but as
the mode is simply a recognition of the current direction
of electricity flow, there is no barrier to a mode change.
<vspace blankLines="1"/>
A power interface can have capabilities for metering
power and other electric quantities at the shared power
transmission medium. This capability it modeled by an association
to a power meter.
<vspace blankLines="1"/>
In analogy to MAC addresses of network interfaces,
a globally unique identifier is assigned to each
power interface.
<vspace blankLines="1"/>
Physically, a power interface can be located at an AC power
socket, an AC power cord attached to a device, an 8P8C (RJ45)
PoE socket, etc.
</t>
</list></t>
<t><list style="symbols">
<t>Powered Entity (PE)<vspace/>
An entity which consumes or supplies power
with one or more PIs in mode "inlet"
is called a powered entity (PE). This extends the term powered
device (PD) used in <xref target="IEEE-802.3af"/> and
<xref target="IEEE-802.3at"/> to cover not only entities that
are individual devices, but also entities that are just
components of devices.</t>
</list></t>
<t><list style="symbols">
<t>Power Source (PS)<vspace/>
An entity with one or more PIs in mode "outlet"
is called a power source (PS). This
extends the term Power Source Equipment (PSE) used in the
IEEE PoE standards <xref target="IEEE-802.3af"/> and
<xref target="IEEE-802.3at"/> where at a single PI the PSE
provides power to a single PD only. Here a PS may supply an
arbitrary number of PEs at a single PI. Most
PSs have also PIs in mode "inlet" and all are also a PE.</t>
</list></t>
<t><list style="symbols">
<t>Power Meter (PM)<vspace/>
A metering function attached to a power interface of an
entity is called a power meter (PM). Power meters are
contained within an entity and attached to one or more of the
entity's power interfaces. A single PM can only provide a
single meter reading at a time. Most PIs will be connected
to a single other PI only, but those attached to multiple
power interfaces only measure the aggregate use over all of the
other interfaces.
Components that lack interfaces have a meter for their total
net consumption.</t>
</list></t>
</section>
<section anchor="psu-topology" title="Power Supply Topology">
<t>Similar to network interfaces, power interfaces can be connected
to each other via a shared (power) transmission medium. The most simple
connection is a single outlet connected to a single inlet as shown
in <xref target="fig-psu-simple"/>.</t>
<figure anchor="fig-psu-simple"
title="Simple one-to-one power supply topology">
<artwork><![CDATA[
+----------------+ +----------------+
| power source | | powered entity |
| +----------+ | | +----------+ |
| | PI, ID 1 ########## PI, ID 2 | |
| | (outlet) | | | | (inlet, | |
| | | | | | meter) | |
| +----------+ | | +----------+ |
+----------------+ +----------------+
]]></artwork>
</figure>
<t>This figure extends the PSU layer of <xref
target="fig-powersupply"/> by power interfaces.
The power source has a single power interface in outlet mode
connected to a power supply lime that connects it to the power
interface of the powered entity in inlet mode. The corresponding
PSU layer model of the topology in <xref target="fig-psu-simple"/>
is shown by <xref target="fig-psu-simple-model"/>.</t>
<figure anchor="fig-psu-simple-model"
title="PSU layer model for one-to-one supply topology">
<artwork><![CDATA[
PS ----- PI ID 1 ----- PI ID 2 ----- PE
outlet inlet
|
|
PM
]]></artwork>
</figure>
<t>This model shows four relationships,
<list style ="symbols">
<t>a containment relationship modeling the power source PS
containing the power interface PI with ID 1,</t>
<t>a containment relationship modeling the powered entity PE
containing the power interface PI with ID 2,</t>
<t>a metering relationship between PI ID 2 and a power meter
PM.</t>
<t>a connection relation between PI ID 1 and PI ID 2.</t>
</list></t>
<t>Implicit in this model is a containment relationship between
the PE and the PM. It is implicit, because the PI ID 2 is
contained in the PE and the PI ID 2 has a metering relationship
with the PM.</t>
<t>The model also shows that PIs have an attribute indicating
the mode. In <xref target="fig-psu-simple-model"/> PI ID 1 is
in mode "outlet" and PI ID 2 is in mode "inlet".</t>
<t><xref target="fig-psu-multidev"/> extends the PSU layer of
the example from <xref target="fig-multiplesupplieddevices"/>
by power interfaces. A power source with a single outlet
supplies three powered entities.</t>
<figure anchor="fig-psu-multidev"
title="PSU Layer for a Single PS Supplying Multiple PEs.">
<artwork><![CDATA[
+----------------+ +------------------+
| power source | | powered entity I |
| +----------+ | | +----------+ |
| | PI, ID 3 ############## PI, ID 4 | |
| | (outlet) | | # | | (inlet) | |
| +----------+ | # | +----------+ |----+
+----------------+ # +------------------+ II |
# | +----------+ |
########## PI, ID 5 | |
# | | (inlet) | |
# | +----------+ |-----+
# +---------------------+ III |
# | +----------+ |
########## PI, ID 6 | |
| | (inlet) | |
| +----------+ |
+-------------------------+
]]></artwork>
</figure>
<t>The corresponding PSU layer data model is shown by <xref
target="fig-psu-multidev-model"/>.</t>
<figure anchor="fig-psu-multidev-model"
title="PSU Layer Model of a Single PS Supplying Multiple PEs.">
<artwork><![CDATA[
PS ----- PI ID 3 --+-- PI ID 4 ----- PE I
outlet | inlet
|
+-- PI ID 5 ----- PE II
| inlet
|
+-- PI ID 6 ----- PE III
inlet
]]></artwork>
</figure>
<t><xref target="fig-psu-multiplesupplies"/> shows the PSU layer
model of the example from <xref target="fig-multiplesupplieddevices"/>.
A PE with three inlets is supplied by two power sources PS I and
PS II. There are two power supply connections between PS I and the
PE.</t>
<figure anchor="fig-psu-multiplesupplies"
title="Multiple Power Supply for Single Powered Device">
<artwork><![CDATA[
PS I --+-- PI ID 7 ----- PI ID 8 --+-- PE
| outlet inlet |
| |
+-- PI ID 9 ----- PI ID 10 --+
outlet inlet |
|
PS II ----- PI ID 11 ----- PI ID 12 --+
outlet inlet
]]></artwork>
</figure>
</section>
<section anchor="psu-powersources" title="Power Sources">
<t>In the PSU layer, a EO that is a power supply can be seen
as having two roles in that it is also a PE.
A good example is a PoE
switch that is a PE supplied with AC power and a PS supplying
other PEs with DC power. Examples which are pure AC devices
include a UPS or a PDU.</t>
<figure anchor="fig-psu-ps" title="Power Source Roles">
<artwork><![CDATA[
+--------------------------------------------------------+
| powered entity / power source |
| +---------+ +---------+ +---------+ +---------+ |
###### PI ID 13| | PI ID 14| | PI ID 15| | PI ID 16| |
| | (inlet) | | (outlet)| | (outlet)| | (outlet)| |
| +---------+ +----#----+ +----#----+ +----#----+ |
+----------------------#------------#------------#-------+
# # #
]]></artwork>
</figure>
<t><xref target="fig-psu-ps"/> shows the example a power source
with three power outlets and a power inlet and <xref
target="fig-psu-ps-model"/> shows its PSU layer information model.</t>
<figure anchor="fig-psu-ps-model"
title="PSU Layer Model of a Dual Role Power Source">
<artwork><![CDATA[
EO -------+------------+------------+------------+
PE | | | |
PS PI ID 13 PI ID 14 PI ID 15 PI ID 16
inlet outlet outlet outlet
]]></artwork>
</figure>
</section>
<section anchor="psu-metering" title="Power Meters">
<t>On the PSU layer each power and energy meter is integrated
with one or more power interfaces, though usually just with one,
or with a component.
A common case is shown by
Figures <xref format="counter" target="fig-psu-simple"/> and
<xref format="counter" target="fig-psu-simple-model"/> where
the PE has metering capability at its power inlet.
Power outlets can have metering capabilities as well.</t>
<t>When power meters are attached to more than one power
interface within a single powered entity, the
PM cannot report per power interface individually, but just
the summed of multiple interfaces.
A common example is a PoE switch that measures power per
group of eight ports. Another example
is a powered entity with two power inlets that only
measures the total power input to the entity as illustrated by
<xref target="fig-psu-dual-meter"/> and modeled by
<xref target="fig-psu-dual-meter-model"/>.</t>
<figure anchor="fig-psu-dual-meter" title="Dual power supply topology">
<artwork><![CDATA[
+--------------+ +--------------+
| power | +--------------------------+ | power |
| source 1 | | powered entity | | source 2 |
| +---------+ | | +---------+ +---------+ | | +---------+ |
| | PI ID 17########## PI ID 18| | PI ID 19########## PI ID 20| |
| | (outlet)| | | | (inlet) | | (inlet) | | | | (outlet)| |
| +---------+ | | +----#----+ +----#----+ | | +---------+ |
+--------------+ | # # | +--------------+
| +----#------------#----+ |
| | power meter | |
| +----------------------+ |
+--------------------------+
]]></artwork>
</figure>
<figure anchor="fig-psu-dual-meter-model"
title="PSU Layer Model of a Dual Role Power Source">
<artwork><![CDATA[
PS I ----- PI ID 17 ----- PI ID 18 --+-- PE
outlet inlet |
| |
| |
PM |
| |
| |
PS II ----- PI ID 19 ----- PI ID 20 --+
]]></artwork>
</figure>
<t>A power meter can cover any mixture of inlets and outlets
and simply reports the sum. As an example, see
the model of a the dual role PE and PS from <xref
target="fig-psu-ps-model"/> extended by a power meter
attached to all PIs in <xref target="fig-psu-ps-meter-model"/>.</t>
<figure anchor="fig-psu-ps-meter-model"
title="PSU Layer Model of a Dual Role Power Source">
<artwork><![CDATA[
EO -------+------------+------------+------------+
PE | | | |
PS PI ID 13 PI ID 14 PI ID 15 PI ID 16
inlet outlet outlet outlet
| | | |
+------------+------------+------------+----- PM
]]></artwork>
</figure>
</section>
<section title="External Power Meters">
<t>A device which is only a power meter is modeled exactly as
any other PS.
It is modeled as a device that
has an inlet power interface receiving power from a PS and
one or more outlet power interfaces providing power to PEs,
see, for example, <xref target="fig-psu-pm"/>.
The fact that a device may consume none of the energy that
passes through it is not relevant to EMAN.</t>
<figure anchor="fig-psu-pm"
title="External Power Meter">
<artwork><![CDATA[
+------------------------------+
| external power meter |
| +---------+ +---------+ |
from PS ###### PI ID 21| | PI ID 22###### to PE(s)
| | (inlet) | | (outlet,| |
| | | | meter) | |
| +---------+ +---------+ |
+------------------------------+
]]></artwork>
</figure>
</section>
<section anchor="psu-relationships"
title="PSU Layer Relationships">
<t>The PSU topology is usually asymmetric. PS devices supply other
PEs with power and meters may measure power that is consumed
or provided by other entities than the one at which the
measurement was conducted. This way we define two kinds of
relationships between EOs in the PSU layer: power source
relationships and power meter relationships</t>
<section title="Power Source Relationship">
<t>A power source relationship exists between an outlet PI
of a PS and an inlet PI of a PE. It is an asymmetric
relationship. The role of the outlet is providing energy
and the role of the inlet is receiving energy.</t>
<t>An outlet can be directly connected to multiple inlets and
thus can have multiple power source relationships. An inlet
is typically connected to a single outlets only and thus has
only one power source relationship to a directly connected
outlet.
While not common, an inlet can be connected to multiple outlets.</t>
<t>The relationship is transitive. If an outlet PI
acts as power source for an inlet PI of an entity that itself
acts as PS for further PEs, then the outlet may have also
power source relationships to inlets of entities supplied by
the entity in the middle.</t>
<t><xref target="fig-psu-relations"/> shows a simple example.
PI ID 23 has a power source relationship with PI Id 24.
But since the entity in the middle is a dual role device that
also acts as PS, PI ID 23 has also a power source relationship
with PI ID 26.</t>
<figure anchor="fig-psu-relations"
title="Relationships between Cascaded Power Sources">
<artwork><![CDATA[
PS 1 PE 1 / PS 2 PE 2
| | |
| +-----+------+ |
| | | |
PI ID 23 ----- PI ID 24 PI ID 25 ----- PI ID 26
outlet inlet outlet inlet
| |
PM PM
]]></artwork>
</figure>
</section>
<section title="Power Meter Relationship">
<t>The power meter relationship is very similar to the
power source relationship. It is asymmetric as well and it
has two roles: the metering PI and the metered PI. Different
from the power source relationship, the role of a PI does not
depend on its mode. The metering PI can be an outlet PI or
an inlet PI. The same holds for the metering PI. Thus this
relationship works not just downstream but also upstream.</t>
<t>In <xref target="fig-psu-relations"/> PI ID 23 has a metering
relationship as metering PI with PI ID 24 in the downstream
direction. In the same way, PI ID 26 is the metering PI in
a metering relationship with PI ID 25. Assuming that PE 1 /
PS 2 is just a switch with no energy consumption, PI ID 23 and
PI ID 26 have two metering relationship with each other with
different directions. In one PI IS 23 measures power remotely
for PI ID 26 and in the other one measured value at PI ID 26
can be used to report the power at PI ID 23.</t>
</section>
</section>
<section anchor="informationmodel"
title="PSU Layer Information Model">
<t><xref target="fig-psu-im"/> illustrates the information model
of the PSU layer. Electrical objects (EOs) are a synony for powered entity.</t>
<figure anchor="fig-psu-im"
title="Basic Information Model of the PSU Layer">
<artwork><![CDATA[
+--------------------+ 1 +-----------+ 1..N +-------+
+->| electrical |--------| power |--------| power |
| | object | 0..N | interface | 0..N | meter |
| +--------------------+ +-----------+ +-------+
| | ID |
| +--------------------+ | mode |
+--| powered entity | +-----------+
+--------------------+ 0..N | | 0..N
+---+
]]></artwork>
</figure>
<t>Each EO contains a number of PIs. PIs have two attributes,
their ID and their mode. Each PI may be attached to one or
more PMs. A PM may be attached to one or more PIs. Finally,
a PI may be connected to one or more PIs of other EOs.</t>
</section>
</section>
<section anchor="lmi-layer"
title="Local Energy Management Interface (LMI) Layer">
<t>The local energy management interface (LMI) layer provides a
set of interfaces for monitoring and controlling power and
use of energy at EOs. These interfaces are offered by an EO and
restricted to only report and control properties and states
that are local to the EO, as do most of the common network
management interfaces at managed entities today.</t>
<t>Interfaces at this layer deal components of the PSU layer
at the local EO. They are structured into five specific interfaces:</t>
<figure anchor="fig-lmi-interfaces"
title="Interfaces of an EO at the LMI layer">
<artwork><![CDATA[
^ ^ ^ ^ ^
| | | | |
+------------------------------------------------------------------+
| EO | | | | | |
| v v v v v |
| +----------+ +----------+ +----------+ +----------+ +----------+ |
| | PI | | PI | | meter | | power | | power | |
| |monitoring| | control | | reading | | state | | state | |
| | | | | | | |monitoring| | control | |
| +----------+ +----------+ +----------+ +----------+ +----------+ |
+------------------------------------------------------------------+
]]></artwork>
</figure>
<t><list style="symbols">
<t>PI monitoring<vspace/>
This interfaces provide methods for retrieving information on
PIs contained in the EO. Particularly included is information
on the mode of the PI (inlet or outlet) and its operational
state (on, off, ready, etc.) and known power source relationships and
power meter relationships.</t>
</list></t>
<t><list style="symbols">
<t>PI control<vspace/>
PI control is limited to switching PIs on and off.</t>
</list></t>
<t><list style="symbols">
<t>Meter reading<vspace/>
This interfaces includes methods for reporting quantities
that are measured by power meters and that are related to
power and to energy consumption.</t>
</list></t>
<t><list style="symbols">
<t>Power state monitoring<vspace/>
Methods of this interface provide information on power states
of PEs. These methods are only available at PEs. But since
all EOs can be considered to be PEs they can in general be
made available at any EO.</t>
</list></t>
<t><list style="symbols">
<t>Power state control<vspace/>
The number of control methods at this interface may be very
small. At least included is a method for setting the power
state of a PE.</t>
</list></t>
</section>
<section anchor="emm-layer"
title="Energy Management Mediation (EMM) Layer">
<t>Information and control means provided by the LMI layer
is local to the reporting EO. However, with information from the
PSU layer, there are some obvious steps of processing this
information to make it more useful or easier to digest by an
energy management system. In general, all functions in this
layer are 'convenience' functions and an energy management
system can execute all of them directly.</t>
<t>This layer may contain various kinds of functions. The ones
that are already known can be structured into 7 groups:</t>
<t><list style="symbols">
<t>remote PE information</t>
<t>remote PE control</t>
<t>all available information on a PE</t>
<t>all available control affecting a PE</t>
<t>aggregated information from multiple PEs</t>
<t>aggregated control of multiple PEs</t>
<t>proxying for an EO</t>
</list></t>
<t>This list may not be complete, so that new 'convenience'
functions may be added. Some of them may not
match any of the groups listed above. <xref target="fig-emm"/>
shows (except for the proxying functions) how the groups are
structured in the EMM layer and interact with the LMI layer.</t>
<figure anchor="fig-emm" title="Groups of Functions in the LMI layer">
<artwork><![CDATA[
+---------------------------------------------------------------+
| energy management system |
+---------------------------------------------------------------+
^ ^ ^ ^ ^ ^ ^
| | | | | | |
v | | | | | v
+------------------+ | | | | | +------------------+
| aggregated | | | | | | | aggregated |
| info on | | | | | | | control of |
| multiple PEs | | | | | | | multiple PEs |
+------------------+ | | | | | +------------------+
| | | | | | | | | | |
| | v v | | | v v | |
| | +-------------+ | | | +-------------+ | |
| | | all info | | | | | all control | | |
| | | on a PE | | | | | of a PE | | |
| | +-------------+ | | | +-------------+ | |
| | | | | | | | | | |
| +---------+ | | | | | +---------+ |
| | v v v | v v v | |
| | +-------------+ | +-------------+ | |
| | | remote PE | | | remote PE | | |
| | | information | | | control | | |
| | +-------------+ | +-------------+ | |
| | | | | | |
v v v v v v v
+----------------------------------------------------------------+
| LMI layer |
+----------------------------------------------------------------+
]]></artwork>
</figure>
<t>In this layer, EOs offer functions to the EnMS that concern
other PEs. By doing so, they establish a relationship to the
respective PEs. Relationships on this layer include</t>
<t><list style="symbols">
<t>Reporting relationship<vspace/>
This relationship is between a reporting EO and a PE on which
it reports. It is an asymmetric relationship and the PE on
which is reported may not even have any knowledge on the
existence of the relationship. Subject of reporting can be
the power supply status for PE, metered values for a
PE, a power state information on a PE, and other information
on the PE that is relevant for the energy management system.
</t>
<t>Control relationship<vspace/>
Analogous to the reporting relationship, the control
relationship is between a controlling EO and a controlled
PE. Again, the PE does not necessary know of this relationship,
for example, in case the controlling EO controls the power
supply of a PE by communicating with the PS supplying the PE.
This can be done in a way that is completely hidden from the PE.
Subject of control can be the power supply of the PE, its
power state, and other states relevant for the energy
management system.</t>
<t>Proxy relationship<vspace/>
This is a relationship between a proxying EO and a proxied PE.
The concept of a proxy relationship overlaps with the reporting
relationship and the control relationship. A proxy relationship
always includes one of the two or both. Characteristic for a
proxy relationship is that it includes reporting or control
function that the proxying EO cannot conduct without remotely
retrieving data or remotely controlling other EOs.</t>
</list></t>
<t>The groups of the EMM layer are described individually in
the following subsections.</t>
<section title="Remote PE Information">
<t>This group contains functions that allow an EO to provide
information about another PE. These functions are useful in
scenarios like the ones described in Section <xref
format="counter" target ="powersupply"/> where an EO switches
or measures power at an outlet PI. If the EO has information
on the PSU layer topology, particularly about which PEs are
connected to the outlet, then it can combine this information
and report on the power supply for the connected PEs.</t>
<t>This way an EO uses local information and deduces information
on other, remote PEs from it. Such information may not be
as reliable as a direct report from the concerned PEs, but it
is often valuable information for energy management.
Such reporting must be cognizant of possibilities like devices
with multiple power supplies.</t>
<t>The functions in this group can also be implemented by EOs
that are neither one of the concerned PEs nor the EO at which
the observation or measurement was conducted. In such a case
the executing EOs of these functions act as a kind of mid-level
manager between management system and managed devices and
could, for example, be components of an conventional element
management system.</t>
<t>Obviously, the EO that reports on a certain other PE has
a reporting relationship to the PE. However, if the PE is aware
of the relationship, the PE may have means to report which
EO has which kind of relationship to it.</t>
<t>Like some other functions on the EMM layer, the remote PE
functions are 'convenience' functions. Inferring available
information from different EOs can also be done by the energy
management system.</t>
</section>
<section title="Remote PE Control">
<t>This group has some similarities to the previous one.
Again, operations at an EO are combined with knowledge of the
PSU layer topology in order to realize operations on a remote
PE. In the example scenario from figures <xref format="counter"
target="fig-psu-simple"/> and <xref format="counter"
target="fig-psu-simple-model"/>, power for the PE can be
switching by switching the outlet PI ID 1 of the PS.
On the LMI layer the offered function would be "switch of PI
ID 1 at PS". This function can be offered by the PS at the
EMM layer as "switch power for the PE". Both function would
have the same technical effect, but they are semantically on
different layers.</t>
<t>Here, the EO that controls an PE has a control relationship
to the PE. If the PE is aware of the relationship, the PE may
have means to report which EO has which kind of relationship
to it.</t>
<t>Again, like in the previous group, these functions are
convenience functions and they can be executed by the PS, by the
PE or by any other EO.</t>
</section>
<section title="Parent function: All Available Information on a PE">
<t>This group provides just a single logical function that
we call the parent function for reporting: A parent EO makes
all information on a PE, that is available somewhere in the
network, but that might be distributed among several EOs,
available at a single point of contact, the parent.</t>
<t>Realizing such a function would be expected to require
to instantiate several of the functions in the "Remote PE
Information" group described above.</t>
<t>The parent EO that provides all available information on
a certain other PE has definitely a reporting relationship to it.
In addition it may have a proxying relationship, for example
if it reports the PE's power state.</t>
<t>This function is again a 'convenience' function for an energy
management system that in some cases may be much easier done
locally at involved EOs than within the energy management
system.</t>
</section>
<section title="All Available Control Affecting a PE">
<t>This group also provides just a single logical function:
The parent control function: It makes all control functions
affecting a PE, that are available somewhere in the network,
but that might be distributed among several EOs, available
at a single point of contact, the parent.</t>
<t>Realizing such a function would be expected to require
to instantiate several of the functions in the "Remote PE
Control" group described above.</t>
<t>Again, the parent EO that controls a certain other PE has
a control relationship to it. If controls the
power state, it may also be a proxy relationship.</t>
<t>This function is again a 'convenience' function for an energy
management system that in some cases may be much easier done
locally at involved EOs than within the energy management
system.</t>
</section>
<section title="Aggregated Information from Multiple PEs">
<t>Functions in this group aggregate monitoring information
from multiple PEs into more compact representations with
potential loss of information.</t>
<t>For example, power measurements from a set of PEs may be
summed up into a single value that is provided to an energy
management system that does not need more detailed information.
aggregating such information in the EMM layer is not just a
convenience functions but may also increase scalability of the
energy management system.</t>
<t>Aggregation is not necessarily limited to just summing
up values. Also included, for example, are aggregation
functions that give information on how many PEs of a group
are in a certain power state. The range of potential functions
in this group appears to be huge. However, it will probably
sufficient to standardize the most commonly used ones only.</t>
</section>
<section title="Aggregated Control of Multiple PEs">
<t>Like monitoring and reporting functions covered in the
previous group, also control functions can be aggregated.
Examples include switching power supply for all PEs in a
given group or setting all of them to the same power state
with a single command.</t>
<t>Again, this can be considered a convenience function, but
at the same time increase scalability of the energy management
system. And again it will probably be sufficient to standardize
just a few of the wide range of possible functions in this
group.</t>
</section>
<section title="Proxying for an EO">
<t>This section still needs to be written. Summary: An EO can act as a
proxy for an EO that cannot directly communicate with
the energy management system.</t>
</section>
</section>
<section anchor="EnMS-layer"
title="Energy Management System Interface (EnMS) Layer">
<t>
The EMS receives EMAN data directly from devices, or via the mediation
layer. Similarly, it can exercise control directly or via the mediation
layer. In many cases, the same action can be accomplished through
either means, though some are only available via mediation.
</t>
</section>
</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>
<section title="Acknowledgements">
<t>This memo was inspired by discussions with Benoit Claise,
John Parello, Mouli Chandramouli, Rolf Winter, Thomas Dietz,
Bill Mielke, and Chris Verges.</t>
</section>
<section title="Open Issues">
<section title="Devices or entities?">
<t>Entities expands on the category of devices by adding components.
Do components have all the features of devices (including having
power interfaces) or do they only have metering of their
energy/power use? The relationships among powered devices,
powered entities, components, and electrical objects needs to be clarified.</t>
</section>
<section title="Add PM monitoring and control interfaces to LMI layer?">
<t>In earlier versions of this draft, monitoring and configuring
the power meter have also been considered. Shall we list them
as further local interfaces on the LMI layer?</t>
</section>
<section title="Topology changes">
<t>Ideally topology would never change so the EMS need only
query it once. A date/time stamp for time of last
topology change would enable the EMS to know when it needs to
rescan the topology.</t>
</section>
<section title="Topology reporting">
<t>For each interface, there is a list of [device,interface]
tuples that is connected to the interface. If one of these
is listed as "unknown", then any number of unknown
devices may be connected (that is, the device need not
specify the number, since likely it will usually not know).
Topology information need not be symmetric. A device
providing power to the second may know the ID of the
second while the second device may lack knowledge of the ID of the supplying device.
The mediation layer brings together such information to form a more
complete picture.</t>
</section>
<section title="Proxying">
<t>Does all proxying occur at the mediation layer?</t>
</section>
<section title="PSU Info Model">
<t>The PSU layer information model needs to be further elaborated.</t>
</section>
</section>
</middle>
<back>
<references title="Informative References">
&rfc2578;
&rfc6020;
&id.draft-ietf-eman-framework;
<reference anchor="IEEE-802.3af">
<front>
<title>IEEE Std 802.3af-2003 - IEEE Standard for Information
technology - Telecommunications and information exchange
between systems - Local and metropolitan area networks -
Specific requirements - Part 3: Carrier Sense Multiple
Access with Collision Detection (CSMA/CD) Access Method
and Physical Layer Specifications - Amendment: Data Terminal
Equipment (DTE) - Power via Media Dependent Interface (MDI)</title>
<author initials="" surname="IEEE 802.3 Working Group"
fullname="IEEE 802.3 Working Group"></author>
<date year="2003" month="July" />
</front>
</reference>
<reference anchor="IEEE-802.3at">
<front>
<title>IEEE Std 802.3at-2009 - IEEE Standard for Information
technology - Telecommunications and information exchange
between systems - Local and metropolitan area networks -
Specific requirements - Part 3: Carrier Sense Multiple
Access with Collision Detection (CSMA/CD) Access Method
and Physical Layer Specifications - Amendment: Data Terminal
Equipment (DTE) - Power via Media Dependent Interface (MDI)
Enhancements</title>
<author initials="" surname="IEEE 802.3 Working Group"
fullname="IEEE 802.3 Working Group"></author>
<date year="2009" month="October" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:28:49 |