Energy Management Working Group C. Verges Internet-Draft Cyber Switching, Inc. Intended status: Standards Track February 23, 2011 Expires: August 27, 2011 Energy Monitoring and Management of Networked Entities using SNMP and Role-Specific Sparse Tables draft-verges-eman-separate-modules-mib-00 Abstract This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. The module addresses devices identification, context information, and the relationship between reporting devices, remote devices, and monitoring probes. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the power usage of a network entity. The energy management schema is split into one core table to enumerate the entities being managed and numerous sparse table extensions that add role-specific functionality where appropriate. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 27, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Verges Expires August 27, 2011 [Page 1] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 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. Verges Expires August 27, 2011 [Page 2] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Energy Management Document Overview . . . . . . . . . . . . . 4 3. Relationship to Other EMAN Proposals . . . . . . . . . . . . . 5 4. The Internet-Standard Management Framework . . . . . . . . . . 8 5. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Structure of the EMAN-CORE-MIB Module . . . . . . . . . . . . 8 6.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 8 6.1.1. EmanEntityRole . . . . . . . . . . . . . . . . . . . . 8 6.1.2. EmanEntityCapabilities . . . . . . . . . . . . . . . . 8 6.1.3. Thousandths . . . . . . . . . . . . . . . . . . . . . 9 6.1.4. UnitMultiplier . . . . . . . . . . . . . . . . . . . . 9 6.2. The Notifications Subtree . . . . . . . . . . . . . . . . 9 6.3. The Table Structures . . . . . . . . . . . . . . . . . . . 9 7. Structure of the EMAN-DATA-MIB Module . . . . . . . . . . . . 10 7.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 11 7.2. The Notifications Subtree . . . . . . . . . . . . . . . . 11 7.3. The Table Structures . . . . . . . . . . . . . . . . . . . 11 8. Structure of the EMAN-CONTROL-MIB Module . . . . . . . . . . . 12 8.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 12 8.2. The Notifications Subtree . . . . . . . . . . . . . . . . 12 8.3. The Table Structures . . . . . . . . . . . . . . . . . . . 12 9. Structure of the EMAN-CONTEXT-MIB Module . . . . . . . . . . . 13 9.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 13 9.2. The Notifications Subtree . . . . . . . . . . . . . . . . 13 9.3. The Table Structures . . . . . . . . . . . . . . . . . . . 13 10. Structure of the EMAN-HEALTH-MIB Module . . . . . . . . . . . 14 10.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 14 10.2. The Notifications Subtree . . . . . . . . . . . . . . . . 14 10.3. The Table Structures . . . . . . . . . . . . . . . . . . . 14 11. Structure of the EMAN-LLDP-MIB Module . . . . . . . . . . . . 14 11.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 14 11.2. The Notifications Subtree . . . . . . . . . . . . . . . . 14 11.3. The Table Structures . . . . . . . . . . . . . . . . . . . 14 12. Relationship to Other MIB Modules . . . . . . . . . . . . . . 14 12.1. Relationship to the [TEMPLATE TODO] MIB . . . . . . . . . 15 12.2. MIB modules required for IMPORTS . . . . . . . . . . . . . 15 13. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 15 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 17.1. Normative References . . . . . . . . . . . . . . . . . . . 35 17.2. Informative References . . . . . . . . . . . . . . . . . . 36 17.3. URL References . . . . . . . . . . . . . . . . . . . . . . 37 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 37 Verges Expires August 27, 2011 [Page 3] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 1. Introduction This memo defines a portion 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 Energy Management Framework [EMAN-FMWK], which in turn, is based on Requirements for Power Monitoring [EMAN-REQ]. This module's special focus is on monitoring energy-aware networks and devices. The module addresses enumeration of the entities being managed, reporting of energy data, control of the power state, mapping to physical and logical (business) contexts, and monitoring of self-reported health. 2. Energy Management Document Overview The EMAN standards provides network administrators with energy management. This document is based on Energy Management Framework [EMAN-FMWK], which in turn, is based on Requirements for Power Monitoring [EMAN-REQ]. The EMAN-MIB contains five key subschemas which are given their own references for discussion purposes: EMAN-CORE-MIB, EMAN-DATA-MIB, EMAN-CONTROL-MIB, EMAN-CONTEXT-MIB, and EMAN-LLDP-MIB. +---------------+ | EMAN-CORE-MIB | +---------------+ | +---------------+ | +------------------+ | EMAN-DATA-MIB |---------+---------| EMAN-CONTROL-MIB | +---------------+ | +------------------+ | +---------------+ | +------------------+ | EMAN-LLDP-MIB |---------+---------| EMAN-CONTEXT-MIB | +---------------+ +------------------+ Figure 1 The Core MIB [EMAN-CORE-MIB] described in Section 6 contains the core list of entities that are to be managed using the rest of this framework. It is separated from any role-specific functionality so that vendor-specific extensions and other future extensions may be developed independent from the core index. The Energy Data MIB [EMAN-DATA-MIB] described in Section 7 contains the role-specific extensions needed to report power and energy usage for an entity. This MIB provides the detailed properties of the Verges Expires August 27, 2011 [Page 4] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 actual energy rate (power) and of accumulated energy, along with the power quality. EMAN-DATA-MIB is a sparse-table extension to EMAN- CORE-MIB. The Energy Control MIB [EMAN-CONTROL-MIB] described in Section 8 contains the role-specific extensions needed to monitor and control power states for an entity. This MIB provides the current power state, power state transitions, and power state statistics. The Energy Context MIB [EMAN-CONTEXT-MIB] described in Section 9 contains the role-specific extensions needed to establish physical and logical (business) context for an entity. This MIB provides a generic mechanism to create a classification category, map entities into the proper categories, and associate pricing data with each category. The Energy LLDP MIB [EMAN-LLDP-MIB] described in Section 11 contains the role-specific extensions needed to link the entity with its associated Link Layer Discovery Protocol (LLDP) information. 3. Relationship to Other EMAN Proposals At the time of this writing, two other MIB drafts are being considered by the EMAN working group: [PARELLO]/[CLAISE] and [QUITTEK]. The MIB proposed here combines aspects of both in a more generic structure, while still meeting all requirements of [EMAN-REQ]. (For the purposes of this explanation, [PARELLO] and [CLAISE] are referenced as a single group of tightly related drafts that must be considered together.) In [PARELLO] and [CLAISE], the primary structure is centered around pmTable. Entities are defined by separate rows in the table structure, but the structure tightly couples the entity definition with context-related attributes of the entity's use. For example: o pmDomainName defines a single context for an entity. While the intention is that pmDomainName primarily describe a physical relationship that the entity may share with other entities (like being connected to the same branch circuit), it does not allow for other groupings due to the one-to-one relationship between pmDomainName and pmIndex. If such groupings were added at a later time using a sparse table extension, many attributes (like pmRoleDescription, pmKeywords, and pmImportance) would need to be duplicated in the sparse table, resulting in the same type of information living in separate OID subtrees. o The LLDP information defined by pmLldpPortNumber, pmEthPortIndex, and pmEthPortGrpIndex are very specific to networking equipment Verges Expires August 27, 2011 [Page 5] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 such as routers and switches. Since such information is optional for other equipment (like servers and intelligent power distribution units), the LLDP properties should be split into a separate sparse table to make the coupling looser and increase MIB maintainability as it continues to be expanded in the future. o The control mechanism defined by pmPowerLevelTable forces a single interface for power control, on an arbitrary 0-12 scale. While the authors have maintained on the mailing list that the pmPowerLevelMappingTable can be used to map other mechanisms such as ACPI or DMTF, such a structure forces the end user to map their own use onto the schema, rather than the schema supporting the operation desired by the end user. o The complex power data reporting structure defined by pmACPwrQualityTable, pmACPwrQualityPhaseTable, etc. attempts to link too much context awareness of the data into the schema itself, resulting in a bloated and cumbersome system. If an end user wanted to obtain data updates, several OID trees would need to be walked simultaneously in order to fully understand the data. [QUITTEK] assumes that all entities that will ever be modeled must be physical in nature, so uses ENTITY-MIB as a core model. This results in an extremely simple MIB schema that cannot adequately meet the requirements of network switches that report power on behalf of PoE devices or intelligent power distribution units (iPDU's). For example: o Given ENTITY-MIB's natural structure to enumerate both physical and logical entities of a system, the attraction to re-use this structure is apparent. However, ENTITY-MIB distinguishes physical and logical entities by containing two MIB tables, one for each category. The result is that sparse table extensions (such as powerStateTable and energyConsumpTable) must choose whether to link to entPhysicalTable or entLogicalTable. For a server or other devices that are relatively simple in power distribution design, all components being modeled are generally physical, so entPhysicalTable makes sense. However, for intelligent power distribution units, a major limitation is reached. Some iPDU's, for example, support "ganging" of outlets into a logical entity for management purposes. To represent such a collection in entPhysicalTable would misuse the core rationale behind entPhysicalTable. One solution that would use ENTITY-MIB to solve this problem would be to have two of everything in [QUITTEK], one for physical entities and one for logical entities. But this is not an ideal solution, as it both burdens the end user and the implementing vendor. Verges Expires August 27, 2011 [Page 6] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 This draft attempts to correct those problems through the use of several specific changes: 1. Define both physical and logical entities that are power-related in a standalone table. If a power entity should be related to an entity defined by ENTITY-MIB, the value of the index can be placed into emanEntityPhysicalId or emanEntityLogicalId as appropriate; otherwise, the value should be zero for the unused column(s). 2. Similar to [QUITTEK], sparse tables that have a narrowly defined scope extend off this core entity list. This allows for an end user to walk a single sparse table to obtain all data updates related to one group: data, control/state, LLDP information, etc. 3. Power entities are defined as one of two types: simple or complex. A simple entity can be fully described by a single data row or control/state row. A complex entity can be deconstructed into multiple simple entities. An example of a simple entity would be a single phase AC power meter, while a complex entity would be a three phase AC power meter. (A three phase meter can be thought of as being comprised by three or four individual single phase meters with phase relationship information added.) The result is a simplified MIB tree with a single "data" tree and a single "control" tree that can be accessed and understood with a single table walk. 4. Multiple control mechanisms are supported so that end users can think in whatever terms are familiar to them. For example, if an end user is more familiar with ACPI levels than DMTF Power State levels, they can use the emanAcpiControl object. If they work more with the DMTF, they can use the emanDmtfControl object. Or if they think more in terms of a percentage scale, they can use the emanPercentageControl object. It is up to the implementing vendor to figure out how to relate these different control mechanisms with each other in a way that makes sense to the agent's core purpose. Exposing different interfaces only simplifies the process for the end user. 5. Context for an entity is not considered a core concept for defining what an entity is, but is instead a sparse table extension. Both physical contexts (like branch circuits) and logical contexts (like ownership by a common business unit) are enabled in the same context tree, allowing the user to access a single table that contains all of the context information, regardless of the context type. The end result is a design which has low coupling and high cohesion, Verges Expires August 27, 2011 [Page 7] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 that will allow the IETF to continue to grow and expand it as the Smart Grid and other power-related technologies continue to mature and develop. 4. 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 a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 5. Conventions 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]. 6. Structure of the EMAN-CORE-MIB Module The primary structure in EMAN-CORE-MIB is the emanEntityTable. This structure comprises a list of entities that are to be managed under the EMAN schemas. The list is hierarchical in nature, where entities may have parent/child relationships. 6.1. Textual Conventions 6.1.1. EmanEntityRole This textual convention specifies the type of entity being described. For example, the entity can either be a meter reporting on behalf of an another device or a consumer reporting its own use. Other entity types may be defined as future extensions. 6.1.2. EmanEntityCapabilities This textual convention specifies the EMAN-specific capabilities that the entity is capable of supporting, as a SMIv2 BITS extension. Each role-specific extension is represented as one bit, and entities which support a role extension must advertise that capability by setting the corresponding bit. Verges Expires August 27, 2011 [Page 8] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 6.1.3. Thousandths This textual convention specifies a fixed point decimal value up to a 10^(-3) precision (0.001). Based on an Integer32 data type, this textual convention supports from -2,147,483.647 to +2,147,483.647. 6.1.4. UnitMultiplier This textual convention is an integer value that represents the IEEE 61850 Annex A units multiplier associated with the integer units used to measure the power or energy. For example, a UnitMultiplier of -3 corresponds with a unit scale of "milli", 10^-3. When used in combination with a Thousandths TC value of 1234, for example, a UnitMultiplier of unit(0) would result in the value being equivalent to the original intent behind the Thousandths TC (1.234). Changing the UnitMultiplier to milli(-3) would result in the value being equivalent to 0.001234. Likewise, changing to kilo(3) would result in the value being 1,234.000. 6.2. The Notifications Subtree EMAN-CORE-MIB implements no notifications at this time. 6.3. The Table Structures The heart of the entire role-specific extension schema is the list of entities in emanEntityTable. An entity in this list may be simple (described in and of itself) or complex (described by several child entities.) For example, consider a standard computer workstation with a single AC/DC power supply. The emanEntityTable to describe this scenario might contain the following: +-----+-----------------+-------------+--------+ | Idx | Name | Type | Parent | +-----+-----------------+-------------+--------+ | 1 | PC Power Supply | consumer(1) | 0 | +-----+-----------------+-------------+--------+ Table 1: Simple entities in emanEntityTable Complex entities can be described using the same schema by describing a set of simple child entities. For example, consider an ingellient power distribution unit with one three-phase input cord and three Verges Expires August 27, 2011 [Page 9] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 single-phase banks of two outlets each: +-----+--------------------------+-------------+--------+ | Idx | Name | Type | Parent | +-----+--------------------------+-------------+--------+ | 1 | Internal NIC | consumer(0) | 0 | | 2 | Input Cord 1 - 3PH DELTA | meter(1) | 0 | | 3 | Input Cord 1 - Line A | meter(1) | 2 | | 4 | Input Cord 1 - Line B | meter(1) | 2 | | 5 | Input Cord 1 - Line C | meter(1) | 2 | | 6 | Bank 1 - Line AB | meter(1) | 0 | | 7 | Bank 2 - Line BC | meter(1) | 0 | | 8 | Bank 3 - Line CA | meter(1) | 0 | | 9 | Outlet 1 | meter(1) | 0 | | 10 | Outlet 2 | meter(1) | 0 | | ... | ... | ... | ... | +-----+--------------------------+-------------+--------+ Table 2: Complex entities in emanEntityTable In the above example, note how the complex entity of the three-phase input cord is subdivided into separate simple entities that are the individual lines in the input cord. This allows each entity (the input cord bundle and each of its lines) to be addressed separately, if desired, by role-specific extensions and enterprise-specific extensions. In deciding whether an entity is simple or complex, an implementing vendor should consider the impact of using either type on the role- specific subschemas that the entity will implement. For example, a server can be modeled as either a simple entity (the server as a single, simple entity) or as a complex entity (the server as an aggregation of power supplies, internal batteries, processors, etc.) Both choices are equally valid, and the implementing agent should choose the one that makes the most sense for the end users that it serves. Top-level entities should set their emanEntityParent to zero (0) if the entity has no parent. The emanEntityParent column refers to the emanEntityIndex of the parent entity. If a row is added or deleted, the corresponding role-specific extensions should likewise update to reflect the new state. 7. Structure of the EMAN-DATA-MIB Module EMAN-DATA-MIB builds on EMAN-CORE-MIB by providing power and energy data for entities that support it. Entities which implement EMAN- Verges Expires August 27, 2011 [Page 10] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 DATA-MIB must set the instant(0) and/or historical(1) capabilities bits appropriately. 7.1. Textual Conventions PhaseOffset specifies the phase angle offset of the entity's voltage wave relative to zero (0) degrees. In a typical three-phase system, Line AN is 0 degrees, BN is 120 degrees, and CN is 240 degrees, for example. Negative values can indicate a positive or negative rotation. DataAccuracy specifies the accuracy of the data as a percentage. This data type is based on the IEC classification of power meters (2.0%, 1.0%, 0.5%, etc.) A DataAccuracy value of 150 corresponds with an accuracy of 1.5%. DataCaliber specifies the caliber of the data, whether it is unknown(0) or actual(1) or estimated(2) or presumed(3). If the data is measured, for example, the caliber is "actual." 7.2. The Notifications Subtree EMAN-DATA-MIB implements no notifications at this time. 7.3. The Table Structures The data represented in emanInstantDataTable represents the instantaneous data for an entity. To use this table, an implementing entity must set the instant(0) capability bit. All data in this table is "normalized" to single-phase AC or DC format to ensure consistency in the data returned and simplicity of third-party systems that will be using the data returned by the EMAN agent. For example, consider modeling the instantaneous data for the three- phase input cord entity described earlier in Table 2: +-----+--------------------------+---------+---------+--------------+ | Idx | (Name) | Voltage | Current | Active Power | +-----+--------------------------+---------+---------+--------------+ | 2 | Input Cord 1 - 3PH DELTA | 208.830 | 33.481 | 6,991.848 | | 3 | Input Cord 1 - Line A | 205.350 | 14.900 | 3,059.715 | | 4 | Input Cord 1 - Line B | 212.031 | 7.455 | 1,580.691 | | 5 | Input Cord 1 - Line C | 209.110 | 11.245 | 2,351.442 | +-----+--------------------------+---------+---------+--------------+ The complex input cord data entry reflects the proper three-phase power and the single-phase-equivalent voltage/current. Verges Expires August 27, 2011 [Page 11] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 Table 3: Instantaneous data for complex entities If an entity does not support one of the data types (ex. harmonic distortion), that column may optionally be ommitted for the entity's row. 8. Structure of the EMAN-CONTROL-MIB Module EMAN-CONTROL-MIB builds on EMAN-CORE-MIB by providing power state control for entities that support it. Since several different power state mechanisms are currently in use on various systems, EMAN- CONTROL-MIB offers a way for an entity to interface with all of the mechanisms, allowing both the implementing agent and end user the flexibility to choose the best mechanism for their purpose. Entities which implement EMAN-CONTROL-MIB must set the acpi(2), percent(3) and/or dmtf(7) capabilities bits appropriately. 8.1. Textual Conventions AcpiState specifies the seven power usage states defined by the Advanced Configuration and Power Interface standard [ACPI]. Percentage specifies a gradiated scale from 0% (off) to 100% (full- power). DmtfPowerState specifies the fifteen power usage states defined by the Distributed Management Task Force [DSP1027]. 8.2. The Notifications Subtree EMAN-CONTROL-MIB implements no notifications at this time. 8.3. The Table Structures The control mechanisms in emanControlTable allow a end user to query and change the power state of the entity. To use emanAcpiControl, an implementing entity must set the acpi(2) capability bit. To use emanPercentageControl, an implementing entity must set the percentage(3) capability bit. To use emanDmtfControl, an implementing entity must set the dmtf(7) capability bit. With one exception, the implementing entity will decide how to map the different control mechanisms to each other, based on what is appropriate for the entity. For example, consider a standard network workstation: Verges Expires August 27, 2011 [Page 12] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 +------+------------+ | ACPI | Percentage | +------+------------+ | g0s0 | 100% | | g1s1 | 75% | | g1s2 | 66% | | g1s3 | 30% | | g1s4 | 1% | | g2s5 | 5% | | g3 | 0% | +------+------------+ Table 4: Mapping of ACPI and Percentage Control Mechanisms for Workstation XYZ The flexibility of supporting several different control mechanisms at the same time means that vendors who implement EMAN-CONTROL-MIB should carefully consider the mapping for the various mechanisms for their product. The exception is when an entity implements both acpi(2) and dmtf(7). The link between these states defined in [DSP1027] Table 3 must be observed to ensure entity compliance to the ACPI and DMTF standards. 9. Structure of the EMAN-CONTEXT-MIB Module EMAN-CONTEXT-MIB builds on EMAN-CORE-MIB by providing context behind the power use of an entity. Entities which implement EMAN-CONTEXT- MIB must set the context(5) capability bit appropriately. 9.1. Textual Conventions ContextType specifies what type of context is being defined -- physical(1) or logical(2). A physical context is one where the entities are related electrically, like a common branch circuit or transformer. A logical context is one where the entities are related in some other way, such as ownership or intended use. 9.2. The Notifications Subtree EMAN-CONTEXT-MIB implements no notifications at this time. 9.3. The Table Structures emanContextTable is a list of all contexts known by the agent. This allows contexts to be listed once and reused by several entities if such a mapping makes sense. emanContextMappingTable creates a link between contexts and entities. Verges Expires August 27, 2011 [Page 13] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 It uses a single entry, emanContextMappingRowStatus, to determine whether the mapping is active. Mappings can be added through 'createAndGo' or 'createAndWait' and can be removed through 'destroy'. 10. Structure of the EMAN-HEALTH-MIB Module 10.1. Textual Conventions TBD 10.2. The Notifications Subtree EMAN-HEALTH-MIB implements no notifications at this time. 10.3. The Table Structures TBD 11. Structure of the EMAN-LLDP-MIB Module 11.1. Textual Conventions The various textual conventions implemented by this MIB are fully described in the MIB itself. 11.2. The Notifications Subtree EMAN-LLDP-MIB implements no notifications at this time. 11.3. The Table Structures emanLldpTable provides LLDP-specific information for an entity. 12. Relationship to Other MIB Modules [[anchor29: [TEMPLATE TODO]: The narrative part should include a section that specifies the relationship (if any) of the MIB modules contained in this internet drafts to other standards, particularly to standards containing other MIB modules. If the MIB modules defined by the specification import definitions from other MIB modules or are always implemented in conjunction with other MIB modules, then those facts should be noted in the narrataive section, as should any special interpretations of objects in other MIB modules. Note that citations may NOT be put into the MIB module portions of the internet draft, but documents used for Imported items are Normative references, so the citations should exist in the narrative section of the internet draft. The preferred way to fill in a REFERENCE clause Verges Expires August 27, 2011 [Page 14] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 in a MIB module is of the form: "Guidelines for Writing an IANA Considerations Section in RFCs", RFC2434, section 2.3.]] 12.1. Relationship to the [TEMPLATE TODO] MIB [[anchor31: Example: The Interface MIB [RFC2863] requires that any MIB module which is an adjunct of the Interface MIB clarify specific areas within the Interface MIB. These areas were intentionally left vague in the Interface MIB to avoid over-constraining the MIB, thereby precluding management of certain media-types. Section 4 of [RFC2863] enumerates several areas which a media-specific MIB must clarify. The implementor is referred to [RFC2863] in order to understand the general intent of these areas.]] 12.2. MIB modules required for IMPORTS [[anchor33: [TEMPLATE TODO]: Citations are not permitted within a MIB module, but any module mentioned in an IMPORTS clause or document mentioned in a REFERENCE clause is a Normative reference, and must be cited someplace within the narrative sections. If there are imported items in the MIB module, such as Textual Conventions, that are not already cited, they can be cited in text here. Since relationships to other MIB modules should be described in the narrative text, this section is typically used to cite modules from which Textual Conventions are imported. Example: "The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], and IF-MIB [RFC2863]."]] 13. Definitions EMAN-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, mib-2 FROM SNMPv2-SMI SnmpAdminString FROM SNMP-FRAMEWORK-MIB TEXTUAL-CONVENTION, RowStatus, TimeInterval, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF PhysicalIndexOrZero Verges Expires August 27, 2011 [Page 15] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 FROM ENTITY-MIB; eman MODULE-IDENTITY LAST-UPDATED "201102110000Z" ORGANIZATION "Cyber Switching, Inc." CONTACT-INFO "http://www.cyberswitching.com" DESCRIPTION "The MIB for reporting and managing power usage of networked entities through SNMP." REVISION "201102110000Z" DESCRIPTION "Initial draft release." ::= { mib-2 XXX } EmanEntityRole ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the type of entity." SYNTAX INTEGER { meter(0), consumer(1) } EmanEntityCapabilities ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the capabilities of the entity." SYNTAX BITS { instant(0), -- instant data reporting historical(1), -- historical data reporting acpi(2), -- ACPI-based control percent(3), -- Percentage-based control health(4), -- health reporting context(5), -- context awareness lldp(6), -- LLDP awareness dmtf(7) -- DMTF Power State control } Thousandths ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-3" STATUS current DESCRIPTION "Specifies a value as 10^(-3) precision." SYNTAX Integer32 UnitMultiplier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Unit Multiplier is an integer value that represents the IEEE 61850 Annex A units multiplier associated with the integer units used to measure the power or energy. For example, when used with pmPowerUnitMultiplier, Verges Expires August 27, 2011 [Page 16] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 -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 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 } emanCore OBJECT IDENTIFIER ::= { eman 1 } emanEntityTable OBJECT-TYPE SYNTAX SEQUENCE OF EmanEntityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of all power entities being managed." ::= { emanCore 1 } emanEntityEntry OBJECT-TYPE SYNTAX EmanEntityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A power entity." INDEX { emanEntityIndex } ::= { emanEntityTable 1 } EmanEntityEntry ::= SEQUENCE { emanEntityIndex Unsigned32, emanEntityName SnmpAdminString, emanEntityAlias SnmpAdminString, emanEntityType EmanEntityRole, Verges Expires August 27, 2011 [Page 17] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 emanEntityCapabilities EmanEntityCapabilities, emanEntityParent Unsigned32, emanEntityPhysicalId PhysicalIndexOrZero, emanEntityLogicalId Integer32 } emanEntityIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the entry in the table." ::= { emanEntityEntry 1 } emanEntityName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the entity." ::= { emanEntityEntry 2 } emanEntityAlias OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "The user-defined alias of the entity." ::= { emanEntityEntry 3 } emanEntityType OBJECT-TYPE SYNTAX EmanEntityRole MAX-ACCESS read-only STATUS current DESCRIPTION "The type of entity being modeled." ::= { emanEntityEntry 4 } emanEntityCapabilities OBJECT-TYPE SYNTAX EmanEntityCapabilities MAX-ACCESS read-only STATUS current DESCRIPTION "A list of capabilities supported by this entity." ::= { emanEntityEntry 5 } emanEntityParent OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The index of the entity's parent in the table." ::= { emanEntityEntry 6 } Verges Expires August 27, 2011 [Page 18] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 emanEntityPhysicalId OBJECT-TYPE SYNTAX PhysicalIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The index of the entity's entry in entPhysicalTable, or zero (0) if unused." ::= { emanEntityEntry 7 } emanEntityLogicalId OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The index of the entity's entry in entLogicalTable, or zero (0) if unused." ::= { emanEntityEntry 8 } -- -- EMAN Data Add-On -- emanData OBJECT IDENTIFIER ::= { eman 2 } PercentageDistortion ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-3" STATUS current DESCRIPTION "Specifies the distortion as a tenth of a percent (0.1%)." SYNTAX Unsigned32 (0..1000) PhaseOffset ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Specifies the phase offset." SYNTAX Integer32 (-360..360) DataAccuracy ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-4" STATUS current DESCRIPTION "Specifies the data accuracy as a hundredth of a percent (ex. 0.0001 or 0.01%)." SYNTAX Integer32 (-10000..10000) DataCaliber ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the data caliber." SYNTAX INTEGER { unknown(0), Verges Expires August 27, 2011 [Page 19] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 actual(1), estimated(2), presumed(3) } PowerType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the type of power." SYNTAX INTEGER { unknown(0), ac(1), dc(2) } EmanDataType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the data type to use for an alert comparison." SYNTAX INTEGER { unknown(0), undefined(1), current(2), voltage(3), activepower(4), reactivepower(5), apparentpower(6), frequency(7), powerfactor(8) } ComparisonOperator ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies a comparison operator." SYNTAX INTEGER { unknown(0), undefined(1), equal(2), notequal(3), greater(4), greaterorequal(5), less(6), lessorequal(7) } AlertSeverity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies a severity level for an alert." SYNTAX INTEGER { Verges Expires August 27, 2011 [Page 20] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 emergency(0), alert(1), critical(2), error(3), warning(4), notice(5), informational(6), debug(7) } emanInstantDataTable OBJECT-TYPE SYNTAX SEQUENCE OF EmanInstantDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A sparse table of an entity's power data." ::= { emanData 1 } emanInstantDataEntry OBJECT-TYPE SYNTAX EmanInstantDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The real-time power data for an entity." INDEX { emanEntityIndex } ::= { emanInstantDataTable 1 } EmanInstantDataEntry ::= SEQUENCE { emanInstantAmperage Thousandths, emanInstantVoltage Thousandths, emanInstantPowerUnit UnitMultiplier, emanInstantActivePower Thousandths, emanInstantReactivePower Thousandths, emanInstantApparentPower Thousandths, emanInstantPowerFactor Thousandths, emanInstantFrequency Thousandths, emanInstantHarmonicDistortion PercentageDistortion, emanInstantPhaseOffset PhaseOffset } emanInstantAmperage OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only STATUS current DESCRIPTION "The instantaneous RMS amperage." ::= { emanInstantDataEntry 1 } emanInstantVoltage OBJECT-TYPE SYNTAX Thousandths Verges Expires August 27, 2011 [Page 21] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 MAX-ACCESS read-only STATUS current DESCRIPTION "The instantaneous RMS voltage." ::= { emanInstantDataEntry 2 } emanInstantPowerUnit OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "The unit scale used for emanInstantActivePower, emanInstantReactivePower, and emanInstantApparentPower." ::= { emanInstantDataEntry 3 } emanInstantActivePower OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only STATUS current DESCRIPTION "The instantaneous wattage." ::= { emanInstantDataEntry 4 } emanInstantReactivePower OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only STATUS current DESCRIPTION "The instantaneous volt-amps (reactive)." ::= { emanInstantDataEntry 5 } emanInstantApparentPower OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only STATUS current DESCRIPTION "The instantaneous volt-amps." ::= { emanInstantDataEntry 6 } emanInstantPowerFactor OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only STATUS current DESCRIPTION "The instantaneous power factor." ::= { emanInstantDataEntry 7 } emanInstantFrequency OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only STATUS current DESCRIPTION "The instantaneous frequency." ::= { emanInstantDataEntry 8 } Verges Expires August 27, 2011 [Page 22] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 emanInstantHarmonicDistortion OBJECT-TYPE SYNTAX PercentageDistortion MAX-ACCESS read-only STATUS current DESCRIPTION "The instantaneous harmonic distortion." ::= { emanInstantDataEntry 9 } emanInstantPhaseOffset OBJECT-TYPE SYNTAX PhaseOffset MAX-ACCESS read-only STATUS current DESCRIPTION "The instantaneous phase offset." ::= { emanInstantDataEntry 10 } emanDataPropertyTable OBJECT-TYPE SYNTAX SEQUENCE OF EmanDataPropertyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A sparse table of an entity's data attributes." ::= { emanData 2 } emanDataPropertyEntry OBJECT-TYPE SYNTAX EmanDataPropertyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The power data attributes for an entity." INDEX { emanEntityIndex } ::= { emanDataPropertyTable 1 } EmanDataPropertyEntry ::= SEQUENCE { emanDataAccuracy DataAccuracy, emanDataCaliber DataCaliber, emanNameplatePowerUnit UnitMultiplier, emanNameplateMaxPower Thousandths, emanNameplateMaxCurrent Thousandths, emanNameplateMaxVoltage Thousandths, emanNameplateMinPower Thousandths, emanNameplateMinCurrent Thousandths, emanNameplateMinVoltage Thousandths, emanPowerType PowerType } emanDataAccuracy OBJECT-TYPE SYNTAX DataAccuracy MAX-ACCESS read-only STATUS current DESCRIPTION "The accuracy of the power data reported." Verges Expires August 27, 2011 [Page 23] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 ::= { emanDataPropertyEntry 1 } emanDataCaliber OBJECT-TYPE SYNTAX DataCaliber MAX-ACCESS read-only STATUS current DESCRIPTION "The caliber of the power data reported." ::= { emanDataPropertyEntry 2 } emanNameplatePowerUnit OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "The unit scale used for emanNameplate[Max|Min]Power." ::= { emanDataPropertyEntry 3 } emanNameplateMaxPower OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum nameplate power rating." ::= { emanDataPropertyEntry 4 } emanNameplateMaxCurrent OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum nameplate current rating." ::= { emanDataPropertyEntry 5 } emanNameplateMaxVoltage OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum nameplate voltage rating." ::= { emanDataPropertyEntry 6 } emanNameplateMinPower OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum nameplate power rating." ::= { emanDataPropertyEntry 7 } emanNameplateMinCurrent OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only Verges Expires August 27, 2011 [Page 24] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 STATUS current DESCRIPTION "The minimum nameplate current rating." ::= { emanDataPropertyEntry 8 } emanNameplateMinVoltage OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum nameplate voltage rating." ::= { emanDataPropertyEntry 9 } emanPowerType OBJECT-TYPE SYNTAX PowerType MAX-ACCESS read-only STATUS current DESCRIPTION "The power type for the entity." ::= { emanDataPropertyEntry 10 } emanDataAlertTable OBJECT-TYPE SYNTAX SEQUENCE OF EmanDataAlertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A sparse table of an entity's data alerts." ::= { emanData 3 } emanDataAlertEntry OBJECT-TYPE SYNTAX EmanDataAlertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The power data alert for an entity." INDEX { emanEntityIndex, emanDataAlertIndex } ::= { emanDataAlertTable 1 } EmanDataAlertEntry ::= SEQUENCE { emanDataAlertIndex Unsigned32, emanDataAlertName SnmpAdminString, emanDataAlertEnabled TruthValue, emanDataAlertCompareOn EmanDataType, emanDataAlertComparison ComparisonOperator, emanDataAlertValue Thousandths, emanDataAlertUnit UnitMultiplier, emanDataAlertDelay TimeInterval, emanDataAlertSeverity AlertSeverity, emanDataAlertRowStatus RowStatus } emanDataAlertIndex OBJECT-TYPE Verges Expires August 27, 2011 [Page 25] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the alert condition." ::= { emanDataAlertEntry 1 } emanDataAlertName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the alert condition." ::= { emanDataAlertEntry 2 } emanDataAlertEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "The flag to indicate whether the alert is enabled." ::= { emanDataAlertEntry 3 } emanDataAlertCompareOn OBJECT-TYPE SYNTAX EmanDataType MAX-ACCESS read-create STATUS current DESCRIPTION "The data type to compare against for the alert." ::= { emanDataAlertEntry 4 } emanDataAlertComparison OBJECT-TYPE SYNTAX ComparisonOperator MAX-ACCESS read-create STATUS current DESCRIPTION "The comparison operation to perform for the alert." ::= { emanDataAlertEntry 5 } emanDataAlertValue OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-create STATUS current DESCRIPTION "The value to compare against for the alert." ::= { emanDataAlertEntry 6 } emanDataAlertUnit OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "The unit scale used for emanDataAlertValue." ::= { emanDataAlertEntry 7 } Verges Expires August 27, 2011 [Page 26] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 emanDataAlertDelay OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-create STATUS current DESCRIPTION "The time delay to wait after the alert condition is triggered but before triggering the alert." ::= { emanDataAlertEntry 8 } emanDataAlertSeverity OBJECT-TYPE SYNTAX AlertSeverity MAX-ACCESS read-only STATUS current DESCRIPTION "The severity of the alert when triggered." ::= { emanDataAlertEntry 9 } emanDataAlertRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The mechanism to manage dynamic alert entries." ::= { emanDataAlertEntry 10 } emanDataTrapVariables OBJECT IDENTIFIER ::= { emanData 4 } emanDataAlertTriggeredValue OBJECT-TYPE SYNTAX Thousandths MAX-ACCESS read-only STATUS current DESCRIPTION "The actual value when the alert condition triggered." ::= { emanDataTrapVariables 1 } emanDataTraps OBJECT IDENTIFIER ::= { emanData 5 } emanDataTrapsReversible OBJECT IDENTIFIER ::= { emanDataTraps 0 } emanDataAlertNotification NOTIFICATION-TYPE OBJECTS { emanDataAlertName, emanDataAlertSeverity, emanDataAlertValue, emanDataAlertUnit, emanDataAlertTriggeredValue } STATUS current Verges Expires August 27, 2011 [Page 27] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 DESCRIPTION "Sent to notify a third-party about an alert condition triggering." ::= { emanDataTrapsReversible 1 } -- -- EMAN Control Add-On -- emanControl OBJECT IDENTIFIER ::= { eman 5 } AcpiState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the states specified by the ACPI standard." SYNTAX INTEGER { g0s0(0), g1s1(1), g1s2(2), g1s3(3), g1s4(4), g2s5(5), g3(6) } DmtfPowerState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the states specified by the DMTF DSP1027 standard. The state powercyclehard(9) is a transition state for offhard(6) followed by on(2), so is a write-only operation to simplify the SNMP client interaction with an agent." SYNTAX INTEGER { on(2), sleeplight(3), sleepdeep(4), powercyclesoft(5), offhard(6), hibernate(7), offsoft(8), powercyclehard(9), masterbusreset(10), diaginterrupt(11), offsoftgraceful(12), offhardgraceful(13), masterbusresetgraceful(14), powercycleoffsoftgraceful(15), powercycleoffhardgraceful(16) Verges Expires August 27, 2011 [Page 28] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 } Percentage ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Specifies a percentage value." SYNTAX Unsigned32 (0..100) emanControlTable OBJECT-TYPE SYNTAX SEQUENCE OF EmanControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A sparse table of all the entity's control mechanisms." ::= { emanControl 1 } emanControlEntry OBJECT-TYPE SYNTAX EmanControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The control mechanisms for an entity." INDEX { emanEntityIndex } ::= { emanControlTable 1 } EmanControlEntry ::= SEQUENCE { emanAcpiControl AcpiState, emanPercentageControl Percentage, emanDmtfControl DmtfPowerState } emanAcpiControl OBJECT-TYPE SYNTAX AcpiState MAX-ACCESS read-write STATUS current DESCRIPTION "The current ACPI state of the entity." ::= { emanControlEntry 1 } emanPercentageControl OBJECT-TYPE SYNTAX Percentage MAX-ACCESS read-write STATUS current DESCRIPTION "The current state of the entity as expressed by a percentage of its full running capacity." ::= { emanControlEntry 2 } emanDmtfControl OBJECT-TYPE SYNTAX DmtfPowerState Verges Expires August 27, 2011 [Page 29] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 MAX-ACCESS read-write STATUS current DESCRIPTION "The current DMTF power state of the entity." ::= { emanControlEntry 3 } -- -- EMAN Context Add-On -- emanContext OBJECT IDENTIFIER ::= { eman 4 } ContextType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the type of context." SYNTAX INTEGER { physical(1), logical(2) } emanContextTable OBJECT-TYPE SYNTAX SEQUENCE OF EmanContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A sparse table of all the entity's usage contexts." ::= { emanContext 1 } emanContextEntry OBJECT-TYPE SYNTAX EmanContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A physical or logical context to describe the power usage of an entity." INDEX { emanContextIndex } ::= { emanContextTable 1 } EmanContextEntry ::= SEQUENCE { emanContextIndex Unsigned32, emanContextName SnmpAdminString, emanContextType ContextType } emanContextIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index for the context of the entity." Verges Expires August 27, 2011 [Page 30] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 ::= { emanContextEntry 1 } emanContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The identifier for the context of the entity." ::= { emanContextEntry 2 } emanContextType OBJECT-TYPE SYNTAX ContextType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the context." ::= { emanContextEntry 3 } emanContextMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF EmanContextMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A sparse table that maps an entity to a context." ::= { emanContext 3 } emanContextMappingEntry OBJECT-TYPE SYNTAX EmanContextMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A simple mapping mechanism to link a context to an entity." INDEX { emanContextIndex, emanEntityIndex } ::= { emanContextMappingTable 1 } EmanContextMappingEntry ::= SEQUENCE { emanContextMappingRowStatus RowStatus } emanContextMappingRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object facilitates the addition and deletion of a conceptual row mapping in the table." ::= { emanContextMappingEntry 1 } -- -- EMAN LLDP Add-On -- Verges Expires August 27, 2011 [Page 31] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 emanLldp OBJECT IDENTIFIER ::= { eman 6 } LldpUuid ::= TEXTUAL-CONVENTION DISPLAY-HINT "16a" STATUS current DESCRIPTION "Specifies a Universally Unique Identifier." REFERENCE "IETF RFC 4122" SYNTAX OCTET STRING (SIZE (16)) LldpPortIndexOrZero ::= 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) LldpPortGroupIndexOrZero ::= 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 Verges Expires August 27, 2011 [Page 32] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 (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) emanLldpTable OBJECT-TYPE SYNTAX SEQUENCE OF EmanLldpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A sparse table of all the entity's LLDP information." ::= { emanLldp 1 } emanLldpEntry OBJECT-TYPE SYNTAX EmanLldpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The LLDP information for an entity." INDEX { emanEntityIndex } ::= { emanLldpTable 1 } EmanLldpEntry ::= SEQUENCE { emanLldpUuid LldpUuid, emanLldpPhysicalIndex PhysicalIndexOrZero, emanLldpPortIndex LldpPortIndexOrZero, emanLldpPortGroupIndex LldpPortGroupIndexOrZero, emanLldpPort LldpPortNumberOrZero } emanLldpUuid OBJECT-TYPE SYNTAX LldpUuid MAX-ACCESS read-only STATUS current DESCRIPTION "The UUID of the entity." ::= { emanLldpEntry 1 } emanLldpPhysicalIndex OBJECT-TYPE SYNTAX PhysicalIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The physical index of the entity in ENTITY-MIB::entPhysicalTable." Verges Expires August 27, 2011 [Page 33] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 ::= { emanLldpEntry 2 } emanLldpPortIndex OBJECT-TYPE SYNTAX LldpPortIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The port index of the entity." ::= { emanLldpEntry 3 } emanLldpPortGroupIndex OBJECT-TYPE SYNTAX LldpPortGroupIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The port group index of the entity." ::= { emanLldpEntry 4 } emanLldpPort OBJECT-TYPE SYNTAX LldpPortNumberOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The port number of the entity." ::= { emanLldpEntry 5 } END 14. Security Considerations There are a number of management objects defined in this MIB module 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. These are the tables and objects and their sensitivity/vulnerability: o emanControlTable - write access to the entries in this table allows an external user to change the power state of the entity. If not properly configured and secured, this could result in equipment being powered down accidentally or maliciously. Some of the readable objects in this MIB module (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. These are the tables and objects and their sensitivity/vulnerability: Verges Expires August 27, 2011 [Page 34] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 o None at this time 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 this MIB module. 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 this MIB module 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. 15. 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 ---------- ----------------------- eman { mib-2 XXX } 16. Contributors A special thanks to John Parello, Brad Schoening, and Bruce Nordman for their help and feedback during the development of this draft. 17. References 17.1. Normative References [RFC2119] Bradner, S., "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. Verges Expires August 27, 2011 [Page 35] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 [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. 17.2. Informative References [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005. [ENERGY-AWARE] Claise, B. and J. Parello, "Energy-aware Networks and Devices MIB", draft-ietf-eman-energy-aware-00 (work in progress), December 2010, . [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. Chandramouli, "Requirements for Power Monitoring", draft-ietf-eman-requirements-00 (work in progress), December 2010, . [EMAN-FMWK] Claise, B., Parello, J., Schoening, B., and J. Quittek, "Energy Management Framework", draft-ietf-eman-framework-00 (work in progress), December 2010, . [EMAN-AS] Tychon, E., Laherty, M., and B. Schoening, "Energy Management (EMAN) Applicability Statement", draft-tychon-eman-applicability-statement-00 (work in progress), October 2010, . [QUITTEK] Quittek, J., Winter, R., Dietz, T., and D. Dudkowski, "Definition of Managed Objects for Energy Management", draft-quittek-power-mib-01 (work in progress), April 2010, . Verges Expires August 27, 2011 [Page 36] Internet-Draft draft-verges-eman-separate-modules-mib-00 February 2011 [PARELLO] Parello, J. and B. Claise, "Energy-aware Networks and Devices MIB", draft-parello-eman-energy-aware-mib-00 (work in progress), October 2010, . [CLAISE] Claise, B., Chandramouli, M., Parello, J., and B. Schoening, "Power and Energy Monitoring MIB", draft-claise-energy-monitoring-mib-06 (work in progress), October 2010, . 17.3. URL References [idguidelines] IETF Internet Drafts editor, "http://www.ietf.org/ietf/1id-guidelines.txt". [idnits] IETF Internet Drafts editor, "http://www.ietf.org/ID-Checklist.html". [xml2rfc] XML2RFC tools and documentation, "http://xml.resource.org". [ops] the IETF OPS Area, "http://www.ops.ietf.org". [ietf] IETF Tools Team, "http://tools.ietf.org". [DSP1027] Distributed Management Task Force, "http:// www.dmtf.org/sites/default/files/standards/documents/ DSP1027_1.0.1.pdf", 2008. [ACPI] Advanced Configuration and Power Interface, "http://www.acpi.info/spec.htm", 2010. Appendix A. Acknowledgements TBD Author's Address Chris Verges Cyber Switching, Inc. 2050 Ringwood Avenue San Jose, California 95131 USA Phone: +1 408 436 9830 EMail: chrisv@cyberswitching.com Verges Expires August 27, 2011 [Page 37]