Network Working Group B. Claise Internet-Draft M. Chandramouli Intended Status: Standards Track J. Parello Expires: September 8, 2010 B. Schoening Cisco Systems, Inc. March 8, 2010 Energy Monitoring MIB draft-claise-energy-monitoring-mib-02 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. Expires March 8 2010 [Page 1] Internet-Draft Sep 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 BSD License. Abstract This document defines the Management Information Base (MIB) for the power monitoring of network elements. 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]. Expires March 8, 2011 [Page 2] Internet-Draft Sep 2010 Table of Contents 1. Introduction.............................................. 4 2. The Internet-Standard Management Framework................ 4 3. Terminology............................................... 5 4. Concepts.................................................. 6 4.1. Parent/Child Concept..................................10 5. Examples................................................. 11 6. Link with the other IETF MIBs............................ 20 6.1. Link with the ENTITY-MIB and the ENTITY-SENSOR-MIB....20 6.2. Link with the ENTITY-STATE-MIB........................21 6.3. Link with the POWER-OVER-ETHERNET MIB.................21 7. Structure of the MIB..................................... 22 8. MIB Definitions.......................................... 22 9. Security Considerations.................................. 42 10. IANA Considerations..................................... 43 11. References.............................................. 44 11.1. Normative References.................................44 11.2. Informative References...............................44 12. Authors' Addresses...................................... 45 Expires March 8, 2011 [Page 3] Internet-Draft Sep 2010 1. Introduction This document defines a subset of the Management Information Base (MIB) for use with network management protocols for monitoring the power state and the power consumption of network elements, taking into account the requirements specified in [POWER-MON-REQ]. In addition to power monitoring, functionality to configure the power state of network elements is proposed. The MIB module in this document has been designed to be highly flexible, with twelve different power levels, in accordance to the Advanced Configuration and Power Interface SPECIFICATION (ACPI) specifications [ACPI]. The target devices include: routers, switches, attached devices such as Power over Ethernet (PoE) devices (but not limited to PoE devices), proxy for building energy management, intelligent meters, home energy gateway, hosts and servers, sensor proxy, etc. However, the monitoring and configuration should be available for individual components of devices as well, such as line cards, processor cards, hard drives, etc. when those components are independent from a power state point of view. Those targets devices and components may be characterized by the power related attributes of a physical entity present in ENTITY- MIB, even though the ENTITY-MIB compliance is not a requirement. 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]. Expires March 8, 2011 [Page 4] Internet-Draft Sep 2010 3. Terminology PowerMonitor Entity A PowerMonitor Entity is a system of one or more components, that provides power, draws power, or reports power consumption on behalf of another PowerMonitor Entity. It can be independently managed from a power monitoring and power state configuration point of view. This PowerMonitor Entity may be represented by a physical component referenced using the EntPhysicalTable from the Entity MIB [RFC4133], or by a port and group in the Power over Ethernet MIB [RFC3621] Examples of PowerMonitor Entities are: a router line card, a motherboard with a CPU, an IP Phone connected with a switch, etc. PowerState Level A uniform way to classify power settings on a PowerMonitor Entity (e.g., shut, hibernate, sleep, standby). Levels are software setting for interacting with the underlying hardware supported power settings. PowerMonitor Unit Scale A scaling factor used to represent the magnitude of PowerMonitor Entity usage. It conforms to the standard prefixes for the SI (System International) units of measure. Measured values are represented in SI units obtained by BaseValue * 10 raised to the power of Scale. For example, if current usage of a PowerMonitor Entity is 3, it could be 3 W, 3 mW, 3 KW, 3 MW depending on the value of PowerMonitor Scale. PowerMonitor Domain A PowerMonitor Domain is a name or name space which logically groups together PowerMonitor Entities that comprises a unit of manageable power consumption. For example, all phones in a floor, all PowerMonitor Entities from a specific building, or all PowerMonitor Entities of a specific device type for which a common profile is deployed. From the point of monitoring power consumption, it is useful to report the total power consumed as the sum of power consumed by all the PowerMonitor Entities within a PowerMonitor Domain. Expires March 8, 2011 [Page 5] Internet-Draft Sep 2010 PowerMonitor Parent A PowerMonitor Parent is a PowerMonitor Entity that is the root of one or multiple subtending PowerMonitor Entities, called a PowerMonitor Children. The PowerMonitor Parent is able to report the power consumption for his PowerMonitor Child(ren). For example, in case of Power-over-Ethernet (PoE) device such as an IP phone or an access point attached to a switch port, the switch is the source of power for the attached device. In such a case, the PowerMonitor Parent is the port of the switch, while the attached device is the PowerMonitor Child. PowerMonitor Child A PowerMonitor Child is a PowerMonitor Entity associated to a PowerMonitor Parent, which draws power from its PowerMonitor Parent or reports its power usage and power state to its PowerMonitor Parent. 4. Concepts PowerState Levels represent one of twelve power management states of an PowerMonitor Entity. Each PowerState Level corresponds to a global, system, and performance state in the ACPI model. Level ACPI Global/System Name State Non-operational states: 1 G3, S5 Mech Off 2 G2, S5 Soft Off 3 G1, S4 Hibernate 4 G2, S3 Sleep, Save-to-RAM 5 G2, S2 Standby 6 G2, S1 Ready Operational states: 7 G0, S0, P5 Low 8 G0, S0, P4 Frugal 9 G0, S0, P3 Medium Expires March 8, 2011 [Page 6] Internet-Draft Sep 2010 10 G0, S0, P2 Reduced 11 G0, S0, P1 High 12 G0, S0, P0 Full For example, a PowerMonitor Entity with a power state of 9 would indicate an operational state with medium power consumption. The pmPowerUsageCategory MIB object, specified as a read-only object, indicates the power usage type of the PowerMonitor Entity: power consumer, power producer, or meter. The value of pmPowerUsage, specified as Integer32, can be positive or negative, and must corresponding with the usage type in pmPowerUsageCategory. A PowerMonitor Entity should have a pmName, a unique PowerMonitor index pmIndex, and potentially an entityPhysicalIndex from the ENTITY-MIB [RFC4133] in the pmPhysicalEntity, if supported by the PowerMonitor Entity. In case of Power over Ethernet, the PowerMonitor Entity pmethPortIndex and pmethPortGrpIndex may contain the pethPsePortIndex and pethPsePortGroupIndex. The pmName can be configured or defined by DNS. Possible pmName are: textual DNS name, MAC-address of the device, interface ifName, or a text string uniquely identifying the PowerMonitor Entity. The pmName should ideally be unique. As an example, in the case of IP phones, pmName can be the devices DNS name. In the case of router/switch line cards, the pmName could be the entPhysicalName. Each PowerMonitor Entity can be a member of a PowerMonitor Domain. The PowerMonitor Domain could map 1-1 with a metered or sub-metered portion of the customers site. It can be used to further sub divide the deployment down to finer PowerMonitor Domains such as a lab, data center, rack, etc. With the possible evolution of this draft, to a framework document, the notion of PowerMonitor Domain shall be useful. For a PowerMonitor Entity, instantaneous power usage is reported using pmPowerUsage and the magnitude of measurement is specified in pmPowerUnits which is based on MonitorScale. Nameplate power consumption of a PowerMonitor Entity is specified by the vendor as the maximum capacity required to safely power the device. Often this label is a conservative Expires March 8, 2011 [Page 7] Internet-Draft Sep 2010 number and is the worst case power draw of all elements in a fully configured system. While the actual utilization of an entity can be lower, Nameplate power consumption is important for power provisioning, capacity planning and billing. In addition to measuring power consumption, an approach to characterize the energy demand is also presented in the MIB. It is well-known in commercial electrical utility rates, that demand charges can be on par with actual power charges. So, in addition to measuring power consumption, it is useful to characterize the demand. The demand can be described as average energy usage of an PowerMonitor Entity over a time window, called a demand interval, typically 15 minutes. The highest peak energy demand measured over a time horizon, say 1 month or 1 year is often the basis for usage charge. A single window of time of high usage can penalize the power consumption charges. However, it is relevant to measure the demand only when there are actual power measurements from a PowerMonitor Entity, and not when the power measurement is assumed or predicted as specified in the MIB OID PowerUsageCaliber. Two tables are introduced to characterize the energy demand - emDemandTable and emDemandControlTable. The emDemandControl Table consists of parameters defining: the duration of the demand intervals in seconds, emDemandControlIntervalLength; the number of demand intervals kept in the emDemandTable, emDemandControlIntervalNumber; and a same rate used to calculate the average, emDemandControlSampleRate. Judicious choice of the SamplingRate will ensure accurate measurement of power while not imposing an excessive polling burden. The emDemandControlStatus is useful to specify the energy measurement is actual and thus to indicate if the emDemandTable entries exist or not. The emDemand Table consists of energy measurements in DemandIntervalEnergyUsed, the scale of energy measured, DemandIntervalEnergyScale, and the maximum observed demand in a window - emDemandIntervalMax Several efficiency metrics can be derived and tracked with the usage data present in this MIB module. For example, - Per-packet power costs for a networking device (router or switch) can be calculated by an network management system. The packets count can be determined from the traffic usage in the ifTable [RFC2863] from the forwarding plane figure, or from the platform specifications - Watt-hour power use from this MIB can be combined with utility energy sources to estimate carbon footprint and other emission statistics. Expires March 8, 2011 [Page 8] Internet-Draft Sep 2010 An example is provided to illustrate the concepts. For example, a given PowerMonitor Entity as described by the pmIndex "7" pmPhysicalEntity "5" and pmName "switch2.foo.com". For that PowerMonitor Entity, the power measurement and power state is reported as follows: the units of measurement pmPowerUnits is "watts" (value 0), the instantaneous power usage enPowerUsage is 100 watts, while the maximum power consumption as prescribed by the vendor pmPowerNamePlate is 300 watts. The pmPowerUsageCaliber indicates that the power measurement is "actual". The power state of that PowerMonitor Entity PmPowerLevel is "9" to indicate medium power usage and pmPowerUsageCategory indicates the device is a consumer of power. In addition, the maximum power consumption at the current level is indicated as 150 watts in pmLevelMaxUsage. The emDemandTable and emDemandControlTable will be illustrated following the same example. First, in order to estimate demand, an interval to sample energy usage should be specified, i.e. emDemandControlIntervalLength can be "900 seconds" and the number of consecutive intervals over which the maximum demand is calculated emDemandControlIntervalNumber as "10". The sampling rate internal to the PowerMonitor Entity for measurement of power usage, emDemandControlSampleRate, can be "1000 milliseconds", as set by the PowerMonitor Entity as a reasonable value. Then, the emDemandControlStatus is set to active (value 1) to indicate that the PowerMonitor Entity should start monitor the usage as per the emDemandTable. The indices in the emDemandTable are pmIndex, which identifies the PowerMonitor Entity, and emDemandIntervalStartTime, which denotes the start time of the demand measurement interval based on sysUpTime. The value of emDemandIntervalEnergyUsed is the measured of the energyconsumption over the time interval specified (emDemandControlIntervalLength) based on the PowerMonitor Entity internal sampling rate (emDemandControlSampleRate). The units are derived from emDemandIntervalPowerScale. For example, emDemandIntervalPowerUsed can be "100" with emDemandIntervalPowerUnits equal to 0, the demand is 100 watt-hours. emDemandIntervalMax is the maximum demand observed can be "150 watt-hours". The emDemandTable has a buffer to retain a certain number of intervals, as defined by emDemandControlIntervalNumber. If the default value of "10" is kept, then the emDemandTable contains 10 demand measurements, including the maximum. A brief Expires March 8, 2011 [Page 9] Internet-Draft Sep 2010 explanation on how the maximum demand is calculated. 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 Network Management System could compute the maximum over a longer period, i.e. a month, 3 months, or a year. [POWER-MON-REQ] specifies some requirements about power states such as "the current state - the time of the last change", "the total time spent in each state", "the number of transitions to each state", etc... Such requirements are fulfilled thanks to the pmLevelChange NOTIFICATION-TYPE, indexed by the pmIndex and the pmPowerLevel, which is generated when the value of pmPowerLevel has changed for the PowerMonitor Entity represented by the pmIndex. Indeed, assuming that the SNMP notification arrives at the Network Management Station (NMS), the NMS can deduce all the information. 4.1. Parent/Child Concept A PowerMonitor Entity can be connected to another PowerMonitor Entity and either draw power from that entity or report power usage to the Entity. EnergyMonitor Child can be fully dependent on the EnergyMonitor Parent or independent. In the dependent case, EnergyMonitor Parent provides power for the EnergyMonitor Child and the power consumption of the child can be measured at the EnergyMonitor parent. Also, the PowerMonitor Levels can be set by the EnergyMonitor Parent. In the independent case, an EnergyMonitor Child draws power from another source (typically a wall outlet). However, the EnergyMonitor Child does not have a separate network management presence and instead reports the power usage and PowerMonitoring Level on to the EnergyMonitor Parent. The EnergyMonitor Child may listen to the power control settings from a EnergyMonitor Parent and the EnergyMonitor Child could react to the control messages. Note that the communication between the EnergyMonitor Parent and EnergyMonitor Child is out of scope of this document. In order to link the PowerMonitor Child and the PowerMonitor Parent, the notion of pmParentId is introduced. Expires March 8, 2011 [Page 10] Internet-Draft Sep 2010 Consider the example of a PoE device attached to a switch where the switch can measure the power at the switch port level. For example, a PoE device with an pmIndex of 100 and a pmParentId value of 20 representing the parent pmIndex. This PowerMonitor parent will report the power usage for the attached PoE device while the PoE port reports zero for power usage. Furthermore, if the pmPhysicalEntity value is non zero, the switch port to which the PoE device is connected to can be deduced. The use of a PowerMonitor parent is not limited to just PoE children. However, in the case of non-POE devices, the power usage cannot be measured at the switch port; since the switch is not source of power supply. In that case, proprietary communication of power usage between the child (PC) and the parent (switch) could be established, the form of which is outside of scope of this document. Consider a PC attached to a switch port, powered from a wall outlet. In this example, the PC would appear as a PowerMonitor child Entity and report his usage in the parents emEntry table. Similarly to the previous PoE example, the PC PowerMonitor parent and switch port can be deduced through cross-references. It is not possible to have multiple PoE devices on a single PoE port. However, it is possible to have a single PoE device on a switch port and another non-PoE device such a PC can be daisy- chained from the phone for the LAN connection. In this scenario, the switch port parent has two children; the IP phone and PC. As stated before, for the PoE device, it is possible to measure the power consumption at the switch port, whereas for the non-POE device (PC), there must be out-of-band communication of power usage and power levels between the non-PoE device and the switch. The communication between the parent and a child is out of scope of this document and is not discussed here. 5. Examples A PowerMonitor Entity is a fundamental concept from the point of view of power monitoring application considered in this document. Some illustrative examples are presented to model different network scenarios of the PowerMonitor Parent and PowerMonitor Child relationship. Example 1: Consider an PoE IP Phone connected to the switch port, as displayed on figure 1. The IP phone draws power from the Power over Ethernet switch port. The switch has the following attributes that are illustrated in Figure 1. Expires March 8, 2011 [Page 11] Internet-Draft Sep 2010 The switch has pmIndex "1", pmPhysicalEntity is "2" and pmPowerMonitorID is "UUID 1000". The power consumption of the switch is "440 Watts". The switch does not have a 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 consumption of the POE switch port is "12 watts". The POE switch port has the switch as the 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 parent; the POE switch port whose pmPowerMonitorID is "UUID 1003". The power consumption 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 8, 2011 [Page 12] Internet-Draft Sep 2010 | 31 | 0 | UUID 2003 | UUID 1003 | 0 | ============================================================== Figure 1: Example 1 Example 2: 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 Example 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 5004". The PC has a parent 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 PowerMonitor 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 PowerMonitor Parent sends power control messages to both the PowerMonitor 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 8, 2011 [Page 13] Internet-Draft Sep 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 5004 | UUID 1003 | 120 | ============================================================ Figure 2: Example 2 Example 3: 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 PowerMonitor Parent for the Wireless Access Point and the PCs. There is a distinction, between the children, as the Wireless Access Point 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 1". The power consumption of the switch is "440 Watts". The switch does not have a parent. The POE switch port has the following attributes - The switch port has pmIndex "7", pmPhysicalEntity is "18" and pmPowerMonitorID is "UUID 2". The power consumption of the POE switch port is "20 watts". The POE switch port has the switch as the parent and the pmParentID is "UUID 1000". Expires March 8, 2011 [Page 14] Internet-Draft Sep 2010 The Wireless Access Point has the following attributes. The WAP doesn't have an entry for pmPhysicalEntity. The WAP has pmIndex "47" and pmPowerMonitorID "UUID 3" and WAP has a parent; the POE switch port whose pmPowerMonitorID is "UUID 2". The power consumption 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 2". 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 2". 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 1 | null | 440 | | ============================================================ | | | | SWITCH PORT | | ============================================================ | | | Switch | Switch | Switch | Switch | Switch | | | Port | Port | Port | Port | Port | | | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | | ============================================================ | | 7 | 18 | UUID 2 | UUID 1 | 20 | | | ============================================================ | | ^ | | | | |----------------------------------------------|---------------| | POE Wireless Access Point | | | ============================================================== | WAP | WAP | WAP | WAP | WAP | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentID | pmUsage | ============================================================== | 47 | 0 | UUID 3 | UUID 2 | 0 | ============================================================== . Expires March 8, 2011 [Page 15] Internet-Draft Sep 2010 . . . PC1 connected to WAP . . ============================================================== | PC | PC |PC |PC | PC | | pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage | ============================================================== | 53 | 0 | UUID 4 | UUID 2 | 120 | ============================================================== . . PC2 connected to WAP . . ================================================================ | PC | PC |PC | PC | PC | | pmIndex| pmPhyIdx |pmPowerMonitorId | pmParentID | pmUsage | =============================================================== | 58 | 0 | UUID 5 | UUID 2 | 120 | ================================================================ Figure 3: Example 3 Example 4: An example of the proposed MIB on how to model monitoring the energy consumption of buildings is presented. At the top of the network hierarchy of building network is mediator device that does protocol conversion between many facility management protocols such as BACNET, MODBUS, DALI, LON, etc. There are power meters associated with power consuming entities (HVAC, lighting, electrical, fire control, elevators, ...). The proposed MIB can be implemented on the mediator device. The mediator can be considered as the PowerMonitor Parent, while the power meters associated with the energy consuming entities such (HVAC, electrical, lighting, ...) can be considered as PowerMonitor Childen. EntPhysicalIndex is not defined for these EnergyMonitor Parent or the Children, as the ENTITY-MIB is generally not implemented in such an environment. Hence the mediator, Meter 1, and Meter 2 have pmPhysicalEntities of value zero. The pmIndex of the Mediator is "5", and the pmPowerMonitorID is "UUID 1008". The mediator does not have a parent; The total power usage of the Mediator and its children is "9000 Watts". Expires March 8, 2011 [Page 16] Internet-Draft Sep 2010 Meter 1 has pmIndex "2051", and pmPowerMonitorID is "UUID 2004". Meter 1 shall report a power consumption of "6000 watts". Meter 1 has the Mediator as the parent and its pmParentID is "UUID 1008". Meter 2 has pmIndex "2072", and pmPowerMonitorID is "UUID 2007". Meter 2 shall report a power consumption of "1500 watts". Meter 2 has the Mediator as the parent and its pmParentID is "UUID 1008". --------------------------------------------------------------- | Building Mediator | | | |==============================================================| | Mediat | Mediat | Mediat | Mediat | Mediat | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | ============================================================ | | 5 | None | UUID 1008 | Null | 9000 | | ============================================================ | | | | | ---------------------------------------------------------------- | | | | Meter 1 | | ============================================================= | | Meter1 | Meter1 |Meter1 |Meter1 | Meter1 | | | pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage | |=>|============================================================ | | 2051 | 0 | UUID 2004 | UUID 1008 | 6000 | | ============================================================= | | Meter 2 | ============================================================ |=>| Meter2 | Meter2 |Meter2 |Meter2 | Meter2 | | pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage | ============================================================= | 2072 | 0 | UUID 2007 | UUID 1008 | 1500 | ============================================================= Figure 4: Example 4 Example 5: An example of the proposed MIB on how to model a data center network is presented. In summary, a typical data Expires March 8, 2011 [Page 17] Internet-Draft Sep 2010 center network consists of a hierarchy of switches. At the bottom of hierarchy there are servers mounted on rack, and those are connected to the top of the row switches. Top of the row switches are connected to aggregation switches, who are in turn connected to core switches. As an example, Server 1 and Server 2 are connected to different switch ports of the top of the row switch. The proposed MIB can be implemented on the switches. The switch can be considered as the PowerMonitor Parent. The servers can be considered as the children. The switch has pmIndex "1", pmPhysicalEntity is "2" and the pmPowerMonitorID is "1000". The power consumption 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 "8", pmPhysicalEntity is "15" and pmPowerMonitorID is "1041". The power consumption of the non-POE switch port cannot be measured. The switch port has the switch as the parent and its pmParentID is "1000". The Server 1 has a value of zero for pmPhysicalEntity. The pmIndex of the Server 1 is "53", and the pmPowerMonitorID is "5016". Server 1 has a parent; i.e., the switch port whose pmPowerMonitorID is "1041". The power usage of the Server 1 is "200 Watts" and is communicated to the switch port. Server 2 is connected to Switch port 2. Switch port 2 has pmIndex "6", pmPhysicalEntity is "16" and pmPowerMonitorID is "1054". The power consumption of the non-POE switch port cannot be measured. The switch port has the switch as the parent and its pmParentID is "1000". The Server 2 has a value of zero for pmPhysicalEntity. The pmIndex of the Server 2 is "72", and the pmPowerMonitorID is "5043". 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. |--------------------------------------------------------------| | Switch | |==============================================================| | |Switch | Switch | Switch | Switch | Switch | | | |pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | Expires March 8, 2011 [Page 18] Internet-Draft Sep 2010 | ============================================================ | | | 1 | 2 | UUID 1000 | null | 440 | | | ============================================================ | | | | | | SWITCH PORT 1 | | ============================================================ | | | Switch | Switch | Switch | Switch | Switch | | | Port1 | Port1 | Port1 | Port1 | Port1 | | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | ============================================================ | | | 8 | 15 | UUID 1041 | UUID 1000 | NULL || | ============================================================ | | | | SWITCH PORT 2 | | ============================================================ | | | Switch | Switch | Switch | Switch | Switch | | | Port2 | Port2 | Port2 | Port2 | Port2 | | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | ============================================================ | | | 6 | 16 | UUID 1054 | 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 | |=>|============================================================ | | 64 | 0 | UUID 5016 | UUID 1041 | 200 | | ============================================================= | | Server 2 connected to switch (Non-POE) | ============================================================ |=>| Server 2| Server 2 | Server 2 | Server 2 | Server 2 | | pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID| pmUsage | ============================================================= | 72 | 0 | UUID 5043 | UUID 1054 | 140 | ============================================================= Figure 5: Example 5 Expires March 8, 2011 [Page 19] Internet-Draft Sep 2010 6. Link with the other IETF MIBs 6.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) and those physical entities listed indexed by entPhysicalIndex. From an energy management point of view, of interest are the physical entities that consume or produce energy. 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 Monitoring MIB, is on measurement of power consumption by 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 consumption of devices such as routers and switches, the ENTITY-MIB and ENTITY- SENSOR-MIB should be implemented. In such cases, the PowerMonitor Entities are modeled by the entPhysicalIndex through the pmPhysicalEntity MIB object specified in the pmTable. However, the ENTITY-SENSOR-MIB doesn't have the ANSI C12.x accuracy classes required for electricity, i.e., 1%, 2%, 0.5% accuracy classes. These ANSI and IEC Standards require that we use an accuracy class, and not the precision model in RFC3433. The pmPowerUsageAccuracy MIB object models this accuracy. Note that the emEntPowerScale represents the scale is a more logical representation (compared to entPhySensorScale), with the mantissa and the exponent values X * 10 ^ Y. Finally, one cannot assume that the ENTITY-MIB and ENTITY- SENSOR-MIB are implemented for all PowerMonitor Entity 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 8, 2011 [Page 20] Internet-Draft Sep 2010 As a consequence, the pmIndex MIB object has been kept as the unique PowerMonitor Entity index. Finally, not that the emEntPowerUsage is similar to entPhySensorValue [RFC3433] and the emEntPowerScale is similar to entPhySensorScale 6.2. Link with the ENTITY-STATE-MIB RFC 4268 [RFC4268] defines the Entity State MIB module that gives the operational states (enabled, disabled, testing) and alarm states and usage states (idle, active, busy) of the entities in the entity MIB. From a Power monitoring point of view, different power states to indicate the power state of the entities models need to be developed. The Power Monitoring MIB proposes the power states of entities in the Entity MIB. 6.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. One cannot assume that the Power-over-Ethernet MIB is implemented for all PowerMonitor Entity 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 pmethPortIndex and pmethPortGrpIndex values contain the zero value, thanks to new PethPsePortIndexOrZero and textual PethPsePortGroupIndexOrZero conventions. However, if the Power-over-Ethernet is supported, the PowerMonitor Entity pmethPortIndex and pmethPortGrpIndex contain the pethPsePortIndex and pethPsePortGroupIndex, respectively. As a consequence, the pmIndex MIB object has been kept as the unique PowerMonitor Entity index. Expires March 8, 2011 [Page 21] Internet-Draft Sep 2010 7. Structure of the MIB The primary MIB object in this MIB module is PowerMonitorMIBObjects. The pmTable table defines the PowerMonitor Entities, with references to the entPhysicalIndex, pmethPortIndex and pmethPortGrpIndex when available. The PowerMonitor Entities are used for describing and configuring the entities that are possible candidates for power management. The specific PowerState Level can be configured in the pmTable. The pmLevelTable table lists the maximum power usage at each PowerState Level for each PowerMonitor Entity. Finally, the monitoring of all the PowerMonitor Entities on the SNMP agent can be turned on/off with the pmEnable MIB object. 8. MIB Definitions -- ************************************************************ -- -- -- This MIB is used to monitor Power Consumption of network -- devices -- -- ************************************************************* POWER-MONITOR-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Integer32, TimeTicks FROM SNMPv2-SMI MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB Expires March 8, 2011 [Page 22] Internet-Draft Sep 2010 RowStatus, TimeInterval FROM SNMPv2-TC PhysicalIndexOrZero FROM ENTITY-MIB; pethPsePortIndex, pethPsePortGroupIndex FROM POWER-ETHERNET-MIB; powerMonitorMIB MODULE-IDENTITY LAST-UPDATED "201001130000Z" 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 usage in network Devices." REVISION "201001130000Z" DESCRIPTION "This Latest draft of this MIB module." ::= { 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 Expires March 8, 2011 [Page 23] Internet-Draft Sep 2010 DESCRIPTION "An enumerated integer value that represents the value of PowerState Level, a power setting at which a PowerMonitor Entity uses power. The PowerState Levels are divided into six operational states, and six non-operational states. Each non- operational state corresponds to an ACPI (Advanced Configuration and Power Interface Specification, http://www.acpi.info/spec30b.htm) Global and System level state between G3 (hard-off) and G1 (sleeping). The operational levels represent a performance state, and correspond to ACPI states P0 (maximum performance & power) through P5 (minimum performance and minimum power). PowerMonitor Entities need not support all levels, but a subset of the levels that can be mapped to their system state. mechoff(1) : An off state. No entity features are available. The entity is unavailable. No power is being consumed and the power connector can be removed. This maps to the level G3 in ACPI. softoff(2) : Similar to off, but some components remain powered so the device can be woken from its off state. In soft-off, no context is saved and the device requires a complete boot when awakened. This maps to level G2 in ACPI. hibernate(3): No entity features are available. The entity may be awoken without requiring a complete boot, but the time for availability is longer than sleep. This is generally the same as save-to- disk where DRAM context is not maintained. Minimal, nearly zero, or zero power is consumed. This maps to level G1, S4 in ACPI. sleep(4) : No entity features are available. The entity may be available but the time for availability is longer than standby. This is generally the same as save-to-RAM, where DRAM context is Expires March 8, 2011 [Page 24] Internet-Draft Sep 2010 maintained. Minimal power is consumed. This maps to level G1, S3 in ACPI. standby(5) : Indicates some entity features may not be available. The entity may be available but the time for availability is longer than ready. Processor context is not maintained. Minimal power is consumed. This maps to level G1, S2 in ACPI. ready(6) : Indicates some entity features may not be available. The entity itself may be available but there may be a time delay for availability. Processors are not executing, but their context is maintained. Low or less power is consumed. This maps to level G1, S1 in ACPI. low(7) : Indicates some features may not be available and the entity has taken measures/options to provide less than frugal usage. This maps to ACPI State G0; which includes operational levels low to full. frugal(8) : Indicates some features may not be available and the entity has take measures/options to provide less than medium usage. medium(9) : Indicates all entity features are available but the entity has taken measures/options to provide less than reduced usage. reduced(10) : Indicates all entity features are available but the entity has taken measures/options to provide less than high usage. high(11) : Indicates all entity features are available and power consumption is less than full. full(12) : Indicates all entity features are available and the entity is consuming the highest power." Expires March 8, 2011 [Page 25] Internet-Draft Sep 2010 SYNTAX INTEGER { mechoff(1), softoff(2), hibernate(3), sleep(4), standby(5), ready(6), low(7), frugal(8), medium(9), reduced(10), high(11), full(12) } PowerMonitorId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A unique identifier for the PowerMonitor Entity in the PowerMonitor Domain. Implementation must ensure that the ID for each PowerMonitor Entity is unique among all entities within the PowerMonitor Domain. A Universally Unique Identifier (UUID) is typically used." REFERENCE "IETF RFC 4122" SYNTAX OCTET STRING (SIZE (16)) MonitorScale ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Monitor Scale: an integer value that represents the scale factor associated with the units used to measure the power or energy. For example, when used with pmPowerUnits, 3 represents 10^-3 or milliwatts" REFERENCE "The International System of Units (SI), National Institute of Standards and Technology, Spec. Publ. 330, August 1991." SYNTAX INTEGER { yocto(-24), -- 10^-24 zepto(-21), -- 10^-21 atto(-18), -- 10^-18 femto(-15), -- 10^-15 pico(-12), -- 10^-12 Expires March 8, 2011 [Page 26] Internet-Draft Sep 2010 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 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 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 this extension are situations where none or all physical entities need to be referenced." SYNTAX Integer32 (0..2147483647) Expires March 8, 2011 [Page 27] Internet-Draft Sep 2010 -- Objects pmTable OBJECT-TYPE SYNTAX SEQUENCE OF PmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists PowerMonitor Entities." ::= { powerMonitorMIBObjects 1 } pmEntry OBJECT-TYPE SYNTAX PmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes attributes of a PowerMonitor Entity. Whenever the device creates/destroys a PowerMonitor Entity, the device creates/destroys a row in the pmTable." INDEX { pmIndex } ::= { pmTable 1 } PmEntry ::= SEQUENCE { pmIndex Integer32, pmPowerMonitorId PowerMonitorId, pmPhysicalEntity PhysicalIndexOrZero, pmethPortIndex PethPsePortIndexOrZero, pmethPortGrpIndex PethPsePortGroupIndexOrZero, pmDomainName SnmpAdminString, pmName SnmpAdminString, pmRoleDescription SnmpAdminString, pmPowerUnits MonitorScale, pmPowerUsage Integer32, pmPowerUsageNameplate Integer32, pmPowerUsageAccuracy Integer32, pmPowerUsageCaliber INTEGER, pmPowerLevel PowerMonitorLevel, pmPowerUsageCategory BITS, pmParentId PowerMonitorId } pmIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) Expires March 8, 2011 [Page 28] Internet-Draft Sep 2010 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each PowerMonitor Entity. It is recommended that values are assigned contiguously 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 PowerMonitor UUID identifier. This object value must be unique within the PowerMonitor Domain." ::= { 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 ACCESS read-only STATUS mandatoty 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 ACCESS read-only STATUS mandatory DESCRIPTION Expires March 8, 2011 [Page 29] Internet-Draft Sep 2010 "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." ::= { pmEntry 5 } pmDomainName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the name of a PowerMonitor Domain for the PowerMonitor Entity. This object specifies a null string if no PowerMonitor 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 6 } pmName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies a printable name, a text string, for the PowerMonitor Entity. It is preferred, but not required that pmName be unique. The process to assign the pmName is implementation specific. Example: DNS Name, MAC address in canonical form, ifName, etc..." ::= { pmEntry 7 } pmRoleDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies an administratively assigned name to indicate the purpose a PowerMonitor Entity 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 8 } Expires March 8, 2011 [Page 30] Internet-Draft Sep 2010 pmPowerUnits OBJECT-TYPE SYNTAX MonitorScale MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of Watts for the usage value in pmPowerUsage and pmPowerUsageNameplate." ::= { pmEntry 9 } pmPowerUsage OBJECT-TYPE SYNTAX Integer32 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the instantaneous consumption for the PowerMonitor Entity. This value is specified in SI units of watts with the magnitude of watts (milliwatts, kilowatts, etc.) indicated separately in pmPowerUnits. If the PowerMonitor Entity is a consumer (bit value 1 in pmPowerUsageCategory, the usage value will be positive. If the PowerMonitor Entity is a producer (bit value 2 in pmPowerUsageCategory, the usage value will be negative. This should be less than or equal to the maximum power that can be consumed at the specified level." ::= { pmEntry 10 } pmPowerUsageNameplate OBJECT-TYPE SYNTAX Integer32 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the rated maximum consumption for the fully populated PowerMonitor Entity. The nameplate power requirements are the worst-case power consumption numbers and in almost all cases, are well above the expected operating level. Nameplate power is widely used for power provisioning. This value is specified in SI units of watts with the magnitude of watts (milliwatts, kilowatts, etc.) indicated separately in pmPowerUnits. Nameplate power is widely used for capacity and provisioning planning. It is typically a value provided via experimentation and prediction from the manufacturer of the entity." Expires March 8, 2011 [Page 31] Internet-Draft Sep 2010 ::= { pmEntry 11 } pmPowerUsageAccuracy 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 pmPowerUsage 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" ::= { pmEntry 12 } pmPowerUsageCaliber OBJECT-TYPE SYNTAX INTEGER { unknown(1), actual(2) , trusted(3), predicted(4), presumed(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies how the usage value, reported by pmPowerUsage, is obtained. - unknown: This indicates that the way the usage is determined is unknown. In some cases, entities report aggregate power like what a lighting controller or aggregate controller does. In such cases it is not known whether the usage reported is actual or presumed. - actual: This indicates that the usage data reported is not presumed or predicted but the real power drawn. A PoE phone drawing X amount of power can be determined by reading from the port. - trusted: This indicates that the usage data reported was reported from another source. For example, a PoE Expires March 8, 2011 [Page 32] Internet-Draft Sep 2010 phone can report the actual usage as X W, but this is not typically as accurate as port level metering on the switch. Trusted is higher caliber than predicted. - predicted: This indicates that the actual power drawn cannot be determined. The value is an estimate based upon the device type, state, and/or utilization. Predicted is a higher caliber than presumed. For example, a switch is known to draw 200w when PoE on all interfaces is disabled, and 600w when PoE is fully enabled. - presumed: This indicates that the actual power drawn cannot be determined but can be presumed from a model. Presumed is the lowest caliber. For example, a PC Model X draws 200W, while a PC Model Y draws 210W." ::= { pmEntry 13 } pmParentId OBJECT-TYPE SYNTAX PowerMonitorID ACCESS read-only STATUS mandatory DESCRIPTION "If the current PowerMonitor Entity has a PowerMonitor Parent, then its PowerMonitor Id value is set in pmParentId. Otherwise, the pmParentId value is the null string." ::= { pmEntry 14 } pmPowerLevel OBJECT-TYPE SYNTAX PowerMonitorLevel MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the current power level (1..12) for the PowerMonitor Entity." ::= { pmEntry 15 } pmPowerUsageCategory OBJECT-TYPE SYNTAX BITS { consumer(1), producer(2), meter(3) } MAX-ACCESS read-only STATUS current DESCRIPTION Expires March 8, 2011 [Page 33] Internet-Draft Sep 2010 "This object specifies the power usage type of the entity. An entity could be producing power when pmPowerUsageCategory is producer(2) or a consumer of power consumer (1) or a hybrid - consumer and producer(3). Negative values of power usage are permissible to indicate the entities as power sources. Consumer: This indicates that the entity consumes power. Producer: This indicates that the entity generates power. Meter: This indicates that the entity is a meter which reads the power consumed or produced." ::= { pmEntry 16 } pmLevelTable OBJECT-TYPE SYNTAX SEQUENCE OF PmLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enumerates the maximum power usage in watts at each PowerState Level for each PowerMonitor Entity. This table has an expansion dependent relationship on the pmTable, containing rows describing each PowerState Level for the corresponding PowerMonitor Entity." ::= { powerMonitorMIBObjects 2 } pmLevelEntry OBJECT-TYPE SYNTAX PmLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A pmLevelEntry extends a corresponding pmEntry. This entry displays max usage and delta values at each possible power level. For example, given the values of a PowerMonitor Entity corresponds to a maximum usage of 11W at the level 1 (off), 6 (low), 8 (medium), 12 (full): Level MaxUsage Units 1 0 0 5 0 0 6 8 0 7 8 0 8 11 0 Expires March 8, 2011 [Page 34] Internet-Draft Sep 2010 12 11 0" INDEX { pmIndex, pmLevelIndex } ::= { pmLevelTable 1 } PmLevelEntry ::= SEQUENCE { pmLevelIndex PowerMonitorLevel, pmLevelMaxUsage Integer32, pmLevelPowerUnits MonitorScale } pmLevelIndex OBJECT-TYPE SYNTAX PowerMonitorLevel MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object indicates the level for which this entry describes the power usage." ::= { pmLevelEntry 1 } pmLevelMaxUsage OBJECT-TYPE SYNTAX Integer32 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the maximum power usage for the PowerMonitor Entity at the particular PowerState Level. This value is specified in SI units of watts with the magnitude of the units (milliwatts, kilowatts, etc.) indicated separately in pmLevelPowerUnits." ::= { pmLevelEntry 2 } pmLevelPowerUnits OBJECT-TYPE SYNTAX MonitorScale MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of watts for the usage value in pmLevelMaxUsage." ::= { pmLevelEntry 3 } Expires March 8, 2011 [Page 35] Internet-Draft Sep 2010 emDemandControlTable OBJECT-TYPE SYNTAX SEQUENCE OF EmDemandControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls and configures the demand table emDemandTable." ::= { powerMonitorMIBObjects 3 } emDemandControlEntry OBJECT-TYPE SYNTAX EmDemandControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry controls energy usage measurements." INDEX { pmIndex } ::= { emDemandControlTable 1 } EmDemandControlEntry ::= SEQUENCE { emDemandControlIntervalLength TimeInterval, emDemandControlIntervalNumber Integer32, emDemandControlSampleRate Integer32, emDemandControlStatus RowStatus } emDemandControlIntervalLength OBJECT-TYPE SYNTAX TimeInterval UNITS "Seconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object indicates the length of time in seconds over which the average demand is computed. The computation is based on PowerMonitor Entity internal sampling rate of power consumption of the entity. The sampling rate may differ based on device capabilities. The average power consumption is computed over the length of the demand interval." DEFVAL { 900 } ::= { emDemandControlEntry 1 } emDemandControlIntervalNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current Expires March 8, 2011 [Page 36] Internet-Draft Sep 2010 DESCRIPTION "The number of demand intervals maintained. Whenever the maximum number of entry is reached, the new demand interval replaces the oldest one, except if the oldest one is the emDemandIntervalMax. In which case, the next oldest interval is replaced." DEFVAL { 10 } ::= { emDemandControlEntry 2 } emDemandControlSampleRate OBJECT-TYPE SYNTAX Integer32 UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The sampling rate in milliseconds at which the PowerMonitor Entity should poll the instantaneous power usage in order to compute the average emDemandIntervalEnergyUsed measurement in the table emDemandTable. The PowerMonitor 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 that it would impact the PowerMonitor Entity performance by requesting continuous polling." DEFVAL { 1000 } ::= { emDemandControlEntry 3 } emDemandControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. An entry may not exist in the active state unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated entries in the emDemandTable shall be deleted." ::= {emDemandControlEntry 4 } emDemandTable OBJECT-TYPE SYNTAX SEQUENCE OF EmDemandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires March 8, 2011 [Page 37] Internet-Draft Sep 2010 "This table lists PowerMonitor Entity energy usage measurements. Only when the PowerMonitor Entity has the pmPowerUsageCaliber value set to actual(2) will this table be populated." ::= { powerMonitorMIBObjects 4 } emDemandEntry OBJECT-TYPE SYNTAX EmDemandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes energy usage measurements." INDEX { pmIndex, emDemandIntervalStartTime } ::= { emDemandTable 1 } EmDemandEntry ::= SEQUENCE { emDemandIntervalStartTime TimeTicks, emDemandIntervalEnergyUsed Integer32, emDemandIntervalEnergyUnits MonitorScale, emDemandIntervalMax Integer32 } emDemandIntervalStartTime 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. " ::= { emDemandEntry 1 } emDemandIntervalEnergyUsed 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 PowerMonitor Entity over the defined interval. This value is specified in the common billing units of watts-hours with the magnitude of watt-hours Expires March 8, 2011 [Page 38] Internet-Draft Sep 2010 (kW-Hr, MW-Hr, etc.) indicated separately in emDemandIntervalPowerScale." ::= { emDemandEntry 2 } emDemandIntervalEnergyUnits OBJECT-TYPE SYNTAX MonitorScale MAX-ACCESS read-only STATUS current DESCRIPTION "This magnitude of watt-hours for the energy field in emDemandIntervalEnergyUsed." ::= { emDemandEntry 3 } emDemandIntervalMax OBJECT-TYPE SYNTAX Integer32 UNITS "Watt-hours" MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the maximum demand ever observed in emDemandIntervalEnergyUsed 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 emDemandIntervalEnergyUnits." ::= { emDemandEntry 4 } pmEnable OBJECT-TYPE SYNTAX INTEGER { enable(1), disable(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "A control object to activate or de-activate all PowerMonitor Entities on the SNMP agent (e.g. Switch). enable: enables all PowerMonitor Entities. disable: disables all PowerMonitor Entities" ::= { powerMonitorMIBObjects 5 } pmVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only Expires March 8, 2011 [Page 39] Internet-Draft Sep 2010 STATUS current DESCRIPTION "This object specifies the current version of the PowerMonitor software running on a PowerMonitor Entity." ::= { powerMonitorMIBObjects 6 } -- Notifications pmLevelChange NOTIFICATION-TYPE OBJECTS { pmIndex, pmPowerLevel } STATUS current DESCRIPTION "The SNMP entity generates the PmLevelChange when the value of pmPowerLevel has changed for the PowerMonitor Entity 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, powerMonitorMIBNotifGroup } ::= { 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 Expires March 8, 2011 [Page 40] Internet-Draft Sep 2010 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, powerMonitorMIBNotifGroup } OBJECT pmName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmRoleDescription MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmDomainName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT pmEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { powerMonitorMIBCompliances 2 } -- Units of Conformance powerMonitorMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object pmIndex is NOT -- included since it is not-accessible pmPowerMonitorId, pmPhysicalEntity, pmDomainName, pmName, pmRoleDescription, pmPowerUnits, pmPowerUsage, pmPowerUsageNameplate, pmPowerUsageAccuracy, pmPowerUsageCaliber, Expires March 8, 2011 [Page 41] Internet-Draft Sep 2010 pmPowerLevel, pmPowerUsageCategory, pmEnable, pmVersion } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the PowerMonitor Entity." ::= { powerMonitorMIBGroups 1 } powerMonitorMIBLevelTableGroup OBJECT-GROUP OBJECTS { -- pmLevelIndex, pmLevelMaxUsage, pmLevelPowerUnits } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the PowerState Level." ::= { powerMonitorMIBGroups 2 } powerMonitorMIBNotifGroup NOTIFICATION-GROUP NOTIFICATIONS { pmLevelChange -- pmLevelIndex } STATUS current DESCRIPTION "This group contains the notifications for the power monitoring MIB Module." ::= { powerMonitorMIBGroups 3 } END 9. 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 Expires March 8, 2011 [Page 42] Internet-Draft Sep 2010 when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: All other objects and tables contain no data that is considered sensitive. 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. 10. 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 8, 2011 [Page 43] Internet-Draft Sep 2010 11. References 11.1. Normative References [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB", RFC3621, December 2003. [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. [POWER-MON-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. Chandramouli, "Requirements for Power Monitoring", draft-quittek-power-monitoring- requirements-00 (work in progress), October 2009. [ACPI] "Advanced Configuration and Power Interface Specification", http://www.acpi.info/spec30b.htm 11.2. Informative 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. Expires March 8, 2011 [Page 44] Internet-Draft Sep 2010 [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie, "Guidelines for Writing an IANA Considerations Section in RFCs ", BCP 26, RFC 5226, May 2008. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework ", RFC 3410, December 2002. [RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group MIB", RFC 2863, June 2000. [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. 12. Authors' Addresses Benoit Claise Cisco Systems Inc. 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 Expires March 8, 2011 [Page 45] Internet-Draft Sep 2010 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 8, 2011 [Page 46]