Subject: [OPSAWG] Power Monitoring/Management: which problem(s) do we try to solve?

From: Benoit Claise <[email-masked]>
Date: Thu, 10 Jun 2010 17:53:16 +0200

Dear all,

There are currently two drafts being discussed, with technical 
discussions around power level (operational and non operational), 
parent/child, domain, keyword, power quality, etc...
We should certainly continue these discussions.
However, allow me refocus the discussion on one important point: which 
problem(s) do we try to solve?

    monitoring power states of managed entities,
    monitoring energy consumption of managed entities,
    where the managed devices means what?
	battery based device
	routers and switches
	PoE end points
	non PoE end points attached to switch/router
	non PoE end points attached behind a PoE end point
	smart PDU
	connected building devices, with potentially non-IP enabled power meters
	home energy gateway, with potentially non-IP enabled power meters
	PC
	something else?

Please share your view.

Regards, Benoit.

---

From: "Chris Verges" <[email-masked]>
Date: Thu, 10 Jun 2010 10:13:03 -0700

Hi Benoit,

I'll preface this reply by admitting that I am new to these discussions
and probably don't have as much knowledge on the history as I'd like.
What I'll offer is my observations of the industry's needs related to
power measurement.

"Smart Grid" (to me) means more than just the utility infrastructure.
It means intelligent power management, from the generator down to the
appliance consuming the energy.  People need reliable, quality
information to make the best decisions about allocating resources to
meet their business needs.

At least for the present, there are two main types of appliances found
in a network: legacy and "enhanced", for lack of a better term.  The
legacy equipment does not monitor its own power usage, so needs it
reported by a third party on its behalf.  The enhanced equipment has
internal power monitoring capabilities, but may not have ALL aspects of
power monitoring within its purview.  (For example, a switch may not
monitor its power factor.)  So it seems like there needs to be a
cohesive reporting structure for these two scenarios -- self-reporting
equipment and reporting-on-behalf-of equipment.

This information is really only useful when combined with management of
that equipment.  There are two obvious states of management: on and off.
But there could be additional states possible: low power mode, high
performance mode, etc.  Certainly, others have brought up a vast array
of possibilities for what this means.  Really, these all center around
one concept: how do I inject the business policies around managing
energy into the technical aspect of running the equipment?  Not a simple
question to answer, but a critical one.

The solution needs to be flexible.  We can talk all day long on this
thread about what power states make sense, but customers will find ways
to mold it to their own needs in the field.  Does a strict ACPI-style
list of power levels really make sense?  Maybe there are other
technologies which perform this same
business-policy-to-technology-implementation that we can learn from.
BGP (the routing protocol) comes to mind as one in which distributed
policies are routinely expressed through route-maps, community values,
and prefix preferences.  The information needs to be reported in a
consistent manner, but scope of the information should be malleable.

So this comes down to three problems to solve:

   1. Reporting energy usage of any piece of equipment
        a. self-reporting
        b. on-behalf-of reporting

   2. Managing energy usage
        a. demand/response policies
        b. cpu utilization policies
        c. etc.

   3. Flexing to various customers' needs

Thanks,

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Benoit Claise
Sent: Thursday, June 10, 2010 8:53 AM
To: [email-masked]
Subject: [OPSAWG] Power Monitoring/Management: which problem(s) do we
try tosolve?

Dear all,

    monitoring power states of managed entities,
    monitoring energy consumption of managed entities,
    where the managed devices means what?
	battery based device
	routers and switches
	PoE end points
	non PoE end points attached to switch/router
	non PoE end points attached behind a PoE end point
	smart PDU
	connected building devices, with potentially non-IP enabled
power meters
	home energy gateway, with potentially non-IP enabled power
meters
	PC
	something else?

Please share your view.

Regards, Benoit.

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

---

From: Benoit Claise <[email-masked]>
Date: Fri, 11 Jun 2010 10:32:10 +0200

Hi Chris,

Pretty good summary.
See inline.
> equipment and reporting-on-behalf-of equipment.
Fully agree.
And if we base our monitoring design on this, then it implies that we're 
pretty open in terms of use cases.
> question to answer, but a critical one.
This is a key question, but we must start by doing a standardized 
monitoring, which is not there yet.
For example, by knowing the energy consumed in buildings, we see a 
direct drop of 30% of this energy consumed, because we directly realize 
what we do wrong/what we can improve: lights on after 7PM, reduce the 
temperature, etc...
However, the real gain is around applying business policies to the 
network, you're right!

>     3. Flexing to various customers' needs

I didn't want to directly answer my own email about "Power 
Monitoring/Management: which problem(s) do we try to solve?", but my 
view is:
- 
http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-00 contains 
a good series of requirements
- NOT limit ourselves to router/switch/PoE ports. So fully agree with

- we should focus on reporting first, with power and energy. However, we 
should think of the architecture for configuration already.
- in terms of distributing (business) policies, this is the ultimate goal.
     However, at this point, I'm not sure how to do it in a standardized 
way.
     I mean: today, it's done either by configuring individual devices 
or with a proprietary protocol

Regards, Benoit.

---

From: "Chris Verges" <[email-masked]>
Date: Fri, 11 Jun 2010 04:42:09 -0700

Hi Benoit,

>> This information is really only useful when combined with
>> management of that equipment.
>

Agreed.  We do have a basic understanding of what that standardized
monitoring must encompass.  (After all, the utility companies have been
doing this for years!)

kWh reduction is the goal, so it is an obvious metric to track.

Instantaneous data (voltage, amperage, etc.) helps to identify which
equipment is a candidate for reduction; the techniques used by companies
like Power Assure, for example, are an excellent model.  (Power Assure's
model is to use instantaneous power data to help track the CPU
utilization of connected equipment inside a cloud, which can be
determined through a series of profiling tests.)

What other data has proven useful in innovative, successful solutions to
managing energy usage?

http://tools.ietf.org/html/draft-quittek-power-monitoring-requirements-0
0

Definitely a good read.  Thanks for passing it on!

> - we should focus on reporting first, with power and energy.
>   However, we should think of the architecture for configuration
>   already.
>
> - in terms of distributing (business) policies, this is the ultimate
>   goal.  However, at this point, I'm not sure how to do it in a
>   standardized way.  I mean: today, it's done either by configuring
>   individual devices or with a proprietary protocol

And this would be why we all still have jobs.  :-)  It's certainly a
difficult problem, but the major sticking point behind why every PDU
vendor produces their own BMS/EMS solution.  This really isn't a viable,
long-term answer, and this MIB work is the first step toward
consolidation towards a common platform.

If we look at the utility company programs like Automated
Demand/Response (Auto-DR), we see how they model this management
technique:

   1. Inform the unit of the power grid's requirements for reduction
      through a simple demand metric: Normal, Moderate, High.

   2. Add pricing data to allow the consumer (of the data) to
      determine the best solution for itself.

   3. The actual response taken is dependent on the equipment's
      capabilities.

In the end, it's up to the equipment that is receiving the command to
perform whatever reduction is possible.  The utility company would never
be able to enumerate all of the possibilities, but they don't really
care to do so ... as long as the end goal of reduction is reached.

The ACPI-style list we've discussed previously seems to get into the
Normal/Moderate/High concept; perhaps all we need to do is decouple the
actual behavior related to each level with the desired goal.

What do others think?

Regards,
Chris