Network Working Group M. Chandramouli Internet-Draft Cisco Systems, Inc. Intended Status: Standards Track B. Schoening Expires: February 5, 2012 Independent Consultant J. Quittek T. Dietz NEC Europe Ltd. B. Claise Cisco Systems, Inc. August 5, 2011 Power and Energy Monitoring MIB draft-eman-energy-monitoring-mib-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 2012. Expires February 5 2012 [Page 1] Internet-Draft August 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction............................................ 3 2. The Internet-Standard Management Framework.............. 4 3. Use Cases............................................... 4 4. Terminology............................................. 5 5. Architecture Concepts Applied to the MIB Module......... 5 5.1. Power Monitor Information............................ 11 5.2. Power State.......................................... 12 5.2.1. Power State Set...............................13 5.2.2. IEEE1621 Power State Set......................13 5.2.3. DMTF Power State Set..........................13 5.2.4. EMAN Power State Set..........................14 5.3. Power Monitor Usage Information...................... 17 5.4. Optional Power Usage Quality......................... 18 5.5. Optional Energy Measurement.......................... 19 Expires February 5, 2012 [Page 2] Internet-Draft August 2011 5.6. Fault Management...................................... 22 6. Discovery............................................... 23 6.1. ENERGY-AWARE-MIB Module Implemented................... 23 6.2. ENERGY-AWARE-MIB Module Not Implemented, ENTITY-MIB Implemented................................................ 24 6.3. ENERGY-AWARE-MIB Module and ENTITY-MIB Not Implemented.24 7. Link with the other IETF MIBs........................... 24 7.1. Link with the ENTITY MIB and the ENTITY-SENSOR MIB..24 7.2. Link with the ENTITY-STATE MIB......................26 7.3. Link with the POWER-OVER-ETHERNET MIB...............26 7.4. Link with the UPS MIB...............................27 7.5. Link with the LLDP and LLDP-MED MIBs................28 8. Implementation Scenario................................. 29 9. Structure of the MIB.................................... 31 10. MIB Definitions........................................ 31 11. Security Considerations................................ 66 12. IANA Considerations.................................... 67 12.1. IANA Considerations for the MIB Modules.............. 67 12.2. IANA Registration of new Power State Set............. 67 12.2.1. IANA Registration of the IEEE1621 Power State Set.68 12.2.2. IANA Registration of the DMTF Power State Set.....68 12.2.3. IANA Registration of the EMAN Power State Set.....69 12. Contributors........................................... 69 13. Acknowledgment......................................... 69 14. Open Issues............................................ 69 15. References............................................. 72 15.2. Normative References...............................72 15.3. Informative References.............................72 1. Introduction This document defines a subset of the Management Information Base (MIB) for use in energy management of devices within or connected to communication networks. The MIB modules in this document are designed to provide a model for energy management, which includes monitoring for power state and energy consumption of networked elements. This MIB takes into account the Power Management Architecture [EMAN-FRAMEWORK], which in turn, is based on the Power Monitoring Requirements [EMAN-REQ]. Energy management is applicable to devices in communication networks. Target devices for this specification include (but are not limited to): routers, switches, Power over Ethernet (PoE) endpoints, protocol gateways for building management Expires February 5, 2012 [Page 3] Internet-Draft August 2011 systems, intelligent meters, home energy gateways, hosts and servers, sensor proxies, etc. Where applicable, device monitoring extends to the individual components of the device and to any attached dependent devices. For example: A device can contain components that are independent from a power-state point of view, such as line cards, processor cards, hard drives. A device can also have dependent attached devices, such as a switch with PoE endpoints or a power distribution unit with attached endpoints. Devices and their sub-components may be characterized by the power-related attributes of a physical entity present in the ENTITY MIB, even though the ENTITY MIB compliance is not a requirement due to the variety and broad base of devices concerned with energy management. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies MIB modules that are compliant to SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Use Cases Requirements for power and energy monitoring for networking devices are specified in [EMAN-REQ]. The requirements in [EMAN- REQ] cover devices typically found in communications networks, such as switches, routers, and various connected endpoints. For a power monitoring architecture to be useful, it should also apply to facility meters, power distribution units, gateway proxies for commercial building control, home automation devices, and devices that interface with the utility and/or smart grid. Accordingly, the scope of the MIB modules in this document is broader than that specified in [EMAN-REQ]. Several use cases for Energy Management have been identified in the "Energy Management (EMAN) Applicability Statement" [EMAN-AS]. An Expires February 5, 2012 [Page 4] Internet-Draft August 2011 illustrative example scenario is presented in Section 8. " Implementation Scenario". 4. Terminology The definitions of basic terms like Power Monitor, Power Monitor Parent, Power Monitor Child, Power Monitor Meter Domain, Power State can be found in the Power Management Architecture [EMAN- FRAMEWORK]. EDITOR'S NOTE: it is foreseen that some more term will follow such a Proxy, Aggregator, Energy Management, etc... Power State Set A Power State Set is defined as a sequence of incremental energy saving modes of a device. The elements of this set can be viewed as an interface for the underlying device- implemented power settings of a device. Examples of Power State Sets include DTMF [DMTF], IEEE1621 [IEEE1621], ACPI [ACPI] and EMAN. Power State A Power State is defined as a specific power setting for a Power Monitor (e.g., shut, hibernate, sleep, high). Within the context of a Power State Set, the Power State of a device is one of the power saving modes in that Power State Set. EDITOR'S NOTE: the definitions of Power State Series and Power State should be copied over in [EMAN-FRAMEWORK], and referenced here. 5. Architecture Concepts Applied to the MIB Module This section describes the concepts specified in the Power Monitor Architecture [EMAN-FRAMEWORK] that pertain to power usage, with specific information related to the MIB module specified in this document. This subsection maps to the section "Architecture High Level Concepts" in the Power Monitoring Architecture [EMAN-FRAMEWORK]. The Energy Monitoring MIB has 2 independent MIB modules. The first MIB module powerMonitorMIB is focused on measurement of power and energy. The second MIB module powerQualityMIB is focused on Power Quality measurement. Expires February 5, 2012 [Page 5] Internet-Draft August 2011 The powerMonitorMIB MIB module consists of four tables. The first table pmPowerTable is indexed by pmPowerIndex and pmPowerStateSetIndex. The second table pmPowerStateTable indexed by pmPowerIndex, pmPowerStateSetIndex and pmPowerStateIndex. pmEnergyParametersTable and pmEnergyTable are indexed by pmPowerIndex. pmPowerTable(1) | +---pmPowerEntry(1) [pmPowerIndex, pmPowerStateSet] | | | +-- --- Integer32 pmPowerIndex(1) | +-- --- PowerStateSet pmPowerStateSet(2) | +-- r-n Integer32 pmPower(3) | +-- r-n Integer32 pmPowerNamePlate(4) | +-- r-n UnitMultiplier pmPowerUnitMultiplier(5) | +-- r-n Integer32 pmPowerAccuracy(6) | +-- r-n INTEGER pmMeasurementCaliber(7) | +-- r-n INTEGER pmPowerCurrentType(8) | +-- r-n INTEGER pmPowerOrigin(9) | +-- rwn Integer32 pmPowerAdminState(10) | +-- r-n Integer32 pmPowerOperState(11) | +-- r-n OwnerString pmPowerStateEnterReason(12) | | | | +---pmPowerStateTable(2) | +--pmPowerStateEntry(1) | | [pmPowerIndex, | | pmPowerStateSet, | | pmpowerStateIndex] | +-- --- Integer32 pmPowerStateIndex(1) | +-- r-n Interger32 pmPowerStateMaxPower (2) | +-- r-n UnitMultiplier | pmPowerStatePowerUnitMultiplier (3) | +-- r-n TimeTicks pmPowerStateTotalTime(4) | +-- r-n Counter64 pmPowerStateEnterCount(5) | +pmEnergyParametersTable(1) +---pmEnergyParametersEntry(1) [pmPowerIndex] | | +-- r-n TimeInterval | pmEnergyParametersIntervalLength (1) | +-- r-n Integer32 | pmEnergyParametersIntervalNumber (2) | +-- r-n Integer32 | pmEnergyParametersIntervalMode (3) Expires February 5, 2012 [Page 6] Internet-Draft August 2011 | +-- r-n TimeInterval | pmEnergyParametersIntervalWindow (4) | +-- r-n Integer32 | pmEnergyParametersSampleRate (5) | +-- r-n RowStatus pmEnergyParametersStatus (6) | +pmEnergyTable(1) +---pmEnergyEntry(1) [pmPowerIndex] | | +-- r-n TimeInterval pmEnergyIntervalStartTime (1) | +-- r-n Integer32 pmEnergyIntervalEnergyUsed (2) | +-- r-n UnitMultiplier | pmEnergyIntervalEnergyUnitMultiplier (3) | +-- r-n Integer32 pmEnergyIntervalMax (4) | +-- r-n TimeTicks | pmEnergyIntervalDiscontinuityTime(5) | +-- r-n RowStatus pmEnergyParametersStatus (6) The powerQualityMIB consists of four tables. PmACPwrQualityTable is indexed by pmPowerIndex. PmACPwrQualityPhaseTable is indexed by pmPowerIndex and pmPhaseIndex. pmACPwrQualityWyePhaseTable and pmACPwrQualityDelPhaseTable are indexed by pmPowerIndex and pmPhaseIndex. pmPowerTable(1) | +---PmACPwrQualityEntry (1) [pmPowerIndex] | | | | | +----- INTEGER pmACPwrQualityConfiguration (1) | +-- r-n Interger32 pmACPwrQualityAvgVoltage (2) | +-- r-n Integer32 pmACPwrQualityAvgCurrent (3) | +-- r-n Integer32 pmACPwrQualityFrequency (4) | +-- r-n UnitMultiplier | pmACPwrQualityPowerUnitMultiplier (5) | +-- r-n Integer32 pmACPwrQualityPowerAccuracy (6) | +-- r-n Interger32 pmACPwrQualityTotalActivePower (7) | +-- r-n Integer32 | pmACPwrQualityTotalReactivePower (8) | +-- r-n Integer32 pmACPwrQualityTotalApparentPower (9) | +-- r-n Integer32 pmACPwrQualityTotalPowerFactor(10) | +-- r-n Integer32 pmACPwrQualityThdAmpheres (11) | +pmACPwrQualityPhaseTable (1) +---PmACPwrQualityPhaseEntry(1)[pmPowerIndex, | | pmPhaseIndex] | | Expires February 5, 2012 [Page 7] Internet-Draft August 2011 | +-- r-n Integer32 pmPhaseIndex (1) | +-- r-n Integer32 | | pmACPwrQualityPhaseAvgCurrent (2) | +-- r-n Integer32 | | pmACPwrQualityPhaseActivePower (3) | +-- r-n Integer32 | | pmACPwrQualityPhaseReactivePower (4) | +-- r-n Integer32 | | pmACPwrQualityPhaseApparentPower (5) | +-- r-n Integer32 | | pmACPwrQualityPhasePowerFactor (6) | +-- r-n Integer32 | | pmACPwrQualityPhaseImpedance (7) | | +pmACPwrQualityDelPhaseTable (1) +-- pmACPwrQualityDelPhaseEntry(1) | | [pmPowerIndex, | | pmPhaseIndex] | +-- r-n Integer32 | | pmACPwrQualityDelPhaseToNextPhaseVoltage (1) | +-- r-n Integer32 | | pmACPwrQualityDelThdPhaseToNextPhaseVoltage (2) | +-- r-n Integer32 pmACPwrQualityDelThdCurrent (3) | | +pmACPwrQualityWyePhaseTable (1) +-- pmACPwrQualityWyePhaseEntry (1) | | [pmPowerIndex, | | pmPhaseIndex] | +-- r-n Integer32 | | pmACPwrQualityWyePhaseToNeutralVoltage (1) | +-- r-n Integer32 | | pmACPwrQualityWyePhaseCurrent (2) | +-- r-n Integer32 | | pmACPwrQualityWyeThdPhaseToNeutralVoltage (3) | . A UML representation of the MIB objects in the two MIB modules are powerMonitorMIB and powerQualityMIB are presented. Expires February 5, 2012 [Page 8] Internet-Draft August 2011 +--------------------------+ | PowerMonitor ID | | | | Energy-aware-MIB (*) | | | +---------------------------+ | | | | | pmPowerIndex | | PowerMonitor Attributes | | pmPowerStateSetIndex | | | +--------------------------+ | pmPowerNamePlate | | | | pmPowerMeasurementCaliber | | | | pmPowerOrigin | | | | pmPowerCurrentType | | | +---------------------------+ | | | | | | v | v +-----------------------------------------+ | PowerMonitor Measurement | | | | pmPower | | pmPowerUnitMultiplier | | pmPowerAccuracy | +-----------------------------------------+ ^ | ^ | | | +-------------------------+ | | | PowerMonitor State | | +------------------------+ | | | | PowerMonitor State | | pmPowerAdminState | | | Statistics | | pmPowerOperState | | | | | pmPowerStateEnterReason | | | pmPowerStateMaxPower | +-------------------------+ | | pmPowerStateTotalTime | | | pmPowerStateEnterCount | | +------------------------+ | | | | Figure 1:UML diagram for powerMonitor MIB (*) Link with the ENERGY-AWARE-MIB Expires February 5, 2012 [Page 9] Internet-Draft August 2011 | | | V +------------------------------------+ | Energy Table | | | | pmEnergyIntervalStartTime | | pmEnergyIntervalEnergyUsed | | pmEnergyIntervalMax | | pmEnergyIntervalDiscontinuityTime | +------------------------------------+ +--------------------------+ | PowerMonitor ID | | | | Energy-aware-MIB (*) | | | | pmPowerIndex | | pmPowerStateSetIndex | +--------------------------+ | v +-------------------------------------+ | Power Quality | | | | pmACPwrQualityConfiguration | | pmACPwrQualityAvgVoltage | | pmACPwrQualityAvgCurrent | pmACPwrQualityFrequency | | pmACPwrQualityPowerUnitMultiplier | | pmACPwrQualityPowerAccuracy | | pmACPwrQualityTotalActivePower | | pmACPwrQualityTotalReactivePower | | pmACPwrQualityTotalApparentPower | | pmACPwrQualityTotalPowerFactor | | pmACPwrQualityThdAmpheres | +-------------------------------------+ ^ ^ ^ | | | ------- | ---- | | | | | | | +-------------------------------------+ | | | Power Phase Quality | | | Expires February 5, 2012 [Page 10] Internet-Draft August 2011 | | | | | pmPhaseIndex | | | | pmACPwrQualityPhaseAvgCurrent | | | | pmACPwrQualityAvgCurrent | | | | pmACPwrQualityFrequency | | | | pmACPwrQualityPowerUnitMultiplier | | | | pmACPwrQualityPowerAccuracy | | | | pmACPwrQualityPhaseActivePower | | | | pmACPwrQualityPhaseReactivePower | | | | pmACPwrQualityPhaselApparentPower | | | | pmACPwrQualityPhaseImpedance | | | +-------------------------------------+ | | | | | | +---------------------------------------------+ | | Power Quality DEL Configuration | | | | | | pmACPwrQualityDelPhaseToNextPhaseVoltage | | | pmACPwrQualityDelThdPhaseToNextPhaseVoltage | | | pmACPwrQualityDelThdCurrent | | +---------------------------------------------+ | | | +---------------------------------------------+ | Power Quality WYE Configuration | | | | pmACPwrQualityWyePhaseToNeutralVoltage | | pmACPwrQualityWyePhaseCurrent | | pmACPwrQualityWyeThdPhaseToNeutralVoltage | +---------------------------------------------+ Figure 2: UML diagram for the powerQualityMIB 5.1. Power Monitor Information Refer to the "Power Monitor Information" section in [EMAN- FRAMEWORK] for background information. An energy aware device is considered an instance of a Power Monitor as defined in the [EMAN-FRAMEWORK]. The Power Monitor identity information is specified in the MIB ENERGY-AWARE-MIB module [EMAN-AWARE-MIB] primary table, i.e. the pmTable.In this table, every Power Monitor SHOULD have a printable name pmName, and MUST HAVE a unique Power Monitor index pmIndex. The ENERGY-AWARE-MIB module returns the relationship (parent/child) between Power Monitors. Expires February 5, 2012 [Page 11] Internet-Draft August 2011 EDITOR'S NOTE: this last sentence will have to be updated with terms such as Aggregator, Proxy, etc... when the [EMAN- FRAMEWORK] will stabilize. 5.2. Power State Refer to the "Power Monitor States" section in [EMAN-FRAMEWORK] for background information. A Power Monitor may have energy conservation modes called Power States. Between the ON and OFF states of a device, there can be several intermediate energy saving modes. Those energy saving modes are called as Power States. Power States, which represent universal states of power management of a Power Monitor, are specified by the pmPowerState MIB object. The actual Power State is specified by the pmPowerOperState MIB object, while the pmPowerAdminState MIB object specifies the Power State requested for the Power Monitor. The difference between the values of pmPowerOperState and pmPowerAdminState can be attributed that the Power Monitor is busy transitioning from pmPowerAdminState into the pmPowerOperState, at which point it will update the content of pmPowerOperState. In addition, the possible reason for change in Power State is reported in pmPowerStateEnterReason. Regarding pmPowerStateEnterReason, management stations and Power Monitors should support any format of the owner string dictated by the local policy of the organization. It is suggested that this name contain at least the reason for the transition change, and one or more of the following: IP address, management station name, network manager's name, location, or phone number. The MIB objects pmPowerOperState, pmPowerAdminState , and pmPowerStateEnterReason are contained in the pmPowerTable MIB table. The pmPowerStateTable table enumerates the maximum power usage in watts, for every single supported Power State of each Power State Set supported by the Power Monitor In addition, PowerStateTable provides additional statistics: pmPowerStateEnterCount, the number of times an entity has visited a particular Power State, and pmPowerStateTotalTime, the total time spent in a particular Power State of a Power Monitor. Expires February 5, 2012 [Page 12] Internet-Draft August 2011 5.2.1. Power State Set There are several standards and implementations of Power State Sets. A Power Monitor can support one or multiple Power State Set implementation(s) concurrently. There are currently three Power State Sets advocated: Reserved(0) IEEE1621(1) - [IEEE1621] DMTF(2) - [DMTF] EMAN(3) - [EMAN-MONITORING-MIB] The respective specific states related to each Power State Set are specified in the following sections. 5.2.2. IEEE1621 Power State Set The IEEE1621 Power State Set [IEEE1621] consists of 3 rudimentary states : on, off or sleep. on(0) - The device is fully On and all features of the device are in working mode. off(1) - The device is mechanically switched off and does not consume energy. sleep(2) - The device is in a power saving mode, and some features may not be available immediately. 5.2.3. DMTF Power State Set DMTF [DMTF] standards organization has defined a power profile standard based on the CIM (Common Information Model) model that consists of 15 power states ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off-Soft (6), Hibernate(7), PowerCycle Off- Soft (8), PowerCycle Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt (11), Off-Soft-Graceful (12), Off-Hard Graceful (13), MasterBus reset Graceful (14), Power-Cycle Off- Soft Graceful (15), PowerCycle-Hard Graceful (16). DMTF standard is targeted for hosts and computers. Details of the semantics of each Power State within the DMTF Power State Set can be obtained from the DMTF Power State Management Profile specification [DMTF]. DMTF power profile extends ACPI power states. The following table provides a mapping between DMTF and ACPI Power State Set: Expires February 5, 2012 [Page 13] Internet-Draft August 2011 --------------------------------------------------- | DMTF | ACPI | | Power State | Power State | --------------------------------------------------- | Reserved(0) | | --------------------------------------------------- | Reserved(1) | | --------------------------------------------------- | ON (2) | G0-S0 | -------------------------------------------------- | Sleep-Light (3) | G1-S1 G1-S2 | -------------------------------------------------- | Sleep-Deep (4) | G1-S3 | -------------------------------------------------- | Power Cycle (Off-Soft) (5) | G2-S5 | --------------------------------------------------- | Off-hard (6) | G3 | --------------------------------------------------- | Hibernate (Off-Soft) (7) | G1-S4 | --------------------------------------------------- | Off-Soft (8) | G2-S5 | --------------------------------------------------- | Power Cycle (Off-Hard) (9) | G3 | --------------------------------------------------- | Master Bus Reset (10) | G2-S5 | --------------------------------------------------- | Diagnostic Interrupt (11) | G2-S5 | --------------------------------------------------- | Off-Soft Graceful (12) | G2-S5 | --------------------------------------------------- | Off-Hard Graceful (13) | G3 | --------------------------------------------------- | MasterBus Reset Graceful (14) | G2-S5 | --------------------------------------------------- | Power Cycle off-soft Graceful (15)| G2-S5 | --------------------------------------------------- | Power Cycle off-hard Graceful (16)| G3 | --------------------------------------------------- Figure 3: DMTF and ACPI Powe State Set Mapping 5.2.4. EMAN Power State Set The EMAN Power State Set represents an attempt for a uniform standard approach to model the different levels of power consumption of a device. The EMAN Power States are an expansion of the basic Power States as defined in IEEE1621 that also Expires February 5, 2012 [Page 14] Internet-Draft August 2011 incorporate the Power States defined in ACPI and DMTF. Therefore, in addition to the non-operational states as defined in ACPI and DMTF standards, several intermediate operational states have been defined. There are twelve Power States, that expand on IEEE1621 on,sleep and off. The expanded list of Power States are divided into six operational states, and six non-operational states. The lowest non-operational state is 1 and the highest is 6. Each non- operational state corresponds to an ACPI state [ACPI] corresponding to Global and System states between G3 (hard-off) and G1 (sleeping). For Each operational state represent a performance state, and may be mapped to ACPI states P0 (maximum performance power) through P5 (minimum performance and minimum power). An Power Monitor may have fewer Power States than twelve and would then map several policy states to the same power state. Power Monitor with more than twelve states, would choose which twelve to represent as power policy states. In each of the non-operational states (from mechoff(1) to ready(6)), the Power State preceding it is expected to have a lower power consumption and a longer delay in returning to an operational state: IEEE1621 Power(off): mechoff(1) : An off state where no entity features are available. The entity is unavailable. No energy is being consumed and the power connector can be removed. This corresponds to ACPI state G3. softoff(2) : Similar to mechoff(1), but some components remain powered or receive trace power so that the entity can be awakened from its off state. In softoff(2), no context is saved and the device typically requires a complete boot when awakened. This corresponds to ACPI state G2. IEEE1621 Power(sleep) hibernate(3): No entity features are available. The entity may be awakened without requiring a complete boot, but the time for Expires February 5, 2012 [Page 15] Internet-Draft August 2011 availability is longer than sleep(4). An example for state hibernate(3) is a save to-disk state where DRAM context is not maintained. Typically, energy consumption is zero or close to zero. This corresponds to state G1, S4 in ACPI. sleep(4) : No entity features are available, except for out-of-band management, for example wake-up mechanisms. The time for availability is longer than standby(5). An example for state sleep(4) is a save- to-RAM state, where DRAM context is maintained. Typically, energy consumption is close to zero. This corresponds to state G1, S3 in ACPI. standby(5) : No entity features are available, except for out-of-band management, for example wake-up mechanisms. This mode is analogous to cold-standy. The time for availability is longer than ready(6). For example, the processor context is not maintained. Typically, energy consumption is close to zero. This corresponds to state G1, S2 in ACPI. ready(6) : No entity features are available, except for out-of-band management, for example wake-up mechanisms. This mode is analogous to hot-standby. The entity can be quickly transitioned into an operational state. For example, processors are not executing, but processor context is maintained. This corresponds to state G1, S1 in ACPI. IEEE1621 Power(on): lowMinus(7) : Indicates some entity features may not be available and the entity has selected measures/options to provide less than low(8) usage. This corresponds to ACPI State G0. This includes operational states lowMinus(7) to full(12). low(8) : Indicates some features may not be available and the entity has taken Expires February 5, 2012 [Page 16] Internet-Draft August 2011 measures or selected options to provide less than mediumMinus(9) usage. mediumMinus(9): Indicates all entity features are available but the entity has taken measures or selected options to provide less than medium(10) usage. medium(10) : Indicates all entity features are available but the entity has taken measures or selected options to provide less than highMinus(11) usage. highMinus(11): Indicates all entity features are available and power usage is less than high(12). high(12) : Indicates all entity features are available and the entity is consuming the highest power. 5.3. Power Monitor Usage Information Refer to the "Power Monitor Usage Measurement" section in [EMAN- FRAMEWORK] for background information. For a Power Monitor, power usage is reported using pmPower. The magnitude of measurement is based on the pmPowerUnitMultiplier MIB variable, based on the UnitMultiplier Textual Convention (TC). Power measurement magnitude should conform to the IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] definition of unit multiplier for the SI (System International) units of measure. Measured values are represented in SI units obtained by BaseValue * 10 raised to the power of the scale. For example, if current power usage of a Power Monitor is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value of pmPowerUnitMultiplier. Note that other measurements throughout the two MIB modules in this document use the same mechanism, including pmPowerStatePowerUnitMultiplier, pmEnergyIntervalEnergyUnitMultiplier, and pmACPwrQualityPowerUnitMultiplier. In addition to knowing the usage and magnitude, it is useful to know how a pmPower measurement was obtained. An NMS can use this to account for the accuracy and nature of the reading Expires February 5, 2012 [Page 17] Internet-Draft August 2011 between different implementations. For this pmPowerOrigin describes whether the measurements were made at the device itself or from a remote source. The pmPowerMeasurementCaliber describes the method that was used to measure the power and can distinguish actual or estimated values. There may be devices in the network, which may not be able to measure or report power consumption. For those devices, the object pmPowerMeasurementCaliber shall report that measurement mechanism is "unavailable" and the pmPower measurement shall be "0". The nameplate power rating of a Power Monitor is specified in pmPowerNameplate MIB object. 5.4. Optional Power Usage Quality Refer to the "Optional Power Usage Quality" section in [EMAN- FRAMEWORK] for background information. The optional powerQualityMIB MIB module can be implemented to further describe power usage quality measurement. The powerQualityMIB MIB module adheres closely to the IEC 61850 7-2 standard to describe AC measurements. The powerQualityMIB MIB module contains a primary table, the pmACPwrQualityTable table, that defines power quality measurements for supported pmIndex entities, as a sparse extension of the pmPowerTable (with pmPowerIndex as primary index). This pmACPwrQualityTable table contains such information as the configuration (single phase, DEL 3 phases, WYE 3 phases), voltage, frequency, power accuracy, total active/reactive power/apparent power, amperage, and voltage. In case of 3-phase power, the pmACPwrQualityPhaseTable additional table is populated with power quality measurements per phase (so double indexed by the pmPowerIndex and pmPhaseIndex). This table, which describes attributes common to both WYE and DEL configurations, contains the average current, active/reactive/apparent power, power factor, and impedance. In case of 3-phase power with a DEL configuration, the pmACPwrQualityDelPhaseTable table describes the phase-to-phase power quality measurements, i.e., voltage and current. In case of 3-phase power with a Wye configuration, the pmACPwrQualityWyePhaseTable table describes the phase-to-neutral power quality measurements, i.e., voltage and current. Expires February 5, 2012 [Page 18] Internet-Draft August 2011 5.5. Optional Energy Measurement Refer to the "Optional Energy and demand Measurement" section in [EMAN-FRAMEWORK] for the definition and terminology information. It is relevant to measure energy when there are actual power measurements from a Power Monitor, and not when the power measurement is assumed or predicted as specified in the description clause of the object pmPowerMeasurementCaliber. Two tables are introduced to characterize energy measurement of a Power Monitor: pmEnergyTable and pmEnergyParametersTable. Both energy and demand information can be represented via the pmEnergyTable. Energy information will be an accumulation with no interval. Demand information can be represented as an average accumulation per interval of time. The pmEnergyParametersTable consists of the parameters defining the duration of measurement intervals in seconds, (pmEnergyParametersIntervalLength), the number of successive intervals to be stored in the pmEnergyTable, (pmEnergyParametersIntervalNumber), the type of measurement technique (pmEnergyParametersIntervalMode), and a sample rate used to calculate the average (pmEnergyParametersSampleRate). Judicious choice of the sampling rate will ensure accurate measurement of energy while not imposing an excessive polling burden. There are three pmEnergyParametersIntervalMode types used for energy measurement collection: period, sliding, and total. The choices of the the three different modes of collection are based on IEC standard 61850-7-4. Note that multiple pmEnergyParametersIntervalMode types MAY be configured simultaneously. These three pmEnergyParametersIntervalMode types are illustrated by the following three figures, for which: - The horizontal axis represents the current time, with the symbol <--- L ---> expressing the pmEnergyParametersIntervalLength, and the pmEnergyIntervalStartTime is represented by S1, S2, S3, S4, ..., Sx where x is the value of pmEnergyParametersIntervalNumber. - The vertical axis represents the time interval of sampling and the value of pmEnergyIntervalEnergyUsed can be obtained at the Expires February 5, 2012 [Page 19] Internet-Draft August 2011 end of the sampling period. The symbol =========== denotes the duration of the sampling period. | | | =========== | |============ | | | | | | | | |============ | | | | | | | <--- L ---> | <--- L ---> | <--- L ---> | | | | | S1 S2 S3 S4 Figure 4 : Period pmEnergyParametersIntervalMode A pmEnergyParametersIntervalMode type of 'period' specifies non- overlapping periodic measurements. Therefore, the next pmEnergyIntervalStartTime is equal to the previous pmEnergyIntervalStartTime plus pmEnergyParametersIntervalLength. S2=S1+L; S3=S2+L, ... |============ | | | | <--- L ---> | | | | |============ | | | | | | <--- L ---> | | | | | | |============ | | | | | | | | <--- L ---> | | | | | | | | |============ | | | | | | | | | | <--- L ---> | S1 | | | | | | | | | | | | S2 | | | | | | | | | S3 | | | | | | S4 Expires February 5, 2012 [Page 20] Internet-Draft August 2011 Figure 5 : Sliding pmEnergyParametersIntervalMode A pmEnergyParametersIntervalMode type of 'sliding' specifies overlapping periodic measurements. | | |========================= | | | | | | | | <--- Total length ---> | | | S1 Figure 4 : Total pmEnergyParametersIntervalMode A pmEnergyParametersIntervalMode type of 'total' specifies a continuous measurement since the last reset. The value of pmEnergyParametersIntervalNumber should be (1) one and pmEnergyParametersIntervalLength is ignored. The pmEnergyParametersStatus is used to start and stop energy usage logging. The status of this variable is "active" when all the objects in pmEnergyParametersTable are appropriate which in turn indicates if pmEnergyTable entries exist or not. The pmEnergyTable consists of energy measurements inpmEnergyIntervalEnergyUsed , the units of the measured energy pmEnergyIntervalEnergyUnitMultiplier, and the maximum observed energy within a window - pmEnergyIntervalMax. Measurements of the total energy consumed by a Power Monitor may suffer from interruptions in the continuous measurement of energy consumption. In order to indicate such interruptions, the object pmEnergyIntervalDiscontinuityTime is provided for indicating the time of the last interruption of total energy measurement. pmEnergyIntervalDiscontinuityTime shall indicate the sysUpTime [RFC3418] when the device was reset. The following example illustrates the pmEnergyTable and pmEnergyParametersTable: First, in order to estimate energy, a time interval to sample energy should be specified, i.e. pmEnergyParametersIntervalLength can be set to "900 seconds" or 15 minutes and the number of consecutive intervals over which Expires February 5, 2012 [Page 21] Internet-Draft August 2011 the maximum energy is calculated (pmEnergyParametersIntervalNumber) as "10". The sampling rate internal to the Power Monitor for measurement of power usage (pmEnergyParametersSampleRate) can be "1000 milliseconds", as set by the Power Monitor as a reasonable value. Then, the pmEnergyParametersStatus is set to active (value 1) to indicate that the Power Monitor should start monitoring the usage per the pmEnergyTable. The indices in the pmEnergyTable are pmPowerIndex, which identifies the Power Monitor, and pmEnergyIntervalStartTime, which denotes the start time of the energy measurement interval based on sysUpTime [RFC3418]. The value of pmEnergyIntervalEnergyUsed is the measured energy consumption over the time interval specified (pmEnergyParametersIntervalLength) based on the Power Monitor internal sampling rate (pmEnergyParametersSampleRate). While choosing the values for the pmEnergyParametersIntervalLength and pmEnergyParametersSampleRate, it is recommended to take into consideration either the network element resources adequate to process and store the sample values, and the mechanism used to calculate the pmEnergyIntervalEnergyUsed. The units are derived from pmEnergyIntervalPowerUnitMultiplier. For example, pmEnergyIntervalPowerUsed can be "100" with pmEnergyIntervalPowerUnits equal to 0, the measured energy consumption of the Power Monitor is 100 watt-hours. The pmEnergyIntervalMax is the maximum energyobserved and that can be "150 watt-hours". The pmEnergyTable has a buffer to retain a certain number of intervals, as defined by pmEnergyParametersIntervalNumber. If the default value of "10" is kept, then the pmEnergyTable contains 10 energymeasurements, including the maximum. Here is a brief explanation of how the maximum energy can be calculated. The first observed energy measurement value is taken to be the initial maximum. With each subsequent measurement, based on numerical comparison, maximum energy may be updated. The maximum value is retained as long as the measurements are taking place. Based on periodic polling of this table, an NMS could compute the maximum over a longer period, i.e. a month, 3 months, or a year. 5.6. Fault Management [EMAN-REQ] specifies requirements about Power States such as "the current power state" , "the time of the last state change", Expires February 5, 2012 [Page 22] Internet-Draft August 2011 "the total time spent in each state", "the number of transitions to each state" etc. Some of these requirements are fulfilled explicitly by MIB objects such as pmPowerOperState, pmPowerStateTotalTime and pmPowerStateEnterCount. Some of the other requirements are met via the SNMP NOTIFICATION mechanism. pmPowerStateChange SNMP notification which is generated when the value(s) of pmPowerStateSet, pmPowerOperState, pmPowerAdminState have changed. 6. Discovery 6.1. ENERGY-AWARE-MIB Module Implemented The NMS must first poll the ENERGY-AWARE-MIB module [EMAN-AWARE- MIB], if available, in order to discover all the Power Monitors and the relationships between those (notion of Parent/Child). In the ENERGY-AWARE-MIB module tables, the Power Monitors are indexed by the pmIndex. If an implementation of the ENERGY-AWARE-MIB module is available in the local SNMP context, for the same Power Monitor, the pmIndex value (EMAN-AWARE-MIB) MUST be assigned to the pmPowerIndex for The pmPowerIndex characterizes the Power Monitor in the powerMonitorMIB and powerQualityMIB MIB modules (this document). From there, the NMS must poll the pmPowerStateTable (specified in the powerMonitorMIB module in this document), which enumerates, amongst other things, the maximum power usage. As the entries in pmPowerStateTable table are indexed by the Power Monitor (pmPowerIndex), by the Power State Set (pmPowerStateSetIndex), and by the Power State (pmPowerStateIndex), the maximum power usage is discovered per Power Monitor, per Power State Set, and per Power Usage. In other words, polling the pmPowerStateTable allows the discovery of each Power State within every Power State Set supported by the Power Monitor. If the Power Monitor is an Aggregator or a Proxy, the MIB module would be populated with the Power Monitor Parent and Children information, which have their own Power Monitor index value (pmPowerIndex). However, the parent/child relationship must be discovered thanks to the ENERGY-AWARE-MIB module. Finally, the NMS can monitor the Power Quality thanks to the powerQualityMIB MIB module, which reuses the pmPowerIndex to index the Power Monitor. Expires February 5, 2012 [Page 23] Internet-Draft August 2011 6.2. ENERGY-AWARE-MIB Module Not Implemented, ENTITY-MIB Implemented When the ENERGY-AWARE-MIB module [EMAN-AWARE-MIB] is not implemented, the NMS must poll the ENTITY-MIB [RFC4133] in order to discover some more information about the Power Monitors. Indeed, the index for the Power Monitors in the MIB modules specified in this document is the pmPowerIndex, which specifies: "If there is no implementation of the ENERGY-AWARE-MIB module but one of the ENTITY MIB module is available in the local SNMP context, then the same index of an entity MUST be chosen as assigned to the entity by object entPhysicalIndex in the ENTITY MIB module." As the Section 6.1. , the NMS must then poll the pmPowerStateTable (specified in the powerMonitorMIB module in this document), indexed by the Power Monitor (pmPowerIndex that inherited the entPhysicalIndex value), by the Power State Set (pmPowerStateSetIndex), and by the Power State (pmPowerStateIndex). Then the NMS has discovered every Power State within each Power State Set supported by the Power Monitor. Note that, without the ENERGY-AWARE-MIB module, the Power Monitor acts as an standalone device, i.e. the notion of parent/child can't be specified. 6.3. ENERGY-AWARE-MIB Module and ENTITY-MIB Not Implemented If neither the ENERGY-AWARE-MIB module [EMAN-AWARE-MIB] nor of the ENTITY MIB module [RFC4133] are available in the local SNMP context, then this MIB module may choose identity values from a further MIB module providing entity identities. Note that, without the ENERGY-AWARE-MIB module, the Power Monitor acts as an standalone device, i.e. the notion of parent/child can't be specified. 7. Link with the other IETF MIBs 7.1. Link with the ENTITY MIB and the ENTITY-SENSOR MIB RFC 4133 [RFC4133] defines the ENTITY MIB module that lists the physical entities of a networking device (router, switch, etc.) Expires February 5, 2012 [Page 24] Internet-Draft August 2011 and those physical entities indexed by entPhysicalIndex. From an energy-management standpoint, the physical entities that consume or produce energy are of interest. RFC 3433 [RFC3433] defines the ENTITY-SENSOR MIB module that provides a standardized way of obtaining information (current value of the sensor, operational status of the sensor, and the data units precision) from sensors embedded in networking devices. Sensors are associated with each index of entPhysicalIndex of the ENTITY MIB [RFC4133]. While the focus of the Power and Energy Monitoring MIB is on measurement of power usage of networking equipment indexed by the ENTITY MIB, this MIB proposes a customized power scale for power measurement and different power state states of networking equipment, and functionality to configure the power state states. When this MIB module is used to monitor the power usage of devices like routers and switches, the ENTITY MIB and ENTITY- SENSOR MIB SHOULD be implemented. In such cases, the Power Monitors are modeled by the entPhysicalIndex through the pmPhysicalEntity MIB object specified in the pmTable in the ENERGY-AWARE-MIB MIB module [EMAN-AWARE-MIB]. However, the ENTITY-SENSOR MIB [RFC3433] does not have the ANSI C12.x accuracy classes required for electricity (i.e., 1%, 2%, 0.5% accuracy classes). Indeed, entPhySensorPrecision [RFC3433] represents "The number of decimal places of precision in fixed- point sensor values returned by the associated entPhySensorValue object". The ANSI and IEC Standards are used for power measurement and these standards require that we use an accuracy class, not the scientific-number precision model specified in RFC3433. The pmPowerAccuracy MIB object models this accuracy. Note that pmPowerUnitMultipler represents the scale factor per IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22], which is a more logical representation for power measurements (compared to entPhySensorScale), with the mantissa and the exponent values X * 10 ^ Y. Power measurements specifying the qualifier 'UNITS' for each measured value in watts are used in the LLDP-EXT-MED-MIB, POE [RFC3621], and UPS [RFC1628] MIBs. The same 'UNITS' qualifier is used for the power measurement values. One cannot assume that the ENTITY MIB and ENTITY-SENSOR MIB are implemented for all Power Monitors that need to be monitored. A typical example is a converged building gateway, monitoring several other devices in the building, doing the proxy between SNMP and a protocol like BACNET. Another example is the home Expires February 5, 2012 [Page 25] Internet-Draft August 2011 energy controller. In such cases, the pmPhysicalEntity value contains the zero value, thanks to PhysicalIndexOrZero textual convention. The pmPowerIndex MIB object has been kept as the unique Power Monitor index. The pmPower is similar to entPhySensorValue [RFC3433] and the pmPowerUnitMultipler is similar to entPhySensorScale. 7.2. Link with the ENTITY-STATE MIB For each entity in the ENTITY-MIB [RFC4133], the ENTITY-STATE MIB [RFC4268] specifies the operational states (entStateOper: unknown, enabled, disabled, testing), the alarm (entStateAlarm: unknown, underRepair, critical, major, minor, warning, indeterminate) and the possible values of standby states (entStateStandby: unknown, hotStandby, coldStandby, providingService). From a power monitoring point of view, in contrast to the entity operational states of entities, Power States are required, as proposed in the Power and Energy Monitoring MIB module. Those Power States can be mapped to the different operational states in the ENTITY-STATE MIB, if a formal mapping is required. For example, the entStateStandby "unknown", "hotStandby", "coldStandby", states could map to the Power State "unknown", "ready", "standby", respectively, while the entStateStandby "providingService" could map to any "low" to "high" Power State. 7.3. Link with the POWER-OVER-ETHERNET MIB Power-over-Ethernet MIB [RFC3621] provides an energy monitoring and configuration framework for power over Ethernet devices. The RFC introduces a concept of a port group on a switch to define power monitoring and management policy and does not use the entPhysicalIndex as the index. Indeed, the pethMainPseConsumptionPower is indexed by the pethMainPseGroupIndex, which has no mapping with the entPhysicalIndex. One cannot assume that the Power-over-Ethernet MIB is implemented for all Power Monitors that need to be monitored. A typical example is a converged building gateway, monitoring several other devices in the building, doing the proxy between SNMP and a protocol like BACNET. Another example is the home energy controller. In such cases, the pmethPortIndex and Expires February 5, 2012 [Page 26] Internet-Draft August 2011 pmethPortGrpIndex values contain the zero value, thanks to new PethPsePortIndexOrZero and textual PethPsePortGroupIndexOrZero conventions. However, if the Power-over-Ethernet MIB [RFC3621] is supported, the Power Monitor pmethPortIndex and pmethPortGrpIndex contain the pethPsePortIndex and pethPsePortGroupIndex, respectively. As a consequence, the pmPowerIndex MIB object has been kept as the unique Power Monitor index. Note that, even though the Power-over-Ethernet MIB [RFC3621] was created after the ENTITY-SENSOR MIB [RFC3433], it does not reuse the precision notion from the ENTITY-SENSOR MIB, i.e. the entPhySensorPrecision MIB object. 7.4. Link with the UPS MIB To protect against unexpected power disruption, data centers and buildings make use of Uninterruptible Power Supplies (UPS). To protect critical assets, a UPS can be restricted to a particular subset or domain of the network. UPS usage typically lasts only for a finite period of time, until normal power supply is restored. Planning is required to decide on the capacity of the UPS based on output power and duration of probable power outage. To properly provision UPS power in a data center or building, it is important to first understand the total demand required to support all the entities in the site. This demand can be assessed and monitored via the Power and Energy Monitoring MIB. UPS MIB [RFC1628] provides information on the state of the UPS network. Implementation of the UPS MIB is useful at the aggregate level of a data center or a building. The MIB module contains several groups of variables: - upsIdent: Identifies the UPS entity (name, model, etc.). - upsBattery group: Indicates the battery state (upsbatteryStatus, upsEstimatedMinutesRemaining, etc.) - upsInput group: Characterizes the input load to the UPS (number of input lines, voltage, current, etc.). - upsOutput: Characterizes the output from the UPS (number of output lines, voltage, current, etc.) - upsAlarms: Indicates the various alarm events. Expires February 5, 2012 [Page 27] Internet-Draft August 2011 The measurement of power in the UPS MIB is in Volts, Amperes and Watts. The units of power measurement are RMS volts and RMS Amperes. They are not based on the EntitySensorDataScale and EntitySensorDataPrecision of Entity-Sensor MIB. Both the Power and Energy Monitoring MIB and the UPS MIB may be implemented on the same UPS SNMP agent, without conflict. In this case, the UPS device itself is the Power Monitor Parent and any of the UPS meters or submeters are the Power Monitor Children. 7.5. Link with the LLDP and LLDP-MED MIBs The LLDP Protocol is a Data Link Layer protocol used by network devices to advertise their identities, capabilities, and interconnections on a LAN network. The Media Endpoint Discovery is an enhancement of LLDP, known as LLDP-MED. The LLDP-MED enhancements specifically address voice applications. LLDP-MED covers 6 basic areas: capability discovery, LAN speed and duplex discovery, network policy discovery, location identification discovery, inventory discovery, and power discovery. Of particular interest to the current MIB module is the power discovery, which allows the endpoint device (such as a PoE phone) to convey power requirements to the switch. In power discovery, LLDP-MED has four Type Length Values (TLVs): power type, power source, power priority and power value. Respectively, those TLVs provide information related to the type of power (power sourcing entity versus powered device), how the device is powered (from the line, from a backup source, from external power source, etc.), the power priority (how important is it that this device has power?), and how much power the device needs. The power priority specified in the LLDP-MED MIB [LLDP-MED-MIB] actually comes from the Power-over-Ethernet MIB [RFC3621]. If the Power-over-Ethernet MIB [RFC3621] is supported, the exact value from the pethPsePortPowerPriority [RFC3621] is copied over in the lldpXMedRemXPoEPDPowerPriority [LLDP-MED-MIB]; otherwise the value in lldpXMedRemXPoEPDPowerPriority is "unknown". From the Power and Energy Monitoring MIB, it is possible to identify the pethPsePortPowerPriority [RFC3621], thanks to the pmethPortIndex and pmethPortGrpIndex. Expires February 5, 2012 [Page 28] Internet-Draft August 2011 The lldpXMedLocXPoEPDPowerSource [LLDP-MED-MIB] is similar to pmPowerOrigin in indicating if the power for an attached device is local or from a remote device. If the LLDP-MED MIB is supported, the following mapping can be applied to the pmPowerOrigin: lldpXMedLocXPoEPDPowerSource fromPSE(2) and local(3) can be mapped to remote(2) and self(1), respectively. 8. Implementation Scenario This section provides an illustrative example scenario for the implementation of the Power Monitor, including Power Monitor Parent and Power Monitor Child relationships. Example Scenario of a campus network: Switch with PoE Endpoints with further connected Devices The campus network consists of switches that provide LAN connectivity. The switch with PoE ports is located in wiring closet. PoE IP phones are connected to the switch. The IP phones draw power from the PoE ports of the switch. In addition, a PC is daisy-chained from the IP phone for LAN connectivity. The IP phone consumes power from the PoE switch, while the PC consumes power from the wall outlet. The switch has implementations of Entity MIB [RFC4133] and energy-aware MIB [EMAN-AWARE-MIB] while the PC does not have implementation of the Entity MIB, but has an implementation of energy-aware MIB. The switch has the following attributes, pmPowerIndex "1", pmPhysicalEntity "2", and pmPowerMonitorId "UUID 1000". The power usage of the switch is "440 Watts". The switch does not have a Power Monitor Parent. The PoE switch port has the following attributes: The switch port has pmPowerIndex "3", pmPhysicalEntity is "12" and pmPowerMonitorId is "UUID 1000:3". The power metered at the POE switch port is "12 watts". In this example, the POE switch port has the switch as the Power Monitor Parent, with its pmParentID of "1000". The attributes of the PC are given below. The PC does not implementation of Entity MIB, and thus does not have pmPhysicalEntity. The pmPowerIndex (pmPIndex) of the PC is "57", the pmPowerMonitorId is "UUID 1000:57 ". The PC has a Power Monitor Parent, i.e. the switch port whose Expires February 5, 2012 [Page 29] Internet-Draft August 2011 pmPowerMonitorId is "UUID 1000:3". The power usage of the PC is "120 Watts" and is communicated to the switch port. This example illustrates the important distinction between the Power Monitor Children: The IP phone draws power from the switch, while the PC has LAN connectivity from the phone, but is powered from the wall outlet. However, the Power Monitor Parent sends power control messages to both the Power Monitor Children (IP phone and PC) and the Children react to those messages. |--------------------------------------------------------------| | Switch | |==============================================================| | Switch | Switch | Switch | Switch | Switch | | pmPIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmPower | | ============================================================ | | 1 | 2 | UUID 1000 | null | 440 | | ============================================================ | | | | SWITCH PORT | | ============================================================ | | | Switch | Switch | Switch | Switch | Switch | | | Port | Port | Port | Port | Port | | | | pmPIndex| pmPhyIdx | pmPowerMonId | pmParentId | pmPower | | | ============================================================ | | | 3 | 12 | UUID 1000:3 | UUID 1000 | 12 | | | ============================================================ | | ^ | | | | |-----------------------------------|--------------------------| | | POE IP PHONE | | | ============================================================= | IP phone | IP phone |IP phone |IP phone |IP phone| | pmPIndex | pmPhyIdx |pmPowerMonitorId|pmParentID |pmPower| =========================================================== | 31 | 0 | UUID 1000:31 | UUID 1000:3 | 12 | ============================================================ | | PC connected to switch via IP phone | | ============================================================= | PC | PC |PC |PC | PC | |pmPIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmPower | Expires February 5, 2012 [Page 30] Internet-Draft August 2011 ============================================================ | 57 | 0 | UUID 1000:57 | UUID 1000:3 | 120 | ============================================================= Figure 1: Example scenario 9. Structure of the MIB The primary MIB object in this MIB module is the PowerMonitorMIBObject. The pmPowerTable table of PowerMonitorMibObject describes the power measurement attributes of a Power Monitor entity. The notion of identity of the device in terms of uniquely identification of the Power Monitor and its relationship to other entities in the network are addressed in [EMAN-AWARE-MIB]. The power measurement of Power Monitor contains information describing its power usage (pmPower) and its current power state (pmPowerOperState). In addition to power usage, additional information describing the units of measurement (pmPowerAccuracy, pmPowerUnitMultiplier), how power usage measurement was obtained (pmPowerMeasurementCaliber), the source of power (pmPowerOrigin) and the type of power (pmPowerCurrentTtype) are described. A Power Monitor may contain an optional pmPowerQuality table that describes the electrical characteristics associated with the current power state and usage. A Power Monitor may contain an optional pmEnergyTable to describe energy measurement information over time. A Power Monitor may also contain optional battery information associated with this entity. 10. MIB Definitions -- ************************************************************ -- -- -- This MIB is used to monitor power usage of network Expires February 5, 2012 [Page 31] Internet-Draft August 2011 -- devices -- -- ************************************************************* POWER-MONITOR-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Integer32, Counter64, TimeTicks FROM SNMPv2-SMI TEXTUAL-CONVENTION, DisplayString, RowStatus, TimeInterval FROM SNMPv2-TC MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP FROM SNMPv2-CONF OwnerString FROM RMON-MIB; powerMonitorMIB MODULE-IDENTITY LAST-UPDATED "201107080000Z" -- 8 July 2011 ORGANIZATION "IETF EMAN Working Group" CONTACT-INFO "WG charter: http://datatracker.ietf.org/wg/eman/charter/ Mailing Lists: General Discussion: eman@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/eman Archive: http://www.ietf.org/mail-archive/web/eman Editors: Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Bangalore, IN Phone: +91 80 4426 3947 Email: moulchan@cisco.com Brad Schoening 44 Rivers Edge Drive Little Silver, NJ 07739 Expires February 5, 2012 [Page 32] Internet-Draft August 2011 US Email: brad@bradschoening.com Juergen Quittek NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-115 Email: quittek@neclab.eu Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg DE Phone: +49 6221 4342-128 Email: Thomas.Dietz@nw.neclab.eu Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Degem 1831 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com" DESCRIPTION "This MIB is used to monitor power and energy in devices." REVISION "201107080000Z" -- 8 July 2011 DESCRIPTION "Initial version, published as RFC XXXX." ::= { mib-2 xxx } powerMonitorMIBNotifs OBJECT IDENTIFIER ::= { powerMonitorMIB 0 } powerMonitorMIBObjects OBJECT IDENTIFIER ::= { powerMonitorMIB 1 } Expires February 5, 2012 [Page 33] Internet-Draft August 2011 powerMonitorMIBConform OBJECT IDENTIFIER ::= { powerMonitorMIB 2 } -- Textual Conventions PowerStateSet ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "PowerStateSet is a TC that describes the Power State Set a Power Monitor supports. IANA has created a registry of Power State Sets supported by a Power Monitor entity and IANA shall administer the list of Power State Sets. One byte is used to represent the Power State Set. field octets contents range ----- ------ -------- ----- 1 1 Power State Set 1..255 Note: the value of Power State Set in network byte order 1 in the first byte indicates IEEE1621 Power State Set 2 in the first byte indicates DMTF Power State Set 3 in the first byte indicates EMAN Power State Set" REFERENCE "http://www.iana.org/assignments/eman RFC EDITOR NOTE: please change the previous URL if this is not the correct one after IANA assigned it." SYNTAX OCTET STRING (SIZE(1)) UnitMultiplier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Expires February 5, 2012 [Page 34] Internet-Draft August 2011 "The Unit Multiplier is an integer value that represents the IEEE 61850 Annex A units multiplier associated with the integer units used to measure the power or energy. For example, when used with pmPowerUnitMultiplier, -3 represents 10^-3 or milliwatts." REFERENCE "The International System of Units (SI), National Institute of Standards and Technology, Spec. Publ. 330, August 1991." SYNTAX INTEGER { yocto(-24), -- 10^-24 zepto(-21), -- 10^-21 atto(-18), -- 10^-18 femto(-15), -- 10^-15 pico(-12), -- 10^-12 nano(-9), -- 10^-9 micro(-6), -- 10^-6 milli(-3), -- 10^-3 units(0), -- 10^0 kilo(3), -- 10^3 mega(6), -- 10^6 giga(9), -- 10^9 tera(12), -- 10^12 peta(15), -- 10^15 exa(18), -- 10^18 zetta(21), -- 10^21 yotta(24) -- 10^24 } -- Objects pmPowerTable OBJECT-TYPE SYNTAX SEQUENCE OF PmPowerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists Power Monitors." ::= { powerMonitorMIBObjects 1 } pmPowerEntry OBJECT-TYPE SYNTAX PmPowerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes the power usage of a Power Monitor." Expires February 5, 2012 [Page 35] Internet-Draft August 2011 INDEX { pmPowerIndex, pmPowerStateSetIndex} ::= { pmPowerTable 1 } PmPowerEntry ::= SEQUENCE { pmPowerIndex Integer32, pmPowerStateSetIndex PowerStateSet, pmPower Integer32, pmPowerNameplate Integer32, pmPowerUnitMultiplier UnitMultiplier, pmPowerAccuracy Integer32, pmPowerMeasurementCaliber INTEGER, pmPowerCurrentType INTEGER, pmPowerOrigin INTEGER, pmPowerAdminState Integer32, pmPowerOperState Integer32, pmPowerStateEnterReason OwnerString } pmPowerIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, for each Power Monitor. If an implementation of the ENERGY-AWARE-MIB module is available in the local SNMP context, then the same index as the one in the ENERGY-AWARE-MIB MUST be assigned for the identical Power Monitor. In this case, entities without an assigned value for pmIndex cannot be indexed by the pmPowerStateTable. If there is no implementation of the ENERGY-AWARE-MIB module but one of the ENTITY MIB module is available in the local SNMP context, then the same index of an entity MUST be chosen as assigned to the entity by object entPhysicalIndex in the ENTITY MIB module. In this case, entities without an assigned value for entPhysicalIndex cannot be indexed by the pmPowerStateTable. If neither the ENERGY-AWARE-MIB module nor of the ENTITY MIB module are available in the local SNMP context, then this MIB module may choose identity values from a further MIB module providing entity identities. In this case the value for each pmPowerIndex must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. Expires February 5, 2012 [Page 36] Internet-Draft August 2011 In case that no other MIB modules have been chosen for providing entity identities, Power States can be reported exclusively for the local device on which this table is instantiated. Then this table will have a single entry only and an index value of 0 MUST be used." ::= { pmPowerEntry 1 } pmPowerStateSetIndex OBJECT-TYPE SYNTAX PowerStateSet MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object indicates the Power State Set supported by the Power Monitor. The list of Power State Sets and their numbering are administered by IANA" ::= { pmPowerEntry 2 } pmPower OBJECT-TYPE SYNTAX Integer32 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the 'instantaneous' RMS consumption for the Power Monitor. This value is specified in SI units of watts with the magnitude of watts (milliwatts, kilowatts, etc.) indicated separately in pmPowerUnitMultiplier. The accuracy of the measurement is specfied in pmPowerAccuracy. The direction of power flow is indicated by the sign on pmPower. If the Power Monitor is consuming power, the pmPower value will be positive. If the Power Monitor is producing power, the pmPower value will be negative. The pmPower MUST be less than or equal to the maximum power that can be consumed at the power state specified by pmPowerState. The pmPowerMeasurementCaliber object specifies how the usage value reported by pmPower was obtained. The pmPower value must report 0 if the pmPowerMeasurementCaliber is 'unavailable'. For devices that can not measure or report power, this option can be used." ::= { pmPowerEntry 3 } pmPowerNameplate OBJECT-TYPE Expires February 5, 2012 [Page 37] Internet-Draft August 2011 SYNTAX Integer32 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the rated maximum consumption for the fully populated Power Monitor. The nameplate power requirements are the maximum power numbers and, in almost all cases, are well above the expected operational consumption. The pmPowerNameplate is widely used for power provisioning. This value is specified in either units of watts or voltage and current. The units are therefore SI watts or equivalent Volt-Amperes with the magnitude (milliwatts, kilowatts, etc.) indicated separately in pmPowerUnitMultiplier." ::= { pmPowerEntry 4 } pmPowerUnitMultiplier OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of watts for the usage value in pmPower and pmPowerNameplate." ::= { pmPowerEntry 5 } pmPowerAccuracy OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates a percentage value, in 100ths of a percent, representing the assumed accuracy of the usage reported by pmPower. For example: The value 1010 means the reported usage is accurate to +/- 10.1 percent. This value is zero if the accuracy is unknown or not applicable based upon the measurement method. ANSI and IEC define the following accuracy classes for power measurement: IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. ANSI C12.20 class 0.2, 0.5" ::= { pmPowerEntry 6 } pmPowerMeasurementCaliber OBJECT-TYPE SYNTAX INTEGER { Expires February 5, 2012 [Page 38] Internet-Draft August 2011 unavailable(1) , unknown(2), actual(3) , estimated(4), presumed(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies how the usage value reported by pmPower was obtained: - unavailable(1): Indicates that the usage is not available. In such a case, the pmPower value must be 0 For devices that can not measure or report power this option can be used. - unknown(2): Indicates that the way the usage was determined is unknown. In some cases, entities report aggregate power on behalf of another device. In such cases it is not known whether the usage reported is actual(2), estimated(3) or presumed (4). - actual(3): Indicates that the reported usage was measured by the entity through some hardware or direct physical means. The usage data reported is not presumed (4) or estimated (3) but the real apparent current energy consumption rate. - estimated(4): Indicates that the usage was not determined by physical measurement. The value is a derivation based upon the device type, state, and/or current utilization using some algorithm or heuristic. It is presumed that the entity's state and current configuration were used to compute the value. - presumed(5): Indicates that the usage was not determined by physical measurement, algorithm or derivation. The usage was reported based upon external tables, specifications, and/or model information. For example, a PC Model X draws 200W, while a PC Model Y draws 210W" ::= { pmPowerEntry 7 } pmPowerCurrentType OBJECT-TYPE SYNTAX INTEGER { ac(1), dc(2), Expires February 5, 2012 [Page 39] Internet-Draft August 2011 unknown(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether the pmUsage for the Power Monitor reports alternative current AC(1), direct current DC(2), or that the current type is unknown(3)." ::= { pmPowerEntry 8 } pmPowerOrigin OBJECT-TYPE SYNTAX INTEGER { self (1), remote (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the source of power measurement and can be useful when modeling the power usage of attached devices. The power measurement can be performed by the entity itself or the power measurement of the entity can be reported by another trusted entity using a protocol extension. A value of self(1) indicates the measurement is performed by the entity, whereas remote(2) indicates that the measurement was performed by another entity." ::= { pmPowerEntry 9 } pmPowerAdminState OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the desired Power State for the Power Monitor, in the context of the Power State Set specified by pmPowerStateSetIndex in this table. Possible values of pmPowerAdminState are registered at IANA, per Power State Set. A current list of assignments can be found at RFC-EDITOR: please check the location after IANA" ::= { pmPowerEntry 10 } pmPowerOperState OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only Expires February 5, 2012 [Page 40] Internet-Draft August 2011 STATUS current DESCRIPTION "This object specifies the current operational Power State for the Power Monitor, in the context of the Power State Set specified by pmPowerStateSetIndex in this table. Possible values of pmPowerOperState are registered at IANA, per Power State Set. A current list of assignments can be found at RFC-EDITOR: please check the list" ::= { pmPowerEntry 11 } pmPowerStateEnterReason OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "This string object describes the reason for the pmPowerAdminState transition Alternatively, this string may contain with the entity that configured this Power Monitor to this Power State." DEFVAL { "" } ::= { pmPowerEntry 12 } pmPowerStateTable OBJECT-TYPE SYNTAX SEQUENCE OF PmPowerStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enumerates the maximum power usage, in watts, for every single supported Power State of each Power Monitor. This table has an expansion-dependent relationship on the pmPowerTable, containing rows describing each Power State for the corresponding Power Monitor. For every Power Monitor in the pmPowerTable, there is a corresponding entry in this table." ::= { powerMonitorMIBObjects 2 } pmPowerStateEntry OBJECT-TYPE SYNTAX PmPowerStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A pmPowerStateEntry extends a corresponding pmPowerEntry. This entry displays max usage values at Expires February 5, 2012 [Page 41] Internet-Draft August 2011 every single possible Power State supported by the Power Monitor. For example, given the values of a Power Monitor corresponding to a maximum usage of 11W at the state 1 (mechoff), 6 (ready), 8 (mediumMinus), 12 (High): State MaxUsage Units 1 (mechoff 0 W 2 (softoff) 0 W 3 (hibernate) 0 W 4 (sleep) 0 W 5 (standby) 0 W 6 (ready) 8 W 7 (lowMinus) 8 W 8 (low) 11 W 9 (medimMinus) 11 W 10 (medium) 11 W 11 (highMinus) 11 W 12 (high) 11 W Furthermore, this table extends to return the total time in each Power State, along with the number of times a particular Power State was entered." INDEX { pmPowerIndex, pmPowerStateSetIndex, pmPowerStateIndex } ::= { pmPowerStateTable 1 } PmPowerStateEntry ::= SEQUENCE { pmPowerStateIndex Integer32, pmPowerStateMaxPower Integer32, pmPowerStatePowerUnitMultiplier UnitMultiplier, pmPowerStateTotalTime TimeTicks, pmPowerStateEnterCount Counter64 } pmPowerStateIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies the Power State for the Power Monitor, in the context of the Power State Set specified by pmPowerStateSetIndex in this table. Expires February 5, 2012 [Page 42] Internet-Draft August 2011 This object specifies the index of the Power State of the Power Monitor within a Power State Set. The semantics of the specific Power State can be obtained from the Power State Set definition." ::= { pmPowerStateEntry 1 } pmPowerStateMaxPower OBJECT-TYPE SYNTAX Integer32 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the maximum power for the Power Monitor at the particular Power State. This value is specified in SI units of watts with the magnitude of the units (milliwatts, kilowatts, etc.) indicated separately in pmPowerStatePowerUnitMultiplier. If the maximum power is not known for a certain Power State, then the value is encoded as 0xFFFF. For Power States not enumerated, the value of pmPowerStateMaxPower might be interpolated by using the next highest supported Power State." ::= { pmPowerStateEntry 3 } pmPowerStatePowerUnitMultiplier OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of watts for the usage value in pmPowerStateMaxPower." ::= { pmPowerStateEntry 4 } pmPowerStateTotalTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the total time in hundreds of seconds that the Power Monitor has been in this power state since the last reset, as specified in the sysUpTime." ::= { pmPowerStateEntry 5 } pmPowerStateEnterCount OBJECT-TYPE SYNTAX Counter64 Expires February 5, 2012 [Page 43] Internet-Draft August 2011 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates how often the Power Monitor has entered this power state, since the last reset of the device as specified in the sysUpTime." ::= { pmPowerStateEntry 6 } pmEnergyParametersTable OBJECT-TYPE SYNTAX SEQUENCE OF PmEnergyParametersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to configure the parameters for Energy measurement collection in the table pmEnergyTable." ::= { powerMonitorMIBObjects 4 } pmEnergyParametersEntry OBJECT-TYPE SYNTAX PmEnergyParametersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry controls an energy measurement in pmEnergyTable." INDEX { pmPowerIndex } ::= { pmEnergyParametersTable 1 } PmEnergyParametersEntry ::= SEQUENCE { pmEnergyParametersIntervalLength TimeInterval, pmEnergyParametersIntervalNumber Integer32, pmEnergyParametersIntervalMode Integer32, pmEnergyParametersIntervalWindow TimeInterval, pmEnergyParametersSampleRate Integer32, pmEnergyParametersStatus RowStatus } pmEnergyParametersIntervalLength OBJECT-TYPE SYNTAX TimeInterval UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the length of time in seconds over which to compute the average pmEnergyIntervalEnergyUsed measurement in the pmEnergyTable table. The computation is based on the Power Monitor's internal sampling rate of Expires February 5, 2012 [Page 44] Internet-Draft August 2011 power consumed or produced by the Power Monitor. The sampling rate is the rate at which the power monitor can read the power usage and may differ based on device capabilities. The average energy consumption is then computed over the length of the interval." DEFVAL { 900 } ::= { pmEnergyParametersEntry 1 } pmEnergyParametersIntervalNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The number of intervals maintained in the pmEnergyTable. Each interval is characterized by a specific pmEnergyIntervalStartTime, used as an index to the table pmEnergyTable . Whenever the maximum number of entries is reached, the measurement over the new interval replaces the oldest measurement , except if the oldest measurement were to be the maximum pmEnergyIntervalMax, in which case the measurement the measurement over the next oldest interval is replaced." DEFVAL { 10 } ::= { pmEnergyParametersEntry 2 } pmEnergyParametersIntervalMode OBJECT-TYPE SYNTAX INTEGER { period(1), sliding(2), total(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "A control object to define the mode of interval calculation for the computation of the average pmEnergyIntervalEnergyUsed measurement in the pmEnergyTable table. A mode of period(1) specifies non-overlapping periodic measurements. A mode of sliding(2) specifies overlapping sliding windows where the interval between the start of one interval and the next is defined in pmEnergyParametersIntervalWindow. A mode of total(3) specifies non-periodic measurement. In this mode only one interval is used as this is a Expires February 5, 2012 [Page 45] Internet-Draft August 2011 continuous measurement since the last reset. The value of pmEnergyParametersIntervalNumber should be (1) one and pmEnergyParametersIntervalLength is ignored. " ::= { pmEnergyParametersEntry 3 } pmEnergyParametersIntervalWindow OBJECT-TYPE SYNTAX TimeInterval UNITS "Seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The length of the duration window between the starting time of one sliding window and the next starting time in seconds, in order to compute the average pmEnergyIntervalEnergyUsed measurement in the pmEnergyTable table This is valid only when the pmEnergyParametersIntervalMode is sliding(2). The pmEnergyParametersIntervalWindow value should be a multiple of pmEnergyParametersSampleRate." ::= { pmEnergyParametersEntry 4 } pmEnergyParametersSampleRate OBJECT-TYPE SYNTAX Integer32 UNITS "Milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The sampling rate, in milliseconds, at which the Power Monitor should poll power usage in order to compute the average pmEnergyIntervalEnergyUsed measurement in the table pmEnergyTable. The Power Monitor should initially set this sampling rate to a reasonable value, i.e., a compromise between intervals that will provide good accuracy by not being too long, but not so short that they affect the Power Monitor performance by requesting continuous polling. If the sampling rate is unknown, the value 0 is reported. The sampling rate should be selected so that pmEnergyParametersIntervalWindow is a multiple of pmEnergyParametersSampleRate." DEFVAL { 1000 } ::= { pmEnergyParametersEntry 5 } pmEnergyParametersStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Expires February 5, 2012 [Page 46] Internet-Draft August 2011 "The status of this row. The pmEnergyParametersStatus is used to start or stop energy usage logging. An entry status may not be active(1) unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated usage-data logged into the pmEnergyTable will be deleted. The data can be destroyed by setting up the pmEnergyParametersStatus to destroy(2)." ::= {pmEnergyParametersEntry 6 } pmEnergyTable OBJECT-TYPE SYNTAX SEQUENCE OF PmEnergyIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists Power Monitor energy measurements. Entries in this table are only created if the corresponding value of object pmPowerMeasurementCaliber is active(2), i.e., if the power is actually metered." ::= { powerMonitorMIBObjects 5 } pmEnergyIntervalEntry OBJECT-TYPE SYNTAX PmEnergyIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing energy measurements." INDEX { pmPowerIndex, pmEnergyParametersIntervalMode, pmEnergyIntervalStartTime } ::= { pmEnergyTable 1 } PmEnergyIntervalEntry ::= SEQUENCE { pmEnergyIntervalStartTime TimeTicks, pmEnergyIntervalEnergyUsed Integer32, pmEnergyIntervalEnergyUnitMultiplier UnitMultiplier, pmEnergyIntervalMax Integer32, pmEnergyIntervalDiscontinuityTime TimeTicks } pmEnergyIntervalStartTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of seconds" MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires February 5, 2012 [Page 47] Internet-Draft August 2011 "The time (in hundredths of a second) since the network management portion of the system was last re-initialized, as specified in the sysUpTime [RFC3418]. This object is useful for reference of interval periods for which the energy is measured." ::= { pmEnergyIntervalEntry 1 } pmEnergyIntervalEnergyUsed OBJECT-TYPE SYNTAX Integer32 UNITS "Watt-hours" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the energy used in units of watt- hours for the Power Monitor over the defined interval. This value is specified in the common billing units of watt-hours with the magnitude of watt-hours (kW-Hr, MW- Hr, etc.) indicated separately in pmEnergyIntervalEnergyUnitMultiplier." ::= { pmEnergyIntervalEntry 2 } pmEnergyIntervalEnergyUnitMultiplier OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the magnitude of watt-hours for the energy field in pmEnergyIntervalEnergyUsed." ::= { pmEnergyIntervalEntry 3 } pmEnergyIntervalMax OBJECT-TYPE SYNTAX Integer32 UNITS "Watt-hours" MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the maximum energy ever observed in pmEnergyIntervalEnergyUsed since the monitoring started. This value is specified in the common billing units of watt-hours with the magnitude of watt-hours (kW-Hr, MW- Hr, etc.) indicated separately in pmEnergyIntervalEnergyUnits." ::= { pmEnergyIntervalEntry 4 } pmEnergyIntervalDiscontinuityTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only Expires February 5, 2012 [Page 48] Internet-Draft August 2011 STATUS current DESCRIPTION "The value of sysUpTime [RFC3418] on the most recent occasion at which any one or more of this entity's energy consumption counters suffered a discontinuity. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value." ::= { pmEnergyIntervalEntry 5 } -- Notifications pmPowerStateChange NOTIFICATION-TYPE OBJECTS {pmPowerAdminState, pmPowerOperState, pmPowerStateEnterReason} STATUS current DESCRIPTION "The SNMP entity generates the PmPowerStateChange when the value(s) of pmPowerAdminState or pmPowerOperState, in the context of the Power State Set, have changed for the Power Monitor represented by the pmPowerIndex." ::= { powerMonitorMIBNotifs 1 } -- Conformance powerMonitorMIBCompliances OBJECT IDENTIFIER ::= { powerMonitorMIB 3 } powerMonitorMIBGroups OBJECT IDENTIFIER ::= { powerMonitorMIB 4 } powerMonitorMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented with support for read-create, then such an implementation can claim full compliance. Such devices can then be both monitored and configured with this MIB." MODULE -- this module MANDATORY-GROUPS { powerMonitorMIBTableGroup, powerMonitorMIBStateTableGroup, powerMonitorMIBEnergyTableGroup, powerMonitorMIBEnergyParametersTableGroup, powerMonitorMIBNotifGroup } ::= { powerMonitorMIBCompliances 1 } Expires February 5, 2012 [Page 49] Internet-Draft August 2011 powerMonitorMIBReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented without support for read-create (i.e. in read-only mode), then such an implementation can claim read-only compliance. Such a device can then be monitored but can not be configured with this MIB." MODULE -- this module MANDATORY-GROUPS { powerMonitorMIBTableGroup, powerMonitorMIBStateTableGroup, powerMonitorMIBNotifGroup } OBJECT pmPowerOperState MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { powerMonitorMIBCompliances 2 } -- Units of Conformance powerMonitorMIBTableGroup OBJECT-GROUP OBJECTS { pmPower, pmPowerNameplate, pmPowerUnitMultiplier, pmPowerAccuracy, pmPowerMeasurementCaliber, pmPowerCurrentType, pmPowerOrigin, pmPowerAdminState, pmPowerOperState, pmPowerStateEnterReason } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the PowerMonitor." ::= { powerMonitorMIBGroups 1 } powerMonitorMIBStateTableGroup OBJECT-GROUP OBJECTS { pmPowerStateMaxPower, pmPowerStatePowerUnitMultiplier, pmPowerStateTotalTime, pmPowerStateEnterCount Expires February 5, 2012 [Page 50] Internet-Draft August 2011 } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the Power State." ::= { powerMonitorMIBGroups 2 } powerMonitorMIBEnergyParametersTableGroup OBJECT-GROUP OBJECTS { pmEnergyParametersIntervalLength, pmEnergyParametersIntervalNumber, pmEnergyParametersIntervalMode, pmEnergyParametersIntervalWindow, pmEnergyParametersSampleRate, pmEnergyParametersStatus } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the configuration of the Energy Table." ::= { powerMonitorMIBGroups 3 } powerMonitorMIBEnergyTableGroup OBJECT-GROUP OBJECTS { -- Note that object -- pmEnergyIntervalStartTime is not -- included since it is not-accessible pmEnergyIntervalEnergyUsed, pmEnergyIntervalEnergyUnitMultiplier, pmEnergyIntervalMax, pmEnergyIntervalDiscontinuityTime } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the Energy Table." ::= { powerMonitorMIBGroups 4 } powerMonitorMIBNotifGroup NOTIFICATION-GROUP NOTIFICATIONS { pmPowerStateChange } STATUS current Expires February 5, 2012 [Page 51] Internet-Draft August 2011 DESCRIPTION "This group contains the notifications for the power and energy monitoring MIB Module." ::= { powerMonitorMIBGroups 5 } END -- ************************************************************ -- -- This MIB module is used to monitor power quality of networked -- devices with measurements. -- -- This MIB module is an extension of powerMonitorMIB module. -- -- ************************************************************* POWER-QUALITY-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Integer32 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF UnitMultiplier, pmPowerIndex FROM POWER-MONITOR-MIB OwnerString FROM RMON-MIB; powerQualityMIB MODULE-IDENTITY LAST-UPDATED "201107080000Z" -- 8 July 2011 ORGANIZATION "IETF EMAN Working Group" CONTACT-INFO "WG charter: http://datatracker.ietf.org/wg/eman/charter/ Mailing Lists: General Discussion: eman@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/eman Expires February 5, 2012 [Page 52] Internet-Draft August 2011 Archive: http://www.ietf.org/mail-archive/web/eman Editors: Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Bangalore, IN Phone: +91 80 4426 3947 Email: moulchan@cisco.com Brad Schoening 44 Rivers Edge Drive Little Silver, NJ 07739 US Email: brad@bradschoening.com Juergen Quittek NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-115 Email: quittek@neclab.eu Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg DE Phone: +49 6221 4342-128 Email: Thomas.Dietz@nw.neclab.eu Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Degem 1831 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com" DESCRIPTION Expires February 5, 2012 [Page 53] Internet-Draft August 2011 "This MIB is used to report AC power quality in devices. The table is a sparse augmentation of the pmPowerTable table from the powerMonitorMIB module. Both three-phase and single-phase power configurations are supported." REVISION "201107080000Z" -- 8 July 2011 DESCRIPTION "Initial version, published as RFC YYY." ::= { mib-2 yyy } powerQualityMIBConform OBJECT IDENTIFIER ::= { powerQualityMIB 0 } powerQualityMIBObjects OBJECT IDENTIFIER ::= { powerQualityMIB 1 } -- Objects pmACPwrQualityTable OBJECT-TYPE SYNTAX SEQUENCE OF PmACPwrQualityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines power quality measurements for supported pmPowerIndex entities. It is a sparse extension of the pmPowerTable." ::= { powerQualityMIBObjects 1 } pmACPwrQualityEntry OBJECT-TYPE SYNTAX PmACPwrQualityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a sparse extension of the pmPowerTable with entries for power quality measurements or configuration. Each measured value corresponds to an attribute in IEC 61850-7-4 for non-phase measurements within the object MMUX." INDEX { pmPowerIndex } ::= { pmACPwrQualityTable 1 } Expires February 5, 2012 [Page 54] Internet-Draft August 2011 PmACPwrQualityEntry ::= SEQUENCE { pmACPwrQualityConfiguration INTEGER, pmACPwrQualityAvgVoltage Integer32, pmACPwrQualityAvgCurrent Integer32, pmACPwrQualityFrequency Integer32, pmACPwrQualityPowerUnitMultiplier UnitMultiplier, pmACPwrQualityPowerAccuracy Integer32, pmACPwrQualityTotalActivePower Integer32, pmACPwrQualityTotalReactivePower Integer32, pmACPwrQualityTotalApparentPower Integer32, pmACPwrQualityTotalPowerFactor Integer32, pmACPwrQualityThdAmpheres Integer32, pmACPwrQualityThdVoltage Integer32 } pmACPwrQualityConfiguration OBJECT-TYPE SYNTAX INTEGER { sngl(1), del(2), wye(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Configuration describes the physical configurations of the power supply lines: * alternating current, single phase (SNGL) * alternating current, three phase delta (DEL) * alternating current, three phase Y (WYE) Three-phase configurations can be either connected in a triangular delta (DEL) or star Y (WYE) system. WYE systems have a shared neutral voltage, while DEL systems do not. Each phase is offset 120 degrees to each other." ::= { pmACPwrQualityEntry 1 } pmACPwrQualityAvgVoltage OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 Volt AC" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value for average 'instantaneous' RMS line voltage. For a 3-phase system, this is the average voltage (V1+V2+V3)/3. IEC 61850-7-4 measured value attribute 'Vol'" Expires February 5, 2012 [Page 55] Internet-Draft August 2011 ::= { pmACPwrQualityEntry 2 } pmACPwrQualityAvgCurrent OBJECT-TYPE SYNTAX Integer32 UNITS "Ampheres" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the current per phase. IEC 61850- 7-4 attribute 'Amp'" ::= { pmACPwrQualityEntry 3 } pmACPwrQualityFrequency OBJECT-TYPE SYNTAX Integer32 (4500..6500) -- UNITS 0.01 Hertz UNITS "hertz" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value for the basic frequency of the AC circuit. IEC 61850-7-4 attribute 'Hz'." ::= { pmACPwrQualityEntry 4 } pmACPwrQualityPowerUnitMultiplier OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of watts for the usage value in pmACPwrQualityTotalActivePower, pmACPwrQualityTotalReactivePower and pmACPwrQualityTotalApparentPower measurements. For 3-phase power systems, this will also include pmACPwrQualityPhaseActivePower, pmACPwrQualityPhaseReactivePower and pmACPwrQualityPhaseApparentPower" ::= { pmACPwrQualityEntry 5 } pmACPwrQualityPowerAccuracy OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates a percentage value, in 100ths of a percent, representing the presumed accuracy of active, reactive, and apparent power usage reporting. For example: 1010 means the reported usage is accurate Expires February 5, 2012 [Page 56] Internet-Draft August 2011 to +/- 10.1 percent. This value is zero if the accuracy is unknown. ANSI and IEC define the following accuracy classes for power measurement: IEC 62053-22 & 60044-1 class 0.1, 0.2, 0.5, 1 & 3. ANSI C12.20 class 0.2 & 0.5" ::= { pmACPwrQualityEntry 6 } pmACPwrQualityTotalActivePower OBJECT-TYPE SYNTAX Integer32 UNITS "RMS watts" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the actual power delivered to or consumed by the load. IEC 61850-7-4 attribute 'TotW'." ::= { pmACPwrQualityEntry 7 } pmACPwrQualityTotalReactivePower OBJECT-TYPE SYNTAX Integer32 UNITS "volt-amperes reactive" MAX-ACCESS read-only STATUS current DESCRIPTION "A mesured value of the reactive portion of the apparent power. IEC 61850-7-4 attribute 'TotVAr'." ::= { pmACPwrQualityEntry 8 } pmACPwrQualityTotalApparentPower OBJECT-TYPE SYNTAX Integer32 UNITS "volt-amperes" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the voltage and current which determines the apparent power. The apparent power is the vector sum of real and reactive power. Note: watts and volt-ampheres are equivalent units and may be combined. IEC 61850-7-4 attribute 'TotVA'." ::= { pmACPwrQualityEntry 9 } pmACPwrQualityTotalPowerFactor OBJECT-TYPE SYNTAX Integer32 (-10000..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current Expires February 5, 2012 [Page 57] Internet-Draft August 2011 DESCRIPTION "A measured value ratio of the real power flowing to the load versus the apparent power. It is dimensionless and expressed here as a percentage value in 100ths of a percent. A power factor of 100% indicates there is no inductance load and thus no reactive power. Power Factor can be positive or negative, where the sign should be in lead/lag (IEEE) form. IEC 61850-7-4 attribute 'TotPF'." ::= { pmACPwrQualityEntry 10 } pmACPwrQualityThdAmpheres OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "A calculated value for the current total harmonic distortion (THD). Method of calculation is not specified. IEC 61850-7-4 attribute 'ThdAmp'." ::= { pmACPwrQualityEntry 11 } pmACPwrQualityThdVoltage OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "A calculated value for the voltage total harmonic distortion (THD). Method of calculation is not specified. IEC 61850-7-4 attribute 'ThdVol'." ::= { pmACPwrQualityEntry 12 } pmACPwrQualityPhaseTable OBJECT-TYPE SYNTAX SEQUENCE OF PmACPwrQualityPhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes 3-phase power quality measurements. It is a sparse extension of the pmACPwrQualityTable." ::= { powerQualityMIBObjects 2 } pmACPwrQualityPhaseEntry OBJECT-TYPE SYNTAX PmACPwrQualityPhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires February 5, 2012 [Page 58] Internet-Draft August 2011 "An entry describes common 3-phase power quality measurements. This optional table describes 3-phase power quality measurements, with three entries for each supported pmPowerIndex entity. Entities having single phase power shall not have any entities. This table describes attributes common to both WYE and DEL. Entities having single phase power shall not have any entries here. It is a sparse extension of the pmACPwrQualityTable. These attributes correspond to IEC 61850-7.4 MMXU phase measurements." INDEX { pmPowerIndex, pmPhaseIndex } ::= { pmACPwrQualityPhaseTable 1 } PmACPwrQualityPhaseEntry ::= SEQUENCE { pmPhaseIndex Integer32, pmACPwrQualityPhaseAvgCurrent Integer32, pmACPwrQualityPhaseActivePower Integer32, pmACPwrQualityPhaseReactivePower Integer32, pmACPwrQualityPhaseApparentPower Integer32, pmACPwrQualityPhasePowerFactor Integer32, pmACPwrQualityPhaseImpedance Integer32 } pmPhaseIndex OBJECT-TYPE SYNTAX Integer32 (0..359) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A phase angle typically corresponding to 0, 120, 240." ::= { pmACPwrQualityPhaseEntry 1 } pmACPwrQualityPhaseAvgCurrent OBJECT-TYPE SYNTAX Integer32 UNITS "Ampheres" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the current per phase. IEC 61850- 7-4 attribute 'A'" ::= { pmACPwrQualityPhaseEntry 2 } pmACPwrQualityPhaseActivePower OBJECT-TYPE SYNTAX Integer32 Expires February 5, 2012 [Page 59] Internet-Draft August 2011 UNITS "RMS watts" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the actual power delivered to or consumed by the load. IEC 61850-7-4 attribute 'W'" ::= { pmACPwrQualityPhaseEntry 3 } pmACPwrQualityPhaseReactivePower OBJECT-TYPE SYNTAX Integer32 UNITS "volt-amperes reactive" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the reactive portion of the apparent power. IEC 61850-7-4 attribute 'VAr'" ::= { pmACPwrQualityPhaseEntry 4 } pmACPwrQualityPhaseApparentPower OBJECT-TYPE SYNTAX Integer32 UNITS "volt-amperes" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the voltage and current determines the apparent power. Active plus reactive power equals the total apparent powwer. Note: Watts and volt-ampheres are equivalent units and may be combined. IEC 61850-7-4 attribute 'VA'." ::= { pmACPwrQualityPhaseEntry 5 } pmACPwrQualityPhasePowerFactor OBJECT-TYPE SYNTAX Integer32 (-10000..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value ratio of the real power flowing to the load versus the apparent power for this phase. IEC 61850-7-4 attribute 'PF'. Power Factor can be positive or negative where the sign should be in lead/lag (IEEE) form." ::= { pmACPwrQualityPhaseEntry 6 } pmACPwrQualityPhaseImpedance OBJECT-TYPE SYNTAX Integer32 UNITS "volt-amperes" Expires February 5, 2012 [Page 60] Internet-Draft August 2011 MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the impedance. IEC 61850-7-4 attribute 'Z'." ::= { pmACPwrQualityPhaseEntry 7 } pmACPwrQualityDelPhaseTable OBJECT-TYPE SYNTAX SEQUENCE OF PmACPwrQualityDelPhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes DEL configuration phase-to-phase power quality measurements. This is a sparse extension of the pmACPwrQualityPhaseTable." ::= { powerQualityMIBObjects 3 } pmACPwrQualityDelPhaseEntry OBJECT-TYPE SYNTAX PmACPwrQualityDelPhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes quality attributes of a phase in a DEL 3-phase power system. Voltage measurements are provided both relative to each other and zero. Measured values are from IEC 61850-7-2 MMUX and THD from MHAI objects. For phase-to-phase measurements, the pmPhaseIndex is compared against the following phase at +120 degrees. Thus, the possible values are: pmPhaseIndex Next Phase Angle 0 120 120 240 240 0 " INDEX { pmPowerIndex, pmPhaseIndex} ::= { pmACPwrQualityDelPhaseTable 1} PmACPwrQualityDelPhaseEntry ::= SEQUENCE { pmACPwrQualityDelPhaseToNextPhaseVoltage Integer32, pmACPwrQualityDelThdPhaseToNextPhaseVoltage Integer32, pmACPwrQualityDelThdCurrent Integer32 } pmACPwrQualityDelPhaseToNextPhaseVoltage OBJECT-TYPE Expires February 5, 2012 [Page 61] Internet-Draft August 2011 SYNTAX Integer32 UNITS "0.1 Volt AC" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of phase to next phase voltages, where the next phase is IEC 61850-7-4 attribute 'PPV'." ::= { pmACPwrQualityDelPhaseEntry 2 } pmACPwrQualityDelThdPhaseToNextPhaseVoltage OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "A calculated value for the voltage total harmonic disortion for phase to next phase. Method of calculation is not specified. IEC 61850-7-4 attribute 'ThdPPV'." ::= { pmACPwrQualityDelPhaseEntry 3 } pmACPwrQualityDelThdCurrent OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "A calculated value for the voltage total harmonic disortion (THD) for phase to phase. Method of calculation is not specified. IEC 61850-7-4 attribute 'ThdPPV'." ::= { pmACPwrQualityDelPhaseEntry 4 } pmACPwrQualityWyePhaseTable OBJECT-TYPE SYNTAX SEQUENCE OF PmACPwrQualityWyePhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes WYE configuration phase-to-neutral power quality measurements. This is a sparse extension of the pmACPwrQualityPhaseTable." ::= { powerQualityMIBObjects 4 } pmACPwrQualityWyePhaseEntry OBJECT-TYPE SYNTAX PmACPwrQualityWyePhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires February 5, 2012 [Page 62] Internet-Draft August 2011 "This table describes measurements of WYE configuration with phase to neutral power quality attributes. Three entries are required for each supported pmPowerIndex entry. Voltage measurements are relative to neutral. This is a sparse extension of the pmACPwrQualityPhaseTable. Each entry describes quality attributes of one phase of a WYE 3-phase power system. Measured values are from IEC 61850-7-2 MMUX and THD from MHAI objects." INDEX { pmPowerIndex, pmPhaseIndex } ::= { pmACPwrQualityWyePhaseTable 1} PmACPwrQualityWyePhaseEntry ::= SEQUENCE { pmACPwrQualityWyePhaseToNeutralVoltage Integer32, pmACPwrQualityWyePhaseCurrent Integer32, pmACPwrQualityWyeThdPhaseToNeutralVoltage Integer32 } pmACPwrQualityWyePhaseToNeutralVoltage OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 Volt AC" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of phase to neutral voltage. IEC 61850-7-4 attribute 'PhV'." ::= { pmACPwrQualityWyePhaseEntry 1 } pmACPwrQualityWyePhaseCurrent OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 ampheres AC" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of phase currents. IEC 61850-7-4 attribute 'A'." ::= { pmACPwrQualityWyePhaseEntry 2 } pmACPwrQualityWyeThdPhaseToNeutralVoltage OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION Expires February 5, 2012 [Page 63] Internet-Draft August 2011 "A calculated value of the voltage total harmonic distortion (THD) for phase to neutral. IEC 61850-7-4 attribute 'ThdPhV'." ::= { pmACPwrQualityWyePhaseEntry 3 } -- Conformance powerQualityMIBCompliances OBJECT IDENTIFIER ::= { powerQualityMIB 2 } powerQualityMIBGroups OBJECT IDENTIFIER ::= { powerQualityMIB 3 } powerQualityMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "When this MIB is implemented with support for read- create, then such an implementation can claim full compliance. Such devices can then be both monitored and configured with this MIB." MODULE -- this module MANDATORY-GROUPS { powerACPwrQualityMIBTableGroup, powerACPwrQualityPhaseMIBTableGroup } GROUP powerACPwrQualityDelPhaseMIBTableGroup DESCRIPTION "This group must only be implemented for a DEL phase configuration." GROUP powerACPwrQualityWyePhaseMIBTableGroup DESCRIPTION "This group must only be implemented for a WYE phase configuration." ::= { powerQualityMIBCompliances 1 } -- Units of Conformance powerACPwrQualityMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object pmPowerIndex is NOT -- included since it is not-accessible pmACPwrQualityConfiguration, pmACPwrQualityAvgVoltage, pmACPwrQualityAvgCurrent, pmACPwrQualityFrequency, Expires February 5, 2012 [Page 64] Internet-Draft August 2011 pmACPwrQualityPowerUnitMultiplier, pmACPwrQualityPowerAccuracy, pmACPwrQualityTotalActivePower, pmACPwrQualityTotalReactivePower, pmACPwrQualityTotalApparentPower, pmACPwrQualityTotalPowerFactor, pmACPwrQualityThdAmpheres, pmACPwrQualityThdVoltage } STATUS current DESCRIPTION "This group contains the collection of all the power quality objects related to the Power Monitor." ::= { powerQualityMIBGroups 1 } powerACPwrQualityPhaseMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object pmPowerIndex is NOT -- included since it is not-accessible pmACPwrQualityPhaseAvgCurrent, pmACPwrQualityPhaseActivePower, pmACPwrQualityPhaseReactivePower, pmACPwrQualityPhaseApparentPower, pmACPwrQualityPhasePowerFactor, pmACPwrQualityPhaseImpedance } STATUS current DESCRIPTION "This group contains the collection of all 3-phase power quality objects related to the Power State." ::= { powerQualityMIBGroups 2 } powerACPwrQualityDelPhaseMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object pmPowerIndex and -- pmPhaseIndex are NOT included -- since they are not-accessible pmACPwrQualityDelPhaseToNextPhaseVoltage , pmACPwrQualityDelThdPhaseToNextPhaseVoltage, pmACPwrQualityDelThdCurrent } STATUS current DESCRIPTION "This group contains the collection of all quality attributes of a phase in a DEL 3-phase power system." ::= { powerQualityMIBGroups 3 } powerACPwrQualityWyePhaseMIBTableGroup OBJECT-GROUP Expires February 5, 2012 [Page 65] Internet-Draft August 2011 OBJECTS { -- Note that object pmPowerIndex and -- pmPhaseIndex are NOT included -- since they are not-accessible pmACPwrQualityWyePhaseToNeutralVoltage, pmACPwrQualityWyePhaseCurrent, pmACPwrQualityWyeThdPhaseToNeutralVoltage } STATUS current DESCRIPTION "This group contains the collection of all WYE configuration phase-to-neutral power quality measurements." ::= { powerQualityMIBGroups 4 } END 11. Security Considerations Some of the readable objects in these MIB modules (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. There are a number of management objects defined in these MIB modules with a MAX-ACCESS clause of read-write and/or read- create. Such objects MAY be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The following are the tables and objects and their sensitivity/vulnerability: - Unauthorized changes to the pmPowerOperState (via thepmPowerAdminState ) MAY disrupt the power settings of the different Power Monitors, and therefore the state of functionality of the respective Power Monitors. - Unauthorized changes to the pmEnergyParametersTable MAY disrupt energy measurement in the pmEnergyTable table. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), there is still no secure control over who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. Expires February 5, 2012 [Page 66] Internet-Draft August 2011 It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of these MIB modules is properly configured to give access to the objects only to those principals (users) that have legitimate rights to GET or SET (change/create/delete) them. 12. IANA Considerations 12.1. IANA Considerations for the MIB Modules The MIB modules in this document uses the following IANA- assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- PowerMonitorMIB { mib-2 xxx } powerQualityMIB { mib-2 yyy } Additions to the MIB modules are subject to Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the requested MIB objects for completeness and accuracy of the description. Requests for MIB objects that duplicate the functionality of existing objects SHOULD be declined. The smallest available OIDs SHOULD be assigned to the new MIB objects. The specification of new MIB objects SHOULD follow the structure specified in Section 10. and MUST be published using a well-established and persistent publication medium. 12.2. IANA Registration of new Power State Set This document specifies an initial set of Power State Sets. The list of these Power State Sets with their numeric identifiers is given in Section 5.2.1. The Internet Assigned Numbers Authority (IANA) has created a new registry for Power State Sets numeric Expires February 5, 2012 [Page 67] Internet-Draft August 2011 identifiers and filled it with the initial list as in Section 5.2.1. New Assignments to Power State Sets shall be administered by IANA and the guidelines and procedures are listed in this Section. New assignments for Power State Set will be administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the requested state for completeness and accuracy of the description. A pure vendor specific implementation of Power State Set shall not be adopted; since it would lead to proliferation of Power State Sets. 12.2.1. IANA Registration of the IEEE1621 Power State Set This document specifies a set of values for the IEEE1621 Power State Set [IEEE1621]. The list of these values with their identifiers is given in Section 5.2.1. The Internet Assigned Numbers Authority (IANA) created a new registry for IEEE1621 Power State Set identifiers and filled it with the initial list in Section 5.2.2. New assignments (or potentially deprecation) for IEEE1621 Power State Set will be administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the requested state for completeness and accuracy of the description. 12.2.2. IANA Registration of the DMTF Power State Set This document specifies a set of values for the DMTF Power State Set. The list of these values with their identifiers is given in Section 5.2.1. The Internet Assigned Numbers Authority (IANA) has created a new registry for DMTF Power State Set identifiers and filled it with the initial list in Section 5.2.1. New assignments (or potentially deprecation) for DMTF Power State Set will be administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the conformance with the DMTF standard [DMTF], on the top of checking for completeness and accuracy of the description. Expires February 5, 2012 [Page 68] Internet-Draft August 2011 12.2.3. IANA Registration of the EMAN Power State Set This document specifies a set of values for the EMAN Power State Set. The list of these values with their identifiers is given in Section 5.2.1. The Internet Assigned Numbers Authority (IANA) has created a new registry for EMAN Power State Set identifiers and filled it with the initial list in Section 5.2.1. New assignments (or potentially deprecation) for EMAN Power State Set will be administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the requested state for completeness and accuracy of the description. 12. Contributors This document results from the merger of two initial proposals. The following persons made significant contributions either in one of the initial proposals or in this document. John Parello Rolf Winter Dominique Dudkowski 13. Acknowledgment The authors would like to thank Shamita Pisal for her prototype of this MIB module, and her valuable feedback. The authors would like to Michael Brown for improving the text dramatically. 14. Open Issues OPEN ISSUE 1 : Double-check all the IEC references in the draft. IEC 61850-7-4 has been widely referenced in many EMAN drafts. The other IEC references suggested in the email list are: IEC 61000-4-30 and IEC 62053-21 and IEC 62301. It is important to resolve the correct IEC references soon. Expires February 5, 2012 [Page 69] Internet-Draft August 2011 OPEN ISSUE 2 : Description clause of pmPowerIndex. Do we need this text ? Juergen Quittek to comment: "The identity provisioning method that has been chosen can be retrieved by reading the value of powerStateEnergyConsumerOid. In case of identities provided by the ENERGY-AWARE-MIB module, this OID points to an exising instance of pmPowerIndex, in case of the ENTITY MIB, the object points to a valid instance of entPhysicalIndex, and in a similar way, it points to a value of another MIB module if this is used for identifying entities. If no other MIB module has been chosen for providing entity identities, then the value of powerStateEnergyConsumerOid MUST be 0.0 (zeroDotZero). OPEN ISSUE 3: Textual convention for Power State Set PowerStateSeries ::= TEXTUAL-CONVENTION Why is this an OCTET STRING (SIZE(1)) and not simply an enumerated INTEGER? And if this is to be maintained by IANA, why not create a IANA-POWER-SERIES-TC MIB module so that one can simply fetch the latest version from IANA? Discussion is ongoing in the EMAN email list on the design of the TC and IANA registration. OPEN ISSUE 4: pmPowerEntry table has MIB objects which are common across multiple Power State Sets. This issue shall be fixed in the next revision of the draft. OPEN ISSUE 5: TimeStamps for Power measurements required ? OPEN ISSUE 6: Measurement of AC Power, Voltage, and Current "AC power is not an RMS measurement, it is an average reading. The term instantaneous AC power can be misleading and power meters do not report it. " Description clause of MIB objects pmPower, pmACPwrQualityAvgVoltage, pmACPwrQualityAvgCurrent to be updated. Sent email to Michael Suchoff for some text. OPEN ISSUE 7: In addition to WYE and Delta AC power configurations, 3-Phase hybrid of WYE and Delta should be considered ? Expires February 5, 2012 [Page 70] Internet-Draft August 2011 Need more information on the hybrid of WYE and Delta configuration. Email seeking clarification sent to Michael Suchoff. OPEN ISSUE 8: Nameplate power consumption should be a fixed value or a range ? Presently, Nameplate power consumption contains the max value of power consumption (watts) of the device; useful for power planning purposes. The voltage range can be useful for power supply specification. OPEN ISSUE 9: AC data center management is detection of tripped circuit breakers, not covered in the MIB draft. Are Circuit breakers in scope of EMAN ? OPEN ISSUE 10: Time Series of measurements required ? Mechanism pull or push ? What shall the table consist of ? Power, Voltage, Current, Energy and Demand Discussion on the email list. Based on requirements with the need for time series for Power, may need to be considered for the MIB. OPEN ISSUE 11: Demand computation method "Energy not obtained by periodically polling a power measurement with a pmEnergyParametersSampleRate ; Energy (E) is measured to the product's certified IEC 62053-21 accuracy class" Need to verify with IEC62053-21. OPEN ISSUE 12: Consideration of IEEE-ISTO PWG in the IANA list of Power State Set ? PWG Imaging Systems Power Management MIB reference. OPEN ISSUE 13: check if all the requirements from [EMAN-REQ] are covered. OPEN ISSUE 14: Required Information on Powered Entities Expires February 5, 2012 [Page 71] Internet-Draft August 2011 It would be helpful to identify variables that are static vs. those that are dynamic. There are some that are absolutely static, and others that just rarely change. 15. References 15.2. Normative References [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB", RFC3621, December 2003. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information Base extension module for TIA-TR41.4 media endpoint discovery information", July 2005. [EMAN-AWARE-MIB] J. Parello, and B. Claise, "draft-ietf-eman- energy-aware-mib-02 ", work in progress, July 2011. 15.3. Informative References [RFC1628] S. Bradner, "UPS Management Information Base", RFC 1628, May 1994 Expires February 5, 2012 [Page 72] Internet-Draft August 2011 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework ", RFC 3410, December 2002. [RFC3418] Presun, R., Case, J., McCloghrie, K., Rose, M, and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", RFC3418, December 2002. [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002. [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,November 2005. [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie, "Guidelines for Writing an IANA Considerations Section in RFCs ", BCP 26, RFC 5226, May 2008. [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. Chandramouli, " Requirements for Energy Management ", draft-ietf-eman-requirements-03 (work in progress),July 2011. . [EMAN-FRAMEWORK] Claise, B., Parello, J., Schoening, B., and J. Quittek, "Energy Management Framework", draft-ietf- eman-framework-02 , July 2011. [EMAN-MONITORING-MIB] M. Chandramouli, Schoening, B., Dietz, T., Quittek, J. and B. Claise "Energy and Power Monitoring MIB ", draft-claise-energy-monitoring-mib-09, July 2011. [EMAN-AS] Tychon, E., Laherty, M., and B. Schoening, "Energy Management (EMAN) Applicability Statement", draft- tychon-eman-applicability-statement-02, work in progress, June 2011. [ACPI] "Advanced Configuration and Power Interface Specification",http://www.acpi.info/DOWNLOADS/ACPIspec3 0b.pdf [DMTF] "Power State Management Profile DMTF DSP1027 Version 2.0" December 2009 http://www.dmtf.org/sites/default/files/standards/docum ents/DSP1027_2.0.0.pdf Expires February 5, 2012 [Page 73] Internet-Draft August 2011 [IEEE1621] "Standard for User Interface Elements in Power Control of Electronic Devices Employed in Office/Consumer Environments", IEEE 1621, December 2004. [IEC.61850-7-4] International Electrotechnical Commission, "Communication networks and systems for power utility automation Part 7-4: Basic communication structure Compatible logical node classes and data object classes", 2010. [IEC.62053-21] International Electrotechnical Commission, "Electricity metering equipment (a.c.) Particular requirements Part 22: Static meters for active energy (classes 1 and 2)", 2003. [IEC.62053-22]International Electrotechnical Commission, "Electricity metering equipment (a.c.) Particular requirements Part 22: Static meters for active energy (classes 0,2 S and 0,5 S)", 2003. Authors' Addresses Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Bangalore, IN Phone: +91 80 4426 3947 Email: moulchan@cisco.com Brad Schoening 44 Rivers Edge Drive Little Silver, NJ 07739 US Email: brad@bradschoening.com Juergen Quittek NEC Europe Ltd. NEC Laboratories Europe Network Research Division Expires February 5, 2012 [Page 74] Internet-Draft August 2011 Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-115 Email: quittek@neclab.eu Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-128 Email: Thomas.Dietz@neclab.eu Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com Expires February 5, 2012 [Page 75]