Magic Packet Technology White Paper
SOURCE ADDRESS, DESTINATION ADDRESS (which may be the receiving station’s IEEE address or a MULTICAST address which includes the BROAD-CAST address), and CRC. The specific quence con-sists of 16 duplications of the IEEE address of this node, with no breaks or interruptions.
This quence can be located anywhere within the packet, but must be preceded by a synchronization stream. The synchronization stream allows the scan-ning state machine to be much simpler. The synchroni-zation stream is defined as 6 bytes of FFh. The device will also accept a MULTICAST frame, as long as the 16 duplications of the IEEE address match the address of the machine to be awakened.
If the IEEE address for a particular node on the network was 11h 22h 33h 44h 55h 66h, then the LAN controller would be scanning for the data quence (assuming an Ethernet Frame):
DESTINA TION SOURCE MISC FF FF FF FF FF FF 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 11 22 33 44 55 66 MISC CRC Magic Packet Mode Disable
There are two instances where the Magic Packet mode must be disabled, and the Ethernet controller returned to normal operation mode. Either the system has received a Magic Packet frame, possibly from a network administrator who wants to do a hard disk backup, or some other action has caud the system to leave the low power sleep state, such as a ur touching the keyboard, moving the mou, etc. In ei-ther ca, the power management hardware or soft-ware must disable the Magic Packet mode and return the Ethernet controller to normal operation. On the PCnet-ISA II or the PCnet-PCI II, this may be accom-plished by either retting the register bit in an internal register, or de-asrting the SLEEP# pin. SILICON IMPLEMENTATION Implementation details of the Magic Packet T echnology may vary from device to device, as long as the basic functionality is maintained. Since an Ethernet controller already has built-in address matching circuitry to recog-nize regular frames addresd to the node, this circuitry may be re-ud in the ca of Magic Packet mode. A new mode of operation must be implemented, which will allow the power management software or hardware to enter and leave Magic Packet mode. A counter must be added to the address matching circuitry to count up the 16 duplications of the IEEE address, with another circuit to ret the counter if the data being procesd does not match the IEEE address.It should not take much design effort, time, or silicon area to add the Magic Packet T echnology to an existing Ethernet controller. This was one of the primary rea-sons for going with a solution that us the IEEE ad-dres
s as the identifier for the Magic Packet frame, since the circuitry already exists to match this data stream. SYSTEM IMPLEMENTATION
让皮肤美白的方法T o utilize the Magic Packet T echnology in a PC, there are veral modifications which must be done to en-sure proper operation of the feature. Let's take the ca of a motherboard implementation, where the Ethernet controller will be located on the motherboard, with an RJ-45 connector coming out the back of the computer. This implementation is becoming more and more com-mon as Ethernet establishes itlf as a de facto stan-dard for the desktop LAN.
First, let's address the hardware steps necessary to allow the Ethernet controller to wake up the system when it receives a Magic Packet frame. Most desktop PC's the days already have pretty advanced power management circuitry either built into the chipt or as a parate functional block on the motherboard. In this ex-ample, it is a simple matter to connect one of the LED pins, such as LED 3, into the power management cir-cuitry. The Magic Packet frame indication becomes just another possible alert to the power management cir-cuitry that the system needs to wake up. The details as to how to connect the LED 3 pin into the system’s power management circuitry is obviously system, chipt, and design specific, so will not be covered here in detail. The cond stage, the enabling and disabling of the Magic Packet mode, can be done in hardware or soft-ware. I
f done in hardware, the power management cir-cuitry must drive the SLEEP# pin active before it places the machine in the sleep mode. This will stop all normal network activity and place the Ethernet controller into the Magic Packet mode. Upon receiving a Magic Packet frame or nsing some other activity, such as keyboard or mou movement, the hardware must then de-asrt the SLEEP# pin to remove the Ethernet con-troller from Magic Packet mode and return the control-ler to normal operation.
The cond stage can also be done in software, if de-sired. On most systems, the BIOS or other software will be aware of the state of the system and will cooperate in the powering down of the various components of the system. In this instance, if the BIOS is involved in the powering up and down of subsystems, it could, when powering down the system to go to sleep, t a bit in the Ethernet controller to enable Magic Packet mode. When the system wakes up, for whatever reason, the BIOS would then disable Magic Packet mode by de-asrting the same bit to turn off Magic Packet frame detection feature and return the Ethernet controller to the normal operating mode.
Driver Implicationsyesorno2
Network operating system drivers may or may not need to be modified to support the Magic Packet
mode of op-eration. If the hardware or BIOS is responsible for en-abling and disabling the Magic Packet mode, the driver may not need to be changed at all. This is becau the driver has no need to know whether the system has been awake or asleep. If the system goes asleep and then wakes up for some reason, as long as the Ether-net controller is in the same state as when the driver was last accessing it, including the registers and buffer pointers, then the driver can continue functioning as if nothing happened. Of cour, if the system was asleep for an extended time, the PC may have been logged off the network, but it is up to the upper layers, not the driver, to re-establish the link to the rver. However, all that said, the driver may very well be the best place to put support for Magic Packet Technology. For instance, the driver could monitor all Advanced Power Management (APM) calls, and if told that the system is going to sleep, the driver could enable Magic Packet mode. When the APM call indicates the system is in the process of waking up, the driver could then dis-able Magic Packet mode, verify the state of the Ether-net controller, and continue normal activity.
NOS Implications
The implications of Magic Packet Technology on the Network Operating Systems (NOS) is still being deter-mined; however, there are veral points which should be highlighted. First and foremost, many current NOS periodically nd a packet to an end node to determine if the PC is still there and
will log off any station that does not respond to this Ping after X number of retries. This has caud notebook urs frustration for years, since notebooks are designed to go into a SUSPEND mode after a few minutes of inactivity.
This pinging and subquent logging off of PCs that do not respond will have to change, and, in fact, is in the process of changing. The most widely ud NOS which does this is Novell Interware. There are new options in Novell Netware 4.1 which will allow a network adminis-trator to disable this function.
Another problem currently exists with Peer-to-Peer net-working operating systems, such as Windows for Work-groups. The problem is that a ur may attempt to log onto another ur's computer after hours, when that computer has gone into Magic Packet mode and does not respond to normal network traffic. In this ca, the ur will not be able to attach to the other computer as a rver.
小学教师工作计划Infrastructure Implications
Since implementing Magic Packet Technology, there have been many questions concerning the ability of a Magic Packet frame to actually reach and power up a remote PC. The questions usuall
y center around the ability of the Magic Packet frame to bridge and route to a remote PC, which may be in the next building or across the country.体育英语
Bridges
First, let's address the bridge issue. Since the Magic Packet frame is a standard Ethernet frame, there is no reason a bridge would not forward it appropriately. The only difference between a Magic Packet frame and a standard Ethernet frame is the 16 duplications of the 6-byte IEEE address, which is carried in the data portion of the frame. The bridge does not even care what is in the data portion of a frame, it only cares about the des-tination address. The question has also been asked “what happens if a bridge has deleted the address of the end node the Magic Packet frame is destined for from the bridge address databa? Will the bridge just throw the frame away?” The answer is no. If a bridge does not know on which port a specific address is lo-cated, the bridge must forward the frame to all ports. This will guarantee that the node, which the frame has been addresd to, will receive it.
ejeRouters
Next we will focus on the routers in a network. Many networks are parated by routers; a router is a
网恋如何聊天lmost always ud to connect a LAN in one building to a LAN in another building. Routers are ud to gment the LAN and reduce the number of nodes, as well as the number of broadcast messages, on each gment of the LAN. Again, as above with the bridge, since the Magic Packet frame is just a simple Ethernet frame with a specific data pattern in the data field, there should be no reason why a router would not route the frame like any other. And since the Magic Packet frame is protocol independent, it does not matter what protocol the LAN is running, whether it be TCP/IP, IPX, or any other. As long as the data portion of the frame arrives intact at the destination, it will wake up the target machine. Address Aging in Routes
A significant problem prented itlf while the infra-structure discussions were going on. This centers on the aging of ARP (address resolution protocol) tables in routers, as oppod to bridges. In a bridge, when an address has been eliminated from the databa, the in-coming frame would be nt to all ports on the bridge. Again, this is in the definition of a bridge. In a router, however, when a frame is received who address is not in the databa, the router will nd an ARP out onto the network looking for a respon from the node that the frame was addresd to. If the machine is in Magic Packet mode, it will not respond to this ARP and the router will just throw the frame away. Obviously, this would negate the ability to remotely wake up a sleeping PC over a routed network.
However, a method of solving the above problem was prented by IBM engineers, who had been looking at the issue and came up with a novel approach to the problem. Instead of nding a normal frame to the tar-get machine, the program or system administrator would nd a “Subnet Directed Broadcast” to the router to forward to the subnet where the target machine was located. The following is a step-by-step process to as-sure the remote wake up of a station beyond a router. In this scenario, let's assume that the two networks in u are parated by two routers, Router 1 and Router 2. The local subnets of the respective rout-ers are described as sub-net A and Subnet B, respec-tively. Below is an illustration of this hypothetical network for reference. The following diagram will u IP internet as an example:
The Manager who wants to wake up the remote station nds an IP subnet-directed broadcast UDP datagram addresd to the subnet containing the Station. This scenario forces the wake-up packet to be nt out on Subnet B (by Router 2) with a broadcast MAC address.
1.Manager queues wake-up UDP datagram with des-
tination IP address as a subnet-directed broadcast for the subnet of the target station.
in the past2.The IP stack in the Manager nds the frame to the
MAC destination address of Router 1.
3.The UDP datagram is eventually forwarded to
加油的英文Router 2 bad on the network address portion of the IP header in the wake-up UDP datagram
4.Router 2 receives the wake-up UDP datagram, real-
izes that the packet is at the right destination net-work, and recognizes that it is a subnet-directed broadcast packet.
5.Router 2 nds the IP subnet-directed broadcast
wake-up UDP datagram to the MAC broadcast address.
6.The target station recognizes the broadcast frame as
a Magic Packet frame by matching the 16 repeated
address and triggers the wake-up signal from the Ethernet controller.
7.The target station is now awake!Although slightly more complicated than the first con-ceptual u of the Magic Packet T echnology, the ability to ensure the remote wake up of targeted systems across a routed network is key to the u of this tech-nology. This can ensure the ability to u the broad ranging Internet with TCP/IP to wake up any station in the world, as long as the routers will pass on directed subnet broadcasts.
PC System Design Implications
Adding Magic Packet T echnology support to an existing system or a newly designed system can be either sim-ple or complicated, depending on the design and the architecture of the system. Below are some issues which must be addresd for the Magic Packet Tech-nology support to work properly.
Maintain Ethernet Power
The power to the Ethernet controller must be main-tained at all times, allowing the Ethernet controller to scan all incoming packets for the Magic Packet frame. Add Support to Power Management Circuitry
In a normal system, the power management circuitry looks for any one of veral events to wake up the sys-tem. Events such as keyboard entries or mou move-ment that would cau the system to wake up. To u Magic Packet Technology, the power management must include a Magic Packet frame received as a con-dition to wake up the system.
Enable/Disable Magic Packet Mode
The system must have a mechanism to enable and dis-able the Magic Packet mode of operation in the Ethernet controller. This can be done in hardware or software, and is obviously dependent on the Ethernet controller ud. When the system goes into the low power mode, the Magic Packet mode must be enabled, and when the sys-tem exits low power mode, either after receiving a Magic Packet frame or some other event, such as a keyboard entry, Magic Packet mode must be disabled.
Sleep Mode Power Consumption
The issue of power consumption in PCs is increasingly important, not only to the government, through the En-ergy Star program being implemented by the EP A, but also to the MIS managers of major corporations. The managers can easily e an immediate cost savings by the reduction in electricity bills by moving to power managed PCs.
However, there are two thoughts on how to best put a computer into a power down state. The first is to put the PC into what is called a STANDBY mode of oper-ation. In this mode, the computer is actually alive and kicking, with power to the entire motherboard. The low power consumption in this mode is accomplished by slowing down the processor clock, spinning down the hard drives, and putting the monitor in a low power
myfamily
consumption state. There is, however, a limit to the amount of power that can be saved through the STANDBY mode. This may, in fact, become more ap-parent as larger processors and significantly larger DRAM arrays draw more power, regardless of the clock frequency the system is running.
thpa
The cond method, and the one which can be ud with Magic Packet T echnology, is to put the system into what is typically known as a SUSPEND mode. In the SUSPEND mode, the system is us
ually brought to a complete halt. The CPU is stopped, and may even have the power removed from it, although few if any systems do this currently. The entire system board may be pow-ered down, leaving only the power management circuitry powered up, to detect some sort of activity which would indicate that the system should be powered up. In this scenario, the Ethernet controller would also be powered up, receiving frames off the network looking for a Magic Packet frame, which would indicate to the power man-agement that the system should be awakened. CONCLUSION
In this white paper I have identified some of the issues involving the sleeping Green PC and how it works on a network, and the u of the Magic Packet Technology to allow the PC to go into an extremely low power state and still be manageable by the network administrator. The respons AMD has been receiving from the Magic Packet Technology proposal have been very positive, with many major system developers and add-in card vendors expressing interest in the technology. By adopting the Magic Packet Technology as an indus-try standard mechanism to allow the remote wake up of sleeping PCs, the vendors are furthering the goal of reducing the power consumption of non-operating PCs to as low as possible.
AMD believes that the Magic Packet Technology will play an important part in the manageability of net-worked PCs, particularly in the corporate LAN environ-ment, where end node management is gai
ning strategic importance. AMD is working with many ven-dors of PCs, Network Interface Cards, and software to assure the standardization and interoperability of this technology.
