Tunneling X.25 in TCP/IP (X.25 over TCP/IP, XOT)

X.25 Packet Switching Data Networks (PSDN) are disappearing nowadays. However, there are many applications that depend on X.25 hardware and software. Migrating these applications (that run on legacy systems or mainframes) to use modern networks is a major effort. Thus, replacing X.25 networks with TCP/IP is a fast growing market. Many customers choose XOT (RFC 1613), unaware of other possible solutions. Branch offices use terminals emulators connected to terminal controllers through LANs. Their terminal emulation software is far simpler to change than the central applications. Besides, eliminating the X.25 equipment and its maintenance results in large savings. In this page you will find XOT and some alternate solutions to this challenge using our PXS: XOT RFC 1613 Cisco-Cisco XOT RFC 1613 Cisco-PXS or PXS-PXS XOT RFC 1613 Cisco-XOT LayGO Client aXOT PXS-aXOT LayGO Client (Advanced XOT) Remote Procedure Calls (RPC) X.25 to TCP/IP Gateway

A Typical Legacy X.25 Network

For example, for a Pacific Bell (SBC) project in 1998 we used an XOT client to communicate to more than 400 Cisco routers (XOT servers) connected to Nortel DMS/100 and Lucent 5ESS phone switches, using a configuration similar to the one depicted in the "XOT RFC 1613 Cisco-XOT LayGO Client" section. This was a suitable solution since SBC uses the same application to access other switches through standard 19.2 kbps RS-232 X.25 connections. Our LayGO API is not aware that the underlying X.25 uses LAPB, LAPD or TCP/IP.

In another example, in 2004 we used our newly-released PXS (Protocol eXchange Server) in a project for Cable & Wireless Europe. We replaced nine Cisco XOT routers and nine AFT/X.25/XOT CDR file collectors with the PXS. We now terminate the AFT/X.25 at the nine DMS/100E using a file client/server module to transfer CDR files from the nine DMS/100Es to only one collector. This project uses the same design principles explained in "X.25 TCP/IP Gateway"

We recommend terminating the X.25 protocol at the mainframe site and switching the data onto a TCP/IP connection. This may require modifying the current application to replace the proprietary X.25 API with a socket interface, but this investment is worth the effort.

X.25 over TCP/IP (XOT) RFC 1613 Cisco-Cisco

X.25 PSDN replaced by TCP/IP network using Cisco XOT routers

XOT (X.25 Over TCP/IP) RFC 1613 is a solution where all ends use X.25 equipment and the Inter/Intranet replaces an X.25 Packet Switching Data Network (PSDN) or point-to-point X.25 leased line connections. PSDNs are more expensive, slower, often charge for traffic and number of virtual circuits, and for that reason are fast disappearing. Most companies using PSDNs are already using alternative Inter- or intranet or WAN TCP/IP connections. Cisco, the major supporter of RFC 1613, addressed the need of tunneling X.25 data through a TCP/IP connection without making changes to the existing X.25 connections. Cisco routers terminate all end-points by connecting their X.25 port to the customer X.25 equipment.

Under RFC 1613, X.25 packet level data are encapsulated into a TCP/IP stream. The second 2 bytes of a 4-byte header define the size of a following packet. There is no LAPB layer traffic, and there is no LCN0 traffic. SVCs are established via Call Request/Call Accepted packets, facilities for packet and window size are mandatory. Each VC uses one TCP/IP connection.

Go to top

X.25 over TCP/IP (XOT) RFC 1613 Cisco-PXS or PXS-PXS

If the customer X.25 implementation predates the X.25 1988 recommendation, the Cisco XOT will most likely require an update for the X.25 software, particularly if non- standard defaults for packet and window sizes are used. If so, instead of using the Cisco router at the branch offices or the central office, the PXS can be used without these limitations.

PXS replaces XOT Cisco routers

Go to top

X.25 over TCP/IP (XOT) RFC 1613 Cisco-XOT LayGO Client

Since branch offices are far more numerous than mainframe sites, the elimination of the X.25 hardware at these sites results in large cost savings and increased line speed. With the X.25 PLP data encapsulated into TCP/IP, the X.25 packets can be extracted and processed in an X.25 PLP module.

LayGO XOT Client

(Click to enlarge) LayGO XOT Client Protocol Stack Diagram

At the receiver, the X.25 packets are routed to the lower edge of the packet layer using the LayGO Return Layer. They are then decoded as if they had arrived from the LAPB or LAPD layer. At the transmitter, the X.25 packets are routed from the lower edge of the X.25 packet layer to the XOT client using the LayGO Return Layer. The XOT client also emulates the LCN0 traffic. The LayGO application is unaware that XOT is used. In addition to XOT, RPC can be used to support multiple local or remote simultaneous processes.

Advanced X.25 over TCP/IP (aXOT) PXS-aXOT LayGO Client

If the X.25 connection is point-to-point, tunneling of X.25/LAPB or X.25/LAPD (whole HDLC-frame) or advanced XOT (aXOT) is an option. Instead of having one socket for each virtual circuit, one socket is used for each major X.25 device.

With aXOT the complete HDLC with LAPB or LAPD header and the X.25 packet are encapsulated into TCP/IP. The same encoding would work for SLDC type protocols, such as SNA.

(Click to enlarge) LayGO aXOT Client Protocol Stack Diagram

At the receiver, the LAPB or LAPD frame is routed to the lower edge of the link layer (frame level) using the LayGO Return Layer. They are then decoded as if they had arrived from the X.21 layer. At the transmitter, the LAPB or LAPD frames are routed from the lower edge of the X.25 link layer to the aXOT client using the LayGO Return Layer. The LayGO application is unaware that aXOT is used. In addition to aXOT, RPC can be used to support multiple local or remote simultaneous processes.

Go to top

X.25 over TCP/IP through Remote Procedure Calls (RPC)

A different approach is to access a front-end X.25 device such as the PXS or a PC using LayGO X.25 hardware and software. In this case only LayGO API calls are redirected through the TCP/IP connection. A read or write RPC client function will pass the user data to a read or write RPC server function which accesses the LayGO protocol stack at the PXS.

RPC LayGO Server - Client

(Click to enlarge) RPC Remote LayGO Protocol Stack Diagram

The PXS can be accessed from any of the LayGO client applications.

Go to top

X.25 to TCP/IP Gateway

All of the above options have one disadvantage: the application at the branch offices is still burdened with using a proprietary X.25 API. This may be a temporary solution to replace at least the X.25 PSDN with a TCP/IP WAN. Ultimately it will be far better to eliminate the X.25 applications altogether from the branch offices and replace them with a socket application.

X.25 to TCP/IP Gateway with PXS

(Click to enlarge) X.25 to TCP/IP Gateway LayGO Protocol Stack Diagram

The PXS handles and terminates the X.25 connection (and possibly Application Layer protocols) to the mainframe. Data received from the mainframe (payload) are forwarded via TCP/IP. As in XOT, a 2-byte header or a terminating character can be used to define the length of the data. Data received from the TCP/IP WAN are forwarded via X.25 to the mainframe.

A similar architecture can be used to replace PSDN X.25 virtual circuits connecting terminal emulators to a mainframe. A PXS running a telnet server listens to connection requests arriving via TCP/IP. One of the synchronous ports connects to the mainframe, using X.25. Each telnet session is assigned an X.25 virtual circuit. All the X.25 protocol is terminated at the mainframe site. Any terminal emulator that supports telnet can be used.

Go to top