X.25

X.25 is an ITU-T standard network layer protocol for packet switched wide area network (WAN) communication. An X.25 WAN consists of packet-switching exchange (PSE) nodes as the networking hardware, and leased lines, Plain old telephone service connections or ISDN connections as physical links. X.25 is part of the OSI protocol suite, a family of protocols that was used especially during the 1980s by telecommunication operators and in financial systems such as automated teller machines. X.25 is today to a large extent replaced by less complex and less secure protocols, especially the Internet protocol (IP) although some telephone operators offer X.25-based communication via the signalling ("D") channel of ISDN lines.

History

X.25 is one of the oldest packet-switched services available. [See packet switched network.] It was developed before the OSI Reference Model, [harv|Friend|1988|p=242] but after the Network Access Layer of the DoD protocol model. [See TCP/IP model.] Its three layers correspond closely to the lower three layers of the OSI model. [harv|Friend|1988|p=243] Its functionality maps directly to network layer of the OSI model. [http://www.itu.int/rec/T-REC-X.223/en/ ITU-T Recommendation X.223] .] It also supports functionality not found in the OSI network layer. [ [http://www.itu.int/rec/T-REC-X.28/en/ ITU-T Recommendation X.28] .] [ [http://www.itu.int/rec/T-REC-X.3/en/ ITU-T Recommendation X.3] .]

X.25 was developed in the ITU-T (formerly CCITT) Study Group VII based upon a number of emerging data network projects. Various updates and additions were worked into the standard, eventually recorded in the ITU series of technical books describing the telecom systems. These books were published every fourth year with different colored covers. The X.25 specification is only part of the larger set of [http://www.itu.int/rec/T-REC-X/en/ X-Series] specifications on public data networks. [harv|Friend|1988|p=230]

The "Public data network" was the common name given to the international collection of X.25 providers, [See public data network.] typically the various national telephone companies. Their combined network had large global coverage during the 1980s and into the 1990s.Fact|date=July 2008

X.25 remains in use for certain applications and for some marginal transmission media performance conditions.Fact|date=July 2008

Architecture

The general concept of X.25 was to create a universal and global packet-switched network. Much of the X.25 system is a description of the rigorous error correction needed to achieve this, as well as more efficient sharing of capital-intensive physical resources.

The X.25 specification defines only the interface between a subscriber (DTE) and an X.25 network (DCE). X.75, a very similar protocol to X.25, defines the interface between two X.25 networks to allow connections to traverse two or more networks. X.25 does not specify how the network operates internally—many X.25 network implementations used something very similar to X.25 or X.75 internally, but others used quite different protocols internally. The ISO equivalent protocol to X.25, ISO 8208, is the same as X.25, but additionally includes provision for two X.25 DTEs to be directly connected to each other with no network in between.

The X.25 model was based on the traditional telephony concept of establishing reliable circuits through a shared network, but using software to create "virtual calls" through the network. These calls interconnect "data terminal equipment" (DTE) providing endpoints to users, which looked like point-to-point connections. Each endpoint can establish many separate virtual calls to different endpoints.

For a brief period, the specification also included a connectionless datagram service, but this was dropped in the next revision. The "fast select with restricted response facility" is intermediate between full call establishment and connectionless communication. It is widely used in query-response transaction applications involving a single request and response limited to 128 bytes of data carried each way. The data is carried in an extended call request packet and the response is carried in an extended field of the call reject packet, with a connection never being fully established.

Closely related to the X.25 protocol are the protocols to connect asynchronous devices (such as dumb terminals and printers) to an X.25 network: X.3, X.28 and X.29. This functionality was performed using a Packet Assembler/Disassembler or PAD (also known as a "Triple-X device", referring to the three protocols used).

Relation to the OSI Reference Model

Although X.25 predates the OSI Reference Model (OSIRM), the physical layer of the model corresponds to the X.25 "physical level"; the link layer, the X.25 "link level"; and network layer, the X.25 "packet level". [harv|Friend|1988|p=230] The X.25 "link-layer", LAPB, provides a reliable data path across a data link (or multiple parallel data links, multilink) which may not be reliable itself. The X.25 packet-layer, provides the virtual call mechanisms, running over X.25 LAPB. As long as the "link layer" does provide reliable data transmission, the "packet-layer" will provide error-free virtual calls.Fact|date=July 2008 However, the "packet-layer" also includes mechanisms to maintain virtual calls and to signal data errors in the event that the "link-layer" does not provide reliable data transmission. All but the earliest versions of X.25 include facilities [ [http://www.itu.int/rec/T-REC-X.25-199610-I/en/ ITU-T Recommendation X.25] , G.3.2 Called address extension facility, pp. 141-142.] which provide for OSI network layer Addressing (NSAP addressing, see below) [ [http://www.itu.int/rec/T-REC-X.223/en/ ITU-T Recommendation X.223] , Appendix II.] .

User device support

X.25 was developed in the era of dumb terminals connecting to host computers, although it also can be used for communications between computers. Instead of dialing directly “into” the host computer — which would require the host to have its own pool of modems and phone lines, and require non-local callers to make long-distance calls — the host could have an X.25 connection to a network service provider. Now dumb-terminal users could dial into the network's local “PAD” (Packet Assembly/Disassembly facility), a gateway device connecting modems and serial lines to the X.25 link as defined by the ITU-T X.29 and X.3 standards.

Having connected to the PAD, the dumb-terminal user tells the PAD which host to connect to, by giving a phone-number-like address in the X.121 address format (or by giving a host name, if the service provider allows for names that map to X.121 addresses). The PAD then places an X.25 call to the host, establishing a virtual circuit. Note that X.25 provides for virtual circuits, so "appears" to be a circuit switched network, even though in fact the data itself is packet switched internally, similar to the way TCP provides virtual circuits even though the underlying data is packet switched. Two X.25 hosts could, of course, call one another directly; no PAD is involved in this case. In theory, it doesn't matter whether the X.25 caller and X.25 destination are both connected to the same carrier, but in practice it was not always possible to make calls from one carrier to another.

For the purpose of flow-control, a sliding window protocol is used with the default window size of 2. The acknowledgements may have either local or end to end significance. A D bit (Data Delivery bit) in each data packet indicates if the sender requires end to end acknowledgement. When D=1, it means that the acknowledgement has end to end significance and must take place only after the remote DTE has acknowledged receipt of the data. When D=0, the network is permitted (but not required) to acknowledge before the remote DTE has acknowledged or even received the data.

While the PAD function defined by X.28 and X.29 specifically supported asynchronous character terminals, PAD equivalents were developed to support a wide range of proprietary intelligent communications devices, such as those for IBM System Network Architecture (SNA).

Error control

Error recovery procedures at the packet level assume that the frame level is responsible for retransmitting data received in error. Packet level error handling focuses on resynchronizing the information flow in calls, as well as clearing calls that have gone into unrecoverable states:
*Level 3 Reset packets, which re-initializes the flow on a virtual circuit (but does not break the virtual circuit)
*Restart packet, which clears down all switched virtual circuits on the data link and resets all permanent virtual circuits on the data link

Addressing and virtual circuits

X.25 supports two types of virtual circuits, Virtual Calls (VC) which are established as and when required through a call establishment and clearing procedure, and Permanent Virtual Circuits (PVC) which are preconfigured into the network [ [http://www.itu.int/rec/T-REC-X.7-200404-I/en/ ITU-T Recommendation X.7 (04/2004)] , pp. 17-18.] . It should be noted that Virtual Calls were also commonly referred to as Switched Virtual Circuits (SVC).

VC may be established using X.121 addresses. The X.121 address consists of a three-digit "Data Country Code" (DCC) plus a network digit, together forming the four-digit "Data Network Identification Code" (DNIC), followed by the "National Terminal Number" (NTN) of at most ten digits. Note the use of a single network digit, seemingly allowing for only 10 network carriers per country, but some countries are assigned more than one DCC to avoid this limitation. Networks often used fewer than the full NTN digits for routing, and made the spare digits available to the subscriber (sometimes called the sub-address) where they could be used to identify applications or for further routing on the subscribers networks.

NSAP addressing facility was added in the X.25(1984) revision of the specification, and this enabled X.25 to better meet the requirements of OSI Connection Oriented Network Service (CONS). [ [http://www.itu.int/rec/T-REC-X.223/en/ ITU-T Recommendation X.223] .] Public X.25 networks were not required to make use of NSAP addressing, but, to support OSI CONS, were required to carry the NSAP addresses and other ITU-T specified DTE facilities transparently from DTE to DTE. [ [http://www.itu.int/rec/T-REC-X.25-199610-I/en/ ITU-T Recommendation X.25 (10/96)] , Annex G, p. 140.] Later revisions allowed multiple addresses in addition to X.121 addresses to be carried on the same DTE-DCE interface: Telex addressing (F.69), PSTN addressing (E.163), ISDN addressing (E.164), Internet Protocol addresses (IANA ICP), and local IEEE 802.2 MAC addresses. [ [http://www.itu.int/rec/T-REC-X.213-200110-I/en/ ITU-T Recommendation X.213] , Annex A.] These were never used though.Fact|date=July 2008

PVCs are permanently established in the network and therefore do not require the use of addresses for call setup. PVCs are identified at the subscriber interface by their logical channel identifier (see below). However, in practice not many of the national X.25 networks supported PVCs.

One DTE-DCE interface to an X.25 network has a maximum of 4095 logical channels on which it is allowed to establish virtual calls and permanent virtual circuits [http://www.itu.int/rec/T-REC-X.25-199610-I/en/ ITU-T Recommendation X.25 (10/96)] , p. 45.] , although networks are not expected to support a full 4095 virtual circuits. [ [http://www.itu.int/rec/T-REC-X.283-199712-I/en/ ITU-T Recommendation X.283 (12/97)] , p. 42.] For identifying the channel to which a packet is associated, each packet contains a 12 bit logical channel identifier made up of an 8-bit "Logical Channel Number" and a 4-bit "Logical Channel Group Number." Logical channel identifiers remain assigned to a virtual circuit for the duration of the connection. Logical channel identifiers identify a specific logical channel between the DTE (subscriber appliance) and the DCE (network), and only has local significance on the link between the subscriber and the network. The other end of the connection at the remote DTE is likely to have assigned a different logical channel identifier. The range of possible logical channels is split into 4 groups: channels assigned to permanent virtual circuits, assigned to incoming virtual calls, two-way (incoming or outgoing) virtual calls, and outgoing virtual calls. [http://www.itu.int/rec/T-REC-X.25-199610-I/en/ ITU-T Recommendation X.25 (10/96)] , Annex A, pp. 119-120.] (Directions refer to the direction of virtual call initiation as viewed by the DTE -- they all carry data in both directions.) [ISO/IEC 8208 : 2000, Fourth Edition, p. 61.] The ranges allowed a subscriber to be configured to handle significantly differing numbers of calls in each direction while reserving some channels for calls in one direction. The extent to which networks implemented these varied considerably, and some networks only offered the two-way logical channel range, that being the simplest.Fact|date=July 2008 All International networks are required to implement support for permanent virtual circuits, two-way logical channels and one-way logical channels outgoing; one-way logical channels incoming is an additional optional facility. [ [http://www.itu.int/rec/T-REC-X.2-200003-I/en/ ITU-T Recommendation X.2 (03/2000)] , p. 4.] DTE-DCE interfaces are not required to support more than one logical channel. Logical channel identifier zero will not be assigned to a permanent virtual circuit or virtual call. [ISO/IEC 8208 : 2000, Fourth Edition, 3.7.1, p. 7.] The logical channel identifier of zero is used for packets which don't relate to a specific virtual circuit (e.g. packet layer restart, registration, and diagnostic packets).

Billing

In public networks, X.25 was typically billed as a flat monthly service fee depending on link speed, and then a price-per-segment on top of this. [ [http://www.itu.int/rec/T-REC-D.11-199103-I/en/ ITU-T Recommendation D.11 (03/91)] , p. 2.] Link speeds varied, typically from 2400bit/s up to 2 Mbit/s, although speeds above 64 kbit/s were uncommon in the public networks. A segment was 64 bytes of data (rounded up, with no carry-over between packets), [ [http://www.itu.int/rec/T-REC-D.12-198811-I/en/ ITU-T Recommendation D.12 (11/88)] , p. 1.] charged to the caller [ [http://www.itu.int/rec/T-REC-X.7-200404-I/en/ ITU-T Recommendation X.7 (04/2004)] , p. 42.] (or callee in the case of reverse charged calls, where supported). [ [http://www.itu.int/rec/T-REC-D.11-199103-I/en/ ITU-T Recommendation D.11 (03/91)] , p. 3.] Calls invoking the "Fast Select" facility (allowing 128 bytes of data in call request, call confirmation and call clearing phases) [ [http://www.itu.int/rec/T-REC-X.7-200404-I/en/ ITU-T Recommendation X.7 (04/2004)] , p. 38.] would generally attract an extra charge, as might use of some of the other X.25 facilities. PVCs would have a monthly rental charge and a lower price-per-segment than VCs, making them cheaper only where large volumes of data are passed.

Obsolescence

Publicly-accessible X.25 networks (Compuserve, Tymnet, Euronet, PSS, and Telenet) were set up in most countries during the 1970s and 80s, to lower the cost of accessing various online services.

With the widespread introduction of "perfect" quality digital phone services and error correction in modems, the overhead of X.25 was no longer worthwhile.Fact|date=June 2008 The result was called Frame relay, essentially the X.25 protocol with the error correction systems removed, and somewhat better throughput as a result. The concept of virtual circuits is still used within ATM to allow for traffic engineering and network multiplexing.

The X.25 protocol processing within packet switches is more complex (hence more costly and/or slower) than the equivalent router function within the Internet Protocol network layer. Internet Protocol places more responsibility on the protocol stacks in the end systems to ensure reliable data transfer across the network, and with reducing cost and increasing processing power of end-systems, combined with the prospects of cheaper network infrastructure, the economic viability of X.25 declined.

X.25 today

X.25 networks are still in use throughout the world, although in dramatic decline,Fact|date=June 2008 being largely supplanted by newer layer 2 technologies such as frame relay, ISDN, ATM, ADSL, POS, and the ubiquitous layer 3 Internet Protocol.Fact|date=June 2008 X.25 however remains one of the only available reliable links in many portions of the developing world,Fact|date=June 2008 where access to a PDN may be the most reliable and low cost way to access the Internet.Fact|date=June 2008 A variant called AX.25 is also used widely by amateur packet radio, though there has been some movement in recent years to replace it with TCP/IP.Fact|date=June 2008 Racal Paknet, now known as Widanet, is still in operation in many regions of the world, running on an X.25 protocol base. Used as a secure wireless low rate data transfer platform, Widanet is commonly used for GPS tracking and point-of-sale solutions currently.Fact|date=June 2008 In some countries, like The Netherlands or Germany, it is possible to use a stripped version of X25 via the D-channel of an ISDN-2 (or ISDN BRI) connection for low volume applications such as point-of-sale terminals. But the future of this service in The Netherlands is uncertain. [See also the Dutch Wiki on ISDN and the Dutch Wiki on X.25 (preface)]

X.25 packet types

X.25 details

The minimum data field length the network must support is 128 octets per packet.Fact|date=June 2008 However the network may allow the selection of the maximal length in range 16 to 4096 octets (2ⁿ values only) per virtual circuit by negotiation as part of the call setup procedure. The maximal length may be different at the two ends of the virtual circuit.
*Data terminal equipment constructs control packets which are encapsulated into data packets. The packets are sent to the data circuit-terminating equipment, using LAPB Protocol.
*Data circuit-terminating equipment strips the layer-2 headers in order to encapsulate packets to the internal network protocol.

X.25 facilities

X.25 provides a set of user facilities defined and described in [http://www.itu.int/rec/T-REC-X.2/en/ ITU-T Recommendation X.2] . The X.2 user facilities fall into five categories:

* essential facilities;
* additional facilities;
* conditional facilities;
* mandatory facilities; and,
* optional facilities.

X.25 also provides X.25 and ITU-T specified DTE optional user facilities defined and described in [http://www.itu.int/rec/T-REC-X.7/en/ ITU-T Recommendation X.7] . The X.7 optional user facilities fall into four categories of user facilities that require:

* subscription only;
* subscription followed by dynamic invocation;
* subscription or dynamic invocation; and,
* dynamic invocation only.

X.25 protocol versions

The CCITT/ITU-T versions of the protocol specifications are for Public Data Networks (PDN). [ [http://www.itu.int/rec/T-REC-X.25-199610-I/en/ ITU-T Recommendation X.25 (10/96)] , Summary, p. v.] The ISO/IEC versions address additional features for private networks (e.g. Local Area Networks (LAN) use) while maintaining compatibility with the CCITT/ITU-T specifications. [ISO/IEC 8208 : 2000, Fourth Edition, Section 1: Scope, p. 1.]

The user facilities and other features supported by each version of X.25 and ISO/IEC 8208 have varied from edition to edition.ISO/IEC 8208 : 2000, Fourth Edition, Annex C.] Several major protocol versions of X.25 exist: [ [http://www.itu.int/rec/T-REC-X.25/en/ ITU-T Recommendation X.25] .]

* CCITT Recommendation X.25 (1976) Orange Book
* CCITT Recommendation X.25 (1980) Yellow Book
* CCITT Recommendation X.25 (1984) Red Book
* CCITT Recommendation X.25 (1988) Blue Book
* [http://www.itu.int/rec/T-REC-X.25-199303-S/en/ ITU-T Recommendation X.25 (1993) White Book]
* [http://www.itu.int/rec/T-REC-X.25-199610-I/en/ ITU-T Recommendation X.25 (1996) Grey Book]

The X.25 Recommendation allows many options for each network to choose when deciding which features to support and how certain operations are performed. This means each network needs to publish its own document giving the specification of its X.25 implementation, and most networks required DTE appliance manufacturers to undertake protocol conformance testing, which included testing for strict adherence and enforcement of their network specific options. (Network operators were particularly concerned about the possibility of a badly behaving or misconfigured DTE appliance taking out parts of the network and affecting other subscribers.) Therefore, subscriber's DTE appliances have to be configured to match the specification of the particular network they are connecting to. Most of these were sufficiently different to prevent interworking if the subscriber didn't configure their appliance correctly or the appliance manufacturer didn't include specific support for that network. In spite of protocol conformance testing, this often lead to interworking problems when initially attaching an appliance to a network. This is in stark contrast to the Robustness Principle employed in the Internet Protocol family.

Public networks were adopters of the earlier protocol versions, but reluctant to upgrade fearing subscriber compatibility issues and struggling to justify the expense. Most public networks ended up running something roughly on a parity with X.25 (1980) with some parts of X.25 (1984). Private networks started using X.25 later and were more likely to take upgrades, and many of those operated something nearer to X.25 (1984) with a few X.25 (1988) features. By about 1990, X.25 development by all the major network switch vendors had ceased, and there were no significant implementations of the 1993 and 1996 protocol versions.

In addition to the CCITT/ITU-T versions of the protocol, four editions of ISO/IEC 8208 exist:

* ISO/IEC 8208 : 1987, First Edition, compatible with X.25 (1980) and (1984)
* ISO/IEC 8208 : 1990, Second Edition, compatible with 1st Ed. and X.25 (1988).
* ISO/IEC 8208 : 1995, Third Edition, compatible with 2nd Ed. and X.25 (1993).
* ISO/IEC 8208 : 2000, Fourth Edition, compatible with 3rd Ed. and X.25 (1996).

ee also

* Packet switched network - protocols related to X.25
* DATAPAC - Canadian variant of X.25 offered by Bell Canada

Notes

References

*Computer Communications, lecture notes by Prof. Chaim Ziegler PhD, Brooklyn College
*cite book
author=Motorola Codex
title=The Basics Book of X.25 Packet Switching
edition=2nd edition
series=The Basics Book Series
year=1992
publisher=Addison-Wesley
location=Reading, MA
isbn=0-201-56369-X
*cite book
last=Friend
first=George E.
coauthors=John L. Fike, H. Charles Baker, John C. Bellamy
title=Understanding Data Communications
edition=2nd Edition
year=1988
publisher=Howard W. Sams & Company
location=Indianapolis
isbn=0-672-27270-9
*cite book
last=Pooch
first=Udo W.
coauthors=William H. Greene, Gary G. Moss
title=Telecommunications and Networking
publisher=Little, Brown and Company
location=Boston
year=1983
isbn=0-316-71498-4

*cite book
last=Thorpe
first=Nicolas M.
coauthors=Derek Ross
title=X.25 Made Easy
year=1992
publisher=Prentice Hall
isbn=0-139-72183-5

External links

* [http://www.itu.int/rec/T-REC-X.25/en Recommendation X.25 (10/96)] at ITU-T
* [http://www.cisco.com/en/US/docs/internetworking/technology/handbook/X25.html Cisco X.25 Reference]
* [http://www.farsite.co.uk/X.25/X.25_info/X.25.htm An X.25 Networking Guide with comparisons to TCP/IP]
* [http://softtechinfo.com/network/x25.html X.25 - Directory & Informational Resource]