Linking LANS with X.25 gateways

Communications News, May, 1990 by Mark Luczak

LINKING LANS WITH X.25 GATEWAYS

Despite the proliferation and interconnection of LANs, the goal of total connectivity is unattainable unless you include remote users needing access to a LAN-connected host.

They have either asynch terminals or PCs and are usually at small remote offices. Though many strategies exist for remote terminal-to-host communications, connecting a remote terminal across a WAN to a host residing on a LAN is more complicated.

First, make a cost-effective connection between the remote site and host. Provide a cost-effective standards-based path between nodes.

X.25 is a WAN standard for remote access from individual remote-user terminals to one or more hosts. X.25 networks should be considered when traffic levels are too small to justify a dedicated transmission line between each site, the processing environment has hosts from several different vendors, or global communication needs dictate a standards-based network that won't lose data during a network outage.

Next, make sure once a link is established that remote users can access hosts attached to the LAN.

The past few years, the personal computer has replaced much of the remote-terminal population, resulting in PC LANs. Often, at corporate headquarters, hosts are linked to each other by LANs. Corporate PC users connected to each other and access hosts by the LAN as well.

Make it Easy

Once the LAN is implemented, network users are understandably reluctant to give up any of the benefits that prompted the installation of the LAN in the first place.

The challenge is to make the communcation between the remote users and the host as transparent as possible The demand for a cost-effective connection between these PC LANs has sparked renewed interest in packet switching.

Industry experts now expect the number of installed X.25 packet-switching networks to triple by 1992.

How to access the LAN from the X.25 newtwork? Connect the LAN to the X.25 network with a packet-switching inteface installed in a host processor or a stand-alone X.25 server/gateway.

The first method involves installing X.25 software on a host to which all users of the X.25 network have access. This is known as a host-based or host-specific approach. The X.25 software runs as an application on the host.

Let's say a company has four hours processors at corporate headquarters, interconnected via Ethernet. Remote nodes, in Europe, use an X.25 network to access the hosts. One host is equipped with X.25 software and the necessary hardware to interface to the packet-switching network.

Host-based packet switching interfaces (PSI) cost about $15,000 per host.

The host represents a single point of failure in the link between users and other hosts on the Ethernet. If it should fail, uses on the X.25 network lose access to all hosts.

Also, since the same processor is used for both X.25 handling and DP, heavy usage of the X.25 network will slow down other applications running on the same host.

Top Versatility

The other method is to use a communications server/gateway, like Infotron's Commix 32 LAN server, to access the X.25 network. In this host-independent approach, users on the X.25 network can access any host on the Ethernet, as in the previous example. The difference: Now the hosts are fre from any X.25 network processing and handle only applications processing. Any of the hosts could fail, or be shut down for periodic maintenance, withou blocking user access to the otehrs.

A server/gateway costs half as much as the host/PSI interface. Two gateways could be used to eliminate the X.25 interface as a single point of failure. Relieving the hosts of X.25 handling also improves response time.

To allow devices made by different vendors in the same LAN to talk to each other, a set of internet protocols, such as TCP/IP (Transmission Control Protocol/Internet Protocol), is used. The gateway converts the TCP/IP protocol into X.25. Then, at the remote node, X.25 traffic is converted into whatever protocol is required there. A VAX, say, can communicate with terminals attached to Ethernet using a DEC/LAT (DEC Local Area Transport) protocol for better response times; the transmitting device need not wait for remote acknowledgements. The gateway locally generates responses to the TCP/IP or LAT protocol. The protocol is regenerated at the other end, so the process is transparent to users. It's like all devices are attached to one network.

Reduces Overhauls

The server/gateway minimizes the need to replace remote user equipment. Asynch terminals or PCs in TE mode, when attached to the server/gateway, can access remote hosts across the X.25 network without using a separate X.25 PAD. And the terminals and PCs can access TCP/UP or DEC/LAT hosts whether those hosts are attached to the same LAN as the server/gateway or on a remote LAN accessed via X.25.

All protocols used by the server/gateway are standards-based. The ability to conform to standards on both the wide-and local-area portions of the network is significant. Compliance with X.25 standards on the WAN means the users can access any other resource, such as an X.25 host, also attached to the network without another gateway at the host site. Once traffic is converted to X.25, it can be sent directly to any X.25 host also attached to the network.