NETWORK "TALK"

This is the tenth Bulletin in the series about recent developments in computer usage and technology. The prior installments covered computer components, printers, data storage systems, cabling and various networking issues (including network hardware, software and shared network support services such as fax and CD-ROM). This issue continues with a discussion about network-based communications and multi-location networks (i.e., Wide Area Networks or WANs).

The basic purpose of a local area network (LAN), as prior Bulletins have discussed, is to link workers together in an office or factory so that they can (1) communicate with one another, (2) access common information and (3) share the use of expensive resources such as high speed printers. But it's a rare workplace that's need to communicate is totally self-contained in a single office. Nearly every organization depends on communications with outside sales or service people, branch offices, customers, suppliers or the public at large. The rest of the Bulletin discusses the various methods by which networks can provide cost-effective links to these outside locations.

DATA COMMUNICATIONS

It's generally illegal with few exceptions to run a cable across public rights-of-way, including all streets and highways. Thus common carriers, principally telephone companies, must be used for this kind of connection and, as things stand today, telephone circuits are usually least expensive. This will likely change over time due to the recently passed Telecommunications Act of 1996 (see "From the Editor"). However, these changes will take at least a year or so to phase in, and even when they do, the basic principles described here will probably remain basically the same.

The three most common types of data communications that LAN users need are:

The ability to dial out to contact other computers or computer services.
The ability to dial in from a remote location to access LAN-resident data.
The ability to dial in from a remote location and work.

It may sound like these last two are the same thing, but from a networking perspective, they aren't.

Dialing out.

The simplest way for a LAN-based PC to connect to a communications line is the same as it is for a "stand-alone" PC . . . via a modem. But this is terribly inefficient in a network environment because few users need data communications more than a couple of minutes a day. It's not that the communications equipment is so expensive it isn't, although it isn't trivial either the big expense is the monthly phone line cost.

In a typical LAN, a few phone lines connected to a "communications server" are usually more than enough to support everyone. Whenever users need to communicate, they just "tell" their computer to dial out, the same as if they had their own modems . . . and the LAN handles everything. The only difference is that if all the lines are in use, they get a busy response and have to try again later.

Two lines are a minimum for most business environments (to avoid long "busys"), and that will usually suffice as a start for the first 25 to 30 users. Another line should be planned for each 25 30 users beyond that initially, and more lines can be added as usage grows.

Dialing in.

Dialing into a LAN is a totally different situation than dialing out because, with outbound dialing, the communications server "knows" which network-based computer is involved: the one dialing out. With inbound, however, the desired recipient for the call could, theoretically, be any server or user computer on the LAN. And since they all usually share the same inbound phone number, the server has to determine the intended recipient and make the connection.

Two different types of dial-in calls regularly come into communications servers: those calling for a "remote node" connection to the LAN and those calling for a "remote control" connection. In network parlance a "node" is a PC connected directly to the LAN, thus a "remote node" is one operating the same way, but from a distance. Computers running as remote nodes work much like a LAN-based computer . . . except that the phone connection between the computer and the LAN is only about 1/350th the speed. Because of this difference, remote node connections can only be used for functions that don't need a lot of data to be transferred between the network and the user, like checking e-mail.

"Remote control" connections, on the other hand, can handle applications that require greater amounts of data transfer. In a remote control connection, the remote computer actually "takes over" an unused computer located on the LAN. The only data that passes between the two are the changes to the screen image (from the LAN-based computer to the dial-in computer) and the remote user's keystrokes (from the dial-in computer to the LAN-based computer). Everything else is done by the LAN-based computer to limit the amount of data that has to pass across the relatively slow phone connection. The advantage of this technique is that it allows remote users to use databases and applications that require lots of data transfer between the network and the user's PC. The disadvantage is that it requires spare PCs to be set up specifically for use as remote control "hosts".

Depending on the needs of the dial-in users, most smaller LANs can probably get away with just remote node or remote control. But larger and more complex LANs will undoubtedly wind up having to support both.

WAN COMMUNICATIONS

The challenge in connecting two or more LANs together into a Wide Area Network (WAN) is the same as it is for dial in and dial out: the speed of the available phone lines is so much slower than the speed of the LANs being connected. In fact, normal voice grade (i.e., analog) phone lines can't be used at all because they're too slow and unreliable; faster digital phone lines are required.

Until recently, only a few types of circuits were available for this kind of connection, of which two are most popular:

DDS circuits with a speed about twice that of a high-speed (28.8) modem.
T1 circuits with a speed equal to 24 DDS lines, but even these are only about 15% of the speed of a LAN.

Both types of circuits are priced on a distance basis, with DDS lines usually starting in the hundreds and T1s in the thousands of dollars per month.

Several new types of digital circuits have become available and practical in the last couple of years, however, and several others are expected to come onto the market soon. All these new offerings can transfer data at speeds equal to or greater than DDS circuits, and most of them are considerably more cost-effective.

The most popular new type of connection so far has been one called Frame Relay. These circuits have a base speed equal to that of DDS lines, but they can be bought in multiples and then combined into a single "pipe" to achieve greater throughput. In addition, they're designed for traffic that comes in bursts (as LAN-to-LAN traffic normally does), rather than a steady stream, and can expand for short durations to handle heavier data flows. Frame relay pricing is usually a bit less than equivalent speed DDS lines.

ISDN lines (Integrated Services Digital Network) have been around in selected areas for years . . . and they've had a few users. But they're notoriously hard to install and, until very recently, very few phone companies had put in the central office equipment needed to support them. A basic ISDN line has a little more than double the capacity of a DDS circuit and, depending on distance, could cost more or less when used to connect LANs.

Other options in use include various types of wireless links (radio wave, microwave, satellite, etc.), some of which require a direct line-of-sight. It's not easy to generalize about the speed and cost of these lines because they're usually variable . . . the more you spend, the faster the connection you can get.

Because of the Telecommunications Act of 1996, common carriers are about to enter a new era. New kinds of data communications circuits suitable for WAN applications will soon be offered by local phone companies, long distance phone companies, cable companies and possibly even electric utilities. Some of these including ATM (Asynchronous Transfer Mode), ADSL (Asymmetric Digital Subscriber Line), HDSL (High-data-rate Speed DSL) and VDSL (Very high-data-rate DSL) will offer transmission speeds in the range of, or even exceeding those used in most LANs today. And, with competition, it's hard to predict just how competitive the prices might get. It's nearly certain, however, that DDS, T1 and Frame Relay will have to come down in price to compete or these new options will obsolete them for all WAN connections in the future.

Using Public Circuits

Although some organizations will always use dedicated private lines, many others may soon be using public circuits, such as the Internet, to connect their WANs. The Internet itself, however, may get so crowded (depending on how its usage develops) that it becomes too slow for LAN-to-LAN connection. But if so, several commercial carriers offer similar services on a reasonably priced pay-as-you-go basis with the same speed as the fastest private lines. And since these circuits are shared among lots of subscribers, their cost can be much less than comparable private circuits.

The key to using public, rather than private, connections is encryption. Data encryption software needs to be secure enough that users can it them to send confidential information without fear of compromise. For this to be do, popular encryption software has to be strong enough that even if a message is intercepted, it can't be effectively decoded. This capability is available today with mathematical algorithms so complex that today's most powerful computers need decades to decode even a short message. But so far, the federal government has been discouraging their use for what it claims are national security reasons. However, such discouragement will ultimately prove useless and unenforceable and, when it does, the use of public networks for WAN connection will become common.

Click here to read the previous article: Servers and Services: What Networks Are Really For Agree or disagree? . . . Take it up with the author.

Back to the top of the page If you have questions or need consulting assistance, mail to: brooks@bizauto.com or call Business Automation at (602) 264-9263 Copyright ©1997 Business Automation Associates, Inc. Bizauto and Bizauto.com are trademarks of Business Automation Associates, Inc.