Protocols and Protocol Stacks
Figure 52 shows how the layers of TCP/IP and other popular network protocols relate differently to the OSI model.
In figure 52, each NOS manufacturer has implemented its own networking protocols to provide the required networking functions. These protocols operate as distinct programs or processes that the NOS use to transport data between the network nodes. Each set of programs is commonly referred as a protocol stack. It is important to note that although the underlying functionality of each of these protocol stacks is similar, the implementation within each NOS is unique.
A client application sends data down its protocol stack, passing through each of the protocols and interfaces. Information necessary to forward the application data to its destination is added by the programs operating at each level. At the receiving side, the data packets traverse a similar stack of protocols and programs, this time in reverse. Starting at the physical layer, the packet passed through each successive layer until it reaches the top of the stack at the relevant application process. At each layer, the information appended by the different protocols is examined so that the host can forward the packet to its final destination. For the host to accomplish this, both the client and the host need to run the same program at each level. If the server received a data packet that contained protocol information generated from a program not in its protocol stack, it would obviously not be able to understand the contained information.
Figure 53 provides a generic illustration of a data packet moving through the different protocol layers of the OSI model.
Each subsequent layer, additional protocol information is appended to the original data packet. At the host side, the protocol information is stripped away layer by layer to finally leave the application data.
Figure 54 shows a more specific example of an application packet moving through a TCP/IP network.
Operating Dual Protocol Stacks:
The biggest problems in providing multiprotocol support to network clients relate to the operation of the interface at both the top and the bottom of the protocol stack.
At the top of the stack, applications are generally written to function through the use of a specific network protocol. The application developer then needs to write different version of the application for it to operate using different network protocols. It is possible, however, for developers to overcome these issues by writing applications based on a common or standard interface such as NetBIOS, WinSock, or BSD sockets. It then becomes the problem of the implemented networking protocol to offer support for these interfaces.
Similar interpretability problems are found at the protocol stack, the use of a standard interface offers a possible solution. Each distinct networking solution offers its own protocol drivers to communicate with the installed network interface card. For example, this means, that if you loaded a separate NIC driver for both your NetWare stack and your TCP/IP stack, each driver program would assume that it had complete control over the installed NIC. The result would be that as either driver attempted to access the NIC it could corrupt any communication being carried out by the other program.
The solution to this problem requires that you load a single device driver to interface directly with the NIC and that this driver provides simultaneous support to all the installed protocol stacks. Two possible solutions have been developed to provide this support. The first is known as the Network Driver Interface Specification, and the second is the Open Datalink Interface. The implementation of either of these standards enables you to effectively provide multiprotocol support, enabling you to load more than one network protocol on a single workstation.
Network Driver Interface Standard (NDIS):
The NDIS specification was written to provide an NIC with the capability to simultaneously support multiple protocol stacks through the use of a single NIC device driver.
The specification defines three main components:
Media Access Control (MAC) driver: This is a device driver written by the vendors of the NIC that directly interfaces with the NIC hardware.
Upper-Level Protocol driver: This is a device driver written by the NOS vendor that provides the required functionality and interface support for the upper-layer protocols.
Protocol manager program: This is a manager or control program that co-ordinates the joining or binding of the preceding two programs to provide the completed protocol stack support. This program is called PROTMAN.DOS or PROTMAN.OS2, depending on the client operating system employed.
The initialisation of the NDIS environment starts with the protocol manager, which reads a configuration file, called PROTOCOL.INI, and stores the contained configuration in a predefined structure in an area of memory known as configuration memory.
As each of the other device drivers are loaded, they issue requests to the protocol manager for their specific configuration details. The protocol manager provides this information by indicating to each driver where it can find the configuration memory. The drivers then access this area of memory, which provides them with the details they need in order to initialise.
After the MAC driver and all the required protocol drivers have been loaded, the protocol manager must connect all the drivers together. This process is known as binding and is initiated by a program called NETBIND. The principal function of NETBIND is to issue the BindAndStart directive to the protocol manager. This indicates that all the drivers and protocols to form the necessary protocol stacks. The protocol manager should initiates communication with the MAC driver by issuing the IniatiateBind directive to each of the protocols that was loaded. Each of the protocols binds to the MAC driver with an indicated vector value. The MAC driver can then multiplexed between each of the loaded protocols based on this vector value.
Figure 55 shows the protocol structure resulting from the binding initiated by the NETBIND program.
Open Datalink Interface (ODI):
The ODI specification is similar in structure and functionality to NDIS. The ODI specification was developed as a means of providing client and server support for network protocols alongside its native networking protocol, IPX.
The ODI specification references the following components:
Multiple Link Interface Drivers (MLID): These drivers are similar in functionality to the MAC drivers specified by NDIS. They provide a device interface to the installed NIC within the client or the server.
Link Support Layer (LSL) interface: This interface manages the interaction between the installed MLID and the various installed upper-layer protocols. References within the LSL are made to redirect traffic from the MLID to the specified upper-layer protocol.
Upper-Level Protocol driver: This is a device driver that allows for the integration of other network protocols and their support within the NetWare environment.
Configuration and protocol loading within an ODI environment are controlled via the net.cfg file on the workstation. The first program to load is the LSL driver, which provides a basis for the binding of upper-layer protocols and for the loading of the NIC drivers. The file net.cfg contains information relating to the installed NIC driver, or MLID, and the LAN frame type support that is required. After the MLID has been installed, the upper-layer protocol drivers can be loaded to interface individually onto the LSL.
Listing 1 shows an example ODI dual protocol stack configuration. It indicates the loading of both the IPXODI driver, for IPX support, and the TCP/IP driver to provide a TCP/IP protocol stack.
REM Load LSL driver
REM Load MLID driver, which reference NET.CFG for its configuration
REM Load IPX upper layer ODI compliant driver
REM Load TCP/IP upper layer ODI compliant driver
REM Load redirector program
REM TCP/IP and IPX stacks loaded, continue with login routines
link driver 3c509
It is also possible to provide for NDIS-compatible environments within the ODI specification. This is provided through inclusion of a program called ODINSUP.COM. This program provides support for upper-layer protocol drivers written to the NDIS specification to interface directly with the installed ODI MLID. In other words, the NDIS protocols bind to the ODI MLID, via ODINSUP.COM, bypassing the installed LSL module. You might undertake this method if the TCP/IP stack you wanted to load supplied only an NDIS-compliant driver.