TCP/IP and OSI fnteroperability with the X Window Systemapplications to the emerging Open Systems Interconnection (OSI) protocols. To accomplish this goal, these users must rewrite

TCP/IP and OSI fnteroperabilitywith the X Window System

Nancy Crowther, Joyce Graham - IBM Cambridge Scientific Center

ABSTRACT

Network users are faced with the problem of making the transition from TCP/Papplications to the emerging Open Systems Interconnection (OSI) protocols. To accomplishthis goal, these users must rewrite their code to use OSI, or switch to new applications, oruse a gateway between TCP/IP and OSI based applications. This paper details how thisproblem was solved in work at IBM's Cambridge Scientific Center for one distributedapplication, the X Window System, and how the same methods could be used for otherapplications. The draft ANSI standard mapping X to OSI is explained. The changes thatwere made to the X Window System to support OSI and an X TCP-OSI Gateway aredescribed. The best method for migrating apþiications was found to be extensions tô thesocket to support OSI at multiple layers.

Introduction

Interoperability on a network connecting dif-ferent types of multi-vendor systems is a featureincreasingly demanded by users. The X WindowSystem, Transmission Control Protocol/Internet Pro-tocol (TCP/IP), and Open Systems Interconnection(OSI) protocols all promote this interoperability. Xallows the workstation user to display results fromapplications running on multiple heterogeneous sys-tems. Both TCP/IP and OSI protocols are non-proprietary ways to connect these multi-vendor sys-tems, but users who want to change from TCP/IP toOSI in order to use new OSI applications face theproblem of converting their current TCP/P applica-tions to run on the OSI network.

This paper examines one TCP/P-based applica-tion, the X Window System, and explains how wemoved it into an OSI environment in experimentalprototypes at IBM's Cambridge Scientific Center. Xover OSI is a natural pairing to address requirementsfor enhanced interoperability, but until recently hasnot been attempted. We explain the mapping of Xto OSI as defined in the draft ANSI standard[ANSI91], and describe how we implemented it intwo different ways on a uMx based operating sys-tem, IBM's AIX 3.1. Our experience indicates thatthere are many advantages to modifying the OSIsocket programming interface found in 4.3 RenoBSD [BSD43] to support OSI at the ApplicationLayer. We also describe an X TCP-OSI Gateway,for use in networks containing some TCP/P-basedsystems and some OSl-based systems.

X Window System

The X Window System is a portable network-transparent window system, allowing multiple appli-cations, called X clients, to run on varied hetero-geneous systems and architectures throughout a

network and display on any workstation running anX server application. The X server controls theworkstation's bitmap display, keyboard and mouse.IBM ships X on most of its platforms, either clientapplication libraries, server, or both, depending onthe system.

Clients and seryer communicate by means ofthe X protocol, which consists of requests from theclient for various functions such as drawing, repliesfrom the server to these requests, events whichnotify the client of mouse or keyboard input, anderror notifications. The X protocol in turn rides ontop of a reliable byte stream between client andserver. If client and server are on the same system,this reliable byte stream is simply some local inter-process communication mechanism. When clientand server are on different systems connected by anetwork, the reliable byte stream is provided bysome communications protocol, typically TCP/IP.All of IBM's current X products use TCP/IP as theunderlying network communication protocol.

Figure L shows the various parts of an X Win-dow System.

X client application programs use various"toolkits", or application programming interfaces(API's) which implement graphical functions. Thetoolkits in turn call routines in the various Xlibraries supplied by the X Window System. Thelowest level X library, referenced eventually by allhigher layers, is the Xlib, or X library. Buried inthis library are the routines which perform the net-work communication. These communication rou-tines, as distributed in the X source code, currentlysupport TCP/IP and DECnet only. The windowmanager is also an X client, and it uses the Xlib toperform network communication to the X server. Aclient in frequent use is the xterm plogtam, a termi-nal emulator. This program displays in a window as

Summer '92 USENIX - June 8-June 12, t992 - San Antonio, TX 243

TCP/P and OSI Interoperability...

if it were the system console. All other programswhich write to the console and read from the kev-board can be run "in" this window, sending their out-put to xterm, which in turn communicates throughXlib to the X server.

The X clients and the X server may be execut-ing on the same workstation, or on completely dif-ferent systems from multiple manufacturers. Sincethe X protocol is system independent, clients may bewritten with assurance that they can display on anyworkstation implementing a standard X server.Similarly, a standard X server can expect to be ableto be used by any standard X client from anysoftware vendor. This of course contributes greatlyto the goal of interoperability. Applications writtenfor a proprietary windowing system or other userinterface are very limited in their use.

Although the X protocol is designed to be ableto be implemented from its documentation, in prac-tice vendors use the sample implementation sourcecode, which is available for free from the Mas-sachusetts Institute of Technology X Consortium,and modify it for their own systems. The X source

Crowther, Graham

code (in the C language) is written in such a waythat it can be compiled for many different operatingsystems by selecting certain compilation options.The X code is truly portable. Although it wasimplemented first on 4.2 BSD it runs on operatingsystems as diverse as VM, MVS, and OS/2, as wellas UMx based operating systems such as AIX. Inthe current Release 5 from the X Consortium, codewhich specifically supports AIX 3.1 and one of thegraphics adapters for the RISC System/6000 isincluded. (This code was written by IBM anddonated to the X Consortium.) This support is thusfreely available to RISC Systenv6000 users eventhough it is not yet available as an IBM product.

OSI

While TCP/IP protocols, whose developmentbegan in the mid-1970s funded by the DefenseAdvanced Research Projects Agency (DARpA) forits collection of networks, are the current de factostandard, the long-term replacement for these proto-cols is the OSI protocols. This suite consists ofseven layers of international standard protocols being

Network

X Server(workstation only)

X Toolkits

Figure 1: X Window System Parts

244 Summer '92 USENIX - June 8-June 12,lgg2 - San Antonio. TX

Crowther, Graham

developed by the international community to provideboth the political and technical solution to world-wide networking. Since August 15, 1990, the USGovernment has required that new network procure-ments and major upgrades to existing networks sup-port the Government OSI Profile (GOSIP). GOSIPis a selected subset of the OSI protocols [GOSIP88].

OSI is a complete family of protocols, separat-ing the functions of communication between applica-tions into well-defined layers. Figure 2 shows theOSI reference model [IS7498]. There are two endsystems communicating with each other, connectedby any number of intermediate systems.

At the highest layer, the Application Layer,applications such as file transfer, mail, and libraryinformation retríeval exchange information organizedinto previously agreed upon data structures. Theseapplications use common application services. Oneof these is the Association Control Service Element(ACSE). The ACSE manages the connection (calledan "association") between the communicating sys-tems. The two sides agree on which application ser-vices will be used in the association by exchangingthe "application context." The two applicationsagree on the semantics of the data which is beingtransferred, but the representation of these data struc-tures on the respective systems may be very

TCPÆP and OSI Interoperability ...

different. As simple examples of such differences,one may use ASCII to represent characters and theother may use EBCDIC. One may use the "bigendian" method of representing integers (mostsignificant byte first), and the other may use "littleendian." The applications are not concerned withthese differences; they call on the Presentation Layerto take care of exchanging the data in such a waythat the two systems can understand each other. Thedata structures are specified in a system independentlanguage capable of representing the abstract syntaxwhich defines the data structures exchanged by thecommunicating applications, The most commonlyused abstract syntax language is called Abstract Syn-tax Notation One (ASN.l), but this is not the onlypossibility.

The Presentation Layer transforms the localdata structures into a system independent syntax (thetransfer syntax) which determinés the format àndordering of the bits which are actually sent over thenetwork to the other side. The receiving Presenta-tion Layer decodes from the transfer syntax into itsown local forms of data representation. The Presen-tation Layer on each side is able to do this becauseit has knowledge about which transfer syntax wasused to encode the data, and which abstract syntaxwas used by the Application Layer. The pair of

End Svstem A End Svstem B

NetworkIP, X.25

Figure 2: OSI Communication

Summer '92 USENIX - June 8-June L2,1992 - San Antonio, TX 24s

TCP/P and OSI Interoperability ...

syntaxes to be used in the communication, called the"presentation context", is negotiated and agreed uponby the two sides of the Presentation Layer. Themost commonly used transfer syntax is the BasicEncoding Rules, BER, but it is not necessary to useBER in OSI.

The Presentation Layer calls on the SessionLayer to conduct an orderly conversation with theother side, including graceful termination of theconversation and choosing of full or half-duplexcommunication. (Session performs many other func-tions, such as synchronization, activity management,and so forth, which are not detailed here.) Sessionconducts its conversation by means of a reliableend-to-end Transport connection, which in turn usesthe Network Layer to route the data through the net-work. Details peculiar to the medium which is used(Token Ring, 802.3 Ethernet, etc.) are handled in theData Link Layer, which in turn is dependent on theIowest Physical Layer for the actual electrical andphysical connections between systems.

Transition from TCP/IP to OSI

Since TCP/IP is so successful, one may ask"Why bother?" when it comes to conversion to OSI.The first answer is the promise of applications whichare much richer in function than those available withInternet protocols. Although only a limited numberof these applications are available now, there will bemany more in the future as more customers start touse OSI. The Message Handling System protocols(MHS) can send many more kinds of mail than thetext-based Internet Simple Mail Transfer Protocol(SMTP) can. It defines a general-purpose third-partytransfer facility, with special kinds of structuredmail, such as messages with binary, voice or imageparts, and Electronic Data Interchange (EDI) forexchange of financial information between enter-prises. The OSI global directory service, using theX.500 standard, is already in widespread use, Itenables the location of application programs all overthe world on any subnet which can connect to adirectory service. The new Transaction Processing(TP) standards will allow the customer's TP monitor,database, and application to be purchased from dif-ferent vendors and still interoperate. The Commit-ment, Concurrency and Recoiery (CCR) protocolprovides the two-phase commit needed in TP anddatabase manipulation. The OSI Virtual Terminalprotocol potentially will allow a user to log in to anysystem in the world from any kind of workstation.The File Transfer, Access and Management (FTAM)services provide more than just the file transfer capa-bility of the Internet File Transfer Protocol (FTp),such as remote database access, performing ofactions on the remote files, access control, and han-dling of many different kinds of files.

Crowther, Graham

The second reason for the broad potential ofOSI is that it is composed of standards reached byformal, international agreements. They are thus pol-itically neutral and less likely to change. OSI is inwidespread use in Europe, and is often the networkof choice for large, multi-vendor corporate networks.

The problem of making the transition fromTCP/IP to OSI has been attacked in several differentways. See in particular Marshall Rose's book, TheOpen Book IROSE9O], which contains an entire sec-tion on Transition to OSI. But none of these docu-mented approaches answer the problem of convertingthe X Window System to run over OSI.

One approach is the Application-Gateway.This is a program which converts analogous proto-cols from one suite to the other. For example, anFTAM-FTP Gateway can send files between OSIand TCP/P systems, because it converts FTAMcommands and responses into FTP commands andresponses and vice-versa, The functions of the OSIFTAM must be truncated into the more limited func-tions of FTP. In the case of the X Window Systemproblem at hand, the application running on bothOSI and TCP/P is exactly the same application.Thus no conversion of functionality is required.Although we did in fact write a Gateway, it does notneed to understand the X requests that are made. Itjust passes the X protocol through to the other side,unexamined. A true Application-Gateway must beable to understand the protocol requests of eachdomain and translate them to an equivalent, orcompromise, request in the other domain.

A second transition approach is to use aTransport-Gateway, Transport Service Bridge, orNetwork-Service Tunnel. These methods involverunning the upper OSI layers on top of either TCP orIP. They are handy when you wish to experimentwith OSl-based applications on systems which donot support the OSI Iower layers. In our case, how-ever, we had a TCP/IP-based application whichneeded conversion, and we had OSI oroducts avail-able on all of our systems.

A third approach, the Dual-Stack, is also usedfor unlike applications to talk to each other, andrequires installation of both protocol suites. As withthe Application-Gateway method, this method doesnot apply since we have one application, which wewant to talk directly to the protocol stack on systemswhich have either OSI or TCP/IP installed.

Our approach is a fourth method. We claimthat rewriting TCP/P based applications to run overOSI can be easier than any of the approaches listedabove, if a simple, high level interface to OSI is pro-vided. The job is particularly straightforward if thehigh level interface is the socket interface, sincemany TCP/IP-based applications are written to thisinterface.

246 Summer '92 USENIX - June 8-June 12,l9g2 - San Antonio. TX

Crowther, Graham

Standards

As shown above in the case of both X and OSI,in order for true communication to exist, standardsare necessary, so independent implementations willinteroperate. The X Window System is already a defacto industry standard. The definition of the proto'col between X client and X server will soon be pub'lished as an American National Standard (ANS)

IANSI9U, and will then become an internationalstandard (IS). One of the authors contributed to PartIV of this draft standard, the Mappíng onto OpenSystems Interconnection (OSI) Servíces.

In this mapping, the X Window System appli'cations, client and server, are found in the Applica-tion Layer of the OSI Reference Model. The Asso-ciation Control Service Element (ACSE) managesthe connection between client and server' The clientsends the first X data, which is the Open Displayrequest of the X protocol. This request, and all sub'sequent X requests, replies, events, and errors, arecarried as User Data on Presentation Iayer P-Datarequests.

International consensus has been reached on Xover OSI. The European Workshop for Open Sys-tems (EWOS) has published the E WOS TechnicalGuide 013, A Mapping of the X Wittdow System overan OSI Sr¿c*. This ETG specifies a minimal use ofACSE, Presentation and Session services, knowncolloquially as the "skinny stack," for use with X.In a Guidance for Implementors section, the ETGsuggests that a Transport Layer API be used, andthat fixed headers for the upper layers be prependedto the outgoing data and removed from incomingdata. In work parallel to ours, the University ofLondon Computer Centre, under the sponsorship ofthe UK's Joint Network Team, has implemented this"skinny stack" method on two systems tJl{'fl.

White it may seem obvious that X, being anapplication, should operate in the Application Layerof the OSI Reference Model, this was not ahvays thecase. Initial work in mapping X to OSI placed itjust above the Transport Layer, since it was felt thatthis layer was more closely analogous to TCP

[BRENN91], ICROWC9O]. This placement, how'ever, is not a valid use of OSL The OSI TransportLayer functions are not completely the same as TCPfunctions, and the OSI Reference Model asqignsfunctions to the upper layers which are needed forvalid communication. It was felt that a TransportLayer mapping would not be approved by ISO com-mittees as an international standard since it violatesthe OSI Reference Model. In addition, ApplicationLayer placement allows for future changes to the Xprotocol which can take advantage of the richness ofOSI functionality, such as the ability to address mul-tiple servers, OSI security aspects, and the ability tospecify multiple transfer syntaxes including one forcompressed data.

TCP/IP and OSI Interoperability ...

Implementation

In order to prove the feasibility of X over OSI,we implemented prototypes on AIX and on ttù/oother IBM operating systems - VM and OS/2 -which support the socket interface to TCP/IP bymeans of a user-space application library' IBMships OSI products on all of these operating systems.On the RISC System/6000, the OSI produc't is calledOSI Messaging and Filing, or OSIMF/6000

[OSIMF91]. For VM and OS/2, the OSI product isða[ed OSl/Communications Subsystem, or OSI/CS

Iosrcs].Because the Application Programming Interface

to OSI is different in OSI/CS and OSIMF/6000, dif-ferent approaches were used. This also provided theopportunity of comparing the methods for ease ofimplementation, minimization of changes to the Xcode, network management ability, and ease of con-formance testing.

The goals of implementation of X over OSIacross all th,ree operating systems were the follow-ing:

o Enable X server and X client to support bothOSI and TCP/P protocol families at the sametime. The reason for this goal is that manypotential customers of X over OSI alreadyhave TCP/P installed, and are adding OSI totheir repertoire.

o Enable IBM X sewers and X clients to sup-port only one of the two protocol families, forsystems on which only one is installed. Thisis done by means of conditional compilationand/or selective linking of the X code'

o Minimize changes to the X code. This was agoal even for the approach in which thechanges rrti'ere concentrated in the X coderather than in the socket laYer.

. Maintain existing semantics of the X code.This goal means that, for example, we did notredesign the X client library to do synchro-nous (blocking) IiO, even though this wouldhave made our job easier. The reason for thisis that client applications are allowed to haveconnections to multiple servers at one time.Thus asynchronous I/O must be used'

o Make it as easy as possible for human usersof X clients to specify the OSI addresses of Xservers. OSI addresses are long and diffrcultto type. We wanted to be able to use nick-names, resolved to an OSI address by direc-tory lookup.

o Require absolutely no changes to X clientsthemselves, except to specify that they mustlink with a particular Xlib. There is a largebody of existing X clients. We did not wantto add an invocation parameter to all of these.

o Make no changes to the invocation pæametersfor X servers, so that switching to the

Summer '92 USENIX - June 8-June 12,1992 - San Antonio' TX 247

TCP/P and OSI Interoperability...

enhanced X server is transparent to worksta-lion users.A primary goal of the design of OSI support

was to allow the enhanced server and Xlib to sup-port both OSI and TCP/IP at the same time. Thus,the server can accept connections from bothTCP/IP-based clients and OSl-based clients, if it isrunning on a system on which both protocol familiesare installed. The client linking with the enhancedXlib can connect to either an OSl-based server or aTCP/IP-based server if both æe installed on theclient host. This raised the problem of how ro dis-tinguish which protocol family is desired when theclient is invoked, Currently, with TCP/IP, the serverdesired is specifred as follows:

-display serveripname : x. y

where serveripname is the Internet host name of thesystem on which the server is running, x is thenumber of the display desired, and y is the numberof the screen for that display. DECnet names aredistinguished from Internet names by specifying adouble colon, as follows:

-display serverdecnetname¡ ¡x.yThe Xlib XOpenDisplay routine knows to attempt aDECnet connection if the server's name is specifiedwith two colons following it.

We decided that a similar svntacrical merhod ofidentifying the OSI protocol family would bebeneficial. We selected the following method:

-display serverosiname : ix.ywhere the i identifies the host name as being an OSfnickname used for OSI directory lookup. Thismethod means that the user running the X client canselect the protocol family desired, and there is noproblem with duplication of Internet names with OSInicknames. An OSI nickname is a short mnemonicname for a system or X server. This nickname isturned into a full OSI address (which may be quitelengthy and difficult to remember) by the software.

The X Window System code as distribured bythe MIT X Consortium uses the BSD socket toaccess TCP/IP. The VM and OS/2 design consisredof modifying the existing application socket library(now shipped as part of the TCP/P products) roinvoke OSI at the ACSE/Presentation level, usingthe API provided by OSI/CS. Using this approacñwe rû¡ere able to avoid changing the X code verymuch, and we could take advantage of the OSI upperlayers in the product. Because of this approach'sadvantages, we also implemented an OSI socketlibrary on AIX,

To result in an upper layer OSI socket, two setsof functional modifications tù/ere needed on thesocket architecture. First, the socket architecture asimplemented by IBM was redesigned to match theOSI socket support found in the 4.3 Reno release of

Crowther, Graham

Berkeley UNIX [BSD43]. A new family wasdefined to allow sockets to be declared as belongingto the OSI address family, and new address struc-tures for this family were introduced.

Second, the 4,3 BSD socket design wasextended to. support OSI at the ACSEÆresentationLaye¡ so that it could be used by the X WindowSystem. Three new protocol definitions were pro-vided so that an application can specify that eitherPresentation layer, Session layer, or Transport layerprotocols are to be used by the OSI socket beingdefined. New setsockopt and getsockopt serviceswere added to specify user information, applicationcontext name, presentation context definition list,and maximum length of user information[CROV/T91]. This new information is stored in rhesocket data structure.

Sklnny Stack Implementation

On AIX, the first method tried was to modifythe X server and X client library source code to sup-port OSI by adding conditional compilation of twocommonly used interfaces to the OSI TransportLayer. These two API's are the socket AP[, takenfrom the 4.3 Reno BSD OSI socket imolementation[BSD43], and the X/Open Transport Inìerface(XTI)[XOPEN88], which is an important new standard fornetwork programming and is the one used in IBM'sOSIMF/6000 product.

The goal of this preliminary AIX work was torevise the Xlib and the sample X server code to sup-port the XTI interface to either OSI or TCP/IP, andto support OSI with either the XTI or socket inter-face. Since X is written in a very clean, modularmanner, the changes were confrned to a very fewexisting X routines: four in Xlib and three in the Xserver, plus a new module for each of client andserver. A new module for XTI support, and amodule for OSI support, linked by both client andserver, were added. A new module for OSI direc-tory support, useable by any OSl-based applicationon AIX, was written. Since no OSI directory ser-vices are available with OSIMF. these routinesneeded to be written.

Because the server and client library must beable to support OSI, TCP/IP and UNlX-domain con-nections, a new data structure used bv all connec-tions had to be added. This data shuóture soecifiesthe protocol family and endpoint rype (soèket orXTI). The connectio¡¡.c module of the server con-tains routines for each protocol family supportedwhich make the connection. A minor change had tobe made to each of these to set up this new datastructure. In both client and server, the data struc-ture is tested on each read or write to determinewhich API to use (socker or XTI) and which domainto use (OSI, UNIX, or TCP/IP).

24E Summer '92 USENIX - June 8-June L2,1992 - San Antonio, TX

Crowther, Graham

The OSI and XTI support was added with thefollowing new or modified C language statements:Xlib, 250 statements; X server, 250 statements; newcode used in both client and server, 1000 state-mentsr.

The work for the prototype was done on thebrand-new Release 5 of the XL1 source code. Whenan attempt was made to retrofit the X changes to theproduct release of AlXWindows, which at the timethe work was done was Release 3 of X11, the over-riding disadvantages of using this approach becameclear. It was difficult to do the retrofit work for theserver because key modules had been changed byMIT. The prospect of repeating this work for eachfuture release of X was unpleasant. In addition. wehad invested a lot of time in this work and the resultwas only that the X Window System now workedover OSI, but not any other application.

Because of these two problems, we decided torewrite the code into a user-space socket emulationlibrary, In AIX, sockets are of course part of thekernel. Vy'e wanted to get this implementation work-ing quickly, without the complications of kernelmodifrcation, AIX does not cunently support socketaccess to OSI at any layer. Our socket emulationlibrary, thus, intercepts socket calls in user-space,determines whether this is a real socket or emulatedSocket, and makes the real socket call if requested.The emulated socket code issues the XTI call, andtranslates the return codes to socket return codesbefore returning to the caller. Much of the codefrom the embedded method was used intact in thesocket library. The per-connection data structurewas simply turned into the emulated socket datastructure, set up on every call to the new Socket ser-vice (even for TCP/IP and UNIX domain sockets).The XTI access routires are now called by thesocket emulation library rather than called by X rou-tines.

Since the X code was alreadv written to thesocket interface, changes to use ihis new socketemulatíon library were minimal. Thus retrofittingthese changes to future releases of X will be pain-less.

The number of lines of code for the changesdone by this method was about the same as the pre-vious method, but the number of lines modified inthe actual X code was substantiallv less - under 100for both client library and server. The bulk of thenew code is in separate modules implementing theOSI socket library.

IAll counts of statements in this paper were arrived atby counting lines of code ending in a semi.colon. Thisincludes data declarations, and does not include linesconsisting only of comments, curly brackets, preprocessorstatements, or if (expressìon).

TCP/P and OSI Interoperability ...

_ In both implementation techniques, the upperOSI layers were needed, since in OSIMF/600O iheonly OSI API is to the Transport Layer. Thisrequired implementation of specialized ACSE,Presentation, and Session Layers, thus lending itselfto use of the "skinny stack" method envisioned inthe EWOS Technical Guide. Thar is, the layersimplement only the simple functions needed by theX Window System. On outgoing data, predeter-mined fixed headers for the upper layers areprepended to the X data itself, and passed out overthe Transport layer. Incoming data is more compli-cated; it must be parsed to determine the header typeand format of the data. The headers are strippedfrom the data, and only the X data itself is passed upto the caller.

The advantage to this approach is that the OSILayer implementations were hand-coded for use byTCP/IP-based applications such as X only, Thuitests for the many unused functions of the SessionLayer, for example, were eliminated. The Presenta-tion Layer implementation does not need to handleencoding of general abstract syntaxes. In the socketapproach, these upper OSI layers are embedded inthe socket emulation library, below the socket ApI.

The initial implementation contains no networkmanagement in the upper layers, a disadvantage tothis approach. If we had been able to use a com-plete, general-purpose OSI implementation, networkmanagement would have been included. Anotherdisadvantage to this approach is that the specializedupper layer code must now be tested for confor-mance with standard OSI layers. While the EWOSTechnical Guide restrictions permit simplifred encod-ing of outgoing data, all possible forms of incomingdata must be decoded, and these must all be tested.If we had been able to use a product level imple-mentation of the OSI upper layers, this testing wouldhave already been done.

A rule of thumb for performance of the X Win-dow System is that the round-trip time for communi-cation between client and server should be 50 mil-liseconds or less in order for human perception ofresponse time to be acceptable. Performance of theOSl-based X server and X client librarv was meas-ured by usingxllperf, which is an X client used formeasuring server performance. This client calculatesand displays the round-trip time of communicationbetween client and server before going on to executedetailed tests of the server graphics operations. Thisround trip time was found to be approximately 20ms, with untuned code, which is an acceptable level.This number was dominated by the performance ofthe OSIMF lower layers. Running at Transport layerversus running at ACSE layer made very little differ-ence in the round-trip time.

Summer '92 USENIX - June 8-June 12, Lg92 - San Antonio. TX 249

TCP/P and OSI Interoperability ...

General Purpose OSI Product Implementation

For both VM and OS/2, IBM ships a socketlibrary as part of their TCP/IP products. Weobtained the source code for these libraries andmodified it to support OSI as well as TCP/IP.

On VM, only X client applications are sup-ported. The availability of X over OSI means that aVM customer running only the OSI communicationsprotocol on thefu machine can execute X-basedapplícations on their VM mainframe and take advan-tage of the display capabilities of a bitmap graphicalterminal attached to an X server connected to anOSI network,

The goal of the design for VM ,ü/as to providethe ability for any program using the socket interfacefor network communications to use TCP/IP, OSI andlocal sockets simultaneouslv, In the case of X. thispermits a single client application to communic"tewith multiple remote X servers, some of whichmight be using TCP/P transport protocol and othersusing OSI transport protocols. The socket applica-tion library was modified to support the OSI/CSACSEÆresentation Layer APL This means that thesocket library need not contain an implementation ofthe OSI upper layers, as was necessary in AIX.

The TCP/P socket code was modified to testfor the domain address family on each request. Formost servic¿s, new routines were written for the OSIprotocols and added to the socket library; in a fewinstances existing routines were simply modified touse the OSI/CS API to invoke the appropriateACSElPresentation Layer function. A major benefitof this approach is thai it will allow any ãppfication(not just the X tr¡/indow System!) which uiiiizes thesocket for network communication to replace TCP/Pwith OSI with only minor changes required to han-dle specification of the OSI protocol and addressfamily. As a result, aside from the socket librarychanges, only minor changes to the X library weremade to set up information required for OSI connec-tions.

The OSI implementation used is an IBM pro-duct, and contains network management in all layers,as well as extensive directory services. It allows theclients and server to refer to each other very simplyby nickname, so that there was no need to write ãnyroutines to perform directory lookup of OSIaddresses. In addition, the OSI implementation isalready conformance tested. Thus testing requiredfor thÍs work could be conûned to the socketchanges and X changes only.

The OSI support was provided by adding ormodifying 100 C statements in Xlib, and 1600 Cstatements of socket library code to utilize the ApIprovided by OSVCS, Noie that this is about thesame effort as the AIX X code modifications, eventhough the AIX code is implementing the upperlayers themselves, and the VM code is using an ApI

Crowther, Graham

to the upper layers. On first examination the numberof lines of code that was added to the socket libraryto provide these services might seem surprising.However, an examination of the code reveals thatthere are three factors that account for this size.First, the socket library changes represent a generalpurpose implementation of services that are notoptimized for usage by X. Modifications were madeto provide consistency with the framework of theexisting socket library structure. TWo, because Xcode handles multiple connections at once, for thisimplementation most OSVCS callable services areperformed asynchronously and control is returned tothe issuing socket routine as soon as the callable ser-vice is received by OSVCS, but before the action iscomplete. Return indicates only that the parametersof the OSI service have undergone a preliminarystage of validation, and that the call has beenaccepted (or rejected) for further processing. Thismeans that for each asynchronous OSVCS servicecall that was used, an additional test had to be addedto the socket code to determine the results of thispreliminary validation. And finally, all return codesand error conditions that are received from OSVCSmust be converted to corresponding socket retumcodes and eror conditions. Due to the large numberof possible codes and conditions that can be returnedfrom OSVCS, a significant portion of the new coderepresents tests that are performed in the event thatan error condition is received, and the subsequentconversion of these codes and conditions to socketcodes and error numbers.

On OS/2, IBM cunently ships an X server,called PMX, and no X client library. Availability ofan OSl-based X server means that clients running onan OSl-based system can display on the PS/2 works-tation. X server requests that are received from anX client program are interpreted and OS/2 Presenta-tion Manager (PM) requests are used to control theworkstation's bitmap display. Keyboard and mouseevents, error notifications, and request replies fromthe server are packaged in X protocol packets andtransported over the network to the client.

Since IBM provides OSI support for OS/2 withits OSVCS product, we originally planned to imple-ment the )VOSI support using an approach similar tothat used in the VM implementation; we wouldmodify the socket code allowing application pro-grams to remain largely unchanged. TCP/IP socketsource code for OSl2 V2 was obtained, and theimplementation designed using this model. How-ever, pending the availability of a OS/2 V2.0 Ether-net device driver for OSI/CS, it was necessary tochange the design to use an approach similar to thefirst AIX implementation - modifications and addi-tions were made to the PMX server. The OS/2 Xserver code code performs all tests for protocol fam-ily determination, and invokes the calls to theOSVCS API as required.

250 Summer '92 USENIX - June 8.June 12,1992 - San Antonio, TX

Crowther, Graham

As in the first AIX implementation, since thePMX server code has been modified this currentOS/2 implementation will require that the changesbe retrofitted whenever there are changes made tothe PMX code on which it is based. Fortunately,modifications to existing server code was confined totwo modules with 100 new C statements added. Alladditional changes were implemented in three newmodules, representing an additional 1700 C state-ments. As in the case of VM, these new modulesprovide general purpose OSI functional equivalentsof socket service requests, and are available to anyapplication. However, since these changes were notmade to the socket library (due to the device driveravailability problem previously mentioned) applica-tions must explicitly call for the OSI version ofrequests (e.g., osi socket, osi_listen, osi_read, etc.).

Finally, as in the case of the VM implementa-tion and in contrast to the AIX implementation, theOSI support is provided by the IBM OSVCS product,and therefore a complete OSI implementation includ-ing network management, extensive directory ser-vices, as well as conformance testing are all pro-vided by this product.

X TCP-OSI Gateway

A typical customer who is beginning to installOSI will have some systems running OSI, but somewhich are still running TCP/IP. The customer willwant to use the X Window System to communicateamong all of these systems. To satisfy this need we

TCP/IP and OSI Interoperabitity ...

implemented the X TCP-OSI Gateway. This pro-gram reads data on one protocol family and writes itout on the other, thus connecting clients and serversrunning different protocol families. It runs on AIXand VM.

Figure 3 shows a diagram of a mixed networkwith some systems running TCPiIP and some run-ning OSI. Through the intermediary of the X TCp-OSI Gateway, these systems can talk to each other.

The Gateway appears as an X server to normalX clients, and appears as an X client to normal Xservers. It must be able to interpret addresses inboth OSI and Internet address domains. It runs on asystem which has both OSI and TCP/P installed.The Gateway was written by adapting some of thenetwork communication routines found in the server,and linking with Xlib to use the network communi-cation routines found in the client. The Gatewavdoes no interpretation of X protocol requests orreplies. It simply passes them uninterpreted to theother side. Because of the specific data exchangemade when an X client connects to an X server, thisGateway will work only for X. However similarwork could be done for other distributed applica-tions.

Future I{ork

Now that we have OSI socket libraries we planto port other socket-based applications to OSL Can-didates for this work include TELNET, FT?, NFS,x3270. This will enable users to maintain their

Figure 3: Use of X TCP-OSI Gateway

Summer '92 USENIX - June 8.June lZ,lgg2 - San Antonio, TX 251

TCP/P and OSI Interoperability ...

productivity with familiar network tools, whileadding new OSI applications to their repertoire.

Concluslons

The problem of moving a TCP/IP-based appli-cation such as the X Window System to OSI wasaddressed. Different approaches were taken in dif-ferent operating systems and these were compared.The "skinny stack" approach was used in AIX. Spe-cialized, minimal function OSI layers were imple-mented by prepending the OSI layer headers to datasent using a Transport Iayer APL This approachminimizes the path-length required for OSI, butmeans that we could not take advantage of upperlayer network management or conformance testing.

When the "skinny stack" code was embedded inthe X source code, retrofitting problems arose. Onsystems where the socket interface is found in auser-space application library, the socket wasmodified to access OSI at the Application Layer.Modification of an existing socket interface to sup-port OSI means that the changes to existing X Win-dow System product code can be confined to under100 lines of code. This method proved to be sosuperior in terms of minimization of changes to theX source code and usefulness for other applications,that a user-space "socket" library was implementedon a UNIX system where sockets are found in thekernel. Proper implementation of an OSI upperlayer socket clearly requires kernel changes. Oncethe socket modifications are made and tested, theycan then be used by any application written to thesocket interface. The socket implementation can usean upper layer access to OSI if this is available tokernel code (often it is not), or can implement the"skinny stack".

Although direct performance comparisonsbetween the "skinny stack" method and general pur-pose OSI layer method could not be made since bothmethods could not be implemented on the sameoperating system, one would suspect that a "skinnystack" would exhibit higher performance. However,a general purpose stack can be implemented in sucha way that a fast path is used for applications whichdo not use the complicated features.

For operating systems which are slow to imple-ment OSI, a Gateway can be interposed betweenclients and servers in different protocol domains.This Gateway is particularly easy to write if a high-level interface such as the socket is available forboth domains.

Based on our experience, we advocate thatcommon network API's such as sockets, XTI, andTLI, should be modified to support OSI at the Appli-galion layer as well as the Transport kyer.

-The

OSI upper layers should contain network manage-ment and directory support, and should be confor-mance tested. The simplifications and fast-path

Crowther, Graham

approach highlighted by the "skinny stack" should beused as much as possible. When these high levelinterfaces are available in operating systems, existingTCP/IP-based application which are now inwidespread use can be rewritten with only minorchanges to run over OSI.

Although these experimental prototypes are notavailable to customers, they point the way towardsolution of the problem of migrating all TCP/IP-based applications to OSL An OSI upper layersocket, which implements the most basic, simplifiedfunctions of Session, Presentation, and ACSE, canbe used by all socket-based TCP/P applications.Since the more complicated functions of the OSIupper layers were not available to them, they eitherdo not use them, or implement them in other ways.This capability is critical for users who want tochange to OSI in order to comply to the GovernmentOSI Profile, or who want to start using the rich func-tionality of OSI applications, or who want to com-municate with European OSl-based networks, but donot want to give up using their TCP/IP applications.

Acknowledgements

We wish to thank our management at the IBMCambridge Scientific Center, Bob Anderson andDick MacKinnon, for funding and encouraging thiswork. Jeny Mouton of IBM Nenvorking Systemshad the original idea for the OSI upper layer socket,and both he and Keith Sklower of the University ofCalifornia made contributions to the design of thissocket. We would like to thank Jay Elinsky andOleg Vishnepolsky of IBM Watson Research, andthe PMX team at Cambridge - Allen Springer, BillBarrett, and Rod Maxwell - for making their socketlibrary source code and PMX source code availableto us.

Bibliography

[ANSI9l]X3.196-199x, X Window System DaraStream Definition. Part I, FunctionalSpecification Parf II, Data Stream Encoding,Part III, KEYSYM Ettcoding. Part IV, Mappingonto Open Systems Interconnection (OSI) Ser-yices. Revised November 20, 1991.

[BRENN9l] Brennan, Thompson, and Wilder, Map-pittg the X Window ortto Open Systems Inter-connection Standards, IEEE Network Maga-zine, May 1991..

[CROWT9l] Crowther, X on OSI, Xhibition 9tConference Proceedings, Integrated ComputerSolutions, June L991.

[BSD43] Manual pages for socker calls in 4.3 Renorelease of Berkeley Software Distribution, Sec-tions 2 and 4, Computer Systems ResearchGroup, Computer Science Division, Univ. ofCalifornia, Berkeley, Calif, May 30, 1990.

[CROWC90] Crowcroft, J., Experience with mappingthe X wittdows protocol onto ISO transport

252 Summer '92 USENIX - June 8-June 12,1992 - San Antonio, TX

Crowther, Graham

service,", Networks 90 - Network Management.Proceedings of the International Conference,Birmingham, UK June 1990

[DYER90] Dyer,"X TVindows over OSI", Report ofJoint Network Team, Rutherford AppletonLaboratory, United Kingdom, October 199b.

[EWOS91] EWOS Technical Guide 013, A Mappingof the X Window System Over an OSI Stack,European Workshop for Open Systems, 2L May799t.

[GOSIP88] U.S. Government Open Systems Inter-connection Profile (GOSIP), U.S. Federal Infor-mation Processing Standards Publication (FIPS)1.46, Version 1, August 1988.

[IS7498] ISO 7498, Information Processing Systems- Open Systems Interconnection - Basic Refer-ence Model, International Organization forStandardization, Geneva, Switzerland (1983).

[IS8823] ISO 8823, Information Processing Sysrems- Open Systems Interconnection - Connectionoriented presentation protocol definition,Geneva, Switzerland (1988).

[JNT] Peter Furniss and Kevin Ashley, personalcommunications with the authors.

[OSICS] OSllCommunications Subsystem GeneralInformation Manual, GL23-0184, IBM, paloAlto, California, March 1990.

[OSIMF91] AIX Version 3 for RISC System/6000OSI Messaging and Filing/6000, User's andSystem Administrator's Guide, Second Edition,SC32-0012-01., IBM, Palo Alto, California,September 1991.

[ROSE9O] Rose, The Open Book, Prentice Hall,1990.

[SCHE9O] Scheifler & Gertys, X Window System,Second Edition, Digital Press, L990.

[XOPEN88] )VOpen Portability Guide 3, Volume 7Networking Services, )VOpen Company, Ltd.,Reading, Berkshire, United Kingdom, 1988.

Author Information

Nancy Crowther has been at IBM for 15 years.Most recently she has been a Staff Member at theIBM Cambridge Scientific Center, where she hasworked in the area of networking software. She alsoworked for Informatics at NASA/Ames ResearchCenter where she did scientific applications for 6years. She has an M.S, in Applied Mathematicsfrom the University of Santa Clara and an A.B. inMathematics from Rutgers. Reach her via US Mailat IBM, 101 Main St., Cambridge, MA 02!42, orelectronically at [email protected].

Joyce Graham is a Staff Member at the IBMCambridge Scientific Cenrer. Prior to joining IBM,she worked at United Technologies Pran & WhitneyDivision as a research engineer, and at the Mas-sachusetts Institute of Technology as a scientific pro-grammer, user consultant, and systems programmer.

TCPÄP and OSI Interoperability ...

Since joining IBM in 1.981, she has worked in theareas of operating systems, user interface, and net-work communications. Ms. Graham received a jointB.A./8.S. (Aeronautical Engineering) from NewYork University. She may be reached [email protected] or via US Mail at IBM,101 Main St., Cambridge, MA 02L42.

Summer '92 USENIX - June 8.June 12, Lgg2 - San Antonio, TX 253