This section describes the requirements for network adapters. Many of these requirements also apply to other network communications devices such as ISDN, cable modem, and ADSL. The section for each device category lists the applicable requirements for that device.
Note: It is recognized that OEMs supply server systems to corporations in situations where the customer will insert network adapters at the end-user site. Systems designed for specific corporate customers are exempt from including a network adapter. However, if a network adapter is included in the system, it must meet these requirements.
Also, references in this chapter to adapters, network interfaces and so on should be taken to apply equally to add-in network adapter cards, network implementations on the system motherboard, and external network interfaces, without preference for any of these types of implementation unless otherwise noted.
Required
An ISA-based network adapter solution is not allowed for a server system.
Required
The network adapter driver must be based on and comply with NDIS 5.0 in order to take advantage of new operating system capabilities. The driver must follow the NDIS miniport driver model defined in the Windows NT 5.0 DDK.
Important: The development of full MAC drivers is no longer supported. Support for full MAC drivers will be removed in the future versions of Windows.
If the network device is for connection-oriented media, such as Asynchronous Transfer Mode (ATM), ISDN, Frame Relay, or X.25, it must have a connection-oriented miniport driver that follows the connection-oriented model defined for NDIS 5.0 in the Windows NT 5.0 DDK. Also, for the connection-oriented media, there needs to be an NDIS 5.0 call manager driver as defined in the DDK.
In some cases, such as ATM, the call manager driver is included in the operating system and the vendor needs to provide only an NDIS 5.0 connection-oriented miniport driver. For other connection-oriented media, such as ISDN or X.25, the call manager is not included in the operating system and must be provided with the hardware. The call manager support can be integrated in the connection-oriented miniport driver or implemented as a separate NDIS 5.0 call manager driver. The documentation of both options, integrated or separated call manager, is included in the Windows NT 5.0 DDK.
An intermediate NDIS 5.0 miniport driver is required for network adapters that connect to the system using IEEE 1394 or USB buses. This driver exposes its media type to NDIS at its upper edge and interfaces with the appropriate bus driver, IEEE 1394 or USB, at its lower edge.
The NDIS 5.0 miniport driver must also meet these requirements:
For Windows NT 5.0, there will be no legacy INF support and no satisfactory upgrade option for OEM components created for Windows NT 4.0.
Required
NDIS drivers for server-side network adapters must support the new higher performance send (NdisSendPackets) and receive (NdisMIndicateReceivePacket) calls documented in the Windows NT 5.0 DDK.
Recommended
Server-side network adapters should support task-offload mechanisms to offload TCP/IP checksum calculation, IP Security encryption, and TCP message segmentation to intelligent hardware. This provides better utilization of computing resources on the server system. Mechanisms for off-loading these tasks are documented in the Windows NT 5.0 DDK NDIS documentation.
Required
The network adapter must negotiate full duplex operation by default when both the network adapter and switch port in a link pair support full duplex and the networking technology provides a standard way for each to detect and/or negotiate the duplex mode. Half duplex may be used if that is the only mode supported by one or both link partners or if it can be manually configured when warranted by special conditions. The goal is to configure this setting automatically without end-user intervention.
Required
Where the network media allows it, the network adapter must be capable of dynamically determining whether it is connected to a functional link partner such as a hub, switch, or router. The device must indicate the link state in the following cases:
If the adapter is on an expansion card not used as a boot device, then the device drivers can determine the presence of the functional link. If the device is not connected to a functional link partner, the miniport driver must provide appropriate NDIS status indication, using support for cable sense in NDIS 5.0.
For information about NDIS status codes and indication mechanisms, see the Windows NT 5.0 DDK.
Required
Network adapters that support multiple transceivers must be capable of automatically detecting which transceiver type is connected to the network unless this is not possible with the network media at hand. The network adapter then must automatically drive the correct connection. In all cases, the user must not be required to set jumpers or manually enter information to inform the operating system of the transceiver type.
Required
Buffer alignment refers to whether a buffer begins on an odd-byte, word, double word or other boundary. Adapters must be able to transmit packets any of whose fragments are on an odd-byte boundary.
For performance reasons, packets should be received into contiguous buffers on a double word boundary.
Required
If the adapter uses a bridge, all communications must be free of errors across any bridge, such as a PCI bridge adapter.
Required
This recommendation applies to those networking technologies that support multicast, such as Ethernet, but it does not apply to those which do not, such as Token Ring. Token Ring for example, distributes IP multicast traffic using the functional address, as specified in RFC 1469.
This capability is needed to support new “push” technology applications such as Microsoft NetShow™, Active Desktop, and Internet Explorer 4.0. The minimum required capability is for filtering 32 multicast addresses (also known as channels).
Required
Some network adapters and drivers might support additional configuration capabilities for performance tuning when used in special environments or applications. Any tuning parameters that are set by the user, an application, or the operating system must be controlled through registry variables.
An example of such performance optimizations might be adjustment of interrupt moderation or the number of receive buffers for systems used as dedicated routers.
In addition to Dynamic Interrupt Moderation, there are other techniques that may be implemented on network adapters to maximize system performance for special environments or applications.
User-tunable parameters must be set through registry variables as parameters for network adapters and must not be set in .INI files, configuration files, or in other locations. These parameters can be accessed using the Advanced Page in the Device Manager. The variables should be set through standard user interfaces provided in Windows.
Recommended
It is strongly recommended that server network adapters support remote new system setup capabilities as defined in Network PC System Design Guide, Version 1.0b or later.
Required
On server systems that support remote new system setup, network connections used for remote boot must comply with remote new system setup capabilities as described in Network PC System Design Guide, Version 1.0b or later. It must be possible to enable and disable the remote boot (remote new system setup) capabilities through administrative control in order to maintain server security.
Note: Multiport network adapters can supply remote system setup capabilities on none, any, or all ports.
Required
PCI commands are defined in the PCI 2.1 specification. This requirement ensures efficient data transfer.
Required
This ensures that the adapter can be used with Microsoft Network Monitor Agent. This requirement applies only to LAN (non-switched) media.
Notice that, by default, promiscuous mode is not turned on. Enabling promiscuous mode should be possible only by using the Microsoft Network Monitor Agent or another similar administrative application.
Required
By supporting this feature, the adapter and the driver enable performance improvements for special-purpose servers and applications, such as multicast routers. This requirement applies to those networking technologies that support multicast, such as Ethernet, and not to those which do not, such as Token Ring.
Notice that, by default, multicast promiscuous mode is not turned on.
Recommended
Windows Quality of Service (QoS) components will provide link layer priority information to NDIS 5.0 miniport drivers in each transmitted packet’s NDIS_PER_PACKET_INFO structure. Priority values are derived by mapping IETF Integrated Services (intserv) service types to 802.1p priority values (referred to as the “user priority” object in http://search.ietf.org/internet-drafts/draft-ietf-issll-is802-svc-mapping-01.txt, which is likely to be superceded by a later draft or final specification). The intserv service type used for the mapping is determined by QoS-aware applications or on behalf of the application, by QoS-aware operating system components.
802.1p/q-capable Ethernet drivers are expected to use the priority level indicated in the NDIS_PER_PACKET_INFO structure to generate the corresponding field in the 802.1p/q MAC headers of transmitted packets. Similarly, these drivers are expected to extract the appropriate information from the MAC headers of received packets and to copy the priority to the NDIS_PER_PACKET_INFO structure before indicating the packet to higher protocol layers.
Note that any link layer driver may interpret the priority information in the NDIS_PER_PACKET_INFO structure and use it as appropriate for the particular media.
For more information, see the Windows NT 5.0 DDK. See also the article “QoS: Assigning Priority in IEEE 802-style Networks,” available on the web at http://www.microsoft.com/devdes/qos802.htm.
Required
Any networking communications device designed as a Device Bay peripheral must interface with either USB, IEEE 1394, or both, and must support relevant USB device class specifications. All Device Bay peripherals must meet the requirements defined in Device Bay Interface Specification, Version 1.0 or later. See also requirement #16, “Device Bay controller and devices meet Device Bay 1.0 and other requirements.”
Required
To improve the system performance by decreasing the load on the system processor, the PCI network adapters must be bus masters.
Recommended
USB network communications device vendors should implement forthcoming networking extensions to the USB Class Definitions for Communications Devices.
Vendors are also encouraged to participate in the definition and implementation of both USB and IEEE 1394 working group efforts.
Required
The additional Plug and Play and power management requirements for network communications devices include the following:
This implies that all device resources must be set and read through the device’s standard bus interfaces. For PCI devices, this interface is the PCI configuration space. Further, device parameter settings must be stored in the registry.
Recommended
This requirement applies specifically to the following network communications devices and their associated NDIS 5.0 miniport drivers:
The Network Device Class Power Management Reference Specification, Version 1.0 or later, does not yet define wake-up mechanisms for ISDN adapters or any network communications adapter that uses ATM signaling.
The system must be capable of being awakened from a lower power state based on network events specified by the local networking software. This capability yields the result that any standard Windows network access—such as connections to shared drives and WinSock connections, plus service and management applications—can awaken a system from lower power states transparently.
As defined in Network Device Class Power Management Reference Specification, a network adapter and its driver must support wake-up on receipt of a network wake-up frame. Support for wake-up on detection of a change in the network link state or on receipt of a Magic Packet event is optional. Implementation details are described in the “Network Wake-up Frames” and “Network Wake-up Frame Details” sections of Network Device Class Power Management Reference Specification, Version 1.0a and in the Windows NT 5.0 DDK. See also the implementation notes at http://www.microsoft.com/hwdev/devdes/netpm.htm.
The packet patterns that define the wake-up frames are provided to the NDIS 5.0 miniport driver by the operating system. To enable Wake-On-LAN capability for basic networking scenarios, the network interface card must be capable of storing information describing a minimum of four wake-up packet patterns, and it must be able to recognize wake-up packets based on pattern matches anywhere in the first 128 bytes of the packet. The network adapters should be capable of storing information describing at least eight wake-up packet patterns to enable more advanced applications such as Wake-On-LAN capability on multi-homed systems or on receipt of multicast packets, in addition to the above basic scenarios.
PCI-based network adapters must support the generation of a power management event (PME# assertion) from the D3 cold device state if the physical layer technology is generally capable of operating under the voltage and current constraints of the D3 cold device state. For example, 100baseTX adapters can meet this requirement based on the state of the art in mid-1988. 1000baseSX or 1000base LX (gigabit Ethernet using optical fiber media) cannot meet this requirement because of the power required to operate the optical physical layer.