NDIS Driver Types

NDIS drivers allow the transport protocols to communicate with the hardware layer. These drivers can be implemented in different configurations, described in the following sections.

Intermediate Drivers

The intermediate driver are found just below the transport protocols and above the miniport drivers in the network protocol stack. There are two types of intermediate drivers that are used: the LAN Emulation Intermediate driver and the Filter driver.

LAN Emulation Intermediate Driver

The LAN Emulation Intermediate Driver translates packets from the overlying connectionless transport's local area network (LAN) format to the connection-oriented format (such as ATM) below. Therefore, the transport protocols appear to communicate with a LAN network adapter (Ethernet) but in reality they are communicating with a different hardware device. The LAN Emulation Intermediate driver translates the packets coming and going to the protocol layer above. It converts these packets into packets that can be sent over a different medium. Figure B.4 illustrates the LAN Emulation Intermediate driver architecture.

Figure B.4 LAN Emulation Intermediate Driver

Currently, the only supported application for this driver is LAN Emulation for ATM. However, this driver configuration can be used for other types of "new media" in future configurations.

For more information about NDIS, see the Platform Software Development Kit (SDK).

Filter Driver

Filter drivers perform special operations (such as compression, encryption and tracing) on packets being transported through them. Figure B.5 shows the filter driver architecture.

Figure B.5 The Filter Driver

As packets are transported through the filter driver, compression and encryption can be performed. Several services utilize this type of intermediate driver, such as the packet scheduler in Quality of Service (QoS) and Network Load Balancing .

Miniport Drivers

A miniport driver is a driver that connects hardware devices to the protocol stack. The miniport driver is connected to an intermediate or protocol driver and a hardware device. A miniport driver handles the hardware-specific operations necessary to manage a network adapter or other hardware device. They implement sending and receiving data on the network adapter. Microsoft produces some intermediate drivers for Windows 2000. This is helpful to hardware manufacturers because it is not necessary for them to implement added functionality. To add additional functionality, hardware vendors can also create intermediate drivers. In this chapter, miniport drivers are also referred to as miniports.

Windows Driver Model (WDM) is a specification for device drivers. WDM makes device drivers compatible between Windows 2000 and Microsoft® Windows® 98. To help reduce the effort necessary for hardware vendors to support all Windows platforms, WDM enables devices designed for either Windows 2000 or Windows 98 to be installed and used with computers running under either operating system. WDM developers write smaller code pieces (miniports) that talk to their hardware directly and call the appropriate class driver to do the bulk of the common tasks.

Miniport drivers can be serialized or deserialized. Serialized drivers rely on NDIS to sequence calls to miniport functions and to manage send queues. Deserialized miniport drivers on multiprocessor systems can perform faster by serializing access to their internal data structures rather than by allowing NDIS to perform this function. They also queue all incoming send packets rather than using NDIS. This can result in a better full duplex performance. However, deserialized miniport drivers are more difficult to design and require more testing and debugging.

Common Miniport Drivers

The most common miniport drivers are:

• Connectionless miniport drivers

• NDISWAN miniport drivers

• Non-NDIS Lower Interface miniport drivers

• Connection-oriented miniport drivers

Connectionless Miniport Drivers

Connectionless miniport drivers control network adapters for connectionless network media such as Ethernet, FDDI, and Token Ring.

Figure B.6 shows the architecture of connectionless miniport drivers.

Figure B.6 Connectionless Miniport Driver Architecture

The most common use of connectionless miniports is for LAN-based network adapters. Network mediums such as Ethernet, Token Ring and FDDI do not support connection-oriented communications. Packets are sent to or received from a destination without any existing connection.

NDISWAN Miniport Drivers

There are many types of NDISWAN miniports. NDISWAN miniports are used with ISDN, Frame Relay and X.25 to provide dial-up networking. Ndiswan.sys is a Microsoft driver that provides Point-to-Point Protocol (PPP encapsulation), compression, and encryption. Ndiswan.sys communicates with the Routing and Remote Access service.

Figure B.7 illustrates the NDISWAN miniport driver architecture and usage.

Figure B.7 NDISWAN Miniport Driver Architecture and Usage

Figure B.7 shows an example of NDISWAN usage. The numbered arrows show the steps for the Routing and Remote Access service to set up a PPP session using an NDISWAN miniport driver.

1. The Routing and Remote Access service initiates a connection by passing information down through the TAPI components, (kmddsp.tsp, NDIS TAPI) to the WAN miniport driver (NDISWAN).

2. A reply is passed back to the Routing and Remote Access service to inform it that a connection is established by the same path. All components are made aware that the call attempt was completed.

3. The RAS Manager negotiates the characteristics of the PPP connection. This includes compression protocols and frame types.

4. Ndiswan.sys creates a virtual circuit for the appropriate protocol.

5. Data is both sent and received through the connection that has been established by Ndiswan.sys.

Non-NDIS Lower Interface Miniport Driver

A Non-NDIS lower interface driver is a connection-oriented miniport driver that interfaces to network protocols on the top, but on the bottom can interface to devices, such as Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 1394 devices. Figure B.8 shows the Non-NDIS miniport driver architecture.

Figure B.8 Non-NDIS Miniport Driver Architecture

Connection-Oriented Miniports

The connection-oriented miniport transports data on a particular connection rather than to a particular destination. It is a new NDIS driver architecture. Connection-oriented miniports differ from connectionless miniports because a connection must be established between two points before data can be exchanged. Connection-oriented miniports support media such as ATM.

Certain applications rely on connection-oriented communication. Since data is sent over a connection, it remains in sequence and all data follows the same path. Because all data follows the same path, QoS parameters can be controlled more easily than connectionless data transfer. QoS requirements for the connection are negotiated by a call manager if the medium supports QoS. Call managers create and maintain connections. There are two types of call managers:

• A stand-alone call manager is a discrete software entity separate from the miniport driver.

• An integrated call manager has code that is an integral part of the connection-oriented miniport driver.

Connection-oriented miniports support many types of data transmission. Data, voice and videoconferencing using data streaming are made possible with connection-oriented miniport drivers. NDIS can offload synchronization and queue management details to the miniport driver. NDIS connection-oriented miniport drivers can expose a connection to the network protocols. For a diagram and additional information about connection-oriented miniport drivers supporting ATM, see ATM later in this chapter.