Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!accuvax.nwu.edu!nucsrl!telecom-request From: "Michael A. Patton" Newsgroups: comp.dcom.telecom Subject: Re: ISDN and TCP/IP Message-ID: <1932@accuvax.nwu.edu> Date: 8 Dec 89 01:32:47 GMT Sender: news@accuvax.nwu.edu Organization: TELECOM Digest Lines: 155 Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 9, Issue 559, message 1 of 4 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. :-)