Device Drivers and the OSI Model

Every hardware device in a computer requires a software-based device driver to make it work. Some drivers—for instance, the driver for an integrated device electronics (IDE) hard disk or for the keyboard—are built into the operating system. Other devices require that drivers be installed separately when the device is attached or installed in the computer. Windows Server 2003 really blurs this distinction because it includes drivers for several hundred different network cards, but if your card isn't on the list, you will need to install drivers provided by the manufacturer.

In the past (e.g., when Windows 3.11 was introduced), network drivers were vendor specific, for both the operating system and the card. You might, for instance, have a difficult time if you wanted to put a 3Com Ethernet card and an IBM Token Ring card in the same server. Worse yet, most drivers could only be bound to a single protocol stack and a single card, so you couldn't have two cards using TCP/IP on one server.

A variety of vendors tried to solve this problem by developing driver interfaces that allowed multiple cards to be bound to multiple protocols. Apple and Novell developed the Open Datalink Interface (ODI), and Microsoft countered with the Network Driver Interface Specification (NDIS). Microsoft's operating systems have supported NDIS ever since, making it possible to bind either multiple protocols to one card or the same protocol to multiple cards.

Network adapter cards and drivers provide the services corresponding to the Data-Link layer in the OSI model. In the IEEE model, the Data-Link layer is split into the Logical Link Control (LLC) sublayer—which corresponds to the software drivers—and the Media Access Control (MAC) sublayer—which corresponds to the network adapter. You can think of the drivers as intermediaries between the higher layers and the card hardware that handles the business of forming packets and stuffing them into a wire.

Was this article helpful?

0 0

Post a comment