Network Device Class This specification co-authored Microsoft Adv

The Datasheet Archive - 100 Million Datasheets from 7500 Manufacturers.

Network Device Class This specification co-authored Microsoft Adv

Datasheet Thumbnail

Top Searches for this datasheet

Device Class Power Management Reference Specification
Network Device Class
This specification co-authored Microsoft Advanced Micro Devices, Inc.
V1.0 March 1997
Device Class Power Management Reference Specification
Network Device Class
Copyright 1996, Microsoft Corporation, Advanced Micro Devices, Inc. rights reserved.
Microsoft Advanced Micro Devices, Inc. (AMD) make representation warranty regarding specifications this document product item developed based these specifications. Microsoft disclaim express implied warranties, including limited implied warranties merchantability fitness particular purpose. Microsoft shall liable damages arising connection with these specifications, including liability lost profit, business interruption, other damages whatsoever. Some states allow exclusion limitation liability consequential incidental damages; above limitation apply you.
INTELLECTUAL PROPERTY STATEMENT
Device-class Power Management Specification, including future enhancements ("NIC class Specification"), being provided Microsoft encourage development devices which exhibit consistent behavior Power-managed system consistent with OnNow Design Initiative. Microsoft grant right reproduce, distribute NIC-class Specification purpose creating, using distributing hardware device drivers that comply with NICclass Specification. Microsoft make warranty that implementations that comply with NIC-class specification infringe rights third parties. Information this document subject change without notice. Companies, names data used examples herein fictitious unless otherwise noted. Microsoft Corporation, Advanced Micro Devices, Inc., 1996. rights reserved.
Microsoft, Windows Win32 registered trademarks Windows trademark Microsoft Corporation. Magic Packet trademarks Advanced Micro Devices, Inc. other product names trademarks, registered trademarks, servicemarks their respective owners.
Table Contents
Scope General Device Power Management Considerations.1 Network Device Power State Definitions Network Device Power Conservation Policy Network Wake-up Events.1 Operating System Considerations.1 Exact Signature Matching.1 Appendix Example Wake-up Frames.1
Revision
Device Class Power Management Reference Specification
Network Device Class
Revision History
Revision 0.99 0.90 0.80 0.75
Date 3/4/97 1/31/97 1/10/97 11/27 10/21 9/23/96 6/14/96 6/3/96 6/3/96 5/1/96
Comments Final version Adds address filter comment examples Incorporates 12/16 feedback Incorporates 11/11 feedback Incorporates 10/7 feedback Incorporates 9/20 feedback Incorporates 6/11 feedback Third edit after meeting Second edit before meeting Initial proposal consideration
Revision
Device Class Power Management Reference Specification
Network Device Class
Scope
This specification defines behavior network devices relates power management, and, specifically, four device power states defined OnNow Architecture. This specification applies specifically Ethernet token ring adapters. Aand ISDN adapters supported this specification. intended that network device vendors system makers will able design consistent power-manageable products, that vendors will able implement appropriate network device power management policy based contents this specification.
General Device Power Management Considerations
OnNow architecture, power management individual devices responsibility policy owner Operating System, generally class-specific driver. This policy-owner will implement power conservation policy that appropriate devices class. policy will operate conjunction with global system power policy implemented operating system (i.e. system working sleeping?). general, device-class power conservation policy strives reduce power consumption while system working transitioning amongst various available power states according device usage. Since policy-owner Operating System very specific knowledge when device use, potentially use, there need hardware timers such determine when make these transitions. Similarly, this level understanding device usage makes possible fewer device power states. Generally, intermediate states attempt draw compromise between latency consumption uncertainty actual device usage. With increased knowledge crisp decisions made about whether device needed all. With this ability turn devices more frequently, benefit having intermediate states diminishes. policy-owner also determines what class-specific events cause system transition from Sleeping Working, enables this functionality based application user requests. Note that definition wake-up events that each class supports will influence system's global power policy terms level power conservation Sleeping state attain while still meeting wake-up latency requirements applications user. OnNow architecture, drivers also implement power policy their class (e.g. PCI, USB, etc.). general, driver responsibility tracking device power states devices bus, transitioning itself only those power states that consistent with those devices. This means that state lower than highest state devices. However, enabled wake-up events affect this well. example particular device state wake system, only forward wake-up requests while state, then must remain state even devices lower state. Device power state transitions explicitly commanded driver invoked through busspecific mechanisms (e.g. Standby command, Suspend, etc.). some cases, bus-specific mechanisms available device-specific mechanisms must used. overall flow control follows strict sequence according hardware hierarchy system. When system policy owner decides system sleep, will first query applications determine sleep should proceed. next queries drivers, starting higher-level drivers hardware hierarchy, then continuing lower-level drivers. Assuming components succeed query indicating they state that successfully support going sleep that they will stay that state (i.e. start uninterruptable operations) until further notification, system will begin transition sleep. Again, applications will notified first impending sleep transition they will close files needed silently succeed notification message. Class-specific drivers will next notified, they will save device context place their device into appropriate device power state depending whether wakeup enabled device. default state different wakeup enabled. drivers will perform actual power state transitions device using bus-specific mechanisms, then driver will device (the controller) into appropriate device power state. Upon wake-up, notification processing will occur reverse order that indicated above. following definitions apply devices classes:
Revision
Device Class Power Management Reference Specification
Network Device Class
Device running. receiving full power from system, delivering full functionality user. Class-specific low-power state (defined below) which device context lost. Buses cannot anything that would force devices that lose context. Class-specific low-power state (defined below) which device context lost. Attains greater power savings than Buses cause devices that lose some context (e.g. reduces power supplied bus). Devices must prepared higher). Device running. Device context lost. Power removed from device.
device context lost must restored device driver when returning device state.
Network Device Power State Definitions
purpose following state definitions transmission" means that transmit requests from host processor honored, reception" means that received data transferred host memory. statement that device context lost means that hardware lose some state information. However, power states device-specific driver responsible saving context restoring context after device returns state This document does specify maximum power maximum latency requirements sleeping states because these numbers very different different network technologies. device must meet requirements that attaches
Device running delivering full functionality performance user. Device fully compliant with requirements attached network.
transmission allowed. reception allowed. interrupts occur. Device context lost.
transmission allowed. reception allowed. interrupts occur. Device context lost.
(Power removed)
Device context assumed lost. transmission allowed. reception allowed. interrupts occur.
Revision
Device Class Power Management Reference Specification
Network Device Class
Although descriptions states same, choice whether implement both depend services required, power requirements, time required restore physical layer. example, device designed particular might include state because needs service such clock support Magic Packetwake that service available state state Also device might include both state state provide choice between lower power lower latency.
Network Device Power Conservation Policy
following transitions will explicitly commanded driver software: Present State Next State Cause System enters sleep state, wakeup enabled network device, lowest power state from which network device supports system wakeup Appropriate time-out (T1) after Link down. lowest power state which network device detect link System initiated network shutdown System enters sleep state wakeup either enabled, network device capable waking from System wakeup (transition S0), including wakeup caused Network Wake-up event
power state after hardware reset specific therefore defined this document.
Network Wake-up Events
wake-up event request hardware and/or software external network device system into power state (Working). wake-up signal caused Detection change network link state, Receipt network wake-up frame, Receipt Magic PacketThese wake-up mechanisms optional. Manufacturers also implement other types wake-up events that listed here, using private interfaces. Network devices that support wake-up events must have device-specific methods individually enabling disabling each wakeup source, indicating which source caused wakeup. Network wake-up events occur from device power state, depending capabilities individual network device. example device able signal wake-up event only when state while another device able signal wake-up event power state.
Change network link state
goal link state change being wakeup event that sleeping system that waiting network wakeup packet notified when link down (i.e. wakeup packet sent system) that lower device's power state and, perhaps, system's sleeping state order
Revision
Device Class Power Management Reference Specification
Network Device Class
conserve energy. Note that Link Down condition result temporary wiring changes net, necessarily disconnection cable from network device itself. Because this, appropriate time-out should used before deciding lower device's power state.
Network Wake-up Frames
purpose frame wake-up mode wake system when another machine network needs communicate with this system. mechanism described this specification does require application running remote machine send special wake-up pattern. Instead when network device operating frame wake-up mode, tries identify certain "interesting" frames that sent existing network protocols. Some examples frames that might cause wake-up signals requests, NETBIOS name lookups, frame addressed machine, etc. These frames addressed broadcasts, multicasts, directly addressed frames. When making decision wake system, device does necessarily examine every byte every incoming frame. example, each these frames source address field that necessarily considered decision wake system. Before putting network adapter into wake-up state, system passes adapter's driver list sample frames that should wake system. each sample wake-up frame system also provides byte mask that indicates which bytes incoming frame should ignored. Since network device looks predefined patterns fixed locations within each frame, this mechanism work some protocols. example NETBIOS name query frames that Internet Protocol version (IPv6), some important data appear after variable number IPv6 headers. This sort packet supported wakeup scheme. Note that including Windows Internet Name Service (WINS) server network eliminates need look beyond first fixedlength IPv6 header pattern matching NETBIOS name queries since these queries handled WINS server sleeping machine. Implementations some protocols compatible with this wake-up mechanism because they require response sooner than system wake send acknowledgment because they require periodic transmissions from stations maintain router tables. table below shows minimum sets wake-up patterns that required support NETBIOS connections three different TCP/IP environments: version version without WINS server, version with WINS server. Pattern filters needed various networking environments Networking Function NetBIOS Broadcast queries Hardware address resolution Unicast IPv4 pattern filter required machine) broadcast Directed address with specific protocol type IPv6 WINS server Won't work because IPv6 Extension Headers Neighbor discovery multicast Directed address with specific protocol type IPv6 w/WINS server applicable WINS does NetBIOS name address association Neighbor discovery multicast Directed address with specific protocol type
Revision
Device Class Power Management Reference Specification
Network Device Class
Network Wake-up Frame Details
Before putting network adapter into wake-up state, system passes adapter's driver list sample frames corresponding byte masks. Each sample frame example frame that should wake system. Each byte mask defines which bytes incoming frames should compared with corresponding sample frame order determine whether accept incoming frame wake-up event. Sample Frame Sample Sample
Byte Mask
00010110011. 00011010011.
Byte
00010100111.
Sample
Sample
00011001011.
Figure List Sample Frames When network adapter operating wake-up mode, byte masks work follows: number byte mask number then byte number each incoming frame will compared with byte number sample frame number Otherwise byte number sample frame number will ignored wake-up comparison. bytes thus selected from sample frames match corresponding bytes incoming frame, then incoming frame will cause network adapter generate specific wake-up signal. sample frame starts beginning header field. first byte mask corresponds first byte Destination Address Field header. sample frame does include token ring source routing information. token ring adapter must skip over source routing data when examining frame wake-up pattern. example below each byte incoming frame that corresponds that byte mask matches corresponding byte sample frame. Therefore this incoming frame would cause wake-up signal asserted.
Sample frame: Mask above frame: Incoming frame:
Figure Sample Frame Byte Mask bytes through been different, comparison would have failed network adapter would move next item list. network adapter goes through frames list
Revision
Device Class Power Management Reference Specification
Network Device Class
cannot find match, simply discards frame. pattern matching described above done addition normal address filtering that occurs state Only frame that passes device's MAC, broadcast, multicast address filter matches previously loaded sample patterns will cause wake-up signal asserted. (Note that pattern byte mask storage space might reduced expense additional hardware complexity driver would store pointer first byte frame that should examined. example first bytes frame ignored, driver could store number along with sample frame that bytes shorter than original sample frame that operating system gave driver. device that built with this type interface, software driver responsible examining parameters passed from operating system determine offset truncate sample frames appropriately.) Appendix includes samples wake-up packets that might used typical protocol.
Magic PacketReceived
Magic Packet signal wakeup compatible with this specification. Existing implementations that proprietary server client software require support OnNow operating system. these solutions, enabling Magic Packet detection implementations OnNow services sleep notifications, wakeup enable, wakeup notification.
Operating System Considerations
order prepare network device respond wake-up frames, operating system must provide standard interface following functions:
driver network device must able indicate which types wake-up events detect each power state. example, device able detect Magic Packet states network wake-up frame state only; link change states must provide notifications driver device power state changes, system sleep, system wake. each sample wake-up frame must pass driver contents frame byte mask that tells driver which bytes incoming data stream accept matching. each sample wake-up frame driver returns indication whether able accept frame. driver able accept frame because device storage space, because device accept sample frames that length, other reasons that specific device. driver must able delete specific frame from list sample frames. When requests driver delete sample frame, identifies frame contents rather than order which loaded. passes driver contents frame deleted corresponding byte mask. Deleting frame must affect other frames that have already been loaded. must able issue commands network device's driver enter leave wake-up mode.
Revision
Device Class Power Management Reference Specification
Network Device Class
load delete sample frame time. Once sample frame been loaded, must remain loaded (either host memory allocated device-specific driver storage space within network device) until specifically deleted. necessary reload sample frames each time puts network device into wake-up mode. details this information passed between driver depend operating system therefore described this specification. When network device operating wake-up mode, save more incoming frames including wake-up frame that pass these frames upper layer software when device returned state. However, this requirement this specification. alternative, network device discard frames received, including wake-up frame, while operating wake-up mode. There performance advantage saving some number frames that arrive while device operating wake-up mode. system respond more quickly wake-up frame saved. Also some cases saving wake-up frame make difference between maintaining virtual connection dropping connection. certain protocols time required wake system relatively long, remote station stop retransmitting requests before sleeping station wakes network device saved wake-up frame, station respond request after wakes thereby able maintain connection. When network device operating wake-up mode, will accept frames from upper layer software transmission. Once operating system issues command network device into wake-up mode, device remains wake-up mode until operating system issues command take device wake-up mode. device does automatically leave wake-up mode when detects wake-up frame. This document places restrictions amount time that network device take examine incoming frame possible match. This means that device fail recognize wake-up frame that arrives while device still examining earlier frame that addressed this network device. assumed that when this happens, device that issued wake-up frame would retry after some timer expired. format wake-up frames differ different network technologies. example positions relevant bytes IEEE 802.3 frame different from corresponding byte positions IEEE 802.5 frame. responsibility operating system pass network device sample patterns that appropriate network technology use.
Exact Signature Matching
above description specifies perfect matching incoming data with selected bytes stored frames. This undesirable even impossible, depending architecture network adapter. While perfect matching would best solution, other mechanisms, such hashing check summing incoming frame offer adequate performance while reducing hardware requirements. example instead storing complete patterns, device store only four-byte value byte mask each sample frame. This approach requires generator circuit each sample frame. each sample frame byte mask that system software passes driver, driver calculates value based those bytes sample frame that correspond bits that
Revision
Device Class Power Management Reference Specification
Network Device Class
byte mask that pattern. driver stores resulting value corresponding byte mask controller hardware. When wake-up mode enabled, frame arrives from network, each generator calculates value based those bytes incoming frame that correspond bits that that generator's byte mask. generators, calculated value matches stored value incoming frame passes standard check, device asserts wake-up signal. example shown Figure network driver computes 32-bit based bytes frame corresponding mask bits that namely bytes network driver loads this value byte mask into network adapter. When frame being received, network adapter calculates value using bytes number incoming frame. When incoming frame ends, calculated compared stored CRC. there match, whole frame's also correct, wake-up event will generated. Other signature matching implementations possible. Signature matching schemes generate false wake ups. This specification does limit often false wake occur.
Revision
Device Class Power Management Reference Specification
Network Device Class
Appendix Example Wake-up Frames
following describes minimum patterns machine with address adapter computer name. absolute minimum patterns that would useful wake support more than this set, they will used additional addresses, multicast addresses, NetBIOS names. Notes: 'computername' below "WAKER" Station address 08003e304770 NetBIOS scope null Media 802.3 without SNAP. different framing (SNAP, FDDI, ARCNET etc.) offsets would different.
machine address 157.55.199.72 This pattern will wake machine whenever another machine needs obtain address. This generally precedes transaction. Offset: Pattern: 0806 Protocol type (0806 ARP) Opcode Request) 9d37c748 Address requested (157.55.199.72) Directed packet (note that this excludes other directed packets address) This pattern will wake machine other machine sends information directly (Normal transactions). Offset: Pattern: 08003e304770 Destination Address (Station Address) 0800 Protocol type (0800 9d37c748 Address (157.55.199.72) Name Query/Registration computername <00>, <03>, <20> This pattern will wake machine whenever another machine needs obtain address order initiate Transaction (using NetBIOS) Offset: Pattern: 0800 Protocol type (0800 Protocol (11= UDP) 00890089 Port Number (NETBIOIS Name Service) NetBIOS Flags Query Registration) Name scope NULL (limited bytes) Computerame coded half-ASCII (`WAKER') **Note that this field always bytes. final character included because unique (may
Revision
Device Class Power Management Reference Specification
Network Device Class
Revision
Device Class Power Management Reference Specification
Network Device Class
Some systems support network wakeup over protocol. such case, below would potential wakeup patterns. Notes: Station address 08003e304770 Media Ethernet 802.2 offsets would different.
Diagnostic Responder Request This pattern will wake machine when diagnostic packet sent network management tools. Offset: Pattern: 8137 Protocol type 0456 Diagnostic Socket Directed packets This pattern will wake machine other machine sends information directly (Normal transactions). Offset: Pattern: 08003E304770 Station Address 8137 Protocol type 08003E304770 Node Address
Revision

Network Device Class This specification co-authored Microsoft Adv

Top Searches for this datasheet

Other recent searches