X.25, X.31 vs Q.921/Q.921 and Networking Style in General


martillo@ATHENA.MIT.EDU
Thu, 26 Mar 87 20:31:35 EST


I have received a suggestion to move a discussion from a UUCP netnews
to this mailing list. I am also not on this mailing list and would
like to be added.

Path: bacchus!martillo
From: martillo@athena.mit.edu (Yakim Martillo)
Newsgroups: comp.dcom.lans,comp.dcom.modems
Subject: X.25, X.31 vs Q.921/Q.921 and Networking Style in General
Message-ID: <363@bacchus.MIT.EDU>
Date: 23 Mar 87 02:00:13 GMT
Sender: daemon@bacchus.MIT.EDU
Reply-To: martillo@athena.mit.edu (Yakim Martillo)
Distribution: net
Organization: MIT Project Athena
Lines: 136
Xref: bacchus comp.dcom.lans:180 comp.dcom.modems:269

I am working on getting a proprietary data communications system to
work over ISDN primary and basic rate interfaces. The system was
originally designed to use only PSDN (PDNs) as the communications
subnet. An end to end protocol was never designed so that individual
applications have their own end to end protocols. Eventually, the
developers put the communications system over a proprietary token
ring and ethernet, as well as point to point leased lines.

Since they wanted to modify the networking software as little as
possible, they basically used a slightly modified version of X.25
level 2 for the token ring (running on top of the token rings datagram
protocol) and ran X.25 level 3 on top of it. On ethernet they
substituted 802.3 for X.25 level 2 and ran X.25 level 3 on top of
that. And for point to point leased lines they run straight X.25. Of
course, they had some sort of procedure whereby one party becomes the
DCE and the other party becomes the DTE. Thus X.25 has basically
become the end to end transport protocol in the network unless a PSDN
is the communications subnet.

Now they want to put their network over ISDN using LAPD, LAPB, X.25
level 3, X.31 with Q.931/Q.921 signaling and I see problems with how
people use the X.25 family of protocols and what Q.931/Q.921 seems to
provide.

Full Q.931 seems to allow for "hold" (via hold, suspend resume
signaling messages) on a given CSC (Circuit-Switched Circuit), and in
fact I think I really want to do this because I could easily see an
individual user using 3 CSCs or more for a given session (e.g. remote
terminal session from A to B, while on B doing a remote copy from C to
B -- the user could easily be taking up 3 CSCs). With an average of
40 users on the machine with a full-blown remote file system and RPCs
(Remote procedure calls), I think it is fairly easy for even a PRI to
get fully loaded really fast, and I would want the PBX to send
indication of incoming calls even when there are no available
channels, so that the controller could put one call on-hold and then
accept the new call. For outgoing, if there are no channels available
I would like to put one call on hold and then place the new outgoing
call, and then round-robin (with prioritization for calls which have
outgoing data) the calls on the available channels.

In the case of a (2B+D or 1B+D) BRI on a workstation, the scenario
described above becomes even more problematic.

The problem comes in with X.25 restart and rest procedures as outlined
in the redbook and as typically implemented.

Deasington says in X.25 Explained (p.52) says:

The restart procedure is used to ensure that both the DCE and DTE
consider that all the PVCs and SVCs are in a known state. A restart
causes all PVCs to be reset and all SVCs to be cleared and free to be
used. The Network level will need to be restarted if the Link level
has failed for some reason, for example the line between the DTE and
DCE was disconnected. If the Link level has timed out and has been
restarted by the exchange of SABM, UA, etc., as previously described,
the Network level will be restarted by the DCE sending to the DTE a
Network level Restart Indication frame; in PSS the Restart Indication
frame will be sent to the DTE at intervals of six seconds until a
Restart Confirmation is received. The DTE may at any time transmit a
Restart Indication to the DCE if it needs to restart the Network level
completely, for example if it has completely lost track of the state
of the active SVCs.

According to the X.25 specification, resets should be generated on VCs
if data has been lost or a protocol error has occurred.

I have no problems with either restart or reset procedures as long as
disconnection of level 2 is not considered a protocol error because I
don't intend for my hosts to loose data in this case and I can set up
the following scenario:

1) non-alien host (i.e one of my hosts which form a part of my
   contractee's proprietary network) connects to non-alien host.

2) calling party exchanges XID with called party,
   establishes calling party as DCE and establishes
   automatic call-back in the event of disconnections while
   VCs are still active (sometimes CSCs just drop).

3) Level 2 gets connected. DCE does a network level restart.

4) VCs get started and normal data communications proceeds.

5) Called or calling party interface fills and incoming call arrives,
   Called or calling party interface selects channel to put on-hold
   (probably least-recently used algorithm), and stat muxes the active
   calls among physical channels.

6) Possibly, the level 2 of one of the calls on hold times out and
   becomes disconnected, when the call goes off-hold.

Now from the above in Deasington, apparently many PSPDNs automatically
restart the interface upon disconnection of the logical link under the
assumption this means the foreign interface had been turned off. I
think in the case of hold this should be utterly unnecessary and the
level 2 should just be reconnected transparently to the level 3.

6) Alternatively, the call drops for unspecified reason, the DCE
replaces the call, reconnects the link-layer, but does not restart the
network interface.

7) Eventually the number of VCs on the link goes to zero. Level three
on both hosts requests to controller to disconnect the logical level 2
and then to disconnect the call.

In the case of alien hosts who do not understand the proprietary
protocols, the alien host is always the DTE and the non-alien host is
always the DCE. Hold and auto-redial could be negotiated in the XID
but I would tend to make the default to disallow hold and neither
expect nor perform auto-redial in case of disconnect but rather inform
level 3 of termination of level 2 so that the VCs could be abnormally
terminated from the host point of view.

When one of my hosts calls a PSDN or is called by a PSDN, the PSDN
would of course be the DCE while my (non-alien) host would be the DCE.
Procedures about hold and auto-redial would be negotiated with the
PSDN at subscription time and could be exchanged in the XID.

To me this all seems like a perfectly reasonable way to do data
communications via ISDN (I mean real resource sharing not kermit)
however all the network "experts" at my employer totally freaked at my
suggest and scenarios.

I would like opinions. If you comment, I would be interested in your
background and experience because I guess I am conducting a survey and
I would like to have some sort of guide to weight opinions. If you
prefer, you may send your comments to me by private mail at

                        martillo@athena.mit.edu
                        ..!ihnp4!mit-eddie!athena!martillo

If there is desire, I can post the results to the net.

Yaqim Martillo

Path: bacchus!mit-eddie!rutgers!ames!ucbcad!ucbvax!ucbarpa.Berkeley.EDU!fair
From: fair@ucbarpa.Berkeley.EDU (Erik E. Fair)
Newsgroups: comp.dcom.lans,comp.dcom.modems
Subject: Re: X.25, X.31 vs Q.921/Q.921 and Networking Style in General
Message-ID: <17977@ucbvax.BERKELEY.EDU>
Date: 23 Mar 87 13:20:42 GMT
References: <363@bacchus.MIT.EDU>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Michael A. Padlipsky Fan Club
Lines: 6
Xref: bacchus comp.dcom.lans:182 comp.dcom.modems:270

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.

        Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu

Path: bacchus!martillo
From: martillo@athena.mit.edu (Yakim Martillo)
Newsgroups: comp.dcom.lans,comp.dcom.modems
Subject: Re: X.25, X.31 vs Q.921/Q.921 and Networking Style in General
Message-ID: <366@bacchus.MIT.EDU>
Date: 25 Mar 87 02:40:13 GMT
References: <363@bacchus.MIT.EDU> <17977@ucbvax.BERKELEY.EDU>
Sender: daemon@bacchus.MIT.EDU
Reply-To: martillo@athena.mit.edu (Yaqim Martillo)
Organization: MIT Project Athena
Lines: 77
Xref: bacchus comp.dcom.lans:189 comp.dcom.modems:277

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-expert 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



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:45 GMT