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