DESIGNING AN OSI TEST BED

Kenneth L. Crocker and Michael T. Thompson

As of August 1990, new government procurements must comply with the Government Open Systems Interconnection Profile (GOSIP, see Federal Information Processing Standard 146). One outgrowth of this requirement will certainly be accelerated development efforts for portable OSI applications, like the PC-based OSI protocol test bed we describe in this article.

This test bed utilizes commercially available, portable source code to provide a Class Four Transport over X.25 Wide Area Network (WAN) implementation. The Class Four transport service provides connection-oriented, end-to-end service regardless of the underlying network services. The test bed software consists of approximately 42,000 lines of portable C source code purchased from Retix, 8000 lines of C developed to emulate an FAA weather data transfer application, and 200 lines of C to interface the Intel 82530 communications hardware to the Retix software. In particular, we'll focus on developing the synchronous communications device drivers that enable the Retix software to communicate with the 82530 hardware.

When designing the hardware-level device driver, you must address: 1. The amount of time allocated to input/output (I/O) routines based upon the highest expected data rate; 2. Timing requirements unique to the communications hardware; and 3. The interface to the portable code. The information presented in this article can be used as an example of how to design an interface to the Intel 82530 controller, as well as an example of overall system design when using portable communications software.

Unix, a multiuser, multitasking operating system (OS), was the OS Retix chose to develop its portable OSI software products in. MS-DOS, a single-tasking OS, allows one program or process to run at any given time. This means that the device driver can either move data via software polling or hardware interrupts. In polling, the device driver routines are placed inside what is essentially an infinite loop. The polling routine is then executed during each pass through the loop; however, every instruction that is added to the polling code, such as program diagnostics, increases the total loop execution time, which means that the communications hardware is interrogated less often. Conversely, interrupt- or event-driven communications alert the processor whenever data has been received or the transmit buffer is ready to accept more data. The interrupt-driven solution gives program control to the device driver whenever it is required, unlike the polling method, where program control is gained on a per-loop basis. The system described in this article uses a combination of polled and interrupt-driven I/O. The upper layer portable code is polled to check a series of event queues, while the receive and transmit data are handled via interrupts. The design of the interrupt handler for this interface must account for the following timing considerations: 1. The overall time to execute the interrupt routine must allow for non-interrupt processing to occur during data transfer; 2. The cycle and reset recovery times of the SCC must be met; and 3. The timing window of the SCC for reading and writing data must also be met.

Because the 9600 bit-per-second (bps) inbound data will generate a receive interrupt every 104 microseconds (mus) in the test bed environment, the SCC is programmed, as will be described later, to generate an interrupt for every 8 bits of received data and whenever the transmit buffer is empty. The receive interrupt period is derived as:

period of receive interrupt = (no. bits per character from SCC) / (transmission rate in bps)

The 104-s time span translates into approximately 624 timing, or clock, states for the 6-MHz XT 286. The 80286 can process approximately 100 assembler instructions in that time frame, assuming an average of six timing states per instruction for the types of instructions used in the device driver (for example, push, pop, mov, test, in, out) and ignoring other pending interrupts, system calls, and so on. For efficiency, the interrupt routine that loads the incoming data into the communication stack buffer manager should not occupy more than 25 percent of the total interrupt period. In a true full-duplex environment, one-half of the total processing time would be spent handling I/O while the other half would be used by application and communications stack-processing needs. Development in the 6-MHz XT-286 environment has shown that a faster processor is required for this type of interface. At 6 MHz, our interrupt routines can take up to a full character time (or 104 ,s) to execute. This is due to the buffer management requirements imposed by the portable software design and the required handshaking with the communications hardware. In our prototype environment, we control the overall throughput of the system by inserting delay to limit the transmit frame rate at the transport layer. In this manner we are able to adjust the transmit throughput at the link layer to accommodate our specific needs. Because LAPB is a windowing, asynchronous, acknowledgment-based protocol, when system A is transmitting a frame to system B, system B will wait until a set number of frames have been correctly received before acknowledging the window to system A. Once a link-layer connection has been established, normal communications continue in this manner.

Assuming a frame size of 512 bytes, this will yield 53 milliseconds (ms) of interrupt processing time and 947 ms to process the frame at the upper layers. For proper throughput efficiency, either a faster processor or a more stream-lined interface to the portable code will be required; however, we have been able to successfully interoperate with hardware and software manufactured by different vendors using this processing method.

The second set of timing considerations of the device driver are the cycle and reset recovery times of the SCC. The cycle recovery time applies to the time period between any read or write cycles to the SCC. This time period is defined to be six Processor Clock (PCLK) cycles. The reset recovery time applies to the time required to perform a software or hardware reset. The local PCLK on the Sealevel Systems board operates at 4.9152 MHz. This implies a cycle recovery time of 1.22 s and a reset recovery time of 2.24 s. To ensure that this critical timing requirement is met, the resulting assembler output from the C compiler must be analyzed. In sections where the cycle and reset recovery times are not met, dummy code (for example, nop,jmp$+2) is inserted to achieve the proper delay. The modified assembler code is then compiled using Microsoft MASM 5.0.

The third device driver timing consideration is the maximum time allowed to transfer data to and from the chip. Synchronous communication transfers data in a steady stream. Unlike asynchronous protocols, which use start and stop bits to frame each character, synchronous data is transferred in streams of 128, 256, and greater bytes of data. These data streams, or frames, are separated by flags. Because each byte of data must be transmitted in succession with the previous byte, the transmit routine must place the outbound data into the SCC before the previous byte has been completely transmitted. This timing requirement is imposed by the internal architecture of the 82530. The architecture of the controller and the required interface software are discussed in following sections.

The SCC has two independent full-duplex channels with 14 write registers and 7 read registers per channel. All modes of communications are established by the bit values sent to the write registers when the system is initialized. As data is received or transmitted, the read register values will change according to the mode programmed in the original setup. These changes to the read registers can cause hardware or software actions that lead to changes to other registers or other software or hardware reactions.

The SCC also utilizes a 3-byte first-in-first-out (FIFO) receive queue and a 20-bit transmit shift register which is loaded by a 1-byte transmit data buffer. The user of the SCC communicates with both mechanisms via a 1-byte I/O buffer. For synchronous communications, the transmit shift register must always contain data during a frame transmission. If a transmit underrun occurs, the SCC appends the 2-byte checksum field and flag information to the data stream. The receiving side of this data transfer will then see an incomplete link-layer data frame, resulting in a link-layer reject and possibly network-layer error recovery. If the 3-byte receive queue overflows, then receive data is lost, again causing link-layer rejects to occur. As stated in the previous section, the hardware driver must assure that the transmit shift register always contains data when sending a frame and that the receive queue is maintained at a nearempty level.

The initialization of the SCC for interrupt-driven synchronous communications is divided into three parts. Each part is unique to the initialization process and must follow the proper initialization sequence for correct operation of the SCC. The proper initialization sequence is the most critical part of the initialization process. As we learned, the SCC can appear to operate correctly, but not be capable of interoperating with other communications hardware. In our case, the two back-to-back SCCs on our test bed were moving data without errors, yet when we tried to communicate across a packet switch, every frame was rejected because of a bad checksum. The transmitter and receiver were inverting the checksum due to an out-of-sequence, but otherwise correct, initialization process.

During early debugging and experimentation with the device driver, we inserted an initialization sequence that corrected our current problem and caused another problem that did not surface until we introduced a different system, such as the packet switch. The initialization of the SCC must strictly follow the sequence explained in the technical manual, and any "debugging" changes should be checked against this sequence to avoid side effects similar to what we encountered.

The first part of the initialization sequence consists of programming the operation modes of the SCC such as bits-per-character and time constants. As you can see in the source code listings, we begin by forcing a hardware reset. The Synchronous Data Link Control (SDLC) mode of operation is then selected. The SCC actually implements a small subset of the SDLC protocol. This subset, in conjunction with the LAPB functions provided by the Retix link-layer software, meets the link-layer requirements of the test bed. The receive and transmit character lengths are then set to 8 bits each, and 7Eh is selected as the flag pattern to be sent between frames. The initial checksum value is set to FFh (required for proper SDLC operation), the RTxC pin of the 82530 is selected as the source for DTE clocking, and the baud-rate time constant is loaded during the final initialization steps of this phase of SCC initialization.

The second phase of SCC initialization consists of enabling the baud-rate generator to provide transmit clock and enabling the transmitter and receiver. During each subsequent phase of initialization, the previously set values (such as transmit and receive character length) must again be set during each use of a particular write register. As an example, write register 3 is used in this section to enable the receiver, yet all previously programmed information for write register 3 must be also be included. This phase of initialization is completed by enabling the transmit checksum generator, transmit interrupts, and receive interrupts.

Part three consists of enabling the different interrupts used by the system. In our implementation, the transmit underrun interrupt is enabled and all previously selected interrupts are enabled. This completes the initialization of the SCC. For further initialization information, the reader should consult the 82530 technical reference manual. The remainder of this article describes the software required to interface the Retix LAPB portable software to the SCC, as well as general information concerning the implementation of portable communications software.

Our test bed has been used to prototype several query/response applications that run over the transport layer and, in another environment, the network layer. The applications include weather database transfer and maintenance messaging. Furthermore, we have been able to successfully interoperate with a VAX utilizing DEC OSI software as well as a Tandem computer implementing Tandem X.25. Successful tests have also been conducted over a small packet switch with two PCs functioning as the end-systems. The PC-based system has to provide the flexibility to interoperate in a heterogeneous hardware and software environment.

Development of the four-layer system and application, including learning curve, required approximately 15 staff months. The staff working on a project of this nature should possess layered protocol, real-time software development, and testing knowledge. This type of project requires the same hardware and software tools as any real-time project. At a minimum, a logic analyzer, oscilloscope, in-circuit emulator, and protocol analyzer with simulation capability should be available. Code-level debuggers (such as Microsoft Code-View) are useful in debugging the application code; however, they do interfere with the individual protocol timers of each layer and the timing requirements of moving data up and down the communications stack. Software in-circuit emulators that utilize the protected mode of the 80386 and allow you to run the test application as a virtual machine (for example, Nu-Mega SoftIce) are very useful. If an 80386-based machine is available, this is a cost-effective substitute for a hardware in-circuit emulator.

Development of the test bed has shown that the device driver is the most critical part of the system design. The device driver should be designed, tested, and tuned before the upper layers are added. Most likely, vendor-unique management interfaces will need to be implemented with the device driver. The device driver can be written in the native language of the portable code to ease the interface to the link layer, and the assembler output of your compiler should be analyzed to determine if further optimization is necessary. In our case, Microsoft C 5.1 (compiling for execution speed optimization) produced tight assembler code that required little hand-tuning outside of that necessary to meet the 82530 cycle and reset times. Once the device driver and management routines have been developed, work can then progress on porting the upper layers. Finally, the application can be written, but the timing, polling, and interrupt activity must be considered at every phase of the system debugging.

The field of OSI software is still young, and technical risks will continue to decrease as the field matures. The test bed development effort has shown that at least the lower four layers can be implemented today using commercially available portable source code. Our work has confirmed that it is much easier to implement portable source code than to redevelop it for a particular system. However, the use of portable source code is not just a "compile-and-go" situation, since it is essentially a large real-time system driven by the data of another OSI end-system or relay-system.

The authors wish to thank Michael McGurrin, group leader, and Dr. Paul T. R. Wang, lead engineer, both of The MITRE Corporation, for their efforts in developing the test bed.

A system can be "closed," whereby components are not interchangable with another supplier's equipment (or alternate technology) without affecting other parts of the system; or, using well-defined, publicly available interface standards that treat components as black-boxes, the system can be "open." The advantage of an open system is its access to multivendor systems and growth without requiring totally new systems.