gnu@toad.com (John Gilmore) (10/23/89)
I am interested in hooking up SPARCstations over ISDN. The machine comes standard with an ISDN terminal interface chip (the "sound" chip, really an ISDN speakerphone chip). The problem is data encoding; I have seen no documentation of standard ways to encode data passing on the 8000 byte/sec channel for IP. I have seen references to ways of encoding e.g. 9600 baud async "RS232" traffic over ISDN, but I will be talking ISDN-to-ISDN, so can use the full bandwidth. Rumor has it that somebody had standardized bit-oriented protocols (HDLC) over ISDN links, which is ridiculous since they are byte oriented links, sort of like storing data in main memory with bit stuffing just in case you ever need to do clock recovery on main memory. My preference would just be something like "PPP". Can anyone on Telecom provide details on upper level ISDN standardization efforts? All I have found was low level protocols; once you get to the 8000 bps byte stream, it's left up to the user to define. (I could go ahead and do this, but I can't get Sun to support it since they want to go with standards even if they are brain dead standards. They say Suns talking to Suns is not interesting. I say getting ANY two pieces of data equipment talking over ISDN would be a miracle at this point.) Please reply by email since I usually don't have time to read Telecom. [Moderator's Note: But please cc: telecom so all of us can share. PT]
goldstein@delni.enet.dec.com (10/23/89)
In article <telecom-v09i0469m02@vector.dallas.tx.us>, gnu@toad.com (John Gilmore) writes... >I am interested in hooking up SPARCstations over ISDN. The machine >comes standard with an ISDN terminal interface chip (the "sound" chip, >really an ISDN speakerphone chip). The problem is data encoding; I >have seen no documentation of standard ways to encode data passing on >the 8000 byte/sec channel for IP. I have seen references to ways of >encoding e.g. 9600 baud async "RS232" traffic over ISDN, but I will be >talking ISDN-to-ISDN, so can use the full bandwidth. Rumor has it >that somebody had standardized bit-oriented protocols (HDLC) over ISDN >links, which is ridiculous since they are byte oriented links, sort of >like storing data in main memory with bit stuffing just in case you >ever need to do clock recovery on main memory. My preference would >just be something like "PPP". Okay, it's like this. ISDN provides "circuit mode" and "packet mode" data services. The "packet mode" is essentially X.25, with call setup either inband (after making a circuit call to the X.25 switch) or modified to use ISDN out of band signaling (i.e., Q.931). In any case, CCITT X.31 tells you all about packet mode. Circuit mode is just like modems, but faster. You get 64 kbps per second. It's "raw bits" (oat hulls, wheat chaff...) and no more. It's isochronous (sync) so you need to have some framing technique. It is NOT byte oriented at this point! So HDLC is quite natural, but byte-oriented protocols (i.e., DDCMP) are technically possible too. HDLC chips do all the work anyway, you don't ever put stuff-bits in main memory. To run async or lower speeds, you use rate adaptation. Two standards exist: V.120 is new and HDLC_based, while V.110 is older and more popular among Europeans than Americans. And you can of course create your own if you want, since it's end-to-end. (Northern Telecom has one called T-link that's widely used.) So to do framing, you can use essentially any L2 protocols. I wouldn't advise SLIP on my worst enemy (well, maybe if I really didn't like him and wanted his errors to go undetected) but ISDN isn't anything special in that regard; you just use whatever L2 that both ends agree to. fred
euatdt@euas11c05.ericsson.se (Torsten Dahlkvist) (10/24/89)
In article <telecom-v09i0469m02@vector.dallas.tx.us> gnu@toad.com (John Gilmore) writes: >I am interested in hooking up SPARCstations over ISDN. The machine >comes standard with an ISDN terminal interface chip (the "sound" chip, >really an ISDN speakerphone chip). The problem is data encoding; I >have seen no documentation of standard ways to encode data passing on >the 8000 byte/sec channel for IP. I have seen references to ways of >encoding e.g. 9600 baud async "RS232" traffic over ISDN, but I will be >talking ISDN-to-ISDN, so can use the full bandwidth. Rumor has it >that somebody had standardized bit-oriented protocols (HDLC) over ISDN >links, which is ridiculous since they are byte oriented links, sort of >like storing data in main memory with bit stuffing just in case you >ever need to do clock recovery on main memory. My preference would >just be something like "PPP". >Can anyone on Telecom provide details on upper level ISDN >standardization efforts? All I have found was low level protocols; >once you get to the 8000 bps byte stream, it's left up to the user to >define. (I could go ahead and do this, but I can't get Sun to support >it since they want to go with standards even if they are brain dead >standards. They say Suns talking to Suns is not interesting. I say >getting ANY two pieces of data equipment talking over ISDN would be a >miracle at this point.) O.K. let's see. First of all, you must bear in mind the basic differrence between ISDN and TCP/IP (apart from the speed). TCP/IP is packet-oriented. ISDN is still circuit-switched in the normal operating modes (i.e. unless you connect via some interworking unit in the exchange for hooking up with other networks). This means that in order to connect one Sun to another via ISDN you have to create a link between them - in a fashion similar to when two modems connect: sending the dialling information to the exchange which then offers the call to the other machine which responds if it finds the call compatible. This also means that you are subject to all the normal "telephony" hassles, like the receiving party (your file-server?!) beeing busy with another call and refusing to talk to you... All the information to set up and disconnect calls is transferred on the D-channel and this is already completely standardized, if rather complex. The compiled binaries to handle these things in our ISDN equipment are about 150 kByte large and the work to write the stuff took a couple of man-years. As far as I know, the hardware available in the SPARCstations is roughly equivalent to the stuff we used. If you really want to go through with this you won't have to worry about what to do for a while. ;-) Once the call is set up you have your 64 kbit data link. What you do with it is basically up to you. If you're content to go at <64 kbit speeds you can adopt the standardized rate-adaption scheme with frames providing sync patterns and some additional data (not likely to be usable in your case). If you go for the full 64 kbit speed you do indeed have an 8 kByte/sec byte-oriented link. The ISDN standard doesn't go any further than that. The upper layers of the OSI-model are _not_ included in the standard! You can compare a SPARCstation with built-in ISDN-chip with a PC with a built-in modem chip. What you have is roughly equivalent to the hardware of a modem but no software. After you decide what kind of use you need you can set it up accordingly. Write the "auto-dialling" software and you can connect it to another machine with a similar interface. After that you can use any old protocol for the data transfer. Regard the ISDN port as basically similar to a serial port and make it login-able (start a getty on it) to allow remote users and/or semi-manual protocols like Kermit or UUCP. If you want to use the ISDN link as an alternative to TCP/IP, you're probably best off using it to TCP/IP-connect a remote machine to an Ethernet system at some other location. (You still have to write the ISDN software to connect the link.) That way you could use the existing TCP/IP software with fairly few and simple changes to route through the ISDN terminal interface chip. That solution would probably please Sun too. It uses a standard... :-) I'm sorry if this doesn't sound too cheery. I'm afraid that until some ISDN protocol software goes public (ours is NOT!) there's little you can realistically do, unless you're in a position to start a university project or something similar to get a large team to help you. The work is HUGE! My suspicion is that the reason Sun put that chip in the SPARCstations is that they hope some university will rise to the bait. It would certainly boost ISDN if it happened (and that chip is cheap compared to the cost of a SPARC :-). Please get in touch if there's anything else I can answer for you. Torsten Dahlkvist ELLEMTEL Telecommunication Laboratories P.O. Box 1505, S-125 25 ALVSJO, SWEDEN Tel: +46 8 727 3788
jwb@uunet.uu.net (Jim Breen) (10/25/89)
gnu@toad.com asks, of ISDN > The problem is data encoding; I > have seen no documentation of standard ways to encode data passing on > the 8000 byte/sec channel for IP. I have seen references to ways of > encoding e.g. 9600 baud async "RS232" traffic over ISDN, but I will be > talking ISDN-to-ISDN, so can use the full bandwidth. Rumor has it > that somebody had standardized bit-oriented protocols (HDLC) over ISDN > links, which is ridiculous since they are byte oriented links....... They are NOT byte-oriented 8000 byte/sec; it is BIT oriented 64000 bps. You can put any protocol you like on an ISDN B-channel. Protocols have been standardized for the D-channel, as this is for signalling and packet traffic. There *are* ISDN standards for mapping lower speeds onto a B-channel. Check out standards I.460-464 from the CCITT Red Book for starters. > Can anyone on Telecom provide details on upper level ISDN > standardization efforts? All I have found was low level protocols; > once you get to the 8000 bps byte stream, it's left up to the user to > define........ This is how it should be! There are standards for various things to intercommunicate over ISDN, such as Group 4 Fax, etc., buter there must NEVER be a standard protocol above Layer 1. ISDN is to be a bit-pipe service. _______ Jim Breen (jwb@cit5.cit.oz) Department of Robotics & /o\----\\ \O Digital Technology. Chisholm Inst. of Technology /RDT\ /|\ \/| -:O____/ PO Box 197 Caulfield East 3145 O-----O _/_\ /\ /\ (p) 03-573 2552 (fax) 572 1298
gnu@toad.com (John Gilmore) (10/30/89)
It seems clear that either nobody is doing IP over ISDN, or they don't read Telecom! My thanks to the authors of the several useful responses; however, there seem to be some misconceptions about ISDN in general among Telecom readers. goldstein@delni.enet.dec.com wrote (others said similar things): > You get 64 kbps per > second. It's "raw bits" (oat hulls, wheat chaff...) and no more. > It's isochronous (sync) so you need to have some framing technique. > It is NOT byte oriented at this point! I beg to differ. First, the rate is 64000 bits per second; "64kbps" implies 65536 bits per second (at least to me!). Second, the frame sent between the on-premises ISDN interface and the terminals (phones) contains its own framing, and individual BYTES of data for the two D channels are contained in the frame. The AMD speakerphone chip provides byte oriented access to all ISDN B-channels and routes *bytes* among the different interfaces (audio in, audio out, two B-channels, microprocessor port, and serial interfaces). But we don't even have to refer to the standards; we have brains. If you are sending raw audio data over this link, the network had better retain byte synchronization, or the 8-bit audio samples would quickly garble into unintelligibility (7 chances out of 8 to get the wrong byte sync, unless the network maintains it for you). > Two standards exist... And you can of course create > your own if you want, since it's end-to-end. This begs the question of interoperability, which was my whole point. If I "create my own" IP-over-ISDN standard, and you implement it another way, we can't talk to each other even though we can dial each others' computers. Someone else said "what's the point -- ISDN only runs for two or three miles anyway". I don't know where they got that idea. Last I heard, ALL of the >500-mile AT&T switching centers went to digital transmission years ago, and they have been pushing digital encoding back toward the CO's ever since. ISDN is the standard for the stretch between the CO and the customer. (There *is* this problem with the idiots who designed the AT&T T1 relays not putting in enough frame sync, so they had to steal the bottom bit of one 8-bit subchannel as frame sync -- leading to "56K" (8000 7-bit samples) rather than "64K" (8000 8-bit samples) service. But I read that they have a plan in place to upgrade those bogus relays -- and meanwhile, they could just software-route the real 8-bit ISDN traffic through one of the subchannels that doesn't get its low order bit munged by the relays. Technical corrections welcomed.)
euatdt@euas11c05.ericsson.se (Torsten Dahlkvist) (11/09/89)
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
kaufman@neon.stanford.edu (Marc T. Kaufman) (11/13/89)
In article <telecom-v09i0504m03@vector.dallas.tx.us> Torsten Dahlkvist <euatdt@euas11c05.ericsson.se> writes: >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. >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. 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. Marc Kaufman (kaufman@Neon.stanford.edu)
desnoyer@apple.com (Peter Desnoyers) (11/14/89)
In article <telecom-v09i0504m03@vector.dallas.tx.us> euatdt@euas11c05. ericsson.se (Torsten Dahlkvist) writes: > 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 ... > >> [...] 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. In my opinion that is what "8 kHz integrity" means when applied to ISDN data calls. (ref. Q.931, low-layer compatibility info element.) This only suggests such a guarantee, however - to prove it would require the appropriate reference from the ISDN service specification. > 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, ... > 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. Peter Desnoyers Apple ATG (408) 974-4469 * I don't mean to suggest that any major LD companies would do this. Someone will, however.
lars@salt.acc.com (Lars J Poulsen) (11/14/89)
In article <telecom-v09i0506m06@vector.dallas.tx.us> 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). Just before HDLC became ubiquitous, DEC designed the last byte-oriented protocol: DDCMP. This is full-duplex, sliding-window and all that good stuff. It also allows transparent binary 8-bit data. DDCMP frames start with a byte count and end with a CRC. You'd still need some idle pattern, DDCMP has a sync character defined. > 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? The same thing that always happened when the two ends are dissimilar. They won't talk to each other. What happens when one end is async data and the other end is synchronous ? They won't talk to each other. This should not preclude us from designing a better protocol. / Lars Poulsen <lars@salt.acc.com> (800) 222-7308 or (805) 963-9431 ext 358 ACC Customer Service Affiliation stated for identification only My employer probably would not agree if he knew what I said !!
jwb@cit5.cit.oz (Jim Breen) (11/14/89)
> Continuing Torsten Dahlkvist and Jim Breen's > little discussion about byte/bit transmission over ISDN. > 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. [...] This is correct for the S-bus interface, and for the T interface for Basic Rate. Primary Rate is different. > [...] Since maintaining the byte-wise sync > is absolutely crucial for telephony, [....] 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. > >> Aren't there ANY byte-oriented protocols [...] > >Sure, there are several: HDLC, LAPB, etc. etc. [..] > 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. I quite agree. 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. _______ Jim Breen (jwb@cit5.cit.oz) Department of Robotics & /o\----\\ \O Digital Technology. Chisholm Inst. of Technology /RDT\ /|\ \/| -:O____/ PO Box 197 Caulfield East 3145 O-----O _/_\ /\ /\ (p) 03-573 2552 (fax) 572 1298
goldstein@delni.enet.dec.com (11/15/89)
This has degenerated into a "tastes filling/less great" kind of
argument. ISDN is a candy mint/breath mint.
Okay, have it your way. ISDN provides 8 kHz integrity, which means
that it does guarantee octet accuracy for the 8 kHz services,
including circuit mode data. You put in an octet, you get out an
octet. Voice coders need that; HDLC doesn't. But HDLC does need bit
sequence integrity, so (for example) if you have two separate 64 kbps
channels, you can't simply combine them and expect all 16 bits to be
delivered in sequence; each channel may have different delay
characteristics. H channels maintain 8 kHz integrity.
HDLC protocols are usually processed on the ISDN chip, so the 8-bit
chip output is taken after bit-destuffing. You tell the chip if it's
HDLC or not; if not, you get raw bits. But the network itself
delivers raw bits with 8 kHz integrity, and it's your option to use a
bit or byte protocols.
DDCMP does have its advantages...
fredeuatdt@euas11c05.ericsson.se (Torsten Dahlkvist) (11/15/89)
In article <telecom-v09i0506m06@vector.dallas.tx.us> 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 <telecom-v09i0508m03@vector.dallas.tx.us> 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 <telecom-v09i0508m01@vector.dallas.tx.us> 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
zweig@brutus.cs.uiuc.edu (Johnny Zweig) (11/17/89)
A codec needs a byte-stream. If ISDN is going to be used with real live 8-bit codecs, there will have to be a byte-stream protocol on the wire. The frames already contain D-channel data as well as off-hook/on-hook bits (or at least that is the Party Line), so no need to do ugly nonsense like robbing the 8th bit. I can whip up a SLIP at 64000bps that will make me happy if I have a line that takes 8000 bytes every second and hands them to whoever I called. Routing and other considerations are research-problems and belong in comp.protocols.tcp-ip. I just want as many bytes/second as I can squeeze out of the wire. SLIP is a framing-protocol, so forget HDLC. I promise to be the only one using the bits. I just don't get this business of taking a byte-stream protocol and layering a bit-stream protocol on it (lowering the bandwidth available to payload), and then putting a byte-stream on that (using, say, bit-stuffing and further lowering available horsepower). Could someone please explain? It seems dumb. Now, if I envision having several interfaces contending for the 64kps, I need a medium-access protocol such as HDLC. Fine. Let me call someone who speaks HDLC if I want to use HDLC -- otherwise, let me use all the bits and call someone who expects that. HDLC is a bit-oriented protocol (see Tanenbaum, "Computer Networks", p. 254). It seems inappropriate, wasteful and silly to use it on a byte-oriented physical medium (which ISDN has to be to support digital telephony). I just don't get it. -Johnny Bits
goldstein@delni.enet.dec.com (11/18/89)
In article <telecom-v09i0516m04@vector.dallas.tx.us>, zweig@brutus.cs.uiuc. edu (Johnny Zweig) writes... >I can whip up a SLIP at 64000bps that will make me happy if I have a >line that takes 8000 bytes every second and hands them to whoever I >called. Routing and other considerations are research-problems and >belong in comp.protocols.tcp-ip. I just want as many bytes/second as >I can squeeze out of the wire. SLIP is a framing-protocol, so forget >HDLC. I promise to be the only one using the bits. If you are happy using SLIP then you have other problems to worry about! :-) SLIP is NOT a valid data link protocol. While it provides framing (as do HDLC, DDMCP, etc.), it provides NO error detection, let alone recovery. So you trust the weak checksums in TCP and IP to detect line noise. From a data integrity point of view that's seriously bad. (That's a general-purpose anti-SLIP diatribe, btw.) >I just don't get this business of taking a byte-stream protocol and >layering a bit-stream protocol on it (lowering the bandwidth available >to payload), and then putting a byte-stream on that (using, say, >bit-stuffing and further lowering available horsepower). Could >someone please explain? It seems dumb. You don't lose much with HDLC, about 1/63 to the bit-stuffing, and with only one flag at each end of the frame, it's probably comparably efficient to SLIP. You gain pretty good (not great) error detection (CRC_16), and optional hop-by-hop error recovery (I vs. UI frames). Since HDLC is used on the D channels already, it's built into ISDN chips, making it cheap. fred