The Windows NT Network Model

The Windows NT network functionality is fully integrated with the operating system, unlike its predecessors, such as MS-DOS, Windows 3.x, and OS/2 1.x, which had network functionality hacked in afterwards. Because network functionality was built into the original design of Windows NT, it is more efficient, and the network implementation is transparent to the user. Adding support for multiple network adapter cards or transport protocols is as simple as adding the adapter card and installing the drivers in the Control Panel Network applet.

Using the OSI model as a basis for the Windows NT network model, the Microsoft engineers also used a modularized architectural design. Although it does not follow the OSI model exactly, it is fairly close, as Figure 8.3 illustrates. In this implementation, the application layer performs the same basic functionality as in the OSI model. After this though, the Windows NT network model begins to digress from the OSI model. The presentation layer is so thin as to be nonexistent. The real work occurs below the presentation layer in the session layer, so that is where we will continue our discussion.

Figure 8.3  The Windows NT network model compared to OSI network model.

Redirectors And Servers

The session layer of the OSI model is subdivided into separate entities in the Windows NT network model. This includes the provider interface, redirector, and server subcomponents.

The provider interface includes the Multiple UNC Provider (MUP) and Multiple UNC Router (MUR). The MUP is used to locate and resolve UNC (Universal Naming Convention) names and route the UNC request to the appropriate provider, such as the LanmanWorkstation provider. A UNC name is a means of specifying a resource based on the computer and share names. For example, the UNC name \\ROADTRIP\C designates the share to the C: drive on my laptop computer called ROADTRIP. The MUR is used to provide a standard interface to Win32 applications to access resources on multiple networks. When the application programming interface (API) called is used to access a resource on the network, the API in turn calls a proprietary dynamic link library (DLL), which in turn calls the appropriate network provider to support the network request.

The redirector subcomponent is used to access resources on another computer, and the server subcomponent is used to share resources on your computer. Both of these subcomponents are implemented as Windows NT file system drivers. There are several benefits to having these network drivers written as a file system driver. This provides the ability to cache the network requests for improved system performance, provides for dynamically loading and unloading the file system driver for improved memory management, and enables NT’s file system drivers to coexist with other file system drivers.

Transport Driver Interface

The Transport Driver Interface is a boundary layer protocol that provides a single entry point from the network redirectors to the various network protocols. This provides the ability to use any redirector without having to be tied to a specific protocol implementation. As you can see in Figure 8.3, the TDI layer straddles the session and transport layers when compared to the OSI network model. The Windows NT network model transport protocol layer combines the functionality of the OSI model transport and network layers. In a later section, we will look at the specific transport protocols Windows NT supports.

Network Device Interface Specification

The Network Device Interface Specification (NDIS) is where the big benefits occur in Windows NT. While early network device drivers were designed to include the network transport protocol and bind this protocol to a single network adapter driver, NDIS drivers are designed to support multiple network protocols to access a single or multiple network adapter(s).

The Microsoft implementation of the OSI data link layer is divided into two separate components. The NDIS 3.1 interface is included in the LLC layer, and the network adapter driver is included in the MAC layer. One of the really nice features of NDIS 3.1 is that it includes a C-callable interface, which makes a network driver easier to write. These network drivers are also true 32-bit implementations that are safe for use in a multiprocessor system.