Subject: Re: [OPSAWG] monitoring power state and energy consumption: draft-claise-energy-monitoring-mib-00.txt is a new draft -> RFC3433

From: Benoit Claise <[email-masked]>
Date: Tue, 02 Feb 2010 09:01:30 +0100

Juergen, all,

Thanks for your feedback regarding this draft.
We would like to focus on the most important feedback: the relationship with the ENTITY-SENSOR-MIB (RFC3433)

It's true that
	emEntEnergyUsage is similar to entPhySensorValue
	emEntEnergyScale is similar to entPhySensorScale

However, here are some issues we discovered regarding RFC3433

1. RFC 3433 mentions entPhySensorPrecision which seems to mix both precision and accuracy.
The Entity-Sensor-MIB doesn’t have the ANSI C12.x accuracy classes
required for electricity. I.e., 1%, 2%, 0.5% accuracy classes.
We have a clear accuracy OID in our MIB module.  These ANSI and IEC
Standards require that we use an accuracy class, and not the precision model in RFC3433.

2. Is the EntitySensorPrecision really useful?
	"If an object of this type contains a value in the range 1 to 9, it
	represents the number of decimal places in the fractional part of an
	associated EntitySensorValue fixed-point number."
	"If an object of this type contains a value in the range -8 to -1, it
	represents the number of accurate digits in the associated EntitySensorValue
	fixed-point number."

3. Maybe a detail, but regarding the index of the scale value, it would seem simpler to represent the mantissa and the exponent values X * 10 ^ Y.   Perhaps it's possible to create a normalized Exponent TC in RFC3433 itself.

4. Additions to our MIB may require units for watt-hours and volt-amperes for reactive power.  These aren't currently available in RFC3433. Note: we see that RFC2579 section 5 foresee the way to update an TC.

5. In the broader standard developments for SmartGrid projects and electrical meters, our thinking is that using domain specific units for electrical values provides greater clarity than the general purpose sensor model with a focus of networking devices.

So, since we’re not measuring WAGES (water, air, gas, electricity, and steam), only electricity, we initially thought about defining an electricity centric MIB module. One extra reason is that the MIB module scope is quite large

          "The target devices include: routers, switches, attached devices
          such as Power over Ethernet (PoE) devices, middle boxes, home
          energy gateway, hosts and servers, sensor proxy, etc."

we can't assume that the ENTITY-MIB will be always be implemented. What
if we need a proxy table in the future?
However, we have foreseen the case where it is, with

          emPhysicalEntity OBJECT-TYPE
              SYNTAX          PhysicalIndexOrZero
              MAX-ACCESS      read-only
              STATUS          current
              DESCRIPTION
                 "This object contains the index of a physical entity in
                 the ENTITY MIB.  This physical entity is the given
                 Observation Point. If such a physical entity cannot be
                 specified or is not known then the object is zero."
              ::= { emEntry 3 }

This should make the link with the ENTITY-MIB, and the ENTITY-SENSOR-MIB, if available.

Regards, Benoit.

> On Thu, Jan 14, 2010 at 05:06:14PM +0100, Benoit Claise wrote:
>
>    
>> This new draft is about a MIB module that contains the energy monitoring
>> and power states of network elements, addressing the requirements in
>> draft-quittek-power-monitoring-requirements-00.txt.
>> This works has been inspired by an existing MIB module, already
>> implemented: CISCO-ENERGYWISE-MIB.my
>> Please review it. As always, your feedback is welcome.
>>      
> My main question is why we can't leverage better the ENTITY-MIBs we
> have in place for reporting energy levels etc, extending them were
> needed.
>
> - If it is important to report a UUID, we could generalize this as an
>    extension of the ENTITY-MIB.
>
> - EnergyMonitorPowerScale seems to achieve the same goals as
>    EntitySensorDataScale - why not use the standard TC?
>
> - I suggest to disallow 0 for emIndex so that it can be used as a NULL
>    value in cases references are ever made to emTable.
>
> - It is unclear what "non-null" means for emDeviceId since
>    EnergyMonitorId has a fixed length of 16 octets.
>
> - The concept of a domain remains unclear to me. It seems that all
>    emEntries tagged with the same value in emDomainName form a domain -
>    but then what is such a domain good for? There is nothing I can
>    really do at a domain level - so this is really just some tagging
>    mechanism, no?
>
> - It seems that the notion of a 'domain' in the description of
>    EnergyMonitorId is different from the notion of a 'domain' mentioned
>    above. If they are the same, the uniqueness constraint and indexing
>    scheme probably do not match up.
>
> - Some emEntry attributes seem to duplicate ENTITY-MIB objects.
>
> - Am I correct that negative energy usage applies to power sources?
>    If so, please spell this out in the emEnergyUsage description
>    clause and the emEnergyUsageNameplate description clause (should
>    this not be named emEnergyMaxUsage?).
>
> - emEnergyUsageCategory could have been modelled as a BITS object, but
>    that does not really make a big difference.
>
> - emVersion and emEnable seem to overlap with existing ENTITY-MIB /
>    ENTITY-STATE-MIB objects
>
> - It needs to be clarified whether changes via SNMP write operations
>    are persistent or not
>
> - The security considerations of course need some work at some point
>    in time...
>
> - Perhaps "PowerState" is a better name for EnergyMonitorLevel and
>    emPowerState might be clearer than emEnergyLevel.
>
> - There was an interesting paper recently pointing out that reporting
>    the current state is often not as useful as reporting the time spent
>    in each state. This is also mentioned in the requirements ID and I
>    think valuable to consider to consider here (so I do not have to do
>    aggressive monitoring to find out the distribution of power states a
>    component used during the last 24 hours or so).
>
> Bottom line: I believe this is useful input for work on MIB modules
> but I consider a solution that is more tightly integrated into the
> ENTITY-MIBs, extending them where necessary, a better approach. Is it
> really too hard to assume devices implement the basic table of the
> ENTITY-MIB? Or is there another reason why extending the ENTITY-MIB
> was not considered?
>
> /js
>
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 2 Feb 2010 13:01:01 +0100

Hi Benoit,

See in-line. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Benoit Claise

> 
> we can't assume that the ENTITY-MIB will be always be 
> implemented. What if we need a proxy table in the future?

Why not? What kind of proxy table you have in mind and why would it
preclude the ENTITY-MIB? 

> ENTITY-SENSOR-MIB, if available.

You can actually use entPhysicalIndex as the index of the tables in the
new MIB module, which would create an automatic linkage to the
ENTITY-MIB and ENTITY-SENOSR-MIB if available.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 02 Feb 2010 14:58:08 +0100

Hi Dan,
> Why not? What kind of proxy table you have in mind and why would it
For example, a converged building gateway, monitoring several other 
devices in the buidling, doing the proxy between SNMP <-> a protocol 
such as BACNET
Another example is the home energy controller.
Even with a PoE device, how to monitor this device with the 
entPhysicalIndex, which relates to the switch to which the PoE device is 
attached.
> ENTITY-MIB and ENTITY-SENOSR-MIB if available.
Yes, we thought about that.
As above, the question is: can we assume that the ENTITY-MIB is always 
present?
Whenever we want to monitor the power consumption of router or switches, 
we can have this assumption. Sure.
So the biggest question: what is the scope of the work?

Regards, Benoit.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 2 Feb 2010 16:16:52 +0100

Yes, but this is not sufficient reason for defining a new MIB that
duplicates part of the ENTITY_MIB functionality as another standard MIB.
If part of the functionality already exists we should use this and add
what is missing.  

Dan

> From: Brad Schoening [mailto:[email-masked]] 
> Sent: Tuesday, February 02, 2010 4:51 PM
> To: Romascanu, Dan (Dan); 'Benoit Claise'; [email-masked]; 
> 'John Parello (jparello)'
> Subject: RE: [OPSAWG] monitoring power state and energy 
> consumption: draft-claise-energy-monitoring-mib-00.txt is a 
> new draft -> RFC3433
> 
> Dan,
> 
> I've spoken to several vendors in the power management space 
> that have SNMP solutions.  For example, Schneider Electric's 
> subsidiary Square D manufactures intelligent meters with SNMP 
> support, and CyberSwitching makes intelligent PDU's (Power 
> Distribution Units).  Neither of these companies implement 
> the ENTITY-MIB.
> 
> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Tuesday, February 02, 2010 7:01 AM
> To: Benoit Claise; [email-masked]; John Parello (jparello); 
> Brad Schoening
> Subject: RE: [OPSAWG] monitoring power state and energy consumption:
> draft-claise-energy-monitoring-mib-00.txt is a new draft -> RFC3433
> 
> Hi Benoit,
> 
> See in-line. 
> 
> Dan
> 
> 
> > we can't assume that the ENTITY-MIB will be always be implemented. 
> > What if we need a proxy table in the future?
> 
> Why not? What kind of proxy table you have in mind and why 
> would it preclude the ENTITY-MIB? 
> 
> >                  "This object contains the index of a 
> physical entity 
> > in
> >                  Observation Point. If such a physical 
> entity cannot 
> > be
> You can actually use entPhysicalIndex as the index of the 
> tables in the new MIB module, which would create an automatic 
> linkage to the ENTITY-MIB and ENTITY-SENOSR-MIB if available. 
> 
> > 
> > Regards, Benoit.
> > 
> 
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 3 Feb 2010 10:51:05 +0100

Just as a side observation - the ENTITY-SENSOR-MIB does not list
separate enumerated entries for multiples or submultiples of units, but
rather defines two different objects for basic unit and scale. 

Dan

> Sent: Tuesday, February 02, 2010 9:24 PM
> Looking at the Johnson Controls MSEA-MIB they define over 300 
> types of units, with, granted, some duplication.
> 
> http://www.johnsoncontrols.com/publish/etc/medialib/jci/be/com
> mercial/ahr_ex
> po/resources.Par.94449.File.tmp/mseami2.txt
> 
> 
> UnitsEnum ::= TEXTUAL-CONVENTION

---

From: "Brad Schoening" <[email-masked]>
Date: Tue, 2 Feb 2010 14:23:55 -0500

Looking at the Johnson Controls MSEA-MIB they define over 300 types of
units, with, granted, some duplication.

http://www.johnsoncontrols.com/publish/etc/medialib/jci/be/commercial/ahr_ex
po/resources.Par.94449.File.tmp/mseami2.txt

UnitsEnum ::= TEXTUAL-CONVENTION
    STATUS        current
    DESCRIPTION
        "Units enumeration"
    SYNTAX        INTEGER {
        -- Square meters
        squareMeters(0),
        -- Square feet
        squareFeet(1),
        -- Milliamperes
        milliAmperes(2),
        -- Amperes
        amperes(3),
        -- Resistance,4
        ohms(4),
        -- Volts
        volts(5),
        -- Kilovolts (1,000 volts)
        kiloVolts(6),
        -- Megavolts (1 million volts)
        megaVolts(7),
        -- Volt amperes
        voltAmperes(8),
        -- Kilovolt amperes
        kilovoltAmperes(9),
        -- Megavolt amperes
        megavoltAmperes(10),
        -- Volt amperes reactive
        voltAmperesReactive(11),
        -- Kilovolt amperes reactive
        kilovoltAmperesReactive(12),
        -- Megavolt amperes reactive
        metavoltAmperesReactive(13),
        -- Degrees phase
        degreesPhase(14),
        -- Power factor
        powerFactor(15),
        -- Joules
        joules(16),
        -- Kilojoules
        kiloJoules(17),
        -- Watt hours
        wattHours(18),
        -- Kilowatt hours
        kiloWattHours(19),
        -- British thermal unit
        btus(20),
        -- Therms
        therms(21),
        -- Ton hours
        tonHours(22),
        -- Joules per kilogram dry air
        joulesPerKilogramDryAir(23),
        -- BTUs per pound dry air
        btusPerPoundDryAir(24),
        -- Cycles per hour
        cyclesPerHour(25),
        -- Cycles per minute
        cyclesPerMinute(26),
        -- Hertz
        hertz(27),
        -- Grams of water per kilogram of dry air
        gramsWaterPerKilogramDryAir(28),
        -- Percent relative humidity
        percentRelativeHumidity(29),
        -- Millimeters
        millimeters(30),
        -- Meters
        meters(31),
        -- Inches
        inches(32),
        -- Feet
        feet(33),
        -- Watts per square foot
        wattsPerSquareFoot(34),
        -- Watts per square meter
        wattsPerSquareMeter(35),
        -- Lumens
        lumens(36),
        -- Luxes
        luxes(37),
        -- Foot candles
        footCandles(38),
        -- Kilograms
        kilograms(39),
        -- Pounds mass
        poundsMass(40),
        -- English tons
        tons(41),
        -- Kilograms per second
        killogramsPerSecond(42),
        -- Kilograms per minute
        kilogramsPerMinute(43),
        -- Kilograms per hour
        kilogramsPerHour(44),
        -- Pounds mass per minute
        poundsMassPerMinute(45),
        -- Pounds mass per hour
        poundsMassPerHour(46),
        -- Watts
        watts(47),
        -- Kilowatts
        kilowatts(48),
        -- Megawatts
        megawatts(49),
        -- Btus per hour
        btusPerHour(50),
        -- Horsepower
        horsepower(51),
        -- Tons of Refrigeration
        tonsRefrigeration(52),
        -- Pascals
        pascals(53),
        -- Kilopascals
        kilopascals(54),
        -- Bars
        bars(55),
        -- Pounds force per square inch
        poundsPerSquareInch(56),
        -- Centimeters water column
        centimetersOfWater(57),
        -- Inches water column
        inchesOfWater(58),
        -- Millimeters of Mercury
        millimetersOfMercury(59),
        -- Centimeters of Mercury
        centimetersOfMercury(60),
        -- Inches of Mercury
        inchesOfMercury(61),
        -- Degrees Celsius
        degreesCelsius(62),
        -- Degrees Kelvin
        degreesKelvin(63),
        -- Degrees Fahrenheit
        degreesFarenheight(64),
        -- Degree days Celsius
        degreeDaysCelsius(65),
        -- Degree days Fahrenheit
        degreeDaysFarenheight(66),
        -- Year/s
        years(67),
        -- Month/s
        months(68),
        -- Week/s
        weeks(69),
        -- Day/s
        days(70),
        -- Hours
        hours(71),
        -- Minutes
        minutes(72),
        -- Seconds
        seconds(73),
        -- Meters per second
        metersPerSecond(74),
        -- Kilometers per hour
        kilometersPerHour(75),
        -- Feet per second
        feetPerSecond(76),
        -- Feet per minute
        feetPerMinute(77),
        -- Miles per hour
        milesPerHour(78),
        -- Cubic feet
        cubicFeet(79),
        -- Cubic meters
        cubicMeters(80),
        -- Imperial gallons
        imperialGallons(81),
        -- Liters
        liters(82),
        -- U.S. gallons
        usGallons(83),
        -- Cubic feet per minute
        cubicFeetPerMinute(84),
        -- Cubic meters per second,
        cubicMetersPerSecond(85),
        -- Imperial gallons per minute
        imperialGallonsPerMinute(86),
        -- Liters per second
        litersPerSecond(87),
        -- Liters per minute
        litersPerMinute(88),
        -- U.S. gallons per minute
        usGallonsPerMinute(89),
        -- Degrees angular
        degreesAngular(90),
        -- Degrees Celsius per hour
        degreesCelsiusPerHour(91),
        -- Degrees Celsius per minute
        degreesCelsiusPerMinute(92),
        -- Degrees Fahrenheit per hour
        degreesFarenheitPerHour(93),
        -- Degrees Fahrenheit per minute
        degreesFarenheitPerMinute(94),
        -- No units have been specified
        noUnits(95),
        -- Parts per million
        partsPerMillion(96),
        -- Parts per billion
        partsPerBillion(97),
        -- Percent
        percent(98),
        -- Percent per second
        percentPerSecond(99),
        -- Per minute
        perMinute(100),
        -- Per second
        perSecond(101),
        -- Psi per degree Fahrenheit
        psiPerDegreeFahrenheit(102),
        -- Radians
        radians(103),
        -- Revolutions per minute
        revolutionsPerMinute(104),
        -- Currency 1
        currency1(105),
        -- Currency 2
        currency2(106),
        -- Currency 3
        currency3(107),
        -- Currency 4
        currency4(108),
        -- Currency 5
        currency5(109),
        -- Currency 6
        currency6(110),
        -- Currency 7
        currency7(111),
        -- Currency 8
        currency8(112),
        -- Currency 9
        currency9(113),
        -- Currency 10
        currency10(114),
        -- Square inches
        squareInches(115),
        -- Square Centimeters
        squareCentimeters(116),
        -- Btu per pound
        btusPerPound(117),
        -- Centimeters
        centimeters(118),
        -- Pounds of mass per second
        poundsMassPerSecond(119),
        -- degrees Fahrenheit (Change in temperature)
        degreesFarenheitDelta(120),
        -- degrees Kelvin (Change in temperature)
        degreesKelvinDelta(121),
        -- Kilohms
        kilohms(122),
        -- Megohms
        megohms(123),
        -- Millivolts
        millivolts(124),
        -- Kilojoules per kilogram
        kilojoulesPerKilogram(125),
        -- Megajoules
        megajoules(126),
        -- Joules per degree Kelvin
        joulesPerDegreeKelvin(127),
        -- Joules per kilogram Kelvin
        joulesPerKilogramDegreesKelvin(128),
        -- Kilohertz
        kilohertz(129),
        -- Megahertz
        megahertz(130),
        -- Per hour
        perHour(131),
        -- Milliwatts
        milliwatts(132),
        -- Hectopascals
        hectopascals(133),
        -- Millibars
        millibars(134),
        -- Cubic meters per hour
        cubicMetersPerHour(135),
        -- Liters per hour
        litersPerHour(136),
        -- Kilowatt hours per square meter
        kilowattHoursPerSquareMeter(137),
        -- Kilowatt hours per square foot
        kilowattHoursPerSquareFoot(138),
        -- Megajoules per square meter
        megajoulesPerSquareMeter(139),
        -- Megajoules per square foot
        megajoulesPerSquareFoot(140),
        -- Watts per square meter Kelvin
        wattsPerSquareMeterDegreesKelvin(141),
        -- Cubic feet per second
        cubicFeetPerSecond(142),
        -- Percent obscuration per foot
        percentObscurationPerFoot(143),
        -- Percent obscuration per meter
        percentObscurationPerMeter(144),
        -- Milliohm
        milliohms(145),
        -- Megawatt Hours
        megawattHours(146),
        -- Kilo British thermal unit
        kiloBTU(147),
        -- Mega British thermal unit
        megaBTU(148),
        -- Kilojoules per kilogram dry air
        kilojoulesPerKilogramDryAir(149),
        -- Megahoules per kilogram dry air
        megajoulesPerKilogramDryAir(150),
        -- Kilojoules per degree Kelvin
        kilojoulesPerDegreeKelvin(151),
        -- Megajoules per degree Kelvin
        megajoulesPerDegreeKelvin(152),
        -- Newton
        newton(153),
        -- Grams per second
        gramsPerSecond(154),
        -- Grams per minute
        gramsPerMinute(155),
        -- Tons per hour
        tonsPerHour(156),
        -- Kilo BTUs per hour
        kiloBtusPerHour(157),
        -- Hundredths of a second
        hundredthsOfSecond(158),
        -- Milliseconds
        milliseconds(159),
        -- Newton Meters
        newtonMeters(160),
        -- Millimeters per second
        millimetersPerSecond(161),
        -- Millimeters per minute
        millimetersPerMinute(162),
        -- Meters per hour
        metersPerHour(163),
        -- Meters per minute
        metersPerMinute(164),
        -- Cubic meters per minute
        cubicMetersPerMinute(165),
        -- Meters per second per second
        metersPerSecondPerSecond(166),
        -- Amperes per meter
        amperesPerMeter(167),
        -- Amperes per square meter
        amperesPerSquareMeter(168),
        -- Amperes square meters
        amperesSquareMeters(169),
        -- Farads
        farads(170),
        -- Henrys
        henrys(171),
        -- Ohm meters
        ohmMeters(172),
        -- Siemens
        siemens(173),
        -- Siemens per meter
        siemensPerMeter(174),
        -- Teslas
        teslas(175),
        -- Volts per degree Kelvin
        voltsPerDegreeKelvin(176),
        -- Volts per meter
        voltsPerMeter(177),
        -- Webers
        webers(178),
        -- Candelas
        candelas(179),
        -- Candelas per square meter
        candelasPerSquareMeter(180),
        -- Degrees Kelvin per aquare meter
        degreesKelvinPerHour(181),
        -- Degrees Kelvin per minute
        degreesKelvinPerMinute(182),
        -- Joule seconds
        jouleSeconds(183),
        -- Radians per second
        radiansPerSecond(184),
        -- Square meters per Newton
        squareMetersPerNewton(185),
        -- Kilograms per cubic meter
        kilogramsPerCubicMeter(186),
        -- Newton seconds
        newtonSeconds(187),
        -- Newtons per meter
        newtonsPerMeter(188),
        -- Watts per meter per degree Kelvin
        wattsPerMeterPerDegreeKelvin(189),
        -- Bytes
        bytes(256),
        -- Milliseconds (JCI)
        millisecondsJci(257),
        -- Counts
        counts(258),
        -- People
        people(259),
        -- Cfm/person
        cfmPerPerson(260),
        -- Liters per person
        litersPerPerson(261),
        -- Minutes per degree squared
        minutesPerDegreeSquared(262),
        -- Kilowatts per minute
        kilowattsPerMinute(263),
        -- Percent open
        percentOpen(264),
        -- Percent closed
        percentClosed(265),
        -- Flow C Cfm
        flowcCfm(266),
        -- Flow C cubic meters per hour
        flowcCubicMetersPerHour(267),
        -- Flow C cubic liters per second
        flowcLitersPerSecond(268),
        -- Hundredths of sec (JCI)
        hundredthsOfSecJci(269),
        -- Entries
        entries(270),
        -- K factor
        kFactor(271),
        -- Custom units
        customUnits(272),
        -- Radians Per Second (JCI)
        radiansPerSecondJci(273),
        -- Acre units
        acreUnits(274),
        -- Atmosphere units
        atmosphereUnits(275),
        -- Cubic inches
        cubicInches(276),
        -- Decibel Units
        decibelUnits(277),
        -- Degrees per second
        degreesPerSecond(278),
        -- Feet of water
        feetOfWater(279),
        -- Foot pounds
        footPounds(280),
        -- Formazin nephelometric units
        formazinNephelometricUnits(281),
        -- Formazin turbidity units
        formazinTurbidityUnits(282),
        -- Grammage units
        grammageUnits(283),
        -- Grams
        grams(284),
        -- kiloBtu (JCI)
        kiloBtuJci(285),
        -- Kilo gallons per minute
        kiloGallonsPerMinute(286),
        -- Kilopounds
        kilopounds(287),
        -- Kilograms per cubic meter (JCI)
        kilogramsPerCubicMeterJci(288),
        -- Kiloliters
        kiloliters(289),
        -- Kilo meters
        kilometers(290),
        -- MegaBTU (JCI)
        megaBtuJci(291),
        -- Megagrams
        megagrams(292),
        -- Micrometers
        micrometers(293),
        -- Miles
        miles(294),
        -- Milligrams
        milligrams(295),
        -- Milliliters per second
        millilitersPerSec(296),
        -- Millimeters of water
        millimetersOfWater(297),
        -- Nephelometric turbidity units
        nephelometricTurbidityUnits(298),
        -- Ph units
        phUnits(299),
        -- Milliliters
        milliliters(300),
        -- Megabytes
        megabytes(301),
        -- Percent command
        percentCommand(302),
        -- Inches pascal
        inchesPascal(303),
        -- Kilocalories per kilogram
        kilocaloriesPerKilogram(304),
        -- Hour:minute
        hourMinute(305),
        -- Seconds per hour
        secondsPerHour(306),
        -- Grams per cubic meter
        gramsPerCubicMeter(307),
        -- Pounds per cubic feet
        poundsPerCubicFeet(308),
        -- Change per minute
        changePerMinute(309),
        -- Digits
        digits(310),
        -- Attempts
        attempts(311),
        -- Entities
        entities(312),
        -- Kilobytes
        kilobytes(313)
    }

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, February 02, 2010 10:17 AM
To: Brad Schoening; Benoit Claise; [email-masked]; John Parello (jparello)
Subject: RE: [OPSAWG] monitoring power state and energy consumption:

Dan

---

From: "Brad Schoening" <[email-masked]>
Date: Wed, 3 Feb 2010 11:17:44 -0500

Dan,

I agree that's a naïve mistake in the Johnson Control MIB.  Taking out the
scalar duplicates, the Johnson MIB still has 170 distinct unit types.

CIM has defined a similar CIM_Sensor object which is interesting for
comparison with the ENTITY-SENSOR-MIB.  The majority of the Johnson unit
types are covered by the CIM_Sensor unit types.

1. CIM_NumericSensor defines RateUnits.  If the RateUnits property is set to
a value other than "None", then the units are further qualified as rate
units.  Valid values are: None, Per MicroSecond, Per MilliSecond, Per
Second, Per Minute, Per Hour, Per Day, Per Week, Per Month, Per Year

   This avoids the redundancy of having to define watts and watt-hours.

2. CIM_Numeric Sensor defines UnitModifier.  The unit multiplier for the
values returned by this Sensor. All the values returned by this Sensor are
represented in the units obtained by (BaseUnits * 10 raised to the power of
the UnitModifier). For example, if BaseUnits is Volts and the Unit Modifier
is -6, then the units of the values returned are MicroVolts.

   Similar to EntitySensorDataScale, but it's an exponent value, not a index
in a lookup table.

1. CIM_NumericSensor defines 65 types of BaseUnits:

	Unknown, Other, Degrees C, 
	Degrees F, Degrees K, Volts, 
	Amps, Watts, Joules, 
	Coulombs, VA, Nits, 
	Lumens, Lux, Candelas, 
	kPa, PSI, Newtons, 
	CFM, RPM, Hertz, 
	Seconds, Minutes, Hours, 
	Days, Weeks, Mils, 
	Inches, Feet, Cubic Inches, 
	Cubic Feet, Meters, Cubic Centimeters, 
	Cubic Meters, Liters, Fluid Ounces, 
	Radians, Steradians, Revolutions, 
	Cycles, Gravities, Ounces, 
	Pounds, Foot-Pounds, Ounce-Inches, 
	Gauss, Gilberts, Henries, 
	Farads, Ohms, Siemens, 
	Moles, Becquerels, PPM (parts/million), 
	Decibels, DbA, DbC, 
	Grays, Sieverts, Color Temperature Degrees K, 
	Bits, Bytes, Words (data), 
	DoubleWords, QuadWords, Percentage, 
	Pascals

    These 65 types can be combined with rate-units to create several hundred
unit types.  This compares with only 9 basic unit types in the
Entity-Sensor-MIB.
  
For further details of the CIM_NumericSensor, see

http://www.vmware.com/support/developer/cim-sdk/smash/u2/ga/apirefdoc/CIM_Nu
mericSensor.html

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, February 03, 2010 4:51 AM
To: Brad Schoening; Benoit Claise; [email-masked]; John Parello (jparello)
Subject: RE: [OPSAWG] monitoring power state and energy consumption:

Dan

---

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Feb 2010 10:46:47 +0100

Juergen, but also Carl, Andy, Dan, Minoru, All,

Thanks for providing feedback.
We have posted a new version of the draft at 
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-01
We have added:
     - an emDemandTable, along with a emDemandControlTable,which lists 
the EnergyMonitor Entity energy usage measurements
     - some clarification text
Regarding the question related to the relationship with the 
ENTITY/ENTITY-SENSOR MIB, we have extended our justification in:
     - section 5.1.1. Link with the ENTITY-MIB and the ENTITY-SENSOR-MIB

See inline for more answers.
>    value in cases references are ever made to emTable.
Done.
>    EnergyMonitorId has a fixed length of 16 octets.
Remove. Btw, we renamed emDeviceId to emEnergyMonitorId: this is more in 
line with the terminology
>    really do at a domain level - so this is really just some tagging
We have a new definition: EnergyMonitor Domain

           A EnergyMonitor Domain is a name or name space which
           logically groups together EnergyMonitor Entities that
           comprises a unit of manageable power consumption.  For
           example, all phones in a floor, all EnergyMonitor Entities
           from a specific building, or all EnergyMonitor Entities of a
           specific device type for which a common profile is deployed.
           From the point of monitoring power consumption, it is useful
           to report the total energy consumed as the sum of energy
           consumed by all the EnergyMonitor Entities of the
           EnergyMonitor Domain.

>    scheme probably do not match up.
We're not sure what you mean.

         emEnergyMonitorId OBJECT-TYPE
             SYNTAX          EnergyMonitorId
             MAX-ACCESS      read-only
             STATUS          current
             DESCRIPTION
                "This object indicates the EnergyMonitor UUID identifier.
                This object value must be unique within the EnergyMonitor
                Domain."

Is this because you see Universal UID, while we say "unique per 
EnergyMonitor Domain" ,which is a kind of obvious statement?

>    clause
Good point. Added to the emEnergyUsage description, and also added some 
clarification text
> and the emEnergyUsageNameplate description clause (should
Note: MaxUsage is the maximum usage for a given level; whereas the 
UsageNameplate is the usage predicted at the maximum usage level.
UsageNameplate is intended to be the maximum power the device could 
theoretically draw.  It's important for power provisioning.
UsageNameplate is usually higher than MaxUsage, depending upon the 
chassis configuration.

>    that does not really make a big difference.
Make sense. Done.
> - emVersion and emEnable seem to overlap with existing ENTITY-MIB /
Not sure. The emVersion specifies the current version of the 
EnergyMonitor software
How could we model with the ENTITY-STATE MIB?
Same question for the emEnable. Let's assume that the ENTITY-MIB is 
present. How can we say: on the top of the ENITTY, monitor the energy?

> - It needs to be clarified whether changes via SNMP write operations
We clarified this for all read-write OID.
> - The security considerations of course need some work at some point
Yeap, in the to do list. ;-)
>    emPowerState might be clearer than emEnergyLevel.
No strong opinion on that. If others feel like it, sure, we'll change it
>    component used during the last 24 hours or so).
Instead of keeping a table in the SNMP agent, we have chosen a design 
based on

         emLevelChange NOTIFICATION-TYPE
             OBJECTS         { emIndex, emEnergyLevel }
             STATUS          current
             DESCRIPTION
                 "The SNMP entity generates the EmLevelChange when
                 the value of emEnergyLevel has changed for the
                EnergyMonitor Entity represented by the emIndex"
            ::= { energyMonitorMIBNotifs 1 }

         [POWER-MON-REQ] specifies some requirements about power states
         such as "the current state - the time of the last change", "the
         total time spent in each state", "the number of transitions to
         each state", etc...  Such requirements are fulfilled thanks to
         the emLevelChange NOTIFICATION-TYPE, indexed by the emIndex and
         the emEnergyLevel, which is generated when the value of
         emEnergyLevel has changed for the EnergyMonitor Entity
         represented by the emIndex.  Indeed, assuming that the SNMP
         notifications arrives to Network Management Station (NMS), the
         NMS can deduce all the information.

> ENTITY-MIB? Or is there another reason why extending the ENTITY-MIB
Thanks for your feedback.

Regards, Benoit.