X.25 dial-up packet network
Dear habrovchane, I want to tell you about packet switching networks, built on the basis of the data transfer protocol ITU-T X.25. I was lucky to be engaged in the maintenance and development of a single X.25 corporate network for several years.
I do not intend to talk about the X.25 protocol, I can read it in accessible sources , I want to share my experience - what was it? why was it needed? What of this might come in handy in the future? I am writing from memory, so I can be a little mistaken or confused about what is an element of the standard, and what is part of the implementation
The X.25 protocol was designed to replace the ISDN protocol, which for data transmission has significant drawbacks (lack of statistical multiplexing). The first edition of the standard was approved in 1976. The basis of the protocol formed the following basic ideas:
- Transmission control between two network nodes
- Transmission control between end users
- Routing at the time of the connection
- Switching packages along the established route
Many sources say that X.25 is a data link protocol. This is not true. X.25 was created before the development of the seven-level OSI model. In the data link layer, it is “recorded” only because of the widely used IP protocol encapsulation in X.25. In fact, the protocol has all the characteristics of a network layer (routing between networks) and provides transmission control between end users, i.e. out of the transport level.
')
The main advantage of the protocol is high efficiency in networks built on communication channels with a high level of errors. The main disadvantages - limited performance, not the ability to transfer real time data.
All subscribers of the X.25 network are divided into synchronous and asynchronous. Synchronous have built-in X.25 interfaces, and asynchronous data transfer devices use devices called PAD (Packet Assembler-Disassembler). PAD accepts asynchronous streams from its ports and sends them in a dial-up connection via an X.25 interface.
The network is based on packet switches. They are interconnected by synchronous communication channels (mainly X.21 via synchronous modems via PM channels or radio channels). Synchronous network subscribers are connected directly to packet switches. PADs are also connected to the switches.
The network uses X.121 addressing. It is somewhat similar to IP addressing, but without dots and with a decimal mask. The mask is never explicitly specified, just the length of the address can vary from 10 to 15 decimal characters.
The X.121 address is:
DDDDNNNPPPP [SSSSS]
Where
DDDD - DNIC (Network number, autonomous system analog in IP)
NNN - Node (Node Number)
PPPP - Port (Port Number)
SSSSS - Subadress
Each packet switch has its own routing table. The table indicates which port to route the connection to the specified address. The sender's address is usually not analyzed.
The important point is that routing occurs at the time of establishing a logical connection (SVC), after the connection is established, only switching occurs. To do this, logical ports (LCI) are created on each port. The number of available LCIs on an interface limits the available number of logical connections through it.
If the route of the established connection fails, then after a timeout and retry, the subscribers will re-establish the connection.
The network with which I had to deal was initially used for the operation of asynchronous terminals, which, via zmodem, transferred files to the file switch ("spinner"). Later, synchronous terminals appeared, exchanging information with the server and IP routers. Everything worked very slowly and very reliably. The speed on the main channels of PM was not higher than 19200, and in the outback there were 2400 “for happiness”, which did not prevent the transfer of data.
Later FR channels began to appear, which were used for X.25 over FR. When high-quality IP channels appeared, they gradually began to implement XOT (X.25 over IP).
The important point is that both technologies assume X.25 tunneling through non-native protocols for it. Sometimes it is convenient to “hone” the X.25 protocol on the interface to which it comes through the tunnel. The protocol does not provide this, protocol termination is possible only on interfaces with pure X.25 (over LAP-B), and tunneling can only be used within the network for switching between nodes.
The network I worked with was built on the equipment of the English company Case Communications . This company often changed ownership and name, at one time called Cray Communications. They started with packet switches, they also had Ethernet routers and routers. The division that produced the routers was bought by Intel, as a result of which fairly well-known Intel Express Router 9100 models and others appeared. The company is currently engaged in the development and production of linux routers.
The Case package switches line consisted of nodes (Packet Switch Exchange - PSE), X.25 / Frame-Relay Assembler-Disassembler - XFRAD switches and PAD. The peculiarity of PSE was that it was possible to make trunk connections between them, which were not addressed as normal ports, but were used for communication between network nodes. The network was supplied with a Sun-based control system with a graphical user interface for X11.
The most advanced model was the modular PSE8525. This is a 13 unit chassis for a 19 ”rack with 16 interface modules and a control module, up to 5 power supplies were installed in the chassis. The architecture of this thing deserves special attention.
The basis was a vertical backplane board. No active elements were detected on it (!) - just a set of tires. The backplane divided the chassis into two parts - in front of the board with controllers and processors, behind - boards with interfaces, a total of 17 slots. In the first 16 slots, you could install X.25 port cards or PAD cards. In the last slot - a payment manager.
PAD cards were “half-hearted” (hereinafter) and were logically separate devices and included in the switchboard in which they stood by external cables.
All other boards consisted of two parts - the controller board and the processor board. Processor boards (UPM) were the same for all boards, the X.25 port controller (SP-XIM) and the manager were different.
The system was loaded in stages. After powering on from floppy A, the manager was loaded. After booting, he read the configuration from diskette B and loaded the interface cards one by one. PADs loaded by themselves as soon as the power appeared. After loading all the boards, they could work independently, each of them could be rebooted separately. A manager in the system was needed only when changing the configuration or rebooting.
All the boards could be removed and reinstalled "on the go." There are cases when the chassis worked without a manager for more than a month. Compare this with pulling the supervisor out of the Cisco7600! ;)
The X.25 protocol played a great role in telecommunications and communications. At the time when it was created, it solved the problem of efficiently using low-speed communication channels with a high level of transmission errors. The developers of X.25 equipment relied not on speed, but on the reliability and survivability of the solution, so this protocol is still alive in the banking sector now.
The development of communication systems has led to the fact that the X.25 protocol has ceased to meet the requirements of modern applications for data transfer speeds, and the presence of high-speed communication channels with a low level of errors allows us to solve modern problems using TCP / IP protocols.
The foundations of the architecture of the protocol and X.25 networks illustrate a rational approach to solving the problem, and are an excellent educational material. Perhaps some of the ideas embodied in X.25 will return, but at higher levels. In particular, MPLS TE (Traffic Engineering) technology is somewhat similar to X.25 in terms of building logical channels.
I recommend everyone who is going to become a specialist in the field of networks and communications to learn the basics of the X.25 protocol, despite the fact that his knowledge is not required to work in many communication enterprises. When studying it, I recommend focusing not on how this or that function is implemented, but on what purpose it was included in the protocol.
I do not intend to talk about the X.25 protocol, I can read it in accessible sources , I want to share my experience - what was it? why was it needed? What of this might come in handy in the future? I am writing from memory, so I can be a little mistaken or confused about what is an element of the standard, and what is part of the implementation
X.25 protocol
The X.25 protocol was designed to replace the ISDN protocol, which for data transmission has significant drawbacks (lack of statistical multiplexing). The first edition of the standard was approved in 1976. The basis of the protocol formed the following basic ideas:
- Transmission control between two network nodes
- Transmission control between end users
- Routing at the time of the connection
- Switching packages along the established route
Many sources say that X.25 is a data link protocol. This is not true. X.25 was created before the development of the seven-level OSI model. In the data link layer, it is “recorded” only because of the widely used IP protocol encapsulation in X.25. In fact, the protocol has all the characteristics of a network layer (routing between networks) and provides transmission control between end users, i.e. out of the transport level.
')
The main advantage of the protocol is high efficiency in networks built on communication channels with a high level of errors. The main disadvantages - limited performance, not the ability to transfer real time data.
X.25 network
All subscribers of the X.25 network are divided into synchronous and asynchronous. Synchronous have built-in X.25 interfaces, and asynchronous data transfer devices use devices called PAD (Packet Assembler-Disassembler). PAD accepts asynchronous streams from its ports and sends them in a dial-up connection via an X.25 interface.
The network is based on packet switches. They are interconnected by synchronous communication channels (mainly X.21 via synchronous modems via PM channels or radio channels). Synchronous network subscribers are connected directly to packet switches. PADs are also connected to the switches.
The network uses X.121 addressing. It is somewhat similar to IP addressing, but without dots and with a decimal mask. The mask is never explicitly specified, just the length of the address can vary from 10 to 15 decimal characters.
The X.121 address is:
DDDDNNNPPPP [SSSSS]
Where
DDDD - DNIC (Network number, autonomous system analog in IP)
NNN - Node (Node Number)
PPPP - Port (Port Number)
SSSSS - Subadress
Each packet switch has its own routing table. The table indicates which port to route the connection to the specified address. The sender's address is usually not analyzed.
The important point is that routing occurs at the time of establishing a logical connection (SVC), after the connection is established, only switching occurs. To do this, logical ports (LCI) are created on each port. The number of available LCIs on an interface limits the available number of logical connections through it.
If the route of the established connection fails, then after a timeout and retry, the subscribers will re-establish the connection.
The network with which I had to deal was initially used for the operation of asynchronous terminals, which, via zmodem, transferred files to the file switch ("spinner"). Later, synchronous terminals appeared, exchanging information with the server and IP routers. Everything worked very slowly and very reliably. The speed on the main channels of PM was not higher than 19200, and in the outback there were 2400 “for happiness”, which did not prevent the transfer of data.
Later FR channels began to appear, which were used for X.25 over FR. When high-quality IP channels appeared, they gradually began to implement XOT (X.25 over IP).
The important point is that both technologies assume X.25 tunneling through non-native protocols for it. Sometimes it is convenient to “hone” the X.25 protocol on the interface to which it comes through the tunnel. The protocol does not provide this, protocol termination is possible only on interfaces with pure X.25 (over LAP-B), and tunneling can only be used within the network for switching between nodes.
Case Communications
The network I worked with was built on the equipment of the English company Case Communications . This company often changed ownership and name, at one time called Cray Communications. They started with packet switches, they also had Ethernet routers and routers. The division that produced the routers was bought by Intel, as a result of which fairly well-known Intel Express Router 9100 models and others appeared. The company is currently engaged in the development and production of linux routers.
The Case package switches line consisted of nodes (Packet Switch Exchange - PSE), X.25 / Frame-Relay Assembler-Disassembler - XFRAD switches and PAD. The peculiarity of PSE was that it was possible to make trunk connections between them, which were not addressed as normal ports, but were used for communication between network nodes. The network was supplied with a Sun-based control system with a graphical user interface for X11.
The most advanced model was the modular PSE8525. This is a 13 unit chassis for a 19 ”rack with 16 interface modules and a control module, up to 5 power supplies were installed in the chassis. The architecture of this thing deserves special attention.
The basis was a vertical backplane board. No active elements were detected on it (!) - just a set of tires. The backplane divided the chassis into two parts - in front of the board with controllers and processors, behind - boards with interfaces, a total of 17 slots. In the first 16 slots, you could install X.25 port cards or PAD cards. In the last slot - a payment manager.
PAD cards were “half-hearted” (hereinafter) and were logically separate devices and included in the switchboard in which they stood by external cables.
All other boards consisted of two parts - the controller board and the processor board. Processor boards (UPM) were the same for all boards, the X.25 port controller (SP-XIM) and the manager were different.
The system was loaded in stages. After powering on from floppy A, the manager was loaded. After booting, he read the configuration from diskette B and loaded the interface cards one by one. PADs loaded by themselves as soon as the power appeared. After loading all the boards, they could work independently, each of them could be rebooted separately. A manager in the system was needed only when changing the configuration or rebooting.
All the boards could be removed and reinstalled "on the go." There are cases when the chassis worked without a manager for more than a month. Compare this with pulling the supervisor out of the Cisco7600! ;)
Conclusion
The X.25 protocol played a great role in telecommunications and communications. At the time when it was created, it solved the problem of efficiently using low-speed communication channels with a high level of transmission errors. The developers of X.25 equipment relied not on speed, but on the reliability and survivability of the solution, so this protocol is still alive in the banking sector now.
The development of communication systems has led to the fact that the X.25 protocol has ceased to meet the requirements of modern applications for data transfer speeds, and the presence of high-speed communication channels with a low level of errors allows us to solve modern problems using TCP / IP protocols.
The foundations of the architecture of the protocol and X.25 networks illustrate a rational approach to solving the problem, and are an excellent educational material. Perhaps some of the ideas embodied in X.25 will return, but at higher levels. In particular, MPLS TE (Traffic Engineering) technology is somewhat similar to X.25 in terms of building logical channels.
I recommend everyone who is going to become a specialist in the field of networks and communications to learn the basics of the X.25 protocol, despite the fact that his knowledge is not required to work in many communication enterprises. When studying it, I recommend focusing not on how this or that function is implemented, but on what purpose it was included in the protocol.
Source: https://habr.com/ru/post/96221/
All Articles