X.25 Protocol

A history of the X.25 Protocol
Tim Elliott
Morrisville State College

Abstract
X.25 is a Wide Area Network standard suite of protocols for packet switching developed by the International Telecommunication Union-Telecommunication Standardization Sector in the early 1970’s. It was designed to support traditional data networking over telephone wiring. Though widely used in the 1980’s, it has been largely replaced by newer IP standards such as frame relay. The purpose of this protocol is to effectively transmit data between different types of systems across a public data network. The main communication groups that ran this form of packet-switched network were the telephone companies but as technology has moved away from these slower forms, the public sector has seen this all but disappear in America. It should be said though that many places around the world still use this because of the cost to upgrade to newer hardware, but that market segment is shrinking quickly.

A history of the X.25 Protocol
In this paper, I will be talking about many of the technical aspects, the history and some of the situations where the X.25 protocol is still in use today.
In Section 1, I will talk about where it fits on the OSI layered architecture and discuss the Network and Data Link layer. In Section 2, I will describe some of the common equipment that this protocol used with the Physical Layer of the OSI model. In Section 3 I will discuss some of the problems that have been found from the protocol. Finally in Section 4, I will describe some of the areas that this is still in use today.
Section 1
The X.25 protocol truly encompasses the first three layers of the OSI model. Within the Data Link Layer, the protocols role is to exchange data across a physical link and assure that it comes through the other end intact. It has the ability to detect errors and make corrections while in use. The main procedure used by X.25 is LAPB, the Link Access Procedure Balanced. This was designed to be able to send frames between nodes in a way that was dependable and in a correct order so that the information would not become corrupted.
The first phase was the disconnected phase. This was the period that the node was not sending or receiving data. Although it was usually a phase that nothing was literally done, some data terminal’s sent out a signal before making a connection to verify that the node on the other end was not communicating with another machine. If the node on the other end was turned off, this would also alert the machine that there was no one to communicate with.
The second phase was the link setup. The node initiating the connection sent a Set Asynchronous Balanced Mode command frame, or SABM . The receiving node would reply with an acknowledgement that a connection could be made.
Once connected, there is an Information Transfer phase. This allows layer three to send its data packets to the node on the receiving end. Although it is an older standard, it has the ability to run full-duplex on over the telephone wires that this system typically runs on. When there was a high level of traffic, the cabling offered
Once all the packets are sent, the sending node sends a request to drop the connection in the Link Disconnection Phase. When the receiving node receives it, it verifies that it will drop the connection by sending a reply. If the receiving machine does not receive the request and has not received any packets within a limited time, it is assumed the transmission is done and drops the connection.

Because the X.25 protocol came out before the OSI model, its network layer was called the packet layer but translates to its equivalent. Any packet sent using the packet layer begins with a header that is three bytes long with the first four bits containing a General Format Identifier. This tells the node which of the two sequence numbers format is being use to send the data. It also contains a Logical channel number and packet type identifier. Attached to the data is a sequence number that tells the receiving node what packet to expect next. The packets will allow the receiving machine to know more data is coming, confirm data is sent and even run a parallel channel used for control information. If any data is corrupted or not received, the receiving node can send a message to stop the flow of data till it can get the missing data resent. If the sender does not send it, the receiver cannot ask for another file resent until the first one is received. Although it was possible for packets to be sent at a maximum size of 128 kbps, the most common size of data was 64 kbps. This was due to the hardware capabilities at the time although some standards such as X.21 could support up to 2 Mbps. Several virtual circuits could be routed through the cabling to make this a true multiplexing environment. This made X.2X series of protocols very popular when it was first introduced.
Section 2
A X.25 network is typically comprised of DTE’s (Data Terminal Equipment, DCE’s (data Communication Equipment, Pad’s (Packet Assembler/Disassembler) and a PSE’s (Packet Switching Node).
Data terminal equipment is the initiator or receiver of data that is sent over a serial connection, used on an X.25 network. The data it sends or receives is converted into a form that the user can understand in a graphical user interface shown on a monitor. As the name implies, this is where information will go and the circuit is ended. These machines can be terminals, personal computers, or network hosts. Many of the earlier, less powerful terminals, deemed “dummy terminals”, did not have the capacity to send out information that was suitable to go out over the network. These machines needed to be attached to Packet assembler/disassembler with data coming out of their async port. As terminals gained in power, PAD’s were no longer needed, and these terminals outgrew the need for the X.25 protocol.
When these devices, such as a character-mode terminal, are too simplistic to work on the network, they are attached to a Packet assembler/disassembler. This connects simple DTE’s with DCE’s by taking information the terminal had, and relaying it to the DCE in a way that a network device could understand and move. It has the ability to buffer information, convert the data, and then send out it out to a DCE. Oppositely it could receive packets, break them down so a dummy terminal can understand the data and relay it. These were really the external computing/network cards of lower end nodes. These were eventually phased out by the ever increasing power of terminals.
Data communication equipment (DCE) is the devices that connect to the terminals and the packet switching nodes. These are most typically modems and switches. Their function was to relay information between terminals and PSE’s. Other than just acting as a repeater for the signal, DCE’s had the important function of coding the data. This was where the sender could send data that had a redundant stream in case any data got corrupted along the way. The terminal receiving the information or another DCE for that matter, could see the error when compared to the redundant stream and disposed of it. This made for better error correction on the fly, but more data traffic to be used. Because you paid for your bandwidth by how much you used, this could double your operating costs when you have very few errors. This was a good option if you had a large amount of throughput and many machines, but if you had a small amount and had very few errors, the cost could far outweigh the gains.
Within the center of the network, are the packet-switching exchanges. These devices store and forward a bulk of a network’s data transmissions between DTE’s. These switches sent information to other terminals as a switching mode known as a virtual circuit. This was where it created and established connection between machines and then sent pre-allocated information that used a connection identifier instead of an address to send the data to. The virtual circuit would stay open until the session had ended. In cases where users wanted the connection to stay up permanently, they could use a permanent virtual circuit.
Section 3
A major disadvantage of using the X.25 protocol is performance when compared to newer protocols. Because it uses redundant data transfers, it can hamper the speed of your network. When errors are found, the terminal stops to figure out where the error came from by checking the redundant file sent. All this double checking slows the node down. Newer protocols drop corrupted packets and have all the packets resent. This speeds up the node because it is not searching or trying to fix errors, getting a replacement is quicker and easier. Because most of these older networks still have older telephone cabling, this further shows the networks down because telephone cables.
The lack of adaptability also hampered the protocol. Because it was set up for mostly old, unsophisticated devices, adding new machines that were more powerful would be a waste on the system. As machines grew in power, better forms of data transmissions were formed to fully utilize their potential. Because most businesses wanted newer devices, it made sense to phase this out.
When frame relay replaced X.25, it did packet switching on its network layer. When compared to Frame Relay, which did its switching on the data-link layer, it was noticeably slower.
Section 4
X.25 is still used today despite its many drawbacks compared to TCP/IP. One of the main areas where it is still seen today in the United States is in ATM and point-of-sale terminals. Because of the low data rates these machines use and virtually no reason to replace it, it’s still a good solution to use. Unfortunately the equipment that these machines use are getting rare and eventually they will all be replaced by newer networks. It has become more cost effective to replace it with newer machines that are in higher production. In Asia, the aeronautical business very much still uses X.25 to interconnect airfields. Because these networks still work, it makes very little sense to put a lot of money into replacing them. But as we have seen, with the shrinking amounts of X.25 hardware out there, it will inevitably be replaced by newer, more dependable networks. Even though most of the world has transitioned to tcp/ip, certain telecommunications companies are still using it as well for a consumer market. As of right now, about 2 million French users are using X.25 until the ISP shuts down the service by the middle of 2012. Solutions and Problems with X.25

The idea of making X.25 was to create a low cost alternative for data communication over public networks. In the early days of networking, it was costly to send any type of data because networking fees were so expensive to have. It was a major advancement to only have to pay for the bandwidth someone used. This allowed smaller companies to get connected to a network without paying a huge amount of money for doing very little. This lower cost helped networking become cost effective and spread to more and more companies. Another positive was the fact that the protocol could work on insufficient cabling. Since the network was not doing anything when not sending information, the cabling was not used and could handle the little traffic that it got. When there was a problem with sending data over the network, especially a poor one, X.25 incorporated error detection and correction which allowed the nodes to keep communicating and not have to restart due to dropped packets. This allowed many places to send data without having to replace all their wires, which lead to a spread of the X.25 protocol. For its time, the speed of the bandwidth was quite well. Although most terminals sent data at 64 Kbps and could send up to 128 Kbps, X.25 could support speeds of just 9.6 Kbps to 2 Mbps. There was also support for up to 4095 virtual circuits over a DTE-DCE link trough multiplexing.
A major problem facing X.25 was the lack of technology used in all aspects of it. Most of the terminals had very low abilities and as personal computers have gotten better, it has made many of the features redundant to have on a network.

References
Hunt, R. (1996). Frame relay: protocols, architecture, operation and performance. Computer Communications, 19, 830-847.

Arora, R.K., Khanna V. K. (1995). Design of a kernel for implementing communication protocols. Microprocessing and Microprogramming, 41, 469-485.

Kanna, V.KF. (1996). A suggested protocol for Internet access on PSDNs. Journal of Systems Architecture, 44, 909-912.

Katsavos, P., Varadharajan, V (1997). High speed network security. Computer Communications, 20, 832-847.

Tredinnick, I. (1995, June). X.25: A new lease on life with ISDN. Telecommunications, 29.6, 59.
West, C. (2010). Some notes on the history of protocol engineering. Computer Networks, 54, 3197 – 3209.

Djavanshir, R. (1996). A review and evaluation of networking technologies. Telematics and Informatics, Vol 13, pp. 33 – 48.

Purser, M. (1988). X.25 The Fulcrum for Network Standardization. Computer Communications, Vol 11, pp. 234 – 238.

(1998) X.25 Network Support. IBM AS/400e. Version 4 Manual

(2011) X.25 Protocol. Performance Technologies Inc. Manual