DECnet Transport Architecture By Mitchell P. Lichtenberg and Jeffrey R. Curless 1 Abstract The PATHWORKS family of software products includes an implementation of the DECnet transport protocol to allow Intel-based personal computers access to network resources. This implementation, the DECnet Network Process (DNP) transport component, provides basic file and print services, terminal emulation, and application services. The new DNP component for the version 4.1 release of the PATHWORKS for DOS client software is written in assembly language to improve performance and reduce memory usage. The DOS and OS/2 versions of the component contain the same base source code, thus decreasing the development and maintenance costs. 2 Introduction Digital's PATHWORKS family of software products provides the means to integrate personal computers into the Digital network environment. The PATHWORKS for DOS client software includes device drivers, network transports, utility programs, and applications that allow PCs full access to the resources available in local and wide area networks (LANs and WANs). Transparent file sharing, electronic mail, and terminal emulation are examples of services supported by PATHWORKS client software. The DECnet protocol suite is implemented in Digital's standard set of software for interconnecting VAX and reduced instruction set computer (RISC) systems. DECnet software, which is included in the PATHWORKS client software, enables PC integration. The DECnet protocols allow PATHWORKS products to use the infrastructure of existing Digital networks and to provide common utility programs and network management capabilities. However, integrating PCs into a network system presents many design challenges to software developers. They must provide network access without limiting the functionality of the PCs and without compromising the compatibility of the existing PC software and peripherals. Since the PC architecture has limited memory resources and few built-in features for networking, PC network software architectures must be as transparent as possible, reducing memory usage and emulating local peripherals and software interfaces. To implement this transparent architecture, the PATHWORKS products comply with PC-related industry standards. Most such standards result from popular vendor software applications or hardware. For example, Microsoft's LAN Manager software product influenced the acceptance of the industry- standard server message block (SMB) protocol. This session layer protocol, implemented over a variety of transports, is used in the LAN Manager redirector for transparent file sharing and peripheral emulation. Digital licenses the LAN Manager software in order to provide these services as features of the PATHWORKS product family. Digital extended the LAN Manager Digital Technical Journal Vol. 4 No. 1, Winter 1992 1 DECnet Transport Architecture across a LAN or a WAN system by using the DECnet transport protocol as the transport layer in its PATHWORKS products. In this paper we first present our rationale behind the design of the DECnet transport component in PATHWORKS for DOS version 4.1, as well as in PATHWORKS for OS/2 version 2.0. We then describe the new component's internal structure, follow a typical network operation through the component, and compare this version of the software component with previous versions. 3 PATHWORKS Client Software and the DNP Component Since its initial release, the PATHWORKS product family has implemented the DECnet transport protocol to provide access to basic file services and printer sharing, terminal emulation, and application services. This network software implementation is called the DECnet Network Process (DNP) transport component. Figure 1 illustrates the relationship between the DNP transport component and the other memory-resident PATHWORKS client software components. Goals for PATHWORKS Client Software PC network software products are judged primarily on two criteria: performance, usually measured with popular benchmark programs, and resident memory usage, a limited resource that may restrict other applications. Increasing performance and decreasing memory usage are major goals for all new releases of the PATHWORKS client software. In the PATHWORKS version 4.1 client software, Digital sought to double the performance of the DNP transport component for small data transfers, while decreasing the size of the code by 50 percent. Another goal was to significantly reduce maintenance costs in order to free engineering resources for future project development. Before describing how we went about achieving these performance, memory, and development cost goals in PATHWORKS version 4.1, we review of the functionality of the DECnet DNP implementation. We also discuss the component in relation to other PATHWORKS client components to give the context in which our design decisions were made. The DNP Component Functionality Application programs can use DNP transport services through one of two software interfaces: the network basic I/O system (NetBIOS) interface and the I/O control block (IOCB) interface. The widely accepted NetBIOS interface is used by applications and drivers that comply with industry- standard specifications to provide peer-to-peer transport services on a LAN. The IOCB interface is specific to Digital's DECnet transport implementation of the DECnet protocols. IOCB provides a socket interface similar to the one used by the ULTRIX operating system. This IOCB interface is used by DECnet-specific application programs. 2 Digital Technical Journal Vol. 4 No. 1, Winter 1992 DECnet Transport Architecture To communicate with the network, the DNP transport component calls the data link layer (DLL) software interface. The DLL component is used by all PATHWORKS client components to send and receive packets on the LAN. This component demultiplexes incoming packets based on their protocol type (e.g., local area transport [LAT], local area system transport [LAST], or DECnet transport) and delivers these packets to the corresponding PATHWORKS client component. The DLL component also transmits packets on the LAN, either directly or indirectly by calling standards-based network drivers. To reduce memory consumption, the DLL component provides a global buffer pool that the DNP and other transport components can use for building network packets or for storing unacknowledged data. To provide timing and background process services, the DNP component calls the PATHWORKS real-time Scheduler (SCH) component. The SCH communicates directly with the DOS operating system and the PC's timer and interrupt hardware to create a simple cooperative process environment. This environment includes sleep and wake calls, and periodic interval timers. The functions of the SCH component are similar to those performed by true multitasking operating systems, such as the OS/2 system, which use preemptive scheduling. Considerations for a New DNP Component Design In previous PATHWORKS client software, separate teams implemented and maintained the DOS and OS/2 versions of the DNP transport component. We decided to use the same base source code for both versions and thus reduce development and maintenance costs. We then proceeded to consider our design options. Originally, the DNP component was written in the C programming language. The internal architecture remained basically unchanged during the five years following its release. This stable code should have been easy to port between operating systems. However, the internal architecture of the OS/2 system was never considered in the original design because this system was not available until 1988. Retrofitting the DOS version of the DNP component for the OS/2 operating system was difficult, and we were not able to maintain a common source code base. To achieve the performance, memory, and development cost goals described earlier in this section, we considered the following three approaches: 1. Rewrite the current DNP transport component 2. Write a new DNP transport component in C 3. Write a new DNP transport component in assembly language Rewriting the current DNP component would not have produced a desirable amount of code common to the DOS and OS/2 versions. In addition, this approach would have resulted in only minimally improving the maintainability of the code. Writing a new transport component in C would have yielded a more portable code, but the performance and memory usage would not have compared favorably with other vendors' transports. We Digital Technical Journal Vol. 4 No. 1, Winter 1992 3 DECnet Transport Architecture decided to write the new transport component in assembly language to make optimal use of the limited memory available on today's personal computers. 4 PATHWORKS Version 4.1 DNP Transport Component Design Internally, the DNP transport component comprises various modules that correspond approximately to the layers of the DECnet protocol suite, as shown in Figure 2. Later in this section, we describe the major DNP modules and how they cooperate.