Network Driver Interface Specification - NDIS 5.0 Overview

Updated: December 4, 2001

NOTE: NDIS 5.0 is deprecated and will be removed in future versions of Windows. Refer to NDIS 6.x.

This paper provides an overview of the Network Driver Interface Specification (NDIS) 5.0, which represents a number of extensions to the interface described in NDIS 3.0 and 4.0. The basic requirements, services, terminology, and architecture of the earlier versions also apply to NDIS 5.0. The NDIS 5.0 architecture is included in the Microsoft Windows 98/Me and Windows 2000/Windows XP operating systems.

NDIS 5.0 is documented in the Windows DDK.

On This Page

  Introduction
  NDIS Version Check
  NDIS Power Management
  NDIS Plug and Play
  WMI and Support for WBEM Management
  Support for Single INF Format
  Deserialized Miniport for Improved Performance
  Task Offload Mechanisms for Improved Performance
  Broadcast Media Extension
  Connection-oriented NDIS and Support for QoS
  Other NDIS Extensions
  More Information about NDIS 5.0

Introduction

NDIS 5.0 extends previous versions of NDIS, so the basic requirements, services, terminology, and architecture of these earlier versions also apply to NDIS 5.0. The new NDIS architecture is included in Windows 98/Me and Windows 2000/Windows XP operating systems.

NDIS 4.0 added the following new features to NDIS 3.1:

• Out-of-band data support (required for Broadcast PC)

• WirelessWAN Media Extension

• High-speed packet send and receive (significant performance win)

• Fast IrDA Media Extension

• Media Sense

• "All local" packet filter (prevents Network Monitor from monopolizing CPU)

• Numerous new NDIS system functions (required for miniport binary compatibility across Windows 95 and Windows NT)

NDIS 5.0 consists of all functionality defined in NDIS 4.0, plus the following extensions:

• NDIS power management, required for network power management and network wake up

• Plug and Play is now applicable to Windows 2000 network drivers

• Windows hardware instrumentation support for structured, cross-platform management of NDIS miniports and their associated adapters

• Simplified network INF format across Windows operating systems, based on the Windows 95 INF format

• Deserialized miniport for improved performance on Windows 2000 multi-processor systems

• New mechanisms for for off-loading tasks such as TCP/IP checksum, IP Security, TCP message segmentation, and Fast Packet Forwarding to intelligent hardware

• Broadcast media extension, required for broadcast components

• Connection-oriented NDIS, required for native access to connection-oriented media such as ATM (including ATM/ADSL, ATM/cable modem, and so on) and ISDN

• Support for QoS when supported by the media

• Intermediate driver support--which is required for broadcast components, virtual LANs, LAN emulation over new media (ATM, satellite or broadcast television, and so on), packet scheduling for QoS, and NDIS support over WDM-supported buses such as IEEE 1394 and Universal Serial Bus (USB)

The goals for these features include the following:

• Increasing ease of use and reducing Total Cost of Ownership (TCO)

• Improving performance

• Enabling new media types, services and applications

• Improving flexibility in the driver architecture

Note: Most of the features in NDIS 5.0 are accessible only by using the miniport driver model and are not supported for full Media Access Control (MAC) drivers or the older miniport drivers.

 Top of page

NDIS Version Check

NDIS 4.0 is included in Windows NT 4.0 and Windows 95 OSR2 (OEM Service Release). NDIS 4.1 (also known as CoNDIS) accommodates raw access to connection-oriented media and was released as an early DDK for Windows NT 4.0 and Windows 95 to facilitate early development and testing of native ATM miniport drivers.

NDIS 5.0 extensions are included in the Windows 2000/Windows XP and Microsoft Windows 98/Me operating systems. NDIS 5.0 subsumes NDIS 4.0 and NDIS 4.1.

 Top of page

NDIS Power Management

NDIS power management is required for network power management and network wake up. The implementation of NDIS power management is based on the Network Device Class Power Management Reference Specification. The specification--which is available from http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/NetPMSPC.rtf--defines the behavior of network devices as it relates to power management and, specifically, to the four device power states defined for the OnNow Architecture. See also Power Management and Network Devices.

 Top of page

NDIS Plug and Play

Windows 2000 Plug and Play is modeled after Windows 95 Plug and Play support. It is transparent to the miniport drivers. When a network adapter is enumerated, a miniport is installed, loaded, and bound. When the network adapter is removed, the miniport is unbound, shut down, and unloaded. The only DriverEntry() should be "init." All other miniport initialization code should be "page," as it might be used after system init. The driver developers should use the standard registry keywords defined in the NDIS DDK.

 Top of page

WMI and Support for WBEM Management

Figure 1 Windows Management Instrumentation (WMI) Architecture

WMI, in conjuction with the Web-Based Enterprise Management (WBEM) standards initiative, allows applications to:

• Enumerate device classes (for example, network adapter), devices per class, and properties per device

• Query and set properties per device

• Register for event notification on applicable properties (WMI properties translate to NDIS OIDs)

At initialization, NDIS queries miniports for device specific properties (legacy miniport drivers will fail the query, thus indicating no device-specific properties). NDIS registers properties with WMI. The properties include the standard properties for all miniport drivers defined as NDIS DDK "mandatory" OIDs, and device-specific properties if provided by the miniport driver.

 Top of page

Support for Single INF Format

The Windows NT 4.0 Network INF files are Interpreted INFs. This accommodates INF language with sophisticated constructs such as definable variables, IF, GOTO, and so on. The interpreter for the INF files is the class installer. This means the Windows NT 4.0 network INFs are complex but flexible. They can be difficult to support and debug, and they have complex binding definitions. On the other hand, they can be extended by calling DLLs.

Windows 95 INFs are Declarative INFs, which define and list information that the system-level class installer will use. They are simpler than Interpreted INFs but less flexible. They are easier to support and debug, and they have simple binding definitions. Declarative INFs can be extended by use of a private class installer.

In Windows NT 4.0, only the network components do not use the Windows 95 INF format. As a result, Windows NT 4.0 network INFs are different from other INFs. Further, it is impossible to have compatible INFs between the two operating systems and, consequently, network driver developers have to write two separate INFs for Windows 95 and Windows NT 4.0.

The common INF format is based on the Windows 95 INF format and is used in Windows 2000/Windows XP and Windows 98/Me. Windows 98/Me use the same INFs as Windows 95. Windows 2000/Windows XP uses Windows 95 format with extensions. Because Windows 2000/Windows XP use drivers and Windows 95 uses VxDs, the format has been extended in a non-intrusive manner to allow the INF to install a service on Windows 2000/Windows XP. The goal is to minimize differences between Windows operating system INFs.

Windows 2000/Windows XP also has enhanced extensibility for INFs using COM interfaces to DLLs and use the same binding definitions as Windows 95.

If network driver developers have a working Windows 98 INF for a particular hardware device, most of the porting can be considered done. Refer to the Windows DDK for information on writing Windows INFs.

Note: Windows NT 4.0 network INFs will not work in Windows 2000/Windows XP.

 Top of page

Deserialized Miniport for Improved Performance

This provides better performance than what can be achieved by a "full duplex" miniport driver. At initialization time, the miniport driver must indicate its capability to perform deserialized operations. NDIS will then offload the synchronization and queue management to the miniport driver.

The following table illustrates the differences between the standard, full duplex, and deserialized miniport drivers.

 Top of page

Task Offload Mechanisms for Improved Performance

The preparation for Task Offload. By using query OIDs, the protocols can request the miniport "task offload capabilities mask." This means the task that can be offloaded must be predefined in NDIS. The protocol specifies the tasks it wants to offload to the miniport. Additional task-specific OIDs might be required for task parameter negotiation. At runtime, the protocol delegates task processing to the miniport driver and the netcard.

TCP/IP Checksum calculation. TCP/IP queries and sets the miniport capabilities. These calls include Add (Send) and Verify (Receive) for TCP, UDP, and IP checksum calculation. When sending, TCP/IP passes packets to the miniport with flag bit requesting the checksum calculation. On receive, the miniport passes the packet with flag bit set if checksum failed.

Fast Packet Forwarding. Fast Packet Forwarding (or Fast Forward Path) refers to functionality where multiport network adapters (802.3, DIX, TR, FastEthernet, FDDI, and so on) or similar single-port network adapters can be used in conjunction with Windows 2000 Routing code to do packet forwarding from one port to another port on the same or similar card without passing the packet to the host processor.

At initialization time, the routing protocols query and set the miniport capability for Fast Packet Forwarding. During runtime, the network adapters monitor and record which ports are used for which routes. If the route is known on packet receipt, the netcard directly forwards the packet to the other port. If the route changes, the miniport is told by the routing protocols (using an OID) to "flush" known routes.

Figure 2. Fast Packet Forwarding Path: Single Card

Figure 3. Fast Packet Forwarding Path: Multiple Cards

 Top of page

Broadcast Media Extension

Broadcast Media Extension is the NDIS extension to support high-speed unidirectional broadcast media such as services provided by Direct TV, PrimeStar or Intercast. The extensions include new OIDs and definitions for receiver tuning, multiple media stream negotiation and fast (zero copy) data streaming to user mode, and support for UDP/IP multicast packets via Microsoft provided LAM Emulation driver. The Broadcast Media Extension accommodates the Broadcast PC architecture.

 Top of page

Connection-oriented NDIS and Support for QoS

Previously, NDIS primarily supported network interface card driver development and deployment of connectionless network media such as Ethernet, Token Ring, ArcNet, and Fiber Distributed Data Interface (FDDI). NDIS 5.0 extends this interface to provide efficient support for connection-oriented media such as ATM (including ATM/ADSL, ATM/cable modem, and so on) and ISDN, with support for QoS and with isochronous data transfer for media that supports QoS. The new architecture also enables support for streaming of multimedia data such as audio and video over the NDIS media.

Information about the miniport driver model is included in the Windows DDK.

Note: NDIS 5.0 features are accessible only by using the NDIS miniport driver model and are not supported for full MAC drivers.

Figure 4. NDIS 5.0 Conceptual View

Support for the extensions and features requires additional software-based support components and changes to NDIS interfaces beyond the simple hardware driver required for LAN or WAN media. These changes include the following and are only supported under the miniport paradigm:

• A Call Manager for connection (or call) setup

• LAN emulation for transparent support of legacy protocols and other mechanisms for more efficient resolution to their native address formats of specific legacy protocol addresses such as IP addresses

• Mechanisms to provide direct access to the media for Kernel-mode streaming

Figure 5. Windows ATM Services

Figure 6. An example of stream handlers in NDIS 5.0 architecture

 Top of page

Other NDIS Extensions

NDIS 5.0 also includes the following extensions:

• Intermediate Driver Support (required for Broadcast PC, Virtual LANs, Packet Scheduling for QOS, and for NDIS support of IEEE 1394 network devices, for example)

• Protocol rebind when the network interface card media type changes

• Packet scheduling, full duplex, and so on

Note: Most of the features in NDIS 5.0 are accessible only using the miniport driver model and are not supported for full MAC drivers or the older miniport drivers.

 Top of page

More Information about NDIS 5.0

Additional information about the miniport driver model and NDIS 5.0 is available in the Windows DDK.

For more information about power states, Network Wake Ups, "Network Wake-up Frames", and so on, please, refer to Network Device Class Power Management Reference Specification.

 Top of page

Related Links

• Microsoft Windows Network INF Format