Device Class Power Management Reference Specification

Network Device Class

This specification is co-authored by Microsoft and 
Advanced Micro Devices, Inc. 

V2.0
October 12, 2000

Copyright © 1996, 1997, 2000 Microsoft Corporation, Advanced Micro Devices, Inc.
All rights reserved.

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

The 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.

Information in this document is subject to change without notice.  Companies, names and data used in examples herein are fictitious unless otherwise noted.

(c) Microsoft Corporation, Advanced Micro Devices, Inc., 1996, 1997.  All rights reserved.

Microsoft, Windows and Win32 are registered trademarks and Windows NT is a trademark of Microsoft Corporation.

AMD and Magic Packet are trademarks of Advanced Micro Devices, Inc.

All other product names are trademarks, registered trademarks, or servicemarks of their respective owners.

Table of Contents

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

Revision History

Revision	Date	Comments	
2.0	10/12/00	Revisions in Version 2.0 incorporate changes in power state definitions to match Appendix A of Advanced Confirmation and Power Interface Specification (ACPI) Revision 2.0.	
1.0a	11/21/97	Clarified where beginning of pattern match is for various network packet types	
1.0	3/4/97	Final version	
0.99	1/31/97	Adds address filter comment & IPX examples	
0.90	1/10/97	Incorporates 12/16 feedback	
0.80	11/27	Incorporates 11/11 feedback	
0.75	10/21	Incorporates 10/7 feedback	
0.7	9/23/96	Incorporates 9/20 feedback	
0.6	6/14/96	Incorporates 6/11 feedback	
0.3	6/3/96	Third edit after 6/3 meeting	
0.2	6/3/96	Second edit before 6/3 meeting	
0.0	5/1/96	Initial proposal for consideration	

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.
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:

•	D0:	Device is on and running.  It is receiving full power from the system, and is delivering full functionality to the user.
•	D1:	Class-specific low-power state (defined below) in which device context may or may not be lost.  Buses in D1 cannot do anything to the bus that would force devices on that bus to lose context.
•	D2:	Class-specific low-power state (defined below) in which device context may or may not be lost.  Attains greater power savings than D1.  Buses in D2 may cause devices on that bus to lose some context (e.g. the bus reduces power supplied to the bus).  Devices in D2 must be prepared for the bus to be in D2 (or higher).
•	D3:  Device is off and not running.  Device context is lost.  Power may be removed from the device.

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

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.

State	Status	Definition	
D0	Required	Device is on and running and is delivering full functionality and performance to the user
Device is fully compliant with the requirements of the attached network	
D1	Optional	No bus transmission allowed 
No bus reception allowed 
No interrupts can occur 
Device context may be lost	
D2	Optional	No bus transmission allowed 
No bus reception allowed 
No interrupts can occur 
Device context may be lost	
D3	Required	Device context is assumed to be lost 
No bus transmission allowed 
No bus reception allowed 
No interrupts can occur	
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.

Network Device Power Conservation Policy

Present State	Next State	Cause	
D0	Dx	System enters sleep state. If wake is enabled, Dx is the lowest power state (for example, D1, D2, D3) from which the network device supports system wake. 
An appropriate time-out has elapsed after a “link down” condition was detected. Dx is the lowest power state in which the network device can detect “link up.”	
D0	D3	System initiated network shutdown. 
System enters sleep state and wake is either not enabled or the network device is capable of waking from D3. 	
D1/D2/D3	D0	System wake (transition to S0), including a wake caused by a network wake event.	

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.
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.

	Pattern filters needed for various networking environments	
Networking Function	IPv4	IPv6 w/o WINS server	IPv6 w/WINS server	
NetBIOS Broadcast queries	1 NBT pattern filter required ( machine)	Won’t work because of IPv6 Extension Headers	Not applicable -- WINS does NetBIOS name to IP address association	
Hardware address resolution	ARP broadcast	Neighbor discovery multicast	Neighbor discovery multicast	
Unicast	Directed MAC address with specific protocol type	Directed MAC address with specific protocol type	Directed MAC address with specific protocol type	

Network Wake-up Frame Details
Before 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.

	Sample frame:		66 AA 00 04 05 06 07 00 BB 00
	Mask for above frame:	 0  0  0  1  1  1  1  0  0  0
	Incoming frame:		10 02 03 04 05 06 07 08 09 0A

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.

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 driver for the network device must be able to indicate to the OS which types of wake-up events it can detect in each power state.  For example, a device may be able to detect a Magic Packet in states D1 or D2; a network wake-up frame in state D1 only; and a link change in states D1, D2, or D3.
•	The OS must provide notifications to the NIC driver of device power state changes, system sleep, and system wake.  
•	For each sample wake-up frame the OS must pass to the driver the contents of the frame and a byte mask that tells the driver which bytes of the incoming data stream to accept for matching.
•	For each sample wake-up frame the driver returns to the OS an indication of whether or not it was able to accept the frame.  The driver may not be able to accept a frame because the device has run out of storage space, because the device can not accept sample frames of that length, or for other reasons that are specific to the device. 
•	The driver must be able to delete any specific frame from its list of sample frames.  When the OS requests the driver to delete a sample frame, the OS identifies the frame by its contents rather than by the order in which it was loaded.  The OS passes to the driver the contents of the frame to be deleted and its corresponding byte mask.  Deleting one frame must not affect any other frames that have already been loaded.
•	The OS must be able to issue commands to the network device’s driver to enter or leave the wake-up mode.

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.
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 22, 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.

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: 
•	'computername' below is "WAKER"
•	Station address is 08003e304770
•	NetBIOS scope is null
•	Media is 802.3 without SNAP.  For a different framing (SNAP, FDDI, ARCNET etc.) the offsets would be different.

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: 
•	Station address is 08003e304770
•	Media is Ethernet II.  For 802.2 the offsets would be different.
•	
•	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