Power Management for Network Devices
November 16, 1998
Microsoft® Windows® 98 and Windows 2000 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 network driver interface specification (NDIS) 5.0 power management and wake up (Wake-on-LAN) under Windows 98 and Windows 2000.
Power management for network media involves putting the system to sleep (suspend) and setting the networking devices to lower power states or off when the network is not in use, 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 www.microsoft.com/hwdev/onnow/default.htm, 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
Current PC System Design Guide guidelines 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:
For devices on PCI, USB, IEEE 1394, and PC Card buses, the device must support the standard hardware interfaces (as specified for each bus) to enable device power management, including setting the Dx states and signaling wake-up events.
For the devices on ISA and other buses, there are no standard interfaces for power management, so the driver must implement the support for different power states and proprietary means might need to be used to enable signaling of the wake-up events.
PCI-based network adapters must support the generation of a power management event (PME # assertion) from the D3 cold-device state, provided that the physical layer technology is generally capable of operating under the voltage and current constraints of the D3 cold device state.
In Windows 2000, CardBus adapters will be supported only on ACPI-based systems. Microsoft is considering adding the CardBus support for non-ACPI systems in future Windows 2000 service packs.
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 2000 DDK, located at www.microsoft.com/ddk/default.htm.
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 into 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 an 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 2000 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 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. PC 99 System Design Guide requires support for Wake-on-LAN specifically in the case of the following network communications devices and their associated NDIS 5.0 miniport drivers:
Ethernet and Token Ring network adapters.
Integrated DOCSIS cable modems.
Other devices that transfer 802.3/DIX Ethernet framed packets.
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 Specification defines three methods of causing wake-up events:
Detection of a change in the network link state.
Receipt of a network wake-up frame.
Receipt of a Magic Packet.
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 2000 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, 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 property 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:
GUID_POWER_DEVICE_WAKE_ENABLE (corresponds to the first check box in figure 1) turns wake-up capabilities on the device on or off.
GUID_POWER_DEVICE_ENABLE (corresponds to the second check box in figure 1) can be used to enable and disable power management for the device.
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:
NetBIOS broadcast queries
Hardware address resolution
These frame types are required to support NetBIOS connections in three different TCP/IP environments: IPv4, IPv6 without Windows Internet Name Server (WINS), and IPv6 with WINS.
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 multihomed 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 run time, the protocol sets the wake-up policy using OIDs. These are, for example, Enable Wakeup, Set Packet Pattern, and Remove 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:
Directed Layer Two packet.
Address resolution protocol (ARP) broadcast for station IP address (frames with DIX header).
NetBIOS over TCP/IP broadcast for station's assigned computername (frames with DIX header).
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. 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 2000 DDK.
The system can wake up in two ways: through 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 be 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 must 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 the system back to sleep again.
Power Management Under Windows 98
For NDIS devices such as network adapters, the power management support is based on the same core technology in Windows 2000 and Windows 98. However, this work was not completed in time for the initial Windows 98 release. This lack of support, combined with the lack of ACPI-enabled hardware required for timely testing of the new suspend/resume and network wake-up capabilities, meant that Windows 98 continued to use the existing suspend/resume code as in Windows 95.
This also means that a network adapter should continue to work on Windows 98 if the network adapter and its driver already pass Microsoft HCT Version 8.0 testing or later requirements and if the device properly supports the NDIS start/stop functions. This capability can be tested by suspending and then resuming the system, after which the network should be fully functional.
Microsoft is planning to include the Wake-on-LAN capability in the first service pack release for Windows 98. The Wake-on-LAN functionality in the Windows 98 service pack and the default settings may differ from the implementation in Windows 2000.
Call to action for NDIS Power Management
Implement NDIS 5.0 power management for network adapter drivers.
For implementation information about NDIS power management and other features, see the Windows 2000 DDK, available from www.microsoft.com/ddk/default.htm. See also the related white papers available from the Web site at www.microsoft.com/hwdev/network/default.htm.