New support is provided in the Windows NT Server operating systems for ADSL adapters, which provide a faster method for moving data over regular phone lines. ADSL adapters are not required for any server type, but if an adapter is included in a server, it must meet the requirements in this section. ADSL is not required in a server system, but if present, it must comply with these requirements.
Please review the white paper, An Interoperable End-to-End Broadband Service Architecture over ADSL Systems, about end-to-end service interoperability over ADSL, jointly developed by leading ADSL vendors. This white paper can be found at http://www.microsoft.com/hwdev/devdes/publicnet.htm.
86 ADSL device meets network adapter requirements
The driver must support NDIS 5.0. It is also recommended that the manufacturer participate in developing standards for ADSL solutions.
87 ATM/ADSL solution is implemented
If an ATM/ADSL solution is implemented, please refer to ATM Adapter requirements earlier in this chapter for specific requirements.
88 ADSL device supports RADSL
On a rate adaptive digital subscriber line (RADSL), the downstream and upstream data rates are independently set either by an automatic adaptive algorithm or by manual selection.
RADSL provides the capability to optimize the transmission speed and performance over a wide range of telephone-line loop distances. Adaptive channel equalization ensures more robust performance in the presence of channel impairments and narrow-band interference.
This also helps telephone companies to provision RADSL access on their existing networks. RADSL products can be provisioned on many telephone lines without costly and time-consuming network upgrades.
ISDN Requirements
Under these guidelines, ISDN is recommended but not required for high-speed connections. If implemented in a server system, ISDN must meet the requirements defined in this section.
There are two classes of ISDN adapters: (1) serial port devices, supported by Unimodem with INFs, and (2) parallel bus devices, supported by NDIS WAN drivers.
In this section, “internal ISDN device” refers to the ISDN terminal adapter, which exposes raw access to its B channels using NDIS miniports. NDIS miniports could also be attached to the server using WDM-supported bus classes such as USB (thereby physically being an external device).
In this section, “ISDN modem” refers to an internal or external ISDN device that exposes itself as a modem controlled by the AT command set. Certain ISDN devices might be attached to the server internally or externally, exposing serial ports or modems to the system. To Windows operating systems, these devices look like modems, and the operating system can use these devices as modems, provided that the hardware manufacturer has done the work to ensure that these devices look and act like modems. This work includes the following:
Interpretation of the standard modem AT command set., either in the ISDN device itself or in a serial port driver. For more information, please refer to the TIA‑602 specification, a subset of ITU V.25ter.
A modem INF file for installing the device and for telling Unimodem which commands to use to control the ISDN device.
Serial ISDN Modems
The requirements in this section apply for a serial ISDN modem designed for or included with a server system that complies with Hardware Design Guide Version 1.0 for Windows NT Server.
ISDN modems share the following features:
ISDN Basic Rate interface (2B+D)
Serial AT command language, with proprietary ISDN extensions
ISDN modems also share the following differences from wireline PSTN modems:
User (or device) must configure for switch type and service profile ID (SPID)
Data only, in increments of one or two 64,000 bps B channels
Fax not available
V.42 and V.42bis usually not available
89 ISDN modem supports required command set
An ISDN modem must support basic AT commands (TIA‑602, which is a subset of ITU V.25ter). Also, commands must be included to set the switch type and SPID to allow user selection if auto-detection fails. This requirement can be implemented in the device or in the communications driver.
90 ISDN modem supports auto-SPID detection algorithms and standard SPID format
An ISDN modem must include commands or means to support software-based automatic switch type and SPID detection using the algorithms as defined by the National ISDN User’s Forum (NIUF) in 1997 Version of National ISDN Basic Rate Interface Terminal Equipment Generic Guidelines. This eliminates the need for the end user to enter the SPIDs.
An ISDN modem must include commands or means to support software-based automatic switch type and SPID detection using the algorithms defined by NIUF. This eliminates the need for the end user to enter the SPIDs and enhances the Plug and Play experience for users.
This requirement applies only in the United States.
91 ISDN modem supports CHAP in firmware if B channels are not exposed
Recommended: Support MS‑CHAP.
If the ISDN modem implements support for multilink PPP protocol, it must also support Challenge Handshake Authentication Protocol (CHAP). Supporting multilink PPP on an ISDN modem requires the devices to authenticate the second call themselves.
The remote access server uses CHAP to negotiate the most secure form of encrypted authentication supported by both server and client.
92 ISDN modem exposes both B channels
ISDN modems should expose both B channels so that they can support the multilink PPP stack.
External ISDN modems should be on a port fast enough to expose the full bandwidth of both B channels, that is, USB. Providing two separate COM-port cables is not an acceptable solution.
93 ISDN modem supports multilink PPP
Multilink PPP as defined in RFC 1717 combines several ISDN B channels to increase the bandwidth of PPP links.
Windows NT includes support for multilink PPP. When using ISDN modems that appear as modems to the operating system, multilink PPP should be implemented in the device. This is because Windows NT cannot see both B channels of the ISDN connection unless each B channel is exposed as a COM port.
See also the “ISDN modem supports CHAP in firmware if B channels are not exposed” requirement earlier in this section.
This recommendation is for ISDN modems only. Internal ISDN devices with NDIS WAN miniport drivers benefit from the built-in multilink support provided by the remote access services of the operating system. Therefore, they do not need to provide multilink PPP support.
94 ISDN modem supports asynchronous-to-synchronous conversion
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.
95 ISDN modem uses high-speed port
Because of speed limitations inherent in a server’s COM ports, the connection for ISDN modems should be high speed, such as USB.
96 ISDN modem driver supports switch detection
The driver can attempt to determine the switch type based on the directory number, or it can use other proprietary solutions to determine the switch type. This support enhances the Plug and Play experience for users.
97 ISDN modem driver supports unattended installation, with limitations
ISDN devices must be capable of being installed without user intervention. The exception is specific ISDN parameters, which must be acquired from the equipment being connected to. Dependent parameters include SPIDs and switch‑type IDs.
Parallel ISDN Devices
This section defines general requirements for ISDN and specific requirements for ISDN terminal adapters. The requirements in this section apply for serial ISDN modems designed for or included with a server system that complies with Hardware Design Guide Version 1.0 for Windows NT Server.
98 Internal ISDN device meets Hardware Design Guide network adapter requirements
The driver must support NDIS 5.0. Only NDIS 5.0 miniport drivers and INF files are allowed for complete user-friendly installation and operation of the ISDN adapter. The following requirements must be met, as defined in the section “Network Adapter Requirements” earlier in this chapter:
Support NDIS 5.0 using a miniport driver
Automatically sense whether a cable is connected
Support quadword buffer alignment or better
Communicate with a driver across any bridge
99 Internal ISDN device supports synchronous HDLC 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 NDISWAN using NDIS.
100 Internal ISDN device uses NDIS WAN miniport driver
The device must have an NDIS WAN miniport driver to support Windows remote access over ISDN. For information about NDIS status codes and indication mechanisms, see the Windows NT 5.0 DDK.
101 Internal ISDN device includes connection for analog phone
Adding an analog (POTS) port to the ISDN device delivers convenience to the SOHO market, allowing customers to use one ISDN line to meet all their telecommuting needs at minimal cost. Many customers in this market don’t want a separate analog phone line for their fax machines, modems, or phone when ISDN can do this with a device that has POTS support.
This recommendation applies only in the United States.
102 ISDN device supports auto-SPID detection algorithms and standard SPID format
ISDN drivers must support auto‑SPID detection algorithms as defined by NIUF in 1997 Version of National ISDN Basic Rate Interface Terminal Equipment Generic Guidelines. This capability eliminates the need for the end user to enter the SPIDs.
ISDN drivers also must support the standard SPID format, which is useful when auto‑SPID is not available.
This requirement applies only in the United States.
103 Driver for internal ISDN device supports switch detection
The driver can attempt to determine the switch type based on the directory number, or it can use other proprietary solutions to determine the switch type. This support enhances the Plug and Play experience for users.
104 Driver for ISDN internal device supports unattended installation, with limitations
ISDN devices must be capable of being installed without user intervention. The exception is specific ISDN parameters, which must be acquired from the equipment being connected to. Dependent parameters include SPIDs and switch‑type IDs.
Notice that it is a requirement for the device to support auto-SPID detection algorithms. If these algorithms are also supported on the equipment being connected to, only the switch type should have to be entered during installation of ISDN hardware if it cannot be detected automatically.
105 ISDN device includes built-in NT‑1
NT‑1 (network terminator) splits the duplexed transmit and receive signals from the ISDN line into separate transmit and receive components. An ISDN device with a built-in NT‑1 can connect directly to the ISDN line. However, doing so prevents other devices from being attached to the ISDN line (only one NT‑1 can be connected to an ISDN line).
This recommendation applies only in the United States.
Chapter 5
Basic Storage Device Requirements
This section summarizes the requirements for storage devices used with servers.
Tips for selecting high-performance storage components. For manufacturers who want to select high-performance components for server systems, the following are the design features to look for in storage components:
Controller supports bus mastering (which is a Hardware Design Guide Version 1.0 for Windows NT Server requirement).
Disks support reduced latency and fast rotational speeds.
Drivers are tuned for 32‑bit performance; that is, 32‑bit alignments on the adapter interface with no 16‑bit alignments on odd addresses.
Components do not use ISA.
Components rely on the SCSI controller.
SCSI differential devices must support DIFFSENS as described in SCSI‑3.
PCI burst mode reduces disk controller time spent on the PCI bus.
This section presents general requirements for controllers and peripherals.
Note: It is recognized that OEMs supply systems with specific feature requirements to corporations, which can include providing servers that do not include any disks installed before shipping to a particular corporate client. However, the system must include at least the minimum required configuration for testing.
106 Non-ISA host controllers and devices support bus mastering
The host controller must not use the ISA bus.
Bus master capabilities must meet the related specification for the particular controller.
An exemption exists for ISA-based, IDE-connected CD‑ROM devices that are used solely for the purpose of software installation on a server system. Such devices cannot be used for any other purpose, including access to data by client systems.
Note: This requirement does not apply to legacy FDCs and will not become a requirement for the FDC in the future.
107 Device supports Int 13h Extensions in system and option ROMs
The Int 13h Extensions ensure correct support for high-capacity drives. Support for the fixed-disk access subset of Int 13h Extensions must be provided in the system BIOS and in any option ROMs for storage devices that include BIOS support. For information about the Int 13h Extension APIs, see the Windows NT 5.0 DDK.
108 Hard drives meet minimum performance requirements
The minimum performance requirement is 20 to 40 MB per second parallel SCSI interface.
109 All rewritable ATAPI devices meet SFF 8070i requirements
The SFF 8070i specification defines the requirements for ATAPI rewritable devices (optical storage devices), including specifications for logical unit number (LUN) implementation, media status notification, and device write protection. This definition includes required support for the Read Format Capacities command.
110 External drive devices have key-locking capabilities
Recommended: Remote software management of physical components.
Each floppy drive, CD‑ROM drive, or optical storage device on a server system should be capable of being physically locked with a key to prevent unauthorized access.
111 Controller and peripherals support media status notification
The following list shows the required specifications for implementing media status notification, depending on device type.
Device type
|
Media status notification implementation
|
CD‑ROM and
DVD‑ROM
|
Required. Comply with all provisions in the Media Event Status Notification subsection of SFF 8090 (Mt. Fuji specification), available at ftp://fission.dt.wdc.com/pub/standards/SFF/specs/.
|
Other types of IDE/ATAPI removable storage devices
|
Required. Comply with Media Status Notification Support, Version 1.03 or higher, available at http://www.microsoft.com/hwdev/specs/.
|
ATAPI floppy drives
|
Required. Comply with media status notification as defined in SFF 8070.
|
Other ATAPI devices, including tape drives
|
Recommended. Comply with SFF 8090 (Mt. Fuji specification) if implemented.
|
Other types of SCSI removable devices
|
Not required. Comply with SFF 8090 (Mt. Fuji specification) if implemented.
|
Important: For CD‑ROM and DVD‑ROM devices, do not use Media Status Notification, Version 1.03 or earlier, as the guideline for implementing status notification on optical devices. This specification does not apply to optical storage devices because it does not contain packet-based support.
| 