Network Working Group M. Chandramouli Internet-Draft Cisco Systems, Inc. Intended Status: Standards Track B. Schoening Expires: January 12, 2013 Independent Consultant J. Quittek T. Dietz NEC Europe Ltd. B. Claise Cisco Systems, Inc. July 11, 2012 Power and Energy Monitoring MIB draft-ietf-eman-energy-monitoring-mib-03 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 January 2013. Expires January 12, 2013 [Page 1] Internet-Draft July 2012 Copyright Notice Copyright (c) 2011 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", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction............................................... 3 2. The Internet-Standard Management Framework................. 4 3. Use Cases.................................................. 4 4. Terminology................................................ 5 5. Architecture Concepts Applied to the MIB Module........... 6 5.1. Energy Object Information............................... 13 5.2. Power State............................................. 13 5.2.1. Power State Set................................. 14 5.2.2. IEEE1621 Power State Set........................ 15 5.2.3. DMTF Power State Set............................ 15 5.2.4. EMAN Power State Set............................ 16 5.3. Energy Object Usage Information......................... 19 5.4. Optional Power Usage Characteristics.................... 20 5.5. Optional Energy Measurement............................. 21 Expires January 12, 2013 [Page 2] Internet-Draft July 2012 5.6. Fault Management........................................ 25 6. Discovery................................................. 25 7. Link with the other IETF MIBs............................. 26 7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB... 26 7.2. Link with the ENTITY-STATE MIB....................... 27 7.3. Link with the POWER-OVER-ETHERNET MIB................ 28 7.4. Link with the UPS MIB................................ 29 7.5. Link with the LLDP and LLDP-MED MIBs................. 30 8. Implementation Scenario................................... 30 9. Structure of the MIB...................................... 33 10. MIB Definitions.......................................... 34 11. Security Considerations.................................. 73 12. IANA Considerations...................................... 74 12.1. IANA Considerations for the MIB Modules................ 74 12.2. IANA Registration of new Power State Set............... 75 12.2.1. IANA Registration of the IEEE1621 Power State Set 75 12.2.2. IANA Registration of the DMTF Power State Set.... 75 12.2.3. IANA Registration of the EMAN Power State Set.... 76 12.3. Updating the Registration of Existing Power State Sets. 76 12. Contributors............................................. 77 13. Acknowledgment........................................... 77 14. Open Issues.............................................. 77 15. References............................................... 78 15.2. Normative References................................ 78 15.3. Informative References.............................. 78 1. Introduction This document defines a subset of the Management Information Base (MIB) for use in energy management of devices within or connected to communication networks. The MIB modules in this document are designed to provide a model for energy management, which includes monitoring for power state and energy consumption of networked elements. This MIB takes into account the Energy Management Framework [EMAN-FRAMEWORK], which in turn, is based on the Requirements for Energy Management[EMAN-REQ]. Energy management is applicable to devices in communication networks. Target devices for this specification include (but are not limited to): routers, switches, Power over Ethernet (PoE) endpoints, protocol gateways for building management systems, intelligent meters, home energy gateways, hosts and servers, sensor proxies, etc. Target devices and the use cases Expires January 12, 2013 [Page 3] Internet-Draft July 2012 for Energy Management are discussed in Energy Management Applicability Statement [EMAN-AS]. Where applicable, device monitoring extends to the individual components of the device and to any attached dependent devices. For example: A device can contain components that are independent from a power-state point of view, such as line cards, processor cards, hard drives. A device can also have dependent attached devices, such as a switch with PoE endpoints or a power distribution unit with attached endpoints. Devices and their sub-components may be characterized by the power-related attributes of a physical entity present in the ENTITY-MIB, even though the 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 (SMI). This memo specifies MIB modules that are compliant to 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 [EMAN-REQ]. The requirements in [EMAN- 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 [EMAN-REQ]. Several use cases for Energy Management have been identified in the Expires January 12, 2013 [Page 4] Internet-Draft July 2012 "Energy Management (EMAN) Applicability Statement" [EMAN-AS]. An illustrative example scenario is presented in Section 8. 4. Terminology Please refer to [EMAN-FRAMEWORK] for the definitions of the following terminology used in this draft. Device Component Energy Management Energy Management System (EnMS) ISO Energy Management System Energy Power Demand Power Characteristics Electrical Equipment Non-Electrical Equipment (Mechanical Equipment) Energy Object Electrical Energy Object Non-Electrical Energy Object Energy Monitoring Energy Control Provide Energy: Receive Energy: Power Interface Expires January 12, 2013 [Page 5] Internet-Draft July 2012 Power Inlet Power Outlet Energy Management Domain Energy Object Identification Energy Object Context Energy Object Relationship Aggregation Relationship Metering Relationship Power Source Relationship Proxy Relationship Energy Object Parent Energy Object Child Power State Power State Set Nameplate Power 5. Architecture Concepts Applied to the MIB Module This section describes the concepts specified in the Energy Management Framework [EMAN-FRAMEWORK] that pertain to power usage, 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 [EMAN-FRAMEWORK]. The Energy Monitoring MIB has 2 independent MIB modules. The first MIB module energyObjectMib is focused on measurement of power and energy. The second MIB module powerCharMIB is focused on Power Characteristics measurements. The energyObjectMib MIB module consists of four tables. The first table eoPowerTable is indexed by entPhysicalIndex. The second table eoPowerStateTable indexed by entPhysicalIndex, Expires January 12, 2013 [Page 6] Internet-Draft July 2012 and eoPowerStateIndex. The eoEnergyParametersTable is indexed by eoEnergyParametersIndex. The eoEnergyTable is indexed by eoEnergyParametersIndex and eoEnergyCollectionStartTime. eoMeterCapabilitiesTable(1) | +--- eoMeterCapabilitiesEntry(1) [entPhysicalIndex] | | | +---r-n BITS eoMeterCapability | eoPowerTable(1) | +---eoPowerEntry(1) [entPhysicalIndex] | | | +---r-n Integer32 eoPower(1) | +-- r-n Integer32 eoPowerNamePlate(2) | +-- r-n UnitMultiplier eoPowerUnitMultiplier(3) | +-- r-n Integer32 eoPowerAccuracy(4) | +-- r-n INTEGER eoMeasurementCaliber(5) | +-- r-n INTEGER eoPowerCurrentType(6) | +-- r-n INTEGER eoPowerOrigin(7) | +-- rwn Integer32 eoPowerAdminState(8) | +-- r-n Integer32 eoPowerOperState(9) | +-- r-n OwnerString eoPowerStateEnterReason(10) | | | | +---eoPowerStateTable(2) | +--eoPowerStateEntry(1) | | [entPhysicalIndex, | | eoPowerStateIndex] | | | +-- --n IANAPowerStateSet eoPowerStateIndex(1) | +-- r-n Interger32 eoPowerStateMaxPower (2) | +-- r-n UnitMultiplier | eoPowerStatePowerUnitMultiplier (3) | +-- r-n TimeTicks eoPowerStateTotalTime(4) | +-- r-n Counter32 eoPowerStateEnterCount(5) | +eoEnergyParametersTable(1) +---eoEnergyParametersEntry(1) [eoEnergyParametersIndex] | | +-- --n PhysicalIndex eoEnergyObjectIndex (1) | + r-n Integer32 eoEnergyParametersIndex (2) | +-- r-n TimeInterval Expires January 12, 2013 [Page 7] Internet-Draft July 2012 | eoEnergyParametersIntervalLength (3) | +-- r-n Integer32 | eoEnergyParametersIntervalNumber (4) | +-- r-n Integer32 | eoEnergyParametersIntervalMode (5) | +-- r-n TimeInterval | eoEnergyParametersIntervalWindow (6) | +-- r-n Integer32 | eoEnergyParametersSampleRate (7) | +-- r-n RowStatus eoEnergyParametersStatus (8) | +eoEnergyTable (1) +---eoEnergyEntry(1) [ eoEnergyParametersIndex, eoEnergyCollectionStartTime] | | +-- r-n TimeTicks eoEnergyCollectionStartTime (1) | +-- r-n Integer32 eoEnergyConsumed (2) | +-- r-n Integer32 eoEnergyyProduced (3) | +-- r-n Integer32 eoEnergyNet (4) | +-- r-n UnitMultiplier | eoEnergyUnitMultiplier (5) | +-- r-n Integer32 eoEnergyAccuracy(6) | +-- r-n Integer32 eoEnergyMaxConsumed (7) | +-- r-n Integer32 eoEnergyMaxProduced (8) | +-- r-n TimeTicks | eoEnergyDiscontinuityTime(9) | +-- r-n RowStatus eoEnergyParametersStatus (10) The powerCharacteristicsMIB consists of four tables. eoACPwrCharTable is indexed by entPhysicalIndex. eoACPwrCharPhaseTable is indexed by entPhysicalIndex and eoPhaseIndex. eoACPwrCharWyePhaseTable and eoACPwrCharDelPhaseTable are indexed by entPhysicalIndex and eoPhaseIndex. eoACPwrCharTable(1) | +---eoACPwrCharEntry (1) [ entPhysicalIndex] | | | | | +---r-n INTEGER eoACPwrCharConfiguration (1) | +-- r-n Interger32 eoACPwrCharAvgVoltage (2) | +-- r-n Integer32 eoACPwrCharAvgCurrent (3) | +-- r-n Integer32 eoACPwrCharFrequency (4) | +-- r-n UnitMultiplier | eoACPwrCharPowerUnitMultiplier (5) | +-- r-n Integer32 eoACPwrCharPowerAccuracy (6) Expires January 12, 2013 [Page 8] Internet-Draft July 2012 | +-- r-n Interger32 eoACPwrCharTotalActivePower (7) | +-- r-n Integer32 | eoACPwrCharTotalReactivePower (8) | +-- r-n Integer32 eoACPwrCharTotalApparentPower (9) | +-- r-n Integer32 eoACPwrCharTotalPowerFactor(10) | +-- r-n Integer32 eoACPwrCharThdAmpheres (11) | +eoACPwrCharPhaseTable (1) +---EoACPwrCharPhaseEntry(1)[ entPhysicalIndex, | | eoPhaseIndex] | | | +-- r-n Integer32 eoPhaseIndex (1) | +-- r-n Integer32 | | eoACPwrCharPhaseAvgCurrent (2) | +-- r-n Integer32 | | eoACPwrCharPhaseActivePower (3) | +-- r-n Integer32 | | eoACPwrCharPhaseReactivePower (4) | +-- r-n Integer32 | | eoACPwrCharPhaseApparentPower (5) | +-- r-n Integer32 | | eoACPwrCharPhasePowerFactor (6) | +-- r-n Integer32 | | eoACPwrCharPhaseImpedance (7) | | +eoACPwrCharDelPhaseTable (1) +-- eoACPwrCharDelPhaseEntry(1) | | [entPhysicalIndex, | | eoPhaseIndex] | +-- r-n Integer32 | | eoACPwrCharDelPhaseToNextPhaseVoltage (1) | +-- r-n Integer32 | | eoACPwrCharDelThdPhaseToNextPhaseVoltage (2) | +-- r-n Integer32 eoACPwrCharDelThdCurrent (3) | | +eoACPwrCharWyePhaseTable (1) +-- eoACPwrCharWyePhaseEntry (1) | | [entPhysicalIndex, | | eoPhaseIndex] | +-- r-n Integer32 | | eoACPwrCharWyePhaseToNeutralVoltage (1) | +-- r-n Integer32 | | eoACPwrCharWyePhaseCurrent (2) | +-- r-n Integer32 | | eoACPwrCharWyeThdPhaseToNeutralVoltage (3) | . Expires January 12, 2013 [Page 9] Internet-Draft July 2012 A UML representation of the MIB objects in the two MIB modules are energyObjectMib and powerCharacteristicsMIB are presented. +--------------------------+ | Energy Object ID | | ----------------------- | | | | entPhysIndex (*) | | entPhysicalName (*) | | entPhysicalUris (*) | +---------------------------+ | (EO UUID) | | | | | | Energy Object Attributes | | | | ------------------------- | | | | | +--------------------------+ | eoPowerNamePlate | | | | eoPowerMeasurementCaliber | | | | eoPowerOrigin | | | | eoPowerCurrentType | | | +---------------------------+ | | | | | | v | v +-----------------------------------------+ | Energy Object Measurement | | --------------------------------------- | | eoPower | | eoPowerUnitMultiplier | | eoPowerAccuracy | +-----------------------------------------+ ^ | ^ | | | +-------------------------+ | | | Energy Object State | | +------------------------+ | ----------------------- | | | Energy Object State | | eoPowerAdminState | | | Statistics | | eoPowerOperState | | |----------------------- | | eoPowerStateEnterReason | | | eoPowerStateMaxPower | +-------------------------+ | | eoPowerStateTotalTime | | | eoPowerStateEnterCount | | +------------------------+ | | | | Expires January 12, 2013 [Page 10] Internet-Draft July 2012 Figure 1:UML diagram for powerMonitor MIB (*) Link with the ENTITY-MIB | | V +----------------------------------------+ | Energy ParametersTable | | -------------------------------------- | | | | eoEnergyObjectIndex | | eoEnergyParametersIndex | | eoEnergyParametersIntervalLength | | eoEnergyParametersIntervalNumber | | eoEnergyParametersIntervalMode | | eoEnergyParametersIntervalWindow | | eoEnergyParametersSampleRate | | eoEnergyParametersStatus | +----------------------------------------+ | | | V +----------------------------------------+ | Energy Table | | ---------------------------------- | | eoEnergyCollectionStartTime | | eoEnergyConsumed | | eoEnergyProduced | | eoEnergyNet | | eoEnergyUnitMultiplier | | eoEnergyAccuracy | | eoMaxConsumed | | eoMaxProduced | | eoDiscontinuityTime | +----------------------------------------+ +--------------------------+ | EnergyObject ID | Expires January 12, 2013 [Page 11] Internet-Draft July 2012 | ----------------------- | | | | | | entPhysicalIndex (*) | | | +--------------------------+ | v +-------------------------------------+ | Power Characteristics | | ----------------------------------- | | eoACPwrCharConfiguration | | eoACPwrCharAvgVoltage | | eoACPwrCharAvgCurrent | | eoACPwrCharFrequency | | eoACPwrCharPowerUnitMultiplier | | eoACPwrCharPowerAccuracy | | eoACPwrCharTotalActivePower | | eoACPwrCharTotalReactivePower | | eoACPwrCharTotalApparentPower | | eoACPwrCharTotalPowerFactor | | eoACPwrCharThdAmpheres | +-------------------------------------+ ^ ^ ^ | | | ------- | ---- | | | | | | | +-------------------------------------+ | | | Power Phase Characteristics | | | | ---------------------------------- | | | | eoPhaseIndex | | | | eoACPwrCharPhaseAvgCurrent | | | | eoACPwrCharAvgCurrent | | | | eoACPwrCharFrequency | | | | eoACPwrCharPowerUnitMultiplier | | | | eoACPwrCharPowerAccuracy | | | | eoACPwrCharPhaseActivePower | | | | eoACPwrCharPhaseReactivePower | | | | eoACPwrCharPhaselApparentPower | | | | eoACPwrCharPhaseImpedance | | | +-------------------------------------+ | | | | | | +---------------------------------------------+ | | AC Input DEL Configuration | | | | | | eoACPwrCharDelPhaseToNextPhaseVoltage | | Expires January 12, 2013 [Page 12] Internet-Draft July 2012 | eoACPwrCharDelThdPhaseToNextPhaseVoltage | | | eoACPwrCharDelThdCurrent | | +---------------------------------------------+ | | | +---------------------------------------------+ | AC Input WYE Configuration | | | | eoACPwrCharWyePhaseToNeutralVoltage | | eoACPwrCharWyePhaseCurrent | | eoACPwrCharWyeThdPhaseToNeutralVoltage | +---------------------------------------------+ Figure 2: UML diagram for the powerCharacteristicsMIB (*) Link with the ENTITY-MIB 5.1. Energy Object Information Refer to the "Energy Object Information" section in [EMAN- FRAMEWORK] for background information. An energy aware device is considered as an instance of a Energy Object as defined in the [EMAN-FRAMEWORK]. The Energy Object identity information is specified in the MIB ENERGY-AWARE-MIB module [EMAN-AWARE-MIB] primary table, i.e. the eoTable. In this table, every Energy Object SHOULD have a printable name eoName, and MUST HAVE a unique Energy Object index entPhysicalUris and entPhysicalIndex. The ENERGY-AWARE-MIB module returns the relationship (parent/child) between Energy Objects. There are several possible relationships between Parent and Child as defined in [EMAN-AWARE-MIB] such as MeteredBy, PoweredBy, AggregatedBy and ProxyedBy. 5.2. Power State Refer to the "Power States" section in [EMAN-FRAMEWORK] for background information. An Energy Object may have energy conservation modes called Power States. Between the ON and OFF states of a device, there can be several intermediate energy saving modes. Those energy saving modes are called as Power States. Expires January 12, 2013 [Page 13] Internet-Draft July 2012 Power States, which represent universal states of power management of an Energy Object, are specified by the eoPowerState MIB object. The actual Power State is specified by the eoPowerOperState MIB object, while the eoPowerAdminState MIB object specifies the Power State requested for the Energy Object. The difference between the values of eoPowerOperState and eoPowerAdminState can be attributed that the Energy Object is busy transitioning from eoPowerAdminState into the eoPowerOperState, at which point it will update the content of eoPowerOperState. In addition, the possible reason for change in Power State is reported in eoPowerStateEnterReason. Regarding eoPowerStateEnterReason, management stations and Energy Objects should support any format of the owner string dictated by the local policy of the organization. It is suggested that this name contain at least the reason for the transition change, and one or more of the following: IP address, management station name, network manager's name, location, or phone number. The MIB objects eoPowerOperState, eoPowerAdminState , and eoPowerStateEnterReason are contained in the eoPowerTable MIB table. The eoPowerStateTable table enumerates the maximum power usage in watts, for every single supported Power State of each Power State Set supported by the Energy Object. In addition, PowerStateTable provides additional statistics: eoPowerStateEnterCount, the number of times an entity has visited a particular Power State, and eoPowerStateTotalTime, the total time spent in a particular Power State of an Energy Object. 5.2.1. Power State Set There are several standards and implementations of Power State Sets. A Energy Object can support one or multiple Power State Set implementation(s) concurrently. There are currently three Power State Sets advocated: unknown(0) IEEE1621(256) - [IEEE1621] DMTF(512) - [DMTF] EMAN(1024) - [EMAN-MONITORING-MIB] The respective specific states related to each Power State Set are specified in the following sections. The guidelines for Expires January 12, 2013 [Page 14] Internet-Draft July 2012 addition of new Power State Sets have been specified in the IANA Considerations Section. 5.2.2. IEEE1621 Power State Set The IEEE1621 Power State Set [IEEE1621] consists of 3 rudimentary states : on, off or sleep. on(0) - The device is fully On and all features of the device are in working mode. off(1) - The device is mechanically switched off and does not consume energy. sleep(2) - The device is in a power saving mode, and some features may not be available immediately. The Textual Convention IANAPowerStateSet provides the proposed numbering of the Power States within the IEEE1621 Power State Set. 5.2.3. DMTF Power State Set DMTF [DMTF] standards organization has defined a power profile standard based on the CIM (Common Information Model) model that consists of 15 power states ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off-Soft (6), Hibernate(7), PowerCycle Off- Soft (8), PowerCycle Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt (11), Off-Soft-Graceful (12), Off-Hard Graceful (13), MasterBus reset Graceful (14), Power-Cycle Off- Soft Graceful (15), PowerCycle-Hard Graceful (16). DMTF standard is targeted for hosts and computers. Details of the semantics of each Power State within the DMTF Power State Set can be obtained from the DMTF Power State Management Profile specification [DMTF]. DMTF power profile extends ACPI power states. The following table provides a mapping between DMTF and ACPI Power State Set: --------------------------------------------------- | DMTF | ACPI | | Power State | Power State | --------------------------------------------------- | Reserved(0) | | --------------------------------------------------- | Reserved(1) | | --------------------------------------------------- | ON (2) | G0-S0 | Expires January 12, 2013 [Page 15] Internet-Draft July 2012 -------------------------------------------------- | Sleep-Light (3) | G1-S1 G1-S2 | -------------------------------------------------- | Sleep-Deep (4) | G1-S3 | -------------------------------------------------- | Power Cycle (Off-Soft) (5) | G2-S5 | --------------------------------------------------- | Off-hard (6) | G3 | --------------------------------------------------- | Hibernate (Off-Soft) (7) | G1-S4 | --------------------------------------------------- | Off-Soft (8) | G2-S5 | --------------------------------------------------- | Power Cycle (Off-Hard) (9) | G3 | --------------------------------------------------- | Master Bus Reset (10) | G2-S5 | --------------------------------------------------- | Diagnostic Interrupt (11) | G2-S5 | --------------------------------------------------- | Off-Soft Graceful (12) | G2-S5 | --------------------------------------------------- | Off-Hard Graceful (13) | G3 | --------------------------------------------------- | MasterBus Reset Graceful (14) | G2-S5 | --------------------------------------------------- | Power Cycle off-soft Graceful (15)| G2-S5 | --------------------------------------------------- | Power Cycle off-hard Graceful (16)| G3 | --------------------------------------------------- Figure 3: DMTF and ACPI Powe State Set Mapping The Textual Convention IANAPowerStateSet contains the proposed numbering of the Power States within the DMTF Power State Set. 5.2.4. EMAN Power State Set The EMAN Power State Set represents an attempt for a uniform standard approach to model the different levels of power consumption of a device. The EMAN Power States are an expansion of the basic Power States as defined in IEEE1621 that also incorporate the Power States defined in ACPI and DMTF. Therefore, in addition to the non-operational states as defined in ACPI and DMTF standards, several intermediate operational states have been defined. Expires January 12, 2013 [Page 16] Internet-Draft July 2012 There are twelve Power States, that expand on IEEE1621 on, sleep and off. The expanded list of Power States are divided into six operational states, and six non-operational states. The lowest non-operational state is 1 and the highest is 6. Each non- operational state corresponds to an ACPI state [ACPI] corresponding to Global and System states between G3 (hard-off) and G1 (sleeping). For Each operational state represent a performance state, and may be mapped to ACPI states P0 (maximum performance power) through P5 (minimum performance and minimum power). An Energy Object may have fewer Power States than twelve and would then map several policy states to the same power state. Energy Object with more than twelve states, would choose which twelve to represent as power policy states. In each of the non-operational states (from mechoff(1) to ready(6)), the Power State preceding it is expected to have a lower power consumption and a longer delay in returning to an operational state: IEEE1621 Power(off): mechoff(1) : An off state where no entity features are available. The entity is unavailable. No energy is being consumed and the power connector can be removed. This corresponds to ACPI state G3. softoff(2) : Similar to mechoff(1), but some components remain powered or receive trace power so that the entity can be awakened from its off state. In softoff(2), no context is saved and the device typically requires a complete boot when awakened. This corresponds to ACPI state G2. IEEE1621 Power(sleep) hibernate(3): No entity features are available. The entity may be awakened without requiring a complete boot, but the time for availability is longer than sleep(4). An example for state hibernate(3) is a save to-disk state where DRAM context is not maintained. Typically, energy consumption Expires January 12, 2013 [Page 17] Internet-Draft July 2012 is zero or close to zero. This corresponds to state G1, S4 in ACPI. sleep(4) : No entity features are available, except for out-of-band management, for example wake-up mechanisms. The time for availability is longer than standby(5). An example for state sleep(4) is a save- to-RAM state, where DRAM context is maintained. Typically, energy consumption is close to zero. This corresponds to state G1, S3 in ACPI. standby(5) : No entity features are available, except for out-of-band management, for example wake-up mechanisms. This mode is analogous to cold-standy. The time for availability is longer than ready(6). For example, the processor context is not maintained. Typically, energy consumption is close to zero. This corresponds to state G1, S2 in ACPI. ready(6) : No entity features are available, except for out-of-band management, for example wake-up mechanisms. This mode is analogous to hot-standby. The entity can be quickly transitioned into an operational state. For example, processors are not executing, but processor context is maintained. This corresponds to state G1, S1 in ACPI. IEEE1621 Power(on): lowMinus(7) : Indicates some entity features may not be available and the entity has selected measures/options to provide less than low(8) usage. This corresponds to ACPI State G0. This includes operational states lowMinus(7) to full(12). low(8) : Indicates some features may not be available and the entity has taken measures or selected options to provide less than mediumMinus(9) usage. mediumMinus(9): Indicates all entity features are Expires January 12, 2013 [Page 18] Internet-Draft July 2012 available but the entity has taken measures or selected options to provide less than medium(10) usage. medium(10) : Indicates all entity features are available but the entity has taken measures or selected options to provide less than highMinus(11) usage. highMinus(11): Indicates all entity features are available and power usage is less than high(12). high(12) : Indicates all entity features are available and the entity is consuming the highest power. The Textual Convention IANAPowerStateSet contains the proposed numbering of the Power States within the EMAN Power State Set. 5.3. Energy Object Usage Information Refer to the "Energy Object Usage Measurement" section in [EMAN- FRAMEWORK] for background information. For an Energy Object, power usage is reported using eoPower. The magnitude of measurement is based on the eoPowerUnitMultiplier MIB variable, based on the UnitMultiplier Textual Convention (TC). Power measurement magnitude should conform to the IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] definition of unit multiplier for the SI (System International) units of measure. Measured values are represented in SI units obtained by BaseValue * 10 raised to the power of the scale. For example, if current power usage of an Energy Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW, depending on the value of eoPowerUnitMultiplier. Note that other measurements throughout the two MIB modules in this document use the same mechanism, including eoPowerStatePowerUnitMultiplier, eoEnergyUnitMultiplier, and eoACPwrCharPowerUnitMultiplier. In addition to knowing the usage and magnitude, it is useful to know how a eoPower measurement was obtained. An NMS can use this to account for the accuracy and nature of the reading between different implementations. For this eoPowerOrigin Expires January 12, 2013 [Page 19] Internet-Draft July 2012 describes whether the measurements were made at the device itself or from a remote source. The eoPowerMeasurementCaliber describes the method that was used to measure the power and can distinguish actual or estimated values. There may be devices in the network, which may not be able to measure or report power consumption. For those devices, the object eoPowerMeasurementCaliber shall report that measurement mechanism is "unavailable" and the eoPower measurement shall be "0". The nameplate power rating of an Energy Object is specified in eoPowerNameplate MIB object. 5.4. Optional Power Usage Characteristics Refer to the "Optional Power Usage Characteristics" section in [EMAN-FRAMEWORK] for background information. The optional powerCharacteristicsMIB MIB module can be implemented to further describe power usage characteristics measurement. The powerCharacteristicsMIB MIB module adheres closely to the IEC 61850 7-2 standard to describe AC measurements. The powerCharacteristicsMIB MIB module contains a primary table, the eoACPwrCharTable table, that defines Power Characteristics measurements for supported entPhysicalIndex entities, as a sparse extension of the eoPowerTable (with entPhysicalIndex as primary index). This eoACPwrCharTable table contains such information as the configuration (single phase, DEL 3 phases, WYE 3 phases), voltage, frequency, power accuracy, total active/reactive power/apparent power, amperage, and voltage. In case of 3-phase power, the eoACPwrCharPhaseTable additional table is populated with Power Characteristics measurements per phase (so double indexed by the entPhysicalIndex and eoPhaseIndex). This table, which describes attributes common to both WYE and DEL configurations, contains the average current, active/reactive/apparent power, power factor, and impedance. In case of 3-phase power with a DEL configuration, the eoACPwrCharDelPhaseTable table describes the phase-to-phase Power Characteristics measurements, i.e., voltage and current. In case of 3-phase power with a Wye configuration, the eoACPwrCharWyePhaseTable table describes the phase-to-neutral Power Characteristics measurements, i.e., voltage and current. Expires January 12, 2013 [Page 20] Internet-Draft July 2012 5.5. Optional Energy Measurement Refer to the "Optional Energy and demand Measurement" section in [EMAN-FRAMEWORK] for the definition and terminology information. It is relevant to measure energy when there are actual power measurements from an Energy Object, and not when the power measurement is assumed or predicted as specified in the description clause of the object eoPowerMeasurementCaliber. Two tables are introduced to characterize energy measurement of an Energy Object: eoEnergyTable and eoEnergyParametersTable. Both energy and demand information can be represented via the eoEnergyTable. Energy information will be an accumulation with no interval. Demand information can be represented. The eoEnergyParametersTable consists of the parameters defining eoEnergyParametersIndex, an index of that specifies the setting for collection of energy measurements for an Energy Object, eoEnergyObjectIndex, linked to the entPhysicalIndex of the Energy Object, the duration of measurement intervals in seconds, (eoEnergyParametersIntervalLength), the number of successive intervals to be stored in the eoEnergyTable, (eoEnergyParametersIntervalNumber), the type of measurement technique (eoEnergyParametersIntervalMode), and a sample rate used to calculate the average (eoEnergyParametersSampleRate). Judicious choice of the sampling rate will ensure accurate measurement of energy while not imposing an excessive polling burden. There are three eoEnergyParametersIntervalMode types used for energy measurement collection: period, sliding, and total. The choices of the the three different modes of collection are based on IEC standard 61850-7-4. Note that multiple eoEnergyParametersIntervalMode types MAY be configured simultaneously. It is important to note that for a given Energy Object, multiple modes (periodic, total, sliding window) of energy measurement collection can be configured with the use of eoEnergyParametersIndex. However, simultaneous measurement in multiple modes for a given Energy Object depends on the Energy Object capability. These three eoEnergyParametersIntervalMode types are illustrated by the following three figures, for which: Expires January 12, 2013 [Page 21] Internet-Draft July 2012 - The horizontal axis represents the current time, with the symbol <--- L ---> expressing the eoEnergyParametersIntervalLength, and the eoEnergyCollectionStartTime is represented by S1, S2, S3, S4, ..., Sx where x is the value of eoEnergyParametersIntervalNumber. - The vertical axis represents the time interval of sampling and the value of eoEnergyConsumed can be obtained at the end of the sampling period. The symbol =========== denotes the duration of the sampling period. | | | =========== | |============ | | | | | | | | |============ | | | | | | | <--- L ---> | <--- L ---> | <--- L ---> | | | | | S1 S2 S3 S4 Figure 4 : Period eoEnergyParametersIntervalMode A eoEnergyParametersIntervalMode type of 'period' specifies non- overlapping periodic measurements. Therefore, the next eoEnergyCollectionStartTime is equal to the previous eoEnergyCollectionStartTime plus eoEnergyParametersIntervalLength. S2=S1+L; S3=S2+L, ... |============ | | | | <--- L ---> | | | | |============ | | | | | | <--- L ---> | | | | | | |============ | | | | | | | | <--- L ---> | | | | | | | | |============ | | | | | | | | | | <--- L ---> | S1 | | | | | | | | Expires January 12, 2013 [Page 22] Internet-Draft July 2012 | | | | S2 | | | | | | | | | S3 | | | | | | S4 Figure 5 : Sliding eoEnergyParametersIntervalMode A eoEnergyParametersIntervalMode type of 'sliding' specifies overlapping periodic measurements. | | |========================= | | | | | | | | <--- Total length ---> | | | S1 Figure 6 : Total eoEnergyParametersIntervalMode A eoEnergyParametersIntervalMode type of 'total' specifies a continuous measurement since the last reset. The value of eoEnergyParametersIntervalNumber should be (1) one and eoEnergyParametersIntervalLength is ignored. The eoEnergyParametersStatus is used to start and stop energy usage logging. The status of this variable is "active" when all the objects in eoEnergyParametersTable are appropriate which in turn indicates if eoEnergyTable entries exist or not. The eoEnergyTable consists of energy measurements in eoEnergyConsumed, eoEnergyProduced and eoEnergyNet, the units of the measured energy eoEnergyUnitMultiplier, and the maximum observed energy within a window, eoEnergyMaxConsumed, eoEnergyMaxProduced. Expires January 12, 2013 [Page 23] Internet-Draft July 2012 Measurements of the total energy consumed by an Energy Object may suffer from interruptions in the continuous measurement of energy consumption. In order to indicate such interruptions, the object eoEnergyDiscontinuityTime is provided for indicating the time of the last interruption of total energy measurement. eoEnergyDiscontinuityTime shall indicate the sysUpTime [RFC3418] when the device was reset. The following example illustrates the eoEnergyTable and eoEnergyParametersTable: First, in order to estimate energy, a time interval to sample energy should be specified, i.e. eoEnergyParametersIntervalLength can be set to "900 seconds" or 15 minutes and the number of consecutive intervals over which the maximum energy is calculated (eoEnergyParametersIntervalNumber) as "10". The sampling rate internal to the Energy Object for measurement of power usage (eoEnergyParametersSampleRate) can be "1000 milliseconds", as set by the Energy Object as a reasonable value. Then, the eoEnergyParametersStatus is set to active (value 1) to indicate that the Energy Object should start monitoring the usage per the eoEnergyTable. The indices for the eoEnergyTable are eoEnergyParametersIndex which identifies the index for the setting of energy measurement collection Energy Object, and eoEnergyCollectionStartTime, which denotes the start time of the energy measurement interval based on sysUpTime [RFC3418]. The value of eoEnergyComsumed is the measured energy consumption over the time interval specified (eoEnergyParametersIntervalLength) based on the Energy Object internal sampling rate (eoEnergyParametersSampleRate). While choosing the values for the eoEnergyParametersIntervalLength and eoEnergyParametersSampleRate, it is recommended to take into consideration either the network element resources adequate to process and store the sample values, and the mechanism used to calculate the eoEnergyConsumed. The units are derived from eoEnergyUnitMultiplier. For example, eoEnergyConsumed can be "100" with eoEnergyUnitMultiplier equal to 0, the measured energy consumption of the Energy Object is 100 watt-hours. The eoEnergyMaxConsumed is the maximum energy observed and that can be "150 watt-hours". The eoEnergyTable has a buffer to retain a certain number of intervals, as defined by eoEnergyParametersIntervalNumber. If the default value of "10" is kept, then the eoEnergyTable contains 10 energy measurements, including the maximum. Expires January 12, 2013 [Page 24] Internet-Draft July 2012 Here is a brief explanation of how the maximum energy can be calculated. The first observed energy measurement value is taken to be the initial maximum. With each subsequent measurement, based on numerical comparison, maximum energy may be updated. The maximum value is retained as long as the measurements are taking place. Based on periodic polling of this table, an NMS could compute the maximum over a longer period, i.e. a month, 3 months, or a year. 5.6. Fault Management [EMAN-REQ] specifies requirements about Power States such as "the current power state" , "the time of the last state change", "the total time spent in each state", "the number of transitions to each state" etc. Some of these requirements are fulfilled explicitly by MIB objects such as eoPowerOperState, eoPowerStateTotalTime and eoPowerStateEnterCount. Some of the other requirements are met via the SNMP NOTIFICATION mechanism. eoPowerStateChange SNMP notification which is generated when the value(s) of ,eoPowerStateIndex, eoPowerOperState, eoPowerAdminState have changed. 6. Discovery It is foreseen that most Energy Objects will require the implementation of the ENERGY-AWARE MIB [EMAN-AWARE-MIB] as a prerequisite for this MIB module. In such a case, eoPowerTable of the EMAN-MON-MIB is a sparse extension of the eoTable of ENERGY-AWARE-MIB. Every Energy Object MUST implement entPhysicalIndex, entPhysicalUris and entPhysicalName from the ENTITY-MIB [RFC4133]. As the index for the primary Energy Object, entPhysicalIndex is used. The NMS must first poll the ENERGY-AWARE-MIB module [EMAN-AWARE- MIB], if available, in order to discover all the Energy Objects and the relationships between those (notion of Parent/Child). In the ENERGY-AWARE-MIB module tables, the Energy Objects are indexed by the entPhysicalIndex. If an implementation of the ENERGY-AWARE-MIB module is available in the local SNMP context, for the same Energy Object, the entPhysicalIndex value (EMAN-AWARE-MIB) shall be used. The entPhysicalIndex characterizes the Energy Object in the energyObjectMib and the powerCharacteristicsMIB MIB modules (this document). Expires January 12, 2013 [Page 25] Internet-Draft July 2012 From there, the NMS must poll the eoPowerStateTable (specified in the energyObjectMib module in this document), which enumerates, amongst other things, the maximum power usage. As the entries in eoPowerStateTable table are indexed by the Energy Object ( entPhysicalIndex), by the Power State Set (eoPowerStateIndex), the maximum power usage is discovered per Energy Object, and the power usage per Power State of the Power State Set. In other words, polling the eoPowerStateTable allows the discovery of each Power State within every Power State Set supported by the Energy Object. If the Energy Object is an Aggregator or a Proxy, the MIB module would be populated with the Energy Object Parent and Children information, which have their own Energy Object index value (entPhysicalIndex). However, the parent/child relationship must be discovered thanks to the ENERGY-AWARE-MIB module. Finally, the NMS can monitor the Power Characteristics thanks to the powerCharacteristicsMIB MIB module, which reuses the entPhysicalIndex to index the Energy Object. 7. Link with the other IETF MIBs 7.1. Link with the ENTITY-MIB and the ENTITY-SENSOR MIB RFC 4133 [RFC4133] defines the ENTITY-MIB module that lists the physical entities of a networking device (router, switch, etc.) and those physical entities indexed by entPhysicalIndex. From an energy-management standpoint, the physical entities that consume or produce energy are of interest. RFC 3433 [RFC3433] defines the ENTITY-SENSOR MIB module that provides a standardized way of obtaining information (current value of the sensor, operational status of the sensor, and the data units precision) from sensors embedded in networking devices. Sensors are associated with each index of entPhysicalIndex of the ENTITY-MIB [RFC4133]. While the focus of the Power and Energy Monitoring MIB is on measurement of power usage of networking equipment indexed by the ENTITY-MIB, this MIB proposes a customized power scale for power measurement and different power state states of networking equipment, and functionality to configure the power state states. When this MIB module is used to monitor the power usage of devices like routers and switches, the ENTITY-MIB and ENTITY- SENSOR MIB SHOULD be implemented. In such cases, the Energy Expires January 12, 2013 [Page 26] Internet-Draft July 2012 Objects are modeled by the entPhysicalIndex through the entPhysicalEntity MIB object specified in the eoTable in the ENERGY-AWARE-MIB MIB module [EMAN-AWARE-MIB]. However, the ENTITY-SENSOR MIB [RFC3433] does not have the ANSI C12.x accuracy classes required for electricity (i.e., 1%, 2%, 0.5% accuracy classes). Indeed, entPhySensorPrecision [RFC3433] represents "The number of decimal places of precision in fixed- point sensor values returned by the associated entPhySensorValue object". The ANSI and IEC Standards are used for power measurement and these standards require that we use an accuracy class, not the scientific-number precision model specified in RFC3433. The eoPowerAccuracy MIB object models this accuracy. Note that eoPowerUnitMultipler represents the scale factor per IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22], which is a more logical representation for power measurements (compared to entPhySensorScale), with the mantissa and the exponent values X * 10 ^ Y. Power measurements specifying the qualifier 'UNITS' for each measured value in watts are used in the LLDP-EXT-MED-MIB, POE [RFC3621], and UPS [RFC1628] MIBs. The same 'UNITS' qualifier is used for the power measurement values. One cannot assume that the ENTITY-MIB and ENTITY-SENSOR MIB are implemented for all Energy Objects that need to be monitored. A typical example is a converged building gateway, monitoring several other devices in the building, doing the proxy between SNMP and a protocol like BACNET. Another example is the home energy controller. In such cases, the eoPhysicalEntity value contains the zero value, thanks to PhysicalIndexOrZero textual convention. The eoPower is similar to entPhySensorValue [RFC3433] and the eoPowerUnitMultipler is similar to entPhySensorScale. 7.2. Link with the ENTITY-STATE MIB For each entity in the ENTITY-MIB [RFC4133], the ENTITY-STATE MIB [RFC4268] specifies the operational states (entStateOper: unknown, enabled, disabled, testing), the alarm (entStateAlarm: unknown, underRepair, critical, major, minor, warning, indeterminate) and the possible values of standby states (entStateStandby: unknown, hotStandby, coldStandby, providingService). Expires January 12, 2013 [Page 27] Internet-Draft July 2012 From a power monitoring point of view, in contrast to the entity operational states of entities, Power States are required, as proposed in the Power and Energy Monitoring MIB module. Those Power States can be mapped to the different operational states in the ENTITY-STATE MIB, if a formal mapping is required. For example, the entStateStandby "unknown", "hotStandby", "coldStandby", states could map to the Power State "unknown", "ready", "standby", respectively, while the entStateStandby "providingService" could map to any "low" to "high" Power State. 7.3. Link with the POWER-OVER-ETHERNET MIB Power-over-Ethernet MIB [RFC3621] provides an energy monitoring and configuration framework for power over Ethernet devices. The RFC introduces a concept of a port group on a switch to define power monitoring and management policy and does not use the entPhysicalIndex as the index. Indeed, the pethMainPseConsumptionPower is indexed by the pethMainPseGroupIndex, which has no mapping with the entPhysicalIndex. One cannot assume that the Power-over-Ethernet MIB is implemented for all Energy Objects that need to be monitored. A typical example is a converged building gateway, monitoring several other devices in the building, doing the proxy between SNMP and a protocol like BACNET. Another example is the home energy controller. In such cases, the eoethPortIndex and eoethPortGrpIndex values contain the zero value, thanks to new PethPsePortIndexOrZero and textual PethPsePortGroupIndexOrZero conventions. However, if the Power-over-Ethernet MIB [RFC3621] is supported, the Energy Object eoethPortIndex and eoethPortGrpIndex contain the pethPsePortIndex and pethPsePortGroupIndex, respectively. As a consequence, the entPhysicalIndex MIB object has been kept as the unique Energy Object index. Note that, even though the Power-over-Ethernet MIB [RFC3621] was created after the ENTITY-SENSOR MIB [RFC3433], it does not reuse the precision notion from the ENTITY-SENSOR MIB, i.e. the entPhySensorPrecision MIB object. Expires January 12, 2013 [Page 28] Internet-Draft July 2012 7.4. Link with the UPS MIB To protect against unexpected power disruption, data centers and buildings make use of Uninterruptible Power Supplies (UPS). To protect critical assets, a UPS can be restricted to a particular subset or domain of the network. UPS usage typically lasts only for a finite period of time, until normal power supply is restored. Planning is required to decide on the capacity of the UPS based on output power and duration of probable power outage. To properly provision UPS power in a data center or building, it is important to first understand the total demand required to support all the entities in the site. This demand can be assessed and monitored via the Power and Energy Monitoring MIB. UPS MIB [RFC1628] provides information on the state of the UPS network. Implementation of the UPS MIB is useful at the aggregate level of a data center or a building. The MIB module contains several groups of variables: - upsIdent: Identifies the UPS entity (name, model, etc.). - upsBattery group: Indicates the battery state (upsbatteryStatus, upsEstimatedMinutesRemaining, etc.) - upsInput group: Characterizes the input load to the UPS (number of input lines, voltage, current, etc.). - upsOutput: Characterizes the output from the UPS (number of output lines, voltage, current, etc.) - upsAlarms: Indicates the various alarm events. The measurement of power in the UPS MIB is in Volts, Amperes and Watts. The units of power measurement are RMS volts and RMS Amperes. They are not based on the EntitySensorDataScale and EntitySensorDataPrecision of ENTITY-SENSOR-MIB. Both the Power and Energy Monitoring MIB and the UPS MIB may be implemented on the same UPS SNMP agent, without conflict. In this case, the UPS device itself is the Energy Object Parent and any of the UPS meters or submeters are the Energy Object Children. Expires January 12, 2013 [Page 29] Internet-Draft July 2012 7.5. Link with the LLDP and LLDP-MED MIBs The LLDP Protocol is a Data Link Layer protocol used by network devices to advertise their identities, capabilities, and interconnections on a LAN network. The Media Endpoint Discovery is an enhancement of LLDP, known as LLDP-MED. The LLDP-MED enhancements specifically address voice applications. LLDP-MED covers 6 basic areas: capability discovery, LAN speed and duplex discovery, network policy discovery, location identification discovery, inventory discovery, and power discovery. Of particular interest to the current MIB module is the power discovery, which allows the endpoint device (such as a PoE phone) to convey power requirements to the switch. In power discovery, LLDP-MED has four Type Length Values (TLVs): power type, power source, power priority and power value. Respectively, those TLVs provide information related to the type of power (power sourcing entity versus powered device), how the device is powered (from the line, from a backup source, from external power source, etc.), the power priority (how important is it that this device has power?), and how much power the device needs. The power priority specified in the LLDP-MED MIB [LLDP-MED-MIB] actually comes from the Power-over-Ethernet MIB [RFC3621]. If the Power-over-Ethernet MIB [RFC3621] is supported, the exact value from the pethPsePortPowerPriority [RFC3621] is copied over in the lldpXMedRemXPoEPDPowerPriority [LLDP-MED-MIB]; otherwise the value in lldpXMedRemXPoEPDPowerPriority is "unknown". From the Power and Energy Monitoring MIB, it is possible to identify the pethPsePortPowerPriority [RFC3621], thanks to the eoethPortIndex and eoethPortGrpIndex. The lldpXMedLocXPoEPDPowerSource [LLDP-MED-MIB] is similar to eoPowerOrigin in indicating if the power for an attached device is local or from a remote device. If the LLDP-MED MIB is supported, the following mapping can be applied to the eoPowerOrigin: lldpXMedLocXPoEPDPowerSource fromPSE(2) and local(3) can be mapped to remote(2) and self(1), respectively. 8. Implementation Scenario Expires January 12, 2013 [Page 30] Internet-Draft July 2012 This section provides an illustrative example scenario for the implementation of the Energy Object, including Energy Object Parent and Energy Object Child relationships. Example Scenario of a campus network: Switch with PoE Endpoints with further connected Devices The campus network consists of switches that provide LAN connectivity. The switch with PoE ports is located in wiring closet. PoE IP phones are connected to the switch. The IP phones draw power from the PoE ports of the switch. In addition, a PC is daisy-chained from the IP phone for LAN connectivity. The IP phone consumes power from the PoE switch, while the PC consumes power from the wall outlet. The switch has implementations of ENTITY-MIB [RFC4133] and ENERGY-AWARE MIB [EMAN-AWARE-MIB] while the PC does not have implementation of the ENTITY-MIB, but has an implementation of ENERGY-AWARE MIB [EMAN-AWARE-MIB]. The switch has the following attributes, entPhysicalIndex "1", and eoUUID "UUID 1000". The power usage of the switch is "440 Watts". The switch does not have an Energy Object Parent. The PoE switch port has the following attributes: The switch port has entPhysicalIndex "3", and eoUUID is "UUID 1000:3". The power metered at the POE switch port is "12 watts". In this example, the POE switch port has the switch as the Energy Object Parent, with its eoParentID of "1000". The attributes of the PC are given below. The PC does not have an entPhysicalIndex, andthe eoUUID is "UUID 1000:57 ". The PC has an Energy Object Parent, i.e. the switch port whose eoUUID is "UUID 1000:3". The power usage of the PC is "120 Watts" and is communicated to the switch port. This example illustrates the important distinction between the Energy Object Children: The IP phone draws power from the switch, while the PC has LAN connectivity from the phone, but is powered from the wall outlet. However, the Energy Object Parent sends power control messages to both the Energy Object Children (IP phone and PC) and the Children react to those messages. Expires January 12, 2013 [Page 31] Internet-Draft July 2012 |-------------------------------------------------------| | Switch | |=======================================================| | Switch | Switch | Switch | Switch | | entPhyIndx | UUID |eoParentId | eoPower | | ===================================================== | | 1 | UUID 1000 | null | 440 | | ===================================================== | | | | SWITCH PORT | | ===================================================== | | | Switch | Switch | Switch | Switch | | | Port | Port | Port | Port | | | entPhyIndx | UUID | eoParentId | eoPower | | ===================================================== | | | 3 | UUID 1000:3 | 1000 | 12 | | ======================================================| | ^ | | |-----------------------------------|------------------- | | POE IP PHONE | | | ====================================================== | IP phone | IP phone | IP phone | IP phone | | entPhyIndx | UUID | eoParentID | eoPower | ====================================================== | Null | UUID 1000:31| UUID 1000:3 | 12 | ======================================================= | | PC connected to switch via IP phone | | ===================================================== | PC | PC | PC | PC | |entPhyIndx | UUID | eoParentID | eoPower | ===================================================== | 7 | UUID 1000:57| UUID 1000:3 | 120 | ===================================================== Figure 1: Example scenario Expires January 12, 2013 [Page 32] Internet-Draft July 2012 9. Structure of the MIB The primary MIB object in this MIB module is the energyObjectMibObject. The eoPowerTable table of energyObjectMibObject describes the power measurement attributes of an Energy Object entity. The notion of identity of the device in terms of uniquely identification of the Energy Object and its relationship to other entities in the network are addressed in [EMAN-AWARE-MIB]. Logically, this MIB module is a sparse extension of the [EMAN-AWARE-MIB] module. Thus the following requirements which are applied to [EMAN-AWARE-MIB] are also applicable. As a requirement for this MIB module, [EMAN-AWARE-MIB] should be implemented and the three MIB objects from ENTITY-MIB (entPhysicalIndex, entPhysicalName and entPhysicalUris) MUST be implemented. eoMeterCapabilitiesTable is useful to enable applications to determine the capabilities supported by the local management agent. This table indicates the energy monitoring MIB groups that are supported by the local management system. By reading the value of this object, it is possible for applications to know which tables contain the information and are usable without walking through the table and querying every element which involves a trial-and-error process. The power measurement of an Energy Object contains information describing its power usage (eoPower) and its current power state (eoPowerOperState). In addition to power usage, additional information describing the units of measurement (eoPowerAccuracy, eoPowerUnitMultiplier), how power usage measurement was obtained (eoPowerMeasurementCaliber), the source of power (eoPowerOrigin) and the type of power (eoPowerCurrentTtype) are described. An Energy Object may contain an optional eoPowerCharacteristics table that describes the electrical characteristics associated with the current power state and usage. An Energy Object may contain an optional eoEnergyTable to describe energy measurement information over time. An Energy Object may also contain optional battery information associated with this entity. Expires January 12, 2013 [Page 33] Internet-Draft July 2012 10. MIB Definitions -- ************************************************************ -- -- -- This MIB is used to monitor power usage of network -- devices -- -- ************************************************************* ENERGY-OBJECT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2, Integer32, Counter32, TimeTicks FROM SNMPv2-SMI TEXTUAL-CONVENTION, DisplayString, RowStatus, TimeInterval, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP FROM SNMPv2-CONF OwnerString FROM RMON-MIB entPhysicalIndex, PhysicalIndex FROM ENTITY-MIB; energyObjectMib MODULE-IDENTITY LAST-UPDATED "201207110000Z" -- 11 July 2012 ORGANIZATION "IETF EMAN Working Group" CONTACT-INFO "WG charter: http://datatracker.ietf.org/wg/eman/charter/ Mailing Lists: General Discussion: eman@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/eman Expires January 12, 2013 [Page 34] Internet-Draft July 2012 Archive: http://www.ietf.org/mail-archive/web/eman Editors: Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Bangalore, IN Phone: +91 80 4426 3947 Email: moulchan@cisco.com Brad Schoening 44 Rivers Edge Drive Little Silver, NJ 07739 US Email: brad@bradschoening.com Juergen Quittek NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-115 Email: quittek@neclab.eu Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg DE Phone: +49 6221 4342-128 Email: Thomas.Dietz@nw.neclab.eu Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Degem 1831 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com" DESCRIPTION Expires January 12, 2013 [Page 35] Internet-Draft July 2012 "This MIB is used to monitor power and energy in devices. This table sparse extension of the eoTable from the ENERGY-AWARE-MIB. As a requirement [EMAN-AWARE-MIB] should be implemented and three MIB objects from ENTITY-MIB (entPhysicalIndex, entPhysicalName and entPhysicalUris)MUST be implemented. " REVISION "201207110000Z" -- 11 July 2012 DESCRIPTION "Initial version, published as RFC XXXX." ::= { mib-2 xxx } energyObjectMibNotifs OBJECT IDENTIFIER ::= { energyObjectMib 0 } energyObjectMibObjects OBJECT IDENTIFIER ::= { energyObjectMib 1 } energyObjectMibConform OBJECT IDENTIFIER ::= { energyObjectMib 2 } -- Textual Conventions IANAPowerStateSet ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "IANAPowerState is a textual convention that describes Power State Sets and Power State Set Values an Energy Object supports. IANA has created a registry of Power State supported by an Energy Object and IANA shall administer the list of Power State Sets and Power States. The textual convention assumes that power states in a power state set are limited to 255 distinct values. For a Power State Set S, the named number with the value S * 256 is allocated to indicate the power state set. For a Power State X Expires January 12, 2013 [Page 36] Internet-Draft July 2012 in the Power State S, the named number with the value S * 256 + X + 1 is allocated to represent the power state." REFERENCE "http://www.iana.org/assignments/eman RFC EDITOR NOTE: please change the previous URL if this is not the correct one after IANA assigned it." SYNTAX INTEGER { other(0), -- indicates other set unknown(255), -- unknown power state ieee1621(256), -- indicates IEEE1621 set ieee1621On(257), ieee1621Off(258), ieee1621Sleep(259), dmtf(512), -- indicates DMTF set dmtfOn(513), dmtfSleepLight(514), dmtfSleepDeep(515), dmtfOffHard(516), dmtfOffSoft(517), dmtfHibernate(518), dmtfPowerOffSoft(519), dmtfPowerOffHard(520), dmtfMasterBusReset(521), dmtfDiagnosticInterrapt(522), dmtfOffSoftGraceful(523), dmtfOffHardGraceful(524), dmtfMasterBusResetGraceful(525), dmtfPowerCycleOffSoftGraceful(526), dmtfPowerCycleHardGraceful(527), eman(1024), -- indicates EMAN set emanmechoff(1025), emansoftoff(1026), emanhibernate(1027), emansleep(1028), emanstandby(1029), emanready(1030), emanlowMinus(1031), emanlow(1032), emanmediumMinus(1033), emanmedium(1034), emanhighMinus(1035), emanhigh(1036) } Expires January 12, 2013 [Page 37] Internet-Draft July 2012 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 eoPowerUnitMultiplier, -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 } -- Objects eoMeterCapabilitiesTable OBJECT-TYPE SYNTAX SEQUENCE OF EoMeterCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is useful for helping applications determine the monitoring capabilities supported by the local management agents. It is possible for applications to know which tables are usable without going through a trial-and-error process." ::= { energyObjectMibObjects 1 } Expires January 12, 2013 [Page 38] Internet-Draft July 2012 eoMeterCapabilitiesEntry OBJECT-TYPE SYNTAX EoMeterCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes the metering capability of an Energy Object." INDEX { entPhysicalIndex } ::= { eoMeterCapabilitiesTable 1 } EoMeterCapabilitiesEntry ::= SEQUENCE { eoMeterCapability BITS } eoMeterCapability OBJECT-TYPE SYNTAX BITS { none(0), powermetering(1), -- power measurement energymetering(2), -- energy measurement powercharacteristics(3) -- Power Characteristics } MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the Energy monitoring capabilities supported by this agent. This object use a BITS syntax and indicate the MIB groups supported by the probe. By reading the value of this object, it is possible to determine the MIB tables supported. " ::= { eoMeterCapabilitiesEntry 1 } eoPowerTable OBJECT-TYPE SYNTAX SEQUENCE OF EoPowerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists Energy Objects." ::= { energyObjectMibObjects 2 } eoPowerEntry OBJECT-TYPE SYNTAX EoPowerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires January 12, 2013 [Page 39] Internet-Draft July 2012 "An entry describes the power usage of an Energy Object." INDEX { entPhysicalIndex } ::= { eoPowerTable 1 } EoPowerEntry ::= SEQUENCE { eoPower Integer32, eoPowerNameplate Integer32, eoPowerUnitMultiplier UnitMultiplier, eoPowerAccuracy Integer32, eoPowerMeasurementCaliber INTEGER, eoPowerCurrentType INTEGER, eoPowerOrigin INTEGER, eoPowerAdminState IANAPowerStateSet, eoPowerOperState IANAPowerStateSet, eoPowerStateEnterReason OwnerString } eoPower OBJECT-TYPE SYNTAX Integer32 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the power measured for the Energy Object. For alternating current, this value is obtained as an average over fixed number of AC cycles. . This value is specified in SI units of watts with the magnitude of watts (milliwatts, kilowatts, etc.) indicated separately in eoPowerUnitMultiplier. The accuracy of the measurement is specfied in eoPowerAccuracy. The direction of power flow is indicated by the sign on eoPower. If the Energy Object is consuming power, the eoPower value will be positive. If the Energy Object is producing power, the eoPower value will be negative. The eoPower MUST be less than or equal to the maximum power that can be consumed at the power state specified by eoPowerState. The eoPowerMeasurementCaliber object specifies how the usage value reported by eoPower was obtained. The eoPower value must report 0 if the eoPowerMeasurementCaliber is Expires January 12, 2013 [Page 40] Internet-Draft July 2012 'unavailable'. For devices that can not measure or report power, this option can be used." ::= { eoPowerEntry 1 } eoPowerNameplate OBJECT-TYPE SYNTAX Integer32 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the rated maximum consumption for the fully populated Energy Object. The nameplate power requirements are the maximum power numbers and, in almost all cases, are well above the expected operational consumption. The eoPowerNameplate is widely used for power provisioning. This value is specified in either units of watts or voltage and current. The units are therefore SI watts or equivalent Volt-Amperes with the magnitude (milliwatts, kilowatts, etc.) indicated separately in eoPowerUnitMultiplier." ::= { eoPowerEntry 2 } eoPowerUnitMultiplier OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of watts for the usage value in eoPower and eoPowerNameplate." ::= { eoPowerEntry 3 } eoPowerAccuracy OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates a percentage value, in 100ths of a percent, representing the assumed accuracy of the usage reported by eoPower. For example: The value 1010 means the reported usage is accurate to +/- 10.1 percent. This value is zero if the accuracy is unknown or not applicable based upon the measurement method. ANSI and IEC define the following accuracy classes for power measurement: IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. Expires January 12, 2013 [Page 41] Internet-Draft July 2012 ANSI C12.20 class 0.2, 0.5" ::= { eoPowerEntry 4 } eoPowerMeasurementCaliber OBJECT-TYPE SYNTAX INTEGER { unavailable(1) , unknown(2), actual(3) , estimated(4), presumed(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies how the usage value reported by eoPower was obtained: - unavailable(1): Indicates that the usage is not available. In such a case, the eoPower value must be 0 for devices that can not measure or report power this option can be used. - unknown(2): Indicates that the way the usage was determined is unknown. In some cases, entities report aggregate power on behalf of another device. In such cases it is not known whether the usage reported is actual(2), estimated(3) or presumed (4). - actual(3): Indicates that the reported usage was measured by the entity through some hardware or direct physical means. The usage data reported is not presumed (4) or estimated (3) but the real apparent current energy consumption rate. - estimated(4): Indicates that the usage was not determined by physical measurement. The value is a derivation based upon the device type, state, and/or current utilization using some algorithm or heuristic. It is presumed that the entity's state and current configuration were used to compute the value. - presumed(5): Indicates that the usage was not determined by physical measurement, algorithm or derivation. The usage was reported based upon external tables, specifications, and/or model information. For example, a PC Model X draws 200W, while a PC Model Y draws 210W" Expires January 12, 2013 [Page 42] Internet-Draft July 2012 ::= { eoPowerEntry 5 } eoPowerCurrentType OBJECT-TYPE SYNTAX INTEGER { ac(1), dc(2), unknown(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether the eoUsage for the Energy Object reports alternative current AC(1), direct current DC(2), or that the current type is unknown(3)." ::= { eoPowerEntry 6 } eoPowerOrigin OBJECT-TYPE SYNTAX INTEGER { self (1), remote (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the source of power measurement and can be useful when modeling the power usage of attached devices. The power measurement can be performed by the entity itself or the power measurement of the entity can be reported by another trusted entity using a protocol extension. A value of self(1) indicates the measurement is performed by the entity, whereas remote(2) indicates that the measurement was performed by another entity." ::= { eoPowerEntry 7 } eoPowerAdminState OBJECT-TYPE SYNTAX IANAPowerStateSet MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the desired Power State and the Power State Set for the Energy Object. Note that other(0) is not a Power State Set and unknown(255) is not a Power State as such, but simply an indication that the Power State of the Energy Object is unknown. Possible values of eoPowerAdminState within the Power State Set are registered at IANA. Expires January 12, 2013 [Page 43] Internet-Draft July 2012 A current list of assignments can be found at RFC-EDITOR: please check the location after IANA" ::= { eoPowerEntry 8 } eoPowerOperState OBJECT-TYPE SYNTAX IANAPowerStateSet MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the current operational Power State and the Power State Set for the Energy Object. other(0) is not a Power State Set and unknown(255) is not a Power State as such, but simply an indication that the Power State of the Energy Object is unknown. Possible values of eoPowerAdminState within the Power State Set are registered at IANA. A current list of assignments can be found at RFC-EDITOR: please check the location after IANA" ::= { eoPowerEntry 9 } eoPowerStateEnterReason OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "This string object describes the reason for the eoPowerAdminState transition Alternatively, this string may contain with the entity that configured this Energy Object to this Power State." DEFVAL { "" } ::= { eoPowerEntry 10 } eoPowerStateTable OBJECT-TYPE SYNTAX SEQUENCE OF EoPowerStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table enumerates the maximum power usage, in watts, for every single supported Power State of each Energy Object. Expires January 12, 2013 [Page 44] Internet-Draft July 2012 This table has an expansion-dependent relationship on the eoPowerTable, containing rows describing each Power State for the corresponding Energy Object. For every Energy Object in the eoPowerTable, there is a corresponding entry in this table." ::= { energyObjectMibObjects 3 } eoPowerStateEntry OBJECT-TYPE SYNTAX EoPowerStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A eoPowerStateEntry extends a corresponding eoPowerEntry. This entry displays max usage values at every single possible Power State supported by the Energy Object. For example, given the values of a Energy Object corresponding to a maximum usage of 11W at the state 1 (mechoff), 6 (ready), 8 (mediumMinus), 12 (High): State MaxUsage Units 1 (mechoff 0 W 2 (softoff) 0 W 3 (hibernate) 0 W 4 (sleep) 0 W 5 (standby) 0 W 6 (ready) 8 W 7 (lowMinus) 8 W 8 (low) 11 W 9 (medimMinus) 11 W 10 (medium) 11 W 11 (highMinus) 11 W 12 (high) 11 W Furthermore, this table extends to return the total time in each Power State, along with the number of times a particular Power State was entered." INDEX { entPhysicalIndex, eoPowerStateIndex } ::= { eoPowerStateTable 1 } EoPowerStateEntry ::= SEQUENCE { eoPowerStateIndex IANAPowerStateSet, eoPowerStateMaxPower Integer32, eoPowerStatePowerUnitMultiplier UnitMultiplier, eoPowerStateTotalTime TimeTicks, Expires January 12, 2013 [Page 45] Internet-Draft July 2012 eoPowerStateEnterCount Counter32 } eoPowerStateIndex OBJECT-TYPE SYNTAX IANAPowerStateSet MAX-ACCESS not-accessible STATUS current DESCRIPTION " This object specifies the index of the Power State of the Energy Object within a Power State Set. The semantics of the specific Power State can be obtained from the Power State Set definition." ::= { eoPowerStateEntry 1 } eoPowerStateMaxPower OBJECT-TYPE SYNTAX Integer32 UNITS "Watts" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the maximum power for the Energy Object at the particular Power State. This value is specified in SI units of watts with the magnitude of the units (milliwatts, kilowatts, etc.) indicated separately in eoPowerStatePowerUnitMultiplier. If the maximum power is not known for a certain Power State, then the value is encoded as 0xFFFF. For Power States not enumerated, the value of eoPowerStateMaxPower might be interpolated by using the next highest supported Power State." ::= { eoPowerStateEntry 2 } eoPowerStatePowerUnitMultiplier OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "The magnitude of watts for the usage value in eoPowerStateMaxPower." ::= { eoPowerStateEntry 3 } eoPowerStateTotalTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current Expires January 12, 2013 [Page 46] Internet-Draft July 2012 DESCRIPTION "This object indicates the total time in hundreds of seconds that the Energy Object has been in this power state since the last reset, as specified in the sysUpTime." ::= { eoPowerStateEntry 4 } eoPowerStateEnterCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates how often the Energy Object has entered this power state, since the last reset of the device as specified in the sysUpTime." ::= { eoPowerStateEntry 5 } eoEnergyParametersTable OBJECT-TYPE SYNTAX SEQUENCE OF EoEnergyParametersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to configure the parameters for Energy measurement collection in the table eoEnergyTable. This table allows the configuration of different measurement settings on the same Energy Object." ::= { energyObjectMibObjects 4 } eoEnergyParametersEntry OBJECT-TYPE SYNTAX EoEnergyParametersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry controls an energy measurement in eoEnergyTable." INDEX { eoEnergyParametersIndex } ::= { eoEnergyParametersTable 1 } EoEnergyParametersEntry ::= SEQUENCE { eoEnergyObjectIndex PhysicalIndex, eoEnergyParametersIndex Integer32, eoEnergyParametersIntervalLength TimeInterval, eoEnergyParametersIntervalNumber Integer32, eoEnergyParametersIntervalMode Integer32, eoEnergyParametersIntervalWindow TimeInterval, Expires January 12, 2013 [Page 47] Internet-Draft July 2012 eoEnergyParametersSampleRate Integer32, eoEnergyParametersStatus RowStatus } eoEnergyObjectIndex OBJECT-TYPE SYNTAX PhysicalIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The unique value, to identify the specific Energy Object on which the measurement is applied, the same index used in the eoPowerTable to identify the Energy Object." ::= { eoEnergyParametersEntry 1 } eoEnergyParametersIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the index of the Energy Parameters setting for collection of energy measurements for an Energy Object. An Energy Object can have multiple eoEnergyParametersIndex, depending on the capability of the Energy Object" ::= { eoEnergyParametersEntry 2 } eoEnergyParametersIntervalLength OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the length of time in hundredth of seconds over which to compute the average eoEnergyConsumed measurement in the eoEnergyTable table. The computation is based on the Energy Object's internal sampling rate of power consumed or produced by the Energy Object. The sampling rate is the rate at which the Energy Object can read the power usage and may differ based on device capabilities. The average energy consumption is then computed over the length of the interval." DEFVAL { 90000 } ::= { eoEnergyParametersEntry 3 } eoEnergyParametersIntervalNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current Expires January 12, 2013 [Page 48] Internet-Draft July 2012 DESCRIPTION "The number of intervals maintained in the eoEnergyTable. Each interval is characterized by a specific eoEnergyCollectionStartTime, used as an index to the table eoEnergyTable. Whenever the maximum number of entries is reached, the measurement over the new interval replacesthe oldest measurement. There is one exception to this rule: when the eoEnergyMaxConsumed and/or eoEnergyMaxProduced are in (one of) the two oldest measurement(s), they are left untouched and the next oldest measurement is replaced." DEFVAL { 10 } ::= { eoEnergyParametersEntry 4 } eoEnergyParametersIntervalMode OBJECT-TYPE SYNTAX INTEGER { period(1), sliding(2), total(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "A control object to define the mode of interval calculation for the computation of the average eoEnergyConsumed or eoEnergyProduced measurement in the eoEnergyTable table. A mode of period(1) specifies non-overlapping periodic measurements. A mode of sliding(2) specifies overlapping sliding windows where the interval between the start of one interval and the next is defined in eoEnergyParametersIntervalWindow. A mode of total(3) specifies non-periodic measurement. In this mode only one interval is used as this is a continuous measurement since the last reset. The value of eoEnergyParametersIntervalNumber should be (1) one and eoEnergyParametersIntervalLength is ignored. " ::= { eoEnergyParametersEntry 5 } eoEnergyParametersIntervalWindow OBJECT-TYPE SYNTAX TimeInterval MAX-ACCESS read-create STATUS current DESCRIPTION Expires January 12, 2013 [Page 49] Internet-Draft July 2012 "The length of the duration window between the starting time of one sliding window and the next starting time in hundredth of seconds, in order to compute the average of eoEnergyConsumed, eoEnergyProduced measurements in the eoEnergyTable table. This is valid only when the eoEnergyParametersIntervalMode is sliding(2). The eoEnergyParametersIntervalWindow value should be a multiple of eoEnergyParametersSampleRate." ::= { eoEnergyParametersEntry 6 } eoEnergyParametersSampleRate OBJECT-TYPE SYNTAX Integer32 UNITS "Milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The sampling rate, in milliseconds, at which the Energy Object should poll power usage in order to compute the average eoEnergyConsumed, eoEnergyProduced measurements in the table eoEnergyTable. The Energy Object should initially set this sampling rate to a reasonable value, i.e., a compromise between intervals that will provide good accuracy by not being too long, but not so short that they affect the Energy Object performance by requesting continuous polling. If the sampling rate is unknown, the value 0 is reported. The sampling rate should be selected so that eoEnergyParametersIntervalWindow is a multiple of eoEnergyParametersSampleRate." DEFVAL { 1000 } ::= { eoEnergyParametersEntry 7 } eoEnergyParametersStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. The eoEnergyParametersStatus is used to start or stop energy usage logging. An entry status may not be active(1) unless all objects in the entry have an appropriate value. If this object is not equal to active(1), all associated usage-data logged into the eoEnergyTable will be deleted. The data can be destroyed by setting up the eoEnergyParametersStatus to destroy(2)." ::= {eoEnergyParametersEntry 8 } Expires January 12, 2013 [Page 50] Internet-Draft July 2012 eoEnergyTable OBJECT-TYPE SYNTAX SEQUENCE OF EoEnergyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists Energy Object energy measurements. Entries in this table are only created if the corresponding value of object eoPowerMeasurementCaliber is active(2), i.e., if the power is actually metered." ::= { energyObjectMibObjects 5 } eoEnergyEntry OBJECT-TYPE SYNTAX EoEnergyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing energy measurements." INDEX { eoEnergyParametersIndex, eoEnergyCollectionStartTime } ::= { eoEnergyTable 1 } EoEnergyEntry ::= SEQUENCE { eoEnergyCollectionStartTime TimeTicks, eoEnergyConsumed Integer32, eoEnergyProduced Integer32, eoEnergyNet Integer32, eoEnergyUnitMultiplier UnitMultiplier, eoEnergyAccuracy Integer32, eoEnergyMaxConsumed Integer32, eoEnergyMaxProduced Integer32, eoEnergyDiscontinuityTime TimeStamp } eoEnergyCollectionStartTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of seconds" MAX-ACCESS not-accessible STATUS current DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized, as specified in the sysUpTime [RFC3418]. This object is useful for reference of interval periods for which the energy is measured." ::= { eoEnergyEntry 1 } Expires January 12, 2013 [Page 51] Internet-Draft July 2012 eoEnergyConsumed OBJECT-TYPE SYNTAX Integer32 UNITS "Watt-hours" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the energy consumed in units of watt- hours for the Energy Object over the defined interval. This value is specified in the common billing units of watt- hours with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) indicated separately in eoEnergyUnitMultiplier." ::= { eoEnergyEntry 2 } eoEnergyProduced OBJECT-TYPE SYNTAX Integer32 UNITS "Watt-hours" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the energy produced in units of watt- hours for the Energy Object over the defined interval. This value is specified in the common billing units of watt- hours with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) indicated separately in eoEnergyUnitMultiplier." ::= { eoEnergyEntry 3 } eoEnergyNet OBJECT-TYPE SYNTAX Integer32 UNITS "Watt-hours" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the resultant of the energy consumed and energy produced for an energy object in units of watt-hours for the Energy Object over the defined interval. This value is specified in the common billing units of watt-hours with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) indicated separately in eoEnergyUnitMultiplier." ::= { eoEnergyEntry 4 } eoEnergyUnitMultiplier OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the magnitude of watt-hours for the energy field in eoEnergyConsumed, eoEnergyProduced, Expires January 12, 2013 [Page 52] Internet-Draft July 2012 eoEnergyNet, eoEnergyMaxConsumed, and eoEnergyMaxProduced ." ::= { eoEnergyEntry 5 } eoEnergyAccuracy OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates a percentage value, in 100ths of a percent, representing the presumed accuracy of Energy usage reporting. eoEnergyAccuracy is applicable to all Energy measurements in the eoEnergyTable. For example: 1010 means the reported usage is accurate to +/- 10.1 percent. This value is zero if the accuracy is unknown." ::= { eoEnergyEntry 6 } eoEnergyMaxConsumed OBJECT-TYPE SYNTAX Integer32 UNITS "Watt-hours" MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the maximum energy ever observed in eoEnergyConsumed since the monitoring started. This value is specified in the common billing units of watt-hours with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) indicated separately in eoEnergyUnitMultiplier." ::= { eoEnergyEntry 7 } eoEnergyMaxProduced OBJECT-TYPE SYNTAX Integer32 UNITS "Watt-hours" MAX-ACCESS read-only STATUS current DESCRIPTION "This object is the maximum energy ever observed in eoEnergyEnergyProduced since the monitoring started. This value is specified in the units of watt-hours with the magnitude of watt-hours (kW-Hr, MW-Hr, etc.) indicated separately in eoEnergyEnergyUnitMultiplier." Expires January 12, 2013 [Page 53] Internet-Draft July 2012 ::= { eoEnergyEntry 8 } eoEnergyDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime [RFC3418] on the most recent occasion at which any one or more of this entity's energy counters in this table suffered a discontinuity: eoEnergyConsumed, eoEnergyProduced or eoEnergyNet. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value." ::= { eoEnergyEntry 9 } -- Notifications eoPowerStateChange NOTIFICATION-TYPE OBJECTS {eoPowerAdminState, eoPowerOperState, eoPowerStateEnterReason} STATUS current DESCRIPTION "The SNMP entity generates the eoPowerStateChange when the value(s) of eoPowerAdminState or eoPowerOperState, in the context of the Power State Set, have changed for the Energy Object represented by the entPhysicalIndex." ::= { energyObjectMibNotifs 1 } -- Conformance energyObjectMibCompliances OBJECT IDENTIFIER ::= { energyObjectMib 3 } energyObjectMibGroups OBJECT IDENTIFIER ::= { energyObjectMib 4 } energyObjectMibFullCompliance 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. The entPhysicalIndex, entPhysicalName, and Expires January 12, 2013 [Page 54] Internet-Draft July 2012 entPhysicalUris [RFC4133] MUST be implemented." MODULE -- this module MANDATORY-GROUPS { energyObjectMibTableGroup, energyObjectMibStateTableGroup, energyObjectMibNotifGroup } GROUP energyObjectMibEnergyTableGroup DESCRIPTION "A compliant implementation does not have to implement. The entPhysicalIndex, entPhysicalName, and entPhysicalUris [RFC4133] MUST be implemented." GROUP energyObjectMibEnergyParametersTableGroup DESCRIPTION "A compliant implementation does not have to implement. The entPhysicalIndex, entPhysicalName, and entPhysicalUris [RFC4133] MUST be implemented." GROUP energyObjectMibMeterCapabilitiesTableGroup DESCRIPTION "A compliant implementation does not have to implement. The entPhysicalIndex, entPhysicalName, and entPhysicalUris [RFC4133] MUST be implemented." ::= { energyObjectMibCompliances 1 } energyObjectMibReadOnlyCompliance 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 cannot be configured with this MIB. The entPhysicalIndex, entPhysicalName, and entPhysicalUris from [RFC4133] MUST be implemented. " MODULE -- this module MANDATORY-GROUPS { energyObjectMibTableGroup, energyObjectMibStateTableGroup, energyObjectMibNotifGroup } Expires January 12, 2013 [Page 55] Internet-Draft July 2012 OBJECT eoPowerOperState MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { energyObjectMibCompliances 2 } -- Units of Conformance energyObjectMibTableGroup OBJECT-GROUP OBJECTS { eoPower, eoPowerNameplate, eoPowerUnitMultiplier, eoPowerAccuracy, eoPowerMeasurementCaliber, eoPowerCurrentType, eoPowerOrigin, eoPowerAdminState, eoPowerOperState, eoPowerStateEnterReason } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the PowerMonitor." ::= { energyObjectMibGroups 1 } energyObjectMibStateTableGroup OBJECT-GROUP OBJECTS { eoPowerStateMaxPower, eoPowerStatePowerUnitMultiplier, eoPowerStateTotalTime, eoPowerStateEnterCount } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the Power State." ::= { energyObjectMibGroups 2 } energyObjectMibEnergyParametersTableGroup OBJECT-GROUP OBJECTS { eoEnergyObjectIndex, eoEnergyParametersIndex, Expires January 12, 2013 [Page 56] Internet-Draft July 2012 eoEnergyParametersIntervalLength, eoEnergyParametersIntervalNumber, eoEnergyParametersIntervalMode, eoEnergyParametersIntervalWindow, eoEnergyParametersSampleRate, eoEnergyParametersStatus } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the configuration of the Energy Table." ::= { energyObjectMibGroups 3 } energyObjectMibEnergyTableGroup OBJECT-GROUP OBJECTS { -- Note that object -- eoEnergyCollectionStartTime is not -- included since it is not-accessible eoEnergyConsumed, eoEnergyProduced, eoEnergyNet, eoEnergyUnitMultiplier, eoEnergyAccuracy, eoEnergyMaxConsumed, eoEnergyMaxProduced, eoEnergyDiscontinuityTime } STATUS current DESCRIPTION "This group contains the collection of all the objects related to the Energy Table." ::= { energyObjectMibGroups 4 } energyObjectMibMeterCapabilitiesTableGroup OBJECT-GROUP OBJECTS { eoMeterCapability } STATUS current DESCRIPTION "This group contains the object indicating the capability of the Energy Object" ::= { energyObjectMibGroups 5 } energyObjectMibNotifGroup NOTIFICATION-GROUP Expires January 12, 2013 [Page 57] Internet-Draft July 2012 NOTIFICATIONS { eoPowerStateChange } STATUS current DESCRIPTION "This group contains the notifications for the power and energy monitoring MIB Module." ::= { energyObjectMibGroups 6 } END -- ************************************************************ -- -- This MIB module is used to monitor Power Characteristics of -- networked devices with measurements. -- -- This MIB module is an extension of energyObjectMib module. -- -- ************************************************************* POWER-CHARACTERISTICS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Integer32 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF UnitMultiplier FROM ENERGY-OBJECT-MIB OwnerString FROM RMON-MIB entPhysicalIndex FROM ENTITY-MIB; powerCharacteristicsMIB MODULE-IDENTITY LAST-UPDATED "201207110000Z" -- 11 July 2012 ORGANIZATION "IETF EMAN Working Group" CONTACT-INFO Expires January 12, 2013 [Page 58] Internet-Draft July 2012 "WG charter: http://datatracker.ietf.org/wg/eman/charter/ Mailing Lists: General Discussion: eman@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/eman Archive: http://www.ietf.org/mail-archive/web/eman Editors: Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Bangalore, IN Phone: +91 80 4426 3947 Email: moulchan@cisco.com Brad Schoening 44 Rivers Edge Drive Little Silver, NJ 07739 US Email: brad@bradschoening.com Juergen Quittek NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-115 Email: quittek@neclab.eu Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg DE Phone: +49 6221 4342-128 Email: Thomas.Dietz@nw.neclab.eu Expires January 12, 2013 [Page 59] Internet-Draft July 2012 Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Degem 1831 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com" DESCRIPTION "This MIB is used to report AC Power Characteristics in devices. The table is a sparse augmentation of the eoPowerTable table from the energyObjectMib module. Both three-phase and single-phase power configurations are supported. As a requirement for this MIB module, [EMAN-AWARE-MIB] should be implemented and three MIB objects from ENTITY-MIB (entPhysicalIndex, entPhysicalName and entPhysicalUris) MUST be implemented. " REVISION "201207110000Z" -- 11 July 2012 DESCRIPTION "Initial version, published as RFC YYY." ::= { mib-2 yyy } powerCharacteristicsMIBConform OBJECT IDENTIFIER ::= { powerCharacteristicsMIB 0 } powerCharacteristicsMIBObjects OBJECT IDENTIFIER ::= { powerCharacteristicsMIB 1 } -- Objects eoACPwrCharTable OBJECT-TYPE SYNTAX SEQUENCE OF EoACPwrCharEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires January 12, 2013 [Page 60] Internet-Draft July 2012 "This table defines Power Characteristics measurements for supported entPhysicalIndex entities. It is a sparse extension of the eoPowerTable." ::= { powerCharacteristicsMIBObjects 1 } eoACPwrCharEntry OBJECT-TYPE SYNTAX EoACPwrCharEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a sparse extension of the eoPowerTable with entries for Power Characteristics measurements or configuration. Each measured value corresponds to an attribute in IEC 61850-7-4 for non-phase measurements within the object MMUX." INDEX {entPhysicalIndex } ::= { eoACPwrCharTable 1 } EoACPwrCharEntry ::= SEQUENCE { eoACPwrCharConfiguration INTEGER, eoACPwrCharAvgVoltage Integer32, eoACPwrCharAvgCurrent Integer32, eoACPwrCharFrequency Integer32, eoACPwrCharPowerUnitMultiplier UnitMultiplier, eoACPwrCharPowerAccuracy Integer32, eoACPwrCharTotalActivePower Integer32, eoACPwrCharTotalReactivePower Integer32, eoACPwrCharTotalApparentPower Integer32, eoACPwrCharTotalPowerFactor Integer32, eoACPwrCharThdAmpheres Integer32, eoACPwrCharThdVoltage Integer32 } eoACPwrCharConfiguration OBJECT-TYPE SYNTAX INTEGER { sngl(1), del(2), wye(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Configuration describes the physical configurations of the power supply lines: * alternating current, single phase (SNGL) * alternating current, three phase delta (DEL) Expires January 12, 2013 [Page 61] Internet-Draft July 2012 * alternating current, three phase Y (WYE) Three-phase configurations can be either connected in a triangular delta (DEL) or star Y (WYE) system. WYE systems have a shared neutral voltage, while DEL systems do not. Each phase is offset 120 degrees to each other." ::= { eoACPwrCharEntry 1 } eoACPwrCharAvgVoltage OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 Volt AC" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value for average of the voltage measured over an integral number of AC cycles For a 3-phase system, this is the average voltage (V1+V2+V3)/3. IEC 61850-7-4 measured value attribute 'Vol'" ::= { eoACPwrCharEntry 2 } eoACPwrCharAvgCurrent OBJECT-TYPE SYNTAX Integer32 UNITS "Ampheres" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the current per phase. IEC 61850- 7-4 attribute 'Amp'" ::= { eoACPwrCharEntry 3 } eoACPwrCharFrequency OBJECT-TYPE SYNTAX Integer32 (4500..6500) -- UNITS 0.01 Hertz UNITS "hertz" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value for the basic frequency of the AC circuit. IEC 61850-7-4 attribute 'Hz'." ::= { eoACPwrCharEntry 4 } eoACPwrCharPowerUnitMultiplier OBJECT-TYPE SYNTAX UnitMultiplier MAX-ACCESS read-only STATUS current DESCRIPTION Expires January 12, 2013 [Page 62] Internet-Draft July 2012 "The magnitude of watts for the usage value in eoACPwrCharTotalActivePower, eoACPwrCharTotalReactivePower and eoACPwrCharTotalApparentPower measurements. For 3-phase power systems, this will include eoACPwrCharPhaseActivePower, eoACPwrCharPhaseReactivePower and eoACPwrCharPhaseApparentPower" ::= { eoACPwrCharEntry 5 } eoACPwrCharPowerAccuracy OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates a percentage value, in 100ths of a percent, representing the presumed accuracy of active, reactive, and apparent power usage reporting. For example: 1010 means the reported usage is accurate to +/- 10.1 percent. This value is zero if the accuracy is unknown. ANSI and IEC define the following accuracy classes for power measurement: IEC 62053-22 & 60044-1 class 0.1, 0.2, 0.5, 1 & 3. ANSI C12.20 class 0.2 & 0.5" ::= { eoACPwrCharEntry 6 } eoACPwrCharTotalActivePower OBJECT-TYPE SYNTAX Integer32 UNITS " watts" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the actual power delivered to or consumed by the load. IEC 61850-7-4 attribute 'TotW'." ::= { eoACPwrCharEntry 7 } eoACPwrCharTotalReactivePower OBJECT-TYPE SYNTAX Integer32 UNITS "volt-amperes reactive" MAX-ACCESS read-only STATUS current DESCRIPTION "A mesured value of the reactive portion of the apparent power. IEC 61850-7-4 attribute 'TotVAr'." ::= { eoACPwrCharEntry 8 } Expires January 12, 2013 [Page 63] Internet-Draft July 2012 eoACPwrCharTotalApparentPower OBJECT-TYPE SYNTAX Integer32 UNITS "volt-amperes" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the voltage and current which determines the apparent power. The apparent power is the vector sum of real and reactive power. Note: watts and volt-ampheres are equivalent units and may be combined. IEC 61850-7-4 attribute 'TotVA'." ::= { eoACPwrCharEntry 9 } eoACPwrCharTotalPowerFactor OBJECT-TYPE SYNTAX Integer32 (-10000..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value ratio of the real power flowing to the load versus the apparent power. It is dimensionless and expressed here as a percentage value in 100ths of a percent. A power factor of 100% indicates there is no inductance load and thus no reactive power. Power Factor can be positive or negative, where the sign should be in lead/lag (IEEE) form. IEC 61850-7-4 attribute 'TotPF'." ::= { eoACPwrCharEntry 10 } eoACPwrCharThdAmpheres OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "A calculated value for the current total harmonic distortion (THD). Method of calculation is not specified. IEC 61850-7-4 attribute 'ThdAmp'." ::= { eoACPwrCharEntry 11 } eoACPwrCharThdVoltage OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION Expires January 12, 2013 [Page 64] Internet-Draft July 2012 "A calculated value for the voltage total harmonic distortion (THD). Method of calculation is not specified. IEC 61850-7-4 attribute 'ThdVol'." ::= { eoACPwrCharEntry 12 } eoACPwrCharPhaseTable OBJECT-TYPE SYNTAX SEQUENCE OF EoACPwrCharPhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes 3-phase Power Characteristics measurements. It is a sparse extension of the eoACPwrCharTable." ::= { powerCharacteristicsMIBObjects 2 } eoACPwrCharPhaseEntry OBJECT-TYPE SYNTAX EoACPwrCharPhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes common 3-phase Power Characteristics measurements. This optional table describes 3-phase Power Characteristics measurements, with three entries for each supported entPhysicalIndex entity. Entities having single phase power shall not have any entities. This table describes attributes common to both WYE and DEL. Entities having single phase power shall not have any entries here. It is a sparse extension of the eoACPwrCharTable. These attributes correspond to IEC 61850-7.4 MMXU phase measurements." INDEX { entPhysicalIndex, eoPhaseIndex } ::= { eoACPwrCharPhaseTable 1 } EoACPwrCharPhaseEntry ::= SEQUENCE { eoPhaseIndex Integer32, eoACPwrCharPhaseAvgCurrent Integer32, eoACPwrCharPhaseActivePower Integer32, eoACPwrCharPhaseReactivePower Integer32, eoACPwrCharPhaseApparentPower Integer32, eoACPwrCharPhasePowerFactor Integer32, eoACPwrCharPhaseImpedance Integer32 } Expires January 12, 2013 [Page 65] Internet-Draft July 2012 eoPhaseIndex OBJECT-TYPE SYNTAX Integer32 (0..359) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A phase angle typically corresponding to 0, 120, 240." ::= { eoACPwrCharPhaseEntry 1 } eoACPwrCharPhaseAvgCurrent OBJECT-TYPE SYNTAX Integer32 UNITS "Ampheres" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the current per phase. IEC 61850- 7-4 attribute 'A'" ::= { eoACPwrCharPhaseEntry 2 } eoACPwrCharPhaseActivePower OBJECT-TYPE SYNTAX Integer32 UNITS " watts" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the actual power delivered to or consumed by the load. IEC 61850-7-4 attribute 'W'" ::= { eoACPwrCharPhaseEntry 3 } eoACPwrCharPhaseReactivePower OBJECT-TYPE SYNTAX Integer32 UNITS "volt-amperes reactive" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the reactive portion of the apparent power. IEC 61850-7-4 attribute 'VAr'" ::= { eoACPwrCharPhaseEntry 4 } eoACPwrCharPhaseApparentPower OBJECT-TYPE SYNTAX Integer32 UNITS "volt-amperes" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the voltage and current determines the apparent power. Active plus reactive power equals the total apparent power. Expires January 12, 2013 [Page 66] Internet-Draft July 2012 Note: Watts and volt-ampheres are equivalent units and may be combined. IEC 61850-7-4 attribute 'VA'." ::= { eoACPwrCharPhaseEntry 5 } eoACPwrCharPhasePowerFactor OBJECT-TYPE SYNTAX Integer32 (-10000..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value ratio of the real power flowing to the load versus the apparent power for this phase. IEC 61850-7-4 attribute 'PF'. Power Factor can be positive or negative where the sign should be in lead/lag (IEEE) form." ::= { eoACPwrCharPhaseEntry 6 } eoACPwrCharPhaseImpedance OBJECT-TYPE SYNTAX Integer32 UNITS "volt-amperes" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of the impedance. IEC 61850-7-4 attribute 'Z'." ::= { eoACPwrCharPhaseEntry 7 } eoACPwrCharDelPhaseTable OBJECT-TYPE SYNTAX SEQUENCE OF EoACPwrCharDelPhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes DEL configuration phase-to-phase Power Characteristics measurements. This is a sparse extension of the eoACPwrCharPhaseTable." ::= { powerCharacteristicsMIBObjects 3 } eoACPwrCharDelPhaseEntry OBJECT-TYPE SYNTAX EoACPwrCharDelPhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describes Power Characteristics attributes of a phase in a DEL 3-phase power system. Voltage measurements are provided both relative to each other and zero. Expires January 12, 2013 [Page 67] Internet-Draft July 2012 Measured values are from IEC 61850-7-2 MMUX and THD from MHAI objects. For phase-to-phase measurements, the eoPhaseIndex is compared against the following phase at +120 degrees. Thus, the possible values are: eoPhaseIndex Next Phase Angle 0 120 120 240 240 0 " INDEX { entPhysicalIndex, eoPhaseIndex} ::= { eoACPwrCharDelPhaseTable 1} EoACPwrCharDelPhaseEntry ::= SEQUENCE { eoACPwrCharDelPhaseToNextPhaseVoltage Integer32, eoACPwrCharDelThdPhaseToNextPhaseVoltage Integer32, eoACPwrCharDelThdCurrent Integer32 } eoACPwrCharDelPhaseToNextPhaseVoltage OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 Volt AC" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of phase to next phase voltages, where the next phase is IEC 61850-7-4 attribute 'PPV'." ::= { eoACPwrCharDelPhaseEntry 2 } eoACPwrCharDelThdPhaseToNextPhaseVoltage OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "A calculated value for the voltage total harmonic disortion for phase to next phase. Method of calculation is not specified. IEC 61850-7-4 attribute 'ThdPPV'." ::= { eoACPwrCharDelPhaseEntry 3 } eoACPwrCharDelThdCurrent OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION Expires January 12, 2013 [Page 68] Internet-Draft July 2012 "A calculated value for the voltage total harmonic disortion (THD) for phase to phase. Method of calculation is not specified. IEC 61850-7-4 attribute 'ThdPPV'." ::= { eoACPwrCharDelPhaseEntry 4 } eoACPwrCharWyePhaseTable OBJECT-TYPE SYNTAX SEQUENCE OF EoACPwrCharWyePhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes WYE configuration phase-to-neutral Power Characteristics measurements. This is a sparse extension of the eoACPwrCharPhaseTable." ::= { powerCharacteristicsMIBObjects 4 } eoACPwrCharWyePhaseEntry OBJECT-TYPE SYNTAX EoACPwrCharWyePhaseEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes measurements of WYE configuration with phase to neutral Power Characteristics attributes. Three entries are required for each supported entPhysicalIndex entry. Voltage measurements are relative to neutral. This is a sparse extension of the eoACPwrCharPhaseTable. Each entry describes Power Characteristics attributes of one phase of a WYE 3-phase power system. Measured values are from IEC 61850-7-2 MMUX and THD from MHAI objects." INDEX { entPhysicalIndex, eoPhaseIndex } ::= { eoACPwrCharWyePhaseTable 1} EoACPwrCharWyePhaseEntry ::= SEQUENCE { eoACPwrCharWyePhaseToNeutralVoltage Integer32, eoACPwrCharWyePhaseCurrent Integer32, eoACPwrCharWyeThdPhaseToNeutralVoltage Integer32 } eoACPwrCharWyePhaseToNeutralVoltage OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 Volt AC" MAX-ACCESS read-only STATUS current Expires January 12, 2013 [Page 69] Internet-Draft July 2012 DESCRIPTION "A measured value of phase to neutral voltage. IEC 61850-7-4 attribute 'PhV'." ::= { eoACPwrCharWyePhaseEntry 1 } eoACPwrCharWyePhaseCurrent OBJECT-TYPE SYNTAX Integer32 UNITS "0.1 ampheres AC" MAX-ACCESS read-only STATUS current DESCRIPTION "A measured value of phase currents. IEC 61850-7-4 attribute 'A'." ::= { eoACPwrCharWyePhaseEntry 2 } eoACPwrCharWyeThdPhaseToNeutralVoltage OBJECT-TYPE SYNTAX Integer32 (0..10000) UNITS "hundredths of percent" MAX-ACCESS read-only STATUS current DESCRIPTION "A calculated value of the voltage total harmonic distortion (THD) for phase to neutral. IEC 61850-7-4 attribute 'ThdPhV'." ::= { eoACPwrCharWyePhaseEntry 3 } -- Conformance powerCharacteristicsMIBCompliances OBJECT IDENTIFIER ::= { powerCharacteristicsMIB 2 } powerCharacteristicsMIBGroups OBJECT IDENTIFIER ::= { powerCharacteristicsMIB 3 } powerCharacteristicsMIBFullCompliance 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. The entPhysicalIndex, entPhysicalName, and entPhysicalUris [RFC4133] MUST be implemented." MODULE -- this module MANDATORY-GROUPS { powerACPwrCharMIBTableGroup Expires January 12, 2013 [Page 70] Internet-Draft July 2012 } GROUP powerACPwrCharOptionalMIBTableGroup DESCRIPTION "A compliant implementation does not have to implement." GROUP powerACPwrCharPhaseMIBTableGroup DESCRIPTION "A compliant implementation does not have to implement." GROUP powerACPwrCharDelPhaseMIBTableGroup DESCRIPTION "A compliant implementation does not have to implement." GROUP powerACPwrCharWyePhaseMIBTableGroup DESCRIPTION "A compliant implementation does not have to implement." ::= { powerCharacteristicsMIBCompliances 1 } -- Units of Conformance powerACPwrCharMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object entPhysicalIndex is NOT -- included since it is not-accessible eoACPwrCharAvgVoltage, eoACPwrCharAvgCurrent, eoACPwrCharFrequency, eoACPwrCharPowerUnitMultiplier, eoACPwrCharPowerAccuracy, eoACPwrCharTotalActivePower, eoACPwrCharTotalReactivePower, eoACPwrCharTotalApparentPower, eoACPwrCharTotalPowerFactor } STATUS current DESCRIPTION Expires January 12, 2013 [Page 71] Internet-Draft July 2012 "This group contains the collection of all the Power Characteristics objects related to the Energy Object." ::= { powerCharacteristicsMIBGroups 1 } powerACPwrCharOptionalMIBTableGroup OBJECT-GROUP OBJECTS { eoACPwrCharConfiguration, eoACPwrCharThdAmpheres, eoACPwrCharThdVoltage } STATUS current DESCRIPTION "This group contains the collection of all the Power Characteristics objects related to the Energy Object." ::= { powerCharacteristicsMIBGroups 2 } powerACPwrCharPhaseMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object entPhysicalIndex is NOT -- included since it is not-accessible eoACPwrCharPhaseAvgCurrent, eoACPwrCharPhaseActivePower, eoACPwrCharPhaseReactivePower, eoACPwrCharPhaseApparentPower, eoACPwrCharPhasePowerFactor, eoACPwrCharPhaseImpedance } STATUS current DESCRIPTION "This group contains the collection of all 3-phase Power characteristics objects related to the Power State." ::= { powerCharacteristicsMIBGroups 3 } powerACPwrCharDelPhaseMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object entPhysicalIndex and -- eoPhaseIndex are NOT included -- since they are not-accessible eoACPwrCharDelPhaseToNextPhaseVoltage , eoACPwrCharDelThdPhaseToNextPhaseVoltage, eoACPwrCharDelThdCurrent } STATUS current DESCRIPTION Expires January 12, 2013 [Page 72] Internet-Draft July 2012 "This group contains the collection of all power characteristic attributes of a phase in a DEL 3-phase power system." ::= { powerCharacteristicsMIBGroups 4 } powerACPwrCharWyePhaseMIBTableGroup OBJECT-GROUP OBJECTS { -- Note that object entPhysicalIndex and -- eoPhaseIndex are NOT included -- since they are not-accessible eoACPwrCharWyePhaseToNeutralVoltage, eoACPwrCharWyePhaseCurrent, eoACPwrCharWyeThdPhaseToNeutralVoltage } STATUS current DESCRIPTION "This group contains the collection of all WYE configuration phase-to-neutral Power Characteristics measurements." ::= { powerCharacteristicsMIBGroups 5 } END 11. 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 eoPowerOperState (via theeoPowerAdminState ) MAY disrupt the power settings of the differentEnergy Objects, and therefore the state of functionality of the respective Energy Objects. - Unauthorized changes to the eoEnergyParametersTable MAY disrupt energy measurement in the eoEnergyTable table. Expires January 12, 2013 [Page 73] Internet-Draft July 2012 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 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. 12. IANA Considerations 12.1. IANA Considerations for the MIB Modules The MIB modules in this document uses the following IANA- assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- energyObjectMib { mib-2 xxx } powerCharacteristicsMIB { mib-2 yyy } Additions to the MIB modules 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 OIDs SHOULD be assigned to the new MIB objects. The specification of new MIB objects SHOULD follow the structure specified in Section 10. and MUST be published using a well-established and persistent publication medium. Expires January 12, 2013 [Page 74] Internet-Draft July 2012 12.2. IANA Registration of new Power State Set This document specifies an initial set of Power State Sets. The list of these Power State Sets with their numeric identifiers is given in Section 5.2.1. IANA maintains a Textual Convention IANAPowerStateSet with the initial set of Power State Sets and the Power States within those Power State Sets. The current version of Textual convention can be accessed http://www.iana.org/assignments/IANAPowerStateSet New Assignments to Power State Sets shall be administered by IANA and the guidelines and procedures are listed in this Section. New assignments for Power State Set will be administered by IANA through 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 state for completeness and accuracy of the description. A pure vendor specific implementation of Power State Set shall not be adopted; since it would lead to proliferation of Power State Sets. 12.2.1. IANA Registration of the IEEE1621 Power State Set This document specifies a set of values for the IEEE1621 Power State Set [IEEE1621]. The list of these values with their identifiers is given in Section 5.2.1. The Internet Assigned Numbers Authority (IANA) created a new registry for IEEE1621 Power State Set identifiers and filled it with the initial listin the Textual Convention IANAPowerStateSet.. New assignments (or potentially deprecation) for IEEE1621 Power State Set will be administered by IANA through 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 state for completeness and accuracy of the description. 12.2.2. IANA Registration of the DMTF Power State Set This document specifies a set of values for the DMTF Power State Set. The list of these values with their identifiers is given in Section 5.2.1. The Internet Assigned Numbers Authority (IANA) has created a new registry for DMTF Power State Set identifiers and filled it with the initial list in the Textual Convention IANAPowerStateSet. Expires January 12, 2013 [Page 75] Internet-Draft July 2012 New assignments (or potentially deprecation) for DMTF Power State Set will be administered by IANA through 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 conformance with the DMTF standard [DMTF], on the top of checking for completeness and accuracy of the description. 12.2.3. IANA Registration of the EMAN Power State Set This document specifies a set of values for the EMAN Power State Set. The list of these values with their identifiers is given in Section 5.2.1. The Internet Assigned Numbers Authority (IANA) has created a new registry for EMAN Power State Set identifiers and filled it with the initial list in the Textual Convention IANAPowerStateSet. New assignments (or potentially deprecation) for EMAN Power State Set will be administered by IANA through 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 state for completeness and accuracy of the description. 12.3. Updating the Registration of Existing Power State Sets IANA maintains a Textual Convention IANAPowerStateSet with the initial set of Power State Sets and the Power States within those Power State Sets. The current version of Textual convention can be accessed http://www.iana.org/assignments/IANAPowerStateSet With the evolution of standards, over time, it may be important to deprecate of some of the existing the Power State Sets or some of the states within a Power State Set. The registrant shall publish an Internet-draft or an individual submission with the clear specification on deprecation of Power State Sets or Power States registered with IANA. The deprecation shall be administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The process should also allow for a mechanism for cases where others have significant objections to claims on deprecation of a registration. In cases, where the registrant cannot be reached, IESG can designate an Expert to modify the IANA registry for the deprecation. Expires January 12, 2013 [Page 76] Internet-Draft July 2012 12. Contributors This document results from the merger of two initial proposals. The following persons made significant contributions either in one of the initial proposals or in this document. John Parello Rolf Winter Dominique Dudkowski 13. Acknowledgment The authors would like to thank Shamita Pisal for her prototype of this MIB module, and her valuable feedback. The authors would like to Michael Brown for improving the text dramatically. We would like to thank Juergen Schoenwalder for proposing the design of the Textual Convention for IANAPowerStateSet and Ira McDonald for his feedback. Thanks for the many comments on the design of the EnergyTable from Minoru Teraoka and Hiroto Ogaki. 14. Open Issues OPEN ISSUE 1 Consideration of IEEE-ISTO PWG in the IANA list of Power State Set ? Printer Power series could be added once the IANA procedure is in place. OPEN ISSUE 2 check if all the requirements from [EMAN-REQ] are covered. OPEN ISSUE 3 IANA Registered Power State Sets deferred to [EMAN- FRAMEWORK] Expires January 12, 2013 [Page 77] Internet-Draft July 2012 15. References 15.2. 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. [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-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information Base extension module for TIA-TR41.4 media endpoint discovery information", July 2005. [EMAN-AWARE-MIB] J. Parello, and B. Claise, "draft-ietf-eman- energy-aware-mib-06 ", work in progress, July 2012. 15.3. Informative References [RFC1628] S. Bradner, "UPS Management Information Base", RFC 1628, May 1994 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet Expires January 12, 2013 [Page 78] Internet-Draft July 2012 Standard Management Framework ", RFC 3410, December 2002. [RFC3418] Presun, R., Case, J., McCloghrie, K., Rose, M, and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", RFC3418, December 2002. [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002. [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, November 2005. [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie, "Guidelines for Writing an IANA Considerations Section in RFCs ", BCP 26, RFC 5226, May 2008. [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. Chandramouli, " Requirements for Energy Management", draft-ietf-eman-requirements-07, July 2012. [EMAN-FRAMEWORK] Claise, B., Parello, J., Schoening, B., and J. Quittek, "Energy Management Framework", draft-ietf- eman-framework-04, March 2012. [EMAN-MONITORING-MIB] M. Chandramouli, Schoening, B., Dietz, T., Quittek, J. and B. Claise "Energy and Power Monitoring MIB ", draft-ietf-eman-energy-monitoring-mib-02, March 2012. [EMAN-AS] Tychon, E., Laherty, M., and B. Schoening, "Energy Management (EMAN) Applicability Statement", draft- ietf-eman-applicability-statement-01, June 2012. [EMAN-TERMINOLOGY] J. Parello, "Energy Management Terminology", draft-parello-eman-definitions-06, work in progress, July 2012. [ACPI] "Advanced Configuration and Power Interface Specification",http://www.acpi.info/DOWNLOADS/ACPIspec3 0b.pdf [DMTF] "Power State Management Profile DMTF DSP1027 Version 2.0" December 2009 http://www.dmtf.org/sites/default/files/standards/docum ents/DSP1027_2.0.0.pdf Expires January 12, 2013 [Page 79] Internet-Draft July 2012 [IEEE1621] "Standard for User Interface Elements in Power Control of Electronic Devices Employed in Office/Consumer Environments", IEEE 1621, December 2004. [IEC.61850-7-4] International Electrotechnical Commission, "Communication networks and systems for power utility automation Part 7-4: Basic communication structure Compatible logical node classes and data object classes", 2010. [IEC.62053-21] International Electrotechnical Commission, "Electricity metering equipment (a.c.) Particular requirements Part 22: Static meters for active energy (classes 1 and 2)", 2003. [IEC.62053-22]International Electrotechnical Commission, "Electricity metering equipment (a.c.) Particular requirements Part 22: Static meters for active energy (classes 0,2 S and 0,5 S)", 2003. Authors' Addresses Mouli Chandramouli Cisco Systems, Inc. Sarjapur Outer Ring Road Bangalore, IN Phone: +91 80 4426 3947 Email: moulchan@cisco.com Brad Schoening 44 Rivers Edge Drive Little Silver, NJ 07739 US Email: brad@bradschoening.com Juergen Quittek NEC Europe Ltd. NEC Laboratories Europe Network Research Division Expires January 12, 2013 [Page 80] Internet-Draft July 2012 Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-115 Email: quittek@neclab.eu Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 4342-128 Email: Thomas.Dietz@neclab.eu Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com Expires January 12, 2013 [Page 81]