Subject: [eman] modeling power states

From: Juergen Quittek <[email-masked]>
Date: Mon, 28 Feb 2011 12:07:26 +0000

Dear all,

We have two proposals for a Power/Energy MIB module:

  - draft-claise-energy-monitoring-mib-06
  - draft-quittek-power-mib-02

Among the authors of both documents we are currently trying to merge them.
But there are some open issues that should be discussed on the mailing
list.  Here is the probably biggest of them: modeling power states.

For simplifying energy management we want to introduce the concept of
power states (aka power levels).  A power state will indicate roughly how
much power a device consumes.  Examples for simple power states are off,
sleep, and operational states.

In the envisioned EMAN MIB modules, a power state is characterized by a
descriptive name and the device's expected power input in this state
(max/min/average).

Power states are not a new concept.  The DMTF has already defined a set of
power states and there is the Other standards bodies as the DMTF
(Distributed Management Task Force) and there  is the ACPI (Advanced
Configuration and Power Interface) for PC motherboards.  And there may be
more than these out there.  I listed some DMTF and ACPI states at the end
of this message.

An easy solution for EMAN would be just adopting one of these sets.
However, there are issues with the ones we looked at.  ACPI was developed
for PC motherboards and is quite PC-centric.  Also it defines states that
seem to be superfluous, because so far, almost no one has implemented
them.  Also the DMTF model seems to have a narrower scope than envisioned
by the EMAN WG.

At some point in time, the EMAN WG hast to make a decision, which power
state model to adopt.  Here is a set of alternatives. The first four have
fixed sets of power states.

Option 1: fixed minimum
Just support three power states (off, sleep (stand-by), operational)
This has clear semantics, but there are several people claiming it's too
restrictive.

Option 2: fixed DMTF
Just use the states defined by DMTF.
Might be too much focussed n PCs.

Option 3: fixed ACPI
Just use the states defined by ACPI.
Might be too much focussed n PCs.

Option 4: fixed EMAN
Define a new fixed set of power levels within the EMAN WG.

Option 5: IANA-registered power states
Have power states be registered at IANA.
We would start with registering (off, sleep, operational, the DMTF set,
and the ACPI set.
Manufacturers can then register further ones.

There has been discussions pointing out that these fixed sets may not be
sufficient, particularly if non-IT equipment should also be covered.

For being more open, the idea to support user-defined or
manufacturer-defined power states of devices has been developed.  In such
a state, for example, certain components of a device may be switched off
or put to sleep.  Which ones are switched off in which state is to be
defined by the user/operator/manufacturer and may be chosen such that
operational needs are met.

Again, there are several proposals how to do this.  All of them favor a
two-level approach that distinguishes between rather flexible functional
power states and rather fixed basic power states.  Functional power states
would be defined by the manufacturer, operator, or user.  These would be
the power states that would be reported by a device.  However, in order to
better define the semantics of functional power states, Each of these
would be mapped to exactly one basic power states.  This means that a
property of any functional state would be the basic state it maps to.
Basic power states would be fixed, such as the ones used in options 1-5.
An easy example would be functional power states defined by
user/operator/manufacturer with each state indicating whether it is an off
state, a sleep state or an operational state.

Here are the corresponding options:

Option 6: flexible functional states mapped to a fixed set of basic states
States could be defined flexibly.  But each state would indicate a basic
state to which it corresponds. Basic states could be either basic
(off/sleep/operational) or the DMTF set or the ACPI set

Option 7: flexible functional states mapped to a IANA registered set of
basic states
This is like Option 6, but basic states would be registered at IANA and
can be extended.  We would register all DMTF and ACPI states and probably
some more at IANA. Manufacturers could add more.

Option 8: IANA-registered sets of functional states, only three basic
states
The main reasoning behind this option is that is should always be clear
whether a power state is an off state, a sleep state, or an operational
state.  Therefore, only these three basic states are supported.  This
would be in line with an instance of Option 6.  However, this option has
an extension for the functional states.  It suggests that for customizing
devices in order to be compliant with given management systems, for
example a DMTF-based system, it should be possible to restrict functional
power states to a given set that is registered at IANA.  An example would
be the DMTF states.  We would register a flag at IANA that indicates we
are using DMTF states only.  This would signal the management application
that all power state IDs are in line with power state numbering as defined
by IANA.  Analogously, ACPI and further sets could be registered at IANA.
A fallback to Option 6 could be realized by registering a set number of 0
at IANA that does not impose any limit for functional states.

Obviously, there are more possible options.  If you think there is a
better one, please send it to this list.

I know this discussion is not easy, but we have to have it in order to
make the right decision in the EMAN WG.  Please take some time and think
about what you consider to be the best way to go.  And of course send
questions on the issue.

Thanks.

    Juergen

DMTF (Distributed Management Task Force) power states:
  - 2 (Power On)
  - 3 (Sleep - Light)
  - 4 (Sleep - Deep)
  - 5 (Power Cycle (Off Soft))
  - 6 (Power Off - Hard)
  - 7 (Hibernate)
  - 8 (Power Off - Soft)
  - 9 (Power Cycle (Off Hard))
  - 10 (Master Bus Reset)
  - 11 (Diagnostic Interrupt (NMI))
  - 12 (Power Off - Soft Graceful)
  - 13 (Power Off - Hard Graceful)
  - 14 (Master Bus Reset Graceful)
  - 15 (Power Cycle (Off - Soft Graceful))
  - 16 (Power Cycle (Off - Hard Graceful))

ACPI (Advanced Configuration and Power Interface Specification) power
states for PC motherboards:
  - G3-S5 (Off-Hard)
  - G2-S5 (Off-Soft)
  - G1-S4 (Hibernate)
  - G1-S3 (Sleep-Deep)
  - G1-S2 (Sleep-Light)
  - G1-S1 (Sleep-Light)
  - G0-S0-P5
  - G0-S0-P4
  - G0-S0-P3
  - G0-S0-P2
  - G0-S0-P2
  - G0-S0-P2

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 28 Feb 2011 09:22:44 -0800

Thanks Juergen for summarizing this. 

I think the stall we've seen on the proposals is directly related to not
converging on an agreement for power states and parent child
aggregation.

We've asked this question on the list before with no dialogue and our
conversations have come down to two differences

The proposal submitted, by verges, quittek, parello, claise are very
similar. The similarities are in data elements and only vary by
partitioning (ie class). The only differences exist in two items

1) Power states / Interfaces
2) Parent Child relationship (or aggregator as specified in references)

IMO any work in EMAN must contain the addition of an IETF power
interface as described in claise architecture (or some compromise as you
listed with IANA interfaces). It must also contain the addition of
parent/child/aggregator relationship for non SNMP energy management.

Without those two additions the work in this group can easily be covered
by two additions to existing SNMP objects. First would be adding energy
related fields (watts units or Kwh) to the sensor mib. The seconds would
be to add better the context information (see energy aware proposal)  to
the entity mib. A simple on/off/standby state already exists in oper
status.

So in short without an IETF EMAN set of power states / interfaces to
unify or map to the states from other orgs as you listed, *and* the
ability to monitor/aggregate non SNMP devices - the work here can easily
be absorbed into the sensor and entity mibs with minor additions.

The experience I've personally had with energy management and running
code with exactly these additions has shown that manufacturers can build
sophisticated energy management systems and devices for many different
network connected devices with a converged set of states and the parent
child relationship. 

Having run a program which adds these features I'm strongly in favor of
a solution that has a unified power interface and the concept of a
parent / child to allow for non-snmp management of power.

Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Monday, February 28, 2011 4:07 AM
To: eman mailing list
Subject: [eman] modeling power states

Dear all,

Among the authors of both documents we are currently trying to merge
them.
But there are some open issues that should be discussed on the mailing
list.  Here is the probably biggest of them: modeling power states.

For simplifying energy management we want to introduce the concept of
power states (aka power levels).  A power state will indicate roughly
how
much power a device consumes.  Examples for simple power states are off,
sleep, and operational states.

Power states are not a new concept.  The DMTF has already defined a set
of
power states and there is the Other standards bodies as the DMTF
(Distributed Management Task Force) and there  is the ACPI (Advanced
Configuration and Power Interface) for PC motherboards.  And there may
be
more than these out there.  I listed some DMTF and ACPI states at the
end
of this message.

An easy solution for EMAN would be just adopting one of these sets.
However, there are issues with the ones we looked at.  ACPI was
developed
for PC motherboards and is quite PC-centric.  Also it defines states
that
seem to be superfluous, because so far, almost no one has implemented
them.  Also the DMTF model seems to have a narrower scope than
envisioned
by the EMAN WG.

At some point in time, the EMAN WG hast to make a decision, which power
state model to adopt.  Here is a set of alternatives. The first four
have
fixed sets of power states.

Option 1: fixed minimum

Option 2: fixed DMTF

Option 3: fixed ACPI

Option 4: fixed EMAN

manufacturer-defined power states of devices has been developed.  In
such

Again, there are several proposals how to do this.  All of them favor a
two-level approach that distinguishes between rather flexible functional
power states and rather fixed basic power states.  Functional power
states
would be defined by the manufacturer, operator, or user.  These would be
the power states that would be reported by a device.  However, in order
to
better define the semantics of functional power states, Each of these
would be mapped to exactly one basic power states.  This means that a
property of any functional state would be the basic state it maps to.
Basic power states would be fixed, such as the ones used in options 1-5.
An easy example would be functional power states defined by
user/operator/manufacturer with each state indicating whether it is an
off
state, a sleep state or an operational state.

Option 6: flexible functional states mapped to a fixed set of basic
states
States could be defined flexibly.  But each state would indicate a basic
state to which it corresponds. Basic states could be either basic
(off/sleep/operational) or the DMTF set or the ACPI set

Option 7: flexible functional states mapped to a IANA registered set of
basic states
This is like Option 6, but basic states would be registered at IANA and
can be extended.  We would register all DMTF and ACPI states and
probably
some more at IANA. Manufacturers could add more.

Option 8: IANA-registered sets of functional states, only three basic
states
The main reasoning behind this option is that is should always be clear
whether a power state is an off state, a sleep state, or an operational
state.  Therefore, only these three basic states are supported.  This
would be in line with an instance of Option 6.  However, this option has
an extension for the functional states.  It suggests that for
customizing
devices in order to be compliant with given management systems, for
example a DMTF-based system, it should be possible to restrict
functional
power states to a given set that is registered at IANA.  An example
would
be the DMTF states.  We would register a flag at IANA that indicates we
are using DMTF states only.  This would signal the management
application
that all power state IDs are in line with power state numbering as
defined
by IANA.  Analogously, ACPI and further sets could be registered at
IANA.
A fallback to Option 6 could be realized by registering a set number of
0
at IANA that does not impose any limit for functional states.

Thanks.

    Juergen

_______________________________________________
eman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eman

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 28 Feb 2011 22:08:20 +0100

Hi John,

Thanks for your comments. Please find replies inline.

> parent/child/aggregator relationship for non SNMP energy management.

You say we MUST adopt the power states from the claise architecture 
and we MUST adopt the parent/child concept.

The reasons you give for this in the paragraphs below are
  - Otherwise we would not need an EMAN WG.
  - This helps manufacturers to build sophisticated energy management systems.

I would not accept the first one as a technical argument, 
On your second argument I would reply that providing good interfaces
for building sophisticated applications is certainly an objective 
of our work in EMAN, but probably not the one with top priority.

Thanks,

    Juergen

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 28 Feb 2011 15:54:43 -0800

Hi Juergen,

Thanks that's where we disagree :)

IMO it is a technical argument. Without adding an common interface for
devices *and*  the ability to manage devices attached to a communication
network you can achieve your goals with simple data models added to
sensor, entity and even UPS mib.

Interface vs implementation abstraction, retrieval, all partitioning of
data is a technical decision. It's not a business, time to market or
artistic argument.

I'll leave the debate to the rest of the group as you can see where my
opinion goes.

Looking forward to feedback!
Jp

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Monday, February 28, 2011 1:08 PM
To: John Parello (jparello)
Cc: eman mailing list
Subject: Re: [eman] modeling power states

Hi John,

The reasons you give for this in the paragraphs below are
  - Otherwise we would not need an EMAN WG.
  - This helps manufacturers to build sophisticated energy management
systems.

Thanks,

    Juergen

---

From: [email-masked]
Date: Mon, 28 Feb 2011 21:06:01 -0800

Hi John and Juergen,

> > be absorbed into the sensor and entity mibs with minor additions.

I disagree with the argument that ENTITY-MIB can be extended to support
power data properly.  ENTITY-MIB contains an inherent flaw, in that it
separates physical and logical entities into distinct buckets that
cannot overlap in sparse tables.

WHEN -- not if -- the IETF decides to provide a meter hook for logical
entities (individual programs, virtual machines on a shared server,
etc.), an EMAN schema based on ENTITY-MIB would have to be forked to
support this.  That duplication of effort is pointless.

And I say "when" because it's a matter of time.  Lots of people are
already working on this problem because there is a huge amount of money
involved:

   30-second internet search:
   http://research.microsoft.com/apps/pubs/default.aspx?id=120435

The IETF exists to enable others' innovation and interoperability in
those pursuits.  It is not our responsibility to debate the merits of
this undertaking.  It is, however, our duty to acknowledge this pursuit
and prepare to integrate it into schema.

So while it's good to make a nod to the predecessor ENTITY-MIB, I urge
us to make a structural break from it.

> of our work in EMAN, but probably not the one with top priority.

I agree with John's first point ("otherwise EMAN wouldn't exist") in the
light that, even though it may not yet be fully and properly
articulated, there is a sense that EMAN is needed because the existing
solution architecture just doesn't quite do what is needed.  I mean, why
does your MIB draft exist?  You see a problem and have tried to solve it
because a solution doesn't yet exist.

Here's a structural example to illustrate the point:

Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor types,
the data COULD be represented.  For a single intelligent power supply on
a server that monitors voltage, amperage, real power, apparent power,
power factor, and frequency, we'd have 6 entities enumerated in
ENTITY-MIB.  And all of this would need to be tied together logically
into a "Power Supply" concept, so that'd be another entity -- 7 in
total.

For a single server, sure, fine, do-able.  Tiny scale.

What about a 24-outlet PDU?  Or a 84-circuit panelboard?

	http://www.kondra.com/circuit/circuit.html

	Eaton Branch Circuit Monitoring Whitepaper:
	http://tinyurl.com/5rpmhrp

Managing 168 entities on a PDU or 588 entities on a panelboard is
a ridiculous burden on the user who is consuming the agent's data.

"Bonding" these entities that are a common purpose reduces the magnitude
by a factor of 7, and simplifies the conceptual use of the framework.
Users don't need to think in terms of "voltage sensor for Outlet 1" but
instead can refer to that same data as "Outlet 1's voltage."

Juergen, it seems like you're so busy focused on a conceptual model that
real-world usability may be getting sacrificed.  Each of your examples
only reflects a single entity at a time.  Why not kick up the examples a
notch and model something like an intelligent PDU with the following
properties?

   1. 24 outlets, single phase
   2. 6 banks (4 outlets per bank), single phase
   3. 2 inputs (3 banks per input), three phase
   4. "Ganged" outlets (multiple outlets that are managed as one
      construct)
   5. High current alerts, low current alerts, circuit breaker alerts,
      high voltage alerts (spikes), low voltage alerts (sags) -- all of
      which can be applied to a physical entity or a logical entity
      (like an outlet "gang")
   6. Internal network card and metering logic
   7. Outlets "owned" by different users (think co-location facility,
      "context")
   8. Manage power via 5 different interface modalities/mechanisms
   9. Except for the existence of the outlets/banks/inputs/"gangs", all
      other properties are potentially optional

I challenge you -- everyone participating in the EMAN list -- to model
this level of complexity.  If your MIB can withstand this, it's a good
MIB (IMO, of course).

Thanks,
Chris

---

From: Bruce Nordman <[email-masked]>
Date: Mon, 28 Feb 2011 22:52:45 -0800

Juergen has provided a good summary and comprehensive set of options.

I think several of the points he makes bear emphasis.
One is the distinction between (basic) power states,
and functionality differences within such states.
It is tempting to want to put all of this onto one linear
scale of states, and sometimes that works.  However,
many functionalities are essentially not on the same
dimension as the basic power state one, so do not
well match to it.  An example is battery charging, which
can occur in on, sleep, or off.

Another point is that going beyond a few basic states
inevitably makes the list specific to narrow groups of
products and/or to specific implementations, and so
is not universal.

With all this, not surprisingly I favor option 1, or 6-8,
with the latter ones recognizing this distinction between
power states and functional states.

For DMTF, this is a mixture of power states, and
transition states and/or commands, so I think not a
good source when we are just talking about power
states.

For ACPI, my understanding is that in practice, S1
and S2 are not used, so the number of actual
states is fewer than appears.

I do think that there may be a fourth basic state
of "Ready", which would apply more to appliances
than to electronic devices.

--Bruce

On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek <[email-masked]> wrote:

> list.  Here is the probably biggest of them: modeling power states........
>
>
-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943