idnits 2.17.1 draft-claise-power-management-arch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (October 20, 2010) is 4908 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) == Outdated reference: A later version (-02) exists of draft-quittek-power-monitoring-requirements-01 == Outdated reference: A later version (-09) exists of draft-claise-energy-monitoring-mib-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Claise 3 Internet-Draft J. Parello 4 Intended Status: Informational B. Schoening 5 Expires: April 20, 2011 Cisco Systems, Inc. 6 October 20, 2010 8 Power Management Architecture 9 draft-claise-power-management-arch-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance 14 with the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its working 18 groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed 31 at http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on September, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described 47 in Section 4.e of the Trust Legal Provisions and are provided 48 without warranty as described in the Simplified BSD License. 50 Abstract 52 This document defines the power management architecture. 54 Table of Contents 56 1. Introduction.............................................. 4 57 2. Use Cases & Requirements.................................. 5 58 3. Terminology............................................... 5 59 4. Energy Management Reference Model......................... 7 60 5. Architecture High Level Concepts and Scope................ 9 61 5.1. Power Monitor Information........................... 11 62 5.2. Power Monitor Meter Domain.......................... 11 63 5.3. Power Monitor Parent and Child...................... 11 64 5.4. Power Monitor Context............................... 12 65 5.5. Power Monitor Levels................................ 13 66 5.6. Power Monitor Usage Measurement..................... 16 67 5.7. Optional Power Usage Quality........................ 17 68 5.8. Optional Energy Measurement......................... 18 69 5.9. Optional Battery Information........................ 18 70 6. Power Monitor Children Discovery......................... 18 71 7. Configuration............................................ 19 72 8. Fault Management......................................... 20 73 9. IPFIX.................................................... 20 74 10. Relationship with Other Standards Development 75 Organizations............................................... 21 76 10.1. Information Modeling............................... 21 77 10.2. Power Levels....................................... 21 78 11. Implementation Scenarios................................ 22 79 Scenario 1: Switch with PoE endpoints.................... 22 80 Scenario 2: Switch with PoE endpoints with further connected 81 device(s)................................................ 22 82 Scenario 3: A switch with Wireless Access Points......... 22 83 Scenario 4: Network connected facilities gateway......... 23 84 Scenario 5: Data center network.......................... 23 85 Scenario 6: Building gateway device...................... 23 86 Scenario 7: Power consumption of UPS..................... 23 87 Scenario 8: Power consumption of battery-based devices... 24 88 12. Security Considerations................................. 24 89 12.1. Security Considerations for SNMP...................... 24 90 12.2. Security Considerations for IPFIX..................... 25 91 13. IANA Considerations..................................... 25 92 14. Acknowledgments......................................... 25 93 15. References.............................................. 25 94 Normative References..................................... 25 95 Informative References................................... 26 97 TO DO 99 - Question for the Working Group: Should the WG consider 100 IPFIX in this architecture? 102 - Question for the Working Group: How to specify the notion 103 of child capabilities, i.e. the capabilities that the 104 Power Monitor Parents have with Power Monitor Children. 105 For Example: 106 1. Monitoring (only reporting) 107 2. Configuration power state 108 3. Configuration: power 109 Example: on a PC, we can set power level without knowing 110 the power. A solution must be specified in this draft. 112 - Question for the Working Group: Should transition states 113 be tracked when setting a level. Example: The configured 114 level is set to Off from High. The Actual level will 115 take time to update as the device powers down. Should 116 there be transitions shown or will the two variables 117 suffice to track the device state. 119 - Question for working group: Should implementation 120 scenarios be incorporated in the architecture draft 122 - We should have a similar section, for all the drafts, 123 which includes an overview of all EMAN documents. 125 1. Introduction 127 Network management is typically divided into the five main 128 network management areas defined in the ISO Telecommunications 129 Management Network model: Fault, Configuration, Accounting, 130 Performance, and Security Management. Absent from this model is 131 any consideration of energy management, which is now becoming a 132 critical area of concern worldwide. 134 This document defines an architecture for power management for 135 devices within or connected to communication networks. This 136 architecture includes monitoring for power state and energy 137 consumption of networked elements, covering the requirements 138 specified in [POWER-MON-REQ]. It also goes a step further in 139 defining some elements of configuration. 141 Energy management is applicable to devices in communication 142 networks. Target devices for this specification include (but 143 are not limited to): routers, switches, Power over Ethernet 144 (PoE) endpoints, protocol gateways for building management 145 systems, intelligent meters, home energy gateway, hosts and 146 servers, sensor proxies, etc. 148 Where applicable, device monitoring extends to the individual 149 components of the device and to any attached dependent devices. 150 For example: A device can contain components that are 151 independent from a power-state point of view, such as line 152 cards, processor cards, hard drives. A device can also have 153 dependent attached devices, such as a switch with PoE endpoints 154 or a power distribution unit with attached endpoints. 156 2. Use Cases & Requirements 158 Requirements for power and energy monitoring for networking 159 devices are specified in [POWER-MON-REQ]. The requirements in 160 [POWER-MON-REQ] cover devices typically found in communications 161 networks, such as switches, routers, and various connected 162 endpoints. For a power monitoring architecture to be useful, it 163 should also apply to facility meters, power distribution units, 164 gateway proxies for commercial building control, home automation 165 devices, and devices that interface with the utility and/or 166 smart grid. Accordingly, this architecture, the scope is 167 broader than that specified in [POWER-MON-REQ]. Several 168 scenarios that cover these broader use cases are presented later 169 in Section 11. - Implementation Scenarios. 171 3. Terminology 173 This section contains definitions of important terms used 174 throughout this specification. 176 IPFIX-specific terminology used in this document is defined in 177 section 2 of [RFC5101]. For example: Flow Record, Collector , 178 etc... As in [RFC5101], these IPFIX-specific terms have the 179 first letter of a word capitalized. 181 Power Monitor 183 A Power Monitor is a component within a system of components 184 that provides power, draws power, or reports energy consumption 185 on behalf of another Power Monitor. It can be independently 186 managed from a power-monitoring and power-state configuration 187 point of view. Examples of Power Monitors are: a router line 188 card, a motherboard with a CPU, an IP phone connected with a 189 switch, etc. 191 Power Monitor Parent 193 A Power Monitor Parent is a Power Monitor that is the root of 194 one or more subtending Power Monitors, called Power Monitor 195 Children. The Power Monitor Parent is able to collect data 196 about or report on the power state and energy consumption of its 197 Power Monitor Children. 199 For example: A Power-over-Ethernet (PoE) device (such as an IP 200 phone or an access point) is attached to a switch port. The 201 switch is the source of power for the attached device, so the 202 Power Monitor Parent is the switch, and the Power Monitor Child 203 is the device attached to the switch. 205 The Power Monitor Parent may report data or implement actions on 206 behalf of the Power Monitor Child. These capabilities must be 207 enumerated by the Power Monitor Parent. 209 The communication between the parent and child for monitoring or 210 collection of power data is left to the device manufacturer. For 211 example: A parent switch may use LLDP to communicate with a 212 connected child, and a parent lighting controller may use BACNET 213 to communicate with child lighting devices. 215 Power Monitor Child 217 A Power Monitor Child is a Power Monitor associated with a Power 218 Monitor Parent, and which reports its power usage and power 219 state to its Power Monitor Parent. The Power Monitor Child may 220 or may not draw power from its Power Monitor Parent. . 222 Power Monitor Meter Domain 224 A Power Monitor Meter Domain is a name or name space that 225 logically groups Power Monitors into a zone of manageable power 226 usage. Typically, this zone will have as members all Power 227 Monitors that are powered from the same electrical panel or 228 panels for which there is a meter or sub meter. For example: 229 All Power Monitors receiving power from the same distribution 230 panel of a building, or all Power Monitors in a building for 231 which there is one main meter, would comprise a Power Monitor 232 Meter Doman. From the standpoint of power-use monitoring, it is 233 useful to report the total power usage as the sum of power 234 consumed by all the Power Monitors within a Power Monitor Meter 235 Domain and then correlate that value with the metered usage. 237 Power Level 239 A Power Level is a uniform way to classify power settings on a 240 Power Monitor (e.g., shut, hibernate, sleep, high). Power 241 Levels can be viewed as an interface for the underlying device- 242 implemented power settings. 244 Manufacturer Power Level 246 A Manufacturer Power Level is a device-specific way to classify 247 power settings implemented on a Power Monitor. For cases where 248 the implemented power settings cannot be directly mapped to 249 Power Levels, we can use the Manufacturer Power Levels to 250 enumerate and show the relationship between the implemented 251 power settings and the Power Level interface. 253 4. Energy Management Reference Model 255 +---------------+ 256 | NMS | - 257 +-----+---+-----+ | 258 | | | 259 | | | S 260 +---------+ +-------+ | N 261 | | | M 262 | | | P 263 +---------------+ +------+-------+ | 264 | Power Monitor | | Power Monitor | | 265 | Parent 1 | ... | Parent N | - 266 +---------------+ +---------------+ 267 ||| 268 (protocol ||| 269 out of ||| +-------------+---------+ 270 the scope)|||------| Power Monitor Child 1 | 271 || +-----------------------+ 272 || 273 || +-------------+---------+ 274 ||-------| Power Monitor Child 2 | 275 | +-----------------------+ 276 | 277 | 278 |-------- ... 279 | 280 | 281 | +-------------+---------+ 282 |--------| Power Monitor Child M | 283 +-----------------------+ 285 Figure 1: Energy Management Pull Reference Model 287 In this architecture a Network Management Station (NMS) will 288 poll MIB variables on a Power Monitors via SNMP. The Power 289 Monitor returns information for itself and for any Power Monitor 290 Children if applicable. The information returned will contain 291 business context, energy usage, power quality and other 292 information as described further. 294 The protocol between the Power Monitor Parent and Power Monitor 295 Children is out of scope of this document. The Power Monitor 296 Parent may speak to a Power Monitor Child using a manufacturer 297 selected protocol. This protocol may or may not based on IP. 298 In this way, a Power Monitor Parent acts as a PROXY for protocol 299 translation between the Power Monitor Parent and Child. The 300 Power Monitor Parent also acts as an aggregation point for other 301 subtended Power Monitor Children. 303 +---------------+ 304 | NMS/Collector | ^ S 305 +-----+---+-----+ | N 306 | | | M I 307 | | | P P 308 +---------+ +-------+ | & F 309 | | | N I 310 | | | O X 311 +---------------+ +------+-------+ | T 312 | Power Monitor | | Power Monitor | | . 313 | Parent 1 | ... | Parent N | - 314 +---------------+ +---------------+ 315 ||| 316 (protocol ||| 317 out of ||| +-------------+---------+ 318 the scope)|||------| Power Monitor Child 1 | 319 || +-----------------------+ 320 || 321 || +-------------+---------+ 322 ||-------| Power Monitor Child 2 | 323 | +-----------------------+ 324 | 325 | 326 |-------- ... 327 | 328 | 329 | +-------------+---------+ 330 |--------| Power Monitor Child M | 331 +-----------------------+ 333 Figure 2: Energy Management PUSH Reference Model 335 The Power Monitor Parents may send SNMP notifications regarding 336 their own state or the state of their Power Monitor Children. 337 The Power Monitor Children do not send SNMP notifications on 338 their own. 340 As discussed in [POWER-MON-REQ], the Power Monitor Parents may 341 export IPFIX Flow Records [RFC5101] to a Collector. The IPFIX 342 protocol is well suited for regular time series export of 343 similar information, such as the energy consumed by the Power 344 Monitor Children. 346 EDITOR'S NOTE: at this point in time, there is no draft 347 specifying the IPFIX Flow Records. 349 5. Architecture High Level Concepts and Scope 351 The scope of this architecture is to enable networking and 352 network-attached devices to be managed with respect to their 353 energy consumption or production. The goal is to make devices 354 energy-aware. 356 The architecture describes how to make a device aware of its 357 consumption or production of energy expressed as usage in watts. 358 This does not include: 360 - Manufacturing costs in currency or environmental units 361 - Embedded carbon or environmental equivalences of the device 362 itself 363 - Cost in currency or environmental impact to dismantle or 364 recycle the device 365 - Relationship to an electrical or smart grid 366 - Supply chain analysis 367 - Conversion of the usage or production of energy to units 368 expressed from the source of that energy (such as the greenhouse 369 gas emissions associated with 1000kW from a diesel source). 371 The remainder of this section describes the basic concepts of 372 the architecture. Each concept is examined in detail in 373 subsequent sections. 375 Examples are provided in a later section to show how these 376 concepts can be implemented. 378 The basic concepts are: 380 The Power Monitor will have basic naming and informational 381 descriptors to identify it in the network. 383 A Power Monitor can be part of a Power Monitor Meter Domain. A 384 Power Monitor Meter Domain is a manageable set of devices that 385 has a meter or sub-meter attached and typically corresponds to a 386 power distribution point or panel. 388 A Power Monitor can be a parent (Power Monitor Parent) or child 389 (Power Monitor Child) of another Power Monitor. This allows for 390 Power Monitor Parent to aggregate power reporting and control of 391 power information. 393 Each Power Monitor can have information to allow it to be 394 described in the context of the business or ultimate use. This 395 is in addition to its networked information. This allows for 396 tagging, grouping, and differentiation between Power Monitors 397 for NMS. 399 For control and universal monitoring, each Power Monitor 400 implements or declares a set of known Power Levels. The Power 401 Levels are mapped to Manufacturer Power Levels that indicate the 402 specific power settings for the device implementing the Power 403 Monitor. 405 When the Power Level is set, a Power Monitor may be busy at the 406 request time. The Power Monitor will set the desired level and 407 then update the actual Power Level when the priority task is 408 finished. This mechanism implies two different Power Level 409 variables: actual versus desired. 411 EDITOR'S NOTE: The transition state will have to be specified. 413 Each Power Monitor will have usage information that describes 414 the power information along with how that usage was obtained or 415 derived. 417 Optionally, a Power Monitor can further describe the power 418 information with power quality information reflecting the 419 electrical characteristics of the measurement. 421 Optionally, a Power Monitor can provide power usage over time to 422 describe energy consumption 424 If a Power Monitor has one or more batteries, it can provide 425 optional battery information as well. 427 5.1. Power Monitor Information 429 Every Power Monitor should have a unique printable name, and 430 must have a unique Power Monitor index. 432 Possible naming conventions are: textual DNS name, MAC-address 433 of the device, interface ifName, or a text string uniquely 434 identifying the Power Monitor. As an example, in the case of IP 435 phones, the Power Monitor name can be the device DNS name. 437 5.2. Power Monitor Meter Domain 439 Each Power Monitor must be a member of a Power Monitor Meter 440 Domain. The Power Monitor Meter Domain should map 1-1 with a 441 metered or sub-metered portion of the site. The Power Monitor 442 Meter Domain must be configured on the Power Monitor Parent. 443 The Power Monitor Children may inherit their domain values from 444 the Power Monitor Parent or the Power Monitor Meter Domain may 445 be configured directly in a Power Monitor Child. 447 5.3. Power Monitor Parent and Child 449 A Power Monitor Child reports its power usage to its Power 450 Monitor Parent. A Power Monitor Child has one and only one 451 Power Monitor Parent. If a Power Monitor had two parents there 452 would be a risk of double-reporting the power usage in the Power 453 Monitor Meter Domain. Therefore, a Power Monitor cannot be both 454 a Power Monitor Parent and a Power Monitor Child at the same 455 time. 457 A Power Monitor Child can be fully dependent on the Power 458 Monitor Parent for its power or independent from the parent 459 (such as a PC connected to a switch). In the dependently 460 powered case, the Power Monitor Parent provides power for the 461 Power Monitor Child (as in the case of Power Over Ethernet 462 devices). In the independently powered case, the Power Monitor 463 Child draws power from another source (typically a wall outlet). 464 Since the Power Monitor Parent is not the source of power 465 supply, the power usage cannot be measured at the Power Monitor 466 Parent. However, an independent Power Monitor Child reports 467 Power Monitor information to the Power Monitor Parent. The 468 Power Monitor Child may listen to the power control settings 469 from a Power Monitor Parent and could react to the control 470 messages. However, note that the communication between the 471 Power Monitor Parent and Power Monitor Child is out of scope for 472 this document. 474 A mechanism, outside of the scope of this document, should be in 475 place to verify the connectivity between the Power Monitor 476 Parent and its Power Monitor Children. If a Power Monitor Child 477 is unavailable, the Power Monitor Parent must follow some rules 478 to determine how long it should wait before removing the Power 479 Monitor Child entry, along with all associated statistics, from 480 its database. In some situations, such as a connected building 481 in which the Power Monitor Children are somewhat static, this 482 removal-delay period may be long, and persistence across a Power 483 Monitor Parent reload may make sense. However, in a networking 484 environment, where endpoints can come and go, there is not much 485 sense in configuring a long removal timer. In all cases, the 486 removal timer or persistence must be clearly specified. 488 Further examples of Power Monitor Parent and Child 489 implementations are provided in the Implementation Scenarios 490 section 11. 492 5.4. Power Monitor Context 494 Monitored power data will ultimately be collected by and 495 reported from an NMS. In order to aid in reporting and in 496 differentiation between Power Monitors, each Power Monitor will 497 contain information establishing its business or site context. 498 A Power Monitor can provide an importance value in the range of 499 1 to 100 to help differentiate a device's use or relative value 500 to the site. The importance range is from 1 (least important) 501 to 100 (most important). The default importance value is 1. 503 For example: A typical office environment has several types of 504 phones, which can be rated according to their business impact. 505 A public desk phone has a lower importance (for example, 10) 506 than a business-critical emergency phone (for example, 100). As 507 another example: A company can consider that a PC and a phone 508 for a customer-service engineer is more important than a PC and 509 a phone for lobby use. 511 Although network managers must establish their own ranking, the 512 following is a broad recommendation: 514 . 90 to 100 Emergency response 515 . 80 to 90 Executive or business-critical 516 . 70 to 79 General or Average 517 . 60 to 69 Staff or support 518 . 40 to 59 Public or guest 519 . 1 to 39 Decorative or hospitality 521 A Power Monitor can provide a set of keywords. These keywords 522 are a list of tags that can be used for grouping and summary 523 reporting within or between Power Monitor Meter Domains. All 524 alphanumeric characters and symbols, such as #, (, $, !, and &, 525 are allowed. Potential examples are: IT, lobby, HumanResources, 526 Accounting, StoreRoom, CustomerSpace, router, phone, floor2, or 527 SoftwareLab. There is no default value for a keyword. 529 Multiple keywords can be assigned to a device. In such cases, 530 the keywords are separated by commas and no spaces between 531 keywords are allowed. For example, "HR,Bldg1,Private". 533 Additionally, a Power Monitor can provide a "role description" 534 string that indicates the purpose the Power Monitor serves in 535 the network or for the site/business. This could be a string 536 describing the context the device fulfills in deployment. For 537 example, a lighting fixture in a kitchen area could have a role 538 of "Hospitality Lighting" to provide context for the use of the 539 device. 541 5.5. Power Monitor Levels 543 Power Levels represent universal states of power management of a 544 Power Monitor. Each Power Level corresponds to a global, 545 system, and performance state in the ACPI model [ACPI]. 547 Level ACPI Global/System Power Level 548 State Name 550 Non-operational states: 552 1 G3, S5 Mech Off 553 2 G2, S5 Soft Off 554 3 G1, S4 Hibernate 555 4 G1, S3 Sleep 556 5 G1, S2 Standby 557 6 G1, S1 Ready 559 Operational states: 560 7 G0, S0, P5 LowMinus 561 8 G0, S0, P4 Low 562 9 G0, S0, P3 MediumMinus 563 10 G0, S0, P2 Medium 564 11 G0, S0, P1 HighMinus 565 12 G0, S0, P0 High 567 Figure 3: ACPI / Power Level Mapping 569 For example, a Power Monitor with a Power Level of 9 would 570 indicate an operational state with MediumMinus Power Level. 572 The Power Levels can be considered as guidelines in order to 573 promote interoperability across device types. Realistically, 574 each specific feature requiring Power Levels will require a 575 complete recommendation of its own. For example, designing IP 576 phones with consistent Power Levels across vendors requires a 577 specification for IP phone design, along with the Power Levels 578 mapping. 580 Manufacturer Power Levels are required in some situations, such 581 as when no mappings with the existing Power Levels are possible, 582 or when more than the twelve specified Power Levels are 583 required. 585 A first example would be an imaginary device type, with only 586 five levels: "none", "short", "tall", "grande", and "venti". 588 Manufacturer Power Level Respective Name 589 0 none 590 1 short 591 2 tall 592 3 grande 593 4 venti 595 Figure 4: Mapping Example 1 597 In the unlikely event that there is no possible mapping between 598 these Manufacturer Power Levels and the proposed Power Monitor 599 Power Levels, the Power Level will remain 0 throughout the MIB 600 module, as displayed below. 602 Power Level / Name Manufacturer Power Level / Name 603 0 / unknown 0 / none 604 0 / unknown 1 / short 605 0 / unknown 2 / tall 606 0 / unknown 3 / grande 607 0 / unknown 4 / venti 609 Figure 5: Mapping Example 2 611 If a mapping between the Manufacturer Power Levels and the Power 612 Monitor Power Levels is achievable, both series of levels must 613 exist in the MIB module in the Power Monitor Parent, allowing 614 the NMS to understand the mapping between them by correlating 615 the Power Level with the Manufacturer Power Levels. 617 Power Level / Name Manufacturer Power Level / Name 618 1 / Mech Off 0 / none 619 2 / Soft Off 0 / none 620 3 / Hibernate 0 / none 621 4 / Sleep, Save-to-RAM 0 / none 622 5 / Standby 0 / none 623 6 / Ready 1 / short 624 7 / LowMinus 1 / short 625 8 / Low 1 / short 626 9 / MediumMinus 2 / tall 627 10 / Medium 2 / tall 628 11 / HighMinus 3 / grande 629 12 / High 4 / venti 631 Figure 6: Mapping Example 3 633 How the Power Monitor Levels are then mapped is an 634 implementation choice. However, it is recommended that the 635 Manufacturer Power Levels map to the lowest applicable Power 636 Levels, so that setting all Power Monitors to a Power Level 637 would be conservative in terms of disabled functionality on the 638 Power Monitor. 640 A second example would be a device type, such as a dimmer or a 641 motor, with a high number of operational levels. For the sake 642 of the example, 100 operational states are assumed. 644 Power Level / Name Manufacturer Power Level / Name 645 1 / Mech Off 0 / off 646 2 / Soft Off 0 / off 647 3 / Hibernate 0 / off 648 4 / Sleep, Save-to-RAM 0 / off 649 5 / Standby 1 / off 650 6 / Ready 2 / off 651 7 / LowMinus 11 / 1% 652 7 / LowMinus 12 / 2% 653 7 / LowMinus 13 / 3% 654 . . 655 . . 656 . . 657 8 / Low 15 / 15% 658 8 / Low 16 / 16% 659 8 / Low 17 / 17% 660 . . 661 . . 662 . . 663 9 / MediumMinus 30 / 30% 664 9 / MediumMinus 31 / 31% 665 9 / MediumMinus 32 / 32% 666 . . 667 . . 668 . . 669 10 / Medium 45 / 45% 670 10 / Medium 46 / 46% 671 10 / Medium 47 / 47% 672 . . 673 . . 674 . . 675 etc... 677 Figure 7: Mapping Example 4 679 As specified in section 6, this architecture allows the 680 configuration of the Power Level, while configuring the 681 Manufacturer Power Level from the MIB directly is not possible. 683 5.6. Power Monitor Usage Measurement 685 The usage or production or power must be qualified as more than 686 a value alone. A measurement should be qualified with the 687 units, magnitude, direction of power flow, and by what means the 688 measurement was made (ex: Root Mean Square versus Nameplate) . 690 In addition, the Power Monitor should describe how it intends to 691 measure usage as one of consumer, producer or meter of usage. 692 Given the intent any readings can be correctly summarized or 693 analyzed by an NMS. For example metered usage reported by a 694 meter and consumption usage reported by a device connected to 695 that meter may naturally measure the same usage. With the two 696 measurements identified by intent a proper summarization can be 697 made by an NMS. 699 The power usage measurement should conform to the IEC 61850 700 definition of unit multiplier for the SI (System International) 701 units of measure. The power usage measurement is considered an 702 instantaneous usage value and does not include the usage over 703 time. 705 Measured values are represented in SI units obtained by 706 BaseValue * 10 raised to the power of the scale. For example, 707 if current power usage of a Power Monitor is 3, it could be 3 W, 708 3 mW, 3 KW, or 3 MW, depending on the value of the scaling 709 factor 711 In addition to knowing the usage and magnitude, it is useful to 712 know how a Power Monitor usage measurement was obtained: 713 . Whether the measurements were made at the device itself or 714 from a remote source. 715 . Description of the method that was used to measure the 716 power and whether this method can distinguish actual or 717 estimated values. 719 An NMS can use this information to account for the accuracy and 720 nature of the reading between different implementations. 722 In addition to the power usage, the nameplate power rating of a 723 Power Monitor is typically specified by the vendor as the 724 capacity required to power the device. Often this label is a 725 conservative number and is the worst-case power draw. While the 726 actual utilization of an entity can be lower, the nameplate 727 power is important for provisioning, capacity planning and 728 billing. 730 5.7. Optional Power Usage Quality 732 Given a power measurement of a Power Monitor, it may in certain 733 circumstances be desirable to know the power quality associated 734 with that measurement. The information model must adhere to the 735 IEC 61850 7-2 standard for describing AC measurements. In some 736 Power Monitor Domains, the power quality may not be needed, 737 available, or relevant to the Power Monitor. 739 5.8. Optional Energy Measurement 741 In addition to reporting the Power Level, an approach to 742 characterizing the energy demand is required. It is well known 743 in commercial electrical utility rates that demand charges can 744 be on par with actual power charges, so it is useful to 745 characterize the demand. The demand can be described as the 746 average energy of an Power Monitor over a time window called a 747 demand interval (typically 15 minutes). The highest peak energy 748 demand measured over a time horizon, such as 1 month or 1 year, 749 is often the basis for usage charges. A single window of time 750 of high usage can penalize the consumer with higher energy 751 consumption charges. However, it is relevant to measure the 752 demand only when there are actual power measurements from a 753 Power Monitor, and not when the power measurement is assumed or 754 predicted. 756 Several efficiency metrics can be derived and tracked with the 757 demand usage data. For example: 759 . Per-packet power costs for a networking device (router or 760 switch) can be calculated by an NMS. The packet count can 761 be determined from the traffic usage in the ifTable 762 [RFC2863], from the forwarding plane figure, or from the 763 platform specifications. 765 . Watt-hour power can be combined with utility energy sources 766 to estimate carbon footprint and other emission statistics. 768 5.9. Optional Battery Information 770 Some Power Monitors may be running on batteries. Therefore 771 information such as the battery status (charging or 772 discharging), remaining capacity, and so on, must be available. 774 6. Power Monitor Children Discovery 776 There are multiple ways that the Power Monitor Parent can 777 discover its Power Monitor Children, if they are not present on 778 the same physical network element: 780 . In case of PoE, the Power Monitor Parent automatically 781 discovers a Power Monitor Child when the Child requests 782 power. 783 . The Power Monitor Parent and Children may run the Link 784 Layer Discovery Protocol [LLDP], or any other discovery 785 protocol, such as Cisco Discovery Protocol (CDP). The 786 Power Monitor Parent might even support the LLDP-MED MIB 787 [LLDP-MED-MIB], which returns extra information on the 788 Power Monitor Children. 789 . The Power Monitor Parent may reside on a network connected 790 facilities gateway. A typical example is a converged 791 building gateway, monitoring several other devices in the 792 building, and serving as a proxy between SNMP and a 793 protocol such as BACNET. 795 When a Power Monitor Child supports only its own Manufacturer 796 Power Levels, the Power Monitor Parent will have to discover 797 those Manufacturer Power Levels. Note that the communication 798 specifications between the Power Monitor Parent and Children is 799 out of the scope of this document. This includes the 800 Manufacturer Power Levels discovery, which is protocol-specific. 802 7. Configuration 804 This power management architecture allows the configuration of 805 the following key parameters: 807 . Power Monitor name: A unique printable name for the Power 808 Monitor. 809 . Power Monitor Role: An administratively assigned name to 810 indicate the purpose a Power Monitor serves in the network. 811 . Power Monitor Importance: A ranking of how important the 812 Power Monitor is, on a scale of 1 to 100, compared with 813 other Power Monitors in the same Power Monitor Meter 814 Domain. 815 . Power Monitor Keywords: A list of keywords that can be used 816 to group Power Monitors for reporting or searching. 817 . Power Monitor Domain: Specifies the name of a Power Monitor 818 Meter Domain for the Power Monitor. 819 . The Power Monitor Level: Specifies the current Power Level 820 (0..12) for the Power Monitor. 821 . The energy demand parameters: For example, which interval 822 length to report the energy on, the number of intervals to 823 keep, etc. 825 When a Power Monitor requires a mapping with the Manufacturer 826 Power Level, the Power Monitor configuration is done via the 827 Power Level settings, and not directly via the Manufacturer 828 Power Levels, which are read-only. Taking into account Figure 829 8, where the LowMinus Power Level corresponds to three different 830 Manufacturer Power Levels (11 for 1%, 12 for 2%, and 13 for 3%), 831 the implication is that this architecture will not set the 832 Manufacturer Power Level to one percent granularity without 833 communicating over or configuring the proprietary protocol for 834 this Power Monitor. 836 This architecture uses a Power Level MIB object to set up the 837 Power Level for a specific Power Monitor. However, the Power 838 Monitor might be busy executing an important task that requires 839 the current Power Level for some more time. For example, a PC 840 might have to finish a backup first, or an IP phone might be 841 busy with a current phone call. Therefore a second MIB object 842 contains the actual Power Level. A difference in values between 843 the two objects indicates that the Power Monitor is currently in 844 Power Level transition. 846 Interactions with established open protocols, such as Wake-up- 847 on-Lan (WoL) and DASH [DASH], may require configuration in the 848 Power Monitor as well, facilitating the communication between 849 Power Monitor Parent and remote Power Monitor Children. 851 Note that the communication specifications between the Power 852 Monitor Parent and Children is out of the scope of this 853 document. This includes communication of power settings and 854 configuration information, such as the Power Monitor Domain. 856 8. Fault Management 858 [POWER-MON-REQ] specifies some requirements about power states 859 such as "the current state - the time of the last change", "the 860 total time spent in each state", "the number of transitions to 861 each state", etc. Such requirements are fulfilled via the 862 pmPowerLevelChange NOTIFICATION-TYPE [POWER-MON-MIB]. This SNMP 863 notification is generated when the value(s) of Power Level has 864 changed for the Power Monitor. 866 9. IPFIX 868 A push-based mechanism, such as IPFIX [RFC5101], might be 869 required to export high-volume time series of energy consumption 870 values, as mentioned in [POWER-MON-REQ]. 872 EDITOR'S NOTE: the Working Group should decide how much of IPFIX 873 should be described in this document 875 10. Relationship with Other Standards Development Organizations 877 10.1. Information Modeling 879 This power management architecture should, as much as possible, 880 reuse existing standards efforts, especially with respect to 881 information modeling and data modeling [RFC3444]. 883 The data model for power, energy related objects is based on IEC 884 61850. 886 Specific examples include: 888 . The scaling factor, which represents Power Monitor usage 889 magnitude, conforms to the IEC 61850 definition of unit 890 multiplier for the SI (System International) units of 891 measure. 893 . The power accuracy model is based on the ANSI and IEC 894 Standards, which require that we use an accuracy class for 895 power measurement. ANSI and IEC define the following 896 accuracy classes for power measurement: 898 . IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. 900 . ANSI C12.20 class 0.2, 0.5 902 . The powerQualityMIB MIB module adheres closely to the IEC 903 61850 7-2 standard for describing AC measurements. 905 10.2. Power Levels 907 There are twelve Power Monitor Levels. They are subdivided into 908 six operational states, and six non-operational states. The 909 lowest non-operational state is 1 and the highest is six. Each 910 non-operational state corresponds to an ACPI level [ACPI]. 912 11. Implementation Scenarios 914 The scope of power and energy monitoring consists of devices 915 that consume power within and that are connected to a 916 communications network. These devices include: 918 - Network devices and sub-components: Devices such as routers 919 and switches and their sub-components. 921 - Network attached endpoints: Devices that use the 922 communications network, such as endpoints, PCs, and facility 923 gateways that proxy energy monitor and control for commercial 924 buildings or home automation. 926 - Network attached meters or supplies: Devices that can monitor 927 the electrical supply, such as smart meters or Universal 928 Power Supplies (UPS) that meter and provide availability. 929 - 930 This section provides illustrative examples that model different 931 scenarios for implementation of the Power Monitor, including 932 Power Monitor Parent and Power Monitor Child relationships. 934 Each of the scenarios below is explained in more detail in the 935 Power Monitor MIB document [POWER-MON-MIB], with a mapping to 936 the MIB Objects. 938 Scenario 1: Switch with PoE endpoints 940 Consider a PoE IP phone connected to a switch. The IP phone 941 draws power from the PoE switch. 943 Scenario 2: Switch with PoE endpoints with further connected 944 device(s) 946 Consider the same example as in Scenario 1, but with a PC daisy- 947 chained from the IP phone for LAN connectivity. The phone draws 948 power from the PoE port of the switch, while the PC draws power 949 from the wall outlet. 951 Scenario 3: A switch with Wireless Access Points 953 Consider a WAP (Wireless Access Point) connected to the PoE port 954 of a switch. There are several PCs connected to the Wireless 955 Access Point over Wireless protocols. All PCs draw power from 956 the wall outlets. 958 The switch port is the Power Monitor Parent for the Wireless 959 Access Point (WAP) and all the PCs. But there is a distinction 960 among the Power Monitor Children, as the WAP draws power from 961 the PoE port of the switch and the PCs draw power from the wall 962 outlet. 964 Scenario 4: Network connected facilities gateway 966 At the top of the network hierarchy of a building network is a 967 gateway device that can perform protocol conversion between many 968 facility management devices, such as BACNET, MODBUS, DALI, LON, 969 etc. There are power meters associated with power-consuming 970 entities (Heating Ventilation & Air Conditioning - HVAC, 971 lighting, electrical, fire control, elevators, etc). The 972 proposed MIB can be implemented on the gateway device. The 973 gateway can be considered as the Power Monitor Parent, while the 974 power meters associated with the energy consuming entities can 975 be considered as its Power Monitor Children. 977 Scenario 5: Data center network 979 A typical data center network consists of a hierarchy of 980 switches. At the bottom of the hierarchy there are servers 981 mounted on a rack, and these are connected to the top-of-the- 982 rack switches. The top switches are connected to aggregation 983 switches that are in turn connected to core switches. As an 984 example, Server 1 and Server 2 are connected to different switch 985 ports of the top switch. 987 The proposed MIB can be implemented on the switches. The switch 988 can be considered as the Power Monitor Parent. The servers can 989 be considered as the Power Monitor Children. 991 Scenario 6: Building gateway device 993 Similar scenario as the scenario 4. 995 Scenario 7: Power consumption of UPS 997 Data centers and commercial buildings can have Uninterruptible 998 Power Supplies (UPS) connected to the network. The Power Monitor 999 can be used to model a UPS as a Power Monitor Parent with the 1000 connected devices as Power Monitor Children. 1002 Scenario 8: Power consumption of battery-based devices 1004 A PC is a typical example of a battery-based device. 1006 12. Security Considerations 1008 Regarding the data attributes specified here, some or all may be 1009 considered sensitive or vulnerable in some network environments. 1010 Reading or writing these attributes without proper protection 1011 such as encryption or access authorization may have negative 1012 effects on the network capabilities. 1014 12.1. Security Considerations for SNMP 1016 Readable objects in a MIB modules (i.e., objects with a MAX- 1017 ACCESS other than not-accessible) may be considered sensitive or 1018 vulnerable in some network environments. It is thus important 1019 to control GET and/or NOTIFY access to these objects and 1020 possibly to encrypt the values of these objects when sending 1021 them over the network via SNMP. 1023 The support for SET operations in a non-secure environment 1024 without proper protection can have a negative effect on network 1025 operations. For example: 1027 . Unauthorized changes to the Power Domain or business 1028 context of a Power Monitor may result in misreporting or 1029 interruption of power. 1030 . Unauthorized changes to a power level may disrupt the power 1031 settings of the different Power Monitors, and therefore the 1032 level of functionality of the respective Power Monitors. 1033 . Unauthorized changes to the demand history may disrupt 1034 proper accounting of energy usage. 1036 With respect to data transport SNMP versions prior to SNMPv3 did 1037 not include adequate security. Even if the network itself is 1038 secure (for example, by using IPsec), there is still no secure 1039 control over who on the secure network is allowed to access and 1040 GET/SET (read/change/create/delete) the objects in these MIB 1041 modules. 1043 It is recommended that implementers consider the security 1044 features as provided by the SNMPv3 framework (see [RFC3410], 1045 section 8), including full support for the SNMPv3 cryptographic 1046 mechanisms (for authentication and privacy). 1048 Further, deployment of SNMP versions prior to SNMPv3 is not 1049 recommended. Instead, it is recommended to deploy SNMPv3 and to 1050 enable cryptographic security. It is then a customer/operator 1051 responsibility to ensure that the SNMP entity giving access to 1052 an instance of these MIB modules is properly configured to give 1053 access to the objects only to those principals (users) that have 1054 legitimate rights to GET or SET (change/create/delete) them. 1056 12.2. Security Considerations for IPFIX 1058 EDITOR'S NOTE: to be completed if IPFIX is discussed in this 1059 document 1061 13. IANA Considerations 1063 This document has no actions for IANA. 1065 14. Acknowledgments 1067 The authors would like to Michael Brown for improving the text 1068 dramatically. 1070 15. References 1072 Normative References 1074 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1075 "Introduction and Applicability Statements for Internet 1076 Standard Management Framework ", RFC 3410, December 1077 2002. 1079 [RFC5101] B. Claise, Ed., Specification of the IP Flow 1080 Information Export (IPFIX) Protocol for the Exchange of 1081 IP Traffic Flow Information, RFC 5101, January 2008. 1083 [POWER-MON-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., 1084 and M. Chandramouli, "Requirements for Power 1085 Monitoring", draft-quittek-power-monitoring- 1086 requirements-01 (work in progress), July 2010. 1088 [POWER-MON-MIB] Claise, B., Chandramouli, M., Parello, J., and 1089 Schoening, B., "Power and Energy Monitoring MIB", 1090 draft-claise-energy-monitoring-mib-06, (work in 1091 progress), October 2010. 1093 Informative References 1095 [RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group 1096 MIB", RFC 2863, June 2000. 1098 [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences 1099 between Information Models and Data Models", RFC 3444, 1100 January 2003. 1102 [ACPI] "Advanced Configuration and Power Interface 1103 Specification", http://www.acpi.info/spec30b.htm 1105 [LLDP] IEEE Std 802.1AB, "Station and Media Control 1106 Connectivity Discovery", 2005. 1108 [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information 1109 Base extension module for TIA-TR41.4 media endpoint 1110 discovery information", July 2005. 1112 [DASH] "Desktop and mobile Architecture for System Hardware", 1113 http://www.dmtf.org/standards/mgmt/dash/ 1115 Authors' Addresses 1117 Benoit Claise 1118 Cisco Systems, Inc. 1119 De Kleetlaan 6a b1 1120 Diegem 1813 1121 BE 1123 Phone: +32 2 704 5622 1124 Email: bclaise@cisco.com 1126 John Parello 1127 Cisco Systems, Inc. 1128 3550 Cisco Way 1129 San Jose, California 95134 1130 US 1131 Phone: +1 408 525 2339 1132 Email: jparello@cisco.com 1134 Brad Schoening 1135 Cisco Systems, Inc. 1136 3550 Cisco Way 1137 San Jose, California 95134 1138 US 1140 Phone: +1 408 525 2339 1141 Email: braschoe@cisco.com