Network Device Class

Version 2.0 October 12, 2000

On This Page

	Disclaimer
	Scope
	General Device Power Management Considerations
	Network Device Power State Definitions
	Network Device Power Conservation Policy
	Minimum Power Capabilities
	Network Wake-up Events
	Operating System Considerations
	Exact vs. Signature Matching
	Appendix A: Example Wake-up Frames

Disclaimer

Note: Revisions in Version 2.0 incorporate changes in power state definitions to match Appendix A of Advanced Configuration and Power Interface Specification (ACPI) Revision 2.0.

Microsoft and Advanced Micro Devices, Inc. (AMD) do not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. Microsoft and AMD disclaim all express and implied warranties, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. Microsoft and AMD shall not be liable for any damages arising out of or in connection with the use of these specifications, including liability for lost profit, business interruption, or any other damages whatsoever. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages; the above limitation may not apply to you.

INTELLECTUAL PROPERTY STATEMENT: This NIC Device-class Power Management Specification, including any future enhancements ("NIC class Specification"), is being provided by Microsoft and AMD to encourage the development of devices which exhibit consistent behavior in a Power-managed PC system consistent with the OnNow Design Initiative. Microsoft and AMD grant you the right to reproduce, use and distribute the NIC-class Specification for the purpose of creating, using and distributing hardware and device drivers that comply with the NIC-class Specification. Microsoft and AMD make no warranty that implementations that comply with the NIC-class specification do not infringe IP rights of third parties.

Top of page

Scope

This specification 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. This specification applies specifically to Ethernet and token ring adapters. ATM and ISDN adapters are not supported by this specification. It is intended that network device vendors and system makers will be able to design consistent power-manageable products, and that OS vendors will be able to implement an appropriate network device power management policy based on the contents of this specification.

Top of page

General Device Power Management Considerations

In the OnNow architecture, power management of individual devices is the responsibility of a policy owner in the Operating System, generally a class-specific driver. This policy-owner will implement a power conservation policy that is appropriate for devices in its class. The policy will operate in conjunction with a global system power policy implemented in the operating system (i.e., is the system working or sleeping?). In general, the device-class power conservation policy strives to reduce power consumption while the system is working by transitioning amongst various available power states according to device usage. Since the policy-owner in the Operating System has very specific knowledge of when a device is in use, or potentially in use, there is no need for hardware timers or such to determine when to make these transitions. Similarly, this level of understanding of device usage makes it possible to use fewer device power states. Generally, intermediate states attempt to draw a compromise between latency and consumption due to the uncertainty of actual device usage. With the increased knowledge in the OS, crisp decisions can be made about whether the device is needed at all. With this ability to turn devices off more frequently, the benefit of having intermediate states diminishes.

The policy-owner also determines what class-specific events can cause the system to transition from Sleeping to Working, and enables this functionality based on application or user requests. Note that the definition of the wake-up events that each class supports will influence the system's global power policy in terms of the level of power conservation the Sleeping state can attain while still meeting wake-up latency requirements set by applications or the user.

In the OnNow architecture, bus drivers also implement power policy for their bus class (e.g., PCI, USB, etc.). In general, the bus driver has responsibility for tracking the device power states of all devices on its bus, and transitioning the bus itself to only those power states that are consistent with those of its devices. This means that the bus state can be no lower than the highest state of one of its devices. However, enabled wake-up events can affect this as well. For example if a particular device is in the D2 state and set to wake up the system, and the bus can only forward wake-up requests while in the D1 state, then the bus must remain in the D1 state even if all devices are in a lower state.

Device power state transitions are explicitly commanded by the driver and invoked through bus-specific mechanisms (e.g., ATA Standby command, USB Suspend, etc.). In some cases, bus-specific mechanisms are not available and device-specific mechanisms must be used. The overall flow of control follows a strict sequence according to the hardware hierarchy of the system. When the system policy owner decides to put the system to sleep, it will first query applications to determine if the sleep should proceed. It next queries the drivers, starting at higher-level drivers in the hardware hierarchy, and then continuing to lower-level drivers. Assuming all components succeed the query indicating they are in a state that can successfully support going to sleep and that they will stay in that state (i.e., not start any uninterruptable operations) until further notification, the system will begin the transition to sleep. Again, applications will be notified first of the impending sleep transition and they will close files as needed and silently succeed the notification message. Class-specific drivers will next get notified, and they will save any device context and place their device into the appropriate device power state depending on whether wakeup is enabled on the device. The default state is D3 but may be different if wakeup is enabled. Bus drivers will perform the actual power state transitions on the device using bus-specific mechanisms, and then the bus driver will put its own device (the bus controller) into the appropriate device power state. Upon wake-up, notification and processing will occur in the reverse order to that indicated above.

The following definitions apply to devices of all classes:

Any device context lost must be restored by the device driver when returning the device to the D0 state.

Top of page

Network Device Power State Definitions

For the purpose of the following state definitions "no bus transmission" means that transmit requests from the host processor are not honored, and "no bus reception" means that received data are not transferred to host memory.

D0
Required

D1
Optional

D2
Optional

D3
Required

This document does not specify maximum power and maximum latency requirements for the sleeping states because these numbers are very different for different network technologies. The device must meet the requirements of the bus that it attaches to.

Although the descriptions of states D1 and D2 are the same, the choice of whether to implement D1 or D2 or both may depend on bus services required, power requirements, or time required to restore the physical layer. For example, a device designed for a particular bus might include state D1 because it needs a bus service such as a bus clock to support Magic Packet™ wake, and that service is available in the bus device's D1 power state but not in D2. Also, a device might include both state D1 and state D2 to provide a choice between lower power and lower latency.

Top of page

Network Device Power Conservation Policy

Top of page

Minimum Power Capabilities

A network device conforming to this specification must support the D0 and D3 states. Support for the D1 and D2 states is optional.

Top of page

Network Wake-up Events

Network wake events are generally the result of either a change in the link status or the reception of a wake frame from the network.

Link Status Events Link status wake events are useful to indicate a change in the network's availability, particularly when this change may impact the level at which the system should re-enter the sleeping state. For example, a transition from "link off" to "link on" may trigger the system to re-enter sleep at a higher level (for example, S2 versus S3) so that wake frames can be detected. Conversely, a transition from "link on" to "link off" may trigger the system to re-enter sleep at a deeper level (for example, S3 versus S2) since the network is not currently available. The network device should implement an internal delay to avoid unnecessary transitions when the link status toggles on or off momentarily.

Wake Frame Events Wake frame events are used to wake the system whenever
meaningful data is presented to the system over the network. Examples of meaningful data include the reception of a Magic Packet, a management request from a remote administrator, or simply network traffic directly targeted to the local system. In all of these cases the network device was pre-programmed by the policy owner or other software with information on how to identify wake frames from other network traffic. The details of how this information is passed between software and network device depend on the OS and therefore are not described in this specification.

When making the decision to wake up the system, the device does not necessarily examine every byte in every incoming frame. For example, each of these frames has a source address field that is not necessarily considered in the decision to wake up the system. Before putting the network adapter into the wake-up state, the system passes to the adapter's driver a list of sample frames that should wake up the system. For each sample wake-up frame the system also provides a byte mask that indicates which bytes of the incoming frame should be ignored.

Since the network device looks for predefined patterns in fixed locations within each frame, this mechanism may not work for some protocols. For example in NETBIOS name query frames that use Internet Protocol version 6 (IPv6), some important data may appear after a variable number of IPv6 headers. This sort of packet is not supported by the wakeup scheme. Note that including a Windows Internet Name Service (WINS) server in the network eliminates the need to look beyond the first fixed-length IPv6 header for pattern matching for NETBIOS name queries since these queries are handled by the WINS server and not by the sleeping machine.

Implementations of some protocols may not be compatible with this wake-up mechanism because they require a response sooner than a system can wake up and send an acknowledgment or because they require periodic transmissions from all stations to maintain router tables.

The table below shows the minimum sets of wake-up patterns that are required to support NETBIOS connections in three different TCP/IP environments: IP version 4, IP version 6 without a WINS server, and IP version 6 with a WINS server.

Network Wake-up Frame DetailsBefore putting the network adapter into the wake-up state, the system passes to the adapter's driver a list of sample frames and corresponding byte masks. Each sample frame is an example of a frame that should wake up the system. Each byte mask defines which bytes of the incoming frames should be compared with the corresponding sample frame in order to determine whether or not to accept the incoming frame as a wake-up event.

Figure 1. A List of Sample Frames

When the network adapter is operating in the wake-up mode, the byte masks work as follows: If bit number i of byte mask number k is 1, then byte number i of each incoming frame will be compared with byte number i of sample frame number k. Otherwise byte number i of sample frame number k will be ignored in the wake-up comparison. If all of the bytes thus selected from one of the sample frames match the corresponding bytes of the incoming frame, then the incoming frame will cause the network adapter to generate a bus specific wake-up signal.

The sample frame starts at the beginning of the MAC header field. For Ethernet, the first bit of the byte mask corresponds to the first byte of the Destination Address Field of the Ethernet MAC header. For Token Ring, the first bit of the byte mask corresponds to the first byte of the Access Control Field of the Token Ring MAC header.
For FDDI, the first bit of the byte mask corresponds to the first byte of the Frame Control Field of the FDDI MAC header.

The sample frame does not include token ring source routing information. A token ring adapter must skip over any source routing data when it is examining a frame for a wake-up pattern.

In the example below each byte of the incoming frame that corresponds to a bit that is set to 1 in the byte mask matches the corresponding byte in the sample frame. Therefore this incoming frame would cause the wake-up signal to be asserted.

Figure 2. A Sample Frame and Byte Mask

If one of bytes 4 through 7 had been different, the comparison would have failed and the network adapter would move on to the next item in the list. If the network adapter goes through all the frames in the list and cannot find a match, it simply discards the frame.

The pattern matching described above is done in addition to the normal address filtering that occurs in state D0. Only a frame that passes the device's MAC, broadcast, or multicast address filter and matches one of the previously loaded sample patterns will cause the wake-up signal to be asserted.

(Note that pattern or byte mask storage space might be reduced at the expense of additional hardware complexity if the driver would store a pointer to the first byte of the frame that should be examined. For example if the first 30 bytes of the frame are to be ignored, the driver could store the number 30 along with a sample frame that is 30 bytes shorter than the original sample frame that the operating system gave to the driver. For a device that is built with this type of interface, the software driver is responsible for examining the parameters passed from the operating system to determine the offset and to truncate the sample frames appropriately.)

Appendix A includes samples of wake-up packets that might be used for a typical protocol.

Magic Packet Received
Use of Magic Packet to signal wakeup is compatible with this specification. Existing implementations that use proprietary server and client software do not require any support in an OnNow operating system. In these solutions, enabling Magic Packet detection is device/driver/application-specific. New implementations can use the OnNow OS services for sleep notifications, wakeup enable, and wakeup notification.

Top of page

Operating System Considerations

In order to prepare the network device to respond to wake-up frames, the operating system must provide a standard interface for the following functions:

The OS can load or delete a sample frame at any time. Once a sample frame has been loaded, it must remain loaded (either in host memory allocated to the device-specific driver or in storage space within the network device) until it is specifically deleted. It is not necessary for the OS to reload the sample frames each time it puts the network device into wake-up mode.

The details of how this information is passed between the OS and the driver depend on the operating system and therefore are not described in this specification.

When the network device is operating in the wake-up mode, it may save one or more incoming frames including the wake-up frame so that it can pass these frames to the upper layer software when the device is returned to the D0 state. However, this is not a requirement of this specification. As an alternative, the network device may discard all frames received, including the wake-up frame, while it is operating in the wake-up mode.

There can be a performance advantage to saving some number of frames that arrive while the device is operating in wake-up mode. The system can respond more quickly if the wake-up frame is saved. Also in some cases saving the wake-up frame may make the difference between maintaining a virtual connection and dropping the connection. For certain protocols if the time required to wake up the system is relatively long, a remote station may stop retransmitting requests before a sleeping station wakes up. If the network device has saved the wake-up frame, the station can respond to the request after it wakes up and thereby may be able to maintain the connection.

When the network device is operating in the wake-up mode, it will not accept frames from upper layer software for transmission.

Once the operating system issues a command to put the network device into the wake-up mode, the device remains in the wake-up mode until the operating system issues a command to take the device out of the wake-up mode. The device does not automatically leave the wake-up mode when it detects a wake-up frame.

This document places no restrictions on the amount of time that the network device may take to examine an incoming frame for a possible match. This means that the device may fail to recognize a wake-up frame that arrives while the device is still examining an earlier frame that was addressed to this network device. It is assumed that when this happens, the device that issued the wake-up frame would retry after some timer expired.

The format of wake-up frames may differ for different network technologies. For example the positions of relevant bytes for an IEEE 802.3 frame may be different from corresponding byte positions in an IEEE 802.5 frame. It is the responsibility of the operating system to pass to the network device sample patterns that are appropriate for the network technology in use.

Top of page

Exact vs. Signature Matching

The above description specifies perfect matching of the incoming data with selected bytes of stored frames. This may be undesirable or even impossible, depending on the architecture of the network adapter. While perfect matching would be the best solution, other mechanisms, such as hashing or check summing the incoming frame may offer adequate performance while reducing the hardware requirements.

For example instead of storing complete patterns, the device may store only a four-byte CRC value and a byte mask for each sample frame. This approach requires one CRC generator circuit for each sample frame. For each sample frame and byte mask that the system software passes to the driver, the driver calculates a CRC value based on those bytes of the sample frame that correspond to bits that are set to 1 in the byte mask for that pattern. The driver stores the resulting value and corresponding byte mask in the controller hardware. When wake-up mode is enabled, as a frame arrives from the network, each CRC generator calculates a CRC value based on those bytes of the incoming frame that correspond to bits that are set to 1 in that CRC generator's byte mask. If for any of the CRC generators, the calculated value matches the stored value and if the incoming frame passes the standard CRC check, the device asserts the wake-up signal.

For the example shown in Figure 2, the network driver computes a 32-bit CRC based on the 4 bytes of the frame corresponding to mask bits that are set to 1, namely bytes 4, 5, 6, and 7. The network driver loads this CRC value and the byte mask into the network adapter. When a frame is being received, the network adapter calculates a CRC value using bytes number 4, 5, 6 and 7 of the incoming frame. When the incoming frame ends, the calculated CRC is compared to stored CRC. If there is a match, and if the whole frame's CRC is also correct, a wake-up event will be generated.

Other signature matching implementations are possible.

Signature matching schemes may generate false wake ups. This specification does not limit how often false wake ups may occur.

Top of page

Appendix A: Example Wake-up Frames

The following describes the minimum set of patterns for a machine with one IP address per adapter and a computer name. It is the absolute minimum set of patterns that would be useful to wake up on. If the NIC can support more than this set, they will be used for additional IP addresses, multicast addresses, or NetBIOS names.

Notes:

ARP to machine address 157.55.199.72
This pattern will wake a machine up whenever another machine needs to obtain its MAC address. This generally precedes any IP transaction.

Offset:	Hex Pattern:
====================================================
12  0806      ; Protocol type (0806 = ARP)
21  01        ; ARP Opcode (01 = Request)
38  9d37c748  ; IP Address requested (157.55.199.72)

Directed IP packet (note that this excludes any other directed packets to our MAC address)
This pattern will wake the machine up if any other machine sends information directly to it (Normal IP transactions).

Offset:	Hex Pattern:
============================================================
0   08003e304770 ; Destination MAC Address (Station Address)
12  0800         ; Protocol type (0800 = IP)
30  9d37c748     ; IP Address (157.55.199.72)

NBT Name Query/Registration for computername <00>, <03>, <20>
This pattern will wake a machine up whenever another machine needs to obtain its IP address in order to initiate an IP Transaction (using NetBIOS

Offset:	Hex Pattern:
=====================================================================
12  0800     ; Protocol type (0800 = IP)
23  11       ; Protocol (11= UDP)
34  00890089 ; Port Number (NETBIOIS Name Service)
45  10       ; NetBIOS Flags (10 = Query OR Registration)
54 20        ; Name scope - NULL (limited to 32 bytes)
55 46 48 45 42 45 4C 45 46  ; Computerame - coded in half-ASCII ('WAKER')
56 46 43 43 41 43 41 43 41  ; **Note that this field is always 30 bytes.  The final character
57 43 41 43 41 43 41 43 41  ; is not included because it is not unique (may be 00, 03 or 20)
79	43 41 43 41 43 41

Some systems may support network wakeup over the IPX protocol. In such a case, the below would be potential wakeup patterns.

Notes:

IPX Diagnostic Responder Request
This pattern will wake the machine when an IPX diagnostic packet is sent by network management tools.

Offset:	Hex Pattern:
=================================
12  8137  ; IPX Protocol type
30  0456  ; IPX Diagnostic Socket

Directed IPX packets
This pattern will wake the machine up if any other machine sends information directly to it (Normal IPX transactions).

Offset:	Hex Pattern:
=====================================
0   08003E304770  ; Station Address
12  8137          ; IPX Protocol type
24  08003E304770  ; IPX Node Address

Top of page