idnits 2.17.1 draft-claise-energy-monitoring-mib-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 8, 2010) is 5156 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4133 (Obsoleted by RFC 6933) == Outdated reference: A later version (-02) exists of draft-quittek-power-monitoring-requirements-00 ** Downref: Normative reference to an Informational draft: draft-quittek-power-monitoring-requirements (ref. 'POWER-MON-REQ') -- Possible downref: Non-RFC (?) normative reference: ref. 'ACPI' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Claise 3 Internet-Draft M. Chandramouli 4 Intended Status: Standards Track J. Parello 5 Expires: September 8, 2010 B. Schoening 6 Cisco Systems, Inc. 7 March 8, 2010 9 Energy Monitoring MIB 10 draft-claise-energy-monitoring-mib-02 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance 15 with the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed 32 at http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on September, 2010. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described 48 in Section 4.e of the Trust Legal Provisions and are provided 49 without warranty as described in the BSD License. 51 Abstract 53 This document defines the Management Information Base (MIB) 54 for the power monitoring of network elements. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 59 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 60 and "OPTIONAL" in this document are to be interpreted as 61 described in RFC 2119 [RFC2119]. 63 Table of Contents 65 1. Introduction.............................................. 4 66 2. The Internet-Standard Management Framework................ 4 67 3. Terminology............................................... 5 68 4. Concepts.................................................. 6 69 4.1. Parent/Child Concept..................................10 70 5. Examples................................................. 11 71 6. Link with the other IETF MIBs............................ 20 72 6.1. Link with the ENTITY-MIB and the ENTITY-SENSOR-MIB....20 73 6.2. Link with the ENTITY-STATE-MIB........................21 74 6.3. Link with the POWER-OVER-ETHERNET MIB.................21 75 7. Structure of the MIB..................................... 22 76 8. MIB Definitions.......................................... 22 77 9. Security Considerations.................................. 42 78 10. IANA Considerations..................................... 43 79 11. References.............................................. 44 80 11.1. Normative References.................................44 81 11.2. Informative References...............................44 82 12. Authors' Addresses...................................... 45 84 1. Introduction 86 This document defines a subset of the Management Information 87 Base (MIB) for use with network management protocols for 88 monitoring the power state and the power consumption of network 89 elements, taking into account the requirements specified in 90 [POWER-MON-REQ]. In addition to power monitoring, functionality 91 to configure the power state of network elements is proposed. 93 The MIB module in this document has been designed to be highly 94 flexible, with twelve different power levels, in accordance to 95 the Advanced Configuration and Power Interface SPECIFICATION 96 (ACPI) specifications [ACPI]. 98 The target devices include: routers, switches, attached devices 99 such as Power over Ethernet (PoE) devices (but not limited to 100 PoE devices), proxy for building energy management, intelligent 101 meters, home energy gateway, hosts and servers, sensor proxy, 102 etc. However, the monitoring and configuration should be 103 available for individual components of devices as well, such as 104 line cards, processor cards, hard drives, etc. when those 105 components are independent from a power state point of view. 106 Those targets devices and components may be characterized by the 107 power related attributes of a physical entity present in ENTITY- 108 MIB, even though the ENTITY-MIB compliance is not a requirement. 110 2. The Internet-Standard Management Framework 112 For a detailed overview of the documents that describe the 113 current Internet-Standard Management Framework, please refer to 114 section 7 of RFC 3410 [RFC3410]. 116 Managed objects are accessed via a virtual information store, 117 termed the Management Information Base or MIB. MIB objects are 118 generally accessed through the Simple Network Management 119 Protocol (SNMP). Objects in the MIB are defined using the 120 mechanisms defined in the Structure of Management Information 121 (SMI). This memo specifies MIB modules that are compliant to 122 the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 123 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 125 3. Terminology 127 PowerMonitor Entity 129 A PowerMonitor Entity is a system of one or more components, 130 that provides power, draws power, or reports power 131 consumption on behalf of another PowerMonitor Entity. It can 132 be independently managed from a power monitoring and power 133 state configuration point of view. This PowerMonitor Entity 134 may be represented by a physical component referenced 135 using the EntPhysicalTable from the Entity MIB [RFC4133], or 136 by a port and group in the Power over Ethernet MIB [RFC3621] 137 Examples of PowerMonitor Entities are: a router line card, a 138 motherboard with a CPU, an IP Phone connected with a switch, 139 etc. 141 PowerState Level 143 A uniform way to classify power settings on a PowerMonitor 144 Entity (e.g., shut, hibernate, sleep, standby). Levels are 145 software setting for interacting with the underlying hardware 146 supported power settings. 148 PowerMonitor Unit Scale 150 A scaling factor used to represent the magnitude of 151 PowerMonitor Entity usage. It conforms to the standard 152 prefixes for the SI (System International) units of measure. 153 Measured values are represented in SI units obtained by 154 BaseValue * 10 raised to the power of Scale. 156 For example, if current usage of a PowerMonitor Entity is 3, 157 it could be 3 W, 3 mW, 3 KW, 3 MW depending on the value of 158 PowerMonitor Scale. 160 PowerMonitor Domain 162 A PowerMonitor Domain is a name or name space which logically 163 groups together PowerMonitor Entities that comprises a unit 164 of manageable power consumption. For example, all phones in 165 a floor, all PowerMonitor Entities from a specific building, 166 or all PowerMonitor Entities of a specific device type for 167 which a common profile is deployed. From the point of 168 monitoring power consumption, it is useful to report the 169 total power consumed as the sum of power consumed by all the 170 PowerMonitor Entities within a PowerMonitor Domain. 172 PowerMonitor Parent 174 A PowerMonitor Parent is a PowerMonitor Entity that is the 175 root of one or multiple subtending PowerMonitor Entities, 176 called a PowerMonitor Children. The PowerMonitor Parent is 177 able to report the power consumption for his PowerMonitor 178 Child(ren). 180 For example, in case of Power-over-Ethernet (PoE) device such 181 as an IP phone or an access point attached to a switch port, 182 the switch is the source of power for the attached device. 183 In such a case, the PowerMonitor Parent is the port of the 184 switch, while the attached device is the PowerMonitor Child. 186 PowerMonitor Child 188 A PowerMonitor Child is a PowerMonitor Entity associated to a 189 PowerMonitor Parent, which draws power from its PowerMonitor 190 Parent or reports its power usage and power state to its 191 PowerMonitor Parent. 193 4. Concepts 195 PowerState Levels represent one of twelve power management 196 states of an PowerMonitor Entity. Each PowerState Level 197 corresponds to a global, system, and performance state in the 198 ACPI model. 200 Level ACPI Global/System Name 201 State 203 Non-operational states: 205 1 G3, S5 Mech Off 206 2 G2, S5 Soft Off 207 3 G1, S4 Hibernate 208 4 G2, S3 Sleep, Save-to-RAM 209 5 G2, S2 Standby 210 6 G2, S1 Ready 212 Operational states: 213 7 G0, S0, P5 Low 214 8 G0, S0, P4 Frugal 215 9 G0, S0, P3 Medium 217 10 G0, S0, P2 Reduced 218 11 G0, S0, P1 High 219 12 G0, S0, P0 Full 221 For example, a PowerMonitor Entity with a power state of 9 would 222 indicate an operational state with medium power consumption. 224 The pmPowerUsageCategory MIB object, specified as a read-only 225 object, indicates the power usage type of the PowerMonitor 226 Entity: power consumer, power producer, or meter. The value of 227 pmPowerUsage, specified as Integer32, can be positive or 228 negative, and must corresponding with the usage type in 229 pmPowerUsageCategory. 231 A PowerMonitor Entity should have a pmName, a unique 232 PowerMonitor index pmIndex, and potentially an 233 entityPhysicalIndex from the ENTITY-MIB [RFC4133] in the 234 pmPhysicalEntity, if supported by the PowerMonitor Entity. In 235 case of Power over Ethernet, the PowerMonitor Entity 236 pmethPortIndex and pmethPortGrpIndex may contain the 237 pethPsePortIndex and pethPsePortGroupIndex. The pmName can be 238 configured or defined by DNS. Possible pmName are: textual DNS 239 name, MAC-address of the device, interface ifName, or a text 240 string uniquely identifying the PowerMonitor Entity. The pmName 241 should ideally be unique. As an example, in the case of IP 242 phones, pmName can be the devices DNS name. In the case of 243 router/switch line cards, the pmName could be the 244 entPhysicalName. Each PowerMonitor Entity can be a member of a 245 PowerMonitor Domain. The PowerMonitor Domain could map 1-1 with 246 a metered or sub-metered portion of the customers site. It can 247 be used to further sub divide the deployment down to finer 248 PowerMonitor Domains such as a lab, data center, rack, etc. With 249 the possible evolution of this draft, to a framework document, 250 the notion of PowerMonitor Domain shall be useful. 252 For a PowerMonitor Entity, instantaneous power usage is reported 253 using pmPowerUsage and the magnitude of measurement is specified 254 in pmPowerUnits which is based on MonitorScale. 256 Nameplate power consumption of a PowerMonitor Entity is 257 specified by the vendor as the maximum capacity required to 258 safely power the device. Often this label is a conservative 259 number and is the worst case power draw of all elements in a 260 fully configured system. While the actual utilization of an 261 entity can be lower, Nameplate power consumption is important 262 for power provisioning, capacity planning and billing. 263 In addition to measuring power consumption, an approach to 264 characterize the energy demand is also presented in the MIB. It 265 is well-known in commercial electrical utility rates, that 266 demand charges can be on par with actual power charges. So, in 267 addition to measuring power consumption, it is useful to 268 characterize the demand. The demand can be described as average 269 energy usage of an PowerMonitor Entity over a time window, 270 called a demand interval, typically 15 minutes. The highest 271 peak energy demand measured over a time horizon, say 1 month or 272 1 year is often the basis for usage charge. A single window of 273 time of high usage can penalize the power consumption charges. 274 However, it is relevant to measure the demand only when there 275 are actual power measurements from a PowerMonitor Entity, and 276 not when the power measurement is assumed or predicted as 277 specified in the MIB OID PowerUsageCaliber. 279 Two tables are introduced to characterize the energy demand - 280 emDemandTable and emDemandControlTable. The emDemandControl 281 Table consists of parameters defining: the duration of the 282 demand intervals in seconds, emDemandControlIntervalLength; the 283 number of demand intervals kept in the emDemandTable, 284 emDemandControlIntervalNumber; and a same rate used to calculate 285 the average, emDemandControlSampleRate. Judicious choice of the 286 SamplingRate will ensure accurate measurement of power while not 287 imposing an excessive polling burden. The emDemandControlStatus 288 is useful to specify the energy measurement is actual and thus 289 to indicate if the emDemandTable entries exist or not. 291 The emDemand Table consists of energy measurements in 292 DemandIntervalEnergyUsed, the scale of energy measured, 293 DemandIntervalEnergyScale, and the maximum observed demand in a 294 window - emDemandIntervalMax 296 Several efficiency metrics can be derived and tracked with the 297 usage data present in this MIB module. For example, 299 - Per-packet power costs for a networking device (router or 300 switch) can be calculated by an network management system. 301 The packets count can be determined from the traffic usage in 302 the ifTable [RFC2863] from the forwarding plane figure, or 303 from the platform specifications 304 - Watt-hour power use from this MIB can be combined with 305 utility energy sources to estimate carbon footprint and other 306 emission statistics. 308 An example is provided to illustrate the concepts. For example, 309 a given PowerMonitor Entity as described by the pmIndex "7" 310 pmPhysicalEntity "5" and pmName "switch2.foo.com". For that 311 PowerMonitor Entity, the power measurement and power state is 312 reported as follows: the units of measurement pmPowerUnits is 313 "watts" (value 0), the instantaneous power usage enPowerUsage is 314 100 watts, while the maximum power consumption as prescribed by 315 the vendor pmPowerNamePlate is 300 watts. The 316 pmPowerUsageCaliber indicates that the power measurement is 317 "actual". The power state of that PowerMonitor Entity 318 PmPowerLevel is "9" to indicate medium power usage and 319 pmPowerUsageCategory indicates the device is a consumer of 320 power. In addition, the maximum power consumption at the 321 current level is indicated as 150 watts in pmLevelMaxUsage. 323 The emDemandTable and emDemandControlTable will be illustrated 324 following the same example. First, in order to estimate demand, 325 an interval to sample energy usage should be specified, i.e. 326 emDemandControlIntervalLength can be "900 seconds" and the 327 number of consecutive intervals over which the maximum demand is 328 calculated emDemandControlIntervalNumber as "10". The sampling 329 rate internal to the PowerMonitor Entity for measurement of 330 power usage, emDemandControlSampleRate, can be "1000 331 milliseconds", as set by the PowerMonitor Entity as a reasonable 332 value. Then, the emDemandControlStatus is set to active (value 333 1) to indicate that the PowerMonitor Entity should start monitor 334 the usage as per the emDemandTable. 336 The indices in the emDemandTable are pmIndex, which identifies 337 the PowerMonitor Entity, and emDemandIntervalStartTime, which 338 denotes the start time of the demand measurement interval based 339 on sysUpTime. The value of emDemandIntervalEnergyUsed is the 340 measured of the energyconsumption over the time interval 341 specified (emDemandControlIntervalLength) based on the 342 PowerMonitor Entity internal sampling rate 343 (emDemandControlSampleRate). The units are derived from 344 emDemandIntervalPowerScale. For example, 345 emDemandIntervalPowerUsed can be "100" with 346 emDemandIntervalPowerUnits equal to 0, the demand is 100 347 watt-hours. emDemandIntervalMax is the maximum demand observed 348 can be "150 watt-hours". 350 The emDemandTable has a buffer to retain a certain number of 351 intervals, as defined by emDemandControlIntervalNumber. If the 352 default value of "10" is kept, then the emDemandTable contains 353 10 demand measurements, including the maximum. A brief 354 explanation on how the maximum demand is calculated. The first 355 observed demand measurement value is taken to be the initial 356 maximum. With each subsequent measurement, based on numerical 357 comparison, maximum demand may be updated. The maximum value is 358 retained as long as the measurements are taking place. Based on 359 periodic polling of this table, a Network Management System 360 could compute the maximum over a longer period, i.e. a month, 3 361 months, or a year. 363 [POWER-MON-REQ] specifies some requirements about power states 364 such as "the current state - the time of the last change", "the 365 total time spent in each state", "the number of transitions to 366 each state", etc... Such requirements are fulfilled thanks to 367 the pmLevelChange NOTIFICATION-TYPE, indexed by the pmIndex and 368 the pmPowerLevel, which is generated when the value of 369 pmPowerLevel has changed for the PowerMonitor Entity represented 370 by the pmIndex. Indeed, assuming that the SNMP notification 371 arrives at the Network Management Station (NMS), the NMS can 372 deduce all the information. 374 4.1. Parent/Child Concept 376 A PowerMonitor Entity can be connected to another PowerMonitor 377 Entity and either draw power from that entity or report power 378 usage to the Entity. 380 EnergyMonitor Child can be fully dependent on the EnergyMonitor 381 Parent or independent. In the dependent case, EnergyMonitor 382 Parent provides power for the EnergyMonitor Child and the power 383 consumption of the child can be measured at the EnergyMonitor 384 parent. Also, the PowerMonitor Levels can be set by the 385 EnergyMonitor Parent. In the independent case, an EnergyMonitor 386 Child draws power from another source (typically a wall outlet). 387 However, the EnergyMonitor Child does not have a separate 388 network management presence and instead reports the power usage 389 and PowerMonitoring Level on to the EnergyMonitor Parent. The 390 EnergyMonitor Child may listen to the power control settings 391 from a EnergyMonitor Parent and the EnergyMonitor Child could 392 react to the control messages. Note that the communication 393 between the EnergyMonitor Parent and EnergyMonitor Child is out 394 of scope of this document. 396 In order to link the PowerMonitor Child and the PowerMonitor 397 Parent, the notion of pmParentId is introduced. 399 Consider the example of a PoE device attached to a switch where 400 the switch can measure the power at the switch port level. For 401 example, a PoE device with an pmIndex of 100 and a pmParentId 402 value of 20 representing the parent pmIndex. This PowerMonitor 403 parent will report the power usage for the attached PoE device 404 while the PoE port reports zero for power usage. Furthermore, 405 if the pmPhysicalEntity value is non zero, the switch port to 406 which the PoE device is connected to can be deduced. 408 The use of a PowerMonitor parent is not limited to just PoE 409 children. However, in the case of non-POE devices, the power 410 usage cannot be measured at the switch port; since the switch is 411 not source of power supply. In that case, proprietary 412 communication of power usage between the child (PC) and the 413 parent (switch) could be established, the form of which is 414 outside of scope of this document. Consider a PC attached to a 415 switch port, powered from a wall outlet. In this example, the 416 PC would appear as a PowerMonitor child Entity and report his 417 usage in the parents emEntry table. Similarly to the previous 418 PoE example, the PC PowerMonitor parent and switch port can be 419 deduced through cross-references. 421 It is not possible to have multiple PoE devices on a single PoE 422 port. However, it is possible to have a single PoE device on a 423 switch port and another non-PoE device such a PC can be daisy- 424 chained from the phone for the LAN connection. In this 425 scenario, the switch port parent has two children; the IP phone 426 and PC. As stated before, for the PoE device, it is possible to 427 measure the power consumption at the switch port, whereas for 428 the non-POE device (PC), there must be out-of-band communication 429 of power usage and power levels between the non-PoE device and 430 the switch. The communication between the parent and a child is 431 out of scope of this document and is not discussed here. 433 5. Examples 435 A PowerMonitor Entity is a fundamental concept from the point of 436 view of power monitoring application considered in this 437 document. Some illustrative examples are presented to model 438 different network scenarios of the PowerMonitor Parent and 439 PowerMonitor Child relationship. 441 Example 1: Consider an PoE IP Phone connected to the switch 442 port, as displayed on figure 1. The IP phone draws power from 443 the Power over Ethernet switch port. The switch has the 444 following attributes that are illustrated in Figure 1. 446 The switch has pmIndex "1", pmPhysicalEntity is "2" and 447 pmPowerMonitorID is "UUID 1000". The power consumption of the 448 switch is "440 Watts". The switch does not have a parent. 450 The POE switch port has the following attributes - The switch 451 port has pmIndex "3", pmPhysicalEntity is "12" and 452 pmPowerMonitorID is "UUID 1003". The power consumption of the 453 POE switch port is "12 watts". The POE switch port has the 454 switch as the parent, with its pmParentID of "1000". 456 The IP Phone has the following attributes: The IP Phone has 457 pmIndex "31" and pmPowerMonitorID "UUID 2003", but doesn't have 458 an entry for pmPhysicalEntity, as the ENTITY-MIB is not 459 supported on this device. The IP Phone has a parent; the POE 460 switch port whose pmPowerMonitorID is "UUID 1003". The power 461 consumption of the IP Phone is measured at the POE switch port 462 and the pmUsage on the PoE IP phone reports 0. 464 |--------------------------------------------------------------| 465 | Switch | 466 |==============================================================| 467 | |Switch | Switch | Switch | Switch | Switch | | 468 | |pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | 469 | ============================================================ | 470 | | 1 | 2 | UUID 1000 | null | 440 | | 471 | ============================================================ | 472 | | 473 | SWITCH PORT | 474 | ============================================================ | 475 | | Switch | Switch | Switch | Switch | Switch | | 476 | | Port | Port | Port | Port | Port | | 477 | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | 478 | ============================================================ | 479 | | 3 | 12 | UUID 1003 | UUID 1000 | 12 | | 480 | ============================================================ | 481 | ^ | 482 | | | 483 |-------------------------------|----------------------------- | 484 | 485 | 486 POE IP PHONE | 487 | 488 ============================================================== 489 | IP Phone| IP Phone | IP Phone | IP Phone | IP Phone| 490 | pmIndex | EntPhyIdx| pmPowerMonitorID| pmParentID| pmUsage | 491 ============================================================== 492 | 31 | 0 | UUID 2003 | UUID 1003 | 0 | 493 ============================================================== 495 Figure 1: Example 1 497 Example 2: Consider the same scenario as example 1 with an IP 498 Phone connected to POE port of a switch. Now, in addition, a PC 499 is also daisy-chained from the IP Phone for LAN connectivity. 500 The phone draws power from POE port of the switch, while the PC 501 draws power from the wall outlet. 503 The attributes of the switch, switch port and IP Phone are the 504 same as in Example 1. The attributes of the PC are given below. 505 The PC does not have pmPhysicalEntity. The pmIndex of the PC 506 "57", the pmPowerMonitorID is "UUID 5004". The PC has a parent 507 the switch port whose pmPowerMonitorID is "UUID 1003". The 508 power usage of the PC is "120 Watts" and is communicated to the 509 switch port. 511 This example is used to illustrate the distinction between the 512 PowerMonitor Children: the IP Phone draws power from the switch, 513 while the PC has LAN connectivity from the Phone, but is powered 514 from the wall outlet. However, the PowerMonitor Parent sends 515 power control messages to both the PowerMonitor children (IP 516 Phone and PC) and the children react upon those messages. 518 |--------------------------------------------------------------| 519 | Switch | 520 |==============================================================| 521 | Switch | Switch | Switch | Switch | Switch | 522 | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | 523 | ============================================================ | 524 | 1 | 2 | UUID 1000 | null | 440 | 525 | ============================================================ | 526 | | 527 | SWITCH PORT | 528 | ============================================================ | 529 | | Switch | Switch | Switch | Switch | Switch | 530 | | Port | Port | Port | Port | Port | | 531 | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | 532 | ============================================================ | 533 | | 3 | 12 | UUID 1003 | UUID 1000 | 12 | | 534 | ============================================================ | 535 | ^ | 536 | | | 537 |-----------------------------------|--------------------------| 538 | 539 | 540 POE IP PHONE | 541 | 542 | 543 ============================================================= 544 | IP Phone | IP Phone |IP Phone |IP Phone |IP Phone| 545 | pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID |pmUsage | 546 ============================================================ 547 | 31 | 0 | UUID 2003 | UUID 1003 | 0 | 548 ============================================================ 549 | 550 | 551 PC connected to switch via IP phone | 552 | 553 ============================================================ 554 | PC | PC |PC |PC | PC | 555 | pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage | 556 ============================================================ 557 | 57 | 0 | UUID 5004 | UUID 1003 | 120 | 558 ============================================================ 560 Figure 2: Example 2 562 Example 3: Consider a Wireless Access Point connected to the POE 563 port of a switch. There are several PCs connected to the 564 Wireless Access Point over Wireless protocols. All PCs draw 565 power from the wall outlets. 567 The switch port is the PowerMonitor Parent for the Wireless 568 Access Point and the PCs. There is a distinction, between the 569 children, as the Wireless Access Point draws power from the POE 570 port of the switch and the PCs draw power from the wall outlet. 572 The switch has pmIndex "1", pmPhysicalEntity is "2" and 573 pmPowerMonitorID is "UUID 1". The power consumption of the 574 switch is "440 Watts". The switch does not have a parent. 576 The POE switch port has the following attributes - The switch 577 port has pmIndex "7", pmPhysicalEntity is "18" and 578 pmPowerMonitorID is "UUID 2". The power consumption of the POE 579 switch port is "20 watts". The POE switch port has the switch 580 as the parent and the pmParentID is "UUID 1000". 582 The Wireless Access Point has the following attributes. The WAP 583 doesn't have an entry for pmPhysicalEntity. The WAP has pmIndex 584 "47" and pmPowerMonitorID "UUID 3" and WAP has a parent; the POE 585 switch port whose pmPowerMonitorID is "UUID 2". The power 586 consumption of the WAP is measured at the POE switch port. 588 The PC1 and PC2 does not have pmPhysicalEntity. The pmIndex of 589 the PC "53", the pmPowerMonitorID is "UUID 3". The PC has a 590 parent; i.e., the switch POE port whose pmPowerMonitorID is 591 "UUID 2". The power usage of the PC is "120 Watts" and is 592 communicated to the switch port. 594 The pmIndex of the PC2 "58", the pmPowerMonitorID is "UUID 5". 595 The PC has a parent; the switch port whose pmPowerMonitorID is 596 "UUID 2". The power usage of the PC is "120 Watts" and is 597 communicated to the switch port. 599 |--------------------------------------------------------------| 600 | Switch | 601 |==============================================================| 602 | Switch | Switch | Switch | Switch | Switch | 603 | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | 604 | ============================================================ | 605 | 1 | 2 | UUID 1 | null | 440 | 606 | ============================================================ | 607 | | 608 | SWITCH PORT | 609 | ============================================================ | 610 | | Switch | Switch | Switch | Switch | Switch | 611 | | Port | Port | Port | Port | Port | | 612 | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | 613 | ============================================================ | 614 | 7 | 18 | UUID 2 | UUID 1 | 20 | | 615 | ============================================================ | 616 | ^ | 617 | | | 618 |----------------------------------------------|---------------| 619 | 620 POE Wireless Access Point | 621 | 622 | 623 ============================================================== 624 | WAP | WAP | WAP | WAP | WAP | 625 | pmIndex | pmPhyIdx | pmPowerMonId | pmParentID | pmUsage | 626 ============================================================== 627 | 47 | 0 | UUID 3 | UUID 2 | 0 | 628 ============================================================== 629 . 631 . 632 . 633 . 634 PC1 connected to WAP . 635 . 637 ============================================================== 638 | PC | PC |PC |PC | PC | 639 | pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage | 640 ============================================================== 641 | 53 | 0 | UUID 4 | UUID 2 | 120 | 642 ============================================================== 643 . 644 . 645 PC2 connected to WAP . 646 . 647 ================================================================ 648 | PC | PC |PC | PC | PC | 649 | pmIndex| pmPhyIdx |pmPowerMonitorId | pmParentID | pmUsage | 650 =============================================================== 651 | 58 | 0 | UUID 5 | UUID 2 | 120 | 652 ================================================================ 654 Figure 3: Example 3 656 Example 4: An example of the proposed MIB on how to model 657 monitoring the energy consumption of buildings is presented. 659 At the top of the network hierarchy of building network is 660 mediator device that does protocol conversion between many 661 facility management protocols such as BACNET, MODBUS, DALI, LON, 662 etc. There are power meters associated with power consuming 663 entities (HVAC, lighting, electrical, fire control, elevators, 664 ...). The proposed MIB can be implemented on the mediator 665 device. The mediator can be considered as the PowerMonitor 666 Parent, while the power meters associated with the energy 667 consuming entities such (HVAC, electrical, lighting, ...) can be 668 considered as PowerMonitor Childen. EntPhysicalIndex is not 669 defined for these EnergyMonitor Parent or the Children, as the 670 ENTITY-MIB is generally not implemented in such an environment. 671 Hence the mediator, Meter 1, and Meter 2 have pmPhysicalEntities 672 of value zero. The pmIndex of the Mediator is "5", and the 673 pmPowerMonitorID is "UUID 1008". The mediator does not have a 674 parent; The total power usage of the Mediator and its children 675 is "9000 Watts". 677 Meter 1 has pmIndex "2051", and pmPowerMonitorID is "UUID 2004". 678 Meter 1 shall report a power consumption of "6000 watts". Meter 679 1 has the Mediator as the parent and its pmParentID is "UUID 680 1008". 682 Meter 2 has pmIndex "2072", and pmPowerMonitorID is "UUID 2007". 683 Meter 2 shall report a power consumption of "1500 watts". Meter 684 2 has the Mediator as the parent and its pmParentID is "UUID 685 1008". 687 --------------------------------------------------------------- 688 | Building Mediator | 689 | | 690 |==============================================================| 691 | Mediat | Mediat | Mediat | Mediat | Mediat | 692 | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | 693 | ============================================================ | 694 | 5 | None | UUID 1008 | Null | 9000 | 695 | ============================================================ | 696 | | 697 | | 698 ---------------------------------------------------------------- 699 | 700 | 701 | 702 | Meter 1 703 | 704 | ============================================================= 705 | | Meter1 | Meter1 |Meter1 |Meter1 | Meter1 | 706 | | pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage | 707 |=>|============================================================ 708 | | 2051 | 0 | UUID 2004 | UUID 1008 | 6000 | 709 | ============================================================= 710 | 711 | Meter 2 712 | ============================================================ 713 |=>| Meter2 | Meter2 |Meter2 |Meter2 | Meter2 | 714 | pmIndex| pmPhyIdx|pmPowerMonitorId|pmParentID| pmUsage | 715 ============================================================= 716 | 2072 | 0 | UUID 2007 | UUID 1008 | 1500 | 717 ============================================================= 719 Figure 4: Example 4 721 Example 5: An example of the proposed MIB on how to model a 722 data center network is presented. In summary, a typical data 723 center network consists of a hierarchy of switches. At the 724 bottom of hierarchy there are servers mounted on rack, and those 725 are connected to the top of the row switches. Top of the row 726 switches are connected to aggregation switches, who are in turn 727 connected to core switches. As an example, Server 1 and Server 728 2 are connected to different switch ports of the top of the row 729 switch. 731 The proposed MIB can be implemented on the switches. The switch 732 can be considered as the PowerMonitor Parent. The servers can 733 be considered as the children. 735 The switch has pmIndex "1", pmPhysicalEntity is "2" and the 736 pmPowerMonitorID is "1000". The power consumption of the switch 737 is "440 Watts". The switch does not have a parent. 739 Firstly, the switch ports are non-POE and have the following 740 attributes - Server 1 is connected to Switch port 1. Switch 741 port 1 has pmIndex "8", pmPhysicalEntity is "15" and 742 pmPowerMonitorID is "1041". The power consumption of the non-POE 743 switch port cannot be measured. The switch port has the switch 744 as the parent and its pmParentID is "1000". 746 The Server 1 has a value of zero for pmPhysicalEntity. The 747 pmIndex of the Server 1 is "53", and the pmPowerMonitorID is 748 "5016". Server 1 has a parent; i.e., the switch port whose 749 pmPowerMonitorID is "1041". The power usage of the Server 1 is 750 "200 Watts" and is communicated to the switch port. 752 Server 2 is connected to Switch port 2. Switch port 2 has 753 pmIndex "6", pmPhysicalEntity is "16" and pmPowerMonitorID is 754 "1054". The power consumption of the non-POE switch port cannot 755 be measured. The switch port has the switch as the parent and 756 its pmParentID is "1000". 758 The Server 2 has a value of zero for pmPhysicalEntity. The 759 pmIndex of the Server 2 is "72", and the pmPowerMonitorID is 760 "5043". Server 1 has a parent; i.e., the switch port whose 761 pmPowerMonitorID is "1054". The power usage of the Server 2 is 762 "140 Watts" and is communicated to the switch port. 763 Communication of power usage of Server1 and Server2 to the 764 switch is out of scope of this document. 766 |--------------------------------------------------------------| 767 | Switch | 768 |==============================================================| 769 | |Switch | Switch | Switch | Switch | Switch | | 770 | |pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | | 771 | ============================================================ | 772 | | 1 | 2 | UUID 1000 | null | 440 | | 773 | ============================================================ | 774 | | 775 | | 776 | SWITCH PORT 1 | 777 | ============================================================ | 778 | | Switch | Switch | Switch | Switch | Switch | 779 | | Port1 | Port1 | Port1 | Port1 | Port1 | 780 | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | 781 | ============================================================ | 782 | | 8 | 15 | UUID 1041 | UUID 1000 | NULL || 783 | ============================================================ | 784 | | 785 | SWITCH PORT 2 | 786 | ============================================================ | 787 | | Switch | Switch | Switch | Switch | Switch | 788 | | Port2 | Port2 | Port2 | Port2 | Port2 | 789 | | pmIndex | pmPhyIdx | pmPowerMonId | pmParentId | pmUsage | 790 | ============================================================ | 791 | | 6 | 16 | UUID 1054 | UUID 1000 | NULL | 792 | ============================================================ | 793 | | 794 | | 795 |--------------------------------------------------------------| 796 | 797 | 798 | Server 1 connected to switch (Non-POE) 799 | ============================================================= 800 | | Server 1| Server 1 | Server 1 | Server 1 | Server 1 | 801 | | pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID| pmUsage | 802 |=>|============================================================ 803 | | 64 | 0 | UUID 5016 | UUID 1041 | 200 | 804 | ============================================================= 805 | 806 | Server 2 connected to switch (Non-POE) 807 | ============================================================ 808 |=>| Server 2| Server 2 | Server 2 | Server 2 | Server 2 | 809 | pmIndex | pmPhyIdx |pmPowerMonitorId|pmParentID| pmUsage | 810 ============================================================= 811 | 72 | 0 | UUID 5043 | UUID 1054 | 140 | 812 ============================================================= 814 Figure 5: Example 5 816 6. Link with the other IETF MIBs 818 6.1. Link with the ENTITY-MIB and the ENTITY-SENSOR-MIB 820 RFC 4133 [RFC4133] defines the Entity MIB module that lists the 821 physical entities of a networking device (router, switch) and 822 those physical entities listed indexed by entPhysicalIndex. 823 From an energy management point of view, of interest are the 824 physical entities that consume or produce energy. 826 RFC 3433 [RFC3433] defines the ENTITY-SENSOR MIB module that 827 provides a standardized way of obtaining information (current 828 value of the sensor, operational status of the sensor, and the 829 data units precision) from sensors embedded in networking 830 devices. Sensors are associated with each index of 831 entPhysicalIndex of the Entity MIB [RFC4133]. While the focus 832 of the Power Monitoring MIB, is on measurement of power 833 consumption by networking equipment indexed by the entity MIB, 834 this MIB proposes a customized power scale for power measurement 835 and different power level states of networking equipment and a 836 functionality to configure the power level states. 838 When this MIB module is used to monitor the power consumption of 839 devices such as routers and switches, the ENTITY-MIB and ENTITY- 840 SENSOR-MIB should be implemented. In such cases, the 841 PowerMonitor Entities are modeled by the entPhysicalIndex 842 through the pmPhysicalEntity MIB object specified in the 843 pmTable. 845 However, the ENTITY-SENSOR-MIB doesn't have the ANSI C12.x 846 accuracy classes required for electricity, i.e., 1%, 2%, 0.5% 847 accuracy classes. These ANSI and IEC Standards require that we 848 use an accuracy class, and not the precision model in RFC3433. 849 The pmPowerUsageAccuracy MIB object models this accuracy. Note 850 that the emEntPowerScale represents the scale is a more logical 851 representation (compared to entPhySensorScale), with the 852 mantissa and the exponent values X * 10 ^ Y. 854 Finally, one cannot assume that the ENTITY-MIB and ENTITY- 855 SENSOR-MIB are implemented for all PowerMonitor Entity that 856 needs to be monitored. A typical example is a converged 857 building gateway, monitoring several other devices in the 858 building, doing the proxy between SNMP and a protocol such as 859 BACNET. Another example is the home energy controller. 860 In such cases, the pmPhysicalEntity value contains the zero 861 value, thanks to PhysicalIndexOrZero textual convention. 863 As a consequence, the pmIndex MIB object has been kept as the 864 unique PowerMonitor Entity index. Finally, not that 865 the emEntPowerUsage is similar to entPhySensorValue [RFC3433] 866 and the emEntPowerScale is similar to entPhySensorScale 868 6.2. Link with the ENTITY-STATE-MIB 870 RFC 4268 [RFC4268] defines the Entity State MIB module that 871 gives the operational states (enabled, disabled, testing) and 872 alarm states and usage states (idle, active, busy) of the 873 entities in the entity MIB. From a Power monitoring point of 874 view, different power states to indicate the power state of the 875 entities models need to be developed. The Power Monitoring MIB 876 proposes the power states of entities in the Entity MIB. 878 6.3. Link with the POWER-OVER-ETHERNET MIB 880 Power-over-Ethernet MIB [RFC3621] provides energy monitoring and 881 configuration framework for power over Ethernet devices. The 882 RFC introduces a concept of a port group on a switch to define 883 power monitoring and management policy and does not use the 884 entPhysicalIndex as index. 886 One cannot assume that the Power-over-Ethernet MIB is 887 implemented for all PowerMonitor Entity that needs to be 888 monitored. A typical example is a converged building gateway, 889 monitoring several other devices in the building, doing the 890 proxy between SNMP and a protocol such as BACNET. Another 891 example is the home energy controller. In such cases, the 892 pmethPortIndex and pmethPortGrpIndex values contain the zero 893 value, thanks to new PethPsePortIndexOrZero and textual 894 PethPsePortGroupIndexOrZero conventions. 896 However, if the Power-over-Ethernet is supported, the 897 PowerMonitor Entity pmethPortIndex and pmethPortGrpIndex contain 898 the pethPsePortIndex and pethPsePortGroupIndex, respectively. 900 As a consequence, the pmIndex MIB object has been kept as the 901 unique PowerMonitor Entity index. 903 7. Structure of the MIB 905 The primary MIB object in this MIB module is 906 PowerMonitorMIBObjects. 908 The pmTable table defines the PowerMonitor Entities, with 909 references to the entPhysicalIndex, pmethPortIndex and 910 pmethPortGrpIndex when available. The PowerMonitor Entities are 911 used for describing and configuring the entities that are 912 possible candidates for power management. The specific 913 PowerState Level can be configured in the pmTable. 915 The pmLevelTable table lists the maximum power usage at each 916 PowerState Level for each PowerMonitor Entity. 918 Finally, the monitoring of all the PowerMonitor Entities on the 919 SNMP agent can be turned on/off with the pmEnable MIB object. 921 8. MIB Definitions 923 -- ************************************************************ 924 -- 925 -- 926 -- This MIB is used to monitor Power Consumption of network 927 -- devices 928 -- 929 -- ************************************************************* 931 POWER-MONITOR-MIB DEFINITIONS ::= BEGIN 933 IMPORTS 934 MODULE-IDENTITY, 935 OBJECT-TYPE, 936 NOTIFICATION-TYPE, 937 mib-2, 938 Integer32, TimeTicks 939 FROM SNMPv2-SMI 940 MODULE-COMPLIANCE, 941 NOTIFICATION-GROUP, 942 OBJECT-GROUP 943 FROM SNMPv2-CONF 944 TEXTUAL-CONVENTION 945 FROM SNMPv2-TC 946 SnmpAdminString 947 FROM SNMP-FRAMEWORK-MIB 949 RowStatus, TimeInterval 950 FROM SNMPv2-TC 951 PhysicalIndexOrZero 952 FROM ENTITY-MIB; 953 pethPsePortIndex, pethPsePortGroupIndex 954 FROM POWER-ETHERNET-MIB; 956 powerMonitorMIB MODULE-IDENTITY 957 LAST-UPDATED "201001130000Z" 958 ORGANIZATION "Cisco Systems, Inc." 959 CONTACT-INFO 960 "Cisco Systems 961 Customer Service 963 Postal: 170 W Tasman Drive 964 San Jose, CA 95134 965 USA 967 Tel: +1 800 553-NETS 969 E-mail: cs-snmp@cisco.com" 971 DESCRIPTION 972 "This MIB is used to monitor power usage in network 973 Devices." 974 REVISION 975 "201001130000Z" 976 DESCRIPTION 977 "This Latest draft of this MIB module." 979 ::= { mib-2 xxxxx } 981 powerMonitorMIBNotifs OBJECT IDENTIFIER 982 ::= { powerMonitorMIB 0 } 984 powerMonitorMIBObjects OBJECT IDENTIFIER 985 ::= { powerMonitorMIB 1 } 987 powerMonitorMIBConform OBJECT IDENTIFIER 988 ::= { powerMonitorMIB 2 } 990 -- Textual Conventions 992 PowerMonitorLevel ::= TEXTUAL-CONVENTION 993 STATUS current 994 DESCRIPTION 995 "An enumerated integer value that represents the value 996 of PowerState Level, a power setting at which a 997 PowerMonitor Entity uses power. 999 The PowerState Levels are divided into six operational 1000 states, and six non-operational states. Each non- 1001 operational state corresponds to an ACPI (Advanced 1002 Configuration and Power Interface Specification, 1003 http://www.acpi.info/spec30b.htm) 1004 Global and System level state between G3 (hard-off) and 1005 G1 (sleeping). The operational levels represent a 1006 performance state, and correspond to ACPI states P0 1007 (maximum performance & power) through P5 (minimum 1008 performance and minimum power). 1010 PowerMonitor Entities need not support all levels, but a 1011 subset of the levels that can be mapped to their system 1012 state. 1014 mechoff(1) : An off state. No entity features are 1015 available. The entity is unavailable. 1016 No power is being consumed and the power 1017 connector can be removed. This maps to 1018 the level G3 in ACPI. 1020 softoff(2) : Similar to off, but some components 1021 remain powered so the device can be woken 1022 from its off state. In soft-off, no 1023 context is saved and the device requires 1024 a complete boot when awakened. This maps 1025 to level G2 in ACPI. 1027 hibernate(3): No entity features are available. The 1028 entity may be awoken without requiring a 1029 complete boot, but the time for 1030 availability is longer than sleep. 1031 This is generally the same as save-to- 1032 disk where DRAM context is not 1033 maintained. Minimal, nearly zero, or zero 1034 power is consumed. This maps to level 1035 G1, S4 in ACPI. 1037 sleep(4) : No entity features are available. The 1038 entity may be available but the time 1039 for availability is longer than 1040 standby. This is generally the same as 1041 save-to-RAM, where DRAM context is 1042 maintained. Minimal power is consumed. 1043 This maps to level G1, S3 in ACPI. 1045 standby(5) : Indicates some entity features may not be 1046 available. The entity may be available 1047 but the time for availability is longer 1048 than ready. Processor context is not 1049 maintained. Minimal power is consumed. 1050 This maps to level G1, S2 in ACPI. 1052 ready(6) : Indicates some entity features may not 1053 be available. The entity itself may be 1054 available but there may be a time delay 1055 for availability. Processors are not 1056 executing, but their context is 1057 maintained. Low or less power is 1058 consumed. This maps to level G1, S1 in 1059 ACPI. 1061 low(7) : Indicates some features may not be 1062 available and the entity has taken 1063 measures/options to provide less than 1064 frugal usage. This maps to ACPI State 1065 G0; which includes operational levels 1066 low to full. 1068 frugal(8) : Indicates some features may not be 1069 available and the entity has take 1070 measures/options to provide less than 1071 medium usage. 1073 medium(9) : Indicates all entity features are 1074 available but the entity has taken 1075 measures/options to provide less than 1076 reduced usage. 1078 reduced(10) : Indicates all entity features are 1079 available but the entity has taken 1080 measures/options to provide less than 1081 high usage. 1083 high(11) : Indicates all entity features are 1084 available and power consumption is less 1085 than full. 1087 full(12) : Indicates all entity features are 1088 available and the entity is consuming the 1089 highest power." 1091 SYNTAX INTEGER { 1092 mechoff(1), 1093 softoff(2), 1094 hibernate(3), 1095 sleep(4), 1096 standby(5), 1097 ready(6), 1098 low(7), 1099 frugal(8), 1100 medium(9), 1101 reduced(10), 1102 high(11), 1103 full(12) 1104 } 1106 PowerMonitorId ::= TEXTUAL-CONVENTION 1107 STATUS current 1108 DESCRIPTION 1109 "A unique identifier for the PowerMonitor Entity in the 1110 PowerMonitor Domain. Implementation must ensure that the 1111 ID for each PowerMonitor Entity is unique among all 1112 entities within the PowerMonitor Domain. A Universally 1113 Unique Identifier (UUID) is typically used." 1115 REFERENCE 1116 "IETF RFC 4122" 1117 SYNTAX OCTET STRING (SIZE (16)) 1119 MonitorScale ::= TEXTUAL-CONVENTION 1120 STATUS current 1121 DESCRIPTION 1122 "The Monitor Scale: an integer value that represents the 1123 scale factor associated with the units used to measure 1124 the power or energy. 1126 For example, when used with pmPowerUnits, 3 represents 1127 10^-3 or milliwatts" 1128 REFERENCE 1129 "The International System of Units (SI), 1130 National Institute of Standards and Technology, 1131 Spec. Publ. 330, August 1991." 1132 SYNTAX INTEGER { 1133 yocto(-24), -- 10^-24 1134 zepto(-21), -- 10^-21 1135 atto(-18), -- 10^-18 1136 femto(-15), -- 10^-15 1137 pico(-12), -- 10^-12 1138 nano(-9), -- 10^-9 1139 micro(-6), -- 10^-6 1140 milli(-3), -- 10^-3 1141 units(0), -- 10^0 1142 kilo(3), -- 10^3 1143 mega(6), -- 10^6 1144 giga(9), -- 10^9 1145 tera(12), -- 10^12 1146 peta(15), -- 10^15 1147 exa(18), -- 10^18 1148 zetta(21), -- 10^21 1149 yotta(24) -- 10^24 1150 } 1152 PethPsePortIndexOrZero::= TEXTUAL-CONVENTION 1153 STATUS current 1154 DESCRIPTION 1155 "This textual convention is an extension of the 1156 pethPsePortIndex convention, which defines a greater than 1157 zero value used to identify a power Ethernet PSE port. 1158 This extension permits the additional value of zero. The 1159 semantics of the value zero are object-specific and must, 1160 therefore, be defined as part of the description of any 1161 object that uses this syntax. Examples of the usage of 1162 this extension are situations where none or all physical 1163 entities need to be referenced." 1164 SYNTAX Integer32 (0..2147483647) 1166 PethPsePortGroupIndexOrZero::= TEXTUAL-CONVENTION 1167 STATUS current 1168 DESCRIPTION 1169 "This textual convention is an extension of the 1170 pethPsePortGroupIndex convention, which defines a greater 1171 than zero value used to identify group containing the 1172 port to which a power Ethernet PSE is connected. This 1173 extension permits the additional value of zero. The 1174 semantics of the value zero are object-specific and must, 1175 therefore, be defined as part of the description of any 1176 object that uses this syntax. Examples of the usage of 1177 this extension are situations where none or all physical 1178 entities need to be referenced." 1179 SYNTAX Integer32 (0..2147483647) 1181 -- Objects 1183 pmTable OBJECT-TYPE 1184 SYNTAX SEQUENCE OF PmEntry 1185 MAX-ACCESS not-accessible 1186 STATUS current 1187 DESCRIPTION 1188 "This table lists PowerMonitor Entities." 1189 ::= { powerMonitorMIBObjects 1 } 1191 pmEntry OBJECT-TYPE 1192 SYNTAX PmEntry 1193 MAX-ACCESS not-accessible 1194 STATUS current 1195 DESCRIPTION 1196 "An entry describes attributes of a PowerMonitor 1197 Entity. Whenever the device creates/destroys a 1198 PowerMonitor Entity, the device creates/destroys 1199 a row in the pmTable." 1200 INDEX { pmIndex } 1201 ::= { pmTable 1 } 1203 PmEntry ::= SEQUENCE { 1204 pmIndex Integer32, 1205 pmPowerMonitorId PowerMonitorId, 1206 pmPhysicalEntity PhysicalIndexOrZero, 1207 pmethPortIndex PethPsePortIndexOrZero, 1208 pmethPortGrpIndex PethPsePortGroupIndexOrZero, 1209 pmDomainName SnmpAdminString, 1210 pmName SnmpAdminString, 1211 pmRoleDescription SnmpAdminString, 1212 pmPowerUnits MonitorScale, 1213 pmPowerUsage Integer32, 1214 pmPowerUsageNameplate Integer32, 1215 pmPowerUsageAccuracy Integer32, 1216 pmPowerUsageCaliber INTEGER, 1217 pmPowerLevel PowerMonitorLevel, 1218 pmPowerUsageCategory BITS, 1219 pmParentId PowerMonitorId 1220 } 1222 pmIndex OBJECT-TYPE 1223 SYNTAX Integer32 (1..2147483647) 1224 MAX-ACCESS not-accessible 1225 STATUS current 1226 DESCRIPTION 1227 "A unique value, greater than zero, for each PowerMonitor 1228 Entity. It is recommended that values are assigned 1229 contiguously starting from 1. The value for each pmIndex 1230 must remain constant at least from one re-initialization 1231 of the entity's network management system to the next re- 1232 initialization." 1233 ::= { pmEntry 1 } 1235 pmPowerMonitorId OBJECT-TYPE 1236 SYNTAX PowerMonitorId 1237 MAX-ACCESS read-only 1238 STATUS current 1239 DESCRIPTION 1240 "This object indicates the PowerMonitor UUID identifier. 1241 This object value must be unique within the PowerMonitor 1242 Domain." 1243 ::= { pmEntry 2 } 1245 pmPhysicalEntity OBJECT-TYPE 1246 SYNTAX PhysicalIndexOrZero 1247 MAX-ACCESS read-only 1248 STATUS current 1249 DESCRIPTION 1250 "This object contains the index of a physical entity in 1251 the ENTITY MIB. This physical entity is the given 1252 Observation Point. If such a physical entity cannot be 1253 specified or is not known then the object is zero." 1254 ::= { pmEntry 3 } 1256 pmethPortIndex OBJECT-TYPE 1257 SYNTAX PethPsePortIndexOrZero 1258 ACCESS read-only 1259 STATUS mandatoty 1260 DESCRIPTION 1261 "This variable uniquely identifies the power Ethernet 1262 port to which the attached device is connected [RFC3621]. 1263 If such a power Ethernet port cannot be specified or is 1264 not known then the object is zero." 1265 ::= { pmEntry 4 } 1267 pmethPortGrpIndex OBJECT-TYPE 1268 SYNTAX PethPsePortGroupIndexOrZero 1269 ACCESS read-only 1270 STATUS mandatory 1271 DESCRIPTION 1272 "This variable uniquely identifies the group containing 1273 the port to which a power Ethernet PSE is connected 1274 [RFC3621]. 1275 If such a group cannot be specified or is not known then 1276 the object is zero." 1277 ::= { pmEntry 5 } 1279 pmDomainName OBJECT-TYPE 1280 SYNTAX SnmpAdminString 1281 MAX-ACCESS read-write 1282 STATUS current 1283 DESCRIPTION 1284 "This object specifies the name of a PowerMonitor Domain 1285 for the PowerMonitor Entity. This object specifies a 1286 null string if no PowerMonitor Domain name is configured. 1287 The value of pmDomainName must remain constant at least 1288 from one re-initialization of the entity's network 1289 management system to the next re-initialization." 1290 ::= { pmEntry 6 } 1292 pmName OBJECT-TYPE 1293 SYNTAX SnmpAdminString 1294 MAX-ACCESS read-write STATUS current 1295 DESCRIPTION 1296 "This object specifies a printable name, a text string, 1297 for the PowerMonitor Entity. It is preferred, but not 1298 required that pmName be unique. 1299 The process to assign the pmName is implementation 1300 specific. Example: DNS Name, MAC address in canonical 1301 form, ifName, etc..." 1302 ::= { pmEntry 7 } 1304 pmRoleDescription OBJECT-TYPE 1305 SYNTAX SnmpAdminString 1306 MAX-ACCESS read-write 1307 STATUS current 1308 DESCRIPTION 1309 "This object specifies an administratively assigned name 1310 to indicate the purpose a PowerMonitor Entity serves in 1311 the network. 1313 For example, we can have a phone deployed to a lobby with 1314 pmRoleDescription as 'Lobby IP Phone'. 1316 This object specifies a null string if no role 1317 description is configured." 1318 ::= { pmEntry 8 } 1320 pmPowerUnits OBJECT-TYPE 1321 SYNTAX MonitorScale 1322 MAX-ACCESS read-only 1323 STATUS current 1324 DESCRIPTION 1325 "The magnitude of Watts for the usage value in 1326 pmPowerUsage and pmPowerUsageNameplate." 1327 ::= { pmEntry 9 } 1329 pmPowerUsage OBJECT-TYPE 1330 SYNTAX Integer32 1331 UNITS "Watts" 1332 MAX-ACCESS read-only 1333 STATUS current 1334 DESCRIPTION 1335 "This object indicates the instantaneous consumption for 1336 the PowerMonitor Entity. This value is specified in SI 1337 units of watts with the magnitude of watts (milliwatts, 1338 kilowatts, etc.) indicated separately in pmPowerUnits. 1340 If the PowerMonitor Entity is a consumer (bit value 1 in 1341 pmPowerUsageCategory, the usage value will be positive. 1342 If the PowerMonitor Entity is a producer (bit value 2 in 1343 pmPowerUsageCategory, the usage value will be negative. 1345 This should be less than or equal to the maximum power 1346 that can be consumed at the specified level." 1347 ::= { pmEntry 10 } 1349 pmPowerUsageNameplate OBJECT-TYPE 1350 SYNTAX Integer32 1351 UNITS "Watts" 1352 MAX-ACCESS read-only 1353 STATUS current 1354 DESCRIPTION 1355 "This object indicates the rated maximum consumption for 1356 the fully populated PowerMonitor Entity. The nameplate 1357 power requirements are the worst-case power consumption 1358 numbers and in almost all cases, are well above the 1359 expected operating level. Nameplate power is widely used 1360 for power provisioning. This value is specified in SI 1361 units of watts with the magnitude of watts (milliwatts, 1362 kilowatts, etc.) indicated separately in pmPowerUnits. 1364 Nameplate power is widely used for capacity and 1365 provisioning planning. It is typically a value provided 1366 via experimentation and prediction from the manufacturer 1367 of the entity." 1369 ::= { pmEntry 11 } 1371 pmPowerUsageAccuracy OBJECT-TYPE 1372 SYNTAX Integer32 (0..10000) 1373 UNITS "hundredths of percent" 1374 MAX-ACCESS read-only 1375 STATUS current 1376 DESCRIPTION 1377 "This object indicates a percentage value in 100ths of a 1378 percent representing the accuracy to which the usage, 1379 reported by the pmPowerUsage can be assumed. Example 1010 1380 means the reported usage is accurate to +/- 10.1 percent. 1381 This value is zero if the accuracy is unknown. 1383 ANSI and IEC define the following accuracy classes for 1384 power measurement: 1385 IEC 62053-22 & 60044-1 class 0.1, 0.2, 0.5, 1 & 3. 1386 ANSI C12.20 class 0.2 & 0.5" 1387 ::= { pmEntry 12 } 1389 pmPowerUsageCaliber OBJECT-TYPE 1390 SYNTAX INTEGER { 1391 unknown(1), 1392 actual(2) , 1393 trusted(3), 1394 predicted(4), 1395 presumed(5) 1396 } 1397 MAX-ACCESS read-only 1398 STATUS current 1399 DESCRIPTION 1400 "This object specifies how the usage value, reported by 1401 pmPowerUsage, is obtained. 1403 - unknown: This indicates that the way the usage is 1404 determined is unknown. In some cases, entities report 1405 aggregate power like what a lighting controller or 1406 aggregate controller does. In such cases it is not known 1407 whether the usage reported is actual or presumed. 1409 - actual: This indicates that the usage data reported is 1410 not presumed or predicted but the real power drawn. A 1411 PoE phone drawing X amount of power can be determined by 1412 reading from the port. 1414 - trusted: This indicates that the usage data reported 1415 was reported from another source. For example, a PoE 1416 phone can report the actual usage as X W, but this is not 1417 typically as accurate as port level metering on the 1418 switch. Trusted is higher caliber than predicted. 1420 - predicted: This indicates that the actual power drawn 1421 cannot be determined. The value is an estimate based upon 1422 the device type, state, and/or utilization. Predicted is 1423 a higher caliber than presumed. For example, a switch is 1424 known to draw 200w when PoE on all interfaces is 1425 disabled, and 600w when PoE is fully enabled. 1427 - presumed: This indicates that the actual power drawn 1428 cannot be determined but can be presumed from a model. 1429 Presumed is the lowest caliber. For example, a PC Model 1430 X draws 200W, while a PC Model Y draws 210W." 1432 ::= { pmEntry 13 } 1434 pmParentId OBJECT-TYPE 1435 SYNTAX PowerMonitorID 1436 ACCESS read-only 1437 STATUS mandatory 1438 DESCRIPTION 1439 "If the current PowerMonitor Entity has a PowerMonitor 1440 Parent, then its PowerMonitor Id value is set in 1441 pmParentId. Otherwise, the pmParentId value is the null 1442 string." 1443 ::= { pmEntry 14 } 1445 pmPowerLevel OBJECT-TYPE 1446 SYNTAX PowerMonitorLevel 1447 MAX-ACCESS read-write 1448 STATUS current 1449 DESCRIPTION 1450 "This object specifies the current power level (1..12) 1451 for the PowerMonitor Entity." 1452 ::= { pmEntry 15 } 1454 pmPowerUsageCategory OBJECT-TYPE 1455 SYNTAX BITS { 1456 consumer(1), 1457 producer(2), 1458 meter(3) 1459 } 1460 MAX-ACCESS read-only 1461 STATUS current 1462 DESCRIPTION 1463 "This object specifies the power usage type of the 1464 entity. An entity could be producing power when 1465 pmPowerUsageCategory is producer(2) or a consumer of 1466 power consumer (1) or a hybrid - consumer and 1467 producer(3). Negative values of power usage are 1468 permissible to indicate the entities as power sources. 1470 Consumer: This indicates that the entity 1471 consumes power. 1472 Producer: This indicates that the entity 1473 generates power. 1474 Meter: This indicates that the entity is a 1475 meter which reads the power consumed 1476 or produced." 1477 ::= { pmEntry 16 } 1479 pmLevelTable OBJECT-TYPE 1480 SYNTAX SEQUENCE OF PmLevelEntry 1481 MAX-ACCESS not-accessible 1482 STATUS current 1483 DESCRIPTION 1484 "This table enumerates the maximum power usage in watts 1485 at each PowerState Level for each PowerMonitor Entity. 1487 This table has an expansion dependent relationship on the 1488 pmTable, containing rows describing each PowerState Level 1489 for the corresponding PowerMonitor Entity." 1490 ::= { powerMonitorMIBObjects 2 } 1492 pmLevelEntry OBJECT-TYPE 1493 SYNTAX PmLevelEntry 1494 MAX-ACCESS not-accessible 1495 STATUS current 1496 DESCRIPTION 1497 "A pmLevelEntry extends a corresponding pmEntry. This 1498 entry displays max usage and delta values at each 1499 possible power level. 1500 For example, given the values of a PowerMonitor 1501 Entity corresponds to a maximum usage of 11W at the 1502 level 1 (off), 6 (low), 8 (medium), 12 (full): 1504 Level MaxUsage Units 1505 1 0 0 1506 5 0 0 1507 6 8 0 1508 7 8 0 1509 8 11 0 1511 12 11 0" 1513 INDEX { 1514 pmIndex, 1515 pmLevelIndex 1516 } 1517 ::= { pmLevelTable 1 } 1519 PmLevelEntry ::= SEQUENCE { 1520 pmLevelIndex PowerMonitorLevel, 1521 pmLevelMaxUsage Integer32, 1522 pmLevelPowerUnits MonitorScale 1523 } 1525 pmLevelIndex OBJECT-TYPE 1526 SYNTAX PowerMonitorLevel 1527 MAX-ACCESS not-accessible 1528 STATUS current 1529 DESCRIPTION 1530 "This object indicates the level for which this entry 1531 describes the power usage." 1532 ::= { pmLevelEntry 1 } 1534 pmLevelMaxUsage OBJECT-TYPE 1535 SYNTAX Integer32 1536 UNITS "Watts" 1537 MAX-ACCESS read-only 1538 STATUS current 1539 DESCRIPTION 1540 "This object indicates the maximum power usage for the 1541 PowerMonitor Entity at the particular PowerState Level. 1542 This value is specified in SI units of watts with the 1543 magnitude of the units (milliwatts, kilowatts, etc.) 1544 indicated separately in pmLevelPowerUnits." 1545 ::= { pmLevelEntry 2 } 1547 pmLevelPowerUnits OBJECT-TYPE 1548 SYNTAX MonitorScale 1549 MAX-ACCESS read-only 1550 STATUS current 1551 DESCRIPTION 1552 "The magnitude of watts for the usage value in 1553 pmLevelMaxUsage." 1554 ::= { pmLevelEntry 3 } 1556 emDemandControlTable OBJECT-TYPE 1557 SYNTAX SEQUENCE OF EmDemandControlEntry 1558 MAX-ACCESS not-accessible 1559 STATUS current 1560 DESCRIPTION 1561 "Controls and configures the demand table emDemandTable." 1562 ::= { powerMonitorMIBObjects 3 } 1564 emDemandControlEntry OBJECT-TYPE 1565 SYNTAX EmDemandControlEntry 1566 MAX-ACCESS not-accessible 1567 STATUS current 1568 DESCRIPTION 1569 "An entry controls energy usage measurements." 1570 INDEX { pmIndex } 1571 ::= { emDemandControlTable 1 } 1573 EmDemandControlEntry ::= SEQUENCE { 1574 emDemandControlIntervalLength TimeInterval, 1575 emDemandControlIntervalNumber Integer32, 1576 emDemandControlSampleRate Integer32, 1577 emDemandControlStatus RowStatus 1578 } 1580 emDemandControlIntervalLength OBJECT-TYPE 1581 SYNTAX TimeInterval 1582 UNITS "Seconds" 1583 MAX-ACCESS read-write 1584 STATUS current 1585 DESCRIPTION 1586 " This object indicates the length of time in seconds 1587 over which the average demand is computed. The 1588 computation is based on PowerMonitor Entity internal 1589 sampling rate of power consumption of the entity. The 1590 sampling rate may differ based on device capabilities. 1591 The average power consumption is computed over the length 1592 of the demand interval." 1593 DEFVAL { 900 } 1594 ::= { emDemandControlEntry 1 } 1596 emDemandControlIntervalNumber OBJECT-TYPE 1597 SYNTAX Integer32 1598 MAX-ACCESS read-write 1599 STATUS current 1600 DESCRIPTION 1601 "The number of demand intervals maintained. Whenever the 1602 maximum number of entry is reached, the new demand 1603 interval replaces the oldest one, except if the oldest 1604 one is the emDemandIntervalMax. In which case, the next 1605 oldest interval is replaced." 1606 DEFVAL { 10 } 1607 ::= { emDemandControlEntry 2 } 1609 emDemandControlSampleRate OBJECT-TYPE 1610 SYNTAX Integer32 1611 UNITS "Milliseconds" 1612 MAX-ACCESS read-write 1613 STATUS current 1614 DESCRIPTION 1615 "The sampling rate in milliseconds at which the 1616 PowerMonitor Entity should poll the instantaneous power 1617 usage in order to compute the average 1618 emDemandIntervalEnergyUsed measurement in the table 1619 emDemandTable. The PowerMonitor should initially set 1620 this sample rate to a reasonable value, i.e. a compromise 1621 between intervals that will provide good accuracy by not 1622 being too long, but not so short that it would impact the 1623 PowerMonitor Entity performance by requesting continuous 1624 polling." 1625 DEFVAL { 1000 } 1626 ::= { emDemandControlEntry 3 } 1628 emDemandControlStatus OBJECT-TYPE 1629 SYNTAX RowStatus 1630 MAX-ACCESS read-create 1631 STATUS current 1632 DESCRIPTION 1633 "The status of this row. An entry may not exist in the 1634 active state unless all objects in the entry have an 1635 appropriate value. If this object is not equal to 1636 active(1), all associated entries in the emDemandTable 1637 shall be deleted." 1638 ::= {emDemandControlEntry 4 } 1640 emDemandTable OBJECT-TYPE 1641 SYNTAX SEQUENCE OF EmDemandEntry 1642 MAX-ACCESS not-accessible 1643 STATUS current 1644 DESCRIPTION 1645 "This table lists PowerMonitor Entity energy usage 1646 measurements. Only when the PowerMonitor Entity has the 1647 pmPowerUsageCaliber value set to actual(2) will this 1648 table be populated." 1649 ::= { powerMonitorMIBObjects 4 } 1651 emDemandEntry OBJECT-TYPE 1652 SYNTAX EmDemandEntry 1653 MAX-ACCESS not-accessible 1654 STATUS current 1655 DESCRIPTION 1656 "An entry describes energy usage measurements." 1657 INDEX { pmIndex, emDemandIntervalStartTime } 1658 ::= { emDemandTable 1 } 1660 EmDemandEntry ::= SEQUENCE { 1661 emDemandIntervalStartTime TimeTicks, 1662 emDemandIntervalEnergyUsed Integer32, 1663 emDemandIntervalEnergyUnits MonitorScale, 1664 emDemandIntervalMax Integer32 1665 } 1667 emDemandIntervalStartTime OBJECT-TYPE 1668 SYNTAX TimeTicks 1669 UNITS "hundredths of seconds" 1670 MAX-ACCESS not-accessible 1671 STATUS current 1672 DESCRIPTION 1673 "The time (in hundredths of a second) since the 1674 network management portion of the system was last 1675 re-initialized, as specified in the sysUpTime [RFC3418]. 1676 This object is useful for reference of interval period 1677 for which the demand is measured. " 1678 ::= { emDemandEntry 1 } 1680 emDemandIntervalEnergyUsed OBJECT-TYPE 1681 SYNTAX Integer32 1682 UNITS "Watt-hours" 1683 MAX-ACCESS read-only 1684 STATUS current 1685 DESCRIPTION 1686 "This object indicates the energy used in units of watt- 1687 hours for the PowerMonitor Entity over the defined 1688 interval. This value is specified in the common billing 1689 units of watts-hours with the magnitude of watt-hours 1690 (kW-Hr, MW-Hr, etc.) indicated separately in 1691 emDemandIntervalPowerScale." 1692 ::= { emDemandEntry 2 } 1694 emDemandIntervalEnergyUnits OBJECT-TYPE 1695 SYNTAX MonitorScale 1696 MAX-ACCESS read-only 1697 STATUS current 1698 DESCRIPTION 1699 "This magnitude of watt-hours for the energy field in 1700 emDemandIntervalEnergyUsed." 1701 ::= { emDemandEntry 3 } 1703 emDemandIntervalMax OBJECT-TYPE 1704 SYNTAX Integer32 1705 UNITS "Watt-hours" 1706 MAX-ACCESS read-only 1707 STATUS current 1708 DESCRIPTION 1709 "This object is the maximum demand ever observed in 1710 emDemandIntervalEnergyUsed since the monitoring started. 1711 This value is specified in the common billing units of 1712 watts-hours with the magnitude of watt-hours (kW-Hr, 1713 MW-Hr, etc.) indicated separately in 1714 emDemandIntervalEnergyUnits." 1715 ::= { emDemandEntry 4 } 1717 pmEnable OBJECT-TYPE 1718 SYNTAX INTEGER { 1719 enable(1), 1720 disable(2) 1721 } 1722 MAX-ACCESS read-write 1723 STATUS current 1724 DESCRIPTION 1725 "A control object to activate or de-activate all 1726 PowerMonitor Entities on the SNMP agent (e.g. Switch). 1728 enable: enables all PowerMonitor Entities. 1730 disable: disables all PowerMonitor Entities" 1732 ::= { powerMonitorMIBObjects 5 } 1734 pmVersion OBJECT-TYPE 1735 SYNTAX SnmpAdminString 1736 MAX-ACCESS read-only 1737 STATUS current 1738 DESCRIPTION 1739 "This object specifies the current version of the 1740 PowerMonitor software running on a PowerMonitor 1741 Entity." 1742 ::= { powerMonitorMIBObjects 6 } 1744 -- Notifications 1746 pmLevelChange NOTIFICATION-TYPE 1747 OBJECTS { pmIndex, pmPowerLevel } 1748 STATUS current 1749 DESCRIPTION 1750 "The SNMP entity generates the PmLevelChange when 1751 the value of pmPowerLevel has changed for the 1752 PowerMonitor Entity represented by the pmIndex" 1753 ::= { powerMonitorMIBNotifs 1 } 1755 -- Conformance 1757 powerMonitorMIBCompliances OBJECT IDENTIFIER 1758 ::= { powerMonitorMIB 3 } 1760 powerMonitorMIBGroups OBJECT IDENTIFIER 1761 ::= { powerMonitorMIB 4 } 1763 powerMonitorMIBFullCompliance MODULE-COMPLIANCE 1764 STATUS current 1765 DESCRIPTION 1766 "When this MIB is implemented with support for 1767 read-create, then such an implementation can 1768 claim full compliance. Such devices can then 1769 be both monitored and configured with this MIB." 1770 MODULE -- this module 1771 MANDATORY-GROUPS { 1772 powerMonitorMIBTableGroup, 1773 powerMonitorMIBLevelTableGroup, 1774 powerMonitorMIBNotifGroup 1775 } 1777 ::= { powerMonitorMIBCompliances 1 } 1779 powerMonitorMIBReadOnlyCompliance MODULE-COMPLIANCE 1780 STATUS current 1781 DESCRIPTION 1782 "When this MIB is implemented without support for 1783 read-create (i.e. in read-only mode), then such an 1784 implementation can claim read-only compliance. Such a 1785 device can then be monitored but can not be configured 1786 with this MIB." 1787 MODULE -- this module 1788 MANDATORY-GROUPS { 1789 powerMonitorMIBTableGroup, 1790 powerMonitorMIBLevelTableGroup, 1791 powerMonitorMIBNotifGroup 1792 } 1794 OBJECT pmName 1795 MIN-ACCESS read-only 1796 DESCRIPTION 1797 "Write access is not required." 1799 OBJECT pmRoleDescription 1800 MIN-ACCESS read-only 1801 DESCRIPTION 1802 "Write access is not required." 1804 OBJECT pmDomainName 1805 MIN-ACCESS read-only 1806 DESCRIPTION 1807 "Write access is not required." 1809 OBJECT pmEnable 1810 MIN-ACCESS read-only 1811 DESCRIPTION 1812 "Write access is not required." 1814 ::= { powerMonitorMIBCompliances 2 } 1816 -- Units of Conformance 1818 powerMonitorMIBTableGroup OBJECT-GROUP 1819 OBJECTS { 1820 -- Note that object pmIndex is NOT 1821 -- included since it is not-accessible 1822 pmPowerMonitorId, 1823 pmPhysicalEntity, 1824 pmDomainName, 1825 pmName, 1826 pmRoleDescription, 1827 pmPowerUnits, 1828 pmPowerUsage, 1829 pmPowerUsageNameplate, 1830 pmPowerUsageAccuracy, 1831 pmPowerUsageCaliber, 1832 pmPowerLevel, 1833 pmPowerUsageCategory, 1834 pmEnable, 1835 pmVersion 1837 } 1838 STATUS current 1839 DESCRIPTION 1840 "This group contains the collection of all the objects 1841 related to the PowerMonitor Entity." 1842 ::= { powerMonitorMIBGroups 1 } 1844 powerMonitorMIBLevelTableGroup OBJECT-GROUP 1845 OBJECTS { 1846 -- pmLevelIndex, 1847 pmLevelMaxUsage, 1848 pmLevelPowerUnits 1849 } 1850 STATUS current 1851 DESCRIPTION 1852 "This group contains the collection of all the objects 1853 related to the PowerState Level." 1854 ::= { powerMonitorMIBGroups 2 } 1856 powerMonitorMIBNotifGroup NOTIFICATION-GROUP 1857 NOTIFICATIONS { 1858 pmLevelChange 1859 -- pmLevelIndex 1860 } 1861 STATUS current 1862 DESCRIPTION 1863 "This group contains the notifications for the power 1864 monitoring MIB Module." 1865 ::= { powerMonitorMIBGroups 3 } 1867 END 1869 9. Security Considerations 1871 Some of the readable objects in these MIB modules (i.e., objects 1872 with a MAX-ACCESS other than not-accessible) may be considered 1873 sensitive or vulnerable in some network environments. It is 1874 thus important to control even GET and/or NOTIFY access to these 1875 objects and possibly to even encrypt the values of these objects 1876 when sending them over the network via SNMP. These are the 1877 tables and objects and their sensitivity/vulnerability: 1879 All other objects and tables contain no data that is considered 1880 sensitive. 1882 SNMP versions prior to SNMPv3 did not include adequate security. 1883 Even if the network itself is secure (for example by using 1884 IPsec), even then, there is no control as to who on the secure 1885 network is allowed to access and GET/SET 1886 (read/change/create/delete) the objects in these MIB modules. 1888 It is RECOMMENDED that implementers consider the security 1889 features as provided by the SNMPv3 framework (see [RFC3410], 1890 section 8), including full support for the SNMPv3 cryptographic 1891 mechanisms (for authentication and privacy). 1893 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1894 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1895 enable cryptographic security. It is then a customer/operator 1896 responsibility to ensure that the SNMP entity giving access to 1897 an instance of these MIB modules is properly configured to give 1898 access to the objects only to those principals (users) that have 1899 legitimate rights to indeed GET or SET (change/create/delete) 1900 them. 1902 10. IANA Considerations 1904 The MIB module in this document uses the following IANA-assigned 1905 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 1907 Descriptor OBJECT IDENTIFIER value 1908 ---------- ----------------------- 1909 PowerMonitorMIB { mib-2 xxx } 1911 Additions to this MIB module are subject to Expert Review 1912 [RFC5226], i.e., review by one of a group of experts designated 1913 by an IETF Area Director. The group of experts MUST check the 1914 requested MIB objects for completeness and accuracy of the 1915 description. Requests for MIB objects that duplicate the 1916 functionality of existing objects SHOULD be declined. The 1917 smallest available OID SHOULD be assigned to a new MIB objects. 1918 The specification of new MIB objects SHOULD follow the structure 1919 specified in Section 6 and MUST be published using a well- 1920 established and persistent publication medium. 1922 11. References 1924 11.1. Normative References 1926 [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 1927 3)", RFC 4133, August 2005. 1929 [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB", 1930 RFC3621, December 2003. 1932 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity 1933 Sensor Management Information Base", RFC 3433, December 1934 2002. 1936 [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 1937 4268,November 2005. 1939 [POWER-MON-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., 1940 and M. Chandramouli, "Requirements for Power 1941 Monitoring", draft-quittek-power-monitoring- 1942 requirements-00 (work in progress), October 2009. 1944 [ACPI] "Advanced Configuration and Power Interface 1945 Specification", http://www.acpi.info/spec30b.htm 1947 11.2. Informative References 1949 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1950 Requirement Levels, BCP 14, RFC 2119, March 1997. 1952 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1953 Schoenwaelder, Ed., "Structure of Management 1954 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1955 1999. 1957 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1958 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1959 STD 58, RFC 2579, April 1999. 1961 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1962 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1963 April 1999. 1965 [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie, 1966 "Guidelines for Writing an IANA Considerations Section 1967 in RFCs ", BCP 26, RFC 5226, May 2008. 1969 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1970 "Introduction and Applicability Statements for Internet 1971 Standard Management Framework ", RFC 3410, December 1972 2002. 1974 [RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group 1975 MIB", RFC 2863, June 2000. 1977 [RFC3418] Presun, R., Case, J., McCloghrie, K., Rose, M, and S. 1978 Waldbusser, " Management Information Base (MIB) for the 1979 Simple Network Management Protocol (SNMP)", RFC3418, 1980 December 2002. 1982 12. Authors' Addresses 1984 Benoit Claise 1985 Cisco Systems Inc. 1986 De Kleetlaan 6a b1 1987 Diegem 1813 1988 BE 1990 Phone: +32 2 704 5622 1991 Email: bclaise@cisco.com 1993 Mouli Chandramouli 1994 Cisco Systems, Inc. 1995 Sarjapur Outer Ring Road 1996 Bangalore, 1997 IN 1999 Phone: +91 80 4426 3947 2000 Email: moulchan@cisco.com 2002 John Parello 2003 Cisco Systems Inc. 2004 3550 Cisco Way 2005 San Jose, California 95134 2006 US 2007 Phone: +1 408 525 2339 2008 Email: jparello@cisco.com 2010 Brad Schoening 2011 Cisco Systems Inc. 2012 3550 Cisco Way 2013 San Jose, California 95134 2014 US 2016 Phone: +1 408 525 2339 2017 Email: braschoe@cisco.com