This section describes the requirements for network adapters.
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.
51 System includes non-ISA NDIS 5.0 network adapter
Recommended: For Ethernet, an integrated hub with five or more ports; snap‑on modules to extend the number of ports.
An ISA-based network adapter solution is not allowed for a server system.
52 Network adapter uses NDIS 5.0 miniport driver
For servers running on Windows NT 5.0, the network adapter driver must support NDIS 5.0 to take advantage of new operating system capabilities and must follow the NDIS miniport driver model. A full MAC implementation is not compliant with these guidelines.
If the device is a switched wide area network (WAN) card (for example, ISDN, X.25, or S56), it must have an NDIS WAN miniport driver that supports all Telephony Application Program Interface (TAPI) functions as defined for NDIS 5.0 in the Windows NT 5.0 DDK. It must support Windows remote access or other WAN services over WAN media.
For information about required driver support for the network adapter, see the Windows NT 5.0 DDK.
53 Full-duplex adapter automatically detects and switches to full-duplex mode
If the network adapter supports full-duplex mode and if the network switch to which the adapter is connected supports full-duplex mode and standard ways of detecting the duplex mode, the network adapter must be capable of detecting the duplex mode automatically and must use that mode. The goal is to configure this setting automatically without end-user intervention.
54 Adapter automatically senses presence of functional network
The network adapter must be capable of dynamically determining whether it is functionally connected to a link partner such as a hub, switch, or router. 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 not functionally connected to a link partner, the miniport driver must provide appropriate NDIS status indication, using support for cable sense in NDIS 5.0.
No time duration is specified for the required detection or status indication.
For information about NDIS status codes and indication mechanisms, see the Windows NT 5.0 DDK.
55 Adapter automatically senses transceiver type
Network adapters that support multiple transceivers must be capable of automatically detecting which transceiver type is connected to the network. The network adapter then must automatically use that transceiver. 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.
56 Adapter supports quadword buffer alignment for receive and byte buffer alignment for send
Recommended: Byte alignment for all buffers, which imposes fewer limitations on overlying software components.
Buffer alignment refers to the allowed offset addresses (boundaries) where packets can begin. Memory allocated for receive buffers must be quadword-aligned or better (byte-aligned or word-aligned). The send buffer must be capable of handling byte-aligned buffers.
The network adapter must impose minimal buffer-alignment restrictions.
57 Adapter communicates with driver across any bridge
If the adapter uses a bridge, all communications must be free of errors across any bridge, such as a PCI bridge adapter.
58 Adapter supports filtering for 32 multicast addresses, at minimum
Recommended: 128 addresses.
This capability is needed to support new “push” technology applications such as Microsoft NetShow™, Active Desktop, and Internet Explorer 4.0. This requirement specifies a minimum capability for filtering 32 multicast addresses (also known as channels). This number is expected to increase incrementally in coming years. Future requirements will specify filtering for a minimum of 128 addresses.
59 Adapter supports configuration capabilities for performance tuning, with all settings stored in the registry
Dynamic interrupt moderation samples incoming work and accordingly adjusts interrupts per second sent to the processor. This allows for batched processing of highly frequent interrupts. Such sampling algorithms take an initial sampling period to adjust the system load; in very bursty traffic situations, the period required to intelligently adjust the system load can cause a situation where the algorithm is constantly adjusting itself. This situation can be addressed by using fixed interrupt moderation, which can preset the interrupt rate on a per-system basis.
Under most circumstances, dynamic interrupt moderation (the default) is the best solution for performance. Only under special circumstances will Fixed Interrupt Moderation be appropriate, such as in a dedicated router, a highly used router, or other systems that often experience highly bursty traffic.
To support performance tuning and optimization for special applications, such as routing, the network adapter must have a configurable number of receive buffers and a configurable level of interrupt moderation. In order for network administrators to optimize the performance of a system used for routing, the two resources—Receive Buffer Count and Fixed/Dynamic Interrupt Moderation—must be configurable and controllable using registry settings on a Windows NT Server system. The proper path and registry settings for each are as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class
\\
FixedIntMod=5000 (DWORD) /This is a value that must be added.
/Number of interrupts per second.
/Note that this is decimal.
RxBuffers=200 (DWORD) /This also is a value that must be added.
/Number of receive buffers.
/Note that this is decimal.
The default configuration for each adapter should be set to 100–200 for receive buffers and to select Dynamic Interrupt Moderation.
60 Adapter is compatible with remote new system setup capabilities, if used as boot device
For a server system that uses a network adapter to support installing the operating system, the network adapter must be compatible with remote new system setup capabilities as defined in the open industry-standard DHCP. The DHCP provides for dynamic configuration of servers on TCP/IP networks, as specified in Internet Engineering Task Force (IETF) RFCs 1533, 1534, 1541, and 1542. Trivial File Transfer Protocol (TFTP), Revision 2, supports boot‑image download, as specified in IETF RFC 1530.
The complete mechanism for remote new system setup is defined in the attachments to Network PC System Design Guidelines, Version 1.0b or higher.
For a network adapter used as the boot device, remote management capabilities are recommended for all server systems. If implemented, there must be a way for this capability to be enabled and disabled by way of administrative control in order to maintain server security.
61 PCI network adapter properly supports higher-level PCI commands
PCI commands are defined in the PCI 2.1 specification. This requirement ensures efficient data transfer.
62 Driver supports promiscuous mode
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. Configuring promiscuous mode should be possible only by using the Microsoft Network Monitor Agent or another similar administrative application.
63 Driver works correctly with Microsoft network clients and protocols
This requirement includes the 32‑bit Microsoft client and NetWare-compatible clients provided with Windows, whether connected to a Windows NT–based server, a Novell NetWare 3.x or 4.x server, or a Windows‑based peer server.
In all cases, this requirement includes connections using Microsoft TCP/IP, IPX/SPX-compatible protocol, and NetBEUI.
64 NDIS miniport driver does not make Windows NT–specific kernel calls
A miniport driver that follows the NDIS 5.0 specification must not make Windows NT–specific calls. A correct driver makes calls only to the NDIS library. The NDIS library provides all the functions a driver needs or should use.
NDIS conformance must be validated over a single network connection and multiple connections. For Windows NT, this must be validated on a multiprocessor system as part of compliance testing for these guidelines.
65 NDIS 5.0 driver uses new INF format
For NDIS 5.0 drivers (which are required for Windows NT 5.0), all network components must use the new-style INF format, which is based on the Windows 95 INF format. For information, see the Windows NT 5.0 DDK.
Note: 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.
|
