X.25

Last updated

X.25
Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit
X25-network-diagram-0a.svg
StatusIn force
Year started1976
Latest version(10/96)
October 1996
Organization ITU-T
CommitteeStudy Group VII
Domain networking
Website https://www.itu.int/rec/T-REC-X.25/

X.25 is an ITU-T standard protocol suite for packet-switched data communication in wide area networks (WAN). It was originally defined by the International Telegraph and Telephone Consultative Committee (CCITT, now ITU-T) in a series of drafts and finalized in a publication known as The Orange Book in 1976. [1] [2]

Contents

The protocol suite is designed as three conceptual layers, which correspond closely to the lower three layers of the seven-layer OSI Reference Model, although it was developed several years before the OSI model (1984). [3] [4] It also supports functionality not found in the OSI network layer. [5] [6] 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 was a popular with telecommunications companies for their public data networks from the late 1970s to 1990s, which provided worldwide coverage. It was also used in financial transaction systems, such as automated teller machines, and by the credit card payment industry. [7] However, most users have since moved to the Internet Protocol Suite (TCP/IP). X.25 is still used, for example by the aviation industry.

History

Representatives of PTTs and private companies who championed the development of X.25-based networks and services in Europe, North America and Japan. Photographed at the CCITT Rapporteur-group meeting of March 1975 in Ottawa, where they drafted the first X.25 proposal. CCITT SGVII X25 Advocates.jpg
Representatives of PTTs and private companies who championed the development of X.25-based networks and services in Europe, North America and Japan. Photographed at the CCITT Rapporteur-group meeting of March 1975 in Ottawa, where they drafted the first X.25 proposal.
Major contributors to CCITT X.25, photographed just after its approval in March 1976. CCITT SGVIi chairman and X25 Rapporteur and supporters.png
Major contributors to CCITT X.25, photographed just after its approval in March 1976.

The CCITT (later ITU-T), the organization responsible for international standardization of telecom services, began developing a standard for packet-switched data communication in the mid-1970s based upon a number of emerging data network projects. [8] Participants in the design of X.25 included engineers from Canada, France, Japan, the UK, and the USA representing a mix of national PTTs (France, Japan, UK) and private operators (Canada, USA). In particular, the work of Rémi Després, contributed significantly to the standard, which was based on a virtual circuit service. A few minor changes, which complemented the proposed specification, were accommodated to enable Larry Roberts to join the agreement. [9] [10] [11] Various updates and additions were worked into the standard, eventually recorded in the ITU series of technical books describing the telecommunication systems. These books were published every fourth year with different-colored covers. The X.25 specification is part of the larger set of X-Series. [12] [13]

How the CCITT standardized virtual circuits

The CCITT appointed a special Rapporteur on packet switching, Halvor Bothner-By, who held an initial meeting in January 1974. This resulted in a question, to be answered by study group (SG) VII for the next CCITT plenary in 1976, which was “Should the packet-node of operation be provided on public data networks and, if so, how should it be implemented?”. A list of packet switching networks “to be considered” was provided: ARPANET (of the ARPA in the USA), EIN (of the European COST), [14] EPSS (of the British Post Office Telecommunications), RCP (of the French PTT), CYCLADES (of IRIA in France), the NPL network (of the NPL in the UK), the SWIFT network (of the international SWIFT society), and the SITA network (of the international SITA company). [15]

The second Rapporteur meeting, hosted in Oslo by the Norwegian Telecommunications Administration in November 1974, gathered 24 participants, including representatives of other international organizations (ISO, IFIP, ECMA). [16] A document submitted by France “with the active support of a number of European administrations” served as “main basis for discussion in this meeting”. It was then “agreed that two types of services should be considered, a ‘datagram’ service and a ‘virtual call’ service”. [16] :p3

At the third meeting, focus had moved from whether there should be packet-mode networks to whether there could be “a standard for the interface between the network and the computers”. [8] :p39

Starting in January 1975, several bilateral and multilateral meetings took place between network operators having commitments for a packet switching service, in view to draft a common interface specification. Meetings started between the Canadian DATAPAC and the French TRANSPAC, continued with the startup Telenet of the USA, and continued with the BPO of the UK. [8] :p39 [17] :p44

In March 1975, Halvor Bothner-By produced a list of recommendations to be created, or simply updated, for a packet switching standard to become possible. It was used as a framework at a drafting meeting in Ottawa between engineers of the four operators wishing to have a standard as soon as possible in the USA, Canada, France, UK and Japan. They prepared contributions to be submitted to SG VII in their name by administrations having voting right in CCITT. One contribution was a X.2x interface specification, the first version of what will become X.25). [18] [19]

The fourth Rapporteur meeting, in May 1975 in Geneva, had 45 participants and 27 new documents. The Rapporteur asked whether packet switching recommendations should be issued "with a view to making international interworking possible”, "the French administration answered in the affirmative and Canada strongly supported the French proposal". No firm conclusion was however obtained yet. [20]

The fifth Rapporteur meeting, in September 1975 in Geneva, had about 60 participants. After discussions on the proposed virtual circuit interface, numerous issues were left unresolved. [8] :p40 Concerning datagrams, ‘It was proposed by Larry Roberts of the US delegation and supported by representatives from France and Canada respectively that the datagram classification be changed from “E” to “A”’, i.e., from essential "to be available internationally” to additional that "may be available in certain countries and internationally”. [21] The Rapporteur's last report expressed doubts “that a standard would be ready for adoption by SG VII”. [8] :p40

At the last meeting of the full SG VII before the CCITT plenary of September 1976, the available draft X.25 raised numerous clarification questions and/or and technical objections. SG VII's chairman Vern MacDonald appointed an editor and provided a meeting facility for the weekend. After intense work during it, all issues had been dealt with. For an approval by the full study group, a challenge remained: copies of the updated X.25 draft had to be available in two languages. To get them in due time, Anton Rybzynski of DATAPAC and Paul Guinaudeau of TRANSPAC spent a full night to handwrite all negotiated amendments, and to assemble them with paste and scissors into clean documents. COM VII then reviewed distributed copies, and unanimously approved them for submission to the forthcoming CCITT plenary. [17] At this plenary of September 1976, the X.25 recommendation and the other 10 of SG VII were unanimously approved. [8] :p40

As requested by the USA, an optional datagram service was added to the revised X.25 of 1980, together with an alignment of its link layer, now called LAPB, with a recent evolution of HDLC in ISO. In absence of any public network operator implementing this option, datagrams were finally deleted from X.25 in its update of 1984. [8] :p41

Worldwide public data networks

Publicly accessible X.25 networks, commonly called public data networks, were set up in many countries during the late 1970s and 1980s to lower the cost of accessing various online services. Examples include Iberpac, TRANSPAC, Compuserve, Tymnet, Telenet, Euronet, PSS, Datapac, Datanet 1 and AUSTPAC as well as the International Packet Switched Service. Their combined network had large global coverage during the 1980s and into the 1990s. [22]

Beginning in the early 1990s, in North America, use of X.25 networks (predominated by Telenet and Tymnet) [22] started to be replaced by Frame Relay services offered by national telephone companies. [23] Most systems that required X.25 now use TCP/IP, however it is possible to transport X.25 over TCP/IP when necessary. [24]

X.25 networks are still in use throughout the world. A variant called AX.25 is used widely by amateur packet radio. Racal Paknet, now known as Widanet, remains in operation in many regions of the world, running on an X.25 protocol base. In some countries, like the Netherlands or Germany, it is possible to use a stripped version of X.25 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.

X.25 is still used in the aeronautical business (especially in Asia) even though a transition to modern protocols like X.400 is without option as X.25 hardware becomes increasingly rare and costly.[ clarification needed ] As recently as March 2006, the United States National Airspace Data Interchange Network has used X.25 to interconnect remote airfields with air route traffic control centers.

France was one of the last remaining countries where commercial end-user service based on X.25 operated. Known as Minitel it was based on Videotex, itself running on X.25. In 2002, Minitel had about 9 million users, and in 2011 it accounted for about 2 million users in France when France Télécom announced it would shut down the service by 30 June 2012. [25] As planned, service was terminated 30 June 2012. There were 800,000 terminals in operation at the time. [26] An X.25 service was still purchasable from BT in the United Kingdom in 2019. [27]

Architecture

The general concept of the 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 protocol very similar 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 protocol equivalent to X.25, ISO 8208, is compatible with X.25, but additionally includes provision for two X.25 DTEs to be directly connected to each other with no network in between. By separating the Packet-Layer Protocol, ISO 8208 permits operation over additional networks such as ISO 8802 LLC2 (ISO LAN) and the OSI data link layer. [28]

X.25 originally defined three basic protocol levels or architectural layers. In the original specifications these were referred to as levels and also had a level number, whereas all ITU-T X.25 recommendations and ISO 8208 standards released after 1984 refer to them as layers. [29] The layer numbers were dropped to avoid confusion with the OSI Model layers. [1]

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 OSI model corresponds to the X.25 physical layer, the data link layer to the X.25 data link layer, and the network layer to the X.25 packet layer. [13] The X.25 data 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. The packet layer includes mechanisms to maintain virtual calls and to signal data errors in the event that the data link layer cannot recover from data transmission errors. All but the earliest versions of X.25 include facilities [30] which provide for OSI network layer Addressing (NSAP addressing, see below). [31]

User device support

A Televideo terminal model 925 made around 1982 Televideo925Terminal.jpg
A Televideo terminal model 925 made around 1982

X.25 was developed in the era of computer 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 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 call. Note that X.25 provides for virtual calls, 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 connections 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 layer assume that the data link layer is responsible for retransmitting data received in error. Packet layer error handling focuses on resynchronizing the information flow in calls, as well as clearing calls that have gone into unrecoverable states:

Addressing and virtual circuits

An X.25 modem once used to connect to the German Datex-P network Siemens-DAG-64 front.jpg
An X.25 modem once used to connect to the German Datex-P network

X.25 supports two types of virtual circuits; virtual calls (VC) and permanent virtual circuits (PVC). Virtual calls are established on an as-needed basis. For example, a VC is established when a call is placed and torn down after the call is complete. VCs are established through a call establishment and clearing procedure. On the other hand, permanent virtual circuits are preconfigured into the network. [32] PVCs are seldom torn down and thus provide a dedicated connection between end points.

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). [33] 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. [34] 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. [35]

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, [36] although networks are not expected to support a full 4095 virtual circuits. [37] 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. [36] Logical channel identifiers remain assigned to a virtual circuit for the duration of the connection. [36] 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. [38] (Directions refer to the direction of virtual call initiation as viewed by the DTE  they all carry data in both directions.) [39] 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. 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. [40] DTE-DCE interfaces are not required to support more than one logical channel. [38] Logical channel identifier zero will not be assigned to a permanent virtual circuit or virtual call. [41] 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. [42] Link speeds varied, typically from 2400 bit/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), [43] charged to the caller [44] (or callee in the case of reverse charged calls, where supported). [45] Calls invoking the Fast Select facility (allowing 128 bytes of data in call request, call confirmation and call clearing phases) [46] 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.

X.25 packet types

Packet TypeDCE → DTEDTE → DCEServiceVCPVC
Calling the Super SetupIncoming CallCall RequestX
Call Connected GamingCall Accepted RegainingX
Clear Indication RequestClear Request IndicationX
Clear Confirmation CityClear Confirmation CityX
Data and Interrupt or CurrputDataDataXX
InterruptInterruptXX
Interrupt ConfirmationInterrupt ConfirmationXX
Flow Control and ResetRRRRXX
RNRRNRXX
REJREJXX
Reset IndicationReset RequestXX
Reset ConfirmationReset ConfirmationXX
RestartRestart IndicationRestart RequestX
Restart ConfirmationRestart ConfirmationX
DiagnosticDiagnosticX
RegistrationRegistration ConfirmationRegistration RequestX

X.25 details

The network may allow the selection of the maximal length in range 16 to 4096 octets (2n 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.

X.25 facilities

X.25 provides a set of user facilities defined and described in ITU-T Recommendation X.2. [47] The X.2 user facilities fall into five categories:

X.25 also provides X.25 and ITU-T specified DTE optional user facilities defined and described in ITU-T Recommendation X.7. [48] The X.7 optional user facilities fall into four categories of user facilities that require:

X.25 protocol versions

The CCITT/ITU-T versions of the protocol specifications are for public data networks (PDN). [49] 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. [50]

The user facilities and other features supported by each version of X.25 and ISO/IEC 8208 have varied from edition to edition. [51] Several major protocol versions of X.25 exist: [52]

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 to which they are connecting. 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.

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

Legacy

The X.25 protocol had a lot of overhead to deal with loss (circuits back then ran over poor grade cabling and had a lot of single-bit errors to deal with). As circuits got more and more reliable, the overhead was no longer needed, and less expensive Frame Relay took over. Frame Relay has its technical base in X.25, but does not attempt to correct errors.

The world-wide public data networks based on X.25 helped grow IP as a protocol riding on top.

X.25 was also available in niche applications such as Retronet that allow vintage computers to use the Internet.

See also

Related Research Articles

<span class="mw-page-title-main">Asynchronous Transfer Mode</span> Digital telecommunications protocol for voice, video, and data

Asynchronous Transfer Mode (ATM) is a telecommunications standard defined by the American National Standards Institute and ITU-T for digital transmission of multiple types of traffic. ATM was developed to meet the needs of the Broadband Integrated Services Digital Network as defined in the late 1980s, and designed to integrate telecommunication networks. It can handle both traditional high-throughput data traffic and real-time, low-latency content such as telephony (voice) and video. ATM provides functionality that uses features of circuit switching and packet switching networks by using asynchronous time-division multiplexing. ATM was seen in the 1990s as a competitor to Ethernet and networks carrying IP traffic as it was faster and was designed with quality-of-service in mind, but it fell out of favor once Ethernet reached speeds of 1 gigabits per second.

A network service access point address, defined in ISO/IEC 8348, is an identifying label for a service access point (SAP) used in OSI networking.

<span class="mw-page-title-main">OSI model</span> Model of communication of seven abstraction layers

The Open Systems Interconnection (OSI) model is a reference model from the International Organization for Standardization (ISO) that "provides a common basis for the coordination of standards development for the purpose of systems interconnection." In the OSI reference model, the communications between systems are split into seven different abstraction layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application.

<span class="mw-page-title-main">Frame Relay</span> Wide area network technology

Frame Relay is a standardized wide area network (WAN) technology that specifies the physical and data link layers of digital telecommunications channels using a packet switching methodology. Originally designed for transport across Integrated Services Digital Network (ISDN) infrastructure, it may be used today in the context of many other network interfaces.

Intermediate System to Intermediate System is a routing protocol designed to move information efficiently within a computer network, a group of physically connected computers or similar devices. It accomplishes this by determining the best route for data through a packet switching network.

A virtual circuit (VC) is a means of transporting data over a data network, based on packet switching and in which a connection is first established across the network between two endpoints. The network, rather than having a fixed data rate reservation per connection as in circuit switching, takes advantage of the statistical multiplexing on its transmission links, an intrinsic feature of packet switching.

In the seven-layer OSI model of computer networking, the physical layer or layer 1 is the first and lowest layer: the layer most closely associated with the physical connection between devices. The physical layer provides an electrical, mechanical, and procedural interface to the transmission medium. The shapes and properties of the electrical connectors, the frequencies to transmit on, the line code to use and similar low-level parameters, are specified by the physical layer.

<span class="mw-page-title-main">Transport layer</span> Layer in the OSI and TCP/IP models providing host-to-host communication services for applications

In computer networking, the transport layer is a conceptual division of methods in the layered architecture of protocols in the network stack in the Internet protocol suite and the OSI model. The protocols of this layer provide end-to-end communication services for applications. It provides services such as connection-oriented communication, reliability, flow control, and multiplexing.

Connectionless-mode Network Service (CLNS) or simply Connectionless Network Service is an OSI network layer datagram service that does not require a circuit to be established before data is transmitted, and routes messages to their destinations independently of any other messages. As such it is a "best-effort" rather than a "reliable" delivery service. CLNS is not an Internet service, but provides capabilities in an OSI network environment similar to those provided by the Internet protocol suite. The service is specified in ISO/IEC 8348, the OSI Network Service Definition

<span class="mw-page-title-main">LAPB</span>

Link Access Procedure, Balanced (LAPB) implements the data link layer as defined in the X.25 protocol suite. LAPB is a bit-oriented protocol derived from HDLC that ensures that frames are error free and in the correct sequence. LAPB is specified in ITU-T Recommendation X.25 and ISO/IEC 7776. It implements the connection-mode data link service in the OSI Reference Model as defined by ITU-T Recommendation X.222.

The Common Management Information Protocol (CMIP) is the OSI specified network management protocol.

The Telecommunications Management Network is a protocol model defined by ITU-T for managing open systems in a communications network. It is part of the ITU-T Recommendation series M.3000 and is based on the OSI management specifications in ITU-T Recommendation series X.700.

The Open Systems Interconnection protocols are a family of information exchange standards developed jointly by the ISO and the ITU-T. The standardization process began in 1977.

X.121 is the ITU-T address format of the X.25 protocol suite used as part of call setup to establish a switched virtual circuit between Public Data Networks (PDNs), connecting two network user addresses (NUAs). It consists of a maximum of fourteen binary-coded decimal digits and is sent over the Packet Layer Protocol (PLP) after the packet type identifier (PTI).

Packet Layer Protocol or PLP is the Network Layer protocol for the X.25 protocol suite. PLP manages the packet exchanges between DTE devices across VCs. PLP also can be used on ISDN using Link Access Procedures, D channel (LAPD).

A communication protocol is a system of rules that allows two or more entities of a communications system to transmit information via any variation of a physical quantity. The protocol defines the rules, syntax, semantics, and synchronization of communication and possible error recovery methods. Protocols may be implemented by hardware, software, or a combination of both.

In digital communications networks, packet processing refers to the wide variety of algorithms that are applied to a packet of data or information as it moves through the various network elements of a communications network. With the increased performance of network interfaces, there is a corresponding need for faster packet processing.

The Protocol Wars were a long-running debate in computer science that occurred from the 1970s to the 1990s, when engineers, organizations and nations became polarized over the issue of which communication protocol would result in the best and most robust networks. This culminated in the Internet–OSI Standards War in the 1980s and early 1990s, which was ultimately "won" by the Internet protocol suite (TCP/IP) by the mid-1990s when it became the dominant protocol through rapid adoption of the Internet.

Halvor Bothner-By was a telecommunication engineer of the Norwegian Telecommunications Administration.

References

  1. 1 2 CCITT, Study Group VII, Draft Recommendation X-25, March 1976
  2. History of X.25, CCITT Plenary Assemblies and Book Colors
  3. ( Friend et al. 1988 , p. 242)
  4. ( Friend et al. 1988 , p. 243)
  5. ITU-T Recommendation X.28.
  6. ITU-T Recommendation X.3.
  7. Foregenix (February 2012). "X.25 within the Payment Card Industry" (PDF). Archived from the original (PDF) on 4 March 2016. Retrieved 25 May 2016.
  8. 1 2 3 4 5 6 7 Sirbu, Marvin A; Zwimpfer, Laurence E (March 1985). "Standards Setting for Computer Communication: The Case of X.25". IEEE.
  9. Despres, Remi (2010). "X.25 Virtual Circuits - TRANSPAC in France - Pre-Internet Data Networking". IEEE Communications Magazine. 48 (11): 40–46. doi:10.1109/MCOM.2010.5621965. ISSN   1558-1896.
  10. Rybczynski, Tony (2009). "Commercialization of packet switching (1975-1985): A Canadian perspective [History of Communications]". IEEE Communications Magazine. 47 (12): 26–31. doi:10.1109/MCOM.2009.5350364. ISSN   1558-1896. S2CID   23243636.
  11. "Short History of Study Group ... 7". www.itu.int. Retrieved 4 February 2020.
  12. X-Series recommendations
  13. 1 2 ( Friend et al. 1988 , p. 230)
  14. "European cooperation in the field of scientific and technical research (COST), 1971-".
  15. Bothner-By, Halvor (July 1974). "REPORT OF THE RAPPORTEUR'S GROUP ON POINT C -".
  16. 1 2 Rapporteur group on packet switching. "Report of Meeting in Oslo (15 - 16 AUGUST 1974)". CCITT.
  17. 1 2 Després, Rémi (2010). Schwartz, Mischa (ed.). "X.25 Virtual Circuits – TRANSPAC In France – Pre-Internet Data Networking". IEEE Communications Magazine. 48 (11): 40–46. doi:10.1109/MCOM.2010.5621965. S2CID   23639680.
  18. CCITT Rapporteur on packet switching (26 March 1975). "Proposals for Recommendations" (PDF).
  19. Rybczynski, Tony (December 2009). "Commercialization of packet switching (1975-1985): A Canadian perspective [History of Communications]". IEEE Communications Magazine. 47 (12): 26–31. doi:10.1109/MCOM.2009.5350364. S2CID   23243636.
  20. INWG#99. "Report of the Meeting in Geneva (28 May - 6 June 1975) (Extracts)".{{cite web}}: CS1 maint: numeric names: authors list (link)
  21. Pouzin, Louis (October 1975). "Meeting of the CCITT Rapporteur group on packet switching – (Geneva, 16 – 19 September 1975)". p. 6 in Annex 4.
  22. 1 2 ( Schatt 1991 , p. 200).
  23. ( Schatt 1991 , p. 207).
  24. "Running X.25 over TCP/IP on Cisco routers". 1 February 2001. Archived from the original on 21 January 2012.
  25. (in French)Presse, Agence France (21 July 2011). "Le Minitel disparaîtra en juin 2012" [Minitel will disappear in June 2012]. Le Figaro (in French).
  26. (in French)
  27. "BT price list: Section 13:BT IP Networking". BT. Retrieved 30 May 2019.
  28. ISO 8208:2000
  29. ISO 8208, Annex B.
  30. ITU-T Recommendation X.25, G.3.2 Called address extension facility, pp. 141–142.
  31. ITU-T Recommendation X.223, Appendix II.
  32. ITU-T Recommendation X.7 (04/2004), pp. 17–18.
  33. ITU-T Recommendation X.223.
  34. ITU-T Recommendation X.25 (10/96), Annex G, p. 140.
  35. ITU-T Recommendation X.213, Annex A.
  36. 1 2 3 ITU-T Recommendation X.25 (10/96), p. 45.
  37. ITU-T Recommendation X.283 (12/97), p. 42.
  38. 1 2 ITU-T Recommendation X.25 (10/96), Annex A, pp. 119–120.
  39. ISO/IEC 8208:2000, Fourth Edition, p. 61.
  40. ITU-T Recommendation X.2 (03/2000), p. 4.
  41. ISO/IEC 8208:2000, Fourth Edition, 3.7.1, p. 7.
  42. ITU-T Recommendation D.11 (03/91), p. 2.
  43. ITU-T Recommendation D.12 (11/88), p. 1.
  44. ITU-T Recommendation X.7 (04/2004), p. 42.
  45. ITU-T Recommendation D.11 (03/91), p. 3.
  46. ITU-T Recommendation X.7 (04/2004), p. 38.
  47. ITU-T Recommendation X.2
  48. ITU-T Recommendation X.7
  49. ITU-T Recommendation X.25 (10/96), Summary, p. v.
  50. ISO/IEC 8208:2000, Fourth Edition, Section 1: Scope, p. 1.
  51. 1 2 ISO/IEC 8208:2000, Fourth Edition, Annex C.
  52. ITU-T Recommendation X.25.
  53. ITU-T Recommendation X.25 (1993) White Book
  54. ITU-T Recommendation X.25 (1996) Grey Book

Further reading