images/contents.gifimages/index.gifimages/prev1.gifimages/next1.gif

Layered Implementation of Network Software

An AspeNet Server depends upon the reliable transport services of the TCP and MCP protocols. Each of these transport protocols, in turn, relies upon the services of the IP and IPX network protocols, respectively.

Both the TCP/IP and MCP/IPX protocol stacks require the use of lower-level services which control the network hardware, allowing the IP and IPX protocols to send and receive datagrams on the physical network infrastructure.

The layering of protocols, services, and hardware facilities provides great flexibility to configuring network software. Each layer presents services to the next higher layer in a standardized fashion, while adapting the implementation of those services to the specifics of the next layer down. Thus, a software module operating at any particular architectural layer can be supported by any number of different modules at the next layer down and can likewise provide support for any number of higher-level modules which desire to use its services.

The Link Support Layer (LSL) software abstracts the necessary details of controlling network hardware into a standardized collection of services; protocol stack implementations employ those generic services to send and receive network data without concern for the exact details of the underlying hardware's operation. To actually control the network hardware, the LSL relies upon hardware-specific driver software.

Driver software written to inter-operate with Novell's LSL adheres to Novell's Open Data-Link Interface (ODI) specification. An ODI-compliant driver implements the standardized services of the Link Support Layer for a particular make and model of network hardware. We will refer to the network hardware as a network board or adapter; its driver will be referred to as a board driver, an adapter driver, or a driver.

Not only does the LSL provide standardized design objectives for the protocol stacks above it and the adapter drivers below it, but it also allows both IPX and TCP/IP protocol stacks to share access to a single network adapter. To generalize even further, the LSL provides a standardized interface to allow one or more protocol stacks to send and receive data using one or more network adapters. It functions as a network traffic “cyber-cop”, channeling the flow of information between protocol stacks and the appropriate network hardware.

The following illustration summarizes the possible relationships within any one machine between an application, protocol stacks, the LSL, adapter drivers, and physical adapter:

Application (e.g., an AspeNet Server)
TCP MCP
IP IPX
Link Support Layer (LSL)
Ethernet Adapter Driver Token-Ring Adapter Driver
Ethernet Adapter Token-Ring Adapter