UNIX Token Ring Drivers

Introduction

The network protocol stack most closely associated with Unix is TCP/IP. This is a collection of protocols of which the most important are IP, UDP, and TCP. IP is a protocol for transporting packets of data; UDP is a protocol for transporting small amounts of data inside a single IP packet; and TCP is a protocol for transporting any amount of data, with guaranteed delivery, inside as many IP packets as necessary.

Although TCP/IP was originally designed for use over Wide Area Networks built from slow and unreliable telephone lines, its modular structure made it suitable for Local Area Networks too. The higher level protocols in the TCP/IP stack (UDP and TCP) have no contact with the communications media, they simply use IP to send and receive data, and are therefore unaffected by whether the packets are transported over a 56Kbit telephone line or a 16Mbps Token Ring.

Token Ring drivers and TCP/IP in Unix networks

The TCP/IP stack that a Unix system uses is usually supplied by the Unix vendor. Network adapter vendors provide network media drivers that run beneath TCP/IP. The media driver takes IP packets from IP and adds a header to them before transmitting them onto the network. When the media driver receives IP packets from the ring, it strips the media header and passes the packet up to IP.

Traditional Drivers

One goal of the original designers of Unix was a simple and elegant model for developers of hardware device drivers to use. To this end they divided hardware devices into two categories: block devices, which handled data in fixed-sized blocks, and character devices, which handled data in streams of characters. The commonest example of a block device was a fixed disk drive; examples of character devices included serial terminals and tape drives.

In this driver model, all drivers of block devices had to support a single set of operating system requests, and all drivers of character devices had to support a different but parallel set of requests. The two sets were similar to each other: in both cases a device driver had to be able to open its device (that is, prepare it for use), close it (that is, stop using it), write to it (that is, transfer data to it), and finally read from it (that is, transfer data from it). The main difference between the two types of driver was simply that one of them read and wrote data in fixed blocks and the other did so in character streams of variable lengths.

This driver model worked well and many device drivers still use it, including network adapter drivers for some versions of Unix. Network adapters, according to the model, were character devices. They handled network packets which are, of course, variable-sized data. Network drivers of this type simply presented an interface to Unix that allowed the operating system to read and write streams of characters that represented IP packets.

However, this driver model proved too simple, especially for serial terminals, because it did not accommodate the diversity of character sequences used in the Unix world for a single system call. For example, on most Unix systems, the <Ctrl> and <C> keys, pressed together, terminate a program. But different sorts of serial terminals generate completely different character sequences for a program termination signal (and for other system calls). Therefore something had to translate control characters into the correct character sequence for a particular system call in a given configuration of Unix. The original device model did not establish where on the system this translation should be accomplished.

In practice, device drivers did it. This was counter to the spirit of the Unix driver model because the model proposed that all drivers should present a uniform interface to Unix and simply write data to and read data from the operting system without interpreting the data at all. Apart from this, for the drivers to do the translating meant that they had to include a lot of complicated code just to enable them to work in different Unix configurations. This made them less reliable. Inevitably, drivers were limited in the number of different configurations they could support.

Where drivers did not translate control characters into system calls, application programs had to instead. This was equally counter to the spirit of Unix because it meant that, like the drivers described above, they had to become more and more complicated just to enable them to work in different Unix configurations. In practice, they too would be limited in the number of Unix configurations they could support.

The Streams model

One of the solutions to the problem posed by the traditional model for device drivers has been the Streams model. In this new model there are three software components: stream drivers, stream modules, and stream heads. A stream driver is a device driver that controls a hardware device. For example, for a network adapter, the stream driver is the network media driver - which is normally the only part of the software supplied by the hardware vendor. A stream head is a piece of software from which Unix applications read and write data. And a stream module is a piece of software that runs between the stream driver and the stream head. Sometimes stream modules are not needed, in which case the stream head runs directly above the stream driver.

Where stream modules are needed, more than one of them might be required, each performing a single, well-defined processing function. A serial terminal might, for example, have one stream module to translate the EBCDIC character set into the ASCII character set, and another one to interpret multiple character sequences that have special meanings.

Figure 1: The Streams model

TCP/IP and the Streams model

Unix vendors now provide TCP/IP stacks that are written according to the Streams model. At the top of the stack is a piece of software that Unix applications send data to and receive data from; beneath this are software modules that perform IP and TCP processing; and beneath these is a network media driver (provided by the adapter vendor) that communicates directly with the physical network.

Of several standards for the interface between the network media driver and the IP stream module, the most commonly used is the Data Link Provider Interface (DLPI). When Unix network media drivers are referred to as DLPI, this describes their upper interface only (that is, their interface to IP). Drivers from different adapter manufacturers, and also drivers for different implementations of Unix, differ enormously in their internal details.

Figure 2: A Streams implementation of TCP/IP

Other Network Protocols

Unix is traditionally associated with TCP/IP networking but most versions of Unix now support other protocols, for example, NetBIOS and IPX, aswell. Since the network media drivers supplied by adapter vendors do not usually interpret the contents of the packets they handle, Unix vendors can often introduce support for new protocols without the network media driver being affected.

Madge Token Ring drivers for UNIX

Madge provide network media drivers for Smart Ringnodes in the following Unix systems:

AIX v3.2.x running on the RS6000 family of workstations
AIX v4.1.x running on the RS6000 family of workstations and Power
Personal Systems
Solaris v2.4 and v2.5 running on Intel x86 platforms
SCO v3.x and ODT v4.x
SCO Open Server v5.x
Unixware v1.x and v2.x

References

1. Internetworking With TCP/IP Volume 1: Principles, Protocols and Architecture, Second Edition, Douglas E. Comer, Prentice Hall 1991, ISBN 0-13-474321-0

2. Data Communications, Computer Networks and Open Systems, Third Edition, Fred Halsall, Addison Wesley 1992, ISBN 0-201-56506-4

3. UNIX System V Release 4 - Programmer's Guide: STREAMS, UNIX Press, Prentice Hall 1990, ISBN 0-13-947003-4