Digital phone links are finally becoming more widely available and fast enough to link remote LANs and workstations. Frame Relay, Switched 56, and ISDN are the services to look for.
Jeffrey Fritz
Remote access to enterprise networks used to be in the same class with caviar, expensive limousines, and upper-class beach resorts--a luxury available only to a privileged few. Because connections to corporate computing services from offices or homes required a fair amount of engineering by the telephone company and MIS, they were neither easy nor cheap. Changes required issuing phone company work orders and were frequently out of the question. Eventually, even making new connections became difficult, as unused copper pairs in the telephone company's cables became scarce.
In addition, you need
ed a dedicated terminal to access corporate information systems; this equipment was installed in corporate offices and perhaps a few remote locations but was too expensive to place in employees' homes.
Today, as corporations move away from mainframe-based systems and onto LANs, terminals are being replaced by personal computers. PCs and LANs facilitate remote access to computing resources but don't, by themselves, solve the problems of remote connectivity. The key that unlocked the door to the remote office was the arrival of affordable, reliable digital telecommunications services coupled with inexpensive network hardware. A variety of digital telecommunications services now support remote connections to enterprise networks. Among the most common are Frame Relay, ISDN, Switched 56, and T1.
Frame Relay
Initially designed as a barrier service for ISDN (which in turn was originally intended to be the front-end access to WAN [wide-area networks] and metropolitan Frame Relay networks), Frame Rela
y has become an independent technology based on the X.25 protocol. Normally, X.25 incorporates extensive error checking at every node in the circuit. Frame Relay's creators, assuming operation over reliable digital links, removed the error checking to provide greater efficiency.
ISDN
Most RBOCs (regional Bell operating companies--the offspring of the AT&T breakup) have considered ISDN to be, in one form or another, the mainstay of their residential and business telecommunications services. The problem is, they kept ISDN a secret, which has delayed its deployment and also confused users. The carriers generally believe that ISDN can meet the voice, video, and data needs of almost every user.
ISDN comes in two primary flavors: BRI (Basic Rate Interface) and PRI (Primary Rate Interface). BRI ISDN offers what's called a 2B+D service (i.e., it has two 64-Kbps B [barrier] channels and one 16-Kbps D [data] channel). PRI, at least in North America, has 23 B channels and one D channel; all PRI channels
are 64 Kbps. Each B channel can support simultaneous and independent voice, video, or data connections. Therefore, one BRI can support voice plus two data calls; voice, video, and data; or multiple data calls. The choice is up to the user.
It's becoming easier to order ISDN, but it's far from one-stop shopping. Recently, I attempted to get rates from Bell Atlantic for an ISDN business connection. It took three separate calls to two different Bell Atlantic sales agencies before I had the information in hand--and I knew exactly what I wanted. I pity the poor user who doesn't know what to ask for.
Digital 56-Kbps Service
Older than ISDN, digital 56-Kbps service is still popular. It comes in two varieties: dedicated and switched. Dedicated 56 is a hard-wired service configured much like older copper circuits. Changes require work orders and several days. As with ISDN, Switched 56 can place calls to a variety of destinations. The user dials the connection, uses the service, and then hangs up.
Switched 56 service has its flaws, including an intolerably long call-setup time. The telephone carriers' in-band signaling systems can set up only one node at a time. If multiple nodes are needed, setup can take a considerable amount of time (e.g., a coast-to-coast connection can take more than 13 seconds and in-state calls aren't much faster). This long delay is deadly to most network applications, which are likely to time out well before the connection is completed.
Digital 56-Kbps service provides connectivity, but it's expensive. Generally, 56-Kbps service costs more than ISDN and offers less than half the bandwidth and half the channels of a BRI. In some cases, 56-Kbps service can be nearly as expensive as T1 service. As a result, it is rarely used for residential connections.
T1
The digital mainstay for corporate networks, T1 service has a bandwidth of 1.544 Mbps and is commonly used to connect various enterprise network sites. A variant, called Fractional T1 is related to ISDN's P
RI service; it breaks the T1 pipe into multiple channels. T1 lines are expensive and thus are rarely run to home offices and small businesses.
Personal Bridges
The appearance of low-cost network devices is radically changing the deployment of digital services. Until recently, bridging or routing equipment was expensive. Connecting a remote site required two bridges and a pair of CSU/DSU (channel service unit/data service unit) devices, or, for ISDN, a pair of terminal adapters. The total cost of all this gear was well over $30,000--far more than is to be spent for a single user.
Today, full-featured ISDN Ethernet bridges, as well as internal PC cards that serve as bridges or routers, are available for under $2000. Single-user, ``personal'' bridges can be found for around $500--not much more than a high-speed analog modem costs--and that includes everything you require on the remote side, except for the PC, NIC (network interface card), and network software. This is a cost-effective way to con
nect homes and small businesses to the corporate or university enterprise.
Ramming 10 Mbps Down a 128-Kbps Pipe
It's important to maximize the efficiency of slower-speed digital links used for remote-network access. And let's face it, even 128 Kbps is slow when compared to typical network bandwidths.
We've all seen what happens during a heavy storm when rainfall exceeds the capacity of the storm drains--the streets get flooded and dangerous. The same holds for interLAN connections. LAN bandwidth is typically 10 Mbps for Ethernet and 4 to 16 Mbps for token ring. ISDN's 64-Kbps channel achieves only a fraction of those speeds and, at first glance, seems inadequate for connecting networks.
In practice, this isn't really a problem. Although 100 users may share a 10-Mbps Ethernet network, each uses only a fraction of the available capacity. The entire bandwidth of a 64-Kbps ISDN link, however, can be devoted to a single user. In addition, not all network traffic needs to use the slower-spee
d link. Most LAN traffic remains local. Only traffic going from one LAN to another crosses the link, and this is typically only a small percentage of the total. Keeping local traffic local is the reason you connect networks with bridges or routers in the first place.
Also, many existing network devices themselves--repeaters, bridges, concentrators, and NICs--act as bottlenecks to network speeds. Tests performed on production LANs at West Virginia University indicate that, on a 10Base-T Ethernet, user throughput is typically no more than 700 Kbps. On a busy Ethernet or on one using slower NICs, actual user throughput can drop to around 300 Kbps. Using data compression, ISDN bridges can provide throughput greater than 210 Kbps. Thus, the apparent difference in bandwidth isn't nearly as marked as it first appears.
West Virginia University has networks in which 50 users are connected through a single 64-Kbps ISDN channel. Because the users perform interactive work (primarily database lookups) rather
than file transfers, their traffic requirements are relatively light. The connection is so efficient that the users can't tell whether they are connected through ISDN or directly to the remote network.
Bandwidth on Demand
Bandwidth management is the key to successful operation of digital links. Suppose that a network's connection requirements change--for example, additional remote workstations are added or a remote workstation begins performing highly data-intensive tasks--and the single 64-Kbps connection no longer provides enough bandwidth. To support users' needs, you simply add bandwidth to the connection in the form of additional B channels.
ISDN network devices can aggregate multiple B channels into one virtual channel. For example, many ISDN Ethernet bridges combine the two BRI B channels to provide 128 Kbps of aggregate bandwidth. This is achieved behind the scenes, using techniques such as Multilink or BONDing (bandwidth on demand). Multilink is a software-based method for adding ch
annels to the network connection. BONDing does much the same thing in hardware. It is more expensive and takes longer to set up or change than Multilink, but it has found favor in videoconferencing applications. Whether Multilink or BONDing is used, the result is the same--bandwidth is added as required. Users and network applications are none the wiser; all they see is a wider data-throughput path.
Multilink and BONDing are dynamic. If one channel is sufficient, only one channel is used. When the link needs to pass more traffic, the network device places more calls and adds channels as needed. When traffic demand falls off, the extra channels are dropped. Thus at any given moment, the network is using only the number of channels it requires to handle the traffic across the link. This minimizes connection costs.
Filtering
One of the most important ways to equalize digital connections with higher-speed LANs is filtering, the elimination of unwanted network traffic. For an enterprise network op
erating with a wide variety of protocols, filtering can add up to 30 percent more effective bandwidth. If you don't need to transport multiple protocols across the link, it's better to filter them out on the enterprise side of the network.
Networks frequently contain multicast and broadcast packets, which are bad news for a narrow-bandwidth network connection. They consume considerable bandwidth and, in many cases, represent superfluous traffic. Every network device receives multicast and broadcast traffic, and many devices generate it. On a large network, this represents a lot of traffic that isn't necessarily relevant to the remote user. A server on the enterprise LAN may simply be looking for a local client when it sends out multicast or broadcast packets. These quickly add up and, on a large network, can become quite numerous. This isn't much of a problem on a 1.544-Mbps T1 link, but it can make a big difference for slower links like ISDN. There have been cases of networks with over 128 Kbps in mul
ticast traffic alone.
While filtering can significantly reduce multicast and broadcast traffic, be careful not to eliminate them without first analyzing whether network services will be adversely affected. Some network protocols actually require broadcast or multicast traffic. For example, a network can age out a remote workstation that hasn't been heard from in a while. If there is subsequent traffic for that workstation, the ARP (Address Resolution Protocol) won't find it in the device table entries, and the network may have to send out a broadcast. Also, if broadcasts are carelessly filtered to the remote workstation, the network won't be able to locate the workstation.
Although not used as often as protocol filtering, address filtering can prevent packets from reaching particular devices on either side of the network. This might improve performance or add security options.
Security for Remote Access
There is an increased risk of unauthorized activity any time network access is give
n to more people. This problem is particularly acute with dial-up connections. Unless appropriate controls are in place, anyone can dial into the network.
Remote network devices typically provide some form of security. The most common methods are ICLID (Incoming Caller Identification) and authentication. Digital services such as ISDN can automatically supply the telephone number of the calling party. Network devices can check the ICLID before accepting the call to determine if the call is coming from a legitimate user. If the number isn't recognized, the call is rejected. This simple security procedure isn't foolproof. It won't work if the call originates at a location that doesn't issue the calling telephone number, and it can be fooled by using call forwarding to route the connection through a second number.
A better method of implementing security employs user authentication. Here the remote bridge sends a password or a random number called a challenge, depending on which authentication schem
e is used. The network bridge compares the password with a stored string or performs a computation on the challenge. If they match, the user is authenticated and given access to the network.
A separate authentication bridge can be used. As can be seen from the figure ``Authentication at the Bridge,'' the authentication bridge accepts calls from remote users. It verifies that the call originated from a legitimate bridge. The authentication bridge then finds an open bridge in the network bridge bank, instructs the open bridge to call the remote user back, and drops the original call from the user. This arrangement not only provides security but also makes it possible to perform call billing and charge-backs from a central location. (For a more complete discussion of network security issues and available control measures, see ``Distributed and Secure,'' June BYTE.)
You Can't Get There from Here
The network side of the remote LAN connection is important. Digital services are of little value if th
ere isn't anything to connect to on the other side. It's one thing to install an ISDN, Switched 56, or Frame Relay line. It's quite something else to provide real connectivity through the digital network. Whether it's the corporate computing system, the Internet, or the NII (National Information Infrastructure), there must be a destination to connect to on the enterprise side. For the Internet and the NII in particular, many questions are yet unanswered: Who will provide network access? How will they do it? At what cost?
How to coordinate network access is an increasingly hot issue. If normal telephone service was like these digital connections, I would first have to send you a letter asking you what kind of phone you have. I need to know because my phone will only work with equipment that is from the same manufacturer. If your equipment is different from mine, we can't talk.
Sounds ridiculous, doesn't it? Unfortunately, this situation is very common in remote-network access. Before we can conne
ct, I must know the answers to a number of important technical questions: What equipment do you have--a bridge or a router? What vendor made the equipment? Which network protocol or protocols should be used? Can your phone network connect to my network? What network addresses can I use? Gathering all this information from every network you want to connect to would be a nightmare. This is a big problem with ISDN, which has many different flavors that don't all interoperate.
Happily, Bellcore, the research arm of the RBOCs, has developed a standard that addresses some of these issues. Called N-ISDN (National ISDN), it provides for a series of progressive interconnection standards for ISDN voice and data services. Currently, N-ISDN 1 and N-ISDN 2 have been widely accepted by switch vendors and service providers. Work continues on an even more robust version, N-ISDN 3, which is planned to be the final iteration.
Many vendors realize that interoperability is critical to sales. The Enterprise Network
Data Interconnectivity Family of NIU-F (the North American ISDN User's Forum) will soon release an interoperability agreement that will allow any vendor's bridge to talk to any other vendor's bridge. A similar agreement will cover router-to-router communications. (Sorry, no router-to-bridge agreements yet--unless your router can pretend to be a bridge.) These won't resolve all the interoperability issues, but they're a good start. With full device interoperability, national and international standards, and a simplified way to order digital lines, plug-and-play networking may yet be possible.
Packet Resequencing
Moving data between networks presents another interesting problem. Consider a network in Washington, D.C., that is linked via a multiple-channel connection to an enterprise network in New York City (see the figure ``Split Telephone Routing''). The telephone network directs the call on channel two over a fiber route directly to New York. But the phone system sends the channel-one connection vi
a a satellite link that goes through Cincinnati before it reaches New York. Strange as this sounds, it happens all the time. Two calls placed one right after the other may routinely be given very different routings. The routes aren't necessarily short, either; the telephone company network uses least-cost, not shortest-length, algorithms for routing call connections.
With the link in place, the Washington bridge is ready to send its traffic. The table ``Putting Packets in Order'' shows the sequence in which packets are placed on the two channels and the order in which they arrive at the destination. As the table shows, the bridge alternates channels, putting the first packet on channel one and the second on channel two. However, because of the longer transmission delay on channel one, packet number two will arrive well before packet number one. In fact, for much of the transmission, New York will see two packets arrive from channel two for every one that arrives from channel one. A very nasty situation
.
Some network protocols (e.g., TCP/IP) aren't bothered by packets that arrive out of sequence; they just rearrange them in the proper order. Other protocols may come unglued, however. Their designers simply never considered the possibility that networks would be connected by multiple links that can deliver packets out of sequence.
There are two ways to deal with this problem. One is to place each protocol on a single link. Routers, even when using multiple channels, allow protocols to be delivered on a single channel. If there are three protocols on the network, it uses a separate channel for each.
Resequencing the packets is more elegant, because it allows multiple links to exist behind the scenes, increasing bandwidth for all protocols. Any protocol's packets are sent over multiple links and then reassembled in sequence on the other side before being handed over to the remote LAN. This fools the protocol into believing it has a higher-bandwidth connection operating over a single link.
And that makes every protocol happy. Many bridge and router products designed for digital links include internal algorithms that resequence the packets before releasing them to the network.
Whose Network Am I on Now?
Network protocols use numerical address schemes to determine where to send traffic. Each device on the network must have a unique network address, expressed as a number. If a computer runs multiple protocols, such as TCP/IP, IPX, and AppleTalk, it may require multiple addresses.
Addresses are generally associated with the network that the computer is connected to. With dial-on-demand, however, remote users may need to connect to multiple networks. They may link up with the corporate LAN to complete some work and then connect to a regional network to pass E-mail.
This can present problems, because the network addressing numbers and naming conventions will change from network to network. The address that was correct for the first network is wrong for the second. This is dang
erous; bad addresses can wreak havoc on enterprise networks. They can confuse network devices, cause conflicts, generate additional traffic, and cause remote-user and network problems as devices argue over which naming convention or address number is really correct. Unfortunately, network numbers aren't easy to change; it usually means fiddling with a configuration file, something the casual user cannot and should not be expected to do.
The problem of network number assignments for dial-in users has yet to be solved. Until it is, you should be careful when connecting to multiple networks.
Bridge Loops
It's all too easy to create bridge loops. Suppose an office in Cambridge, Massachusetts, uses a bridge to connect to its corporate enterprise network across the river in Boston. A second bridge connects Cambridge to an office in Framingham, 20 miles away. One day, the folks in Framingham enhance their communications by installing a bridge link between Framingham and Boston. Unfortunately, neithe
r they nor the Boston office mentions this to the Cambridge office. A triangle now exists from Boston to Cambridge to Framingham and back to Boston. Packets travel merrily around this loop, never dying. Because bridges don't expect to encounter a loop topology, they usually contain no intelligence to remove packets from the network. Therefore, the packets will travel forever around the circle. This condition is called looping, and it can be serious. Bridge loops can easily generate enough excess traffic to bring down an enterprise network.
A protocol called Spanning Tree can overcome this problem. Unfortunately, many remote bridges don't support Spanning Tree because it adds cost and complexity. In addition, it adds more traffic to the link.
Since remote bridge calls can be connected and dropped at will, bridge loops are difficult to spot. Network managers have to be extremely careful to coordinate their network topologies to avoid bridge loops. Fortunately, this is seldom a problem for networks
using routers, which can deal with parallel routes and looping without difficulty.
Making the Connections
Despite these problems, digital services are now a viable means of providing remote LAN access. Generally, the most inexpensive form of digital telecommunications is ISDN. After years of unfulfilled promises and delays, it looks as if ISDN is finally beginning to flourish. A number of RBOCs have announced ``ISDN Anywhere'' programs that allow you to order ISDN services even if your local phone company's central office isn't equipped to provide it.
Clearly, our world is changing. Today there is more reason than ever to tie home- based and traveling workers to the corporate umbilical cord. Full network-service capabilities allow efficient and effective work to be done in remote offices, on the road, or at home. Digital communications services are--at long last--ready to provide remote access to a wide variety of networks.
ACKNOWLEDGMENT
My thanks to Robert Downs of Combinet for h
is assistance with this article.
Putting Packets In Order
Splitting messages into separate packets sent along parallel routes with different transmission times may mean that they arrive out of order and thus require resequencing.
INPUT
PACKET PLACED ARRIVAL OUTPUT COMMENTS
ON PACKET PACKET
CHANNEL SEQUENCE (RESEQUENCED)
1 B1 2 - - - - - - Waiting for packet 1's arrival.
2 B2 4 - - - - - -
3 B1 1 1
4 B2 6 2
5 B1 8 - - - - - - Delay waiting for packet 3's arrival.
6 B2 3 3
7 B1 10 4
8 B2 5 5 Packet 5 delivered just in time.
9 B1 7 6
10 B2 9 7 Now all packets have arrived.
8
9
10
B1 transmission delay = 2 B2
Figure: Authentication at the Bridge
Authentication can be handled by an authentication bridge, which validates the user and has the network dial back to the requesting bridge to complete the connection.
Figure: Split Telephone Routing
A transmission is split and sent along two different routes, B1 and B2, but B1 takes significantly longer as B2, because it involves a satellite uplink.
Jeffrey Fritz is a telecommunications engineer responsible for the design and management of data communications for West Virginia University, including its ISDN Applications Lab. He is the author of Sensible ISDN Data Applications (WVU Press, 1992). He can be reached on the Internet at
jfritz@wvnvm.wvnet.edu
or on BIX c/o ``editors.''
Digital Remote Access
