Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!texbell!vector!telecom-gateway From: euatdt@euas11c05.ericsson.se (Torsten Dahlkvist) Newsgroups: comp.dcom.telecom Subject: Re: TCP/IP over ISDN Basic Rate Message-ID: Date: 15 Nov 89 11:42:10 GMT Sender: news@vector.Dallas.TX.US Reply-To: Torsten Dahlkvist Organization: Ellemtel Utvecklings AB, Stockholm, Sweden Lines: 94 Approved: telecom-request@vector.dallas.tx.us X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@vector.dallas.tx.us X-TELECOM-Digest: volume 9, issue 513, message 4 of 5 In article kaufman@Neon.Stanford. EDU (Marc T. Kaufman) writes: >The maintenance of frame sync on ISDN circuits would certainly allow >you to send DATA at the frame rate (8 KB/sec), but then you would lose >the "out-of-band" information of the HDLC frame, such as FLAG and >IDLE. I always felt that BOPs were a MUCH cleaner way of maintaining >packet synchronization than kludges like Transparent Bisync (DLE-SOH, >DLE-SYN, DLE-ETX, DLE-DLE, etc). Besides, this is only going to work >on pure digital ISDN-ISDN circuits. What happens when one end of the >connection is a remote X.25 dial-up? >I like to use all the bits, too, but you shouldn't overly constrain >the channel. I guess you're right. The highest "standardized" net bit rate maintaining some form of framing within the data channel is 56' bps (I've decided to start using the "56'" notation for 56000 as opposed to 56 k which can be thought to mean 56*1024). The gain from 56' to 64' is 12%, maybe not worth it. But the framing at 56' is still pretty sketchy. Does it really provide all the info you want? The highest "rate-adapted" rate that I know of that provides the _full_ HDLC framing etc. is 48' bps. There are attempts to send framing at 56', but they aren't standardized (yet? :-). As regards the problems when leaving the ISDN system, you must realize that all such connections must always run through some sort of gateway. This IWU (Inter-Working Unit) must of course be compatible with _both_ ends of the dialogue. If I want to introduce "my" standard for 8' Byte/s, then IWUs knowing this protocol must be installed at strategic points in the network. This is really not very different from the conversion needed when leaving the digital network to access an analog phone line (except that X.25 is a *little* more complicated :-). BTW: Exactly which is the ISDN chip installed in the SPARCs? I seem to recall (but I can't be sure) that it was from AMD. Is that correct? In article jwb@cit5.cit.oz (Jim Breen) writes: >Now that Torsten has amplified his original statment, I agree with >*most* of what he says. The exigencies of telephony will result in a >de-facto byte synch, which can potentially be exploited by >manufacturers. We need to watch out, though. If one device always >expects an HDLC Frame octet to turn up in "synch", but the sender >offsets it a bit (as it is allowed to do), we will have no >communication. >[....] There is a potential gain if you could insist on >all devices alligning their frames with the ISDN frames, but 8 >bits is not much overhead. Also, you need some way to mark start >and end of frame. Exactly. Somebody mentioned a protocol from DEC that seemed reasonable. However, the effort of making it a standard seems hardly worth it. In article desnoyer@apple.com (Peter Desnoyers): >> Now do you see what I'm getting at? Up until the codec/shift register, >> a strictly byte-wise transmission is essential for the function of >> your equipment. > That is irrelevant, as it applies only to voice calls. There is no > reason why a telco must treat voice and data calls identically. If you > don't want to risk getting your data ADPCM'd or sent over analog > facilities by some el-cheapo LD company*, you'd better request data > service. In that case, only the guarantees in the spec for data > service hold. Since we're fantasizing about introducing a new standard here, there's nothing to keep us from dreaming about persuading CCITT to include it as an accepted ISDN call class. One of the pre-requisites for this class would necessarily be the strict upkeep of byte-alignment throughout the network(s). Another pre-requisite is that the users would no longer be allowed to offset data bit-wise *in such a call*, just like you need to conform to the specs of X.25 when using *that* protocol. Maybe I should make it absolutely clear that I am in no way advocating the use of ISDN in non-standard ways. The question which started this thread of discussion was if there was any way that you could *theoretically* use the B-channel byte-wise. My answer to that was "yes, but you'd need to extend the specs for ISDN". Technically it is quite possible. I don't think it will ever be done, though. Torsten Dahlkvist ELLEMTEL Telecommunication Laboratories P.O. Box 1505, S-125 25 ALVSJO, SWEDEN Tel: +46 8 727 3788