Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!wuarchive!gem.mps.ohio-state.edu!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!gryphon!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: 9 Nov 89 09:49:26 GMT Sender: news@vector.Dallas.TX.US Reply-To: Torsten Dahlkvist Organization: Ellemtel Utvecklings AB, Stockholm, Sweden Lines: 84 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 504, message 3 of 5 munnari!cit5.cit.oz.au!jwb@uunet.uu.net (Jim Breen) and I have been having a little discussion about byte/bit transmission over ISDN. I said: >> The basic ISDN-frame is byte-oriented and the hardware (in this case >> the ISDN-chip in the SPARCstation) ALWAYS provides a frame sync to >> allow you to read the bit stream byte by byte. Why? Because the >> TELEPHONY transmission is byte oriented.......... ... and he countered: >Ok I'll bite. WHERE in the Red or Blue books does it say the B >channels are byte oriented. Of course, the networks will go to a lot >of trouble to maintain synch, which they do out of band, i.e. using >the F bits on the S bus, and timeslot 0 on the primary access. If >SPARC terminals are adding a frame synch, that's terrific for them; >provided they are always talking to other SPARC terminals. We're looking at different levels of the system. The ISDN frame consists of a frame recognition pattern, D-channel bits and B-channel BYTES. Your basic ISDN chip will extract the clock frequency, B-channels and D-channel and output them separately. Typically the B-channels appear serially on an output pin, eight bits B1, eight bits B2, next eight bits B1 and so on. Since maintaining the byte-wise sync is absolutely crucial for telephony, the frame sync is used together with some counter device and the clock to read the eight bits wanted at the moment into the next device along the line. In a telephone this will be the codec. In some datacomm equipment it can typically be a shift register bank, where the output clock on the other side is the 64000 bps synchronous data rate. 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. It would be trivially easy to implement a byte-wide parallel output instead of the serial one, if some scheme for flow control and such could be established. >> In the bit-oriented datacomm standards specified, this frame sync is >> simply ignored, as far as the interface to other equipment is >> concerned...................... >I'll say they they ignore them; they never see them. I maintain synch >info is NOT sent on the B channel. Certainly. What I'm talking about is the frame surrounding the B-channels. This is ALWAYS available at some level in the hardware. It might not be a good idea to let this generate a system interrupt, however. An interrupt every 125 us to handle a single byte of data seems inefficient. Probably use some kind if FIFO and empty it at regular intervals. If it can be cross-connected with DMA to pipe directly into main memory, all the better! >> >must NEVER be a standard protocol above Layer 1. ISDN is to be a >> >bit-pipe service. >> Aren't there ANY byte-oriented protocols around that could be used to >> form a basis for a bytewise link over ISDN? There are obvious >> advantages. >Sure, there are several: HDLC, LAPB, etc. etc. Different pairs of >users make up their own minds. Of course, if you are using your B >channel to access a service, such as a packet-switched network, you >will have to fall into line with that network. Here in Australia >Austpac access will be available through the B channel, with LAPB as >the link protocol. It will be available for BRA users over the D >channel, in which case LAPD will be used. You seem set on insisting that we stick to the same old methods we've used all along. I suppose that's safer from many points of view. As a (former) designer of the systems involved, however, I feel it's a shame that we can't let them come to full advantage by making use of all the inheritent possibilities. On the other hand, maybe the net gain from eliminating the HDLC frame info from the data stream isn't big enough to justify the work of specifying a new standard. Some kind of flow control, packeting and such would still be needed, so it might turn out not worth it in the end. Torsten Dahlkvist ELLEMTEL Telecommunication Laboratories P.O. Box 1505, S-125 25 ALVSJO, SWEDEN Tel: +46 8 727 3788