Are you trying to find a better technology for your telecommuters than 14.4 Kbps modems? If so, then you probably have looked into Integrated Services Digital Network (ISDN). ISDN offers lots of promise: with two 64 kilobit pipes, it can be a lot of bandwidth at a reasonable monthly price. At this level of bandwidth, working from home becomes much more acceptable. But does it work? And how hard is it to install? These next series of columns will let you know. ISDN, unlike the phone lines that we use everyday, is a completely end-to-end digital link, which has both opportunities and problems. The opportunities are both the extra bandwidth and that it takes almost no time to setup a call -- those of us that are familiar with the various tones and noises as two fast modems synch up can understand how many seconds are saved here. With minimal call setup time, you can have an application that connects to your network when you need it. Some of the ISDN products also allow bandwidth on demand, which means that you start out with one 64 kbps connection and get the second connection when your applications require more bandwidth. This is the way networks ought to work. The problems are that you need special gear that works with ISDN both on the server side and on the client, and that you have to deal with your local phone company to get this line. To make matters worse, not every place in the country has ISDN service yet, and not all ISDN implementations are interoperable, making long-distance connections problematic. My own location is a good example of being on the other side of the ISDN tracks. Being in New York, I have Nynex as my local phone company. Unlike Pacific Bell, which promises to have everyone ISDN-ready in California sometime by the end of this year, Nynex has been slow to get involved in the technology. Only a few places on Long Island, the suburbs east of New York and home to over 3 million people, have the service. The nearest ISDN-ready community to me is Manhasset, home to my former employer about 5 miles away. How do you check? Intel has taken the initiative and will tell anyone who calls their technical support number (800- 538 3373 x21) whether ISDN service is available -- just give them your area code and exchange. Intel gets this information from Bellcore, which as the research arm of the local phone companies has been pushing ISDN hard. Bellcore surveys each of its member companies and tries to keep the information up to date. I called Intel and they told me what I already knew -- that I couldn't get ISDN service in Port Washington. However, my next questions were more difficult: I asked them to search their database and tell me where I could go to find ISDN service in a nearby community, or else when I could expect service on my exchange. Their database isn't set up to do either kind of search. However, when I gave them the number of my old employer in Manhasset, they did correctly tell me that ISDN service was available there. To understand how to work ISDN into your network, let me take a minute and talk about products that are involved and the overall philosophy in getting them connected. First is the actual ISDN adapter itself. This can be either an internal card or an external box. The ISDN adapter has four wires generally and gets connected to a network termination device, called an NT-1 in telephony parlance. This device converts the four-wired ISDN computer interface into the standard two-wire telephone circuit, as well as providing power to the phone company's ISDN line. There are two distinct ways that an ISDN connection can look: either as a fast modem or as a slow network adapter. Various vendors have tried one or the other. The fast modem approach means that your applications will be terminal emulators and other modem-oriented devices. You'll need a driver for the ISDN product that works with your communications program. The network approach means that your LAN client software thinks it is talking to network adapter, so you'll need the appropriate drivers for the ISDN card (if it is internal to the PC) or a standard network adapter (typically, Ethernet) and cabling to attach it to the Ethernet port on the ISDN external box. My site for these ISDN tests was the Brigham and Women's Hospital located in Boston. The hospital has been on the forefront of several medical intiatives, and is trying to do the same when it comes to supporting ISDN. My work there was with John Lightfoot, manager of user and network support services for the hospital. Luckily, both the exchanges at hospital and John's home have ISDN service. The Brigham has about 3800 PCs connected on its token ring network of about 35 Novell 3.11 NetWare file servers and specialized servers running MUMPS, a multi-user operating system that originally ran on Data General minicomputers which have since been replaced for the most part by ordinary IBM Intel file servers. Many of the hosptial applications are written in this language, including patient records and various accounting functions. "Actually, these MUMPS servers first come up in DOS, and then boot MUMPS," said Lightfoot. "It is amazing that we can run databases that are hundreds of megabytes on these machines, but they work really well." The hospital occupies several buildings in Boston, and each building has a run of fiber to connect it to the central data center building. John had been using ordinary 14.4 modems with PC/Anywhere from Symantec to dial into his network from home and keep track of its health in off-hours. However, he wanted to see if an ISDN connection would be faster and more productive for him, as well as investigate whether the technology could be deployed to other hospital workers that eventually could telecommute and avoid the nasty driving habits that Bostonians look upon as ordinary activity. Next week, I'll tell you about the products we tested at the hospital. Strom.5 If you want to get ISDN up and running on your network so that remote users can telecommute, you will have to deal with your local phone company as a data customer. That could prove to be a real challenge. The scene is the Brigham and Women's Hospital in Boston. When I visited John Lightfoot, the network manager for the hospital, he had already been using ISDN to connect to his network from home. Trouble was, John recently bought a new home and had to start over with getting a new line. That took some time -- six weeks to be exact. We were trying to get a remote connection to his NetWare network over ISDN so John could continue to support his network in off-hours without having to come to the office. It seemed like a good idea. Nynex is one of those phone companies that still thinks and acts as if "data" is considered a four-letter word. They have made some effort to support data customers, such as calling 1-800-get-isdn to order service, assuming service is available in your area. And in Boston, Nynex has a special hotline number, 743-data, for its data customers. However, these efforts are just window dressing, and you'll see why. When I arrived at the hospital we hit a few snags. First, we realized that we only had a single NT-1 device. The NT-1 is needed on both ends of the ISDN link -- in other words, in John's home and at the hospital. We had to order a second one from the phone company, or a telephony supplier. These NT-1s are not cheap: they can cost as much as $400. Several vendors are promising ISDN products with an integrated NT-1 by the time you read this, although they weren't available when we did our tests late last year. Next, we decided to call Nynex and get the provisioning information for both lines. "Provisioning" brings up all sorts of 1880s-style camping and wild west metaphors for me, but I'll resist them for now. The word is used by the phone company to indicate how a line is configured for a particular kind of ISDN application. Of course, there are many, many parameters and many combinations that constitute a single ISDN configuration. What this means is that you'll be lucky if you can find two ISDN applications that have the same provisioning setup, so you should know what product you want to use before you order your line from the phone company. Of course, I think this is a bit backwards. Imagine having to first buy your telephone, then read the fine print in the user's manual, before you can order a phone line. Intel has come to the rescue, sort of. Intel sells both a remote access product and a video conferencing product, both of which run on top of ISDN. They have three different configurations: Red, Yellow, and Blue (why not white? Good question.) For most networking applications, you want Code Blue (which has some unfortunate implications in hospital parlance, but I'll resist those as well). This means that the two data channels of your ISDN line can carry either a single voice call or two data calls. These three different codes don't yet mean anything to Nynex, so we had to get the right provisioning details behind Code Blue and tell the phone company exactly what we wanted. Intel provides these details as part of their fax-back service (call 800525 3019 and ask for documents 8101, 8202 and 8109) When we called Nynex to get our provisioning information, we found out that we were trying to use a line in the hospital that was disconnected. They had brought up several ISDN lines earlier in the year for some other tests of Intel's ProShare video system, and when the tests ended these lines were disconnected. A single line remained and we had to track that down. In the meantime, we got our first ISDN products setup. We started out by examining products from three vendors: Intel, Digiboard, and Gandalf. Digiboard and Intel both have internal ISDN adapters that work for the most part like network adapters. Digiboard comes with NDIS and ODI network drivers for both the client and server side, while Intel uses packet drivers and shims to make theirs work. Both products support NetWare 3.x networks. Digiboard also supports Windows/NT, while Intel's supports Banyan, Lan Manager, and IP-based networks as well. Gandalf has an external box that must be attached to a computer via an Ethernet cable. Since Brigham is a token ring shop, this was less attractive to John and we decided not to test it. John liked the fact that the Digiboard had ODI drivers so we decided to start there. Digiboard's server-side installation is a bit arcane. We decided to use a separate test server which I provided. This server had a token ring card in it to connect to the hospital network, and the Digiboard ISDN card. You run a SETUP NetWare loadable module on the server to get the card installed. Unfortunately, this routine doesn't make any changes to your AUTOEXEC.NCF file on your server, which you will need to do manually if you want the Digiboard drivers to load the next time you bring up your server. I also didn't like the fact that the installation copies files to your NetWare SYSTEM directory, rather than asking for a location of your own choosing. Once the server software is installed, you have to next go to a Windows workstation, load a TSR, run the configuration program from the network and type in a variety of parameters. There is also a separate DOS configuration procedure for the client-side piece as well. All of this is too arcane for me, and John also had a tough time. Part of our problem is the manual takes a roundabout way of explaining what you need to do. Unfortunately, it is written from the perspective of someone who knows a lot about ISDN and very little about NetWare. In reality, as with both myself and John, the reverse is probably true. Intel's manual is a bit better explaining things on the ISDN side, but it still has room for improvement. What both John and I would rather see is a single option, based on the vendor used by the telephone company to provide ISDN service to your line. Stay tuned next week for more of our adventures. PC IMAC: $795, Digiboard, 6400 Flying Cloud Dr., Eden Prairie, Minn. 55344 800 344 4273, 612 943 9020, fax 612 943 5398 strom.6 I've been installing network products for many years but have never encountered as many problems as I did when it came time to bring up an ISDN line at the Brigham and Women's Hospital in Boston last month. Just about everything that could go wrong did. First John Lightfoot, the network manager that I was working with, managed to loose track of the ISDN line. He had been testing other ISDN products earlier and had several lines going into the hospital. It took a few calls around before we could locate the sole remaining active line. Then was the case of the missing NT-1, the device that you need to connect your ISDN adapter from Digiboard to the phone company network. We needed two of these to get things going, but only had one for some reason. More delay while we ordered a second part. Next we managed to literally smoke my test server that I had loaned John. I mean smoke: we turned on the machine and managed to melt part of my Dell's mother board. Why? Who knows? Anyway, that set us back a few days while we built another NetWare server from scratch. Then we had to get the right provisioning information from Nynex. Provisioning is the telephony-speak for how the ISDN line is configured. It didn't take long for Nynex to tell us how the hospital line was configured, although it did take John and I and a developer from Digiboard several hours to figure out the corresponding configuration for the Digiboard software. Digiboard has two different ISDN configurations for AT&T switches and we of course were using the wrong setup. More ISDN mumbo-jumbo: while it is nice that the phone company has so many choices, it is frustrating for end-users who are trying to figure out their products to know all these parameters ahead of time. Digiboard does have an auto-configuration option, but the tech support people we used didn't seem to trust it. So, after much ado, we managed to bring up the hospital server on an ISDN line and have the guys at Digiboard actually connect into it and see the hospital's NetWare servers. That was great, but we were only halfway done. Now we had to get the remote end at John's house setup. It took us three separate sessions before we could get things up and running. Part of the problem was another smoked PC: this time we managed to damage just the Digiboard ISDN adapter rather than the entire motherboard. Maybe it was something we ate, maybe it was something in the water -- who knows? I have never seen so much smoke before from one test plan. I guess we were just unlucky. Anyway, the smoked board was one problem. Another was obtaining the correct ISDN provisioning information, and being able to enter it into the Digiboard configuration programs. Another call to Nynex's data hotline. However, this call didn't produce any results. It turns out that the switch that serves John's home is made by Northern Telecom, and for some reason Nynex didn't have the provisioning information for the switch. "Nynex couldn't tell us how the line was provisioned," said Lightfoot. After a marathon conference call between them, us, and Digiboard, we managed to take a stab at the configuration, and luckily picked the right set of parameters. Somehow I felt like we should be in Vegas placing bets at the tables. But we still weren't done. The ISDN adapter in John's home PC was suspect, and although it would load the various drivers and seem to respond to commands, we could connect to the server at the hospital but couldn't see the NetWare servers. It was time to get another adapter from Digiboard and try that out. See what I mean about having a black cloud over us? Next week we'll talk about what happened when we get everything up and running.