Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!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: Sun, 22-Mar-87 21:00:00 EST Article-I.D.: SIMTEL20.KPETERSEN.12288677130.BABYL Posted: Sun Mar 22 21:00:00 1987 Date-Received: Wed, 25-Mar-87 03:35:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 132 Approved: protocols@red.rutgers.edu 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 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" 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 party interface fills and incoming call arrives, Called 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 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