Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!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: 24 Oct 89 09:55:32 GMT Sender: news@vector.Dallas.TX.US Reply-To: Torsten Dahlkvist Organization: Ellemtel Utvecklings AB, Stockholm, Sweden Lines: 91 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 471, message 1 of 8 In article 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