Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!ames!ucbcad!ucbvax!bacchus.UUCP!martillo From: martillo@bacchus.UUCP.UUCP Newsgroups: mod.protocols Subject: X.25, X.31 vs Q.921/Q.921 and Networking Style in General Message-ID: Date: Tue, 24-Mar-87 21:40:00 EST Article-I.D.: SIMTEL20.KPETERSEN.12289354495.BABYL Posted: Tue Mar 24 21:40:00 1987 Date-Received: Sat, 28-Mar-87 00:42:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 74 Approved: protocols@red.rutgers.edu In article <17977@ucbvax.BERKELEY.EDU> fair@ucbarpa.Berkeley.EDU (Erik E. Fair) writes: >Do the obvious thing: chuck it all and use the DoD Internet Protocol >suite for this application. It is certainly clear that you need some >sort of transport that makes no assumption about the reliability of >the data link layers, and the X.* stuff doesn't seem to qualify. While I have enjoy Padlipsky's writing, you have missed the point (or I have accidentally mislead you), the X.25, X.31, LAPD, Q.921/Q.931 suite of protocols is not comparable to TCP/IP but is rather comparable to 1822. The ISDN switch is basically comparable to an IMP (or PSN nowadays I guess). One might argue about the virtual circuit orientation of the X.25 but in fact an ISDN switch is much more complicated than an IMP and you really need something more complex than 1822. As for the circuit orientation, from personal experience in dealing with the FCC, I believe tariffing a reliable virtual circuit access protocol in which the remote end point is specified is much easier than tariffing an access protocol like 1822. Of course, the existence of a level 3 reset is relatively stupid in a virtual circuit oriented access protocol, but the level 3 reset was *demanded* by the PDNs because of the limitations of their switches. Running TCP/IP on top of X.25 is just as reasonable as running TCP/IP on top of 1822 but as far as the PTTs and the private long distance carriers are concerned, they have no interest in an internetting layer or a transport layer built on top of it. A true internetting layer makes tail-end-hop-off (popping in and out between public and private networks where the two end point are accessing the catenet via public phone lines in order to decrease phone bills) and such a specification will never come out of CCITT. Now the proprietary network on which I am working was developed before the modern TCP/IP based Arpanet came into existence. As I understand it the pre-TCP/IP Arpanet basically used a predecessor of 1822 as an end to end protocol, so that my contractee's decision to go with X.25 as the network communications protocol was not unreasonable especially given that the major portion of their business is overseas where until recently no one did TCP/IP. Of course not learning anything from the Arpanet experience is pretty close to criminal but the company is being punished in its sales, so justice is being served. Granted, there is no real reason to run X.25 on an unrestricted digital 64kbps CSC bearer channel except that the CSC may equally probably be going to a PSDN as to one of the proprietary network hosts where one of the network hosts is acting as the DCE and pretends to be a PSDN. This is reasonable because if some other manufacturer supports some service via a PSDN, my contractee can directly offer that service to the other manufacturer's equipment because my contractee's equipment can pretend to be a PSDN. But my contractee is also trying to sell real data communications via a ISDN-PBX-LAN and my feeling is that while the network hosts can pretend to be PSDNs, among friends (non-alien hosts), the host that pretends to be a DCE does not have to imitate the non-obligatory procedures which PSDNs use like VC reset, some of the network-level restarts, the various worthless level 3 DCE timers. If they do complete imitation of the PSDN non-obligatory procedures, a CSC based ISDN-PBX-LAN running the proprietary data communications network should quite quickly become fragmented into topologically disconnected islands of network connectivity with evil consequences like dead-lock, loss of network services and inability to use to use some of the niftier features of Q.921/Q.931 [of course maybe they are trying to prevent the ultimate convergence of phone and computer hacking :)]. I would really like some genuine X.25/PSDN expert to tell me my suggestion is perfectly reasonable and is in fact the right way to do data communications in the environment of a CSC based ISDN-PBX-LAN using the X.25 suite of protocols. Of course, if I am wrong I would like to be told and be told why. The network-export at my contractee's has yet to show any understanding of data communications at a level more sophisticated than that of a PAD. Yaqim Martillo