NDIS Drivers
When a protocol driver wants to read or write messages formatted in its protocol's format from or to the network, the driver must do so using a network adapter. Because expecting protocol drivers to understand the
nuances
of every network adapter on the market (proprietary network adapters number in the thousands) isn't
feasible
, network adapter vendors provide device drivers that can take network messages and transmit them via the
vendors
' proprietary hardware. In 1989, Microsoft and 3Com jointly developed the Network Driver Interface Specification (NDIS), which lets protocol drivers communicate with network adapter drivers in a device-independent manner. Network adapter drivers that conform to NDIS are called NDIS drivers or NDIS miniport drivers. The version of NDIS that ships with Windows 2000 is NDIS 5, and the version that ships with Windows XP and Windows Server 2003 is NDIS 5.1.
The NDIS library (\Windows\System32\Drivers\Ndis.sys) implements the NDIS boundary that exists between TDI transports (typically) and NDIS drivers. As is Tdi.sys, the NDIS library is a helper library that NDIS driver
clients
use to format commands they send to NDIS drivers. NDIS drivers interface with the library to receive
requests
and send back responses. Figure 13-18 shows the relationship between various NDIS-
related
components
.
One of Microsoft's goals for its network architecture was to let network adapter vendors easily develop NDIS drivers and take driver code and move it between Consumer Windows and Windows 2000. Thus, instead of merely providing the NDIS boundary helper routines, the NDIS library provides NDIS drivers an entire execution environment. NDIS drivers aren't
genuine
Windows drivers because they can't function without the encapsulation the NDIS library gives them. This insulation layer wraps NDIS drivers so thoroughly that NDIS drivers don't accept and process IRPs. Rather, TDI protocol drivers call a function in the NDIS library,
NdisAllocatePacket
, and pass the packets to an NDIS miniport by calling an NDIS library function (
NdisSend
, for example). By default, NDIS drivers also don't have to worry about reentrancy, in which the NDIS library invokes an NDIS driver with a new request before the driver has finished
servicing
a previous request. Exemption from reentrancy means that NDIS driver writers don't need to worry about complex synchronization, which is made even more tricky because of the parallel execution possible on a multiprocessor.
Note
|
The NDIS library uses NDIS packets to represent I/O requests instead of IRPs. TDI transports allocate an NDIS packet by calling
NdisAllocatePacket
and then pass the packet to an NDIS miniport by calling an NDIS library function (
NdisSend
, for example).
|
Although the NDIS library's serialization of NDIS drivers
simplifies
development, serialization can hamper multiprocessor scalability. Standard NDIS 4 drivers (the Windows NT 4 version of the NDIS library) don't scale well for certain operations on multiprocessors. Microsoft gave developers a deserialized operation option in NDIS 5. NDIS 5 drivers can
indicate
to the NDIS library that they don't want to be serialized; the NDIS library will then forward requests to the driver as fast as it receives the IRPs that describe the requests. Responsibility for queuing and managing multiple simultaneous requests
falls
on the NDIS driver, but deserialization confers the benefit of higher multiprocessor performance.
NDIS 5 also includes the following features:
-
NDIS drivers can report whether or not their network medium is active, which allows Windows to display a network connected/disconnected icon on the taskbar. This feature also allows protocols and other applications to be aware of this state and
react
accordingly
. The TCP/IP transport, for example, will use this information to determine when it should reevaluate addressing information it receives from DHCP.
-
TCP/IP task offloading allows a miniport to use advanced features of a network adapter to perform operations such as packet checksums and Internet Protocol security (IPSec). This task
offloading
can improve system performance by
relieving
the CPU from these operations.
-
Wake-on-LAN allows a wake-on-LAN-capable network adapter to bring Windows out of a suspend power state. Events that can trigger the network adapter to signal the system include media connections (such as plugging a network cable into the adapter), the receipt of
protocol-specific
patterns registered by a protocol (the TCP/IP transport asks to be woken for Address Resolution Protocol [ARP] requests), and, for Ethernet adapters, the receipt of a
magic
packet (a network packet that contains 16 contiguous copies of the adapter's Ethernet address).
-
Connection-oriented NDIS allows NDIS drivers to manage connection-oriented media such as Asynchronous Transfer Mode (ATM) devices. (Connection-oriented NDIS is described in more detail shortly.)
The interfaces that the NDIS library provides for NDIS drivers to interface with network adapter hardware are available via functions that translate directly to corresponding functions in the HAL.
|
The Ndiskd kernel debugger extension library includes the
!miniports
and
!miniport
commands, which let you list the loaded miniports using a kernel debugger and, given the address of a miniport block (a data structure Windows uses to track miniports), see detailed information about the miniport driver. The following example shows the
!miniports
and
!miniport
commands being used to list all the miniports and then specifics about the miniport responsible for interfacing the system to a PCI Ethernet adapter. (Note that WAN miniport drivers work with dial-up connections.)
kd> .load ndiskd
Loaded ndiskd extension DLL
kd> !miniports
Driver verifier level: 0
Failed allocations: 0
Miniport Driver Block: 817aa610
Miniport: 817b1130 RAS Async Adapter
Miniport Driver Block: 81a1ef30
Miniport: 81a1ea70 DirectParallel
Miniport Driver Block: 81a21cd0
Miniport: 81a217f0 WAN Miniport (PPTP)
Miniport Driver Block: 81a23290
Miniport: 81a22130 WAN Miniport (L2TP)
Miniport Driver Block: 81a275f0
Miniport: 81a25130 Intel 8255x-based PCI Ethernet Adapter(10/100)
kd> !miniport 81a25130
Miniport 81a25130 : Intel 8255x-based PCI Ethernet Adapter(10/100)
Flags : 20413208
BUS_MASTER, INDICATES_PACKETS,
IGNORE_REQUEST_QUEUE
IGNORE_TOKEN_RING_ERRORS, NDIS_5_0,
RESOURCES_AVAILABLE, DESERIALIZED,
MEDIA_CONNECTED,
NOT_SUPPORTS_MEDIA_SENSE,
PnPFlags : 00010021
PM_SUPPORTED, DEVICE_POWER_ENABLED,
RECEIVED_START
CheckforHang interval: 2 seconds
CurrentTick : 0001
IntervalTicks : 0001
InternalResetCount : 0000
MiniportResetCount : 0000
References: 3
UserModeOpenReferences: 0
PnPDeviceState : PNP_DEVICE_STARTED
CurrentDevicePowerState : PowerDeviceD0
Bus PM capabilities
DeviceD1:1
DeviceD2:1
WakeFromD0:0
WakeFromD1:1
WakeFromD2:0
WakeFromD3:0
SystemStateDeviceState
PowerSystemUnspecifiedPowerDeviceUnspecified
S0D0
S1D1
S2PowerDeviceUnspecified
S3PowerDeviceUnspecified
S4D3
S5D3
SystemWake: S1
DeviceWake: D1
WakeupMethodes Enabled 6:
WAKE_UP_PATTERN_MATCH WAKE_UP_LINK_CHANGE
WakeUpCapabilities of the miniport
MinMagicPacketWakeUp: 4
MinPatternWakeUp: 4
MinLinkChangeWakeUp: 4
Current PnP and PM Settings: : 00000030
DISABLE_WAKE_UP, DISABLE_WAKE_ON_RECONNECT,
Allocated Resources:
Memory: f4100000, Length: 1000
IO Port: 1440, Length: 40
Memory: f4000000, Length: 100000
Interrupt Level: 9, Vector: 9
Translated Allocated Resources:
Memory: f4100000, Length: 1000
IO Port: 1440, Length: 40
Memory: f4000000, Length: 100000
Interrupt Level: 12, Vector: 39
MediaType : 802.3
DeviceObject : 81a25030, PhysDO : 81a93cd0 Next DO:
81a63030
MapRegisters : 819fc000
FirstPendingPkt: 0
SingleWorkItems:
[0]: 81a254e8 [1]: 81a254f4 [2]: 81a25500 [3]: 81a2550c
[4]: 81a25518 [5]: 81a25524
DriverVerifyFlags :00000000
MiniportOpen BlockQueue:
8164b888: Protocol 816524a8 = NBF, ProtocolContext 81649030
8191f628: Protocol 81928d88 = TCPIP, ProtocolContext
8191f728
Miniport Interrupt 81a00970
The Flags field for the miniport that was examined indicates that the miniport supports deserialized operation (DESERIALIZED), that the media is currently active (MEDIA_CONNECTED), and that it is an NDIS 5 miniport driver (NDIS_5_0). Also listed are the adapter's system-to-device power-state mappings and the bus resources that the Plug and Play manager assigned to the adapter. (See the section "The Power Manager" in Chapter 9 for more information on power-state mappings.)
|
|
Variations on the NDIS Miniport
The NDIS model also supports hybrid TDI transport-NDIS drivers, called
NDIS intermediate drivers
. These drivers lie between TDI transports and NDIS drivers. To an NDIS driver, an NDIS intermediate driver looks like a TDI transport; to a TDI transport, an NDIS intermediate driver looks like an NDIS driver. NDIS intermediate drivers can see all network traffic taking place on a system because the drivers lie between protocol drivers and network drivers. Software that provides fault tolerant and load balancing options for network adapters, such as Microsoft's Network Load Balancing Provider, are based on NDIS intermediate drivers.
Connection-Oriented NDIS
Support for connection-oriented network hardware (for example, ATM) is native in Windows, which makes connection management and establishment standard in the Windows network architecture. Connection-oriented NDIS drivers use many of the same APIs that standard NDIS drivers use; however, connection-oriented NDIS drivers send packets through established network connections rather than place them on the network medium.
In addition to miniport support for connection-oriented media, NDIS 5 includes definitions for drivers that work to support a connection-oriented miniport driver:
-
Call managers are NDIS drivers that provide call setup and
teardown
services for connection-oriented clients (described shortly). A call manager uses a connection-oriented miniport to exchange signaling messages with other network entities such as network switches or other call managers. A call manager supports one or more signaling protocols, such as ATM User-Network Interface (UNI) 3.1.
-
An integrated miniport call manager (MCM) is a connection-oriented miniport driver that also provides call manager services to connection-oriented clients. An MCM is
essentially
an NDIS miniport driver with a built-in call manager.
-
A connection-oriented client uses the call setup and teardown services of a call manager or MCM and the send and receive services of a connection-oriented NDIS miniport driver. A connection-oriented client can provide its own protocol services to higher levels in the network stack, or it can implement an emulation layer that interfaces connectionless legacy protocols and connection-oriented media. An example of an emulation layer fulfilled by a connection-oriented client is a LAN emulation (LANE), which hides the connected-oriented characteristics of ATM and
presents
a connectionless media (such as Ethernet) to protocols above it.
Figure 13-19 shows the relationships between these components.
|
|
Windows Server comes with a tool named Network Monitor that lets you capture packets that flow through one or more NDIS miniport drivers on your system by installing an NDIS intermediate driver. Before you can use Network Monitor, you need to have the Windows Network Monitor Tools installed on your system. To install these tools,
open
Add/Remove Programs in Control Panel, and select Add/Remove Windows Components. Select Management And Monitoring Tools, click Details, select Network Monitor Tools, and click OK. After Network Monitor has been installed, you can launch Network Monitor by selecting it from the Administrative Tools folder.
Network Monitor might ask you which network connection you want to monitor. After selecting one, begin monitoring by pressing the Start Capture button in the toolbar. Perform operations that generate network activity on the connection you're monitoring, and after you see that Network Monitor has captured packets, stop monitoring by clicking the Stop And View Capture button (the stop button that has
glasses
next to it). Network Monitor will present a view of the capture data like the following:
The screen shot shows the SMB (CIFS) packets that Network Monitor captured as remote files were accessed from the system. If you double-click on a line, Network Monitor will switch to a view of the packet that breaks it apart to show various layered application and protocol headers as shown in the following screen shot:
Network Monitor also includes a number of other features, such as capture triggers and filters, that make it a powerful tool for troubleshooting network problems.
|
|
Remote NDIS
Prior to the development of Remote NDIS, a vendor that developed a USB network device, for example, had to provide a driver that interfaced with NDIS as a miniport driver as well as interfacing with a USB WDM bus driver, as shown in Figure 13-20. If the vendor's hardware supported other
busses
, such as IEEE 1394, they were required to implement drivers that
interfaced
with each specific bus type.
Remote NDIS is a specification for network devices on dynamic Plug and Play I/O buses such as USB, IEEE 1394, and Infiniband. The specification eliminates the need for a hardware vendor to write an NDIS miniport driver at all by defining bus-independent messages and the mechanism by which the messages are transmitted over various buses. Remote NDIS messages mirror the NDIS interface and include messages for initializing and resetting a device, transmitting and receiving packets, setting and querying device parameters, and indicating media link status.
The Remote NDIS architecture, in Figure 13-21, relies on a Microsoft-supplied NDIS miniport driver, \Windows\System32\Drivers\Rndismp.sys, that
translates
NDIS commands and forwards them to a bus transport driver for the bus on which a device is located. The architecture allows for a single NDIS miniport driver to be used for all Remote NDIS drivers and a single bus transport driver for each supported bus.
Currently, Remote NDIS for USB devices is included on Windows XP and Windows Server 2003 and available as a download from Microsoft for Windows 2000. While Remote NDIS on IEEE 1394 is fully specified, Windows does not yet support it.
QOS
If no special measures are taken, IP traffic is delivered over a network on a first-come, firstserve basis. Applications have no control over the priority of their messages, and they can experience
bursty
network behavior, where they occasionally obtain high throughput and low latencies, but
otherwise
receive poor network performance. While this level of service is acceptable in most situations, an increasing number of network applications demand more consistent service levels, or
quality of service (QOS)
guarantees
. Video conferencing, media streaming, and enterprise resource planning (ERP) are examples of applications that require good network performance. QOS allows an application to specify minimum bandwidth and maximum latencies, which can be satisfied only if every networking software and hardware component between a sender and receiver supports QOS standards such as IEEE 802.1P, an industry standard that specifies the format of QOS packets and how OSI layer 2 devices (switches and network adapters) respond to them.
Windows QOS support is based on a handful of Microsoft-defined Winsock APIs that allow an application to request QOS for traffic over their Winsock sockets. For example, an application uses
WSCInstallQOSTemplate
to install a QOS template that specifies desired bandwidth and latency. A second API, the Traffic Control (TC) API, lets an administrative application more precisely control the traffic flow over a networks attached to the computer.
The heart of the Windows QOS implementation is the Resource Reservation Protocol (RSVP) Win32 service (\Windows\System32\Rsvp.exe), as shown in Figure 13-22 The RSVP Winsock service provider (\Windows\System32\Rsvpsp.dll) communicates application QOS requests via RPC to the RSVP service. The RSVP service in
turn
uses the TC API to control traffic flow. The TC API, which is implemented in \Windows\System32\Traffic.dll, sends I/O control commands to the Generic Packet Classifier (GPC) driver (\Windows\System32\Msgpc.sys). The GPC driver communicates closely with the QOS packet scheduler NDIS intermediate driver (\Windows\System32\Psched.sys) to control the flow of packets to the network from the computer so that the QOS levels
promised
to particular applications can be met, and so that appropriate QOS headers can be placed on packets for which QOS is desired.
Note
|
|
RSVP signaling functionality is removed in Windows XP and Windows Server 2003. While the RSVP service still executes, it serves only as a conduit between applications and traffic control components.
|
|
