Software Drivers

When networks were composed of mainly proprietary solutions for a particular vendor's systems, the vendor could write a simple software driver that could handle all the functions for the protocols that the vendor chose to implement. In networks today, it might be necessary to use more than one type of protocol on a network, so now software drivers must be capable of handling more than one protocol.

In the case of servers or routers, another factor to be considered is a system that has multiple network cards installed. The driver software must be capable of distinguishing the different NICs, as well as the protocols supported on each.

The two main types of NIC software drivers that you can find today are ODI and NDIS. Predating both of these, however, is a driver called a Packet Driver, which FTP Software developed in 1986. Because different operating systems or networking software might work only with a specific kind of driver, you must be aware of the kinds of drivers that a network card can be used with if you are planning to upgrade NICs or, perhaps, undergo a more complex change, such as migrating to a new operating system. For example, if you are thinking of migrating to a Novell network, you should concentrate on devices that support ODI drivers. In a Microsoft networking environment, you would need to look for devices that support NDIS.

Packet Drivers

In the early days of PC networking, one of the main problems with network cards and protocol stacks was that they were too closely interrelated; that is, purchasing a network protocol software package meant you had to be sure that it supported the network card you were using. The operating system did not provide the code to interface with the card, but rather the specific protocol package. This, of course, meant that developers of protocol stacks had to spend lots of time developing code to support the many types of network cards that were on the market.

FTP Software developed the Packet Driver to create an interface that protocols could use to access functions the network card provides. Protocol stacks that use the Packet Driver can exist on the computer and use the network card at the same time. Previously, network drivers were tightly bound to the network card at boot time, and you had to make changes to configuration files and reboot the computer each time you wanted to use a different network protocol.

The Open Data-Link Interface (ODI)

Novell and Apple Computer developed ODI in 1989 with a goal of providing a seamless interface at the Network, Transport, and Data Link levels, as shown in the OSI reference model. The ODI specification can be divided into three components:

• Multi-Link Interface Driver (MLID) This component controls communication between the network card and the link support layer. It consists of a section of code written by Novell called the Media Support Module (MSM) and the Hardware-Specific Module (HSM), written by the card vendor. The MSM provides the functions that implement standard network functions for the media types that are supported by ODI. The vendor writes the HSM code to handle the details of its particular card; the HSM code communicates with the MSM.

• Link Support Layer (LSL) This layer enables multiple protocols to exist on a single network card. The LSL is a gateway that determines to which protocol stack a network packet belongs and sends it on its way.

• Protocol Stack This component gets packets from the LSL and then sends the packet to another higher-level protocol or application.

Because ODI is modular, it makes writing protocol stacks or software drivers easier for third-party vendors. The code developer who works on the software to implement a protocol needs only to write to the specifications of the ODI interface, without regard to the underlying network card or the network media. The network card vendor has to worry only about writing code that can communicate with the MSM to implement the functions that are implemented by the card's hardware.

The Network Driver Interface Specification (NDIS)

Microsoft and 3Com Corporation initially developed NDIS, with Microsoft continuing that development with more recent versions. NDIS serves the same purpose, more or less, that ODI does in that it allows for the development of software for multiple protocol stacks to exist on multiple network adapters in a single computer. The actual implementation details, however, are quite different.

In Windows NT/2000/2003/XP, transport protocols span a portion of the Transport layer, the Network layer, and a portion of the Data Link layer. Transport protocols, such as NetBEUI Frame (NBF) and TCP, are implemented by calling services in the NDIS interface. NDIS doesn't completely hide the underlying network media from the protocol stack the way that ODI does. This limits most drivers to using Ethernet 802.3 or Token-Ring 802.5. Most drivers for ARCnet, for example, are written to take this into account and make the media look like Ethernet or Token-Ring to the software layers above.

Both ODI and NDIS provide support for each other. ODI provides a program called ODINSUP to support NDIS drivers. Windows computers come with NWLink, which is Microsoft's implementation of the IPX/SPX protocols. Microsoft also offers an inexpensive product (Services for NetWare). In addition, Windows NT/2000/XP as well as Windows 2000 Server and Windows Server 2003 also include Client Services for NetWare, which allows Windows NT clients to access resources on NetWare servers. Gateway Services for NetWare perform similar functions using a single Windows server computer as a gateway to NetWare services. A separate product called File and Print Services for NetWare is available from Microsoft, and can be used on a NetWare client to give it access to resources in a Windows server network.

In Part VI of this book, "LAN and WAN Network, Service, and Application Protocols," you will find more details about the various networking protocols that are available.