WEBER@harvarda.bitnet (12/06/89)
Harvard University is installing a 5ESS running version 5 of the
software. We also have a fiber optic ethernet backbone network whose
configuration was chosen to permit easy upgrade to FDDI when such
bandwidth is required and when the upgrade is cost effective. The
environment is mostly Unix and VMS machines on the ether, running
TCP/IP with some DECNet. There is some LAT on local ethernets, but
only TCP/IP and DECNet will be supported on the backbone. The backbone
is implemented at present with cisco routers and subnets for various
faculties and departments. THere are a few IBM hosts that are or will
be running TCP/IP, including the server for the library catalog
application.
The is some confusion here about the utility of ISDN in the short
run and in long run. The following questions have arisen:
1. How do we create a gateway between ISDN and TCP/IP so that
the following common cases can get access to TCP (and the world):
a. Dumb terminals with an rs232 connection to circuit switched
d or b channels (i.e., 9.6 kbs or 64kbs).
b. Intelligent peronal computers such as msdos and macintosh
machines. These machines would ordinarily have ethernet
cards and run something like FTP Software's TCP implementation,
or NCSA Telnet on the macs. There might be a stray Unix box
somewhere (no one wants to run slip). THe ISDN connection is
BRI, not PRI.
c. Local area networks in buildings which are nt yet connected
to the fiber ethernet network. These networks are typically
Appletalk or TCP/IP itself, with a few Novell networks
here and there. Again, the ISDN connection is BRI, not
PRI.
Thanks for any information you can offer.
Robert Philip Weber, Ph.D. | Phone: (617) 495-3744
Senior Consultant | Fax: (617) 495-0750
Academic and Planning Services |
Division |
Office For Information Technology| Internet: weber@popvax.harvard.edu
Harvard University | Bitnet: Weber@Harvarda
50 Church Street |
Cambridge MA 02138 |"Michael A. Patton" <MAP@lcs.mit.edu> (12/08/89)
Date: Mon, 1989 Dec 4 21:27 EST From: (Robert Philip Weber) WEBER@HARVARDA.BITNET (glad to see Harvard's up the creek again :-) [Dr. Weber's description of Harvard's installation of a 5ESS in parallel with existing TCP/IP network removed -MAP] This is very much like the installation MIT has just gone through downriver. I expect that since your network & telecom people see ours all the time, they should already know much of this...here is my view from the "epicenter". > There is some confusion here about the utility of ISDN in the short > run and in the long run. The following questions have arisen: There was here, too. In fact there was a sometimes amusing presentation at the MIT Communications forum a couple of years ago, after both Harvard and MIT had jointly and independantly made their decisions, where the "responsible" parties from each organization (along with some others) talked about ISDN. As I recall the appropriate paraphrase from both the MIT and Harvard presentations on why they included ISDN in the purchase was, "It's the new telecom buzz-word. If we don't include it and it turns out to be a winner, they'll have our heads for getting stuck behind the times. If we do include it and it turns out to be a lemon, we can always blame it on the Telco...they over-stated its capabilities." Nobody there had any detailed concrete plans of even a single specific use to be made, but there was lots of fluff and smoke. I believe that state persisted even unto the actual cutover at MIT. (In fact the smoke persisted a little after cutover. :-) Harvard's probably just in that same boat. > 1. How do we create a gateway between ISDN and TCP/IP so that > the following common cases can get access to TCP (and the world): You build one yourself (the only way to get "a", meaning single box, at present) or buy what pieces you can. I'll describe what MIT has done or is considering for each of these. > a. Dumb terminals with an rs232 connection to circuit switched > d or b channels (i.e., 9.6 kbs or 64kbs) I'm not sure what you mean here, several points come to mind that you might be asking about. First, the connection (at 19.2kbps) between the dumb terminal on my desk and the ISDN is a standard DB25 on the back of this here AT&T 7506 phone. It even offers you the option of a semi-rasonable command interpreter or Hayes command set (but I guess Hayes is (tm) since the word does not seem to appear in the manual at all, I think they refer to it as "the industry standard AT command set", shades of Strowger and Step-by-Step). The second thing you might be trying to ask is for the case of someone without an actual ISDN connection in the office (i.e. POTS). These people can hook up any kind of modem to the line (they have a standard RJ-11) and call a bank of modems which gives them that same interface (at 300, 1200, or 2400 bps) preset to command interpreter (it's just some dedicated, no voice, connections with the same circuits and software as my phone). The third possibility is you were asking how people outside get connected to my machine if I put it on the ISDN. They can call a number (assigned seperately by telecom) which the 5ESS routes through that same modem bank, but then automatically connects through to my digital number. These three are all in service and in regular use on the MIT switch. > b. intelligent personal computers such as msdos and macintosh > machines. These machines would ordinarily have ethernet > cards and run something like FTP Software's TCP implementation, > or NCSA Telnet on the macs. There might be a stray unix box > somewhere (no one wants to run slip). The ISDN connection is > BRI, not PRI Again, I'm not quite sure which direction you mean to go here. If they're normally connected to your TCP/IP network via Ethernet, what more do you want? > c. local area networks in buildings which are nt yet connected > to the fiber ethernet network. These networks are typically > appletalk or tcp/ip itself, with a few novell networks > here and there. Again, the ISDN connection is BRI, not > PRI. The best use of ISDN here would probably be to simulate 64kbps leased lines and connect with some standard routers or bridges. You don't get full bandwidth, but with Appletalk at the end do you really care? If you do, pay to get the fiber. I thought Harvard was doing the same thing as MIT. I think we pulled an order of magnitude more fiber than the ESS and Network required together and distributed it to many more places. The cost of the fiber was small compared to the other costs of the installation and the labor to pull N rather than 1 is negligible. Once the fiber is lying there in the dark it doesn't cost a lot to run your photons through it :-). > Thanks for any information you can offer. You're welcome, but you didn't ask about the two most interesting areas (one of which MIT has in place and one of which is "under discussion"), so I'll get to them here. It's probably the case that you meant one of the above to include this and I just misinterpreted it, but I re-read them and I still don't see it. First, given the above, my terminal can reach all over campus at 19.2kbps. So what do I do? Everyone of interest is on the TCP/IP network (this is by definition, my job is managing TCP/IP networks :-) and they're not going to rush out and buy ISDN cards or X.25 software just so I can reach them. The answer is a box from Cisco (the one we use, other manufacturers also do this) with an X.25 connection at 64kbps on one side and an Ethernet connection on the other that knows how to translate between the respective terminal protocols and deal with terminals in general. You call it Pad.MIT.Edu, the MIT PAD. It's just like any other X.25 PAD except that rather than real terminal lines they're virtual using standard TCP/IP networking. Now, while I wait for all the random machines to put in something, I can always call PAD and connect over the network. Note that this system also works in reverse. If someone hooks up with an X.25 host connection designed to be called from a PAD, I can network from my workstation and use commands on Pad to set up X.25 calls. Second, can the 5ESS be used to provide an X.25 subnet to run TCP/IP over? This is the one that's "under discussion". I think the answer is "yes, but why?" I think what's going to happen here -- at least in the foreseeable future -- is that the ESS will be used for "leased line" type services to a few outlying spots, but that no general TCP/IP subnet service. ** * * * * * * * * * * * * * ** Gee, this turned out to be a lot more than I started out to say. Anyway to get back more directly to your specifics, Dr. Weber. I would suggest you should be talking to appropriate people at MIT and Harvard. I see you're in OIT, you should talk to Scott Bradner at Harvard, who should be in touch with Ron Hoffmann and Jeff Schiller here. I would also be willing to answer a few more questions (but it's their job), too. I suspect that MIT and Harvard are the very leading edge of exploring this and many more ideas (and questions) will come up as we expand it. __ /| /| /| \ Michael A. Patton, Network Manager / | / | /_|__/ Laboratory for Computer Science / |/ |/ |atton Massachusetts Institute of Technology Disclaimer: The opinions expressed above are a figment of the phosphor on your screen and do not represent the views of MIT, LCS, or MAP. :-)
jwb@cit5.cit.oz (Jim Breen) (12/11/89)
In article <1842@accuvax.nwu.edu>, WEBER@harvarda.bitnet asks: > 1. How do we create a gateway between ISDN and TCP/IP so that > the following common cases can get access to TCP (and the world): > a. Dumb terminals with an rs232 connection to circuit switched > d or b channels (i.e., 9.6 kbs or 64kbs). > b. Intelligent peronal computers such as msdos and macintosh > machines. These machines would ordinarily have ethernet > cards and run something like FTP Software's TCP implementation, > or NCSA Telnet on the macs. There might be a stray Unix box > somewhere (no one wants to run slip). THe ISDN connection is > BRI, not PRI. > c. Local area networks in buildings which are nt yet connected > to the fiber ethernet network. These networks are typically > Appletalk or TCP/IP itself, with a few Novell networks > here and there. Again, the ISDN connection is BRI, not > PRI. This is a question which comes up again and again, so it certainly deserves some considered attention. We are in a similar position with a backbone using ethernet and routers, and with ISDN compatible PABX's. We intend to make almost NO use of ISDN internally. We will be deriving B-channels for some of our intercampus traffic, and running them between routers, i.e. TCP/IP will be there at layers 3 & 4 but we don't have an interface problem because our (Plessey) digital handsets provide a standard X.21 64kbps interface. What you need to solve your problems are some ISDN Terminal Adaptors (TA) of various flavors. The problem is they haven't been developed yet! In (a) above you need a pair of asynch TA's, i.e. TA's which map various asynch speeds onto a 64k channel, enabling access to some sort of terminal server. In (b) we all hope there is a PC card coming which speaks BRI. Of course you need to connect somewhere, so it might be slip after all. For (c) a TA which can bridge ethernet segments would be fine. Clearly there is a long way to go with data access to ISDN, and there is room for a lot of innovative product development. Start shouting at your suppliers NOW. Better still, get some designers and builders together with a venture capitalist and go for it. _______ 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
euatdt@euas17c10.ericsson.se (Torsten Dahlkvist) (12/12/89)
Hello again! In article <2023@accuvax.nwu.edu> jwb@cit5.cit.oz (Jim Breen) writes: >What you need to solve your problems are some ISDN Terminal Adaptors >(TA) of various flavors. The problem is they haven't been developed >yet! In (a) above you need a pair of asynch TA's, i.e. TA's which map >various asynch speeds onto a 64k channel, enabling access to some sort >of terminal server. In (b) we all hope there is a PC card coming which >speaks BRI. Of course you need to connect somewhere, so it might be >slip after all. For (c) a TA which can bridge ethernet segments would >be fine. >Clearly there is a long way to go with data access to ISDN, and there >is room for a lot of innovative product development. Start shouting at >your suppliers NOW. Better still, get some designers and builders >together with a venture capitalist and go for it. Funny you should ask... I spent five years (83 - 88) as part of Ericsson's ISDN terminal project. We did produce a feature-phone and a range of TA:s which conform very closely to the "official" ISDN spec. The deviations were due to the fact that the specs aren't yet quite waterproof. There are, to put it bluntly, holes in the protocols at some places, so we had to device ways around these. Ericsson's terminals are available NOW for Ericsson customers. The TA:s handle V24, X21 and X25 to mention the more popular protocols. The only problems are availability and the prices... You see, we started that project way back before any VLSI:s had appeared on the market (actually, we cooperated closely with AMD in their work with their chipset) and the custom-circuits used in that first generation of terminals are *expensive* and hard to get. This puts the prices of the terminals at a level few customers can handle and in reality all sales so far have been to Telcos using Ericsson equipment who want to set up field-trials for ISDN. So why don't we re-build them using state-of-the-art hardware and market quick as hell? Partly because the afore-mentioned gaps in the protocols are still there, no *true* standard exists. Partly because no-one in their right minds ventures a project like that when it's well known that several major Japanese producers have competing products in the pipe-line. We're a high-tech, high-cost country. We can't compete with far east producers when it comes to volume sales and all projections indicate that we'd get the market kicked out from under our feet well before we'd made our investment back. However, all is not lost. There are at least a couple of Ericsson trials going on in the U.S. today so if you're lucky enough to be in one of them you may soon get your datacomm gear :-) Sorry if this all sounds like a lot of gripe and blatant advertising. It's just that when Jim said "The problem is they haven't been developed yet" I felt I had to point out that there's a difference between "doesn't exist" and "isn't available in the U.S.". I *know* for a fact that our equipment is beeing installed in Mexico City. But how do you sell telecom equipment on a market where everybody still believes in their hearts that AT&T is the best while spending half the bandwidth of comp.dcom.telecom arguing that Sprint is better... :-) Disclaimer: I DO work for an Ericsson subsidiary but that doesn't mean I have any say-so. Anybody asking for price-quotations will be promptly referred to some suitable sales-creature and will after that be constantly drowned in junk mail. Don't say I didn't warn you! Torsten Dahlkvist ELLEMTEL Telecommunication Laboratories P.O. Box 1505, S-125 25 ALVSJO, SWEDEN Tel: +46 8 727 3788