6. Discovery
It is probable that most Energy Objects will require the implementation of the ENERGY-OBJECT-CONTEXT-MIB [RFC7461] as a prerequisite for this MIB module. In such a case, the eoPowerTable of the EMAN-ENERGY-OBJECT-MIB is cross-referenced with the eoTable of ENERGY-OBJECT-CONTEXT-MIB via entPhysicalIndex. Every Energy Object MUST implement entPhysicalIndex, entPhysicalClass, entPhysicalName, and entPhysicalUUID from the ENTITY-MIB [RFC6933]. As the primary
index for the Energy Object, entPhysicalIndex is used: it characterizes the Energy Object in the ENERGY-OBJECT-MIB and the POWER-ATTRIBUTES-MIB MIB modules (this document). The NMS must first poll the ENERGY-OBJECT-CONTEXT-MIB MIB module [RFC7461], if available, in order to discover all the Energy Objects and the relationships between those Energy Objects. In the ENERGY- OBJECT-CONTEXT-MIB module tables, the Energy Objects are indexed by the entPhysicalIndex. From there, the NMS must poll the eoPowerStateTable (specified in the ENERGY-OBJECT-MIB module in this document), which enumerates, amongst other things, the maximum power usage. As the entries in eoPowerStateTable table are indexed by the Energy Object (entPhysicalIndex) and by the Power State Set (eoPowerStateIndex), the maximum power usage is discovered per Energy Object, and the power usage per Power State of the Power State Set. In other words, reading the eoPowerStateTable allows the discovery of each Power State within every Power State Set supported by the Energy Object. The MIB module may be populated with the Energy Object relationship information, which have its own Energy Object index value (entPhysicalIndex). However, the Energy Object relationship must be discovered via the ENERGY-OBJECT-CONTEXT-MIB module. Finally, the NMS can monitor the power attributes with the POWER- ATTRIBUTES-MIB MIB module, which reuses the entPhysicalIndex to index the Energy Object.7. Link with the Other IETF MIBs
7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB
[RFC6933] defines the ENTITY-MIB module that lists the physical entities of a networking device (router, switch, etc.) and those physical entities indexed by entPhysicalIndex. From an energy- management standpoint, the physical entities that consume or produce energy are of interest. [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-unit precision) from sensors embedded in networking devices. Sensors are associated with each index of the entPhysicalIndex of the ENTITY-MIB [RFC6933]. While the focus of the Monitoring and Control MIB for Power and Energy is on measurement of power usage of networking equipment indexed by the ENTITY-MIB, this MIB supports a customized
power scale for power measurement and different Power States of networking equipment and the functionality to configure the Power States. The Energy Objects are modeled by the entPhysicalIndex through the entPhysicalEntity MIB object specified in the eoTable in the ENERGY- OBJECT-CONTEXT-MIB MIB module [RFC7461]. The ENTITY-SENSOR MIB [RFC3433] does not have the ANSI C12.x accuracy classes required for electricity (e.g., 1%, 2%, and 0.5% accuracy classes). Indeed, entPhySensorPrecision [RFC3433] represents "The number of decimal places of precision in fixed-point sensor values returned by the associated entPhySensorValue object". The ANSI and IEC standards are used for power measurement and these standards require that we use an accuracy class, not the scientific-number precision model specified in RFC3433. The eoPowerAccuracy MIB object models this accuracy. Note that eoPowerUnitMultipler represents the scale factor per IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22], which is a more logical representation for power measurements (compared to entPhySensorScale), with the mantissa and the exponent values X * 10 ^ Y. Power measurements specifying the qualifier 'UNITS' for each measured value in watts are used in the LLDP-EXT-MED-MIB, Power Ethernet [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 MIBs are implemented for all Energy Objects that need to be monitored. A typical example is a converged building gateway, which can monitor other devices in a building and provides a proxy between SNMP and a protocol like BACnet. Another example is the home energy controller. In such cases, the eoPhysicalEntity value contains the zero value, using the PhysicalIndexOrZero Textual Convention. The eoPower is similar to entPhySensorValue [RFC3433] and the eoPowerUnitMultipler is similar to entPhySensorScale.7.2. Link with the ENTITY-STATE MIB
For each entity in the ENTITY-MIB [RFC6933], the ENTITY-STATE MIB [RFC4268] specifies the operational states (entStateOper: unknown, enabled, disabled, testing), the alarm (entStateAlarm: unknown, underRepair, critical, major, minor, warning, indeterminate), and the possible values of standby states (entStateStandby: unknown, hotStandby, coldStandby, providingService).
From a power-monitoring point of view, in contrast to the entity operational states of entities, Power States are required, as proposed in the Monitoring and Control MIB for Power and Energy. Those Power States can be mapped to the different operational states in the ENTITY-STATE MIB, if a formal mapping is required. For example, the entStateStandby "unknown", "hotStandby", and "coldStandby" states could map to the Power State "unknown", "ready", "standby", respectively, while the entStateStandby "providingService" could map to any "low" to "high" Power State.7.3. Link with the POWER-OVER-ETHERNET MIB
The Power-over-Ethernet MIB [RFC3621] provides an energy monitoring and configuration framework for power over Ethernet devices. RFC 3621 defines a port group entity on a switch for power monitoring and management policy and does not use the entPhysicalIndex index. Indeed, pethMainPseConsumptionPower is indexed by the pethMainPseGroupIndex, which has no mapping with the entPhysicalIndex. If the Power-over-Ethernet MIB [RFC3621] is supported, the Energy Object eoethPortIndex and eoethPortGrpIndex contain the pethPsePortIndex and pethPsePortGroupIndex, respectively. However, one cannot assume that the Power-over-Ethernet MIB is implemented for most or all Energy Objects. In such cases, the eoethPortIndex and eoethPortGrpIndex values contain the zero value, via the new PethPsePortIndexOrZero and PethPsePortGroupIndexOrZero TCs. In either case, the entPhysicalIndex MIB object is used as the unique Energy Object index. Note that, even though the Power-over-Ethernet MIB [RFC3621] was created after the ENTITY-SENSOR MIB [RFC3433], it does not reuse the precision notion from the ENTITY-SENSOR MIB, i.e., the entPhySensorPrecision MIB object.7.4. Link with the UPS MIB
To protect against unexpected power disruption, data centers and buildings make use of Uninterruptible Power Supplies (UPS). To protect critical assets, a UPS can be restricted to a particular subset or domain of the network. UPS usage typically lasts only for a finite period of time, until normal power supply is restored. Planning is required to decide on the capacity of the UPS based on output power and duration of probable power outage. To properly provision UPS power in a data center or building, it is important to
first understand the total demand required to support all the entities in the site. This demand can be assessed and monitored via the Monitoring and Control MIB for Power and Energy. The UPS MIB [RFC1628] provides information on the state of the UPS network. Implementation of the UPS MIB is useful at the aggregate level of a data center or a building. The MIB module contains several groups of variables: - upsIdent: Identifies the UPS entity (name, model, etc.). - upsBattery group: Indicates the battery state (upsbatteryStatus, upsEstimatedMinutesRemaining, etc.) - upsInput group: Characterizes the input load to the UPS (number of input lines, voltage, current, etc.). - upsOutput: Characterizes the output from the UPS (number of output lines, voltage, current, etc.) - upsAlarms: Indicates the various alarm events. The measurement of power in the UPS MIB is in volts, amperes, and watts. The units of power measurement are root mean square (RMS) volts and RMS amperes. They are not based on the EntitySensorDataScale and EntitySensorDataPrecision of ENTITY-SENSOR- MIB. Both the Monitoring and Control MIB for Power and Energy and the UPS MIB may be implemented on the same UPS SNMP agent, without conflict. In this case, the UPS device itself is the Energy Object and any of the UPS meters or submeters are the Energy Objects with a possible relationship as defined in [RFC7326].7.5. Link with the LLDP and LLDP-MED MIBs
The Link Layer Discovery Protocol (LLDP) is a Data Link Layer protocol used by network devices to advertise their identities, capabilities, and interconnections on a LAN network. The Media Endpoint Discovery is an enhancement of LLDP, known as LLDP-MED. The LLDP-MED enhancements specifically address voice applications. LLDP-MED covers six basic areas: capability discovery, LAN speed and duplex discovery, network policy discovery, location identification discovery, inventory discovery, and power discovery.
Of particular interest to the current MIB module is the power discovery, which allows the endpoint device (such as a PoE phone) to convey power requirements to the switch. In power discovery, LLDP-MED has four Type-Length-Values (TLVs): power type, power source, power priority, and power value. Respectively, those TLVs provide information related to the type of power (power sourcing entity versus powered device), how the device is powered (from the line, from a backup source, from external power source, etc.), the power priority (how important is it that this device has power?), and how much power the device needs. The power priority specified in the LLDP-MED MIB [LLDP-MED-MIB] actually comes from the Power-over-Ethernet MIB [RFC3621]. If the Power-over-Ethernet MIB [RFC3621] is supported, the exact value from the pethPsePortPowerPriority [RFC3621] is copied over into the lldpXMedRemXPoEPDPowerPriority [LLDP-MED-MIB]; otherwise, the value in lldpXMedRemXPoEPDPowerPriority is "unknown". From the Monitoring and Control MIB for Power and Energy, it is possible to identify the pethPsePortPowerPriority [RFC3621], via the eoethPortIndex and eoethPortGrpIndex. The lldpXMedLocXPoEPDPowerSource [LLDP-MED-MIB] is similar to eoPowerMeasurementLocal in indicating if the power for an attached device is local or from a remote device. If the LLDP-MED MIB is supported, the following mapping can be applied to the eoPowerMeasurementLocal: lldpXMedLocXPoEPDPowerSource fromPSE(2) and local(3) can be mapped to false and true, respectively.8. Structure of the MIB
The primary MIB object in the energyObjectMib MIB module is the energyObjectMibObjects root. The eoPowerTable table of energyObjectMibObjects describes the power measurement attributes of an Energy Object entity. The identity of a device in terms of uniquely identification of the Energy Object and its relationship to other entities in the network are addressed in [RFC7461]. Logically, this MIB module is a sparse extension of the ENERGY- OBJECT-CONTEXT-MIB module [RFC7461]. Thus, the following requirements that are applied to [RFC7461] are also applicable. As a requirement for this MIB module, [RFC7461] SHOULD be implemented and as Module Compliance of ENTITY-MIB V4 [RFC6933] with respect to entity4CRCompliance MUST be supported, which requires four MIB objects: entPhysicalIndex, entPhysicalClass, entPhysicalName, and entPhysicalUUID MUST be implemented.
The eoMeterCapabilitiesTable is useful to enable applications to determine the capabilities supported by the local management agent. This table indicates the energy-monitoring MIB groups that are supported by the local management system. By reading the value of this object, it is possible for applications to know which tables contain the information and are usable without walking through the table and querying every element that involves a trial-and-error process. The power measurement of an Energy Object contains information describing its power usage (eoPower) and its current Power State (eoPowerOperState). In addition to power usage, additional information describing the units of measurement (eoPowerAccuracy, eoPowerUnitMultiplier), how power usage measurement was obtained (eoPowerMeasurementCaliber), the source of power measurement (eoPowerMeasurementLocal), and the type of power (eoPowerCurrentType) are described. An Energy Object may contain an optional eoEnergyTable to describe energy measurement information over time. An Energy Object may contain an optional eoACPwrAttributesTable table (specified in the POWER-ATTRIBUTES-MIB module) that describes the electrical characteristics associated with the current Power State and usage. An Energy Object may also contain optional battery information associated with this entity.9. MIB Definitions
9.1. The IANAPowerStateSet-MIB Module
-- ************************************************************ -- -- -- This MIB, maintained by IANA, contains a single Textual -- Convention: PowerStateSet -- -- ************************************************************ IANAPowerStateSet-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; ianaPowerStateSet MODULE-IDENTITY
LAST-UPDATED "201502090000Z" -- 9 February 2015 ORGANIZATION "IANA" CONTACT-INFO " Internet Assigned Numbers Authority Postal: ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 United States Tel: +1-310-301 5800 EMail: iana@iana.org" DESCRIPTION "Copyright (c) 2015 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This MIB module defines the PowerStateSet Textual Convention, which specifies the Power State Sets and Power State Set Values an Energy Object supports. The initial version of this MIB module was published in RFC 7460; for full legal notices see the RFC itself." -- revision history REVISION "201502090000Z" -- 9 February 2015 DESCRIPTION "Initial version of this MIB module, as published as RFC 7460." ::= { mib-2 228 } PowerStateSet ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "IANAPowerState is a textual convention that describes Power State Sets and Power State Set Values an Energy Object supports. IANA has created a registry of Power State supported by an Energy Object and IANA shall administer the list of Power State Sets and Power States.
The Textual Convention assumes that Power States in a Power State Set are limited to 255 distinct values. For a Power State Set S, the named number with the value S * 256 is allocated to indicate the Power State Set. For a Power State X in the Power State Set S, the named number with the value S * 256 + X + 1 is allocated to represent the Power State. Requests for new values should be made to IANA via email (iana@iana.org)." REFERENCE "http://www.iana.org/assignments/power-state-sets" SYNTAX INTEGER { other(0), -- indicates other set unknown(255), -- unknown ieee1621(256), -- indicates IEEE1621 set ieee1621Off(257), ieee1621Sleep(258), ieee1621On(259), dmtf(512), -- indicates DMTF set dmtfOn(513), dmtfSleepLight(514), dmtfSleepDeep(515), dmtfOffHard(516), dmtfOffSoft(517), dmtfHibernate(518), dmtfPowerOffSoft(519), dmtfPowerOffHard(520), dmtfMasterBusReset(521), dmtfDiagnosticInterrapt(522), dmtfOffSoftGraceful(523), dmtfOffHardGraceful(524), dmtfMasterBusResetGraceful(525), dmtfPowerCycleOffSoftGraceful(526), dmtfPowerCycleHardGraceful(527), eman(1024), -- indicates EMAN set emanMechOff(1025), emanSoftOff(1026), emanHibernate(1027), emanSleep(1028), emanStandby(1029), emanReady(1030), emanLowMinus(1031), emanLow(1032),
emanMediumMinus(1033), emanMedium(1034), emanHighMinus(1035), emanHigh(1036) } END