Subject: [eman] Power States - really

From: Bruce Nordman <[email-masked]>
Date: Tue, 1 Mar 2011 16:54:12 -0800

I am reposting Juergen's email about power states.
While the subsequent discussion has been important
and useful, it is on a different topic.  So, please let's
also make progress on this topic.
--Bruce

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

> 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
>
>
>
>
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: "Chris Verges" <[email-masked]>
Date: Tue, 1 Mar 2011 17:53:20 -0800

Option 6: Support all of them.

Chris

-- 

Chris Verges

408-500-2377

http://www.cyberswitching.com <http://www.cyberswitching.com/> 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bruce Nordman
Sent: Tuesday, March 01, 2011 4:54 PM
To: eman mailing list
Subject: [eman] Power States - really

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

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

-- 
Bruce Nordman

---

From: "Chris Verges" <[email-masked]>
Date: Tue, 1 Mar 2011 17:55:08 -0800

Sorry, the "9" key apparently got put upside down on my keyboard.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Verges
Sent: Tuesday, March 01, 2011 5:53 PM
To: Bruce Nordman; eman mailing list
Subject: Re: [eman] Power States - really

Chris

-- 

Chris Verges

408-500-2377

Dear all,

Option 1: fixed minimum

Option 2: fixed DMTF

Option 3: fixed ACPI

Option 4: fixed EMAN

Thanks.

   Juergen

---

From: Ted Ghose <[email-masked]>
Date: Tue, 1 Mar 2011 17:57:23 -0800

To summarize: there are two existing power states ACPI & DMTF

As an administrator who wants to save energy, I'd like to know one set of
states, regardless of any device I manage. I do no not care if there is 5 or
100 states, so long I have a clear understanding what each state does for
me. Also it will be nice if the devices tells me what is the max power it
will consume at any given state, and if some functionality it may loose.
Better yet, how long will it expected to take for a state transition (may
not be a matrix, a linear delta t from state xi to xi+1)

Since we have two implementation specific power states, which does not give
enough information to plan ahead, I'd like to see this standard body comes
up with an unified states, that normalizes states across every devices. I
understand it is a tall order.

Hope the requirement will steer the discussion in the right path

thanks

-tg-

*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.
                     Save time... see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.

On Tue, Mar 1, 2011 at 4:54 PM, Bruce Nordman <[email-masked]> wrote:

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

---

From: Ted Ghose <[email-masked]>
Date: Tue, 1 Mar 2011 18:06:53 -0800

Chris,

I agree with you from implementation point of view, a flexible interface is
better, but from user experience managing 100s of heterogeneous devices, it
will be a nightmare. Instead if we have one set of states, and a mapping
what devices natively support will be best. I'll let everyone decide who
will be allowed to make the mapping, is it user read-write or read-only. Is
it manufacturer  read-write/user read-only?

thanks

-tg-

On Tue, Mar 1, 2011 at 5:55 PM, Chris Verges <[email-masked]>wrote:

> Sorry, the “9” key apparently got put upside down on my keyboard.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Chris Verges
> *Sent:* Tuesday, March 01, 2011 5:53 PM
> *To:* Bruce Nordman; eman mailing list
> *Subject:* Re: [eman] Power States - really
>
>
>
> http://www.cyberswitching.com
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Bruce Nordman
> *Sent:* Tuesday, March 01, 2011 4:54 PM
> *To:* eman mailing list
> *Subject:* [eman] Power States - really
>
>
>

---

From: "Chris Verges" <[email-masked]>
Date: Tue, 1 Mar 2011 18:22:12 -0800

Hi Ted,

I'm not understanding the drawback to having multiple, coordinated
interfaces.  You're saying that standards like ACPI and DMTF will have
to be mapped to this arbitrary state set created by EMAN, right?  So why
not just expose the ACPI and DMTF states natively and map them
internally in the agent/MIB?  It would provide for a better interface
for the users, and the state-to-behavior mapping is done by the
manufacturer anyway.  (Read-only to the user.)

Thanks,

Chris

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ted Ghose
Sent: Tuesday, March 01, 2011 6:07 PM
To: Chris Verges; eman mailing list
Subject: Re: [eman] Power States - really

Chris,

I agree with you from implementation point of view, a flexible interface
is better, but from user experience managing 100s of heterogeneous
devices, it will be a nightmare. Instead if we have one set of states,
and a mapping what devices natively support will be best. I'll let
everyone decide who will be allowed to make the mapping, is it user
read-write or read-only. Is it manufacturer  read-write/user read-only?

thanks

-tg-

On Tue, Mar 1, 2011 at 5:55 PM, Chris Verges <[email-masked]>
wrote:

Chris

-- 

Chris Verges

408-500-2377

Dear all,

Option 1: fixed minimum

Option 2: fixed DMTF

Option 3: fixed ACPI

Option 4: fixed EMAN

Thanks.

   Juergen

---

From: Bruce Nordman <[email-masked]>
Date: Tue, 1 Mar 2011 18:37:48 -0800

And below is my comment from yesterday to the original thread.

On Tue, Mar 1, 2011 at 4:54 PM, Bruce Nordman <[email-masked]> wrote:

> ...

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

---

From: Ted Ghose <[email-masked]>
Date: Tue, 1 Mar 2011 20:57:15 -0800

So long each state defines it behavior, and in a broad bucket of what is
expected of each state, individual devices behavior (battery vs coffee
machine: say state 1 for battery not charging drawing full power, while
coffee machine not drawing anything) in the respect of power drawn from the
utility will be good.

reverse should be hold good for solar panel which pumps power in.

I totally miss why we are declaring it hard and refuse to explore a solution
to get a linear mapping.

I'm not saying it will be easy but I'd like to find one linear mapping,
which will satisfy most of the devices, laying down some ground rules.

say, I define following rules:

Rule 1: device at low power state takes less power from utility power source
than at a higher state
Rule 2: device express their capability at a given state (may be % or some
measure)

(hypothetical example: a solar panel at lowest state might be 100% capable
producing most power, and sleeps at the highest; reverse for the coffee
machine.)

Now can we map PDUs, UPSs, Batteries, etc?

I'd propose here to come up with a set of rules w/ our objective in view,
and hence define our model!

Let us agree we are defining the MIB for the user and usability, and our
goal is to cover all the devices we could possible get to participate.

Thanks

-tg-

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Tue, 1 Mar 2011 23:06:20 -0600

The discussion of the past few days on the topic of power states has been quite interesting and I am happy to see some discussion on this important topic.  I have some thoughts to throw into the mix that I wish to share.  These are more on the level of general insights than on the level of a cooked proposal but I think that they may introduce some much needed outside the box thinking here.

The discussion thus far is focused on trying to pick a fixed set of enumerated states which are intended to properly and reasonably abstract all possible power savings capabilities which will be found in all existing and future equipment to which this standard will be applied.  While this is a noble goal I fear that it is unrealistically optimistic in its chances for success.  Both the DMTF and the ACPI options are far too PC-centric to be applicable to such a wide reaching goal.  Indeed, how well have these particular standards been adopted and implemented even within that very narrow domain?  I don't know the answer but I will be surprised if the answer is that they are widely adopted, implemented, and used as they were originally envisioned.  If you have anything to suggest otherwise please share it.

So this leads me to the conclusion that even if we were successful in achieving the goal of defining a single fixed set of enumerated states that everyone here is happy with that the chances for the success of such an approach are rather limited.  Note that I am not trying to throw water on the idea or efforts to make it happen, I am just trying to assess the reality of the situation based on my own understanding of the inherent complexities involved with large data and voice networking equipment.

As I pointed out in Beijing I think that the answer needs to be both more flexible and more extensible if it is going to actually be useful.  Here are some of the reasons I believe this to be true:

(1) We are discussing a widely disparate set of technologies which consumer power in widely disparate ways and therefore they will have widely disparate notions of how to actually provide meaningful features for implementing the inherently technology specific trade-offs between power savings and other key product characteristics in terms of things like capacity, throughput, availability, latency and response times, etc.

(2) I expect that in all but the most trivial of products these power savings "knobs" will be independently tunable, and they will need to be set by each product owner so as to meet their specific business requirements.

(3) To think that each product vendor will be able to make a reasonable mapping between N independently controlled features and a simple linear progression of states seems like wishful thinking to me.  "MAYBE" this could be done from a read only reporting perspective, but it will never work from a management and control perspective.  I just don't believe that the operational use cases for a multi-million dollar router or switch will ever boil down to some operator telling their router to go to "sleep" or to enter "power savings level 3".

Now, if we are to pursue the definition of a single set of fixed enumerated states then the level of abstraction needs to be exceedingly high to be able to cover the breadth of equipment we envision.  So I would agree with Bruce that if this is the direction the number of states needs to be absolutely high-level and generic which will also serve to reduce the number of such states.  So, for example, HighPerformance/PowerSavings/Off is about the best that you could do.  But I question the usefulness of having a large router reporting that it is in the PowerSavings state.  Sure, you know that some feature somewhere in the router is not running an maximum performance but that is about all.  It would be useless from a management perspective to tell such a router to enter it's PowerSavings state.  What would that actually mean?  What reasonable mapping could actually be done here?  And Off would not be useful from a reporting perspective because if it was off how would it respond?  Setting it to Off would be useful, I guess, but only in limited circumstances because once it was Off how would you transition it back to any of the other states?

Whether we have 3 states or 5 or 50 it won't really matter because this concept of a linear progression of states (e.g. from Off to PowerSavings to HighPerformance) is not the abstraction we should actually be pursuing IMHO.

I think that a more useful abstraction would be one of modeling independently controllable Capabilities.  I would seek to let each product enumerate its own set of such capabilities along with the type of values that each capability could take on.  By allowing the product to enumerate a set of supported Capabilities each piece of equipment could provide a meaningful set of options to the technicians or management applications.  As the product evolves from one release to the next the list of supported Capabilities can grow and evolve over time based on each vendors design choices and each product's inherent technological constraints.

So, without worrying about the SNMPisms involved (yet) this might only require a couple of tables to enumerate the required meta-data.  I am thinking of something along the following lines:

emanCapabilitiesDefinitionsTable
--------------------------------
1. <ProductSpecificCapabilityID #1> <CapabilityName #1> <CapabilityTypeSpecification>
2. <ProductSpecificCapabilityID #2> <CapabilityName #2> <CapabilityTypeSpecification>
...
N. <ProductSpecificCapabilityID #N> <CapabilityName #N> <CapabilityTypeSpecification>

This allows each product to enumerate a list of product specific capabilities which are supported.  These would be expected to be different from one vendor to another, and possible from one product release to the next.  This would allow the products to evolve over time without requiring any changes to the management interface (as long as there is no need to introduce new meta level attributes).

<CapabilityTypeSpecification> would be any of a small number of simple data types such as String or Integer or Float, or a product defined EnumeratedTypeID which could be discovered via a second table like the following:

emanEnumeratedTypeTable
-----------------------
1. <EnumerationID #1> <EnumerationName #1>
2. <EnumerationID #2> <EnumerationName #2>
...
M. <EnumerationID #M> <EnumerationName #M>

This table enables the product to defined a set of EnumerationTypeIDs which can be used in the emanCapabilitiesDefinitionsTable above as one of the CapabilityTypeSpecifications.  The actual values for each enumeration could be discovered as follows:

emanEnumeratedValuesTable
-------------------------
1. <EnumerationID #1> <ValueID #1> <ValueName #1>        +
2. <EnumerationID #1> <ValueID #2> <ValueName #2>        | List of Values for
...                                                      | EnumerationID #1
I. <EnumerationID #1> <ValueID #I> <ValueName #I>        +
I+1. <EnumerationID #2> <ValueID #I+1> <ValueName #I+1>  +
I+2. <EnumerationID #2> <ValueID #I+2> <ValueName #I+2>  | List of Values for
...                                                      | EnumerationID #2
I+J. <EnumerationID #2> <ValueID #I+J> <ValueName #I+J>  +
...

This table provides a product specific set of enumerated types which in turns defines the possible values that can be assigned as the current state for any of the corresponding capabilities.  Strings, Integers, Floats, and EnumeratedTypes would provide a fairly rich set of management data which is tuned to the specific capabilities of each managed element.

The actual values for the current settings of each of these Capabilities would have to be obtained via Get/Set on yet another table along the lines of:

emanProductCapabilities
-----------------------
1. <ProductSpecificCapabilityID #1> <CapabilityValue>
2. <ProductSpecificCapabilityID #2> <CapabilityValue>
...
N. <ProductSpecificCapabilityID #N> <CapabilityValue>

Where each capability value is constrained to be within an appropriate domain based on the CapabilityType associated with the corresponding ProductSpecificCapabilityID.

Now the thing that we loose with this is a fixed and well-defined set of semantics to go along with these product defined capabilities.  It is up to the operator (or the logic coded into a given management application) to understand the semantics of these settings for any given release of any given product.  I would argue that this is inevitable for any reasonably complex piece of equipment.  I would also argue that it is unrealistic to expect that we can devise some generic set of semantics which would be applicable to a wide range of products anyway.

Using the information from such tables a management application could "easily" support a user interface to display the current state of each of the N capabilities to a human operator.  Similarly, any management application which seeks to exert operational control over these capabilities is required to understand the semantics of each release of each product for it to implement meaningful controls.  In other words, either the operator or the logic coded into the management application must be responsible for understanding the semantics of setting the values no matter what we do at the standard level.  I think that this in inevitable.  For example, putting a desktop PC to "sleep" has a meaningful set of semantics for a desktop PC whereas putting a router or a hub to "sleep" has an entirely different set of product and/or technology specific semantics for that equipment.

At a sufficiently abstract level, yes we can say this means that the equipment is in some "low level power saving state" but this level of a statement is useless from a management perspective.  Either the operator or the management applicable are still required to understand what putting a specific piece of equipment to "sleep" means within the context of that piece of equipment and its roles and responsibilities within the overall organizational scheme.

At this point I am only throwing this out for your consideration and discussion.  We would still have to assess what this would mean within the context of SNMP and the other IETF MIBs.

Let me know if this is unclear as I wrote it up off the top of my head.  I will be happy to clarify anything that is unclear.  I am curious if there is any support for moving things in this direction or whether the group feels that the complexity outweighs the benefits (at least as I see them).

(See below for a simple concrete example.)

Thanks,

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked] <mailto:[email-masked]>
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

As a simple concrete exercise, a product that only supported the single fixed enumerated set of states that are discussed above might choose to expose the following:

emanCapabilitiesDefinitionsTable
--------------------------------
1. CapabilityID#1 "PowerState" EnumerationID#1

emanEnumeratedTypeTable
-----------------------
1. EnumerationID#1 "PowerStateEnumeration"

emanEnumeratedValuesTable
-------------------------
1. EnumerationID#1 ValueID#1 "Off"
2. EnumerationID#1 ValueID#2 "PowerSavings"
3. EnumerationID#3 ValueID#3 "HighPerformance"

emanProductCapabilities
-----------------------
1. CapabilityID#1 ValueID#2

Here we are seeing a case where the product supports a single capability, PowerState, which can be any of three possible values (i.e. Off, PowerSavings, and HighPerformance).  In this example the current state is PowerSavings.

________________________________

        From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce Nordman
        Sent: Tuesday, March 01, 2011 7:54 PM
        To: eman mailing list
        Subject: [eman] Power States - really

                Dear all,

                Option 1: fixed minimum

                Option 2: fixed DMTF

                Option 3: fixed ACPI

                Option 4: fixed EMAN

                Thanks.

                   Juergen

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 1 Mar 2011 21:37:41 -0800

I like the idea of capabilities if they provide introspection on the object/device in question. So I'd like to see that the capabilities are discoverable from the device itself.

Whether they are capabilities or states the point is to have a management interface on the device itself, not left as an exercise for the NMS' manufacturers.

One problem faced over the years with building NMS' (and will be the exasperated with EMS') is that the first thing you do in a presentation is to show the different devices (table, list topology) then provide an interface for commands.

For example if one capability is to sleep you provide that action to the user as a common polymorphoc command to every type of device that can do it. Then the NMS has the daunting job of translating that to the specific vendor capability for that model cross software version running on the device.

That needs to be discoverable by the NMS or a fixed set of interfaces.

So the challenge is to stop this madness and have the device understand there is an interface for management and let it encapsulate the details of how to do it. 

IMO this has been punted to the NMS' for so long it makes for unusable management. With energy and the upcoming IoT, the number of touch points will increase dramatically. If we are going to be managing the power of heterogeneous devices let the interface to  implementation abstraction live on the device not reinvented in every NMS system.

That way we have a universal way of managing power across devices.

The main objection I've heard so far is will it be enough, how will you know you have the right interface. Well running code and try it. 

We propose a solution for that with a fixed interface based on shipping products in an open community of manufacturers and E/NMS vendors. We now total 44 different companies working with such a model. So it's not that difficult to map to a simple interface.

I'm not opposed to having capabilities or other interfaces listed but they need to be discoverable.
Jp

Jp

-----Original Message-----
From: [email-masked] on behalf of Mielke, William F (Bill)
Sent: Tue 3/1/2011 9:06 PM
To: eman mailing list
Subject: Re: [eman] Power States - really

Now, if we are to pursue the definition of a single set of fixed enumerated states then the level of abstraction needs to be exceedingly high to be able to cover the breadth of equipment we envision.  So I would agree with Bruce that if this is the direction the number of states needs to be absolutely high-level and generic which will also serve to reduce the number of such states.  So, for example, HighPerformance/PowerSavings/Off is about the best that you could do.  But I question the usefulness of having a large router reporting that it is in the PowerSavings state.  Sure, you know that some feature somewhere in the router is not running an maximum performance but that is about all.  It would be useless from a management perspective to tell such a router to enter it's PowerSavings state.  What would that actually mean?  What reasonable mapping could actually be done here?  And Off would not be useful from a reporting perspective because if it was off how would it respond?
   Setting it to Off would be useful, I guess, but only in limited circumstances because once it was Off how would you transition it back to any of the other states?

emanEnumeratedTypeTable
-----------------------

emanProductCapabilities
-----------------------

Thanks,

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

emanEnumeratedTypeTable
-----------------------

emanProductCapabilities
-----------------------

                Dear all,

                Option 1: fixed minimum

                Option 2: fixed DMTF

                Option 3: fixed ACPI

                Option 4: fixed EMAN

                Thanks.

                   Juergen

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Tue, 1 Mar 2011 23:51:34 -0600

# Bruce Nordman wrote:
#
# 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.  

I think that this is an argument that mirrors my own to some level for the need to support an approach that goes beyond a single linear list of states.

Your battery charging example is a good one, actually, as it would appear to be a pure read only state without any control aspects to it.  Does this imply there are actually two general types of power states?  One that is for monitoring only and one that is used to effect controls (e.g. like setting something to the "Sleep" state)?  I think that there is an important nuance here that needs to be better understood and teased out.

# 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.

Agreed.  To be universal the level of abstraction needs to be raised so high that the result is useless from a management perspective.  IMHO, of course.

I think you are also recognizing the point that I was making that the mapping from these states to implementation semantics is both technology and vendor aligned.  I don't think that we can define a large number of states that will have some universal applicability.

# 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.

As I said in my previous email I don't think that either the DMTF or the ACPI sets are suitable to our purpose.  So from my perspective if we go the route of a single fixed linear set, then I too favor Option 1 from Juergen's list.  I am not pushing for any specific set of states just that they be defined at a high level of abstraction so something like a ready state would be OK if we take this route.

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

---

From: Ted Ghose <[email-masked]>
Date: Wed, 2 Mar 2011 00:39:42 -0800

I'm dismayed that you failed to define a fine set of rule, and without that
you are putting your model forward.

the elegant this model is, I fail to to understand what are the rule does it
stick to. Coming from a pure mathematics world, I'd like to define the "set"
before "set operations"

If we fail to define the rule, i totally agree with you that "the chances
for the success of such an approach are rather limited"

Are we not putting the cart before the horse?

thanks

-tg-

On Tue, Mar 1, 2011 at 9:06 PM, Mielke, William F (Bill) <
[email-masked]> wrote:

> The discussion of the past few days on the topic of power states has been
> quite interesting and I am happy to see some discussion on this important
> topic.  I have some thoughts to throw into the mix that I wish to share.
>  These are more on the level of general insights than on the level of a
> cooked proposal but I think that they may introduce some much needed outside
> the box thinking here.
>
> The discussion thus far is focused on trying to pick a fixed set of
> enumerated states which are intended to properly and reasonably abstract all
> possible power savings capabilities which will be found in all existing and
> future equipment to which this standard will be applied.  While this is a
> noble goal I fear that it is unrealistically optimistic in its chances for
> success.  Both the DMTF and the ACPI options are far too PC-centric to be
> applicable to such a wide reaching goal.  Indeed, how well have these
> particular standards been adopted and implemented even within that very
> narrow domain?  I don't know the answer but I will be surprised if the
> answer is that they are widely adopted, implemented, and used as they were
> originally envisioned.  If you have anything to suggest otherwise please
> share it.
>
> So this leads me to the conclusion that even if we were successful in
> achieving the goal of defining a single fixed set of enumerated states that
> everyone here is happy with that the chances for the success of such an
> approach are rather limited.  Note that I am not trying to throw water on
> the idea or efforts to make it happen, I am just trying to assess the
> reality of the situation based on my own understanding of the inherent
> complexities involved with large data and voice networking equipment.
>
> As I pointed out in Beijing I think that the answer needs to be both more
> flexible and more extensible if it is going to actually be useful.  Here are
> some of the reasons I believe this to be true:
>
> (1) We are discussing a widely disparate set of technologies which consumer
> power in widely disparate ways and therefore they will have widely disparate
> notions of how to actually provide meaningful features for implementing the
> inherently technology specific trade-offs between power savings and other
> key product characteristics in terms of things like capacity, throughput,
> availability, latency and response times, etc.
>
> (2) I expect that in all but the most trivial of products these power
> savings "knobs" will be independently tunable, and they will need to be set
> by each product owner so as to meet their specific business requirements.
>
> (3) To think that each product vendor will be able to make a reasonable
> mapping between N independently controlled features and a simple linear
> progression of states seems like wishful thinking to me.  "MAYBE" this could
> be done from a read only reporting perspective, but it will never work from
> a management and control perspective.  I just don't believe that the
> operational use cases for a multi-million dollar router or switch will ever
> boil down to some operator telling their router to go to "sleep" or to enter
> "power savings level 3".
>
> Now, if we are to pursue the definition of a single set of fixed enumerated
> states then the level of abstraction needs to be exceedingly high to be able
> to cover the breadth of equipment we envision.  So I would agree with Bruce
> that if this is the direction the number of states needs to be absolutely
> high-level and generic which will also serve to reduce the number of such
> states.  So, for example, HighPerformance/PowerSavings/Off is about the best
> that you could do.  But I question the usefulness of having a large router
> reporting that it is in the PowerSavings state.  Sure, you know that some
> feature somewhere in the router is not running an maximum performance but
> that is about all.  It would be useless from a management perspective to
> tell such a router to enter it's PowerSavings state.  What would that
> actually mean?  What reasonable mapping could actually be done here?  And
> Off would not be useful from a reporting perspective because if it was off
> how would it respond?
>   Setting it to Off would be useful, I guess, but only in limited
> circumstances because once it was Off how would you transition it back to
> any of the other states?
>
> Whether we have 3 states or 5 or 50 it won't really matter because this
> concept of a linear progression of states (e.g. from Off to PowerSavings to
> HighPerformance) is not the abstraction we should actually be pursuing IMHO.
>
> I think that a more useful abstraction would be one of modeling
> independently controllable Capabilities.  I would seek to let each product
> enumerate its own set of such capabilities along with the type of values
> that each capability could take on.  By allowing the product to enumerate a
> set of supported Capabilities each piece of equipment could provide a
> meaningful set of options to the technicians or management applications.  As
> the product evolves from one release to the next the list of supported
> Capabilities can grow and evolve over time based on each vendors design
> choices and each product's inherent technological constraints.
>
> So, without worrying about the SNMPisms involved (yet) this might only
> require a couple of tables to enumerate the required meta-data.  I am
> thinking of something along the following lines:
>
> This allows each product to enumerate a list of product specific
> capabilities which are supported.  These would be expected to be different
> from one vendor to another, and possible from one product release to the
> next.  This would allow the products to evolve over time without requiring
> any changes to the management interface (as long as there is no need to
> introduce new meta level attributes).
>
> <CapabilityTypeSpecification> would be any of a small number of simple data
> types such as String or Integer or Float, or a product defined
> EnumeratedTypeID which could be discovered via a second table like the
> following:
>
> emanEnumeratedTypeTable
> -----------------------
> This table enables the product to defined a set of EnumerationTypeIDs which
> can be used in the emanCapabilitiesDefinitionsTable above as one of the
> CapabilityTypeSpecifications.  The actual values for each enumeration could
> be discovered as follows:
>
> This table provides a product specific set of enumerated types which in
> turns defines the possible values that can be assigned as the current state
> for any of the corresponding capabilities.  Strings, Integers, Floats, and
> EnumeratedTypes would provide a fairly rich set of management data which is
> tuned to the specific capabilities of each managed element.
>
> The actual values for the current settings of each of these Capabilities
> would have to be obtained via Get/Set on yet another table along the lines
> of:
>
> emanProductCapabilities
> -----------------------
> Where each capability value is constrained to be within an appropriate
> domain based on the CapabilityType associated with the corresponding
> ProductSpecificCapabilityID.
>
> Now the thing that we loose with this is a fixed and well-defined set of
> semantics to go along with these product defined capabilities.  It is up to
> the operator (or the logic coded into a given management application) to
> understand the semantics of these settings for any given release of any
> given product.  I would argue that this is inevitable for any reasonably
> complex piece of equipment.  I would also argue that it is unrealistic to
> expect that we can devise some generic set of semantics which would be
> applicable to a wide range of products anyway.
>
> Using the information from such tables a management application could
> "easily" support a user interface to display the current state of each of
> the N capabilities to a human operator.  Similarly, any management
> application which seeks to exert operational control over these capabilities
> is required to understand the semantics of each release of each product for
> it to implement meaningful controls.  In other words, either the operator or
> the logic coded into the management application must be responsible for
> understanding the semantics of setting the values no matter what we do at
> the standard level.  I think that this in inevitable.  For example, putting
> a desktop PC to "sleep" has a meaningful set of semantics for a desktop PC
> whereas putting a router or a hub to "sleep" has an entirely different set
> of product and/or technology specific semantics for that equipment.
>
> At a sufficiently abstract level, yes we can say this means that the
> equipment is in some "low level power saving state" but this level of a
> statement is useless from a management perspective.  Either the operator or
> the management applicable are still required to understand what putting a
> specific piece of equipment to "sleep" means within the context of that
> piece of equipment and its roles and responsibilities within the overall
> organizational scheme.
>
> At this point I am only throwing this out for your consideration and
> discussion.  We would still have to assess what this would mean within the
> context of SNMP and the other IETF MIBs.
>
> Let me know if this is unclear as I wrote it up off the top of my head.  I
> will be happy to clarify anything that is unclear.  I am curious if there is
> any support for moving things in this direction or whether the group feels
> that the complexity outweighs the benefits (at least as I see them).
>
> As a simple concrete exercise, a product that only supported the single
> fixed enumerated set of states that are discussed above might choose to
> expose the following:
>
> Here we are seeing a case where the product supports a single capability,
> PowerState, which can be any of three possible values (i.e. Off,
> PowerSavings, and HighPerformance).  In this example the current state is
> PowerSavings.
>
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 02 Mar 2011 18:39:04 +0100

Dear all,

In the industry, there are multiple series of power states:
-  The ACPI standard. In practice, mainly used for PCs in case of non 
operational power states
-  The DMTF Power State Management Profile defines an information model 
over web services. The DMTF has 6 power states, 5 of them 
non-operational. They merged all operational power states into a single 
one: "on".
- Some manufacturers have their own power state series.

And there is an attempt to define the EMAN states in the EMAN framework, 
which would be a new power states series, at least for the operational ones.

In the world of PCs in case of non operational power states, ACPI seems 
well accepted.
However, my point is the following: there is no clear winner in terms of 
adopted series of power state in the industry.
I believe I would be dangerous to bet on power state series based on our 
knowledge today. The industry will decide, and maybe it will be a new 
power states series.

What I believe the solution is in terms of EMAN:
- we must be ready to support multiple power states series
- we must be ready to support a new power states series.
- the device must report which power states series it supports
In conclusion: be flexible and support all

Regards, Benoit.

> On Mon, Feb 28, 2011 at 4:07 AM, Juergen Quittek <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dear all,
>
>     [email-masked] <mailto:[email-masked]>
> eetd.lbl.gov/ea/nordman <http://eetd.lbl.gov/ea/nordman>
> [email-masked]
> 510-486-7089
> m: 510-501-7943
>
>

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 2 Mar 2011 21:44:12 +0100

Hi all,

Just a short question:

Which power state would apply to my notebook computer when

  - it is switched of, but charging its batteries. 
    This is an off-state with relatively high power consumption. 
    Is this covered by any ACPI or DMTF states or by the states in the drafts we have?

  - it is switched on and fully operational, but running on built-in battery only.
    This is an operational state with zero power consumption, at least as seen from outside.
    Again, how can we cover this with states described so far?

Thanks,

    Juergen

Am 02.03.2011 um 18:39 schrieb Benoit Claise:

> -  The ACPI standard. In practice, mainly used for PCs in case of non operational power states
> -  The DMTF Power State Management Profile defines an information model over web services. The DMTF has 6 power states, 5 of them non-operational. They merged all operational power states into a single one: "on".
> And there is an attempt to define the EMAN states in the EMAN framework, which would be a new power states series, at least for the operational ones.
> 
> In the world of PCs in case of non operational power states, ACPI seems well accepted.
> However, my point is the following: there is no clear winner in terms of adopted series of power state in the industry.
> I believe I would be dangerous to bet on power state series based on our knowledge today. The industry will decide, and maybe it will be a new power states series.
>

---

From: Michael Suchoff <[email-masked]>
Date: Wed, 2 Mar 2011 14:34:56 -0500

The ACPI & DMTF power states are not sufficient for real world applications.

For example, take Cisco data labs that employ Raritan PDUs and Raritan's
Power IQ (Power IQ is a power management service program).

Each night the following actions take place at Cisco
1.  Power IQ scheduler determines which outlets must be turned off.
2.  If outlet is associated with an server, a graceful shutdown takes place
(ssh script sent to server to run /etc/shutdown, etc.)
3. AC power to the outlet is turned off.

Now assume that the server has a BMC (baseboard management controller) that
can report ACPI power states.  These power states refer to the main
processor board and do not include the BMC itself.  In other words, ACPI
power state OFF means no power is being supplied to the motherboard, but AC
power is still being supplied to the server so that the BMC can continue to
function.

When above step 3 occurs to turn off all power to the server, the BMC ceases
to function.  This power state is outside the scope of ACPI.

Now let's assume that Raritan Power IQ adds the capability of interrogating
the ACPI power states of the server and wants to map them into the EMAN
standard.  Clearly at least one additional power state is required (AC power
turned off).  in actual practice, a user would also like to know such things
available from a PDU like "AC power lost due to circuit breaker trip", etc.

On Wed, Mar 2, 2011 at 12:39 PM, Benoit Claise <[email-masked]> wrote:

> over web services. The DMTF has 6 power states, 5 of them non-operational.
> They merged all operational power states into a single one: "on".
> knowledge today. The industry will decide, and maybe it will be a new power
> states series.
>
> eman mailing [email-masked]://www.ietf.org/mailman/listinfo/eman
>
>
>

---

From: [email-masked]
Date: Wed, 2 Mar 2011 18:05:08 -0800

>     Again, how can we cover this with states described so far?

Hi Juergen,

My initial thought is that the server entity would be OFF and the
battery entity would be ON/charging.  Like with a tripped circuit
breaker, "off" doesn't quite cut it, but I think we can find an
appropriate caption.

They key is to realize that the states for each entity are reflected
separately.

Thanks,
Chris

---

From: [email-masked]
Date: Wed, 2 Mar 2011 18:09:16 -0800

> The ACPI & DMTF power states are not sufficient for real world applications.

Agreed with regard's to Cyber Switching's operations, too.  I could
easily see having a "PduPowerStates" standard that augments or even
replaces the ACPI and DMTF standards for certain entities.

Chris

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 4 Mar 2011 16:17:28 +0100

Hi Chris,

What you say shows again that ACPI power states 
are not sufficient for EMAN.

If we model the notebook computer with battery as one device, 
then we will need additional (non-ACPI) states for the notebook, 
such as, for example,
  - off, but charging batters
  - on, but supplied by battery
  - etc.

If we follow your suggestion and model the notebook such that
it contains a PC device and a battery device, then we can use
ACPI states for the contained PC. But we need new (non-ACPI) 
states for modeling the battery, such as, for example,
  - full
  - charging
  - trickle charging
  - discharging (providing power)
  - empty.

The same applies to DMTF states. All static ones are mapped to ACPI.
Thus, also DMTF states are not sufficient for what we need in the EMAN WG.

Thanks,

    Juergen

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Fri, 4 Mar 2011 09:54:45 -0600

This is a good illustration of why I think a single standardized linear set of states will be insufficient and therefore ultimately unsuccessful in pactice.  In this case you are highlighting what I mean when I say that the states have a technological dependency.  The states which make sense for one technology are not necessarily going to make sense for another as we see with your example of the PC vs. the battery.

I may have obscured my earlier point by trying to provide too much detail on a potential solution to this issue.  So let me take this opportunity to back up and pose the following questions to the group:

1. Are we aiming for a single standardized linear set of states in the EMAN standard, or will our approach have to take into account the inherent variabilities between technologies and different vender implementations in some way?

2. What degree of flexibility must we incorporate into our solution such that we adequately account for these variabilities without opening the doors to pure chaos?

Personally I think that the specific answers to these questions will have a significant impact on our chances for success (which I am defining here as having written a useful standard that is widely accepted and utilized effectively).

Thoughts on this issue from others?

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked]
Phone: 614 367 5628
Fax: 614 367 5965

    - Albert Einstein

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Quittek
> Sent: Friday, March 04, 2011 10:17 AM
> To: [email-masked]; eman mailing list
> Cc: Bruce Nordman

---

From: Rolf Winter <[email-masked]>
Date: Fri, 4 Mar 2011 16:14:14 +0000

Bill,

I think I agree with most parts of your statement. Devices are too diverse to fit them into one universal power state model. The technological dependency is what Bruce I think is calling functional states. Ultimately, these functional states have important implications regarding a device's function (speed, rate etc. ...) which in turn has an impact on the energy they consume (likely many functional states only exist to safe energy).

However, I am not sure there is not a rather universal power state categorization in which many functional states exist such as On/Off/Sleep. We have tried to describe that model in draft-norwin-energy-consider. But then, if you really want to model a battery as a single device with its own power states as being discussed (maybe I misunderstood this point) then maybe even that won't work. Basically, I think batteries are a different beast and will complicate things if we attempt to treat them like a switch, server etc.

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> Mielke, William F (Bill)
> Sent: Freitag, 4. März 2011 16:55
> To: eman mailing list
> This is a good illustration of why I think a single standardized linear
> set of states will be insufficient and therefore ultimately
> unsuccessful in pactice.  In this case you are highlighting what I mean
> when I say that the states have a technological dependency.  The states
> which make sense for one technology are not necessarily going to make
> sense for another as we see with your example of the PC vs. the battery.
> 
> I may have obscured my earlier point by trying to provide too much
> detail on a potential solution to this issue.  So let me take this
> opportunity to back up and pose the following questions to the group:
> 
> 1. Are we aiming for a single standardized linear set of states in the
> EMAN standard, or will our approach have to take into account the
> inherent variabilities between technologies and different vender
> implementations in some way?
> 
> 2. What degree of flexibility must we incorporate into our solution
> such that we adequately account for these variabilities without opening
> the doors to pure chaos?
> 
> Personally I think that the specific answers to these questions will
> have a significant impact on our chances for success (which I am
> defining here as having written a useful standard that is widely
> accepted and utilized effectively).
>

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 4 Mar 2011 17:40:19 +0100

Hi Rolf,

It looks like we need to add managing storage devices (batteries, etc.) to the requirements.
As you say, they are different beasts and are not covered by what we have for switches, PCs, etc.

    Juergen

---

From: "Chris Verges" <[email-masked]>
Date: Fri, 4 Mar 2011 08:41:48 -0800

What are the states that a battery can have?

  1. Draining
  2. Charging
  3. Off

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Quittek
Sent: Friday, March 04, 2011 8:40 AM
To: Rolf Winter
Cc: eman mailing list
Subject: Re: [eman] Power States - really

Hi Rolf,

    Juergen

Am 04.03.2011 um 17:14 schrieb Rolf Winter:

> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
> London W3 6BL | Registered in England 2832014
> 
> 
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of Mielke, William F (Bill)
>> This is a good illustration of why I think a single standardized 
>> linear set of states will be insufficient and therefore ultimately 
>> unsuccessful in pactice.  In this case you are highlighting what I 
>> mean when I say that the states have a technological dependency.  The 
>> states which make sense for one technology are not necessarily going 
>> to make sense for another as we see with your example of the PC vs. the battery.
>> 
>> 1. Are we aiming for a single standardized linear set of states in 
>> the EMAN standard, or will our approach have to take into account the 
>> such that we adequately account for these variabilities without 
>> opening the doors to pure chaos?
>> 
>>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>>> Of Juergen Quittek
>>> What you say shows again that ACPI power states are not sufficient 
>>> for EMAN.
>>> 
>>> If we model the notebook computer with battery as one device, then 
>>> we will need additional (non-ACPI) states for the notebook, such as, 
>>> for example,
>>> If we follow your suggestion and model the notebook such that it 
>>> contains a PC device and a battery device, then we can use ACPI 
>>> states for the contained PC. But we need new (non-ACPI) states for 
>>> modeling the battery, such as, for example,
>>>  - full
>>>  - charging
>>>  - trickle charging

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 4 Mar 2011 18:06:54 +0100

Hi Chris,.

There are two charging modes for batteries:

  - regular charging 
    used to get the battery from empty to full.
  - trickle charging or float charging
    used if the battery is full already
    The issue here is that a full battery (depending on the technology tends to discharge itself.
    For compensating this effect trickle charging (open loop) 
    or float charging (with voltage control) is used to keep the battery full

In addition you may want to add power states empty (needs charging) 
and full (does not need charging), because this may be relevant 
for power demand planning.

    Juergen

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Fri, 4 Mar 2011 11:51:39 -0600

When you add in the concept of "level of charge" which you are summarizing as "Empty" or "Full", is this not a totally orthogonal dimension of information from the "PowerState" as articulated by Chris?  This seems to be the same point that Bruce (and others?) have made about the limits of a single linear set of states.

I would argue that what we have here is an example to two independent attributes: PowerState and LevelOfCharge.  I would think that LevelOfCharge would be best modeled as a percentage rather than a fixed set of states, however a "reasonable" approach might be to let it take on the range of values "Empty", "Partial", and "Full".

This leads to something like the following:

BatteryPowerState := { Off, Draining, Charging }
BatteryLevelOfCharge := { Empty, Partial, Full }

If we try to combine these into a single set of states, then logically that set of states will correspond to the cross product of these two sets and should yield a total of 3 x 3 = 9 unique combined states as follows:

CombinedState    BatteryPowerState   BatteryLevelOfCharge
-------------    -----------------   --------------------
CS1              Off                 Empty
CS2              Off                 Partial
CS3              Off                 Full
CS4              Draining            Empty
CS5              Draining            Partial
CS6              Draining            Full
CS7              Charging            Empty
CS8              Charging            Partial
CS9              Charging            Full

Note that not all such combined states are necessarily meaningful.  For example CS4 appears logically inconsistent as does CS9.

This seems to beg the question, what do we actually mean by the term "PowerState"?  Section 5.6 of the updated framework document discusses this concept but I don't see a simple concise definition of the term anywhere.  Have I missed it?

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

> Sent: Friday, March 04, 2011 12:07 PM
> To: Chris Verges
> Cc: eman mailing list; Rolf Winter
> >> I think I agree with most parts of your statement. Devices 
> are too diverse to fit them into one universal power state 
> model. The technological dependency is what Bruce I think is 
> calling functional states. Ultimately, these functional 
> states have important implications regarding a device's 
> function (speed, rate etc. ...) which in turn has an impact 
> on the energy they consume (likely many functional states 
> only exist to safe energy).
> >> 
> >> However, I am not sure there is not a rather universal 
> power state categorization in which many functional states 
> exist such as On/Off/Sleep. We have tried to describe that 
> model in draft-norwin-energy-consider. But then, if you 
> really want to model a battery as a single device with its 
> own power states as being discussed (maybe I misunderstood 
> this point) then maybe even that won't work. Basically, I 
> think batteries are a different beast and will complicate 
> things if we attempt to treat them like a switch, server etc.
> >> 
> >> 
> >> Best,
> >> 
> >> 
> >> Rolf
> >> 
> >>>> Thus, also DMTF states are not sufficient for what we 
> need in the 
> >>>> EMAN WG.
> >>>> 
> >>>> Thanks,
> >>>> 
> >>>>   Juergen

---

From: Ted Ghose <[email-masked]>
Date: Fri, 4 Mar 2011 09:54:59 -0800

Bill,

I totally disagree with you. It is diverse from device perspective, but if I
look at energy saving perspective, I want it unified. We lay down some
guideline for manufactures, but for managing power, I need a fixed set of
states, which to me means lower state, I save more, higher state I pay
more!!

Is it too much to ask?

-tg-

On Fri, Mar 4, 2011 at 7:54 AM, Mielke, William F (Bill) <
[email-masked]> wrote:

> This is a good illustration of why I think a single standardized linear set
> of states will be insufficient and therefore ultimately unsuccessful in
> pactice.  In this case you are highlighting what I mean when I say that the
> states have a technological dependency.  The states which make sense for one
> technology are not necessarily going to make sense for another as we see
> with your example of the PC vs. the battery.
>
> I may have obscured my earlier point by trying to provide too much detail
> on a potential solution to this issue.  So let me take this opportunity to
> back up and pose the following questions to the group:
>
> 1. Are we aiming for a single standardized linear set of states in the EMAN
> standard, or will our approach have to take into account the inherent
> variabilities between technologies and different vender implementations in
> some way?
>
> 2. What degree of flexibility must we incorporate into our solution such
> that we adequately account for these variabilities without opening the doors
> to pure chaos?
>
> Personally I think that the specific answers to these questions will have a
> significant impact on our chances for success (which I am defining here as
> having written a useful standard that is widely accepted and utilized
> effectively).
>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 4 Mar 2011 13:35:05 -0500

Hi,

I suggest that this discussion is confusing the notions of
power state and operational state.

The IEEE-ISTO Printer Working Group approved in February
our abstract Imaging System Power Management Model [1]
and corresponding concrete Imaging System Power MIB [2]
for printers and multifunction devices (print/scan/fax/etc.).

We used exactly the DMTF power states (static and resets)
and their corresponding ACPI power states.

But we *also* used separate operational states (e.g., down,
testing, idle, processing, etc.) for each managed component.

I suggest that a battery, just like any other component, has
a few simple power states (i.e., input/output of power itself)
and a separate set operational states.

Attempting to fold these two related (but independent) states
into a single linear power state will fail - there are just too
many different components with unusual operational states
- and the behavior of a reset will become too ambiguous.

Cheers,
- Ira (editor of PWG Power Model/Power MIB)

[1] PWG Imaging System Power Management Model
ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspower10-20110302.pdf

[2] PWG Imaging System Power MIB
ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspowermib10-20110302.pdf
ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspowermib10-20110302.mib

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Fri, 4 Mar 2011 15:39:27 -0600

> Ted Ghose wrote:
>
> I totally disagree with you.

It is good that we disagree.  Doing so fosters the discussion necessary to better understand the topic du jour and to drive meaningful progress.  :)
 
> It is diverse from device perspective, but if I look at energy saving perspective, 
> I want it unified.

OK, let me challenge you to articulate WHY you want it unified.  I am not saying that "unification" so is either good or bad, I would just like to know the reasons for making that choice.

I have tried to articulate a number of reasons why I think unification is not a good goal in this case.  What are your reasons for asserting that it is a good goal so that we might weigh the benefits against the costs?

> We lay down some guideline for manufactures, but for managing power, I need a 
> fixed set of states, which to me means lower state, I save more, higher state 
> I pay more!!

This is an esthetically pleasing goal based on a nice sounding abstraction.  Even if I accept that such an approach is "doable" in the sense that the constraint that you articulate (i.e. lower state implies lower cost) is satisfied by conforming implementations, I question the utility of such an approach in any practical sense from an effect management strategy.

Any piece of equipment which is going to be managed via these interfaces presumably is part of a larger system of cooperating entities who are expected to jointly satisfy some specific business or operational requirements.  The problem with trying to manage equipment at this level of abstraction is that it is completely divorced from the implications it will have on those business and operational requirements.

If we consider the management of a specific entity the assumption people are making here seems to be that some of the available power levels will be sufficient to meet those business requirements while others will not.  How is an operator to know which levels are business requirements conforming and which are not without understanding the vendor specific implications of setting one level or another?

I argue that they cannot and so raising things to this level of abstraction has not helped anything from a management perspective.  The operators still need to understand the idiosyncracies of each vendor's equipment and so the abstraction has not proven to be useful.

If we instead assume that ALL power levels will somehow be business requirements conforming (a very tall order without knowing any of the business context) then all operators will presumably set the power levels on all equipment to their lowest values since this will obviously save the most money.  Why would you ever use a higher power level if do so costs money for no good business benefit (i.e. in terms of meeting the business requirements)?

If everyone is going to always set the lowest values then why bother to have a parameter at all?  Again, this abstraction, IMHO obviously, has not proven useful from a management perspective.

Do you disagree with the above analysis?  If so please explain why.

Thanks,

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

---

From: Ted Ghose <[email-masked]>
Date: Fri, 4 Mar 2011 16:54:02 -0800

Hi Bill:

## Do you disagree with the above analysis?  If so please explain why.

I actually do agree with you that capability of a device along with
the business context is the extra dimension that will be needed to factor
in. These 2 parameters are crucial to drive the complete solution. How are
we going to represent these two parameter with respect to a devices power
state, and how can we have a granular control from cost benefit analysis is
the next thing on my agenda. But, unless we have a agreed set of power
states, we are not having a forum to work. In my mind all along, I'm
modelling around the power states to drive the enterprise of home power
policies.

My objective is not just to blindly set to a lower state, but have the
ability to have policies around the power states, and this abstraction is
going to give us the tool to do so.

without the fixed number of states though, please show me how could we make
policies or rule engines to automate across a business domain or even for
your home.

If we can achieve that without power states, I'm in one mind with you, that
we do not need them.

Do I the make my reasons clear why I'm for making that choice?

Thanks

-tg-

On Fri, Mar 4, 2011 at 1:39 PM, Mielke, William F (Bill) <
[email-masked]> wrote:

> It is good that we disagree.  Doing so fosters the discussion necessary to
> better understand the topic du jour and to drive meaningful progress.  :)
>
> OK, let me challenge you to articulate WHY you want it unified.  I am not
> saying that "unification" so is either good or bad, I would just like to
> know the reasons for making that choice.
>
> I have tried to articulate a number of reasons why I think unification is
> not a good goal in this case.  What are your reasons for asserting that it
> is a good goal so that we might weigh the benefits against the costs?
>
> This is an esthetically pleasing goal based on a nice sounding abstraction.
>  Even if I accept that such an approach is "doable" in the sense that the
> constraint that you articulate (i.e. lower state implies lower cost) is
> satisfied by conforming implementations, I question the utility of such an
> approach in any practical sense from an effect management strategy.
>
> Any piece of equipment which is going to be managed via these interfaces
> presumably is part of a larger system of cooperating entities who are
> expected to jointly satisfy some specific business or operational
> requirements.  The problem with trying to manage equipment at this level of
> abstraction is that it is completely divorced from the implications it will
> have on those business and operational requirements.
>
> If we consider the management of a specific entity the assumption people
> are making here seems to be that some of the available power levels will be
> sufficient to meet those business requirements while others will not.  How
> is an operator to know which levels are business requirements conforming and
> which are not without understanding the vendor specific implications of
> setting one level or another?
>
> I argue that they cannot and so raising things to this level of abstraction
> has not helped anything from a management perspective.  The operators still
> need to understand the idiosyncracies of each vendor's equipment and so the
> abstraction has not proven to be useful.
>
> If we instead assume that ALL power levels will somehow be business
> requirements conforming (a very tall order without knowing any of the
> business context) then all operators will presumably set the power levels on
> all equipment to their lowest values since this will obviously save the most
> money.  Why would you ever use a higher power level if do so costs money for
> no good business benefit (i.e. in terms of meeting the business
> requirements)?
>
> If everyone is going to always set the lowest values then why bother to
> have a parameter at all?  Again, this abstraction, IMHO obviously, has not
> proven useful from a management perspective.
>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 8 Mar 2011 04:07:53 -0600

Hi Juergen,

Firstly, Battery for a PC can be analogous to a UPS for a Data center.  

During Power outages, UPS can provide power for the network elements in
a Data center for a finite period of time. 

I think a solution to the question you have posed can be to decouple the
device and the battery.   

As a first step,  I think it would be useful to understand if the device
is on direct power or on UPS/battery power - not sure if this has been
captured in the MIB modules. 

If it is direct power, then we have the measurement variables defined. 

If the device is on battery (or storage) power, it may be more useful to
monitor the drain rate of the  battery alone.  

Regarding the scenarios you have indicated,  and if the device is
switched-off (ACPI G3-S5 (Off-Hard)), 

then power consumed is only for the battery charging.  Device state is
G3-S5 (Off-Hard), while the battery state is "Charging".    

So, if we consider the following equation, 

Power consumption of a device = power consumption from the grid + power
drained from storage/battery,

in case power consumption from grid is zero, the power consumption of
device is non-zero. 

Thanks

Mouli

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Thursday, March 03, 2011 2:14 AM
To: Benoit Claise (bclaise)
Cc: eman mailing list; Bruce Nordman
Subject: Re: [eman] Power States - really

Hi all,

Just a short question:

    Is this covered by any ACPI or DMTF states or by the states in the
drafts we have?

  - it is switched on and fully operational, but running on built-in
battery only.

    This is an operational state with zero power consumption, at least
as seen from outside.

Thanks,

    Juergen

Dear all,

And there is an attempt to define the EMAN states in the EMAN framework,
which would be a new power states series, at least for the operational
ones.

Regards, Benoit.

Dear all,

Option 1: fixed minimum

Option 2: fixed DMTF

Option 3: fixed ACPI

Option 4: fixed EMAN

Thanks.

   Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 8 Mar 2011 17:47:19 +0100

Hi Mouli,

Thanks for the summary. That's a good description of the option of 
treating battery and PC as separate entities

But now comes the fun part.
Folks here asked for mapping entities to domains, such as 
'metering domains' and 'power distribution domains'.

The problem I see if we treat battery and PC separately is that
the PC switches domains whenever switching from main power 
to battery power or vice versa. I am afraid that this breaks the 
concept of fixed domains of an entity. 

It may also break the assumption of constant parent-child relationships.
Take this example:
There is an external meter measuring the power of the PC. The meter
acts as the PC's and the battery's direct parent and reports the visible
external power consumed. Now, if you take the battery (or UPS) as separate
entity, it may have its own charging controller and measure charging and 
draining and report on this. The conclusion is that the PC changes its 
parent whenever switching from main power to battery power and vice versa.

Hence, the separate treatment of battery and PC requires us to consider
dynamic memberships in domains and dynamic parent-child relationships.

Thanks,

    Juergen

Am 08.03.2011 um 11:07 schrieb Mouli Chandramouli (moulchan):

> During Power outages, UPS can provide power for the network elements in a Data center for a finite period of time.
>  
> I think a solution to the question you have posed can be to decouple the device and the battery.   
>  
> As a first step,  I think it would be useful to understand if the device is on direct power or on UPS/battery power – not sure if this has been captured in the MIB modules.
>  
> If the device is on battery (or storage) power, it may be more useful to monitor the drain rate of the  battery alone.  
>  
> Regarding the scenarios you have indicated,  and if the device is switched-off (ACPI G3-S5 (Off-Hard)),
> then power consumed is only for the battery charging.  Device state is G3-S5 (Off-Hard), while the battery state is “Charging”.    
>  
> Power consumption of a device = power consumption from the grid + power drained from storage/battery,
> in case power consumption from grid is zero, the power consumption of  device is non-zero.
>  
> Thanks
> Mouli
>  
>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 9 Mar 2011 05:05:15 -0600

Hi Juergen,

Thanks for the email and interesting follow-up questions you have posed
- which probably would require more discussion on a separate thread. 

On the narrow question, I would like to add - 

In the case of battery and PC, the PC has an IP address and battery is
an adjunct device. 

The battery usage/drain can be observed only when the PC is ON.   

So, the battery should not be considered a parent, IMHO. 

Thanks

Mouli

PS: If I can inject some humor, the role of a parent should be more
permanent and not transient lasting only a finite time. 

From: Juergen Quittek [mailto:[email-masked]] 
Sent: Tuesday, March 08, 2011 10:17 PM
To: Mouli Chandramouli (moulchan)
Cc: Benoit Claise (bclaise); eman mailing list; Bruce Nordman
Subject: Re: [eman] Power States - really

Hi Mouli,

Take this example:

external power consumed. Now, if you take the battery (or UPS) as
separate

parent whenever switching from main power to battery power and vice
versa.

Thanks,

    Juergen

Hi Juergen,

Thanks

Mouli

Hi all,

Just a short question:

Thanks,

    Juergen

Dear all,

Regards, Benoit.

Dear all,

Option 1: fixed minimum

Option 2: fixed DMTF

Option 3: fixed ACPI

Option 4: fixed EMAN

Thanks.

   Juergen