Guidelines for products that work well with the Microsoft® Windows® xp and Windows Server 2003 operating systems

səhifə	17/22
tarix	18.07.2016
ölçüsü	0.89 Mb.

1 ... 14 15 16 17 18 19 20 21 22

B7.0 Network Devices

Requirements for network components designed for servers running Windows Datacenter Server, including LAN and wide area network (WAN) server network adapters, are not provided in this appendix, which focuses solely on components for desktop and mobile client PCs and servers running Windows Server 2003, Standard or Enterprise Edition.

B7.1 General Network

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.

B7.1.1 General Network - Windows Compatibility

B7.1.1.1 NDIS 5.0 miniport driver model: "Network Devices and Protocols" in the Windows DDK

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 5.0 miniport driver model defined in the Windows DDK.

Important: The development of full media access control (MAC) drivers is no longer supported.

If the network device is for connection-oriented media, such as 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. Also, for connection-oriented media, there must be an NDIS 5.0 call manager driver as defined in the Windows DDK.

In some cases, the call manager driver is included in the operating system. Consequently, the vendor needs to provide only an NDIS 5.0 connection-oriented miniport driver. For connection-oriented media such as ISDN or X.25, the vendor must provide a call manager driver with the hardware, because the call manager is not included in the operating system. Call manager support can be integrated in the connection-oriented miniport driver or implemented as a separate NDIS 5.0 call manager driver. Documentation for both integrated and separated call managers is included in the Windows DDK.

An NDIS 5.0 miniport driver is required for network adapters that connect to the PC using external buses such as USB. This driver exposes its media type to NDIS 5.0 at its upper edge, and it interfaces with the appropriate bus driver at its lower edge.

B7.1.1.2 Drivers for connection-oriented media (ATM, ISDN): “Connection-Oriented NDIS" in the Windows DDK

NDIS 5.0 CoNDIS miniports are preferred, but NDIS 4 WAN miniports are acceptable.

B7.1.1.3 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdevtech/network/

Note: This is a general reference, not a requirement.

B7.1.1.4 NDIS 5.0 driver uses network class INF format as defined in the Windows DDK

"Creating Network INF Files" in the Windows DDK

B7.1.1.5 DELETED

B7.1.2 General Network - Industry Standards

Note: This list provides complete titles and web locations for references cited. The listing of a reference here does not imply that complete compliance with that reference is a Windows Logo Program requirement.

B7.1.2.1 Network Device Class Power Management Reference Specification, V. 2.0

http://www.microsoft.com/hwdev/resources/specs/pmref/PMnetwork.asp

B7.1.2.2 Home Phoneline Networking Alliance (HomePNA) 2.0 specification or later

http://www.homepna.org

B7.1.2.3 PCI Bus Power Management Interface Specification, Revision 1.1 or later

See B2.5.2.1
http://www.pcisig.com/

B7.1.2.4 USB Communications Class Device 1.1 or later

See B2.6.2.2
http://www.usb.org/developers/devclass.html

B7.1.3 General Network - Quality

WHQL Test Specification References:
Chapter 23: Network Adapter Test Specification

B7.1.3.1 Pass WHQL tests

See “Network Devices” in the HCT documentation.

B7.1.3.2; B7.1.3.3; B7.1.3.4; B7.1.3.5; B7.1.3.6 - See B7.1.3.1

B7.1.4 General Network - Windows Experiences

B7.1.4.1 - See B7.1.1.4

B7.1.3.1.1 Adapter automatically senses presence of functional network connection.

See B7.1.1.1 for updated Media Sense requirements.

B7.1.3.1.2 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 unless detection is not possible with the network media available. 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.

B7.1.3.1.3 Adapter can transmit packets from buffers aligned on any boundary.

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 must be received into contiguous buffers on a double word boundary.

B7.1.3.1.4 Adapter communicates with driver across any bridge.

All communications must be free of errors across any bridge, such as a PCI bridge adapter.

B7.1.3.1.6 Adapter supports filtering for at least 32 multicast addresses.

The None, Directed and Broadcast packet filters are required for all devices. For multicast and all multicast filters:

Include support for 32 multicast addresses
Perfect filtering is not required

This is required for all devices, except it is only required for DSL and cable modem devices if the feature is implemented.

B7.1.3.1.7 Adapter and driver support multicast modes.

This is required for all devices, except it is only required for DSL and cable modem devices if the feature is implemented.

Adapter and driver support all multicast modes. The miniport driver supports all filter types within the DDK.

Notice that, by default, multicast promiscuous mode is not turned on.

B7.1.3.1.8Driver makes only NDIS library calls or WDM system calls.

B7.1.3.3 PCI network adapters are bus masters.

To improve the system performance by decreasing the load on the system processor, the PCI network adapters must be bus masters.

Note: CardBus and Mini-PCI implementations do not need to be bus masters.

B7.1.4.2 Any included diagnostics or utilities work and can be accessed from the Network Connections Properties page.

B7.1.4.12.2 Network adapter supports configuration capabilities and registry settings for performance tuning.

See B7.1.4.2 for requirements related to NDI parameters and the Properties page DLL.

B7.1.4.3 DELETED

B7.1.4.4 Devices that support WOL correctly wake from D3

B7.1.4.4.1 IEEE 802.3 devices support for Wake on LAN from D3 using Pattern Match and Magic Packet

B7.1.4.4.2 WOL is not implemented for PC Card/CardBus devices.

B7.1.4.4.3 USB network devices do not support WOL while on bus power.

External networking devices using USB are not required to support Wake on LAN while operating on bus power.

B7.1.4.4.4 Wireless devices and network devices on mobile PCs are not required to support WOL.

No wireless network connection is required to support Wake on LAN.

Mobile PC Note
For mobile PCs, network device wakeup is not required.

B7.1.4.4.5 Support for power state D3 is required for all devices that support Wake on LAN.

For all devices other than IEEE 802.3, support must comply with Network Device Class Power Management Reference Specification if implemented.

The Network Device Class Power Management Reference Specification, Version 2.0, provides definitions of the OnNow device power states (D0–D3) for network adapters. The specification also covers the device functionality expected in each power state and the possible wakeup event definitions for the class.

Network communications devices that directly attach to the PC over a bus that is power managed such as USB or PCI, must comply with this specification.

Note: Network Device Class Power Management Reference Specification does not yet define wakeup mechanisms for ISDN adapters or any network communications adapter that uses ATM signaling, including ADSL.

B7.1.4.4.6 If power states are implemented, comply with Network Device Class Power Management Reference Specification, with exceptions.

Correct support for states D0 – D3 is required if implemented for all other devices, except those that have more than two PHYs or that implement a Fiber PHY.

B7.1.4.5 Remote boot and remote install options for connection-less LAN devices on PCI bus

Remote boot support is defined in the Preboot Execution Environment (PXE) Specification, Version 2.1. This support may either be included on the adapter, in the system BIOS, or the support may be split between the adapter and the BIOS.

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 PXE 2.1 or later (for IA-32 systems), or EFI 1.0 (for Itanium-based systems). 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.

Client system: Network adapters with PXE support must be available as an option at point of purchase for systems preinstalled with Windows XP Professional. See A1.1.4.

Server system: Server systems must provide PXE-based support if a network adapter with remote new system setup capabilities is provided with the system.

This is not a requirement for CardBus adapters or for Mini-PCI adapters that are not sold as a part of or with a PC system.

B7.1.4.6 HomePNA technology, if implemented, complies with HomePNA 1.0 or later, with NDIS 5.0 miniport driver

If implemented, a network adapter that implements HomePNA technology must comply with the Home Phoneline Networking Alliance Spec, Version 1.0.

B7.1.4.7 Infrared device supports both fast IR and serial IR, and unattended driver installation requirements

All infrared devices must comply with approved IrDA specifications, including support for SIR, FIR, and optional Very Fast IR (VFIR) data devices.

FIR Plug and Play hardware must report a unique Plug and Play ID that matches the combination of the chip set, transceiver, and any other system-specific parameters for the operating system to find and install the correct INF file and the associated driver for the IrDA hardware.

In the best case, the IrDA hardware has only one Plug and Play ID associated INF file and a miniport driver that can autodetect the transceiver type and other system-specific parameters. This combination enables the installation and configuration of the hardware and the driver without user intervention.

In other cases, for example, where the miniport driver cannot autodetect the transceiver type or any other system-specific parameters, a unique Plug and Play ID for each combination of the chip set and the transceiver type must be reported. Also, the vendor must provide for each combination an associated driver and INF file describing the configuration parameters.

B7.1.4.8 Full-duplex adapter automatically detects and switches to full duplex mode

If both the network adapter and switch port in a link pair support full duplex and there exists a standard way for each to detect and negotiate the duplex mode, the network adapter must negotiate full-duplex mode operation by default. Half-duplex mode can be used if that is the only mode supported by one or both link partners, or it can be manually configured if warranted by special conditions. The goal is to configure this setting automatically without end-user intervention.

B7.1.4.9 Plug and Play capabilities support multiple adapters; all resource settings are reported in the UI

For network communications devices, the Plug and Play IDs and resource support must be sufficient to allow the automatic addition of multiple network communications devices to the system.

All resource settings must be viewable in the Device Manager and in the adapter properties dialog boxes. All resource settings that can be changed by the user must be changed using the standard Windows user interface, not through the use of INI files or other setting files.

This requirement implies that all device resources must be set and read through the standard interfaces provided by the bus on which the device resides. For PCI devices, this interface is the PCI configuration space. Also, device parameter settings must be stored in the registry.

B7.1.4.10 Wireless networking requirements

B7.1.4.10.1 Wireless network media adapters must meet all requirements for network adapters except where noted.

B7.1.4.10.2 IEEE 802.11 wireless networking adapters support 11 Mb/s signaling using Direct Sequence Spread Spectrum.

B7.1.4.10.3 Bluetooth Host Controllers (HCI)

Windows uses Bluetooth Wireless technology as a wireless local bus and cable replacement. Therefore, Bluetooth HCI (radios with PC interface) do not need NDIS miniports. Requirements for Bluetooth HCI are listed in B2.3.4.5.

B7.1.4.10.3 Wireless networking media adapters support wireless extensions to NDIS

Wireless extensions to NDIS are documented in “Network-Dependent Wireless Objects” in Network Drivers in the Windows DDK. These extensions are based on the work of the Portable Computer and Communications Association.

B7.1.4.10.4 Wireless network media adapters must meet all requirements for network adapters

IEEE 802.11 devices must support the appropriate OIDs.

IEEE 802.11 devices must be compatible with Wi-Fi

Information on Wi-Fi can be found at http://www.wi-fi.org

Flash based firmware drivers must update without user intervention.

B7.1.3.6 IEEE 802.x network adapter and driver that implement QoS support priority for IEEE 802-style networks.

Windows Quality of Service (QOS) components 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 Internet Engineering Task Force (IETF) Integrated Services (IntServ, RFC 1663) service typed to IEEE 802.1p priority values, referred to as the user priority object. Current IETF references include:

The Subnet Bandwidth Manager.
Framework for integrated services over 802 networks.
Mapping integrated services to 802.1p.

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. Driver support for link layer priority information must adhere to IEEE 802.lp priority values.

IEEE 802.1p/q-capable Ethernet drivers must use the priority level indicated in the NDIS_PER_PACKET_INFO structure to generate the corresponding field in the IEEE 802.1p/q MAC headers of transmitted packets. Similarly, these drivers must extract the appropriate information from the MAC headers of received packets and copy the priority to the NDIS_PER_PACKET_INFO structure before indicating the packet to higher protocol layers.

Notice that any link layer driver has the ability to 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 DDK and “QOS: Assigning Priority in IEEE 802-style Networks.”

See also “QoS: Assigning Priority in IEEE 802-style Networks,” available at http://www.microsoft.com/hwdev/tech/network/qos/qos.asp

B7.1.4.11 External networking devices support standard control interfaces as applicable

B7.1.4.11.1 All external USB networking devices support USB Communications Class Device 1.1 or higher.

B7.1.4.11.2 NDIS 5.0 (WDM layered) miniport driver required for USB-connected network adapters

B7.1.4.12 Windows Server 2003, Standard Edition: Additional adapter and driver support

B7.1.4.12.1 NDIS 5.0 miniport driver supports high-performance send and receive calls.

NDIS drivers for server-side network adapters must support the higher performance send (NdisSendPackets) and receive (NdisMIndicateReceivePacket) calls as documented in the Windows DDK.

B7.1.4.12.2 - See B7.1.4.2

B7.1.4.12.3 DELETED

B7.1.4.12.4 If the network device is for connection-oriented media, it must meet connection-oriented miniport driver and call manager driver requirements.

See the Network Drivers section of the Windows DDK for more information related to this requirement.

B7.1.5 General Network - FAQs

B7.1.5.1 Current Network Device FAQs

See http://www.microsoft.com/winlogo/hardware/.

B7.1.5.2 NDIS status codes and indication mechanisms

See NdisMIndicateStatus in the Windows DDK.

B7.1.5.3 DELETED

Related A1.1.6 deleted.

B7.1.R General Network - Future Requirements

Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/hardware/.

B7.2 Cable Modem

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general network device requirements in B7.1 are included by reference, except for requirements specific to connection-less or LAN devices.

B7.2.1 Cable Modem - Windows Compatibility

B7.2.1.1 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/tech/network/cable/

This is a general reference, not a requirement.

B7.2.2 Cable Modem - Industry Standards

B7.2.2.1 Cablelabs DOCSIS Data-Over-Cable Service Interface Specifications

http://www.cablemodem.com/

B7.2.3 Cable Modem - Quality

B7.2.3.1 Pass WHQL tests - See B1.3.

See “Cable Modem” in HCT documentation.

B7.2.4 Cable Modem - Windows Experiences

B7.2.4.1 DELETED

B7.2.4.2 Integrated cable modem meets Windows Logo Program network adapter requirements

An integrated cable modem exposing an Ethernet interface to the Windows operating system must meet Windows Logo Program network adapter requirements except as noted.

B7.2.4.3 Integrated cable modem exposes an ATM or Ethernet interface to the operating system.

B7.2.5 Cable Modem - FAQs

See B7.1.5.

B7.2.R Cable Modem - Future Requirements

See B7.1.R.

B7.3 DSL Device

B7.3.1 DSL Device - Windows Compatibility

B7.3.1.1 Windows compatibility and implementation notes

http://www.microsoft.com/hwdev/tech/network/dsl/default.asp

This is a general reference, not a requirement.

B7.3.1.2 External DSL Modems Design Guidelines

http://www.microsoft.com/hwdev/tech/network/dsl/extDSLmodems.asp

This is a general reference, not a requirement.

B7.3.2 DSL Device - Industry Standards

B7.3.2.1 An Interoperable End-to-End Broadband Service Architecture over ADSL System

http://www.microsoft.com/hwdev/tech/network/dsl/default.asp

B7.3.2.2 ATM User-Network Interface Specification, V. 3.1

http://www.atmforum.com

B7.3.2.3 DSL modem industry standards

Integrated ADSL modems exposing an Ethernet interface must meet requirement for, “Adapter supports filtering for multicast addresses.”

B7.3.2.3.1 ITU-T G.994.1, G.991.1, G.992.2.

B7.3.2.3.2 T1.413 Issue 2 (G.992.1).

ITU-T G.994.1, Handshake procedures for digital subscriber line (DSL) transceivers, is the international standard that defines mechanisms to allow DSL transceivers to exchange capabilities and to select a common mode of operation. G.994.1 supports modulation standards G.991.1 High bit-rate Digital Subscriber Line (HDSL), G.992.1 (full-rate discrete multitone [DMT] ADSL), G.992.2 (“G.lite” DMT ADSL), T1.413 Issue 2 (ANSI full-rate ADSL), and T1 TR-59 (CAP/QAM).

Use of G.994.1 allows the customer premises and central office DSL modems to negotiate a common mode of operation, and more importantly, identifies the cause of failure when the link is not established due to the incompatible modes of operation of the two modems.

B7.3.2.3.3 U.S. T1 Committee Technical Report TR-59.

U.S. T1 committee Technical Report TR-59, “Single-Carrier Rate Adaptive Digital Subscriber Line (RADSL),” is the industry consensus specification for CAP/QAM ADSL modems. ADSL modems that support CAP/QAM modulation must implement TR-59. CAP/QAM ADSL modems may also support other modulation methods such as DMT.

Note: TR-59 is not a U.S. ANSI standard for ADSL modems, but is supported by some network access providers.

CAP/QAM ADSL modems must support G.994.1; see B7.1.4.5

B7.3.3 DSL Device - Quality

B7.3.3.1 Pass WHQL tests - See B1.3.

See “DSL Devices” in HCT documentation.

B7.3.4 DSL Device - Windows Experiences

B7.3.4.1 All requirements in B7.1.3, except B7.1.3.4 (WOL and power management)

DSL simultaneous connections require support for 32 or more connections.

B7.3.4.2 Integrated ADSL modem meets Windows Logo Program network adapter requirements

An integrated ADSL modem exposing an Ethernet interface must also meet the requirements to support filtering for at least 32 multicast addresses.

B7.3.5 DSL Device - FAQs

B7.3.5.1 - See B7.1.5

B7.3.5.2 – See B7.1.3

B7.3.R DSL Device - Future Requirements

See B7.1.R.

B7.4 ISDN Net Device

B7.4.1 ISDN Net Device - Windows Compatibility

See B7.1.1.

B7.4.2 ISDN Net Device - Industry Standards

See B7.1.2.

B7.4.3 ISDN Net Device - Quality

See “WAN ISDN Network Devices” in HCT documentation.

B7.4.4 ISDN Net Device - Windows Experiences

B7.4.4.1 Performance meets minimal expectations on high-end broadband network devices

If the ISDN device has an S/T-interface for connecting additional ISDN devices, it must also have software-configurable terminating resistors that can be selected on or off. The default value of the termination is on in North America, but off in all other countries, where phone companies unconditionally provide the termination.

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

B7.4.4.2 Device meets Windows Logo network adapter requirements

B7.4.4.3 Device supports synchronous high-level data link control framing

High-level Data Link Control (HDLC) framing is a standard for sending synchronous data. Other framing methods are allowed if the miniport driver provides simple HDLC-framed, synchronous PPP packets to NDIS.

B7.4.4.4 NDIS interface and driver support raw, unframed synchronous B channel I/O

The internal ISDN device and the driver must support raw, unframed (non-HDLC) synchronous B channel I/O at 64 Kbps per B channel, with each B channel individually accessible. This support enables H.320 as well as voice calls over ISDN without audio breakup.

For these raw interfaces, the direct path to each B channel must support synchronous transmission and reception of H.221 frames, which are of 20 ms duration. Since underruns or overruns cause degraded audio, hardware buffering must be adequate to prevent B channel underruns and overruns.

This can be achieved by making buffering software configurable with adequate range to handle foreseeable real-world conditions. The miniport driver should make I/O completion callbacks to NDIS for each I/O buffer as soon as the I/O for that buffer is complete and should not coalesce or delay callbacks.

B7.4.4.5 ISDN Driver supports unattended installation, with limitations

Configuration of the dependent parameters, such as SPIDs and switch-type IDs, must be done through the ISDN configuration wizard included in the operating system.

B7.4.4.6 Device includes software-selectable terminating resistors

If the ISDN device has an S/T-interface for connecting additional ISDN devices and has configurable terminating resistors, they must be software configurable. The software selectable resistors can be selected on or off. The default value of termination is on in North America, but off in all countries where phone companies unconditionally provide the termination.

B7.4.4.7 ISDN modem supports asynchronous-to-synchronous conversion and RFC 1662

Because ISDN is a synchronous service and an ISDN modem connects t a logic asynchronous USB port on the PC, the device must provide
some means of converting asynchronous data to synchronous data. The asynchronous-to-synchronous conversion must support the requirements identified in RFC 1662.

These types of ISDN devices are treated as modems, not as internal ISDN devices supported using NDIS WAN miniports. In the external case, the primary implication is that the operating system will send byte-level PPP, also known as asynchronous PPP. In the NDIS WAN case, the implication is that the operating system will send bit-level PPP, also known as synchronous PPP.

Because ISDN is a synchronous service and an ISDN modem connects to an asynchronous port on the system, the device must provide some means of converting asynchronous data to synchronous data.

B7.4.4.8 ISDN modem supports required command set

An ISDN modem must support the following:

Basic AT commands such as TIA-602, which is a subset of ITU V.250
Commands to select the end-to-end protocol used over the ISDN, for example, synchronous point-to-point protocol (PPP), V.110, V.120.
Commands to set the switch type, subscriber numbers, or directory numbers
Service profile ID (SPID) or EndgerateAushlZiffer (EAZ) (where applicable) for user selection or if auto-detection fails, implemented in the device or in the communications driver

B7.4.5 ISDN Net Device - FAQs

See B7.1.5.

B7.4.R ISDN Net Device - Future Requirements

See B7.1.R.

B7.5 ATM Device

B7.5.1 DELETED

B7.5.2 DELETED

B7.5.3 DELETED

B7.5.3.1 DELETED

B7.5.3.2 DELETED

B7.5.4 DELETED

B7.5.4.1 DELETED

B7.5.4.2 DELETED

B7.5.4.3 DELETED

B7.5.4.4 DELETED

B7.5.4.4.1 DELETED

B7.5.4.4.3 DELETED

B7.5.4.4.5 DELETED

B7.5.4.4.6 DELETED

B7.5.4.4.7 DELETED

B7.5.5 DELETED

B7.5.R DELETED

1 ... 14 15 16 17 18 19 20 21 22