DTJ Number 3 September 1987 - Digital Technical Journals

Te rminal Servers onEthernet Local Area NetworksBruce E. Mann[ Colin Strutt!Mark F. Kempf IDigital's terminal servers provide flexible, cost-effective connectionsbetween terminals and host systems in a local area network (LAN). Theproduct developers tried several approaches before developing te LocalArea Transport (LAT) protocol as the basis for all terminal servers. TheLAT architecture supports connections to multiple hosts over: a highbandwidth Ethernet LAN. LAT establishes a single virtual drcuit 'betweena terminal server and each host, and individual sessions are multiplexedover a virtual drcuit. A unique directory service permits terminal serversto be configured automatically, learning about hosts as they becomeavailable. The latest implementations support mixed-vendor environmentsand Digital's major operating systems.The Original ProblemIn 1981, Digital faced the task of designing amethod for connecting a few hundred "dumbterminals" and printers to a VAXcluster system.If, as in the past, the terminals were connected toa single computer, then many of the advantagesof clustering would be negated. Instead, it wasproposed that terminals be connected to a"front-end" terminal server shared by all membersof the cluster. This front end would thenallow more flexible connections. A user terminal,for example, could connect to any processorin the VAXcluster group, rather than directlyconnecting to just one. Our goal was to migrateour existing installed terminal base gracefullyfrom single-processor attachments to VAXclustersystems.The original effort to provide this server wascalled the CI-Mercury project by our developmentgroups. We aimed to attach this terminalserver directly to the high-speed cluster interconnect,called the CI, so that the server functionedas a switch. However, the cost of thisscheme proved to be excessive. (The cost for theinterface to the CI itself was about $20,000.)Moreover, a connection to the CI would haveresulted in a server that could connct only tonodes in a single cluster.We also studied other vendors' switch offeringsas front-end terminal switches. These productsfunction much as do the dataswitch prod-ucts available today; thar is, backplane multiplexerson the CPUs are switched to the terminals.The problems with! this approach wereexcessive cost, the lack ofl Digital technology inthis product area, and po9r availability.Because of these complexity and cost factors,the original CI-Mercury project was replacedwith one called Pluto. This project envisionedusing an Ethernet as the interconnect, thuslowering the attachment cost dramatically.This server was based on a PDP-11 central processor,and we chose a variant of the RSX- 11Soperating system for the initial kernel software.The lower-layer communiCations protocols usedbetween Pluto and the V Ax cluster nodes werethe DECnet protocols, suc b essfully used in otherproducts.j .We believed that Pluto could be cost effectivein large installations; how ver, its initial cost wastoo high to be competitive in smaller configurations.This cost factor was especially important asEthernet became an integral part of Digital'sstrategy. With Ethernet, it became practical andcost effective to distribute small terminal serversthroughout an office environment rather thanconcentrating all termina interfaces in a large,centrally located server. Therefore, in late 1981,work began on an eight-line terminal server, theIprimary goals being low 'cost and high performance.Internally, this pnhect was dubbed PlutoJunior, later called Poseidbn.Digital TecbnicaljournalNo. 3 September !98673