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.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>         Expires March 8 2010             [Page 1]


     Internet-Draft        <Energy Monitoring MIB>           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].
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>        Expires March 8, 2011            [Page 2]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>        Expires March 8, 2011            [Page 3]


     Internet-Draft        <Energy Monitoring MIB>           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].
     
     
     
     
     
     
     <Claise, et. Al>        Expires March 8, 2011            [Page 4]


     Internet-Draft        <Energy Monitoring MIB>           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.
     
     
     <Claise, et. Al>        Expires March 8, 2011            [Page 5]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011            [Page 6]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011            [Page 7]


     Internet-Draft        <Energy Monitoring MIB>           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.
     
     
     <Claise, et. Al>        Expires March 8, 2011            [Page 8]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011            [Page 9]


     Internet-Draft        <Energy Monitoring MIB>           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.
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 10]


     Internet-Draft        <Energy Monitoring MIB>           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.
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 11]


     Internet-Draft        <Energy Monitoring MIB>           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 |
        ==============================================================
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 12]


     Internet-Draft        <Energy Monitoring MIB>           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   | |
        | ============================================================ |
        |                                   ^                          |
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 13]


     Internet-Draft        <Energy Monitoring MIB>           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".
     
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 14]


     Internet-Draft        <Energy Monitoring MIB>           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    |
        ==============================================================
                                                 .
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 15]


     Internet-Draft        <Energy Monitoring MIB>           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".
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 16]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 17]


     Internet-Draft        <Energy Monitoring MIB>           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  | |
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 18]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 19]


     Internet-Draft        <Energy Monitoring MIB>           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.
     
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 20]


     Internet-Draft        <Energy Monitoring MIB>           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.
     
     
     
     
     
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 21]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 22]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 23]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 24]


     Internet-Draft        <Energy Monitoring MIB>           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."
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 25]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 26]


     Internet-Draft        <Energy Monitoring MIB>           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)
     
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 27]


     Internet-Draft        <Energy Monitoring MIB>           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)
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 28]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 29]


     Internet-Draft        <Energy Monitoring MIB>           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 }
     
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 30]


     Internet-Draft        <Energy Monitoring MIB>           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."
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 31]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 32]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 33]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 34]


     Internet-Draft        <Energy Monitoring MIB>           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 }
     
     
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 35]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 36]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 37]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 38]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 39]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 40]


     Internet-Draft        <Energy Monitoring MIB>           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,
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 41]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 42]


     Internet-Draft        <Energy Monitoring MIB>           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.
     
     
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 43]


     Internet-Draft        <Energy Monitoring MIB>           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.
     
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 44]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 45]


     Internet-Draft        <Energy Monitoring MIB>           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
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Claise, et. Al>        Expires March 8, 2011           [Page 46]