Talk:X.25

--86.132.179.112 15:51, 31 July 2007 (UTC) Can anyone confirm the source of this statement?

"For much of its history X.25 was used for permanent virtual circuits (PVCs) to connect two host computers in a dedicated link. This was common for applications such as banking, where distant branch offices could be connected to central hosts for a cost that was considerably lower than a permanent long distance telephone call. X.25 was typically billed as a flat monthly service fee depending on link speed, and then a price-per-packet on top of this. Link speeds varied, typically from 2400bit/s up to 2 Mbit/s, although speeds above 64 kbit/s were uncommon in the public networks."

I've heard something similar from the lips of a CCIE as well so this seems to be an urban myth that's going unchallenged.

Someone more cynical than I might suggest that the telecoms/network industry would like this to become a well established "truth" so people don't question why switched virtual circuits aren't offered on more modern services like MPLS, ATM etc. As this would allow reselling of capacity, usage based costs and a cheaper alternative to fixed circuits. Even today with much reduced national and international telecoms prices that would be a revenue impact.

SVC services are also more difficult to implement in engineering switch design and are less reliable in operation i.e. network capacity planning.

And avoid the nightmare of usage based tariffs and billing that go with switched virual services.

So it's understandable why "PVCs have always been used in networks" would be a message everyone would want to gain acceptance.

X.25 switches in the early eighties could barely cope with the traffic carried and with the buffer allocation demands of PVCs the operators soon learned that PVCs needed to be priced very highly as large numbers damaged revenues and impacted overall network service by using up switch capacity. Some operators even stopped taking orders for PVCs as the impact was so significant.

Even the example cited above of branch network would best be implemented as a SVC solution as more resilience would be available via call re-direction. Most network traffic was dumb termainal X.3/X.28/X.29 based and that was definetely SVC based traffic.

PVCs I think were not in the X.75 interface specification and none of the PTTs/operators offered them internationally as far as I am aware.

I think the more truthful and historically accurate statement would be that X.25 networks were overwhelmingly SVC based but later network technologies like MPLS, ATM, SMDS and Frame Relay learnt the lessons of X.25 and went for a simpler PVC offering (i.e. what was offered as a commercially available service at reasonable cost to the majority). For the reasons of engineering, network operation and billing complexity as described above.

If you care about being accurate then the statement in the article about PVCs needs to be changed.

I've corrected the PVC section.

British Telecom stopped offering PVCs on PSS because they ran out of table space on the switches to define them. Many other PTTs never offered PVCs due to not having the necessary support/management infrastructure in place, or because their switches didn't support them.

PVCs were in practice more difficult to implement correctly than SVCs. The difficulty arises because PVCs can go up and down as when subscriber links or parts of the network go up and down. With the standard call establishment packets not being permitted on PVCs, Reset packets are used to convey the up/down indications. Many applications never correctly understood how this worked, and it was not uncommon for applications to be sitting there with a wrong impression of the state of their PVC(s).

81.187.162.106 (talk) 01:09, 20 July 2008 (UTC)

---

Shouldn't this line:

"Speeds increased during the years, typically up to 48 or 96 kbit/s" read 4.8 or 9.6Kbps instead of 48 and 96?

I think the history of X.25 is too oriented on UK history. France for example made a lot of work to establish X.25 as a standard. TRANSPAC was also the first X.25 packet-switched commercial network in the world.134.214.165.97 18:14, 24 January 2006 (UTC)

Shouldn't "data terminating equipment" be "data terminal equipment"?

---

JTE, UK

Correct - in CCITT (now ITU-T) literature DTE is Data Terminal Equipment (and DCE is always Data Circuit Terminating Equipment, not the more colloguial Data Communications Equipment).

"X.25 is an ITU-T standard protocol suite for wide area networks using the phone or ISDN system as the networking hardware".

I disagree fundamentally with that opening statement. X.25 is the __recommendation__ (ie definition) for an __interface__ between a DTE and DCE "for terminals operating in the packet mode and connected to public data networks by dedicated circuit". Specifically it was not / is not a protocol suite for "wide area networks". Such networks were frequently constructed using X.25 with proprietary extensions to cover the missing parts of the protocol. Such networks were complex to maintain and manage because routing, recovery from route failure and private numbering schemes were specifically not covered by the X.25 recommendations ITU-T did not concern itself with the details of network internals. It specifies interfaces into and between network providers including exchange of (some) management, operation and charging/billing details. ITU-T work was delibterately called Recommendations not Standards because they were often a minimum set of rules to obtain a degree of international operation.

Speeds: For the UK, in the early 80's access to X.25 was provided using a V-series private-wire modem link at speeds of 2400, 4800 and 9600bps. High speed "group band" modems provided 48kbps access (at great expense, in a 48kHz analogue channel). When BT first introduced Public Packet Switching, the core of the network ran at 48kbps using V.35 modems. Public PADs provided dial-in async terminal access at 200 or 300bps full duplex (V.21) and 75/1200 (V.23) assymetric full duplex. I believe Germany and France had digital access services using X.21 circuit switching.

In popular culture

In the movie Father of the Bride, the groom's character is a consultant who helps European banks link their x.25 networks with US-based banks' IP networks. Does this merit inclusion in the article? Jaysbro 20:26, 21 September 2006 (UTC)

Probably not, unless that fact is significant other than something mentioned in passing; I suspect most viewers of the movie would have little idea what an X.25 network is, and would only know what an IP network is because they might have seen references to "TCP/IP" in articles or in the parts of the UI of their computer that they don't like to use. :-) Guy Harris 00:18, 14 November 2006 (UTC)

man n ash.... —Preceding unsigned comment added by 202.63.162.90 (talk) 14:19, 4 July 2008 (UTC)

X.25 protocols vs. OSI protocols

How many of the protocols listed there were expected to run primarily or solely over X.25? Most stuff above the transport layer was presumably supposed to run over the OSI transport layer protocols, not over X.25; were the transport protocols expected to run directly above X.25, or above OSI network-layer protocols? Guy Harris 00:21, 14 November 2006 (UTC)

---yaaaaa...gr8 work........

Mobitex

Is it worth mentioning that the over the air interface for Mobitex is based around X.25? http://www.leapforum.org/published/internetworkMobility/split/node118.html Jonnyct 15:22, 9 June 2007 (UTC)

X.25 Today: NGN threat?

Does NGN (All IP) threaten to force the replacement of X.25 and similar non-IP protocols? My experience which such technologies is minimal so this may be an incorrect assumption of mine.

While there are assorted definitions of NGN, most assume highly reliable optical transmission media. X.25 remains a viable technique in certain media with high error rate, long delay, and low speed, including poor-quality landlines, amateur radio, some satellite links, etc. Howard C. Berkowitz 16:55, 8 August 2007 (UTC)

Plan to rework History, Architecture and Relation to OSI Model sections

These sections are horrible. They make assertions that conflict with common knowlege and the assertions made in other articles (Packet switched network and TCP/IP model) and verifiable sources (will be cited on rework). They use the wrong terminology (level 2 and level 3, instead of link layer and packet layer) and conflict with the primary documents X.25 and X.223. I intend to rework all three sections. — Dgtsyb (talk) 09:23, 3 July 2008 (UTC)

Virtual Calls vs. Switched Virtual Circuits

ITU-T Rec. X.25 and ISO/IEC 8208 refer to VC and PVC generally as virtual circuits; however, the services provided are termed virtual calls and permanent virtual circuits. Nowhere in these specifications does the term switched virtual circuits appear. The term switched virtual circuits appears only in the frame relay documents. Consistent with this, the virtual call service is only properly referred to as such and should not be referred to as a switched virtual circuit or SVC. Does anyone have a source citation to the contrary? — Dgtsyb (talk) 11:12, 20 July 2008 (UTC)

ITU-T Rec. X.7, Figure 6/X.7, p. 17, and Figure 7/X.7, p. 18, shows two services for PSPDN and packet mode ISDN: virtual call and permanent virtual circuit (referred to collectively as basic virtual circuit services). Figure 10/X.7, p. 24, shows two services for FRPDN (frame relay): switched virtual circuit (SVC) and permanent virtual circuit (PVC). SVC is only used to refer to the frame relay service throughout the document. Dgtsyb (talk) 11:44, 20 July 2008 (UTC)

SVC is definitely the term which was used during the life of X.25, and not virtual call. You can find this in online manuals for various X.25 products. I've just checked in some X.25 source code as well, and that confirms this too. (I might be able to find the 1980 or 1984 spec boxed up somewhere - if I find it, I'll look in there.) ITU may have attempted to rename after the event in the 1990's specs, but all major X.25 vendors had stopped developing X.25 by 1990. The last implementations are mainly 1984, with some 1988. The 1993 and 1996 specs don't describe anything that actually ever existed anywhere and should be ignored. 192.18.1.36 (talk) 18:21, 20 July 2008 (UTC)

(Friend 1988), see the References Section, that was printed before the 1988 ITU-T specifications, uses exclusively the terms Virtual Call and Permanent Virtual Circuit as well. No mention of SVC. I have Red Book specs in boxes somewhere in the basement too. I'm pretty sure those will use virtual circuit too. OK, I have ITU-T Rec. D.11 (1980) "virtual call facility", ITU-T Rec. X.244 (1988) "virtual call" (even in the title), ITU-T Rec. X.2 (1984) "virtual call", ITU-T Rec. I.232.1 (1988) "virtual call". It appears the the terminology was "virtual call" all the way back to 1980. I couldn't find any references to and X.25 virtual call as a "switched virtual circuit". I don't think that user manuals or code comments really count. Dgtsyb (talk) 21:42, 20 July 2008 (UTC)

Some more:

• I.232.1 (1988) (Blue Book Fasc. III.7) (Publ.: Jun 89) Title: Virtual call and permanent virtual circuit
• X.244 (1988) (Blue Book Fasc. VIII.5) (Publ.: Jul 89) Title: Procedure for the exchange of protocol identification during virtual call establishment on packet switched public data networks
• D.11 (03/91) (Rev. 1) (Publ.: May 91) Title: Special tarrif principles for international packet-switched public data communications services by means of the virtual call facility (even defines virtual call)

It is starting to appear that it was called a virtual call even in 1976.

-- Dgtsyb (talk) 21:53, 20 July 2008 (UTC)

An older one and a stronger one:

• X.244 (Malaga-Torremolinous 1984) (Red Book Fascicle VIII.5) Title: Procedures for the exchange of protocol identification during virtual call establishment on packet switched public data networks
• X.2 (Melbourne 1988) (Blue Book) International data transmission services and optional user facilities in public data networks and ISDNs (virtual call service and permanent virtual circuit service)

Dgtsyb (talk) 22:10, 20 July 2008 (UTC)

I found this statement on page 8 of ETSI NET 002:

SVC - Switched Virtual Cirtuit (In CCITT Recommendation X.25 [1] the term Virtual Call is used.)

[1] CCITT Recommendation X.25 (1984): 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

[2] CCITT Recommendation X.25 (1980): 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

So it looks like virtual call in 1984 at least. Documents other than X.25 appear to have propagated a different term. I think we should stick with virtual call because that's what it is in CCITT/ITU-T X.25 and ISO/IEC 8208, at least since 1984. That's 24 to 28 years out of 36 years of virtual call. — Dgtsyb (talk) 23:16, 20 July 2008 (UTC)

Is the X.25 protocol suite equal to, or a subset of, OSI protocol suite?

Currently X.25 protocol suite is redirected to X.25, but if the first is true, it should be recirected to OSI protocol suite.

Are all network layer protocols are of the X.25 protocol suite?Mange01 (talk) 13:35, 10 April 2009 (UTC)

X.25 is one protocol that may be used to implement the OSI CONS; however, it was necessary to add functionality to X.25 to support OSI CONS: for example NSAP addressing. Later it was referred to as the CONP (Connection Oriented Network Protocol), however, it is not the only protocol supporting OSI CONS: IEEE 802.2/ISO 8802 (LLC2), ATM and Frame Relay do as well. One should, therefore, view it as one of the protocols "implementing" the OSI network layer, rather than being in any way "equivalent" to the OSI network layer.

There is another issue: recent references to X.25 Packet Layer Protocol (PLP) and the Packet Layer Protocol article. X.25 does not describe a Packet Layer Protocol. It is ISO that describe the packet layer protocol. The Packet Layer Protocol *is* the competing ISO 8208 protocol. Therefore, I will remove reference to PLP as being the packet layer of X.25. — Dgtsyb (talk) 20:41, 10 April 2009 (UTC)

X.25 is an INTERFACE standard - not a standard for WANs, LANs, or anything else

The whole X.25 article needs to be re-written. As my data comm instructor used to beat into my head - X.25 is a DCE <-> DTE interface ... nothing more nothing less. —Preceding unsigned comment added by Zslg01 (talk • contribs) 20:16, 15 March 2010 (UTC) Zslg01 (talk) 20:22, 15 March 2010 (UTC)