Network Working Group                                 J. Parello
     Internet-Draft                                         B. Claise
     Intended Status: Standards Track             Cisco Systems, Inc.
     Expires: April 16, 2011                         October 16, 2010
     
     
     
                    Energy-aware Networks and Devices MIB
                   draft-parello-eman-energy-aware-mib-00
     
     
     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.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Parello, Claise>       Expires April 16 2011            [Page 1]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
     
     Copyright Notice
     
        Copyright (c) 2010 IETF Trust and the persons identified as the
        document authors.  All rights reserved.
     
        This document is subject to BCP 78 and the IETF Trust's Legal
        Provisions Relating to IETF Documents
        (http://trustee.ietf.org/license-info) in effect on the date of
        publication of this document.  Please review these documents
        carefully, as they describe your rights and restrictions with
        respect to this document.  Code Components extracted from this
        document must include Simplified BSD License text as described
        in Section 4.e of the Trust Legal Provisions and are provided
        without warranty as described in the Simplified BSD License.
     
     
     Abstract
     
        This document defines a subset of the Management Information
        Base (MIB) for power and energy monitoring of devices.
     
     Conventions used in this document
     
       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
       "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
       and "OPTIONAL" in this document are to be interpreted as
       described in RFC 2119 [RFC2119].
     
     
     
     Table of Contents
     
        1. Introduction.............................................. 4
        2. The Internet-Standard Management Framework................ 4
        3. Use Cases................................................. 5
        4. Terminology............................................... 5
        5. Architecture Concepts Applied to the MIB Module........... 5
           5.1 Power Monitor Information............................. 5
           5.2 Power Monitor Meter Domain............................ 6
           5.3 Power Monitor Parent and Child........................ 7
           5.4 Power Monitor Context................................. 7
        6. Structure of the MIB...................................... 7
        7. MIB Definitions........................................... 8
        8. Security Considerations.................................. 18
        9. IANA Considerations...................................... 19
        10. References.............................................. 19
     
     
     <Parello, Claise>       Expires April 16, 2011            [Page 2]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
           10.1. Normative References............................... 19
           10.2. Informative References............................. 20
        11. Acknowledgments......................................... 21
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Parello, Claise>       Expires April 16, 2011            [Page 3]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
     
        TO DO
     
          . The roles/capabilities that the Power Monitor Parent have
             with Power Monitor Child(ren) are described in [POWER-MON-
             ARCH]:
                 1. Monitoring (only reporting)
                 2. Configuration power state
                 3. Configuration: power
             Example: on a PC, we can set power level without knowing
             the power. A solution must be specified in this draft.
             We have to find a way to model this role in this MIB
             module.  Bitmap is just one example.
     
     
     1. Introduction
     
        This document defines a subset of the Management Information
        Base (MIB) for use with network management protocols for power
        and energy monitoring of network devices and devices attached to
        the network, as specified in the Power Management Architecture
        [POWER-MON-ARCH], which in turn, is based on the Power
        Monitoring Requirements [POWER-MON-REQ] .
     
        This module's special focus is on monitoring energy-aware
        networks and devices.  The module addresses device
        identification, context information, and potential relationships
        between reporting devices, remote devices, and monitoring
        probes.
     
        Devices and their sub-components may be characterized by the
        power-related attributes of a physical entity present in the
        ENTITY MIB, even though ENTITY MIB compliance is not a
        requirement due to the variety and broad base of devices
        concerned with energy management.
     
     
     2. The Internet-Standard Management Framework
     
        For a detailed overview of the documents that describe the
        current Internet-Standard Management Framework, please refer to
        section 7 of RFC 3410 [RFC3410].
     
        Managed objects are accessed via a virtual information store,
        termed the Management Information Base or MIB.  MIB objects are
        generally accessed through the Simple Network Management
        Protocol (SNMP).  Objects in the MIB are defined using the
        mechanisms defined in the Structure of Management Information
     
     
     <Parello, Claise>       Expires April 16, 2011            [Page 4]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
        (SMI).  This memo specifies MIB modules that are compliant with
        SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58,
        RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
     
     3. Use Cases
     
        Requirements for power and energy monitoring for networking
        devices are specified in [POWER-MON-REQ].  The requirements in
        [POWER-MON-REQ] cover devices typically found in communications
        networks, such as switches, routers, and various connected
        endpoints.  For a power monitoring architecture to be useful, it
        should also apply to facility meters, power distribution units,
        gateway proxies for commercial building control, home automation
        devices, and devices that interface with the utility and/or
        smart grid.  Accordingly, the scope of the MIB modules in this
        document is broader than that specified in [POWER-MON-REQ].
     
     
     4. Terminology
     
        The definitions of basic terms like Power Monitor, Power Monitor
        Parent, Power Monitor Child, Power Monitor Meter Domain, Power
        Level, and Manufacturer Power Level can be found in the Power
        Management Architecture [POWER-MON-ARCH].
     
     
     
     5. Architecture Concepts Applied to the MIB Module
     
        This section describes the basic concepts specified in the Power
        Monitor Architecture [POWER-MON-ARCH], with specific information
        related to the MIB module specified in this document
        This subsection maps to the section "Architecture High Level
        Concepts" in the Power Monitoring Architecture [POWER-MON-ARCH].
     
     
     
     5.1 Power Monitor Information
     
        Refer to the "Power Monitor Information" section in [POWER-MON-
        ARCH] for background information.  An energy aware device is
        considered an instance of a power monitor as defined in the
        [POWER-MON-ARCH].
     
        The Power Monitor information is specified in the MIB module
        primary table, i.e. the pmTable.  Every Power Monitor SHOULD
     
     
     
     
     <Parello, Claise>       Expires April 16, 2011            [Page 5]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
        have a printable name pmName, and MUST HAVE a unique Power
        Monitor index pmIndex.
     
        The pmIndex is a unique index greater than zero for each Power
        Monitor.  It is recommended that values be assigned sequentially
        starting from 1.  The value for each pmIndex must remain
        constant at least from one re-initialization of the entity's
        network management system to the next re-initialization.  In
        addition, the Power Monitor can potentially have an
        entityPhysicalIndex from the ENTITY MIB [RFC4133] in the
        pmPhysicalEntity, if supported by the Power Monitor.  In case of
        Power over Ethernet (if the Power over Ethernet MIB is supported
        on the Power Monitor), the Power Monitor pmethPortIndex and
        pmethPortGrpIndex must contain the values of pethPsePortIndex
        and pethPsePortGroupIndex, respectively.  In case of LLDP-MED
        (if the LLDP-MED MIB is supported on the Power Monitor), the
        Power Monitor pmLldpPortNumber must contain the lldpLocPortNum
        from the LLDP MIB.
     
        Possible pmName conventions are: textual DNS name, MAC-address
        of the device, interface ifName, or a text string uniquely
        identifying the Power Monitor.  However, if entPhysicalName is
        present for the respective pmPhysicalEntity (i.e. if the ENTITY-
        MIB is supported), then the pmName SHOULD be identical to the
        entPhysicalName.  The pmName SHOULD be unique.  As an example,
        in the case of IP phones, pmName can be the device DNS name,
        while in the case of router/switch line cards, the pmName should
        contain the entPhysicalName.
     
        To distinguish if a Power Monitor is considered producing,
        consuming or metering power, the pmPowerCategory MIB object must
        be implemented.
     
     
       5.2 Power Monitor Meter Domain
     
        Refer to the "Power Monitor Meter Domain" section in [POWER-MON-
        ARCH] for background information.
     
        Each Power Monitor MUST be a member of a Power Monitor Meter
        Domain, specified by the pmDomainName MIB Object.  The
        pmDomainName, which is part of the pmTable, is a read-write MIB
        object.
     
     
     
     
     
     
     
     <Parello, Claise>       Expires April 16, 2011            [Page 6]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
       5.3 Power Monitor Parent and Child
     
        Refer to the "Power Monitor Parent and Child" section in [POWER-
        MON-ARCH] for background information.  In order to link the
        Power Monitor Child and the Power Monitor Parent, the pmParentId
        is introduced.
     
     
       5.4 Power Monitor Context
     
        Refer to the "Power Monitor Context" section in [POWER-MON-ARCH]
        for background information.
     
        A Power Monitor can provide a pmImportance value in the range of
        1..100 to help differentiate the use or relative value to the
        site.  The importance range is from 1 (least important) to 100
        (most important).  The default importance value is 1.
     
        A Power Monitor can provide a set of pmKeywords.  These keywords
        are a list of tags that can be used for grouping and summary
        reporting within or between Power Monitor Meter Domains.
     
        Additionally, a Power Monitor can provide a pmRoleDescription
        string that indicates the purpose the Power Monitor serves in
        the network or for the site/business.
     
     
     
     6. Structure of the MIB
     
        The primary MIB object in this MIB module is the
        EnergyAwareDeviceMIBObject.  The pmTable table of
        EnergyAwareDeviceMIBObject describes an entity in the network
        that is a Power Monitor according the [POWER-MON-ARCH].
     
        A Power Monitor that implements the EnergyAwareDeviceMIB
        contains information describing itself as an entity in the
        context of the network (such as its Power Monitor Meter Domain
        pmDomainName) and attributes for describing its business context
        (such as pmImportance, pmRoleDescription and pmKeywords).
     
        The information in this MIB describes the device itself so that
        the device is aware of its context in a communication network
        with respect to power.  The actual power usage, which is
        described in [POWER-MON-ARCH], is specified in [POWER-MON-MIB].
     
     
     
     
     
     <Parello, Claise>       Expires April 16, 2011            [Page 7]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
     
     7. MIB Definitions
     
     
        -- ************************************************************
        --
        --
        -- This MIB is used to monitor power usage of network
        -- devices
        --
        -- *************************************************************
     
        ENERGY-AWARE-MIB DEFINITIONS ::= BEGIN
     
        IMPORTS
            MODULE-IDENTITY,
            OBJECT-TYPE,
            mib-2,
            Integer32
                FROM SNMPv2-SMI
            TEXTUAL-CONVENTION
                FROM SNMPv2-TC
            MODULE-COMPLIANCE,
            OBJECT-GROUP
                FROM SNMPv2-CONF
            SnmpAdminString
                FROM SNMP-FRAMEWORK-MIB
            PhysicalIndexOrZero
                FROM ENTITY-MIB;
     
     
        energyAwareMIB MODULE-IDENTITY
            LAST-UPDATED    "201010150000Z"
            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
     
     
     
     <Parello, Claise>       Expires April 16, 2011            [Page 8]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
               "This MIB is used to monitor power and energy in
               devices."
            REVISION
                "201010150000Z"
            DESCRIPTION
               "Initial version, published as RFC XXXX."
     
     
           ::= { mib-2 xxxxx }
     
        energyAwareMIBNotifs OBJECT IDENTIFIER
            ::= { energyAwareMIB 0 }
     
        energyAwareMIBObjects OBJECT IDENTIFIER
            ::= { energyAwareMIB 1 }
     
        energyAwareMIBConform  OBJECT IDENTIFIER
            ::= { energyAwareMIB 2 }
     
     
        -- Textual Conventions
     
        PowerMonitorId ::= TEXTUAL-CONVENTION
            STATUS          current
            DESCRIPTION
             "This object indicates the Power Monitor Universally
             Unique Identifier."
            REFERENCE
                   "IETF RFC 4122"
            SYNTAX          OCTET STRING (SIZE (16))
     
        PethPsePortIndexOrZero ::= TEXTUAL-CONVENTION
        DISPLAY-HINT "d"
           STATUS            current
           DESCRIPTION
               "This textual convention is an extension of the
               pethPsePortIndex convention, which defines a greater than
               zero value used to identify a power Ethernet PSE port.
               This extension permits the additional value of zero.  The
               semantics of the value zero are object-specific and must,
               therefore, be defined as part of the description of any
               object that uses this syntax.  Examples of the usage of
               this extension are situations where none or all physical
               entities need to be referenced."
           SYNTAX Integer32 (0..2147483647)
     
     
     
     <Parello, Claise>       Expires April 16, 2011            [Page 9]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
        PethPsePortGroupIndexOrZero::= TEXTUAL-CONVENTION
        DISPLAY-HINT "d"
           STATUS            current
           DESCRIPTION
               "This textual convention is an extension of the
               pethPsePortGroupIndex convention, which defines a greater
               than zero value used to identify group containing the
               port to which a power Ethernet PSE is connected.  This
               extension permits the additional value of zero.  The
               semantics of the value zero are object-specific and must,
               therefore, be defined as part of the description of any
               object that uses this syntax.  Examples of the usage of
               this extension are situations where none or all physical
               entities need to be referenced."
           SYNTAX Integer32 (0..2147483647)
     
      LldpPortNumberOrZero ::= TEXTUAL-CONVENTION
           DISPLAY-HINT "d"
           STATUS     current
           DESCRIPTION
               "This textual convention is an extension of the
               LldpPortNumber convention specified in the LLDP MIB,
               which defines a greater than zero value used to uniquely
               identify each port contained in the chassis (that is
               known to the LLDP agent) by a port number.  This
               extension permits the additional value of zero. The
               semantics of the value zero are object-specific and must,
               therefore, be defined as part of the description of any
               object that uses this syntax.  Examples of the usage of
               this extension are situations where none or all physical
               entities need to be referenced."
          SYNTAX Integer32(0..4096)
     
       PowerMonitorKeywordList ::= TEXTUAL-CONVENTION
           STATUS          current
           DESCRIPTION
               "A list of keywords that can be used to group Power
               Monitors for reporting or searching. If multiple keywords
               are present, then this string will contain all the
               keywords separated by the ',' character. For example, if
               a Power Monitor were to be tagged with the keyword values
     
     
     
     <Parello, Claise>       Expires April 16, 2011           [Page 10]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
               'hospitality' and 'guest', then the keyword list will be
               'hospitality,guest'."
           SYNTAX OCTET STRING (SIZE (0..255))
     
     
        -- Objects
     
     
        pmTable OBJECT-TYPE
            SYNTAX          SEQUENCE OF PmEntry
            MAX-ACCESS      not-accessible
            STATUS          current
            DESCRIPTION
               "This table lists Power Monitors."
            ::= { energyAwareMIBObjects 1 }
     
     
        pmEntry OBJECT-TYPE
            SYNTAX          PmEntry
            MAX-ACCESS      not-accessible
            STATUS          current
            DESCRIPTION
               "An entry describes the attributes of a Power Monitor.
               Whenever a new Power Monitor is added or deleted a row in
               the pmTable is added or deleted."
            INDEX           { pmIndex }
            ::= { pmTable 1 }
     
     
        PmEntry ::= SEQUENCE {
                pmIndex                     Integer32,
                pmPowerMonitorId            PowerMonitorId,
                pmPhysicalEntity            PhysicalIndexOrZero,
                pmEthPortIndex              PethPsePortIndexOrZero,
                pmEthPortGrpIndex           PethPsePortGroupIndexOrZero,
                pmLldpPortNumber            LldpPortNumberOrZero,
                pmName                      SnmpAdminString,
                pmDomainName                SnmpAdminString,
                pmRoleDescription           SnmpAdminString,
                pmKeywords                  PowerMonitorKeywordList,
                pmImportance                Integer32,
                pmPowerCategory             INTEGER,
                pmParentId                  PowerMonitorId
        }
     
        pmIndex OBJECT-TYPE
            SYNTAX          Integer32 (1..2147483647)
     
     
     <Parello, Claise>       Expires April 16, 2011           [Page 11]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
            MAX-ACCESS      not-accessible
            STATUS          current
            DESCRIPTION
               "A unique value, greater than zero, for each Power
               Monitor. It is recommended that values be assigned
               sequentially starting from 1.  The value for each pmIndex
               must remain constant at least from one re-initialization
               of the entity's network management system to the next re-
               initialization."
             ::= { pmEntry 1 }
     
        pmPowerMonitorId OBJECT-TYPE
            SYNTAX          PowerMonitorId
            MAX-ACCESS      read-only
            STATUS          current
            DESCRIPTION
               "This object indicates the Power Monitor UUID
               identifier."
            ::= { pmEntry 2 }
     
        pmPhysicalEntity OBJECT-TYPE
            SYNTAX          PhysicalIndexOrZero
            MAX-ACCESS      read-only
            STATUS          current
            DESCRIPTION
               "This object contains the index of a physical entity in
               the ENTITY MIB.  This physical entity is the given
               observation point.  If such a physical entity cannot be
               specified or is not known then the object is zero."
            ::= { pmEntry 3 }
     
        pmEthPortIndex   OBJECT-TYPE
            SYNTAX       PethPsePortIndexOrZero
            MAX-ACCESS   read-only
            STATUS       current
            DESCRIPTION
               "This variable uniquely identifies the power Ethernet
               port to which the attached device is connected [RFC3621].
               If such a power Ethernet port cannot be specified or is
               not known then the object is zero."
            ::= { pmEntry 4 }
     
        pmEthPortGrpIndex   OBJECT-TYPE
            SYNTAX       PethPsePortGroupIndexOrZero
            MAX-ACCESS   read-only
            STATUS       current
            DESCRIPTION
     
     
     
     <Parello, Claise>       Expires April 16, 2011           [Page 12]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 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 }
     
        pmLldpPortNumber   OBJECT-TYPE
            SYNTAX       LldpPortNumberOrZero
            MAX-ACCESS   read-only
            STATUS       current
            DESCRIPTION
              "This variable uniquely identifies the port component
              (contained in the local chassis with the LLDP agent) as
              defined by the lldpLocPortNum in the [LLDP-MIB] and
              [LLDP-MED-MIB]. If such a port number cannot be specified
              or is not known then the object is zero."
           ::= { pmEntry 6 }
     
        pmName OBJECT-TYPE
            SYNTAX          SnmpAdminString
            MAX-ACCESS      read-write
            STATUS          current
            DESCRIPTION
               "This object specifies a printable name, a text string,
               for the Power Monitor. The pmName SHOULD be unique.If
               pmPhysicalName is present for the respective
               pmPhysicalEntity (i.e. if the ENTITY-MIB is supported),
               then the pmName SHOULD be identical to the
               pmPhysicalName. If pmPhysicalName is not present, the
               process to assign the pmName can be implementation
               specific. Example: DNS Name, MAC address in canonical
               form, ifName, etc.
               However, if pmPhysicalName is present for the respective
               pmPhysicalEntity (i.e. if the ENTITY-MIB is supported),
               then the pmName should be identical to the
               pmPhysicalName."
            ::= { pmEntry 7 }
     
        pmDomainName OBJECT-TYPE
            SYNTAX          SnmpAdminString
            MAX-ACCESS      read-write
            STATUS          current
            DESCRIPTION
               "This object specifies the name of a Power Monitor Meter
               Domain for the Power Monitor.  This object specifies a
               null string if no Power Monitor Domain name is
               configured. The value of pmDomainName must remain
               constant at least from one re-initialization of the
     
     
     <Parello, Claise>       Expires April 16, 2011           [Page 13]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
               entity's network management system to the next re-
               initialization."
            ::= { pmEntry 8 }
     
        pmRoleDescription OBJECT-TYPE
            SYNTAX          SnmpAdminString
            MAX-ACCESS      read-write
            STATUS          current
            DESCRIPTION
               "This object specifies an administratively assigned name
               to indicate the purpose a Power Monitor serves in the
               network.
     
               For example, we can have a phone deployed to a lobby with
               pmRoleDescription as 'Lobby IP phone'.
     
               This object specifies a null string if no role
               description is configured."
            ::= { pmEntry 9 }
     
        pmKeywords OBJECT-TYPE
            SYNTAX          PowerMonitorKeywordList
            MAX-ACCESS      read-write
            STATUS          current
            DESCRIPTION
              "This object specifies a list of keywords that can be
              used to group Power Monitors for reporting or searching.
              This object specifies the null string if no keywords have
              been configured. If multiple keywords are present, then
              this string will contain all the keywords separated by
              the ',' character. For example, if a Power Monitor were
              to be tagged with the keyword values 'hospitality' and
              'guest', then the keyword list will be
              'hospitality,guest'.
     
               If write access is implemented and a value is written
               into the instance, the agent must retain the supplied
               value in the pmKeywords instance associated with
               the same physical entity for as long as that entity
               remains instantiated.  This includes instantiations
               across all re-initializations/reboots of the network
               management system."
            ::= { pmEntry 10 }
     
        pmImportance OBJECT-TYPE
            SYNTAX          Integer32 (1..100)
            MAX-ACCESS      read-write
            STATUS          current
     
     
     <Parello, Claise>       Expires April 16, 2011           [Page 14]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
            DESCRIPTION
               "This object specifies a ranking of how important the
               Power Monitor is (on a scale of 1 to 100) compared with
               other Power Monitors in the same Power Monitor Meter
               Domain. The ranking should provide a business or
               operational context for the Power Monitor as compared to
               other similar Power Monitors. This ranking could be used
               as input for policy-based network management.
     
     
               Although network managers must establish their own
               ranking, the following is a broad recommendation:
     
               90 to 100 Emergency response
               80 to 90 Executive or business critical
               70 to 79 General or Average
               60 to  69 Staff or support
               40 to  59 Public or guest
               1  to 39 Decorative or hospitality"
            DEFVAL          { 1 }
            ::= { pmEntry 11 }
     
        pmPowerCategory OBJECT-TYPE
            SYNTAX          INTEGER {
                                consumer(0),
                                provider(1),
                                meter(2)
                            }
            MAX-ACCESS      read-only
            STATUS          current
            DESCRIPTION
               "This object describes the Power Monitor and indicates
               the expected power usage of the Power Monitor. A Power
               Monitor could be designed or manufactured to be a
               provider(1), consumer(0) or meter(2) of power.
     
               The actual power direction is indicated by the sign of
               pmPower, with positive representing consumption and
               negative representing production, and may or may not
               match the expected value of pmPowerCategory. In these
               cases the two objects can be used to detect unexpected
               conditions of the Power Monitor.
     
               For example a generator with a category of provider(1)
               that is malfunctioning and is consuming power as
               indicated by a positive pmPower value."
            ::= { pmEntry 12 }
     
     
     
     <Parello, Claise>       Expires April 16, 2011           [Page 15]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
     
        pmParentId OBJECT-TYPE
            SYNTAX       PowerMonitorId
            MAX-ACCESS   read-only
            STATUS       current
            DESCRIPTION
               "If the current Power Monitor has a Power Monitor Parent,
               then its Power Monitor Id value is set in pmParentId.
               Otherwise, the pmParentId value is the null string."
            ::= { pmEntry 13 }
     
     
     
        -- Conformance
     
        energyAwareMIBCompliances  OBJECT IDENTIFIER
            ::= { energyAwareMIBObjects 3 }
     
        energyAwareMIBGroups  OBJECT IDENTIFIER
            ::= { energyAwareMIBObjects 4 }
     
     
        energyAwareMIBFullCompliance 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 {
                        energyAwareMIBTableGroup
                            }
     
            ::= { energyAwareMIBCompliances 1 }
     
        energyAwareMIBReadOnlyCompliance MODULE-COMPLIANCE
            STATUS          current
            DESCRIPTION
                "When this MIB is implemented without support for
                read-create (i.e. in read-only mode), then such an
                implementation can claim read-only compliance.  Such a
                device can then be monitored but can not be configured
                with this MIB."
            MODULE          -- this module
            MANDATORY-GROUPS {
                         energyAwareMIBTableGroup
                            }
     
     
     <Parello, Claise>       Expires April 16, 2011           [Page 16]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
     
            OBJECT          pmName
            MIN-ACCESS      read-only
            DESCRIPTION
                "Write access is not required."
     
            OBJECT          pmDomainName
            MIN-ACCESS      read-only
            DESCRIPTION
                "Write access is not required."
     
            OBJECT          pmRoleDescription
            MIN-ACCESS      read-only
            DESCRIPTION
                "Write access is not required."
     
            OBJECT          pmKeywords
            MIN-ACCESS      read-only
            DESCRIPTION
            "Write access is not required."
     
            OBJECT          pmImportance
            MIN-ACCESS      read-only
            DESCRIPTION
                "Write access is not required."
     
        ::= { energyAwareMIBCompliances 2 }
     
        -- Units of Conformance
     
        energyAwareMIBTableGroup OBJECT-GROUP
            OBJECTS         {
                                -- Note that object pmIndex is NOT
                                -- included since it is not-accessible
                                pmPowerMonitorId,
                                pmPhysicalEntity,
                                pmEthPortIndex,
                                pmEthPortGrpIndex,
                                pmLldpPortNumber,
                                pmName,
                                pmDomainName,
                                pmRoleDescription,
                                pmKeywords,
                                pmImportance,
                                pmPowerCategory,
                                pmParentId
                            }    STATUS          current
            DESCRIPTION
     
     
     <Parello, Claise>       Expires April 16, 2011           [Page 17]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
                "This group contains the collection of all the objects
                related to the PowerMonitor."
            ::= { energyAwareMIBGroups 1 }
     
     
        END
     
     
     8. Security Considerations
     
        Some of the readable objects in these MIB modules (i.e., objects
        with a MAX-ACCESS other than not-accessible) may be considered
        sensitive or vulnerable in some network environments.  It is
        thus important to control even GET and/or NOTIFY access to these
        objects and possibly to even encrypt the values of these objects
        when sending them over the network via SNMP.
     
        There are a number of management objects defined in these MIB
        modules with a MAX-ACCESS clause of read-write and/or read-
        create.  Such objects MAY be considered sensitive or vulnerable
        in some network environments.  The support for SET operations in
        a non-secure environment without proper protection can have a
        negative effect on network operations.  The following are the
        tables and objects and their sensitivity/vulnerability:
     
          . Unauthorized changes to the pmDomainName, pmName,
             pmRoleDescription, pmKeywords, and/or pmImportance MAY
             disrupt power and energy collection, and therefore any
             predefined policies defined in the network.
     
     
        SNMP versions prior to SNMPv3 did not include adequate security.
        Even if the network itself is secure (for example, by using
        IPsec), there is still no secure control over 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
     
     
     <Parello, Claise>       Expires April 16, 2011           [Page 18]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
        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 GET or SET (change/create/delete) them.
     
     
     9. 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
          ----------                         -----------------------
          energyAwareMIB   { 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.
     
     
     10. References
     
     10.1. Normative References
     
     
        [RFC2119] S. Bradner, Key words for use in RFCs to Indicate
                Requirement Levels, BCP 14, RFC 2119, March 1997.
     
        [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
                Schoenwaelder, Ed., "Structure of Management
                Information Version 2 (SMIv2)", STD 58, RFC 2578, April
                1999.
     
        [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
                Schoenwaelder, Ed., "Textual Conventions for SMIv2",
                STD 58, RFC 2579, April 1999.
     
        [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                "Conformance Statements for SMIv2", STD 58, RFC 2580,
                April 1999.
     
     
     
     
     <Parello, Claise>       Expires April 16, 2011           [Page 19]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
        [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB",
                RFC3621, December 2003.
     
        [RFC4133]  Bierman, A. and K. McCloghrie, "Entity MIB (Version
                3)", RFC 4133, August 2005.
     
        [LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base
                module for LLDP configuration, statistics, local system
                data and remote systems data components", May 2005.
     
        [LLDP-MED-MIB]  ANSI/TIA-1057, "The LLDP Management Information
                Base extension module for TIA-TR41.4 media endpoint
                discovery information", July 2005.
     
     
     10.2. Informative References
     
     
     
        [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
                "Introduction and Applicability Statements for Internet
                Standard Management Framework ", RFC 3410, December
                2002.
     
        [RFC5226]  Narten, T. Alverstrand, H., A. and K. McCloghrie,
                "Guidelines for Writing an IANA Considerations Section
                in RFCs ", BCP 26, RFC 5226, May 2008.
     
     
        [POWER-MON-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B.,
                and M. Chandramouli, "Requirements for Power
                Monitoring", draft-quittek-power-monitoring-
                requirements-01 (work in progress), October 2009.
     
        [POWER-MON-ARCH] Claise, B., Parello, J., and B. Schoening,
                "Power Management Architecture", draft-claise-power-
                management-arch-01 (work in progress), August 2010.
     
        [POWER-MON-MIB] Claise, B., Chandramouli, M., Parello, J., and
                B. Schoening, "Power and Energy Monitoring MIB", draft-
                claise-energy-monitoring-mib-05 (work in progress),
                September 2010.
     
     
     
     
     
     
     
     
     <Parello, Claise>       Expires April 16, 2011           [Page 20]


     Internet-Draft <Energy-aware Networks and Devices MIB>  Oct 2010
     
     11. Acknowledgments
     
        The authors would like to Brad Schoening and Mouli Chandramouli
        for their help, and Michael Brown for improving the text
        dramatically.
     
     
     
     Authors' Addresses
     
      Benoit Claise
      Cisco Systems Inc.
      De Kleetlaan 6a b1
      Diegem 1813
      BE
     
      Phone: +32 2 704 5622
      Email: bclaise@cisco.com
     
     
      John Parello
      Cisco Systems Inc.
      3550 Cisco Way
      San Jose, California 95134
      US
     
      Phone: +1 408 525 2339
      Email: jparello@cisco.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     <Parello, Claise>       Expires April 16, 2011           [Page 21]