Power Management for Network Devices
Updated: December 4, 2001
The Microsoft Windows family of operating systems support OnNow power management policies and interfaces for drivers so that device designers and driver writers can create OnNow-enabled devices. The OnNow design initiative supports creating PCs that appear to be off when not in use, but that respond immediately to user or other system requests.
This article discusses power management for network media, including NDIS 5.0 power management and wake up (Wake-on-LAN) under Windows.
On This Page
NDIS Power Management
NDIS Power Management
Power management for network media involves putting the system to sleep (suspend) and turning the networking devices to lower power states, or to off, when the network is not in use, and then waking up the system (resume) based on user intervention or network traffic directed to the system from the network. In addition to power management features in the networking hardware, support for power management is needed in NDIS and the overlying networking components in the operating system, including the applications.
The implementation of NDIS power management is based on the Network Device Class Power Management Reference Specification, available at http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/NetPMSPC.rtf, which defines the behavior of network devices as it relates to power management and, specifically, to the four device power states defined for the OnNow architecture.
NDIS power management and the Network Device Class Power Management Specification currently apply specifically to Ethernet and Token Ring adapters. It is intended that network device vendors and system makers will be able to design consistently power-manageable products, and that operating system vendors will be able to implement appropriate network-device power management policies based on the contents of the Network Device Class Power Management Reference Specification.
Power Management Support in the Hardware
Default Device Class Power Management Specification, Version 1.0Current PC System Design Guide require all drivers and devices to support D0 and D3 power states, consistent with the definitions in the relevant device class power management reference specification and the Default Device Class Power Management Specification, Version 1.0 or later. Support of D1 and D2 states is optional unless stated as required in the relevant device class specification. The following summarizes support for each bus class:
NDIS 5.0 and Power Management
NDIS 5.0 extends previous versions of NDIS, so the basic requirements, services, terminology, and architecture of these earlier versions also apply to NDIS 5.0. One of the new features not included in the previous versions of NDIS is network power management. Consequently, in most cases, the NDIS miniport drivers have to be modified to support network power management. NDIS power management implementation is defined and discussed in detail in the Windows DDK.
NDIS can power down network adapters when the system requests a power level change. The request can be initiated either by the user or the system. For example, the user might want to put the system in sleep mode, or the system might request this based on the keyboard or mouse inactivity. If supported by the network adapter, a power down request to a network device can be also caused by disconnecting the network cable. In such a case, the system would wait for a configurable time period before powering down the network adapter--the disconnect might be result of temporary wiring changes on the network, and not necessarily a result of the cable disconnecting from the network device itself.
NDIS power management policy is "No Net Activity" based. This means all overlying network components must agree to the request before the network adapter can be powered down. If there are any active sessions or open files over the network, the power down request can be refused by any or all of the components involved.
Legacy miniport drivers must have properly implemented HaltHandlers and must support dynamic load and unload. This enables limited power management capabilities with legacy miniport drivers and network adapters. The network adapter (by way of the appropriate entry points in its driver) must be capable of being stopped and restarted as many times as necessary without any side effects such as leaving the hardware in undetermined state, leaving resources still allocated, and so on. Therefore, systems having network adapters with no Wake-on-LAN capabilities and with legacy miniport drivers can still be suspended and resumed based on the user activity, but not resumed based on directed network traffic.
Note: Network adapters with full MAC drivers cannot be suspended. Although full MAC drivers can still run on the Windows operating system, many of the newer features such as power management and Wake-on-LAN support are not supported for full MAC drivers, and the Windows DDK no longer documents development of full MAC drivers. This means that systems that have network adapters with full MAC drivers will not be able to go to sleep. Also note that operating system support for full MAC drivers will be removed completely in a future releases of Windows.
Network Wake-up Events
A network wake-up event is a request from hardware or software, external to the network, to put the system into fully powered state (S0, working) from a lower power state. The Windows Logo Program requires support for Wake-on-LAN specifically in the case of the following network communications devices and their associated NDIS 5.0 miniport drivers:
The Network Device Class Power Management Reference Specification does not yet define wake-up mechanisms for ISDN adapters or any network communications adapter that uses ATM signaling. The NDIS architecture itself does not preclude connection-oriented media types, such as ISDN or ATM, from supporting wake-up events. The problem with these media types is that, typically, the signaling stack for the media is running on the host computer as part of the NDIS miniport driver or as a separate NDIS call manager miniport driver. The signaling stack needs to be running and talking to the switch in the network; otherwise, the switch is not aware of the existence of the node. This means the system cannot be put into the sleep state while the connection is up, even if it is idle, with no data being sent over the connection.
The Network Device Class Power Management Reference Specificationdefines three methods of causing wake-up events:
Other methods can also be defined and implemented by the manufacturers.
NDIS 5.0 supports all the three wake-up methods described in the Network Device Class Power Management Reference Specification. (For implementation details, see the Windows DDK.) In addition to support in NDIS, the network adapter, and the miniport supporting Wake-on-LAN, there must be another component (or components) in the system--usually a protocol stack, a driver, or an application--that enables the wake-up methods to be used.
To enable the system to wake up transparently in typical networking scenarios, such as peer-to-peer networking, personal web servers, and other networking applications, the system must be able to wake up from a lower power state based on network events specified by the local networking software. This capability yields the result that any standard Windows network access, such as connections to shared folders and Windows Sockets (WinSock) connections, plus service and management applications, can wake the system from lower power states transparently.
This is achieved if the network adapter and its associated NDIS 5.0 miniport drivers support wake-up on receipt of a network wake-up frame, (method #2), which is a requirement for network adapters in PC 99 System Design Guide. Support for wake-up on detection of a change in the network link state (method #1), or on receipt of a Magic Packet event (method #3), is optional.
By default, none of the three wake-up methods are enabled (turned on) in Windows 2000 and later versions, even if the network adapter supports all three wake-up methods. Wake-on-LAN can be enabled by the end user in the Device Manager properties page for the network adapter, or programmatically using the WMI calls. The following two globally unique identifiers (GUIDs) that can be used for this purpose correspond to settings in the Device Manager property page:
The buffer of WMI request will contain TRUE or FALSE to turn these features on or off. Every time these values are changed, they will be recorded in the registry, so that they are preserved from session to session. More granular settings can be enabled by implementing vendor-specific property pages for the device.
Figure 1. Property page for NIC power management in the Device Manager (subject to change)
Packet Patterns Define the Wake-up Frames
The minimum sets for wake-up patterns are defined in the Network Device Class Power Management Reference Specification as follows:
These frame types are required to support NetBIOS connections in three different TCP/IP environments: IPv4, IPv6 without Windows Internet Name Server (WINS) server, and IPv6 with WINS server.
At driver initialization, NDIS queries the capabilities of the miniport and the network adapter--such as support for Magic Packet, pattern match, or link change wake-ups--and what the lowest required power states are for each wake-up method.
To enable Wake-on-LAN capability for these basic networking scenarios, the network adapter must be capable of storing information describing a minimum of three wake-up packet patterns, and it must be able to recognize wake-up packets based on pattern matches anywhere in the first 128 bytes of the packet. It is recommended that network adapters be capable of storing information describing at least five wake-up packet patterns, enabling more advanced applications such as Wake-on-LAN capability on multi-homed systems and on receipt of multicast packets, in addition to the basic scenarios.
The packet patterns that define the wake-up frames are provided to the NDIS 5.0 miniport driver by the operating system. At runtime, the protocol sets the wake-up policy using OIDs. These are, for example, Enable WakeupSet Packet PatternRemove Packet Pattern. Currently, the Microsoft TCP/IP is the only Microsoft protocol stack that supports network power management. It will register the following packet patterns at miniport initialization:
In the network environments where different frame types may be used concurrently (frames with DIX or SNAP headers), storing the information describing only the basic three wake-up packet patterns on the network adapter might not be sufficient to cover the basic scenarios; instead, a minimum of five packet patterns is needed. For future releases of Windows, Microsoft is considering an implementation in the Microsoft TCP/IP stack to register more than these three packet patterns to cover the basic scenarios in such mixed environments.
During the operation, the system calls NDIS for Power Down Queries and Power Down Sets for each network adapter. NDIS then calls the miniport drivers and the overlying network components to complete the requests. Before doing so, NDIS checks with miniport drivers to ensure that power levels for wake-ups are correct and that the network adapters can be powered down. When a wake-up occurs, for example, the network adapter initiates power-up when a wake-up packet arrives, the system calls NDIS for each network adapter. NDIS forwards the power-up request to each miniport driver and the overlying network components.
Only valid packets can be wake-up packets, for example, filtered packets must pass all normal received-packet checks. For example, RUNTS, short packets, fragments, and so on, should not be considered as potential wake-up packets. Implementation details are described in the Network Wake-up Frames and Network Wake-up Frame Details sections of Network Device Class Power Management Reference Specification; see also the Windows DDK.
The system can wake up in two ways: from a user event or a hardware event. The operating system needs to know which type of event is requesting wake up; the ACPI wake-up mechanism provides this information. For example, if the PCI bus's PME signal is asserted, the operating system knows this is a hardware event and assumes the user is not present. Some of the devices in the system might not get notified about the wake-up event immediately and be turned on until the device is requested by other components in the system. Applications receive a RESUMEAUTOMATIC notification, so the applications that enabled the wake up can take an action, but all other applications don't do anything.
Therefore, when PME is asserted, the PCI bus driver checks the PCI bus to determine which device on the bus caused the event. In this case, it is the network adapter, so the network adapter driver (through NDIS) receives notification that the system is waking up on its behalf; NDIS then has to handle the event. The first thing it does is turn its device to D0 state. Notice that there can be no I/O on the device, and the device cannot generate any interrupts unless it is in D0 state.
Once the device is in the D0 state, the miniport handles the event as it normally would, responding to an interrupt if one is generated. The enabling application must call the OnNow APIs to keep the system awake as long as it is needed; otherwise, the operating system will put it back to sleep again.
Call to action for NDIS power management: