Subject: [eman] simplifying the support of multiple power state sets

From: Juergen Quittek <[email-masked]>
Date: Tue, 6 Nov 2012 03:45:53 +0000

Dear all,

I would like to re-open a closed issue: the concurrent support of
multiple power sets.  Curently our requirements documents states
in section 5.4:
  "In order to support multiple management
   systems possibly using different Power State sets, while
   simultaneously interfacing with a particular entity, the energy
   management standard must provide means for supporting multiple Power
   State sets used simultaneously at an entity."

When trying to design such a system at NEC, we ran into several
problems that made us doubt whether this requirements is wisely
chosen.

The problem arises from the issue that not for all states in a
power state set A there is necessarily a corresponding state in
power set B and/or vice versa.

The problem is which power state to report for set B if the device
is set to a power state of set A that cannot be mapped to any state
of set B?  Fortunately, the DMTF has all of its state more or less
mappable to ACPI states, but as soon as we include ASHRAE states,
this is gone.

One solution would be extending each set by a generic power state
that is called "non-supported-by-this-set".

Another solution would be to give up supporting multiple state sets
concurrently.

I would like to make a simple proposal that would still allow a
device to support multiple sets, just not at the same time.
It implies de-regulating power set support and gives a bit more
freedom to implementers.

The proposal is
  - Having all power states registered at IANA with a unique number
    The membership of a power state set can be indicated by just an
    attribute in the IANA registration.
  - Allowing devices to implement any subset of IANA registered
    power states (independent of power state sets).
  - Requiring a device to provide a list of all power states it
    implemens.
  - Requiring a device to be in exactly one power state at a time
(I don't claim the proposal is new. Probably it has already been
made already on the list in earlier discussions by someone else.)

This would support the following options:

1. We can still have power state sets.  They would consist of all
power states registered at IANA with the same power state set
attribute.

2. We can have a device implementing exactly one set by implementing
all power states that are registered at IANA with the same power
state set attribute.

3. We can extend power sets if needed, by just adding one more state
with the same power state set attribute to the IANA registry.

4. We can have devices supporting only a subset of a single power
state set.  The device would indicate to any management system
which states it supports.

5. We can have a device supproting two or more power state sets.
It would just implement all or a subset of all states in multiple
power sets.  Management systems that can operate on just a single
set would use only power states belonging to the set that they know.

6. We can even have manfacturers creating private extensions of
standard power state sets by supporting all states of a set and
additional states that are in the standard set, but have been
registered individually by the manufacturer.  This provides
extensibility to device types we did not consider today or to new
power saving technologies that lead to new power states.

7. If we want we can further allow proprietary power states that
are not registered at IANA. For these we would have to reserve a
number space.

8. We can still make recommendations that certain devices types
should implement certain power state sets.

The only drawback I see compared to the current solution occurs in
the situation of multiple management systems managing the device
using different power states.  If one management system wants the
device to be in a certain state of a cretain set and another
managament system want to have it in another state of a different
set, then the device may be permanently swapping power states.

What do people on this list think about the proposed simplification?

Dear all,

I would like to re-open a closed issue: the concurrent support of
multiple power sets.  Curently our requirements documents states
in section 5.4:
  "In order to support multiple management
   systems possibly using different Power State sets, while
   simultaneously interfacing with a particular entity, the energy
   management standard must provide means for supporting multiple Power
   State sets used simultaneously at an entity."

When trying to design such a system at NEC, we ran into several
problems that made us doubt whether this requirements is wisely
chosen.

The problem arises from the issue that not for all states in a
power state set A there is necessarily a corresponding state in
power set B and/or vice versa.

The problem is which power state to report for set B if the device
is set to a power state of set A that cannot be mapped to any state
of set B?  Fortunately, the DMTF has all of its state more or less
mappable to ACPI states, but as soon as we include ASHRAE states,
this is gone.

One solution would be adding a generic power state to each set that
is called "non-supported-by-this-set".

Another solution would be to give up supporting multiple state sets
concurrently.

I would like to make a simple proposal that still allows a
device to support multiple sets, just not at the same time.
It implies de-regulating power set support and gives a bit more
freedom to implementers.

The proposal is
  - Having all power states registered at IANA with a unique number
    The membership of a power state set can be indicated by just an
    attribute in the IANA registration.
  - Allowing devices to implement any subset of IANA registered
    power states (independent of power state sets).
  - Requiring a device to provide a list of all power states it
    implemens.
  - Requiring a device to be in exactly one power state at a time
(I don't claim the proposal is new. Probably it has already been
made already on the list in earlier discussions by someone else.)

This would support the following options:

1. We can still have power state sets.  They would consist of all
power states registered at IANA with the same power state set
attribute.

2. We can have a device implementing exactly one set by implementing
all power states that are registered at IANA with the same power
state set attribute.

3. We can extend power sets if needed, by just adding one more state
with the same power state set attribute to the IANA registry.

4. We can have devices supporting only a subset of a single power
state set.  The device would indicate to any management system
which states it supports.

5. We can have a device supproting two or more power state sets.
It would just implement all or a subset of all states in multiple
power sets.  Management systems that can operate on just a single
set would use only power states belonging to the set that they know.

6. We can even have manfacturers creating private extensions of
standard power state sets by supporting all states of a set and
additional states that are in the standard set, but have been
registered individually by the manufacturer.  This provides
extensibility to device types we did not consider today or to new
power saving technologies that lead to new power states.

7. If we want we can further allow proprietary power states that
are not registered at IANA. For these we would have to reserve a
number space.

8. We can still make recommendations that certain devices types
should implement certain power state sets.

The only drawback I see compared to the current solution occurs in
the situation of multiple management systems managing the device
using different power states.  If one management system wants the
device to be in a certain state of a cretain set and another
managament system want to have it in another state of a different
set, then the device may be permanently swapping power states.

Implied changes in the requirements draft would be:
Section 5.4  Power State
OLD
  "In order to support multiple management
   systems possibly using different Power State sets, while
   simultaneously interfacing with a particular entity, the energy
   management standard must provide means for supporting multiple Power
   State sets used simultaneously at an entity."
NEW
  "In order to support multiple management
   systems possibly using different Power State sets, the energy
   management standard must provide means for supporting multiple Power
   State sets at an entity."

5.4.3.  Multiple Power State sets
OLD
  "The standard must provide means for supporting multiple Power State
   sets simultaneously at an entity."
NEW
  "The standard must provide means for supporting multiple Power State
   sets at an entity."

5.4.4.  List of supported Power State sets
Delete requirement, because it is implicitly covered by
requirement 5.4.2 (List of supported Power States)

5.4.5.  List of supported Power States within a set
Delete requirement, because it is implicitly covered by
requirement 5.4.2 (List of supported Power States)

What do people on this list think about the proposed simplification?

Thanks,
    Juergen

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 6 Nov 2012 17:16:28 +0000

Hi Juergen,

Sorry you've had problems designing such a system. At Cisco and with the EnergyWise program and partner system we have  designs and deployments that do not have this problem. We support multiple concurrent sets of power levels (this group is calling them states now) with various vendors.

Our partners and device manufacturers have had no problems mapping the DMTF, ACPI, Poe, PWG, Cisco, and  manufacturer specific states. (see Cisco,Lenovo, Xerox, Schneider APC, Raritan etc..) simultaneously.

In fact it's been very usable by our management partners who have implemented EnMS' on such a scheme. (see Joulex, Cisco Prime, Verdiem, CA Nimsoft, IBM Tivoli)

Your premise that you do not have corresponding states between sets of states is one that can be loosened when you look at overlapping ranges of state. Again we've been doing this for four  with years now with about 85 partners now and thousands of devices deployed under management.

So if you make a requirement that we can't do multiple states at the same time you'd be negating our work and design.

The requirement doc should not dictate implementation. I think by stating that a device should be able to support multiple power state sets that is enough. The fact that they are simultaneous or not is a limitation of some device but please don't limit it in the requirements for those of us who can.

The proposal you have is more relevant as an implementation discussion not a requirements discussion.

 In that light thanks for the impementation proposal below, can you provide an example much like the tables we showed in our work in the framework over the past two years on this issue that shows your proposal. 
 
I'd like to make sure that for those of us who can and are doing  this mapping as a matter of course can still be able to without a long cumbersome list. 

Without that example I feel we are just thrashing an issue which we've shown in running code and stated in nearly two years of discussion here. 

Jp

Design references

http://www.cisco.com/en/US/docs/solutions/Enterprise/Borderless_Networks/Energy_Management/energywisedg.html

Manufacturers and EnMS references

http://www.cisco.com/en/US/prod/switches/ps5718/ps10195/energywise_partner_ecosystem.html

Sent from my iPad 
(expect ridiculous spelling mistakes) 

On Nov 5, 2012, at 7:46 PM, "Juergen Quittek" <[email-masked]> wrote:

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

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 6 Nov 2012 22:50:58 +0000

Hi John,

On 06.11.12 12:16, "John Parello (jparello)" <[email-masked]> wrote:

>Hi Juergen,
>
>Sorry you've had problems designing such a system. At Cisco and with the
>EnergyWise program and partner system we have  designs and deployments
>that do not have this problem. We support multiple concurrent sets of
>power levels (this group is calling them states now) with various vendors.
>
>Our partners and device manufacturers have had no problems mapping the
>DMTF, ACPI, Poe, PWG, Cisco, and  manufacturer specific states. (see
>Cisco,Lenovo, Xerox, Schneider APC, Raritan etc..) simultaneously.

I explicitly wrote that we did not have a problem mapping DMTF and ACPI
states, but we ran into problems mapping (1) ASHRAE states and (2) states
not covered by these sets.  It looks like this is a problem that you and
your partners have not addressed yet.

>In fact it's been very usable by our management partners who have
>implemented EnMS' on such a scheme. (see Joulex, Cisco Prime, Verdiem, CA
>Nimsoft, IBM Tivoli)
>
>Your premise that you do not have corresponding states between sets of
>states is one that can be loosened when you look at overlapping ranges of
>state. Again we've been doing this for four  with years now with about 85
>partners now and thousands of devices deployed under management.

Can you explain how you solved the problem by "looking at overlapping
ranges"?.

>So if you make a requirement that we can't do multiple states at the same
>time you'd be negating our work and design.

Not at all.  I just say that I cannot do it in my case.  I have no doubt
that your case is fully working.  And again, we had no problems mapping
state sets that fit well to each other, such as ACPI and DMTF.

And I do not make new requirement, I just claim that I have problems with
meeting a requirement.  I'll gladly take your advice on any solution.

>The requirement doc should not dictate implementation.

I fully agree.  But the tighter the requirement, the stronger the
'dictate'.  I argue about relaxing the requirement and having less
'dictated'.  Thus you should be glad I'm doing so, if you care about
implementation flexibility.

>I think by stating that a device should be able to support multiple power
>state sets that is enough.

Yes, this is what I suggested. Thanks.

>The fact that they are simultaneous or not is a limitation of some device
>but please don't limit it in the requirements for those of us who can.

Yes. The requirements are I suggested are less limiting, not more limiting.

>not a requirements discussion.

Fully agreed.

> In that light thanks for the impementation proposal below, can you
>provide an example much like the tables we showed in our work in the
>framework over the past two years on this issue that shows your proposal.
> 
>I'd like to make sure that for those of us who can and are doing  this
>mapping as a matter of course can still be able to without a long
>cumbersome list.

Yes, I will send you the cases.

I think I your funny term "those of us who can" does not make the point. I
said that I can do the mappings you did. My problem occurred with mappings
you did not do. 

>Without that example I feel we are just thrashing an issue which we've
>shown in running code and stated in nearly two years of discussion here.

I don't want to trash anything.  However, if I have a technical concern, I
will speak up, independent of the number of customers that you have.
Let's continue the discussion in a separate email where I will elaborate
the case.  I hope you can help me solving it and then there will be no
issue anymore.

Thanks,
    Juergen