Network Working Group B. Claise Internet-Draft M. Chandramouli Intended Status: Standards Track J. Parello Expires: March 16, 2011 B. Schoening Cisco Systems, Inc. September 16, 2010 Power and Energy Monitoring MIB draft-claise-energy-monitoring-mib-05 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 September, 2010. Internet-Draft Sept 2010 Copyright Notice Copyright (c) 2010 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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction.............................................. 4 2. The Internet-Standard Management Framework................ 5 3. Use Cases................................................. 5 4. Terminology............................................... 5 5. Architecture Concepts Applied to the MIB Module........... 5 5.1 Power Monitor Information............................. 6 5.2 Power Monitor Meter Domain............................ 7 5.3 Power Monitor Parent and Child........................ 7 5.4 Power Monitor Context................................. 7 5.5 Power Monitor Levels.................................. 7 5.6 Power Monitor Usage Measurement....................... 8 5.7 Optional Power Usage Quality.......................... 9 5.8 Optional Energy Measurement........................... 9 5.9 Optional Battery Information......................... 13 6. Implementation Scenarios................................. 13 Expires March 25, 2011 [Page 2] Internet-Draft Sept 2010 Scenario 1: Switch with PoE endpoints.................... 13 Scenario 2: Switch with PoE endpoints with further connected device(s)................................................ 15 Scenario 3: A switch with Wireless Access Points......... 16 Scenario 4: Network connected facilities gateway......... 18 Scenario 5: Data Center Network.......................... 20 Scenario 7: Switch with Power Distribution Units (PDU)... 24 Scenario 8: Power Consumption of UPS..................... 26 Scenario 9: Power Consumption of Battery-based Devices... 26 7. Link with the other IETF MIBs............................ 26 7.1. Link with the ENTITY MIB and the ENTITY-SENSOR MIB.. 26 7.2. Link with the ENTITY-STATE MIB...................... 28 7.3. Link with the POWER-OVER-ETHERNET MIB............... 28 7.4. Link with the UPS MIB............................... 29 7.5. Link with the LLDP and LLDP-MED MIBs................ 30 8. Structure of the MIB..................................... 31 9. MIB Definitions.......................................... 31 10. Security Considerations................................. 74 11. IANA Considerations..................................... 75 12. Acknowledgment.......................................... 76 13. References.............................................. 76 13.1. Normative References............................... 76 13.2. Informative References............................. 76 14. Authors' Addresses...................................... 77 Expires March 25, 2011 [Page 3] Internet-Draft Sept 2010 TO DO . do we require the ability to have multiple pmDemandEnergyParametersIntervalMode for the same pmIndex? 1. Introduction Network management is typically divided into areas of concerns according to the ISO Telecommunications Management Network model. The model defines Fault, Configuration, Accounting, Performance, and Security Management. Notably missing is an area of concern specifically covering energy management at an equal level to these areas. With energy becoming a more critical area of concern, this document defines a subset of the Management Information Base (MIB) for use with devices in and connected to communication networks for energy management. 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 requirements specified in [POWER-MON-REQ]. Energy management is applicable to devices that comprise and that are connected to a communication network. Target devices for this specification include (but are not limited to): routers, switches, Power over Ethernet (PoE) endpoints, protocol gateways for building management systems, intelligent meters, home energy gateway, hosts and servers, sensor proxy, etc. Where applicable, monitoring of a device is extended to the individual components of the device and/or to any attached dependent device(s). An example of such a case could be when a device contains components that are independent from a power state point of view (such as line cards, processor cards, hard drives) or when a devices has 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 Expires March 25, 2011 [Page 4] Internet-Draft Sept 2010 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 the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Use Cases The requirements for power and energy monitoring for networking devices are specified in [POWER-MON-REQ]. The requirements in [POWER-MON-REQ] cover devices that typically make up a communications network such as such as switches, routers, and various connected endpoints. For power monitoring to be useful, a specification should also be applicable 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. Due to this fact, the scope of the MIB modules in this document is broader than that specified in [POWER-MON-REQ]. Several scenarios that cover these broader use cases are presented later in Section 6 - Implementation Scenarios. 4. Terminology The definitions of the basic terms like Power Monitor, Power Monitor Parent, Power Monitor Child, Power Monitor Domain, Power Level, and Manufacturer Power Level can be found in the Power Management Architecture [POWER-MON-ARCH]. 5. Architecture Concepts Applied to the MIB Module This section will go over the basic concepts specified in the Power Monitor Architecture [POWER-MON-ARCH], with specific information related to the MIB module specified in this document Expires March 25, 2011 [Page 5] Internet-Draft Sept 2010 This subsection structure maps to the section "Architecture High Level Concepts" sub-structure in the Power Monitoring Architecture [POWER-MON-ARCH]. 5.1 Power Monitor Information Refer to the "Power Monitor Information" section in [POWER-MON- ARCH] for background information. The Power Monitor information is specified in the MIB module primary table, i.e. the pmTable. Every Power Monitor SHOULD have a printable name pmName, and MUST HAVE a unique Power Monitor index pmIndex. pmIndex is an unique index greater than zero for each Power Monitor. It is recommended that values be assigned sequentially starting from 1. The value for each pmIndex must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. In addition, that Power Monitor can potentially have an entityPhysicalIndex from the ENTITY MIB [RFC4133] in the pmPhysicalEntity, if supported by the Power Monitor. In case of Power over Ethernet (if the Power over Ethernet MIB is supported on the Power Monitor), the Power Monitor pmethPortIndex and pmethPortGrpIndex must contain the values of pethPsePortIndex and pethPsePortGroupIndex, respectively. In case of LLDP-MED (if the LLDP-MED MIB is supported on the Power Monitor), the Power Monitor pmLldpPortNumber must contain the lldpLocPortNum from the LLDP MIB. Possible pmName conventions are: textual DNS name, MAC-address of the device, interface ifName, or a text string uniquely identifying the Power Monitor. However, if entPhysicalName is present for the respective pmPhysicalEntity (i.e. if the ENTITY- MIB is supported), then the pmName SHOULD be identical to the entPhysicalName. The pmName SHOULD be unique. As an example, in the case of IP phones, pmName can be the device DNS name, while in the case of router/switch line cards, the pmName should contain the entPhysicalName. To distinguish if a Power Monitor is producing, consuming or metering power, the pmPowerCategory MIB object must be implemented. Expires March 25, 2011 [Page 6] Internet-Draft Sept 2010 5.2 Power Monitor Meter Domain Refer to the "Power Monitor Meter Domain" section in [POWER-MON- ARCH] for background information. Each Power Monitor MUST be a member of a Power Monitor Meter Domain, specified by the pmDomainName MIB Object. The pmDomainName, which is part of the pmTable, is a read-write MIB object. 5.3 Power Monitor Parent and Child Refer to the "Power Monitor Parent and Child" section in [POWER- MON-ARCH] for background information. In order to link the Power Monitor Child and the Power Monitor Parent, the pmParentId is introduced. 5.4 Power Monitor Context Refer to the "Power Monitor Context" section in [POWER-MON-ARCH] for background information. A Power Monitor can provide a pmImportance value in the range of 1..100 to help differentiate the use or relative value to the site. The importance range is from 1 (least important) to 100 (most important). The default importance value is 1. A Power Monitor can provide a set of pmKeywords. These keywords are a list of tags that can be used for grouping and summary reporting within or between Power Monitor Meter Domains. Additionally, a Power Monitor can provide a pmRoleDescription string that indicates the purpose the Power Monitor serves in the network or to site/business. 5.5 Power Monitor Levels Refer to the "Power Monitor Levels" section in [POWER-MON-ARCH] for background information. Power Levels, which represent universal states of power management of a Power Monitor, are specified by the pmPowerLevel MIB object. Expires March 25, 2011 [Page 7] Internet-Draft Sept 2010 Via the pmManufacturerActualPowerLevel MIB variable, the manufacturer power levels might be specified, in case the Power Levels specified in this document are not (yet) supported. The manufacturer power level name can be read with the pmManufacturerActualPowerLevel Name MIB variable. The actual Power Level is specified by the pmPowerActualLevel MIB objects. The MIB objects pmPowerLevel and pmManufacturerDefinedPowerLevel are contained in the pmTable MIB table. The pmPowerLevelTable table enumerates the maximum power usage in watts, for every single supported Power Level of each Power Monitor. The pmPowerLevelMappingTable table enumerates the maximum power usage in watts, for every single manufacturer power level. Furthermore, this table maps the manufacturer power levels with the Power Levels specified in this document, more specifically with the PowerMonitorLevel textual convention. Finally, this table returns the name of each manufacturer power level. 5.6 Power Monitor Usage Measurement Refer to the "Power Monitor Usage Measurement" section in [POWER-MON-ARCH] 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). For example, if current power usage of a Power Monitor is 3, it could be 3 W, 3 mW, 3 KW, 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 pmPowerLevelPowerUnitMultiplier, pmDemandIntervalEnergyUnitMultiplier, 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 between different implementations. For this pmPowerOrigin describes whether the measurements were made at the device itself or from a remote source. The pmPowerMeasurementCaliber Expires March 25, 2011 [Page 8] Internet-Draft Sept 2010 describes the method that was used to measure the power and can distinguish actual or estimated values. The nameplate power rating of a Power Monitor is specified in pmPowerNameplate MIB object. 5.7 Optional Power Usage Quality Refer to the "Optional Power Usage Quality" section in [POWER- MON-ARCH] for background information. The optional powerQualityMIB MIB module can be implemented to further describe the 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 pmTable (so with pmIndex as primary index). This pmACPwrQualityTable table contains information such as the configuration (single phase, DEL 3 phases, WYE 3 phases), the voltage, frequency, power accuracy, total active/reactive power/apparent power, the amphere, and the voltage. In case of 3-phase power, the pmACPwrQualityPhaseTable additional table is populated with power quality measurements per phase (so double indexed by the pmIndex 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 the 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. 5.8 Optional Energy Measurement Refer to the "Optional Energy Measurement" section in [POWER- MON-ARCH] for background information. It is relevant to measure the demand only when there are actual power measurements from a Power Monitor, and not when the power Expires March 25, 2011 [Page 9] Internet-Draft Sept 2010 measurement is assumed or predicted as specified in the description clause of the object pmPowerMeasurementCaliber. Two tables are introduced to characterize the energy demand - pmDemandEnergyTable and pmDemandEnergyParametersTable. The pmDemandEnergyParametersTable table consists of parameters defining: the duration of the demand intervals in seconds, pmDemandEnergyParametersIntervalLength; the number of demand intervals kept in the pmDemandEnergyTable, pmDemandEnergyParametersIntervalNumber; the type of demand intervals, pmDemandEnergyParametersIntervalMode, and a same rate used to calculate the average, pmDemandEnergyParametersSampleRate. Judicious choice of the SamplingRate will ensure accurate measurement of power while not imposing an excessive polling burden. There are three types of pmDemandEnergyParametersIntervalMode for energy measurement collection: period, sliding, and total. These three concepts are illustrated by the following three figures for which: - the horizontal axis represents the current time, with the symbol <--- L ---> expressing the pmDemandEnergyParametersIntervalLength, and the pmDemandEnergyIntervalStartTime is represented by S1, S2, S3, S4, ..., Sx where x is the value of pmDemandEnergyParametersIntervalNumber - the vertical axis represents the time interval of sampling and the value of pmDemandEnergyIntervalEnergyUsed can be obtained at the end of the sampling period. The symbol =========== denotes the duration of the sampling period. | | | =========== | |============ | | | | | | | | |============ | | | | | | | <--- L ---> | <--- L ---> | <--- L ---> | | | | | S1 S2 S3 S4 Figure 1 : period pmDemandEnergyParametersIntervalMode A pmDemandEnergyParametersIntervalMode mode of period specifies non-overlapping periodic measurements. Therefore, the next pmDemandEnergyIntervalStartTime is equal to the previous Expires March 25, 2011 [Page 10] Internet-Draft Sept 2010 pmDemandEnergyIntervalStartTime plus pmDemandEnergyParametersIntervalLength. S2=S1+L; S3=S2+L, ... |============ | | | | <--- L ---> | | | | |============ | | | | | | <--- L ---> | | | | | | |============ | | | | | | | | <--- L ---> | | | | | | | | |============ | | | | | | | | | | <--- L ---> | S1 | | | | | | | | | | | | S2 | | | | | | | | | S3 | | | | | | S4 Figure 2 : sliding pmDemandEnergyParametersIntervalMode A pmDemandEnergyParametersIntervalMode mode of sliding specifies overlapping periodic measurements. | | |========================= | | | | | | | | <--- Total length ---> | | | S1 Figure 3 : total pmDemandEnergyParametersIntervalMode Expires March 25, 2011 [Page 11] Internet-Draft Sept 2010 A pmDemandEnergyParametersIntervalMode mode of 'total' specifies a continuous measurement since the last reset. The value of pmDemandEnergyParametersIntervalNumber should be (1) one and pmDemandEnergyParametersIntervalLength is ignored. The pmDemandEnergyParametersStatus is useful to specify the energy measurement is actual and thus to indicate if the pmDemandEnergyTable entries exist or not. The pmDemand Table consists of energy measurements in pmDemandIntervalEnergyUsed, the scale of energy measured, pmDemandIntervalEnergyUnitMultiplier, and the maximum observed demand in a window - pmDemandIntervalMax. The pmDemandEnergyTable and pmDemandEnergyParametersTable will be illustrated with the following example. First, in order to estimate demand, an interval to sample energy should be specified, i.e. pmDemandEnergyParametersIntervalLength can be "900 seconds" and the number of consecutive intervals over which the maximum demand is calculated pmDemandEnergyParametersIntervalNumber as "10". The sampling rate internal to the Power Monitor for measurement of power usage, pmDemandEnergyParametersSampleRate, can be "1000 milliseconds", as set by the Power Monitor as a reasonable value. Then, the pmDemandEnergyParametersStatus is set to active (value 1) to indicate that the Power Monitor should start monitor the usage as per the pmDemandEnergyTable. The indices in the pmDemandEnergyTable are pmIndex, which identifies the Power Monitor, and pmDemandIntervalStartTime, which denotes the start time of the demand measurement interval based on sysUpTime. The value of pmDemandIntervalEnergyUsed is the measured energy consumption over the time interval specified (pmDemandEnergyParametersIntervalLength) based on the Power Monitor internal sampling rate (pmDemandEnergyParametersSampleRate). While choosing the values for the pmDemandEnergyParametersIntervalLength and pmDemandEnergyParametersSampleRate, it is recommended to take into consideration either the network element resources adequate to process and store the sample values and/or the mechanism used to calculate the pmDemandEnergyIntervalEnergyUsed. The units are derived from pmDemandIntervalPowerUnitMultiplier. For example, pmDemandIntervalPowerUsed can be "100" with pmDemandIntervalPowerUnits equal to 0, the demand is 100 watt- hours. pmDemandIntervalMax is the maximum demand observed can be "150 watt-hours". Expires March 25, 2011 [Page 12] Internet-Draft Sept 2010 The pmDemandEnergyTable has a buffer to retain a certain number of intervals, as defined by pmDemandEnergyParametersIntervalNumber. If the default value of "10" is kept, then the pmDemandEnergyTable contains 10 demand measurements, including the maximum. A brief explanation on how the maximum demand can be calculated is presented. The first observed demand measurement value is taken to be the initial maximum. With each subsequent measurement, based on numerical comparison, maximum demand may be updated. The maximum value is retained as long as the measurements are taking place. Based on periodic polling of this table, a NMS could compute the maximum over a longer period, i.e. a month, 3 months, or a year. 5.9 Optional Battery Information EDITOR NOTE: since a merge between this draft and [QUITTEK- POWER-MIB] seems to be the direction that the OPSAWG IETF WG wants to go, one idea is to copy the battery MIB module from [QUITTEK-POWER-MIB]. 6. Implementation Scenarios The scope of power and energy monitoring consists of devices that consume power within and connected to a communications network. These devices include: - Network devices and sub-components: devices such as routers and switches and their sub-components. - Network attached endpoints: devices that use the communications network such as endpoints, PCs, or facility gateways that proxy energy monitor and control for commercial buildings or home automation, - Network attached meters or supplies: devices that can monitor the electrical supply such as smart meters or Universal Power Supplies (UPS) that meter and provide availability. This section provides illustrative examples that model different scenarios for implementation of the Power Monitor including Power Monitor Parent and Power Monitor Child relationships. Scenario 1: Switch with PoE endpoints Consider a PoE IP phone connected to a switch, as displayed on figure 4. The IP phone draws power from the PoE switch. The Expires March 25, 2011 [Page 13] Internet-Draft Sept 2010 switch has the following attributes, also illustrated in Figure 4: pmIndex "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 pmIndex "3", pmPhysicalEntity is "12" and pmPowerMonitorId is "UUID 1003". The power usage of the POE switch port is "12 watts". The POE switch port has the switch as the Power Monitor Parent, with its pmParentID of "1000". The IP phone has the following attributes: the IP phone has pmIndex "31" and pmPowerMonitorId "UUID 2003", but doesn't have an entry for pmPhysicalEntity, as the ENTITY MIB is not supported on this device. The IP phone has a Power Monitor Parent; the POE switch port whose pmPowerMonitorId is "UUID 1003". The power usage of the IP phone is measured at the POE switch port and the pmUsage on the PoE IP phone reports 0. |--------------------------------------------------------------| | Switch | |==============================================================| | |Switch | Switch | Switch | Switch | Switch | | | |pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | | ============================================================ | | | 1 | 2 | UUID 1000 | null | 440 | | | ============================================================ | | | | SWITCH PORT | | ============================================================ | | | Switch | Switch | Switch | Switch | Switch | | | | Port | Port | Port | Port | Port | | | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | | ============================================================ | | | 3 | 12 | UUID 1003 | UUID 1000 | 12 | | | ============================================================ | | ^ | | | | |-------------------------------|----------------------------- | | | POE IP PHONE | | ============================================================== | IP phone| IP phone | IP phone | IP phone | IP phone| | pmIndex | EntPhyIdx| pmPowerMonitorId| pmParentID| pmUsage | ============================================================== Expires March 25, 2011 [Page 14] Internet-Draft Sept 2010 | 31 | 0 | UUID 2003 | UUID 1003 | 0 | ============================================================== Figure 4: Scenario 1 Scenario 2: Switch with PoE endpoints with further connected device(s) Consider the same scenario as example 1 with an IP phone connected to PoE port of a switch. Now, in addition, a PC is also daisy-chained from the IP phone for LAN connectivity. The phone draws power from PoE port of the switch, while the PC draws power from the wall outlet. The attributes of the switch, switch port and IP phone are the same as in Scenario 1. The attributes of the PC are given below. The PC does not have pmPhysicalEntity. The pmIndex of the PC "57", the pmPowerMonitorId is "UUID 3003". The PC has a Power Monitor Parent, i.e. the switch port whose pmPowerMonitorId is "UUID 1003". The power usage of the PC is "120 Watts" and is communicated to the switch port. This example is used to illustrate the 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 upon those messages. |--------------------------------------------------------------| | Switch | |==============================================================| | Switch | Switch | Switch | Switch | Switch | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | ============================================================ | | 1 | 2 | UUID 1000 | null | 440 | | ============================================================ | | | | SWITCH PORT | | ============================================================ | | | Switch | Switch | Switch | Switch | Switch | | | Port | Port | Port | Port | Port | | | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | | ============================================================ | | | 3 | 12 | UUID 1003 | UUID 1000 | 12 | | | ============================================================ | Expires March 25, 2011 [Page 15] Internet-Draft Sept 2010 | ^ | | | | |-----------------------------------|--------------------------| | | POE IP PHONE | | | ============================================================= | IP phone | IP phone |IP phone |IP phone |IP phone| | pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID |pmUsage | ============================================================ | 31 | 0 | UUID 2003 | UUID 1003 | 0 | ============================================================ | | PC connected to switch via IP phone | | ============================================================= | PC | PC |PC |PC | PC | | pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage | ============================================================ | 57 | 0 | UUID 3003 | UUID 1003 | 120 | ============================================================= Figure 5: Scenario 2 Scenario 3: A switch with Wireless Access Points Consider a Wireless Access Point connected to the PoE port of a switch. There are several PCs connected to the Wireless Access Point over Wireless protocols. All PCs draw power from the wall outlets. The switch port is the Power Monitor Parent for the Wireless Access Point (WAP) and the PCs. There is a distinction, between the Power Monitor Children, as the WAP draws power from the PoE port of the switch and the PCs draw power from the wall outlet. The switch has pmIndex "1", pmPhysicalEntity is "2" and pmPowerMonitorId is "UUID 1000". The power usage of the switch is "440 Watts". The switch does not have a Power Monitor Parent. Expires March 25, 2011 [Page 16] Internet-Draft Sept 2010 The PoE switch port has the following attributes - The switch port has pmIndex "3", pmPhysicalEntity is "12" and pmPowerMonitorId is "UUID 1003". The power usage of the POE switch port is "20 watts". The POE switch port has the switch as the parent and the pmParentID is "UUID 1000". The WAP has the following attributes. The WAP doesn't have an entry for pmPhysicalEntity. The WAP has pmIndex "47" and pmPowerMonitorId "UUID 2004" and WAP has a parent; the POE switch port whose pmPowerMonitorId is "UUID 1003". The power usage of the WAP is measured at the PoE switch port. The PC1 and PC2 does not have pmPhysicalEntity. The pmIndex of the PC "53", the pmPowerMonitorId is "UUID 3". The PC has a parent; i.e., the switch PoE port whose pmPowerMonitorId is "UUID 3004". The power usage of the PC is "120 Watts" and is communicated to the switch port. The pmIndex of the PC2 "58", the pmPowerMonitorId is "UUID 5". The PC has a parent; the switch port whose pmPowerMonitorId is "UUID 4004". The power usage of the PC is "120 Watts" and is communicated to the switch port. |--------------------------------------------------------------| | Switch | |==============================================================| | Switch | Switch | Switch | Switch | Switch | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | ============================================================ | | 1 | 2 | UUID 1000 | null | 440 | | ============================================================ | | | | SWITCH PORT | | ============================================================ | | | Switch | Switch | Switch | Switch | Switch | | | | Port | Port | Port | Port | Port | | | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | | ============================================================ | | | 3 | 12 | UUID 1003 | UUID 1000 | 20 | | | ============================================================ | | ^ | | | | |-----------------------------------------------|--------------| | POE Wireless Access Point | | | ============================================================== Expires March 25, 2011 [Page 17] Internet-Draft Sept 2010 | WAP | WAP | WAP | WAP | WAP | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentID | pmUsage | ============================================================== | 47 | 0 | UUID 2004 | UUID 1003 | 0 | ============================================================== . . . . PC1 connected to WAP . . ============================================================== | PC | PC |PC | PC | PC | | pmIndex| pmPhyIdx |pmPowerMonitorId | pmParentID | pmUsage | ============================================================== | 53 | 0 | UUID 3004 | UUID 1003 | 120 | ============================================================== . . PC2 connected to WAP . . ================================================================ | PC | PC |PC | PC | PC | | pmIndex| pmPhyIdx |pmPowerMonitorId | pmParentID | pmUsage | =============================================================== | 58 | 0 | UUID 4004 | UUID 1003 | 120 | ================================================================ Figure 6: Scenario 3 Scenario 4: Network connected facilities gateway At the top of the network hierarchy of a building network is a gateway device that can perform protocol conversion between many facility management devices, such as BACNET, MODBUS, DALI, LON, etc. There are power meters associated with power consuming entities (Heating Ventilation & Air Conditioning - HVAC, lighting, electrical, fire control, elevators, etc). The proposed MIB can be implemented on the gateway device. The gateway can be considered as the Power Monitor Parent, while the power meters associated with the energy consuming entities such can be considered as Power Monitor Children. EntPhysicalIndex is not defined for these Power Monitor Parent or the Children, as the ENTITY MIB is generally not implemented in such an Expires March 25, 2011 [Page 18] Internet-Draft Sept 2010 environment. Hence the gateway, meter 1, and meter 2 have pmPhysicalEntities of value zero. The pmIndex of the gateway is "5", and the pmPowerMonitorId is "UUID 1004". The gateway does not have a Power Monitor Parent; The total power usage of the gateway and its children is "9000 Watts". Meter 1 has pmIndex "100", and pmPowerMonitorId is "UUID 2005". Meter 1 shall report a power usage of "6000 watts". Meter 1 has the gateway as the parent and its pmParentID is "UUID 1004". Meter 2 has pmIndex "101", and pmPowerMonitorId is "UUID 3005". Meter 2 shall report a power usage of "1500 watts". Meter 2 has the gateway as the Power Monitor Parent and its pmParentID is "UUID 1004". --------------------------------------------------------------- | Building Gateway | | | |==============================================================| | Mediat | Mediat | Mediat | Mediat | Mediat | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | ============================================================ | | 5 | None | UUID 1004 | Null | 9000 | | ============================================================ | | | | | ---------------------------------------------------------------- | | | | Meter 1 | | ============================================================= | | Meter1 | Meter1 |Meter1 |Meter1 | Meter1 | | | pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage | |=>|============================================================ | | 100 | 0 | UUID 2005 | UUID 1004 | 6000 | | ============================================================= | | Meter 2 | ============================================================ |=>| Meter2 | Meter2 |Meter2 |Meter2 | Meter2 | | pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage | ============================================================= | 101 | 0 | UUID 3005 | UUID 1004| 1500 | ============================================================= Expires March 25, 2011 [Page 19] Internet-Draft Sept 2010 Figure 7: Scenario 4 Scenario 5: Data Center Network A typical data center network consists of a hierarchy of switches. At the bottom of hierarchy there are servers mounted on a rack, and those are connected to the top of the rack switches. The top switches are connected to aggregation switches that are in turn connected to core switches. As an example, Server 1 and Server 2 are connected to different switch ports of the top switch. The proposed MIB can be implemented on the switches. The switch can be considered as the Power Monitor Parent. The servers can be considered as the Power Monitor Children. The switch has pmIndex "1", pmPhysicalEntity is "2", and the pmPowerMonitorId is "UUID 1000". The power usage of the switch is "440 Watts". The switch does not have a parent. Firstly, the switch ports are non-PoE and have the following attributes - Server 1 is connected to Switch port 1. Switch port 1 has pmIndex "3", pmPhysicalEntity is "12" and pmPowerMonitorId is "UUID 1003". Switch port 2 has pmIndex "4", pmPhysicalEntity is "13" and pmPowerMonitorId is "UUID 1004". The power usage of the non-POE switch port cannot be measured. The switch ports have the switch as the Power Monitor Parent and its pmParentID is "1000". The Server 1 has a value of zero for pmPhysicalEntity. The pmIndex of the Server 1 is "5", and the pmPowerMonitorId is "UUID 2006". Server 1 has a Power Monitor Parent; i.e., the switch port whose pmPowerMonitorId is "1003". The power usage of the Server 1 is "200 Watts" and is communicated to the switch port. The Server 2 has a value of zero for pmPhysicalEntity. The pmIndex of the Server 2 is "6", and the pmPowerMonitorId is "UUID 3006". Server 1 has a parent; i.e., the switch port whose pmPowerMonitorId is "1054". The power usage of the Server 2 is "140 Watts" and is communicated to the switch port. Communication of power usage of Server1 and Server2 to the switch is out of scope of this document. Expires March 25, 2011 [Page 20] Internet-Draft Sept 2010 |--------------------------------------------------------------| | Switch | |==============================================================| | |Switch | Switch | Switch | Switch | Switch | | | |pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | | ============================================================ | | | 1 | 2 | UUID 1000 | null | 440 | | | ============================================================ | | | | | | SWITCH PORT 1 | | ============================================================ | | | Switch | Switch | Switch | Switch | Switch | | | Port1 | Port1 | Port1 | Port1 | Port1 | | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | ============================================================ | | | 3 | 12 | UUID 1003 | UUID 1000 | NULL || | ============================================================ | | | | SWITCH PORT 2 | | ============================================================ | | | Switch | Switch | Switch | Switch | Switch | | | Port2 | Port2 | Port2 | Port2 | Port2 | | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | ============================================================ | | | 4 | 13 | UUID 1004 | UUID 1000 | NULL | | ============================================================ | | | | | |--------------------------------------------------------------| | | | Server 1 connected to switch (Non-POE) | ============================================================= | | Server 1| Server 1 | Server 1 | Server 1 | Server 1 | | | pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID| pmUsage | |=>|============================================================ | | 5 | 0 | UUID 2006 | UUID 1003 | 200 | | ============================================================= | | Server 2 connected to switch (Non-POE) | ============================================================ |=>| Server 2| Server 2 | Server 2 | Server 2 | Server 2 | | pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID| pmUsage | ============================================================= | 6 | 0 | UUID 3006 | UUID 1004 | 140 | ============================================================= Expires March 25, 2011 [Page 21] Internet-Draft Sept 2010 Figure 8: Scenario 5 Scenario 6: Building Gateway Device ------ | NMS | | | ------ | | | ========================(IP Network) ^ | North side interface | ----------------------- | Building Gateway | | | ----------------------- | | Ethernet Interface RS-232/ | | RS-438 | | MODBUS, BACNET, etc... | | --------- | -------- HVAC | Cont | | | Cont | UPS -------------- | roll | |--| roll |--------- | | | er 1 | | | er 3 | | | | --------- | -------- | | | | | | | -------- | ------- Lighting | Cont | | | Cont | Electrical ------------ | roll | |--| roll |------------ | | | er 2| | | er 4 | | | | | -------- | ------- | | Figure 9: Scenario 6 Traditional building systems consists of lighting; Heating, Ventilating, and Air Conditioning (HVAC); metering; fire; Expires March 25, 2011 [Page 22] Internet-Draft Sept 2010 uninterruptible power supplies (UPS); video surveillance; physical access; and others. A simplified illustration of the building gateway network is presented in figure 9. At the top of the network hierarchy of a building network is a gateway device that performs protocol conversion between many facility management devices. The north interface of the building gateway is connected to the NMS. The south side of the building gateway communicates to the controllers, via RS-232/RS-485 interfaces and ethernet interfaces and building management protocols such as BACNET or MODBUS. Each controller is associated with a specific energy consuming function such as HVAC, electrical or lighting. The controllers are in turn connected to the actual building energy management devices-meters, sub-meters, valves, actuators etc. Controller 1 is associated with a meter for the HVAC system and controller 2 can be associated with a meter for the Lighting. With the MIB design, the building gateway can be considered as the Power Monitor Parent, while the controllers associated with the meters can be considered as Power Monitor Children. This assumes that MIB is implemented in the gateway device. Thus the power measurement collected is at the granularity of a controller, which aggregates all the energy measurement collected from all the meters and sub-meters. However, if energy measurement needs to be collected at a meter level, then the MIB should be implemented at the controller level. Typically in building management, the EntPhysicalIndex is not defined for these Power Monitor Parent or the Children, as the ENTITY MIB is generally not implemented for these devices. Hence the gateway, controller 1, and controller 2 have pmPhysicalEntities of value zero. The pmIndex of the gateway is "7", and the pmPowerMonitorId is "UUID 1007". The gateway does not have a Power Monitor Parent; The total power usage of the gateway and its children is "2000 Watts". Controller 1 has pmIndex "707", and pmPowerMonitorId is "UUID 5007". Controller 1 shall report a power usage of "2000 watts". Controller 1 has the gateway as the parent and its pmParentID is "UUID 1007". Controller 2 has pmIndex "708", and pmPowerMonitorId is "UUID 5008". Controller 2 shall report a power usage of "500 watts". Expires March 25, 2011 [Page 23] Internet-Draft Sept 2010 Controller 2 has the gateway as the Power Monitor Parent and its pmParentID is "UUID 1007". ---------------------------------------------------------- | Building Gateway | | | |======================================================== | | Mediat | Mediat | Mediat | Mediat | Mediat | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId|pmUsage | |======================================================== | | 7 | None | UUID 1007 | Null | 2500 | |======================================================== | | ------------------------------------------------------ | | |=> Controller 1 ========================================================= | Cntrl1 | Cntrl1 | Cntrl1 | Cntrl1 | Cntrl1 | | pmIndex | pmPhyIdx |pmPowerMonId|pmParentID | pmUsage | |========================================================| | 707 | 0 | UUID 5007 | UUID 1007 | 2000 | |========================================================= | | |===>Controller 2 ========================================================== | Cntrl2 | Cntrl2 | Cntrl2 | Cntrl2 | Cntrl2 | | pmIndex | pmPhyIdx |pmPowerMonId| pmParentID |pmUsage | | ========================================================| | 708 | 0 | UUID 5008 | UUID 1007 | 500 | | | |=========================================================| Figure 10: Scenario 6 Scenario 7: Switch with Power Distribution Units (PDU) Consider the same scenario as example 1 with two PDUs. The switch draws power from one of the PDU's, while the PDU's are plugged into the switch for LAN connectivity. The attributes of the switch and switch ports are the same as in Scenario 1. The attributes of the PDUs are given below. Expires March 25, 2011 [Page 24] Internet-Draft Sept 2010 The PDU's are network peers of the switch, with their own management agent and no pmPowerMonitor parent pmPowerMonitorId, as the PDU's are Power Monitor Parent themselves. The power usage of the PDU's are reporting 3000 watts and 12000 watts categorized as 'Meter'. This example is used to illustrate the distinction between power supply, metering, and LAN connectivity: the PDUs supply and meter power to 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 upon those messages. |--------------------------------------------------------------| | Switch | |==============================================================| | Switch | Switch | Switch | Switch | Switch | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | ============================================================ | | 1 | 2 | UUID 1000 | null | 440 | | ============================================================ | | | | SWITCH PORT | | ============================================================ | | | Switch | Switch | Switch | Switch | Switch | | | Port | Port | Port | Port | Port | | | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | | ============================================================ | | | 3 | 12 | | UUID 1000 | 0 | | | ============================================================ | | | 4 | 13 | | UUID 1000 | 0 | | | ============================================================ | | ^ | | | | |-----------------------------------|--------------------------| | | PDU #1 (no children) | | | ============================================================= | PDU | PDU |PDU |PDU | Meter | | pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID |pmUsage | ============================================================ | 1 | 1 | UUID 2001 | null | 3000 | ============================================================ | Expires March 25, 2011 [Page 25] Internet-Draft Sept 2010 | PDU #2 (with children)_ | | ============================================================= | PDU | PDU |PDU |PDU | Meter | | pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID |pmUsage | ============================================================ | 1 | 1 | UUID 3001 | null | 600 | | 2 | 2 | UUID 3002 | null | 1000 | | 3 | 3 | UUID 3003 | null | 800 | ============================================================= Figure 11: Scenario 7 Scenario 8: Power Consumption of UPS Data centers and commercial buildings can have Uninterruptible Power Supplies (UPS) connected to the network. The Power Monitor can be used to model a UPS as a Power Monitor Parent with the connected devices as Power Monitor Children. EDITOR'S NOTE: the example will be completed in the future. Scenario 9: Power Consumption of Battery-based Devices As specified in [POWER-MON-REQ], battery state monitoring is a requirement for the Power and Energy Monitoring MIB. EDITOR NOTE: since a merge between this draft and [QUITTEK- POWER-MIB] seems to be the direction that the OPSAWG IETF WG wants to go, one idea is to copy the battery MIB module from [QUITTEK-POWER-MIB]. 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...) and those physical entities listed indexed by entPhysicalIndex. From an energy management point of view, the physical entities that consume or produce energy are of interest. Expires March 25, 2011 [Page 26] Internet-Draft Sept 2010 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 level states of networking equipment and a functionality to configure the power level states. When this MIB module is used to monitor the power usage of devices such as 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. However, the ENTITY-SENSOR MIB [RFC3433] doesn't have the ANSI C12.x accuracy classes required for electricity, i.e., 1%, 2%, 0.5% accuracy classes: indeed, the 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, and not the scientific number precision model as specified in RFC3433. The pmPowerAccuracy MIB object models this accuracy. Note that the pmPowerUnitMultipler represents the scale factor per IEC 61850, 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 by 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 Monitor that needs 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 such as BACNET. Another example is the home energy controller. In such cases, the pmPhysicalEntity value contains the zero value, thanks to PhysicalIndexOrZero textual convention. Expires March 25, 2011 [Page 27] Internet-Draft Sept 2010 The pmIndex 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 Levels are required, as proposed in the Power and Energy Monitoring MIB module. Those Power Levels 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 Level "unknown", "ready", "standby", respectively, while the entStateStandby "providingService" could map to any "low" to "high" Power Level. 7.3. Link with the POWER-OVER-ETHERNET MIB Power-over-Ethernet MIB [RFC3621] provides 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 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 such as BACNET. Another example is the home energy controller. In such cases, the pmethPortIndex and pmethPortGrpIndex values contain the zero value, thanks to new PethPsePortIndexOrZero and textual PethPsePortGroupIndexOrZero conventions. Expires March 25, 2011 [Page 28] Internet-Draft Sept 2010 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 pmIndex MIB object has been kept as the unique Power Monitor index. Note that, even 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 can last only for a finite period of time, until normal power supply is restored. Planning is required to decide on the capacity of UPS based on output power and duration of probable power outage. From a power provisioning point of view of a data center or building, it is important to understand the total demand required to support all the entities in order to plan on the capacity of the UPS to be installed. This demand can be monitored via the Power and Energy Monitoring MIB. UPS MIB [RFC1628] provides information on the state of the UPS network. Implementation of UPS MIB is useful at the aggregate level of a data center or a building. The MIB module contains several groups of variables - upsIdent - to identify the UPS entity (name, model,..), the upsBattery group - to indicate the battery state, (upsbatteryStatus, upsEstimatedMinutesRemaining, ...), upsInput group - to characterize the input load to the UPS (number of input lines, voltage, current,...) , upsOutput - to characterize the output from the UPS (number of output lines, voltage, current,...), upsAlarms - to indicate the various alarm events. The measurement of power in UPS MIB are in Volts, Amps and Watts. The units of power measurement are RMS volts, RMS Amps and are not based on 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 such a case, the UPS device itself would be the Power Monitor Parent and any the UPS meters or submeters would be the Power Monitor Children. Expires March 25, 2011 [Page 29] Internet-Draft Sept 2010 7.5. Link with the LLDP and LLDP-MED MIBs The LLDP Protocol is a Data Link Layer protocol used by network devices for advertising of 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 - capabilities 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 end device such as a PoE phone to convey power requirement to the switch. In the power discovery, the LLDP-MED has four Type Length Value (TLV): 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. The lldpXMedLocXPoEPDPowerSource [LLDP-MED-MIB] is similar to pmPowerOrigin to indicate if the power for an attached device is local or from a remote device. If 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. Expires March 25, 2011 [Page 30] Internet-Draft Sept 2010 8. Structure of the MIB The primary MIB object in this MIB module is the PowerMonitorMIBObject. The pmTable table of PowerMonitorMibObject describes an entity in the network that is a Power Monitor. A Power Monitor contains information to describe the entity in the context of the network (such as its Power Monitor Meter Domain pmDomainName) and attributes for describing its business context (such as pmImportance, pmRoleDescription and pmKeywords). A Power Monitor contains information describing its power usage (pmPower) along with its power state (pmPowerLevel). Along with the power usage is information describing how the power usage was determined (such as pmPowerMeasurementCaliber and pmPowerOrigin). The pmPowerLevelMappingTable table enumerates the maximum power usage in watts, for every single manufacturer power level. Furthermore, this table maps the manufacturer power levels with the Power Levels specified in this document, more specifically with the PowerMonitorLevel textual convention. Finally, this table returns the name of each manufacturer power level. A Power Monitor may also 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 pmDemandEnergyTable to describe energy information over time. A Power Monitor may also contain optional battery information associated with this entity. EDITOR NOTE: since a merge between this draft and [QUITTEK- POWER-MIB] seems to be the direction that the OPSAWG IETF WG wants to go, one idea is to copy the battery MIB module from [QUITTEK-POWER-MIB]. 9. MIB Definitions -- ************************************************************ -- -- Expires March 25, 2011 [Page 31] Internet-Draft Sept 2010 -- This MIB is used to monitor power usage of network -- devices -- -- ************************************************************* POWER-MONITOR-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Integer32, TimeTicks FROM SNMPv2-SMI TEXTUAL-CONVENTION, DisplayString, RowStatus, TimeInterval FROM SNMPv2-TC MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB PhysicalIndexOrZero FROM ENTITY-MIB; powerMonitorMIB MODULE-IDENTITY LAST-UPDATED "201005300000Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO "Cisco Systems Customer Service Postal: 170 W Tasman Drive San Jose, CA 95134 USA Tel: +1 800 553-NETS E-mail: cs-snmp@cisco.com" DESCRIPTION "This MIB is used to monitor power and energy in devices." REVISION "201005300000Z" DESCRIPTION Expires March 25, 2011 [Page 32] Internet-Draft Sept 2010 "Initial version, published as RFC XXXX." ::= { mib-2 xxxxx } powerMonitorMIBNotifs OBJECT IDENTIFIER ::= { powerMonitorMIB 0 } powerMonitorMIBObjects OBJECT IDENTIFIER ::= { powerMonitorMIB 1 } powerMonitorMIBConform OBJECT IDENTIFIER ::= { powerMonitorMIB 2 } -- Textual Conventions PowerMonitorLevel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An enumerated integer value that represents the value of the power policy level, a current power setting at which a Power Monitor uses power. There are twelve power policy levels; divided into six operational states, and six non-operational states. The lowest non-operational state is 1 and the highest is six. Each non- operational state corresponds to an ACPI level [ACPI]. Global and System level state between G3 (hard-off) and G1 (sleeping). For operational levels, 6 is the lowest, and 12 the highest (full power). Each operational level represent a performance state, and may be mapped to ACPI states P0 (maximum performance & power) through P5 (minimum performance and minimum power). An entity may have fewer power levels than twelve and would then map several policy levels to the same power state. Entities with more than twelve levels, would choose which twelve to represent as power policy levels. Note that Power Monitor Parent MUST report some of the non operational Power Levels of its Power Monitor Children who are unable to report their Power Level. A typical example a phone which may notify its Power Monitor Parent that it will go into a mechoff(1) or hibernate(3) state so that the Power Monitor Parent can report the phone's current state, for example either Expires March 25, 2011 [Page 33] Internet-Draft Sept 2010 zero or 1 watt. Conversely, a PC with Desktop and mobile Architecture for System Hardware [DASH] out-of-band management is an example where a Power Monitor Child can report its usage and level even when in a non-operational state. In each of the non operational levels (from mechoff(1) to ready(6)), the Power Level preceding it is expected to have a lower power consumption and a longer delay in returning to an operational state. 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 the level G3 in ACPI. softoff(2) : Similar to mechoff(1), but some components remain powered or receive trace power so that the entity can be woken from its off state. In softoff(2), no context is saved and the device typically requires a complete boot when awakened. This corresponds to level G2 in ACPI. hibernate(3): No entity features are available. The entity may be woken up without requiring a complete boot, but the time for 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 level 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 level G1, S3 in ACPI. standby(5) : No entity features are available, except for out-of-band management, for example Expires March 25, 2011 [Page 34] Internet-Draft Sept 2010 wake-up mechanisms. This mode is analogous to cold-standy. The time for availability is longerthan ready(6). For example, the processor context is not maintained. Typically, energy consumption is close to zero. This corresponds to level 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-standy. The entity can be quickly transitioned into an operational state. For example, processors are not executing, but processor context is maintained. This corresponds to level G1, S1 in ACPI. lowMinus(7) : Indicates some entity features may not be available and the entity has taken measures/options to provide less than low(8) usage. This corresponds to ACPI State G0; which includes operational levels lowMinus(7) to full(12). low(8) : Indicates some features may not be available and the entity has taken 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/options to provide less than medium(10) usage. medium(10) : Indicates all entity features are available but the entity has taken measures/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 Expires March 25, 2011 [Page 35] Internet-Draft Sept 2010 available and the entity is consuming the highest power. Note that unknown(0) is not a Power Level as such, but simply an indication that the Power Level unavailable. " SYNTAX INTEGER { unknown(0), mechoff(1), softoff(2), hibernate(3), sleep(4), standby(5), ready(6), lowMinus(7), low(8), mediumMinus(9), medium(10), highMinus(11), high(12) } PowerMonitorId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This object indicates the Power Monitor Universally Unique Identifier." REFERENCE "IETF RFC 4122" SYNTAX OCTET STRING (SIZE (16)) UnitMultiplier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "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 Expires March 25, 2011 [Page 36] Internet-Draft Sept 2010 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 } PethPsePortIndexOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the pethPsePortIndex convention, which defines a greater than zero value used to identify a power Ethernet PSE port. This extension permits the additional value of zero. The semantics of the value zero are object-specific and must, therefore, be defined as part of the description of any object that uses this syntax. Examples of the usage of this extension are situations where none or all physical entities need to be referenced." SYNTAX Integer32 (0..2147483647) PethPsePortGroupIndexOrZero::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the pethPsePortGroupIndex convention, which defines a greater than zero value used to identify group containing the port to which a power Ethernet PSE is connected. This extension permits the additional value of zero. The semantics of the value zero are object-specific and must, therefore, be defined as part of the description of any object that uses this syntax. Examples of the usage of Expires March 25, 2011 [Page 37] Internet-Draft Sept 2010 this extension are situations where none or all physical entities need to be referenced." SYNTAX Integer32 (0..2147483647) LldpPortNumberOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This textual convention is an extension of the LldpPortNumber convention specified in the LLDP MIB, which defines a greater than zero value used to uniquely identify each port contained in the chassis (that is known to the LLDP agent) by a port number. This extension permits the additional value of zero. The semantics of the value zero are object-specific and must, therefore, be defined as part of the description of any object that uses this syntax. Examples of the usage of this extension are situations where none or all physical entities need to be referenced." SYNTAX Integer32(0..4096) PowerMonitorKeywordList ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A list of keywords that can be used to group Power Monitors for reporting or searching. If multiple keywords are present, then this string will contain all the keywords separated by ',' character. For example, If a Power Monitor were to be tagged with a values of 'hospitality' and 'guest' then the keyword list will be 'hospitality,guest'." SYNTAX OCTET STRING (SIZE (0..255)) -- Objects pmTable OBJECT-TYPE SYNTAX SEQUENCE OF PmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists Power Monitors." Expires March 25, 2011 [Page 38] Internet-Draft Sept 2010 ::= { powerMonitorMIBObjects 1 } pmEntry OBJECT-TYPE SYNTAX PmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes the attributes of a Power Monitor. Whenever a new Power Monitor is added or deleted a row in the pmTable is added or deleted." INDEX { pmIndex } ::= { pmTable 1 } PmEntry ::= SEQUENCE { pmIndex Integer32, pmPowerMonitorId PowerMonitorId, pmPhysicalEntity PhysicalIndexOrZero, pmEthPortIndex PethPsePortIndexOrZero, pmEthPortGrpIndex PethPsePortGroupIndexOrZero, pmLldpPortNumber LldpPortNumberOrZero, pmName SnmpAdminString, pmDomainName SnmpAdminString, pmRoleDescription SnmpAdminString, pmKeywords PowerMonitorKeywordList, pmImportance Integer32, pmParentId PowerMonitorId, pmPower Integer32, pmPowerNameplate Integer32, pmPowerUnitMultiplier UnitMultiplier, pmPowerAccuracy Integer32, pmPowerMeasurementCaliber INTEGER, pmPowerOrigin INTEGER, pmPowerCategory BITS, pmPowerLevel PowerMonitorLevel, pmPowerActualLevel PowerMonitorLevel, pmManufacturerActualPowerLevel Integer32, pmManufacturerMappingId Integer32, pmCurrentType INTEGER, } pmIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires March 25, 2011 [Page 39] Internet-Draft Sept 2010 "A unique value, greater than zero, for each Power Monitor. It is recommended that values be assigned sequentially starting from 1. The value for each pmIndex must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization." ::= { pmEntry 1 } pmPowerMonitorId OBJECT-TYPE SYNTAX PowerMonitorId MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the Power Monitor UUID identifier." ::= { pmEntry 2 } pmPhysicalEntity OBJECT-TYPE SYNTAX PhysicalIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the index of a physical entity in the ENTITY MIB. This physical entity is the given observation point. If such a physical entity cannot be specified or is not known then the object is zero." ::= { pmEntry 3 } pmEthPortIndex OBJECT-TYPE SYNTAX PethPsePortIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the power Ethernet port to which the attached device is connected [RFC3621]. If such a power Ethernet port cannot be specified or is not known then the object is zero." ::= { pmEntry 4 } pmEthPortGrpIndex OBJECT-TYPE SYNTAX PethPsePortGroupIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the group containing the port to which a power Ethernet PSE is connected [RFC3621]. If such a group cannot be specified or is not known then the object is zero." Expires March 25, 2011 [Page 40] Internet-Draft Sept 2010 ::= { pmEntry 5 } pmLldpPortNumber OBJECT-TYPE SYNTAX LldpPortNumberOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the port component (contained in the local chassis with the LLDP agent) as defined by the lldpLocPortNum in the [LLDP-MIB] and [LLDP-MED-MIB]. If such a port number cannot be specified or is not known then the object is zero." ::= { pmEntry 6 } pmName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies a printable name, a text string, for the Power Monitor. The pmName SHOULD be unique.If pmPhysicalName is present for the respective pmPhysicalEntity (i.e. if the ENTITY-MIB is supported), then the pmName SHOULD be identical to the pmPhysicalName. If pmPhysicalName is not present, the process to assign the pmName can be implementation specific. Example: DNS Name, MAC address in canonical form, ifName, etc However, if pmPhysicalName is present for the respective pmPhysicalEntity (i.e. if the ENTITY-MIB is supported), then the pmName should be identical to the pmPhysicalName" ::= { pmEntry 7 } pmDomainName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the name of a Power Monitor Meter Domain for the Power Monitor. This object specifies a null string if no Power Monitor Domain name is configured. The value of pmDomainName must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization." ::= { pmEntry 8 } Expires March 25, 2011 [Page 41] Internet-Draft Sept 2010 pmRoleDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies an administratively assigned name to indicate the purpose a Power Monitor serves in the network. For example, we can have a phone deployed to a lobby with pmRoleDescription as 'Lobby IP phone'. This object specifies a null string if no role description is configured." ::= { pmEntry 9 } pmKeywords OBJECT-TYPE SYNTAX PowerMonitorKeywordList MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies a list of keywords that can be used to group Power Monitors for reporting or searching. PowerMonitorKeywordList This object specifies the null string if no keywords have been configured. For example, if the Power Monitors were to be tagged with the value of 'hospitality' and 'guest' then the keyword list will be hospitality, guest. If write access is implemented and a value is written into the instance, the agent must retain the supplied value in the pmKeywords instance associated with the same physical entity for as long as that entity remains instantiated. This includes instantiations across all re-initializations/reboots of the network management system." ::= { pmEntry 10 } pmImportance OBJECT-TYPE SYNTAX Integer32 (1..100) MAX-ACCESS read-write STATUS current DESCRIPTION Expires March 25, 2011 [Page 42] Internet-Draft Sept 2010 "This object specifies a ranking of how important the Power Monitor is on a scale of 1 to 100 compared to other Power Monitors in the same Power Monitor Meter Domain. The ranking should provide a business or operational context for the Power Monitor as compared to other similar Power Monitors: this ranking could be used as input for policy-based network management. Although network managers must establish their own ranking the following is a broad recommendation: 90 to 100 Emergency response 80 to 90 Executive or business critical 70 to 79 General or Average 60 to 69 Staff or support 40 to 59 Public or guest 1 to 39 Decorative or hospitality" DEFVAL { 1 } ::= { pmEntry 11 } pmParentId OBJECT-TYPE SYNTAX PowerMonitorId MAX-ACCESS read-only STATUS current DESCRIPTION "If the current Power Monitor has a Power Monitor Parent, then its Power Monitor Id value is set in pmParentId. Otherwise, the pmParentId value is the null string." ::= { pmEntry 12 } pmPower OBJECT-TYPE SYNTAX Integer32 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the 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 a consuming power the pmPower value will be positive. If the Power Monitor is producing power the pmPower value will be negative. Expires March 25, 2011 [Page 43] Internet-Draft Sept 2010 The pmPower MUST be less than or equal to the maximum power that can be consumed the power level specified by pmPowerLevel." ::= { pmEntry 13 } pmPowerNameplate OBJECT-TYPE 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." ::= { pmEntry 14 } pmPowerUnitMultiplier OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of watts for the usage value in pmPower and pmPowerNameplate." ::= { pmEntry 15 } 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 accuracy to which the usage, reported by the pmPower can be assumed. Example 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: Expires March 25, 2011 [Page 44] Internet-Draft Sept 2010 IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. ANSI C12.20 class 0.2, 0.5" ::= { pmEntry 16 } pmPowerMeasurementCaliber OBJECT-TYPE SYNTAX INTEGER { unknown(1), actual(2) , estimated(3), presumed(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies how the usage value, reported by pmPower, is obtained. - unknown: This indicates that the way the usage is 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: This caliber rating indicates that usage was measured by the entity presumably 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: This 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. The entity's state and current configuration was presumably used to compute the value. - presumed: This indicates that the usage was not determine 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." ::= { pmEntry 17 } pmPowerOrigin OBJECT-TYPE SYNTAX INTEGER { self (1), remote (2) Expires March 25, 2011 [Page 45] Internet-Draft Sept 2010 } 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." ::= { pmEntry 18 } pmPowerCategory OBJECT-TYPE SYNTAX BITS { consumer(0), provider(1), meter(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the power usage type of the Power Monitor. A Power Monitor could be producing power when pmPowerCategory is provider(1) or a consumer of power consumer(0) or a meter(2). Negative values of power usage are used to indicate the entity is a power source. Consumer: This indicates that the Power Monitor consumes power. Provider: This indicates that the Power Monitor generates or provides power. Meter: This indicates that the Power Monitor is a meter which reads the power provided or consumed by other sources." ::= { pmEntry 19 } pmPowerLevel OBJECT-TYPE SYNTAX PowerMonitorLevel MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the current Power Level (0..12) that was requested for the Power Monitor. The pmPowerLevel values are increasing with the power consumption. A difference in values between the Expires March 25, 2011 [Page 46] Internet-Draft Sept 2010 pmPowerLevel and pmPowerActualLevel indicates that Power Monitor SHOULD go into the pmPowerLevel, at which point it will update the content of pmPowerActualLevel. If the Power Monitor is unable to report its Power Level, it must report the value unknown(0). Note that unknown(0) is not a Power Level as such, but simply an indication that the Power Level is unknown." ::= { pmEntry 20 } pmPowerActualLevel OBJECT-TYPE SYNTAX PowerMonitorLevel MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the current Power Level (0..12) for the Power Monitor. If the Power Monitor is unable to report its Power Level, it must report the value unknown(0). Note that unknown(0) is not a Power Level as such, but simply an indication that the Power Level is unknown." ::= { pmEntry 21 } pmManufacturerActualPowerLevel OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the actual manufacturer power level (-10000..10000) for the Power Monitor. If the manufacturer power level is not defined, the pmManufacturerActualPowerLevel will report 0xFFFF. If the Power Monitor is unable to report its Manufacturer Power Level, it must report the value 0xFFFF." ::= { pmEntry 22 } pmManufacturerMappingId OBJECT-TYPE SYNTAX Integer32 (1..1000) MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the actual manufacturer power level mapping id for the Power Monitor. The pmManufacturerMappingId points to the pmPowerLevelMappingTable, which maps the manufacturer power levels versus the standard ones specified in the PowerMonitorLevel textual convention. If the manufacturer power level mapping is not defined, the Expires March 25, 2011 [Page 47] Internet-Draft Sept 2010 pmManufacturerMappingId will report 0. If the Power Monitor is unable to report its Manufacturer Power Level mapping id, it must report the value 0." ::= { pmEntry 23 } pmCurrentType OBJECT-TYPE SYNTAX INTEGER { ac(1), dc(2), 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 whether the value is unknown(3)." ::= { pmEntry 24 } pmPowerLevelTable OBJECT-TYPE SYNTAX SEQUENCE OF PmPowerLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enumerates the maximum power usage in watts, for every single supported Power Level of each Power Monitor. This table has an expansion dependent relationship on the pmTable, containing rows describing each Power Level for the corresponding Power Monitor. For every Power Monitor in the pmTable, there is a corresponding entry in this table. " ::= { powerMonitorMIBObjects 2 } pmPowerLevelEntry OBJECT-TYPE SYNTAX PmPowerLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A pmPowerLevelEntry extends a corresponding pmEntry. This entry displays max usage values at every single possible Power Monitor Level supported by the Power Monitor. For example, given the values of a Power Monitor corresponds to a maximum usage of 11W at the level 1 (off), 6 (low), 8 (medium), 12 (full): Expires March 25, 2011 [Page 48] Internet-Draft Sept 2010 Level MaxUsage Units 1 0 0 5 0 0 6 8 0 7 8 0 8 11 0 12 11 0" INDEX { pmIndex, pmPowerLevelIndex } ::= { pmPowerLevelTable 1 } PmPowerLevelEntry ::= SEQUENCE { pmPowerLevelIndex PowerMonitorLevel, pmPowerLevelMaxPower Integer32, pmPowerLevelPowerUnitMultiplier UnitMultiplier } pmPowerLevelIndex OBJECT-TYPE SYNTAX PowerMonitorLevel MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object indicates the level for which this entry describes the power usage." ::= { pmPowerLevelEntry 1 } pmPowerLevelMaxPower 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 Level. This value is specified in SI units of watts with the magnitude of the units (milliwatts, kilowatts, etc.) indicated separately in pmPowerLevelPowerUnitMultiplier. If the maximum power is not known for a certain Power Level, then the value is encoded as 0xFFFF. Expires March 25, 2011 [Page 49] Internet-Draft Sept 2010 For Power Levels not enumerated, the value of pmPowerLevelMaxPower might be interpolated by using the next highest supported Power Level." ::= { pmPowerLevelEntry 2 } pmPowerLevelPowerUnitMultiplier OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of watts for the usage value in pmPowerLevelMaxPower." ::= { pmPowerLevelEntry 3 } pmPowerLevelMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF pmPowerLevelMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enumerates the maximum power usage in watts, for every single manufacturer power level. Furthermore, this table maps the manufacturer power levels with the Power Levels specified in this document, more specifically with the PowerMonitorLevel textual convention. Finally, this table returns the name of each manufacturer power level. For every different pmManufacturerMappingId in the pmTable, there is a corresponding entry in this table." ::= { powerMonitorMIBObjects 3 } pmPowerLevelMappingEntry OBJECT-TYPE SYNTAX PmPowerLevelMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "For every pmManufacturerMappingId, this entry displays the max usage value at every single possible manufacturer power level supported by the Power Monitor, along with the mapping at the standardized Power Level For example, given the values of a Power Monitor corresponds to a maximum usage of 0, 3, 7, and 11W at the level 1 (off), 2 (low), 3 (medium), 4 (full), respecitvley: Pow. Lev. Manu. Pow. Lev./Name maxUsage 1 1/off 0 W 6 2/low 3 W Expires March 25, 2011 [Page 50] Internet-Draft Sept 2010 8 3/medium 7 W 12 4/full 11 W" INDEX { pmManufacturerMappingId, pmPowerLevelIndex, pmManufacturerDefinedPowerLevel } ::= { pmPowerLevelMappingTable 1 } PmPowerLevelMappingEntry ::= SEQUENCE { pmManufacturerDefinedPowerLevel Integer32, pmManufacturerPowerLevelMaxPower Integer32, pmManufacturerPowerLevelPowerUnitMultiplier UnitMultiplier, pmManufacturerPowerLevelName DisplayString } pmManufacturerDefinedPowerLevel OBJECT-TYPE SYNTAX Integer32 (0..10000) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object specifies the manufacturer power levels for the specific pmManufacturerMappingId." ::= { pmPowerLevelMappingEntry 1 } pmManufacturerPowerLevelMaxPower OBJECT-TYPE SYNTAX Integer32 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the maximum power for the manufacturer power level specified by the pmManufacturerDefinedPowerLevel index. This value is specified in SI units of watts with the magnitude of the units (milliwatts, kilowatts, etc.) indicated separately in pmManufacturerPowerLevelPowerUnitMultiplier. If the maximum power is not known for a certain Power Level, then the value is encoded as 0xFFFF. For Power Levels not enumerated, the value of pmManufacturerPowerLevelMaxPower might be interpolated by using the next highest supported Power Level." ::= { pmPowerLevelMappingEntry 2 } pmManufacturerPowerLevelPowerUnitMultiplier OBJECT-TYPE Expires March 25, 2011 [Page 51] Internet-Draft Sept 2010 SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of watts for the usage value in pmManufacturerPowerLevelMaxPower ." ::= { pmPowerLevelMappingEntry 3 } pmManufacturerPowerLevelName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "The textual name of the manufacturer name for the power level specified by the pmManufacturerDefinedPowerLevel index. If there is no local name, or this object is otherwise not applicable, then this object contains a zero-length string." ::= { pmPowerLevelMappingEntry 4 } pmDemandEnergyParametersTable OBJECT-TYPE SYNTAX SEQUENCE OF PmDemandEnergyParametersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls and configures the demand table pmDemandEnergyTable." ::= { powerMonitorMIBObjects 4 } pmDemandEnergyParametersEntry OBJECT-TYPE SYNTAX PmDemandEnergyParametersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry controls an energy measurement in pmDemandEnergyTable." INDEX { pmIndex } ::= { pmDemandEnergyParametersTable 1 } PmDemandEnergyParametersEntry ::= SEQUENCE { pmDemandEnergyParametersIntervalLength TimeInterval, pmDemandEnergyParametersIntervalNumber Integer32, pmDemandEnergyParametersIntervalMode Integer32, pmDemandEnergyParametersIntervalWindow TimeInterval, pmDemandEnergyParametersSampleRate Integer32, pmDemandEnergyParametersStatus RowStatus } Expires March 25, 2011 [Page 52] Internet-Draft Sept 2010 pmDemandEnergyParametersIntervalLength OBJECT-TYPE SYNTAX TimeInterval UNITS "Seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates the length of time in seconds over which to compute the average pmDemandIntervalEnergyUsed measurement in the pmDemandEnergyTable table. The computation is based on Power Monitor internal sampling rate of power usage of the Power Monitor. The sampling rate may differ based on device capabilities. The average energy consumption is computed over the length of the demand interval." DEFVAL { 900 } ::= { pmDemandEnergyParametersEntry 1 } pmDemandEnergyParametersIntervalNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The number of demand intervals maintained in the pmDemandEnergyTable table. Each interval is characterized by a specific pmDemandIntervalStartTime, used as an index in the the table pmDemandEnergyTable table pmDemandIntervalStartTime. Whenever the maximum number of entry is reached, the new demand interval replaces the oldest one, except if the oldest one is the pmDemandIntervalMax. In which case, the next oldest interval is replaced." DEFVAL { 10 } ::= { pmDemandEnergyParametersEntry 2 } pmDemandEnergyParametersIntervalMode OBJECT-TYPE SYNTAX INTEGER { period(1), sliding(2), total(3) } MAX-ACCESS read-write STATUS current DESCRIPTION Expires March 25, 2011 [Page 53] Internet-Draft Sept 2010 "A control object to define the mode of interval calculation for the computation of the average pmDemandIntervalEnergyUsed measurement in the pmDemandEnergyTable 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 pmDemandEnergyParametersIntervalWindow. A mode of total(3) specifies non-periodic measurement. In this mode only one interval is used as this is a continuous measurement since the last reset. The value of pmDemandEnergyParametersIntervalNumber should be (1) one and pmDemandEnergyParametersIntervalLength is ignored. " ::= { pmDemandEnergyParametersEntry 3 } pmDemandEnergyParametersIntervalWindow OBJECT-TYPE SYNTAX TimeInterval UNITS "Seconds" MAX-ACCESS read-write 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 pmDemandIntervalEnergyUsed measurement in the pmDemandEnergyTable table This is valid only when the pmDemandEnergyParametersIntervalMode is sliding(2). The pmDemandEnergyParametersIntervalWindow value should be a multiple of pmDemandEnergyParametersSampleRate " ::= { pmDemandEnergyParametersEntry 4 } pmDemandEnergyParametersSampleRate OBJECT-TYPE SYNTAX Integer32 UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The sampling rate in milliseconds at which the Power Monitor should poll the power usage in order to compute the average pmDemandIntervalEnergyUsed measurement in the table pmDemandEnergyTable. The Power Monitor should initially set this sample 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 Expires March 25, 2011 [Page 54] Internet-Draft Sept 2010 that it would impact the Power Monitor performance by requesting continuous polling. If the sample rate is unknown, the value 0 is reported. The sample rate should be selected so that pmDemandEnergyParametersIntervalWindow would be a multiple of pmDemandEnergyParametersSampleRate " DEFVAL { 1000 } ::= { pmDemandEnergyParametersEntry 5 } pmDemandEnergyParametersStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. The pmDemandEnergyParametersStatus 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 pmDemandEnergyTable shall be deleted. The data can be destroyed by setting up the pmDemandEnergyParametersStatus to destroy(2)." ::= {pmDemandEnergyParametersEntry 6 } pmDemandEnergyTable OBJECT-TYPE SYNTAX SEQUENCE OF PmDemandEnergyEntry 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 } pmDemandEnergyEntry OBJECT-TYPE SYNTAX PmDemandEnergyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing energy measurements " INDEX { pmIndex, pmDemandEnergyIntervalStartTime } ::= { pmDemandEnergyTable 1 } Expires March 25, 2011 [Page 55] Internet-Draft Sept 2010 PmDemandEnergyEntry ::= SEQUENCE { pmDemandEnergyIntervalStartTime TimeTicks, pmDemandEnergyIntervalEnergyUsed Integer32, pmDemandEnergyIntervalEnergyUnitMultiplier UnitMultiplier, pmDemandEnergyIntervalMax Integer32 } pmDemandEnergyIntervalStartTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of seconds" MAX-ACCESS not-accessible STATUS current DESCRIPTION "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 period for which the demand is measured. " ::= { pmDemandEnergyEntry 1 } pmDemandEnergyIntervalEnergyUsed 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 watts-hours with the magnitude of watt-hours (kW-Hr, MW- Hr, etc.) indicated separately in pmDemandEnergyIntervalEnergyUnitMultiplier." ::= { pmDemandEnergyEntry 2 } pmDemandEnergyIntervalEnergyUnitMultiplier OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "This magnitude of watt-hours for the energy field in pmDemandEnergyIntervalEnergyUsed." ::= { pmDemandEnergyEntry 3 } pmDemandEnergyIntervalMax OBJECT-TYPE SYNTAX Integer32 UNITS "Watt-hours" MAX-ACCESS read-only Expires March 25, 2011 [Page 56] Internet-Draft Sept 2010 STATUS current DESCRIPTION "This object is the maximum demand ever observed in pmDemandEnergyIntervalEnergyUsed since the monitoring started. This value is specified in the common billing units of watts-hours with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) indicated separately in pmDemandEnergyIntervalEnergyUnits." ::= { pmDemandEnergyEntry 4 } -- Notifications pmPowerLevelChange NOTIFICATION-TYPE OBJECTS {pmPowerLevel,pmManufacturerActualPowerLevel} STATUS current DESCRIPTION "The SNMP entity generates the PmPowerLevelChange when the value(s) of pmPowerLevel and/or pmManufacturerActualPowerLevel has changed for the Power Monitor represented by the pmIndex" ::= { 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, powerMonitorMIBLevelTableGroup, powerMonitorMIBDemandEnergyTableGroup, powerMonitorMIBDemandEnergyParametersTableGroup, powerMonitorMIBNotifGroup } Expires March 25, 2011 [Page 57] Internet-Draft Sept 2010 ::= { powerMonitorMIBCompliances 1 } 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, powerMonitorMIBLevelTableGroup, pmPowerLevelMappingTableGroup, powerMonitorMIBNotifGroup } OBJECT pmName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmDomainName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmRoleDescription MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmKeywords MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmImportance MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmPowerLevel MIN-ACCESS read-only DESCRIPTION "Write access is not required." Expires March 25, 2011 [Page 58] Internet-Draft Sept 2010 ::= { powerMonitorMIBCompliances 2 } -- Units of Conformance powerMonitorMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object pmIndex is NOT -- included since it is not-accessible pmPowerMonitorId, pmPhysicalEntity, pmEthPortIndex, pmEthPortGrpIndex, pmLldpPortNumber, pmName, pmDomainName, pmRoleDescription, pmKeywords, pmImportance, pmParentId, pmPower, pmPowerNameplate, pmPowerUnitMultiplier, pmPowerAccuracy, pmPowerMeasurementCaliber, pmPowerOrigin, pmPowerCategory, pmPowerLevel, pmPowerActualLevel, pmManufacturerActualPowerLevel, pmManufacturerMappingId, pmCurrentType } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the PowerMonitor." ::= { powerMonitorMIBGroups 1 } powerMonitorMIBLevelTableGroup OBJECT-GROUP OBJECTS { pmPowerLevelMaxPower, pmPowerLevelPowerUnitMultiplier } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the Power Level. " ::= { powerMonitorMIBGroups 2 } Expires March 25, 2011 [Page 59] Internet-Draft Sept 2010 pmPowerLevelMappingTableGroup OBJECT-GROUP OBJECTS { pmManufacturerPowerLevelMaxPower, pmManufacturerPowerLevelPowerUnitMultiplier, pmManufacturerPowerLevelName } STATUS current DESCRIPTION "This table enumerates the maximum power usage in watts, for every single manufacturer power level." ::= { powerMonitorMIBGroups 3 } powerMonitorMIBDemandEnergyParametersTableGroup OBJECT-GROUP OBJECTS { pmDemandEnergyParametersIntervalLength, pmDemandEnergyParametersIntervalNumber, pmDemandEnergyParametersIntervalMode, pmDemandEnergyParametersIntervalWindow, pmDemandEnergyParametersSampleRate, pmDemandEnergyParametersStatus } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the configuration of the Demand Table." ::= { powerMonitorMIBGroups 4 } powerMonitorMIBDemandEnergyTableGroup OBJECT-GROUP OBJECTS { -- Note that object -- pmDemandIntervalStartTime is not -- included since it is not-accessible pmDemandEnergyIntervalEnergyUsed, pmDemandEnergyIntervalEnergyUnitMultiplier, pmDemandEnergyIntervalMax } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the Demand Table." ::= { powerMonitorMIBGroups 5 } powerMonitorMIBNotifGroup NOTIFICATION-GROUP Expires March 25, 2011 [Page 60] Internet-Draft Sept 2010 NOTIFICATIONS { pmPowerLevelChange } STATUS current DESCRIPTION "This group contains the notifications for the power and energy monitoring MIB Module." ::= { powerMonitorMIBGroups 6 } 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, NOTIFICATION-TYPE, mib-2, Integer32 FROM SNMPv2-SMI MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION FROM SNMPv2-TC UnitMultiplier, pmTable, pmIndex FROM POWER-MONITOR-MIB ; powerQualityMIB MODULE-IDENTITY LAST-UPDATED "201005300000Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO "Cisco Systems Customer Service Postal: 170 W Tasman Drive Expires March 25, 2011 [Page 61] Internet-Draft Sept 2010 San Jose, CA 95134 USA Tel: +1 800 553-NETS E-mail: cs-snmp@cisco.com" DESCRIPTION "This MIB is used to report AC power quality in devices. The table is a sparse augmentation of the pmTable table from the powerMonitorMIB module. Both three phase and single phase power configurations are supported." REVISION "201005300000Z" DESCRIPTION "Initial version, published as RFC XXXX." ::= { mib-2 yyyyy } 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 pmIndex entities. It is a sparse extension of the pmTable." ::= { powerQualityMIBObjects 1 } pmACPwrQualityEntry OBJECT-TYPE SYNTAX PmACPwrQualityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a sparse extension of the pmTable with entries for power quality measurements or configuration. Each measured value corresponds to an attribute in IEC Expires March 25, 2011 [Page 62] Internet-Draft Sept 2010 61850-7-4 for non-phase measurements within the object MMUX." INDEX { pmIndex } ::= { pmACPwrQualityTable 1 } 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 Expires March 25, 2011 [Page 63] Internet-Draft Sept 2010 DESCRIPTION "A measured value for average 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'" ::= { 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 Expires March 25, 2011 [Page 64] Internet-Draft Sept 2010 "This object indicates a percentage value in 100ths of a percent representing the accuracy of active, reactive, and apparent power can be assumed. Example 1010 means the reported usage is accurate 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 } Expires March 25, 2011 [Page 65] Internet-Draft Sept 2010 pmACPwrQualityTotalPowerFactor 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 vs. 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 } Expires March 25, 2011 [Page 66] Internet-Draft Sept 2010 pmACPwrQualityPhaseEntry OBJECT-TYPE SYNTAX PmACPwrQualityPhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes common 3-phase power quality measurements. This optional table describes 3-phase power quality measurements, with three entries for each supported pmIndex 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 { pmIndex, 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'" Expires March 25, 2011 [Page 67] Internet-Draft Sept 2010 ::= { pmACPwrQualityPhaseEntry 2 } pmACPwrQualityPhaseActivePower 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 '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 vs. 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 } Expires March 25, 2011 [Page 68] Internet-Draft Sept 2010 pmACPwrQualityPhaseImpedance OBJECT-TYPE SYNTAX Integer32 UNITS "volt-amperes" 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 { pmIndex, pmPhaseIndex} ::= { pmACPwrQualityDelPhaseTable 1} PmACPwrQualityDelPhaseEntry ::= SEQUENCE { pmACPwrQualityDelPhaseToNextPhaseVoltage Integer32, pmACPwrQualityDelThdPhaseToNextPhaseVoltage Integer32, Expires March 25, 2011 [Page 69] Internet-Draft Sept 2010 pmACPwrQualityDelThdCurrent Integer32 } pmACPwrQualityDelPhaseToNextPhaseVoltage OBJECT-TYPE 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 Expires March 25, 2011 [Page 70] Internet-Draft Sept 2010 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes measurements of WYE configuration with phase to neutral power quality attributes. Three entries are required for each supported pmIndex 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 { pmIndex, 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" Expires March 25, 2011 [Page 71] Internet-Draft Sept 2010 MAX-ACCESS read-only STATUS current DESCRIPTION "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 pmIndex is NOT -- included since it is not-accessible pmACPwrQualityConfiguration, Expires March 25, 2011 [Page 72] Internet-Draft Sept 2010 pmACPwrQualityAvgVoltage, pmACPwrQualityAvgCurrent, pmACPwrQualityFrequency, 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 pmIndex is NOT -- included since it is not-accessible pmACPwrQualityPhaseActivePower, pmACPwrQualityPhaseReactivePower, pmACPwrQualityPhaseApparentPower, pmACPwrQualityPhasePowerFactor, pmACPwrQualityPhaseImpedance } STATUS current DESCRIPTION "This group contains the collection of all 3-phase power quality objects related to the Power Level." ::= { powerQualityMIBGroups 2 } powerACPwrQualityDelPhaseMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object pmIndex and -- pmPhaseIndex are NOT included -- since they are not-accessible pmACPwrQualityDelPhaseToZeroVoltage, 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." Expires March 25, 2011 [Page 73] Internet-Draft Sept 2010 ::= { powerQualityMIBGroups 3 } powerACPwrQualityWyePhaseMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object pmIndex 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 10. 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 pmDomainName, pmName, and/or pmRoleDescription, MAY disrupt the power and energy collection, and therefore any predefined policies defined in the network. . Unauthorized changes to the pmPowerLevel MAY disrupt the power settings of the different Power Monitor, and therefore the level of functionality of the respective Power Monitors. Expires March 25, 2011 [Page 74] Internet-Draft Sept 2010 . Unauthorized changes to the pmDemandControlTable MAY disrupt the energy measurement in the pmDemandEnergyTable table. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. 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 indeed GET or SET (change/create/delete) them. 11. IANA Considerations The MIB module 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 } Additions to this MIB module 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 OID SHOULD be assigned to a new MIB objects. The specification of new MIB objects SHOULD follow the structure specified in Section 6 and MUST be published using a well- established and persistent publication medium. Expires March 25, 2011 [Page 75] Internet-Draft Sept 2010 12. Acknowledgment The authors would like to thank Shamita Pisal for her prototype of this MIB module, and her valuable feedback. 13. References 13.1. 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-MIB] IEEE 802.1AB-2005, "Management Information Base module for LLDP configuration, statistics, local system data and remote systems data components", May 2005. [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information Base extension module for TIA-TR41.4 media endpoint discovery information", July 2005. 13.2. Informative References [RFC1628] S. Bradner, "UPS Management Information Base", RFC 1628, May 1994 Expires March 25, 2011 [Page 76] Internet-Draft Sept 2010 [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. [POWER-MON-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. Chandramouli, "Requirements for Power Monitoring", draft-quittek-power-monitoring- requirements-01 (work in progress), October 2009. [QUITTEK-POWER-MIB] Quittek, J., Winter, R., Dietz, T., and Dudkowski, D., "Requirements for Power Monitoring", draft-quittek-power-mib-01.txt(work in progress), April 2010. [POWER-MON-ARCH] Claise, B., Parello, J., and B. Schoening, "Power Management Architecture", draft-claise-power- management-arch-01 (work in progress), August 2010. [ACPI] "Advanced Configuration and Power Interface Specification", http://www.acpi.info/spec30b.htm [DASH] "Desktop and mobile Architecture for System Hardware", http://www.dmtf.org/standards/mgmt/dash/ 14. Authors' Addresses Benoit Claise Cisco Systems Inc. Expires March 25, 2011 [Page 77] Internet-Draft Sept 2010 De Kleetlaan 6a b1 Diegem 1813 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Bangalore, IN Phone: +91 80 4426 3947 Email: moulchan@cisco.com John Parello Cisco Systems Inc. 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: jparello@cisco.com Brad Schoening Cisco Systems Inc. 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: braschoe@cisco.com Expires March 25, 2011 [Page 78]