Network Working Group B. Claise Internet-Draft J. Parello Intended Status: Informational B. Schoening Expires: March 17, 2011 Cisco Systems, Inc. September 17, 2010 Power Management Architecture draft-claise-power-management-arch-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September, 2010. Expires March 17 2011 [Page 1] Internet-Draft Sept 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document defines the power management architecture. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Expires March 17, 2011 [Page 2] Internet-Draft Sept 2010 Table of Contents 1. Introduction............................................... 4 2. Uses Cases & Requirements.................................. 5 3. Terminology................................................ 5 4. Architecture High Level Concepts and Scope................. 6 4.1. Power Monitor Information............................. 8 4.2. Power Monitor Meter Domain............................ 8 4.3. Power Monitor Parent and Child........................ 9 4.4. Power Monitor Context................................ 10 4.5. Power Monitor Levels................................. 11 4.6. Power Monitor Usage Measurement...................... 13 4.7. Optional Power Usage Quality......................... 14 4.8. Optional Energy Measurement.......................... 14 4.9. Optional Battery Information......................... 15 5. Power Monitor Children Discovery.......................... 15 6. Configuration............................................. 16 7. Fault Management.......................................... 16 8. Relationship with Other Standard Development Organizations................................................ 17 8.1. Information Modeling................................. 17 8.2. Power Levels......................................... 17 9. Implementation Scenarios.................................. 18 Scenario 1: Switch with PoE endpoints..................... 18 Scenario 2: Switch with PoE endpoints with further connected device(s)................................................. 18 Scenario 3: A switch with Wireless Access Points.......... 18 Scenario 4: Network connected facilities gateway.......... 19 Scenario 5: Data Center Network........................... 19 Scenario 6: Building Gateway Device....................... 19 Scenario 7: Power Consumption of UPS...................... 19 Scenario 8: Power Consumption of Battery-based Devices.... 20 10. Security Considerations.................................. 20 11. IANA Considerations...................................... 20 12. References............................................... 20 Normative References...................................... 20 Informative References.................................... 20 13. Authors' Addresses....................................... 21 TO DO: . Since we have the notion of desired versus actual Power Level, we must deal with the notion of transition state: Expires March 17, 2011 [Page 3] Internet-Draft Sept 2010 Gracefully versus hard way. Note: the transition states are apparently described in the DMTF model. . In terms of other SDOs, discuss DMTF? . Do we need the pmIndex persistence? . Security Considerations to be done 1. Introduction Network management is typically divided into areas of concerns according to the ISO Telecommunications Management Network model. The model defines Fault, Configuration, Accounting, Performance, and Security Management. Notably missing is an area of concern specifically covering energy management at an equal level to these areas. With energy becoming a more critical area of concern, this document defines an architecture for power management for use with devices in and connected to communication networks. This architecture includes monitoring for power state and energy consumption of networked elements, taking into account the requirements specified in [POWER-MON-REQ]. However, this architecture goes one step further, as it includes some elements of elements of configuration. Energy management is applicable to devices that comprise and that are connected to a communication network. Target devices for this specification include (but are not limited to): routers, switches, Power over Ethernet (PoE) endpoints, protocol gateways for building management systems, intelligent meters, home energy gateway, hosts and servers, sensor proxy, etc. Where applicable, monitoring of a device is extended to the individual components of the device and/or to any attached dependent device(s). An example of such a case could be when a device contains components that are independent from a power state point of view (such as line cards, processor cards, hard drives) or when a devices has dependent attached devices (such as a switch with PoE endpoints or a power distribution unit with attached endpoints). Expires March 17, 2011 [Page 4] Internet-Draft Sept 2010 2. Uses Cases & Requirements The requirements for power and energy monitoring for networking devices are specified in [POWER-MON-REQ]. The requirements in [POWER-MON-REQ] cover devices that typically make up a communications network such as switches, routers, and various connected endpoints. For power monitoring to be useful, a specification should also be applicable to facility meters, power distribution units, gateway proxies for commercial building control, home automation devices and devices that interface with the utility and/or smart grid. Due to this fact, the scope of this architecture is broader than that specified in [POWER-MON-REQ]. Several scenarios that cover these broader use cases are presented later in Section 9. - Implementation Scenarios. 3. Terminology This section contains definitions of major terms used in explaining the concepts, examples, and the MIB definitions. Power Monitor A Power Monitor is a system of one or more components that provide power, draws power, or reports energy consumption on behalf of another Power Monitor. It can be independently managed from a power monitoring and power state configuration point of view. Examples of Power Monitors are: a router line card, a motherboard with a CPU, an IP phone connected with a switch, etc. Power Monitor Parent A Power Monitor Parent is a Power Monitor that is the root of one or multiple subtending Power Monitors, called Power Monitor Children. The Power Monitor Parent is able to report the power state and energy consumption for his Power Monitor Child(ren). For example, in case of Power-over-Ethernet (PoE) device such as an IP phone or an access point attached to a switch port, the switch is the source of power for the attached device. In such a case, the Power Monitor Parent is the port of the switch, while the attached device is the Power Monitor Child. Power Monitor Child Expires March 17, 2011 [Page 5] Internet-Draft Sept 2010 A Power Monitor Child is a Power Monitor associated to a Power Monitor Parent, which draws power from its Power Monitor Parent or reports its power usage and power state to its Power Monitor Parent. Power Monitor Meter Domain A Power Monitor Meter Domain is a name or name space that logically groups together Power Monitors that comprises a zone of manageable power usage. Typically, this will comprise all Power Monitors that are powered from the same electrical panel or panels for which there is a meter or sub meter. For example, all Power Monitors receiving power from the same distribution panel of a building, or all Power Monitors in a building for which there is one main meter. From the point of monitoring power use, it is useful to report the total power usage as the sum of power consumed by all the Power Monitors within a Power Monitor Meter Domain and then correlate that value to the metered usage. Power Level A uniform way to classify power settings on a Power Monitor (e.g., shut, hibernate, sleep, high). Power Levels can be viewed as an interface for interacting with the underlying device implemented power settings. Manufacturer Power Level A device specific way to classify power settings implemented on a Power Monitor. For cases where the implemented power setting cannot be directly mapped to a Power Level(s), the Manufacturer Power Levels are used to enumerate and show the relationship between the implemented power settings and the Power Level interface. 4. Architecture High Level Concepts and Scope The scope of this architecture is to enable networking and network attached devices to be managed with respect to their energy consumption or production. The goal is to make devices energy aware. Expires March 17, 2011 [Page 6] Internet-Draft Sept 2010 The architecture describes how to make a device aware of its consumption or production of energy expressed as usage in watts. This does not include: - Manufacturing costs in currency or environmental units - Embedded carbon or environmental equivalences of the device itself - Cost in currency or environmental impact to dismantle or recycle the device - Relationship to an electrical or smart grid - Supply chain analysis - Conversion of the usage or production of energy to units expressed from the source of that energy - for example the greenhouse gas emissions associated with 1000kW from a diesel source. This remainder of this section will go over the basic concepts of the architecture. Each concept is then listed with notable descriptions in subsequent sections. Examples will be provided in a later section to show how these concepts can be fulfilled in an implementation. Given a Power Monitor, we can describe the information about the Power Monitor through various data. A Power Monitor will have basic naming and informational descriptors to identify it in the network. A Power Monitor can be part of a Power Monitor Meter Domain. A Power Monitor Meter Domain is a manageable set of devices that has a meter or sub-meter attached and typically corresponds to a power distribution point or panel. A Power Monitor can be a parent (Power Monitor Parent) or child (Power Monitor Child) of another Power Monitor. This allows for devices to aggregate reporting and/or control of power information. Each Power Monitor can have information to allow it to be described in the context of the business or ultimate use. This is in addition to its networked information. This allows for tagging, grouping and differentiation between Power Monitors for NMS. For control and universal monitoring each Power Monitor will implement or declare a set of known Power Levels. The Power Levels can be mapped to Manufacturer Power Levels that indicate the specific power setting for the device implementing the Power Expires March 17, 2011 [Page 7] Internet-Draft Sept 2010 Monitor, in case that Power Monitor doesn't implement yet the standard Power Levels [POWER-MON-MIB]. The desired Power Level variable is set, when setting the Power Level. If the Power Monitor is busy at the request time, it might update the actual Power Level when his priority task is finished. This mechanism implies two different Power Level variables: actual versus desired. EDITOR'S NOTE: the transition state will have to be specified. Each Power Monitor will have usage information that describes the power information along with how that usage was obtained or derived. Optionally a Power Monitor can further describe the power information with power quality information reflecting the electrical characteristics of the measurement. Optionally a Power Monitor can provide power usage over time to describe energy consumption If a Power Monitor has one or more batteries, it can provide optional Battery information as well. 4.1. Power Monitor Information Every Power Monitor SHOULD have a unique printable name, and MUST have a unique Power Monitor index. Possible naming conventions are: textual DNS name, MAC-address of the device, interface ifName, or a text string uniquely identifying the Power Monitor. As an example, in the case of IP phones, the Power Monitor name can be the device DNS name. 4.2. Power Monitor Meter Domain Each Power Monitor MUST be a member of a Power Monitor Meter Domain. The Power Monitor Meter Domain SHOULD map 1-1 with a metered or sub-metered portion of the site. The Power Monitor Meter Domain MUST be configured on the Power Monitor Parent. The Power Monitor Children MAY inherit its domain value from the Power Monitor Parent or the Power Monitor Meter Domain MAY be configured directly in Power Monitor Child. Expires March 17, 2011 [Page 8] Internet-Draft Sept 2010 4.3. Power Monitor Parent and Child A Power Monitor can be connected to another Power Monitor and either draw power from that entity or report power usage to that entity. A Power Monitor Child can be fully dependent on the Power Monitor Parent (as in the case of Power Over Ethernet) or independent from the parent (such as a PC connected to a switch). In the dependent case, the Power Monitor Parent provides power for the Power Monitor Child (the PoE case). In the independent case, the Power Monitor Child draws power from another source (typically a wall outlet). Since the Power Monitor Parent is not the source of power supply, the power usage cannot be measured at the Power Monitor Parent. However, an independent Power Monitor Child may report Power Monitor information to the Power Monitor Parent. The Power Monitor Child may listen to the power control settings from a Power Monitor Parent and could react to the control messages. Note that the communication between the Power Monitor Parent and Power Monitor Child is out of scope of this document. A Power Monitor cannot be at the same time a Power Monitor Parent and a Power Monitor Child. Indeed such configuration would lead to double counting the energy consumed within a specific Power Monitor Domain. A mechanism, outside of the scope of this document, should be in place to verify the connectivity between the Power Monitor Parent and its Power Monitor Children. If the Power Monitor Child is unavailable, the Power Monitor Parent must follow some rules to determine how long it should wait before removing the Power Monitor Child entry, along with all associated statistics, from his database. In some situations, such as connected building, in which the Power Monitor Children are pretty static, this removal timer might be pretty long. The persistence across a Power Monitor Parent reload could even make sense. However, in a networking environment, where endpoints could come and go, there is not much sense to configure a long removal timer. In all cases, the removal timer or persistence must be clearly specified. Further examples of Power Monitor Parent and Child implementations are provided in the Implementation Scenarios section. Expires March 17, 2011 [Page 9] Internet-Draft Sept 2010 4.4. Power Monitor Context Monitored power will ultimately be collected to and reported from a NMS. In order to aid in the reporting and differentiation between Power Monitors, each Power Monitor will contain information to establish a business or site context. A Power Monitor can provide an importance value in the range of 1..100 to help differentiate the use or relative value to the site. The importance range is from 1 (least important) to 100 (most important). The default importance value is 1. For example, a typical office environment has several types of phones, which can be rated according to the business impact: a public desk phone has a lower importance (for example, 10) than a business-critical emergency phone (for example, 100). As another example, a company can consider that a PC and a phone for a customer-service engineer is more important than a PC and a phone for lobby use. Although network managers must establish their own ranking the following is a broad recommendation: . 90 to 100 Emergency response . 80 to 90 Executive or business critical . 70 to 79 General or Average . 60 to 69 Staff or support . 40 to 59 Public or guest . 1 to 39 Decorative or hospitality A Power Monitor can provide a set of keywords. These keywords are a list of tags that can be used for grouping and summary reporting within or between Power Monitor Meter Domains. All alphanumeric characters and symbols such as #, (, $, !, and & are allowed. Potential examples are: IT, lobby, HumanResources, Accounting, StoreRoom, CustomerSpace, router, phone, floor2, or SoftwareLab. There is no default value for the keyword. Multiple keywords can be assigned to a device. In such cases, the keywords are separated by commas and no spaces between keywords are allowed. For example, "HR,Bldg1,Private". Additionally, a Power Monitor can provide a "role description" string that indicates the purpose the Power Monitor serves in the network or to site/business. This could be a string describing the context the device fulfils in deployment. For example, a lighting fixture in a kitchen area could have a role of "Hospitality Lighting" to provide context for the use of the device. Expires March 17, 2011 [Page 10] Internet-Draft Sept 2010 4.5. Power Monitor Levels Power Levels represent universal states of power management of a Power Monitor. Each Power Level corresponds to a global, system, and performance state in the ACPI model. Level ACPI Global/System Name State Non-operational states: 1 G3, S5 Mech Off 2 G2, S5 Soft Off 3 G1, S4 Hibernate 4 G1, S3 Sleep 5 G1, S2 Standby 6 G1, S1 Ready Operational states: 7 G0, S0, P5 LowMinus 8 G0, S0, P4 Low 9 G0, S0, P3 MediumMinus 10 G0, S0, P2 Medium 11 G0, S0, P1 HighMinus 12 G0, S0, P0 High For example, a Power Monitor with a Power Level of 9 would indicate an operational state with MediumMinus Power Level. The Power Levels can be considered as guidelines for an interface in order to promote interoperability across device types. Realistically, it is foreseen that each specific feature requiring Power Levels will require a complete recommendation of its own. For example, designing IP phones with consistent Power Levels across vendors requires a specification for IP phone design, along with the Power Levels mapping. In some situation, Manufacturer Power Levels are required, for example, when no mappings with the existing Power Levels are possible or when more levels than the twelve specified Power Levels are required. A first example would be an imaginary device type, with only five levels: "none", "short", "tall", "grande", and "venti". Manufacturer Power Level Respective Name 0 none Expires March 17, 2011 [Page 11] Internet-Draft Sept 2010 1 short 2 tall 3 grande 4 venti In the unlikely event of no possible mapping between these Manufacturer Power Levels and the Power Levels, the Power Level will remain 0 throughout the MIB module, as displayed below. Power Level / Name Manufacturer Power Level / Name 0 / unknown 0 / none 0 / unknown 1 / short 0 / unknown 2 / tall 0 / unknown 3 / grande 0 / unknown 4 / venti If a mapping between the Manufacturer Power Levels and the Power Levels is achievable, both series of levels exist in the MIB module, allowing the NMS to understand the mapping between them by correlating the Power Level with the Manufacturer Power Levels. Power Level / Name Manufacturer Power Level / Name 1 / Mech Off 0 / none 2 / Soft Off 0 / none 3 / Hibernate 0 / none 4 / Sleep, Save-to-RAM 0 / none 5 / Standby 0 / none 6 / Ready 1 / short 7 / LowMinus 1 / short 8 / Low 1 / short 9 / MediumMinus 2 / tall 10 / Medium 2 / tall 11 / HighMinus 3 / grande 12 / High 4 / venti How the Power Monitor Levels are then mapped, i.e. assigning the directly lower or directly higher level, is an implementation choice. However, its recommended that the Manufacturer Power Levels l maps to the directly lower Power Level, so that setting all Power Meters to a Power Level would be conservative in terms of disabled functionality on the Power Monitor implementing the Manufacturer Power Levels. A second example would be a device type, such as a dimmer or a motor, with a high number of operational levels. For the sake of the example, 100 operational states are assumed. Expires March 17, 2011 [Page 12] Internet-Draft Sept 2010 Power Level / Name Manufacturer Power Level / Name 1 / Mech Off 0 / off 2 / Soft Off 0 / off 3 / Hibernate 0 / off 4 / Sleep, Save-to-RAM 0 / off 5 / Standby 0 / off 6 / Ready 0 / off 7 / LowMinus 1 / 1% 7 / LowMinus 2 / 2% 7 / LowMinus 3 / 3% . . . . . . 8 / Low 15 / 15% 8 / Low 16 / 16% 8 / Low 17 / 17% . . . . . . 9 / MediumMinus 30 / 30% 9 / MediumMinus 31 / 31% 9 / MediumMinus 32 / 32% . . . . . . 10 / Medium 45 / 45% 10 / Medium 46 / 46% 10 / Medium 47 / 47% . . . . . . etc... 4.6. Power Monitor Usage Measurement For a Power Monitor, RMS (Root Mean Square) or RMS equivalent (for example, after conversion to DC power) power usage must be reported, including the magnitude of measurement, as multiple scaling factors can be used. The power usage measurement should conform to the IEC 61850 definition of unit multiplier for the SI (System International) units of measure. The power usage measurement is considered an instantaneous usage value and does not include the usage over time. Measured values are represented in SI units obtained by BaseValue * 10 raised to the power of scale. For example, if current power usage of a Power Monitor is 3, it could be 3 W, 3 Expires March 17, 2011 [Page 13] Internet-Draft Sept 2010 mW, 3 KW, 3 MW depending on the value of scaling factor (called pmPowerUnitMultiplier in the MIB module). In addition to knowing the usage and magnitude it is useful to know how a Power Monitor usage measurement was obtained: . whether the measurements were made at the device itself or from a remote source . Description of the method that was used to measure the power and can distinguish actual or estimated values. An NMS can use this information to account for the accuracy and nature of the reading between different implementations. In addition to the power usage the nameplate power rating of a Power Monitor is typically specified by the vendor as the capacity required to power the device. Often this label is a conservative number and is the worst-case power draw. While the actual utilization of an entity can be lower, the nameplate power is important for provisioning, capacity planning and billing. 4.7. Optional Power Usage Quality Given a power measurement of a Power Monitor, it may in certain circumstances be desirable to know the power quality associated with that measurement. The information model must adhere to the IEC 61850 7-2 standard to describe AC measurements. In some Power Monitor Domains, the power quality may not be needed, available, nor relevant to the Power Monitor. 4.8. Optional Energy Measurement In addition to reporting the Power Level, an approach to characterize the energy demand is required. It is well known in commercial electrical utility rates, that demand charges can be on par with actual power charges. So, it is useful to characterize the demand. The demand can be described as the average energy of an Power Monitor over a time window, called a demand interval, typically 15 minutes. The highest peak energy demand measured over a time horizon, say 1 month or 1 year is often the basis for usage charges. A single window of time of high usage can penalize the energy consumption charges. However, it is relevant to measure the demand only when there are actual power measurements from a Power Monitor, and not when the power measurement is assumed or predicted. Expires March 17, 2011 [Page 14] Internet-Draft Sept 2010 Several efficiency metrics can be derived and tracked with the demand usage data. . For example, per-packet power costs for a networking device (router or switch) can be calculated by an network management system. The packets count can be determined from the traffic usage in the ifTable [RFC2863] from the forwarding plane figure, or from the platform specifications. . Watt-hour power can be combined with utility energy sources to estimate carbon footprint and other emission statistics. 4.9. Optional Battery Information Some Power Monitors might be running on batteries. Therefore information such as the battery status (charging or discharging), remaining capacity, etc... must be available. 5. Power Monitor Children Discovery There are multiple ways that the Power Monitor Parent can discover its Power Monitor Children, if not present on the same physical network element. . In case of PoE, the Power Monitor Parent automatically discovers that a Power Monitor Child requests some power. . The Power Monitor Parent and Children may run the Link Layer Discovery Protocol [LLDP], or any proprietary similar protocols such as Cisco Discovery Protocol (CDP). The Power Monitor Parent might even support the LLDP-MED MIB [LLDP-MED-MIB], which returns some extra information on the Power Monitor Children. . The Power Monitor Parent might reside on a network connected facilities gateway. A typical example is a converged building gateway, monitoring several other devices in the building, doing the proxy between SNMP and a protocol such as BACNET. When a Power Monitor Child doesn't support the Power Levels, but its own Manufacturer Power Levels, the Power Monitor Parent will have to discover those Manufacturer Power Levels. Note that the communication specifications between the Power Monitor Parent and Children is out of the scope of this document. This includes the Manufacturer Power Levels discovery, which is protocol-specific. Expires March 17, 2011 [Page 15] Internet-Draft Sept 2010 6. Configuration This power management architecture allows the configuration of a couple of key parameters: . Power Monitor name: an unique printable name for the Power Monitor. . Power Monitor Role: an administratively assigned name to indicate the purpose a Power Monitor serves in the network. . Power Monitor Importance: a ranking of how important the Power Monitor is on a scale of 1 to 100 compared to other Power Monitors in the same Power Monitor Meter Domain. . Power Monitor Keywords: a list of keywords that can be used to group Power Monitors for reporting or searching. . Power Monitor Domain: specifies the name of a Power Monitor Meter Domain for the Power Monitor. . The Power Monitor Level: specifies the current Power Level (0..12) for the Power Monitor. . Manufacturer Power Level and name . The energy demand parameters: for example, which interval length to report the energy on, the number of interval to keep, etc... Interactions with established open protocols such as Wake-up-on- Lan (WoL) and DASH [DASH] may require configuration in the Power Monitor as well, facilitating the communication between Power Monitor Parent and remote Power Monitor Children. Note that the communication specifications between the Power Monitor Parent and Children is out of the scope of this document. This includes the communication of the power settings and configuration information such as the Power Monitor Domain. 7. Fault Management [POWER-MON-REQ] specifies some requirements about power states such as "the current state - the time of the last change", "the total time spent in each state", "the number of transitions to each state", etc... Such requirements are fulfilled via the pmPowerLevelChange NOTIFICATION-TYPE [POWER-MON-MIB]. This SNMP notification is generated when the value(s) of Power Level has changed for the Power Monitor. Expires March 17, 2011 [Page 16] Internet-Draft Sept 2010 A push based mechanism such as IPFIX might be required to export high volume time series of energy consumption values, as mentioned in [POWER-MON-REQ]. 8. Relationship with Other Standard Development Organizations 8.1. Information Modeling This power management architecture should reuse as much as possible existing standard efforts and not re-invent something new, specifically in terms of information modeling and data modeling [RFC3444]. The data model for power, energy related objects is based on the IEC 61850. Specific examples include: . The scaling factor, which represent the magnitude of Power Monitor usage, conforms to the IEC 61850 definition of unit multiplier for the SI (System International) units of measure. . The power accuracy model is based on the ANSI and IEC Standards, which require that we use an accuracy class for power measurement. ANSI and IEC define the following accuracy classes for power measurement: . IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. . ANSI C12.20 class 0.2, 0.5 . The powerQualityMIB MIB module adheres closely to the IEC 61850 7-2 standard to describe AC measurements. 8.2. Power Levels There are twelve Power Monitor Levels; divided into six operational states, and six non-operational states. The lowest non-operational state is 1 and the highest is six. Each non- operational state corresponds to an ACPI level [ACPI]. Expires March 17, 2011 [Page 17] Internet-Draft Sept 2010 9. Implementation Scenarios The scope of power and energy monitoring consists of devices that consume power within and connected to a communications network. These devices include: - Network devices and sub-components: devices such as routers and switches and their sub-components. - Network attached endpoints: devices that use the communications network such as endpoints, PCs, or facility gateways that proxy energy monitor and control for commercial buildings or home automation, - Network attached meters or supplies: devices that can monitor the electrical supply such as smart meters or Universal Power Supplies (UPS) that meter and provide availability. This section provides illustrative examples that model different scenarios for implementation of the Power Monitor including Power Monitor Parent and Power Monitor Child relationships. Each of the scenarios below is explained in more details in the Power Monitor MIB document [POWER-MON-MIB], with a mapping to the MIB Objects. Scenario 1: Switch with PoE endpoints Consider a PoE IP phone connected to a switch, as displayed on figure 1. The IP phone draws power from the PoE switch. Scenario 2: Switch with PoE endpoints with further connected device(s) Consider the same scenario as example 1 with an IP phone connected to PoE port of a switch. Now, in addition, a PC is also daisy-chained from the IP phone for LAN connectivity. The phone draws power from PoE port of the switch, while the PC draws power from the wall outlet. Scenario 3: A switch with Wireless Access Points Consider a Wireless Access Point connected to the PoE port of a switch. There are several PCs connected to the Wireless Access Point over Wireless protocols. All PCs draw power from the wall outlets. Expires March 17, 2011 [Page 18] Internet-Draft Sept 2010 The switch port is the Power Monitor Parent for the Wireless Access Point (WAP) and the PCs. There is a distinction, between the Power Monitor Children, as the WAP draws power from the PoE port of the switch and the PCs draw power from the wall outlet. Scenario 4: Network connected facilities gateway At the top of the network hierarchy of a building network is a gateway device that can perform protocol conversion between many facility management devices, such as BACNET, MODBUS, DALI, LON, etc. There are power meters associated with power consuming entities (Heating Ventilation & Air Conditioning - HVAC, lighting, electrical, fire control, elevators, etc). The proposed MIB can be implemented on the gateway device. The gateway can be considered as the Power Monitor Parent, while the power meters associated with the energy consuming entities such can be considered as Power Monitor Children. Scenario 5: Data Center Network A typical data center network consists of a hierarchy of switches. At the bottom of hierarchy there are servers mounted on a rack, and those are connected to the top of the rack switches. The top switches are connected to aggregation switches that are in turn connected to core switches. As an example, Server 1 and Server 2 are connected to different switch ports of the top switch. The proposed MIB can be implemented on the switches. The switch can be considered as the Power Monitor Parent. The servers can be considered as the Power Monitor Children. Scenario 6: Building Gateway Device Similar scenario as the scenario 4. Scenario 7: Power Consumption of UPS Data centers and commercial buildings can have Uninterruptible Power Supplies (UPS) connected to the network. The Power Monitor can be used to model a UPS as a Power Monitor Parent with the connected devices as Power Monitor Children. Expires March 17, 2011 [Page 19] Internet-Draft Sept 2010 Scenario 8: Power Consumption of Battery-based Devices A PC is typical example of a battery-based device. 10. Security Considerations TO DO 11. IANA Considerations This document has no actions for IANA. 12. References Normative References [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. [POWER-MON-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. Chandramouli, "Requirements for Power Monitoring", draft-quittek-power-monitoring- requirements-01 (work in progress), July 2010. [POWER-MON-MIB] Claise, B., Chandramouli, M., Parello, J., and Schoening, B., "Power and Energy Monitoring MIB", draft-claise-energy-monitoring-mib-04, (work in progress), Sept 2010. Informative References [RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences between Information Models and Data Models", RFC 3444, January 2003. [ACPI] "Advanced Configuration and Power Interface Specification", http://www.acpi.info/spec30b.htm Expires March 17, 2011 [Page 20] Internet-Draft Sept 2010 [LLDP] IEEE Std 802.1AB, "Station and Media Control Connectivity Discovery", 2005. [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information Base extension module for TIA-TR41.4 media endpoint discovery information", July 2005. [DASH] "Desktop and mobile Architecture for System Hardware", http://www.dmtf.org/standards/mgmt/dash/ 13. Authors' Addresses Benoit Claise Cisco Systems Inc. De Kleetlaan 6a b1 Diegem 1813 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com John Parello Cisco Systems Inc. 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: jparello@cisco.com Brad Schoening Cisco Systems Inc. 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: braschoe@cisco.com Expires March 17, 2011 [Page 21]