#
Upgrading and Repairing Networks

# - 4 -

# Upgrading to a WAN

WAN stands for wide area network. Although the definition of how big an area has to be before it gets to be wide varies, the most common definition is that a WAN is one that extends beyond the boundaries of a single building.

Why extend a local area network (LAN) to a WAN? If it seems unnecessary to extend a network beyond the bounds of a building, think of only a few years ago when it seemed unnecessary to extend computing ability beyond a single machine. After the mainframe dependency of the sixties, stand-alone machines finally became powerful enough to hold their own data and processing power. After a time, however, the people using these powerful stand-alone computers realized that there had been some advantages to computing's physical structure in the sixties, and networking began to experience a renaissance--first to peer-to-peer networking and then, more and more, back to some form of client/server networking.

The natural outgrowth of this new interest in networking computing resources is the WAN, as companies outgrow their original sites and move part of the operation to another office. Rather than lose the resources moved to the new building, many companies have begun exploring the possibilities of wide area networking.

Wide area networking offers a lot of advantages to companies in a position to take advantage of it:

- Flexibility of location: not all of the people using the same data have to work at the same site
- Communication between branch offices can be improved via e-mail and file sharing
- A centralized company-wide backup system
- Companies located in a number of small interrelated offices can store files centrally and access each other's information

## Differentiating a WAN from a LAN

This distinction isn't as easy to make as it once was. If you're on a LAN, you work in the same office as your data and the network is generally faster than any WAN connection. Today, the distinctions between LANs and WANs have blurred.

- New technology can make some WANs as fast as LANs
- Telecommuting has led to increased use of remote access and remote control software

### Speed

Until fairly recently, speed was one of the most obvious things that distinguished most WANs from most LANs; all other things being equal, the WAN was generally slower than the LAN.

Today, new technology has made native LAN speeds a reality in some parts of the United States--that is, in some areas, you can get a wide area connection that can keep up with your LAN. (You'll learn about this technology and its limitations in the "Fiber Distributed Data Interface (FDDI) across a WAN" section later in this chapter.)

### Accessibility

Although a full discussion of remote control and remote node access is reserved for chapter 27, "Adding Remote Network Access (Telecommuting)," you're probably well aware that you can buy software--or some network operating systems, like Microsoft's Windows NT Server--that allow clients to dial into your network and use it from another location. Remote control access allows the client to control a physical computer attached to the network, while remote node access allows the client to dial in and become a member of the LAN, albeit a much slower one.

Telecommuting is becoming a reality for more and more companies. The numbers will only increase, what with the environmental regulations requiring companies of more than 100 employees to take steps toward instituting telecommuting where practical. Even some employers who don't have to follow the EPA line are beginning to see the advantages that telecommuting can offer and more will follow. Are these remote users connecting to a LAN, or does their presence make it a WAN?

I'd argue that telecommuters do not make a LAN if they're working from a single PC at home and using a modem to dial in. Once you start adding more PCs on the home side, a faster connection, or office users accessing the home PC, then it makes more sense to talk of a telecommuting connection as a WAN. For the present, however, most remote connections are more LAN-like than WAN-like.

### What's a MAN?

MAN, which stands for metropolitan area network, is a WAN confined to a single metro area or city. Although you'll see this term in networking literature often enough that you should know what it means, it's generally not a very useful term. First of all, the definition of a metropolitan area is pretty flexible. In the Washington, DC area, for example, the metro area covers parts of three states. Richmond, on the other hand, has a metro area that pretty much involves Richmond and a few suburbs. Applying the same term to Richmond's metro area and that of Washington, DC doesn't make much sense.

Even though the definition of a MAN is a bit ambiguous, it more or less defines the area of a local access telephone area (LATA). A LATA is a logical (as opposed to physical) grouping of telephonic points of presence (POP). As it's more or less confined to a LATA, one WAN technology is MAN-based by definition. Switched Multimegabit Data System, which is discussed in more detail in the section "Switched Multimegabit Data Service (SMDS)" later in this chapter, in its basic form is confined to a local telephone area.

## Understanding WAN Terminology

Much of the terminology associated with WANs is similar to the jargon that you know from working with LANs. However, since the jargon used isn't always identical, you'll learn some of the WAN-specific terminology that is used to talk about the various wide area technologies.

### Packets

Most newer WAN technologies transmit data in the form of packets, which contain both the data and the means to get that data to its destination. Packets are easiest to understand if you think of them as regular postal mail (or just snail mail). Packets are like mail in that

- An "envelope" identifies the packet as a unit in the flow of correspondence
- The addressing information on the envelope notes the recipient and usually the sender
- The envelope contains the actual data, which makes the bulk of the packet

The Envelope. The envelope, or the structure of the packet, puts the data into a form that the connection can understand. Just as the postal system wouldn't be able to mail your letter if you wrapped it in a lettuce leaf instead of an envelope, most connections require some kind of standard container; that's where the basic form of a packet comes from.

The Addressing. For the data to get to its destination, at the very least it requires the address of its intended recipient. For any kind of acknowledgment that the data was received, it also needs the sender's address. There is, however, a special name for packets that don't require any kind of acknowledgment--they're called datagrams. When you send a datagram, the only way you know that it didn't reach its destination is if the recipient tells you that he or she never got the message.

The Data. The amount of data that is included in each packet depends on the type of packet. Frames, used in frame relay (discussed in the later section "Frame Relay" contain more data than cells (discussed in the later section "Switched Multimegabit Data Services (SMDS)." For the moment, just remember that the size of the packet will always be greater than the amount of data in it, just as a letter includes more paper and writing than the paper and writing used for the letter.

You can see the basic information contained in a packet in figure 4.1.

Figure 4.1
Generally speaking, a packet will contain the information shown here.

Different WAN technologies use different packets. For example, some older WAN technologies incorporate error-correcting information into the packet so that if some data in the packet gets lost or corrupted in transmission, the missing data can be reconstructed on the other end. Because the fiber-optic cables used in modern telephonics and WAN connections are less vulnerable to the kinds of electronic noise that can corrupt data, error-control capabilities are less necessary for the WAN technologies designed to use these digital lines. Error-control is discussed later in this section, but that's one example of how not all packets are identical.

Packets can vary not only in content but in size. For example, some WAN technologies enclose their data for transmittal in a kind of packet called a frame. Frames can vary in size and don't even all have to be the same size within the same kind of WAN. WAN access protocols using frames are collectively called frame relay technologies. Other WAN types, on the other hand, package data in small packets of fixed size (53 bytes) called cells. Access protocols using cells are collectively called cell relay technologies. If your WAN involves more than one technology and those technologies use mutually unintelligible packet types, you'll need to come up with some method of converting one packet type into the other. Generally speaking, the quoted speeds of cell relay technologies will be higher than the quoted speeds of frame relay technologies.

> Frame Relay versus Cell Relay: Which Is Better?
> Why is cell relay faster than frame relay if cells are smaller than frames? After all, the top speed of frame relay "in the wild" is about 2 Mbps, while SMDS starts at 1.544 Mbps and goes up from there. Asynchronous Transfer Mode (ATM), another cell relay technology, starts at around 155 Mbps and goes up to 2 Gbps. (We'll talk more about the details of particular frame relay and cell relay technologies in the course of this chapter.)

> The answer to this puzzler is that cell relay isn't exactly faster, it just works differently and is meant to do different things from frame relay technologies.
> Framing technologies are designed to squeeze more throughput from bandwidth than is technically possible. The idea is that you can connect a number of different sites with a relatively skinny pipe by exploiting the fact that all of those sites are probably not going to transmit at the same time. It's much the same idea as a bank that loans out its deposits--the bank depends on not every depositor demanding its money back at the same time. If there's a run on the bank, the bank can't pay everyone back; if there's a run on bandwidth (that is, more sites need it than there's room for), then frames get dropped. Because frame relay technologies interleave frames from a number of different sources at once, the frames in a single source's transmission won't necessarily arrive at their destination in a smooth stream, so frame relay WAN access works best for "bursty" data like text and static pictures where it doesn't matter which order the frames arrive in so long as they get there.

> Cell relay technologies have a different function: rather than trying to squeeze more throughput out of existing bandwidth, cell relay is designed to make it possible to transmit a variety of data types (real-time voice and video and static data like text and pictures) over the same pipe. The packets used in cell relay are a uniform size (53 bytes) and travel in a steady stream to their destination. The throughput of cell relay depends on both the exact technology used and the size of the pipe through which the cells travel.

### Packet Switching versus Circuit Switching

If you're wondering why you should care what a packet is, it's because packets use a different method of getting from point A to point B than some other data forms do. This method is known as packet switching, to distinguish it from circuit switching.

First of all, what is switching? Simply put, it describes how data finds a path from its source to its destination. A circuit-switching network defines a static path from one point to another; so long as the two points are connected, all data traveling between those two points will take the same path. Thus, it's unnecessary to include adddressing information in the packet with the data. Because there's only one path, the data can't get lost.

In a packet-switching network, on the other hand, there is no direct connection from point A to point B. Rather than a direct connection, the packet-switching network has a mesh of paths between the two points (see fig. 4.2).

Figure 4.2
A packet-switching network has no set paths for data to travel.

A packet-switching network has no permanent physical path determining how data moves from point to point. Instead, the addressing information in the packet helps route the data its destination. You could think of a circuit-switching network as a complex of moving pipes, each disconnected from the others and a packet-switching network as a complex of connected pipes, through which data travels, choosing its path based on variables like traffic conditions.

> NOTE: Circuit switching is faster because there's less overhead required, but packet switching is more flexible and so less vulnerable to "traffic jams."

Establishing Virtual Connections. When a connection is established between point A and point B on a packet-switching network, the network evaluates itself and sees how busy each of the paths are. Generally speaking, it will send the packets along the most direct route, but if that route is congested (that is, if another connection is already using it) it will choose a perhaps longer but less congested route. Think of it like this: you probably know the most direct route between your home and your workplace. If, however, you leave the building one day and hear that a five-car pileup has backed up traffic on your regular route, it's clear that the most direct route is not a good idea that day. Instead, you'll try your alternate route, the one that goes through three residential neighborhoods because even though the alternate is longer it'll be faster at that point.

Once a path between the two ends of the connections is established, that path won't change for the duration of the connection, even if a shorter path becomes available. Similarly, every time the connection is reestablished, the network evaluates the traffic conditions and finds the best route at that time. Packet-switching networks are not creatures of habit.

Practical Differences. The way that packet-switching networks send information affects both the kinds of data that they can transmit and the amount of overhead involved. A circuit-switching network establishes a physical connection between two points, whereas a packet-switching network establishes only a virtual connection for the duration of the session. That means that the following things are true:

- A packet-switching network requires some additional information to get the data to its destination
- There may be a slight delay as the packets get to their destination as the network figures out where they're going and how to get them there

The "additional information" noted here is the addressing information discussed in the previous section. A circuit-switching network, because it's a straight shot from one end of the network to the other, doesn't require that information any more than you have to provide directions to someone taking a subway from one stop to the end of the line: if they get on the train, they'll get to their destination. Packet switching is more like city traffic, as the network looks at the addressing information on the packets and figures out how best to get them where they need to be.

The delay in transmission is not long by human standards as such, but it's enough of a problem that until very recently packet-switching networks did not allow for transmission of time-sensitive information such as real-time video or voice. Recently, voice over packet-switching networks has been offered, but it's such a new technology that the jury's still out on how well it works.

### Speed, Bandwidth, and Throughput

Although WANs don't necessarily have to be slower than LANs, they usually are. The difference does not have to be incapacitating by any means, but it's a fact of life that you've got to recognize. In fact, if you transmit much data across your WAN, you'll recognize this fact early and often.

A really good wide area connection has a practical speed of 1-2 Mbps (megabits per second). Although this doesn't sound like much when compared to the 10 Mbps of ordinary Ethernet or the 16 Mbps of fast token ring, it's not bad at all for the proper applications. Even slower WAN technologies, like ISDN, work fine with fairly large files so long as you've got your system configured properly. For example, keep as many applications on the LAN as possible and make sure that applications don't automatically search wide area connections first.

Speed, however, is not necessarily an accurate measure of a WAN pipeline's effectiveness. Throughput, or the measure of how much data actually gets from point A to point B in a given period, is more accurate. You can think of throughput as a function of the speed of data transmission combined with the size of the pipe--known as the bandwidth. Bandwidth describes the amount of data that can be squeezed into the physical medium of the cable at one time. For example, all other things being equal, a fiber-optic cable with two fibers has a higher bandwidth than a fiber-optic cable with only one fiber.

Before we continue, let me note that the number of channels--that is, the number of physical wires in the cable through which data travels--is related to bandwidth but is not necessarily the only thing determining it.

As you can see in figure 4.3, if you've got a skinny pipe (that is, low bandwidth), it doesn't matter how fast you shove data down it--only as much data as will fit in the pipe at a time will transmit. Likewise, if you've got a really wide pipe but low transmittal speed, the connection's throughput will be low because you're not pushing much down the pipe at one time. Speed is easier (and cheaper) to get than bandwidth, so you're more likely to run into the first scenario than the second.

The concepts shown in figure 4.3 may seem obvious, but keep it in mind as you continue through this chapter. Effective use of bandwidth to increase throughput is the key to making many WAN technologies work for you. Speed, bandwidth and throughput are not synonomous, as shown in table 4.1.

Figure 4.3
High bandwidth and low speed can contribute to the same throughput as low bandwidth and high speed.

#### Table 4.1 The Speed of Transmisssion Combined with the Available Bandwidth Determines Throughput

Factor | Explanation
Speed | Indicates how fast data travels
Bandwidth | Indicates the width of the "pipe" through which the data travels
Throughput | The amount of data transmitted during a given interval

In other words: SpeedxBandwidth=Throughput

### Error Control

If the channels through which the data travels are prone to errors (perhaps caused by interference from other electronic signals), then some sort of error control needs to take place to ensure that the data that arrives at point B is the same data that left point A. The easiest way to do error control is to send duplicates of each packet, but this generates a lot of overhead and isn't a perfect solution anyway--if one packet gets corrupted, can you be sure that the other one isn't? How do you tell which one is right?

More elaborate forms of error control involve methods collectively known as Cyclic Redundancy Checking (CDC) using exclusive-or operations. Essentially, before the sender transmits a data packet it runs a particular algorithm using the data in the packet as the variables in the algorithm. This algorithm and the expected result is included in the packet along with the addressing information and the data. If the algorithm generates an unexpected result when the receiving node performs it, then the recipient assumes that the data was corrupted in transmission and sends a message to the sender to ask it to retransmit that packet.

For example, if the data in a particular packet consisted of the numbers 6 and 2, a potential error-checking algorithm might specify that the data should be added together, with a result of 8. If the recipient adds the data and gets 9, it knows that something went wrong in the transmission and asks the sender to resend the packet. The recipient can't correct the error as it has no way of determining what the original data was--it can only tell that the data was corrupted in transit.

CRCs are highly reliable. They add a little extra overhead to data transmission, but if there's a chance of the data being corrupted in transit, the overhead cost is lower than always sending duplicates or getting scrambled information.

### Data Flow

When discussing WAN technologies, you'll encounter a couple of terms pertaining to the flow of data across the network that you may not be familiar with: half duplex and full duplex. Essentially, these terms describe the flow of packets through a connection. A half duplex connection means that data can only travel in one direction at once, while a full duplex connection means that it's possible to have data traveling in both directions at once (see fig. 4.4).

Figure 4.4
Half duplex transmissions can only send data in one direction at a time; full duplex can send in both directions simultaneously.

As you'll learn in the "Integrated Services Digital Network (ISDN)" section later in this chapter, some WAN technologies can be flexible about whether they're configured for full duplex communications or half duplex. Half duplex gives you greater throughput for one-way communications, but full duplex, if an option, means that both sides of the connection can "talk" at once, without waiting for the other side to finish.

### Access Areas and WANs

The way that the telephone system is structured in the United States drives both the way that data services are structured and how you're billed for them. The FCC mapped the United States into LATAs.

LATAs do not necessarily correspond to local calling areas versus long-distance calls--you can be in the same LATA as the target of your call, but the call may be long distance. The boundaries of the LATAs only govern who can handle the call. If it's intra-LATA (within the boundaries of one LATA), either the local telephone company or a long-distance carrier can handle the call. If it's inter-LATA, on the other hand, a long-distance carrier must handle the part of the call that extends across the border. Refer to figure 4.5 to see how this works.

Figure 4.5
How the boundaries of LATAs govern who handles the connection.

Based on population and some other factors, the FCC may change the boundaries of a LATA. Essentially, LATAs are like the logical workgroups of the large network of the United States.

Why do you care where the LATAs are? Because the boundaries affect the data services that are available to you or (more accurately) how much those services will cost. If you need the service to span LATA boundaries, you can get it--but it will cost you.

Data services are generally offered on an intra-LATA basis. (If you buy the services from a third-party vendor, this is transparent to you.) If you want to cross a LATA boundary for your data connection, you'll need to buy space on a high-speed line (such as a T1 or T3) that connects two points within the LATAs. For example, say that your organization maintains three offices, in Greensboro, Springfield, and Hilltown. You can buy a data connection from the local carrier that will connect the sites in Greensboro and Springfield, but a long-distance carrier will need to handle the connection between those sites and Hilltown because it is in a different LATA. To make the inter-LATA connection, you'll need to buy space on a high-speed line connecting a POP in each of the LATAs. From the POPs, the data connection works as it normally does in the LATA. Like a router, the POP bothers itself only with what it must transmit.

The lines that you use to connect your sites may vary considerably in speed. On the low end, you've got the DS0 lines that run at 64 Kbps (kilobits per second). One step up from there is a T1 connection (the physical cable used in a T1 connection is known as a DS1), which contains bandwidth equivalent to 28 DS0s or 1.544 Mbps. From there, you can get a T3 connection with bandwidth equivalent to 28 T1s or 45 Mbps. There are cables with even higher bandwidth than the T3, but that's the most that you'll probably have to worry about.

The price of these connections depends on the speed of the connection and how far you want it to stretch. As you'd expect, you'll pay more for a T3 line that extends across 200 miles than you will for a DS0 line that extends the same distance. Although there is an installation charge to connect a T1 (or whatever) line to your site, many vendors, such as AT&T, will waive the installation charges as part of a promotional deal.

## Types of WANs

That should be enough background to enable you to discuss WAN types and understand their characteristics. Over the next few pages, you will learn about some of the more popular WAN types.

### Integrated Services Digital Network (ISDN)

Although one of the slower wide area technologies, ISDN definitely has its uses for connecting LANs, especially LANs not too far from each other. First of all, it's relatively cheap--the slowest speed (64 Kbps or 128 Kbps depending on how you set it up) is available in most urban areas for around $40 per month plus about two cents per connected minute for each data channel. The hardware is equally reasonable because you need only two pieces of hardware on each end of the connection.

Where ISDN is available (unfortunately, it isn't everywhere) the telephone company makes a dial-up connection between two sites. Each site gets an ISDN number, which looks like a telephone number. The connection between the two sites consists of three channels. The bearer, or "B," channel carries connection information between the two sites at a rate of 16 Kbps. The data, or "D," channel transmits the actual data and runs at 64 Kbps each. Refer to figure 4.6 for an illustration of how an ISDN connection is set up.

Figure 4.6
An ISDN connection consists of two data channels and one channel for transmitting connection information.

If you need data to be able to run in both directions at once (or need to use one of the data channels for voice), you can get 64 Kbps throughput from a regular ISDN connection. If a more unidirectional approach will work for you, you can double the effective speed of the connection by logically combining the channels to make the connection 128 Kbps. Combining the channels and making the ISDN connection effectively half duplex isn't as bad an idea as it may sound. First, a half duplex connection doesn't mean that data can only travel in one direction, it means that data can travel only in one direction at a time over the connection, like a travel lane that changes directions depending on the time of day. Second, in many wide area applications the flow of data is tilted to one side more than another: I need more data from you than you need data from me. Third, 128 Kbps isn't a bad speed at all, and you may well be able to clear the connection before data needs to travel the other way (or at least before there's a discernible wait). Figure 4.7 shows how you can combine ISDN channels.

Figure 4.7
Combine ISDN channels to increase throughput.

Over time, new breeds of ISDN have evolved as everything does to become both faster and more expensive. Some areas now offer ISDN with more data channels--and thus greater throughput--that can increase the speed of the connection to 256 Kbps or even 512 Kbps. Of course, with increased speed comes more expensive hardware and more expensive connections. In addition to the installation charges, a 256 Kbps connection, where available, costs around $150 per month and the hardware runs about $1,500 per site. To have a 512 Kbps connection means a monthly charge of about $300 and hardware costs of around $5,000 per site. (Exact costs and availability for all of these will depend heavily on where you are and what's available.) If you're not sure that you'll need the 512 Kbps connection, you can get the 256 Kbps connection and upgrade the hardware later. The hardware required is a device called an IMAC, which can be either a stand-alone black box or a card that plugs into a slot on the motherboard of your NetWare or NT server. The card is easily upgradeable; modules plug into the card and then are connected to a device called an NT1 that is your site's liason to the telephone company. Each module carries 128 Kbps, so you can add more modules (up to a total of four) to get more speed.

> NOTE: IMAC, pronounced "Eye-Mack," stands for ISDN MAC-layer (bridge), meaning that it's a bridge that operates at the MAC layer of the OSI model. (You know it's a networking acronymn when it nests not one but two other acronyms.) Turn to chapters 3, "The OSI Model: Bringing Order to Chaos," for more information about the media access control layer and 14, "Repeaters and Bridges," to learn about the exact function of a bridge.

Distance. If those are the speeds available, how much does distance affect those speeds? Not at all, actually. Whether you're five blocks away or fifty miles, a 128 Kbps connection pushes data along at the same rate. This is because even fiber-optic cable can only transmit data so long without needing to bump up the signal (about three miles), so the telephone companies maintain repeaters to increase the signal volume when necessary. The signal starts afresh each time it hits a repeater, and fiber-optic signals travel so fast that the time for the signal to travel from point to point along the connection is determined by the size of the path (the bandwidth), rather than the distance that the signal has to travel.

However, distance does affect your ISDN connection in terms of cost. If you've got two ISDN sites in two different area codes, every second of connect time is billed as a long distance call. The amount of traffic sent over the line doesn't matter, any more than the cost of a half-hour long-distance telephone call depends on whether you talk a lot or sit in silence for most of the call. It's the time that the connection is maintained that determines the cost.

Connection Charges. In most cases (there are a few exceptions, but you can't count on being one of them) you'll be charged a few cents per minute for the connection. This fee is not dependent on whether you're actually sending anything during that time; if the connection is active, you'll be charged for it.

The way that ISDN connection costs are determined makes a difference in how best to set up your WAN if you're connecting two sites in the same local telephone area. If it's a flat connect fee, you can have one site call the other and never hang up. At any time, the connection between the two sites is maintained. This is much more convenient, as you don't have to redial whenever someone needs to connect to the other site.

If, however, you're charged for connect time, as most sites will be, then keeping the connection open could be very expensive. Check your tariff system before deciding whether to maintain the connection or only dial up when someone needs to transmit data.

Preparing for ISDN. So far you've read a lot about what ISDN is, how it works, and some of the options that you can set on your ISDN connection, but there's one question left unanswered: if you want an ISDN connection, how do you get it?

The local telephone company (or a local vendor working with the telephone company) offers the service. Call them and ask to talk to someone about data services--if you just tell the operator that you're interested in an ISDN connection, you may not get very far. When you call, be prepared with the telephone numbers of the sites that you want to connect.

You'll need answers to the following questions, which the vendor can help you answer:

- What's the installation fee?
- What are the flat connect charges? Are there use-based charges? What are they?
- What hardware do I need? Where do I get it, and what will it cost?
- Who's responsible for making sure that the connection is set up properly?

Using ISDN. Using ISDN isn't difficult. Your ISDN number will be programmed by the vendor) into an IMAC that connects your network to the outside world via a gateway machine. This IMAC can be either a stand-alone device or a card that plugs into a server running Netware 4.x or NT Server 3.5x or later. (The card is called a PC-IMAC, and it's available for ISA, EISA, and MCA slots.) The vendor will provide a management application to program the IMAC. Using the software on the gateway machine, you'll call the other ISDN number whenever you want to connect to another site. If you've wrangled a deal in which you don't get charged per minute of connect time, then you can call once and never hang up, leaving your WAN perpetually available. More likely, however, you'll set up the session each time you need it, perhaps every morning. The exact times that you call and hang up will of course depend on what you need from the office you connect to and whether you're connecting to more than one ISDN site.

Special Considerations about ISDN. When considering ISDN for your organization, there are a few things peculiar to ISDN that you should know about.

First, ISDN supports both voice and data. This means that, should you need more available bandwidth for your voice applications, you have a 64 Kbps channel available. You will need a special digital ISDN telephone for the connection, however, as analog telephones can't deal with the digital signals.

Second, although you can use a modem on an ISDN line, you'll need a translator to convert the digital signals to analog signals for the modem because modems can't receive digital signals. This seems like a lot of trouble and expense to go through to have a slower connection, unless you're using a special modem to get that ISDN Internet connection and download DOOM scenarios at 128 Kbps.

> NOTE: Modems aren't accustomed to receiving digital signals? If this sounds odd, remember that modems modulate digital signals into analog signals that can travel along normal (analog) telephone lines. ("Modem" stands for modulator/demodulator.) The modem at the other end demodulates the signal into the digital form that the PC can understand.

### Switched Multimegabit Data Service (SMDS)

ISDN is good for point-to-point connections, but what if your enterprise includes a number of points within a metro area that need to be connected? Technically, you could connect them all by ISDN (see fig. 4.8), but this situation is less than ideal for a few reasons:

- You have to make and break connections to talk to all sites--you can't switch dynamically
- Maintaining a large number of connections is expensive
- Slower than some other options

Figure 4.8
You can connect multiple sites with ISDN, but it's not an ideal solution.

SMDS is one solution to the problem of how to connect multiple sites in a relatively small area. Rather than being a point-to-point protocol, it connects each site to a WAN "cloud" that allows any SMDS client to connect to any other. You can see how SMDS can connect a number of sites in figure 4.9.

Figure 4.9
Individual sites connect to an SMDS cloud.

> NOTE: A WAN "cloud" is the space between the sites served by the public company, in which you don't know the exact mesh pattern. The exact contents and appearance of the cloud are usually not important to the operation of your WAN.

Although it's still a mesh configuration (in that you need one connection for each site that you're connected to), SMDS has other features that render it closer to the cloud configuration illustrated in figure 4.9 than to the ISDN spiderweb. It differs from that spiderweb in that

- It's faster--at a minimum, a 1.17 Mbps connection instead of at ISDN's fastest 512 Kbps
- You pay a flat monthly rate (around $600 for each site) for the connection, so you can dial in and not hang up, meaning that your network is always operational
- Instead of dialing a number to make the connection, you order your router to do it
- You can add more addresses to your possible connections--you just can't connect to more addresses at one time than you have connections

> Pricing SMDS
> If the $600 monthly cost of SMDS for each site connected seems expensive, consider this: to connect a four-site WAN with SMDS, you need four router WAN ports and four SMDS CSU/DSUs for a total equipment cost of around $35,000. Getting a T1 connection (which provides the same throughput) between each site requires eight router WAN ports and eight CSU/DSUs (for a total of around $40,000), plus four T1 channels and eight T1 terminations, and however many miles of DS1 cable required to connect the sites, at around $23 per mile, for a total of around $3,000 per month. The SMDS-compatible equipment is more expensive than the T1-compatible equipment, but you need less of it.

How SMDS Works. SMDS is a cell relay WAN technology, meaning that the packets in which it encloses data are the 53-byte cells discussed earlier in this chapter. Using the fixed-size cells means that the connection can be faster as it takes more overhead for a connection to cope with packets of varying size. Although the Institute of Electrical and Electronics Engineers (IEEE) specification around which it was designed describes how to handle data, voice, and video, SMDS only supports data transfer. However, if you're contemplating moving to ATM, which does support all three, SMDS could be a good idea for you. (Right now, some telephone companies are offering ATM on a beta basis to a few customers, but that's about it.) The 53-byte cells that SMDS uses are completely compatible with those used by ATM, so according to theory, the upgrade will be pretty easy.

At each point on an SMDS network, the site contains a piece of hardware called an SMDSU (a CSU/DSU configured for SMDS) and a router that's been configured for SMDS. These units are connected to a high-speed line that plugs the site into the SMDS cloud illustrated in the previous figure. In other words, to connect your LAN to a SMDS network, you'll need the following:

- A router that supports SMDS, running SMDS software
- A CSU/DSU that supports SMDS
- A service agreement with the local telephone company or other provider

> NOTE: CSU/DSU stands for Channel Service Unit/Data Service Unit. Each of these devices functions as a digital "modem" getting data from the gateway PC to the WAN. Not all devices with this name perform exactly the same operations, but the device's job can include such tasks as line conditioning, framing the data (getting the data into the appropriate packets for the network type), and performing error-checking.

The router and CSU/DSU work together to get the data from the LAN to the WAN. First, the router encapsulates the LAN frame into an SMDS frame (called a L3PDU, for level 3 protocol data unit). Then the router encapsulates the L3PDU into a high-level data-link control (HDLC) frame that the CSU/DSU can receive. The CSU/DSU then removes the HDLC envelope and converts the L3PDU to the 53-byte cells transmitted across the network. Thus, the equipment on your site, in combination with the telephone company's hardware, links your site to the SMDS cloud and to other linked sites with addresses listed in your router (see fig. 4.10)

Figure 4.10
An equipment chain links your LAN to the SMDS cloud.

You can either ask the SMDS vendor to get the equipment for you or purchase your own from another source. If you purchase your own equipment, make sure that it corresponds to any hardware compatibility lists that the vendor has issued.

> TIP: Interoperability can be a bit of a problem when it comes to getting routers and CSU/DSU to work together. You will probably have to purchase both devices from the same vendor--another reason to let the SMDS vendor help you find equipment.

Like most other WAN technologies, SMDS is available in a variety of speeds. The baseline version connects your sites at a little more than 1 Mbps (1.17 to be exact). You can also purchase faster connections, which can bump the connection's throughput up to 34 Mbps--more than three times an LAN Ethernet connection. For most purposes, the 1 Mbps connection is adequate.

Security: Creating Virtual Private Networks. If your SMDS connection plugs you into the main SMDS network in the area, how do you keep outsiders from calling into your system? The answer is an address-screening system. Although an SMDS network is in some ways similar to a peer-to-peer network (in that it connects several sites on an equal basis), it differs from a peer-to-peer network in that no browsing is allowed. You can only connect to those addresses listed in your router.

This sounds complicated, but it's pretty straightforward. Imagine that the four of your company's sites have just joined the network, called A, B, C, and D. However, another company's sites, E and F, are already plugged into the network. They can't see you, however. Your router only accepts calls from A-D (and, for that matter, E and F wouldn't have any idea how to find you). Part of the setup of your SMDS installation is programming the routers with the addresses of any of the sites that you'll ever need to connect to. Add a site, add an address. Think of it as telling the receptionist at your company, "I'll take any calls from Joe, Susan, or Betty, but if anyone else calls I'm not here." You don't have to deliberately exclude anyone, but if you don't include a site in your "accept calls" list, they won't be able to talk to you.

SMDS sites can have more than one address per access line (up to 16), so you can even direct connections within the site. Thus, another SMDS site could call not just a physical site, but subsets within that site. If your site A should only be connecting to a subset of site B, you can set up more than one address at site B and only permit site A to transmit data to a particular address.

SMDS Considerations. Before subscribing to SMDS, the following are a few items to keep in mind:

- The number of sites that you'll need to connect to at one time
- The kinds of networks running at each site
- The speed of connection that you need

Number of Sites. When subscribing, you'll need to buy as many connections as you intend to be connected to at one time. For example, if your company has four sites, but you know that you'll never connect to more than two of the others at a time, you can get away with two connections. Be conservative and assume that you'll need full connectibility when you're figuring what you can afford. In addition, make sure that you've got a couple of extra WAN ports on your router so that you can add more connections if you have to.

To connect to more sites, you don't necessarily need more connections. It's the number of concurrent connections that you need to plan for.

Kind of LAN at Each Site. The LANs connected via SMDS can be a little different, but you need the same logical topology on both ends (and, obviously, a mutually compatible file format) to make the connection work. You can't connect an Ethernet network to a token-ring network and expect the thing to work without the extra bells and whistles that you'd expect to connect an Ethernet and token-ring network locally. The cabling that you use matters less, however, as the two networks never touch except via the router and the WAN.

> TIP: A logical topology describes the form in which data is packaged and passed around a network. An Ethernet network uses a different logical topology than a token-ring network (the frames and method of data transmission are different) even if the Ethernet and token-ring networks are physically arranged in the same way.

Speed Required. You can get an SMDS connection up to 34 Mbps quite easily, but you need to consider the ramifications of the speeds. First and foremost, higher-speed connections cost more. Second, the hardware may not be upgradeable, so if you know that you'll need the faster connection next year and plan to get it, look for a router that can make the connection.

The Future of SMDS. Although SMDS is an intra-LATA data service because of those FCC regulations discussed earlier in this chapter, you can buy a T1 connection to connect the POPs in the LATAs that you want to connect, thereby extending your WAN across the country. The price of these connections isn't dropping as fast as other computing hardware (in fact, the cost of a DS0 connection just went up in 1995), but it's possible to maintain the connection at local speeds. Presumably, as bandwidth technology progresses, the cost of the inter-LATA connections will drop and connecting distant sites will become more cost-effective.

In addition to widening its scope, SMDS will become faster. Already, it's available at speeds up to 34 Mbps with a high-speed line (although quite expensive). Its use of cell relay technology, with consistently-sized packets, means that it should be upgradeable to ATM, so long as you're using a line that can handle the high speeds that ATM technology requires. For now, however, high-speed WANs may take a different form, using fiber distributed data interface.

### Using Fiber Distributed Data Interface (FDDI) across a WAN

The best trick in the book is a WAN that's as fast as your LAN. Sound impossible? Not any more. In some locations (not many right now, but it should be more soon) you can get native speed from your WAN by connecting to a fiber-optic ring that's using FDDI. This is called the FDDI Network Services (FNS).

What Is FNS? FNS is a public network that uses a 100 Mbps FDDI backbone to provide a connection for LANs within its geographical reach. The telephone company runs two concentric fiber rings (two so that the redundant ring can take over if the first breaks or fails) that subscribers can tap into throughout the service area. The entire setup looks like figure 4.11.

Although this technology was first described to me as a wide area Ethernet (Ethernet being the LAN type), that's not really accurate. FNS could just as easily be described as a wide area token-ring network. Because it follows both the IEEE 802.3 standards, which describe Ethernet communications, and the 802.5, which describe how token-ring networks transmit data, the fiber backbone rings can work with either. When subscribing, you tell the telephone company what kind of network you've got and they'll provide you with the proper interface.

Figure 4.11
FNS can connect sites in a metropolitan area so that the WAN connection is as fast as the LAN speeds.

Of course, the LANs at the sites that you're connecting must be of the same type or else they won't recognize each other any more than an Ethernet LAN recognizes a PC bearing only a token-ring network interface card (NIC), assuming you rigged some way to connect the token-ring NIC to the rest of the LAN.

> NOTE: Recall the discussion earlier in this chapter of packet switching versus circuit switching. Because it's using FDDI, FNS is an example of a WAN technology that isn't really either one. The ring connects the taps, and the packets on the ring get routed to the appropriate tap depending on the address in the packet header--just like those on a WAN. There are no alternate routes to switch.

Applications. The high speeds of the fiber backbone make it possible for you to do almost anything over your WAN that you can do locally.

- Share drive space
- Share peripheral devices, such as CD-ROM drives
- Back up networked drives
- Send e-mail that will arrive as fast as e-mail sent intra-office and without requiring an online service

With native LAN speeds between local sites, the only restriction that you're likely to run into is one of convenience. For example, printing to a printer three blocks away is inconvenient, at best. Even if the output is for the people in the office where the printer is located, you'd need someone to play printer administrator to make sure that the printer has paper and toner and isn't jammed. (Admittedly, some printers and operating systems provide error messages to the machine where the print job originated if something goes wrong, but most printer error messages reduce problems to the printer being out of paper, even if it isn't.)

Printing may not be a good wide area application, but backups certainly could be. If you've got one backup administrator in the main office, they can be responsible for backing up the servers at the branch offices as well--the 10 Mbps of an Ethernet connection is certainly fast enough to back up a drive. Having a centralized backup system makes it easier to collect and keep all the backup archives off-site. (See chapter 17, "Backup Technology: Programs and Data," for more about backup strategies.)

Another application in which FNS can really shine is client/server software, such as databases. One of the biggest concerns of running any kind of software over a network is response time. The longer you have to wait to make the application work, the less useful it is, and the less likely that it will get used. Even client/server software, which should be optimized so that only the processing best done at the server end is done there and the rest is done by the client machine, is vulnerable to slow connections (although less so than older applications that put all the processing at one end of the connection). So client/server applications will benefit from the higher WAN speeds available with FNS.

The usefulness of FNS to client/server goes even farther, however. One of the emerging trends in client/server processing is peer-to-peer information accessing. Rather than having a central repository of data at the server, the database is distributed among the clients. If one client updates the information in its database (perhaps a stock inventory) then all the other clients need to know about this change immediately so that their records are accurate. So long as the updates are handled well (that is, if the database writers don't try to replicate the entire database to the other clients when one entry changes), this doesn't present too much of a traffic problem for a high-speed LAN. Over a slower WAN, however, the updates take more time, especially if other traffic needs the bandwidth as well. If the clients using and updating a peer-to-peer database were connected by a WAN technology as fast as a LAN, then peer-to-peer databases over a WAN become much more possible.

In any case, if you sign your offices up for this service, think about what you'll be using it for and make sure to use the high-speed WAN for the things it's best at. If you want to use the WAN connection for something, make sure that it's something that no one needs to be on the spot for.

Hardware Requirements. One of the best things about making the fiber ring the backbone of your WAN is that the hardware requirements are almost nil. To connect a token-ring network to the ring, you need no additional hardware--the telephone company provides a multistation access unit (MAU, a term already familiar to token-ring users) and a repeater to boost the signal as required. An Ethernet network requires only a transceiver. You literally plug the network in as though you were connecting two segments of your network. In a sense, you are.

You can see how you'd connect your Ethernet or token-ring network to the fiber line in figures 4.12 and 4.13:

Figure 4.12
Connecting an Ethernet network to the fiber ring.

Figure 4.13
Connecting a token-ring network to the fiber ring.

Security. If anyone in a metro area with an Ethernet or token-ring network can tap into FNS, how do you keep other FNS subscribers from accessing your network? Actually, the security built into FNS is much like that built into SMDS. In each case, the routers maintain a list of the valid addresses that may connect to a given site. The only difference is who does the maintaining: if it's SMDS, you (the customer) updates the router; if it's FNS, the vendor does it. But the bottom line is that other FNS subscribers can't see into your network. So far as each subscriber's concerned, they're the only ones on the fiber ring.

Price and Availability. If FNS is so wonderful, why isn't everyone using it already? Two reasons. First, it's not available everywhere. Installing a fiber backbone like the one illustrated at the beginning of this section is an expensive enterprise, and locations without a large number of potential subscribers are not likely candidates for fiber WAN backbones.

Second, where it is available there is sometimes surprisingly little information about it. Your best bet for getting information specific to your area is probably the marketing manager for data services at your local telephone company. Outside vendors, even if they contract with the telephone company, may not know much about it (as I discovered when shopping for WAN technologies at one point).

Third, and this is really the big one keeping people from lining up in droves to sign up, a fiber connection is expensive. Even without any hardware at your site, the installation costs run about $1,300 per site, and then you've got monthly charges ranging from around $850-$1,200 per month, depending on whether you're connecting 4 Mbps token ring, 10 Mbps Ethernet, or 16 Mbps token ring. That's a lot of money to spend on networking, even if your additional hardware costs are low or nonexistent. Before purchasing a WAN that is this expensive, some serious cost-accounting is in order.

> NOTE: To learn more about the mechanics of how the fiber ring transmits data, turn to chapter 7, "Major Network Types," to learn more about the FDDI logical topology.

The Future of FNS. FNS is a relatively new technology, only offered since the early to mid nineties. What's going to happen to it over the next few years?

Replacing Dark Fiber. Dark fiber, as you may know, used to be the private answer to FNS. Dark fiber is a point-to-point fiber line that the telephone company runs for you (only those with right-of-way can run cable, such as the telephone company or the television cable providers) that you maintain. With a router on each end to connect the fiber to the LAN, you could have a privately maintained, high-speed WAN, like the FNS described over the past few pages but for the fault-tolerance provided by the second ring.

Note the use of past tense here. Most telephone companies won't be offering dark fiber by the time you read this. As one telephone data services representative explained it, it's not cost-effective for them to run the fiber and have the customer maintain it. Under previous legislation, the FCC made the telephone companies offer the service, but the new rules mean that they don't have to offer it, so they don't. The bottom line is that, if you want a new fiber backbone for your WAN, you'll have to get FNS unless you own the land under which you propose to run the fiber.

More Rings. If FNS spreads across the country, it's going to do it by means of interconnected rings following population growth. Currently, four rings are deployed in the Washington, DC metro area, meaning that intra-LATA areas in Virginia, DC, and Maryland can be connected without having to have one huge fiber ring. Given that even fiber has its distance limits (about three miles before the signal needs boosting with a repeater), this means that FNS can extend farther with less hardware involved. Costs for everything in the computing industry fall eventually--look at how the price of a hard disk has fallen over just the past five years. Barring legislation that makes it more expensive for the telephone companies to run the fiber, expect the service to spread and costs to drop. Who knows? Individual taps may become reasonably priced. The path to the full-blown information highway may yet be via your computer, rather than your television.

Wide Area ATM? ATM is one of the great buzzwords of the age, but at this point not much more than that due to its extremely high costs and limited availability. ATM is a networking technology that can transmit data, real-time video, and voice. Its extremely high speeds avoid the lag time that kills voice and video (if you remember calling long distance when delay was a fact of life, you know how frustrating that can be), and its use of cell relay technology, like SMDS, means that it can split various kinds of data into a steady stream of 53-byte cells and route them smoothly to their destinations.

If FNS becomes more affordable and widespread, it's possible that it could be the physical medium that gets ATM to the desktop, not just in LANs but across the country. Although the hardware costs would still have to come down (the equipment that reverts the 53-byte cells to their original data, voice, or video form costs a lot), FNS could at least get the data to its destination. The only catch is that for inter-LATA communications, the data has to travel across a T line supplied by a long distance company. That's a lot of bandwidth to maintain the high speeds: seven T1 lines to maintain a 10 Mbps connection across a LATA.

### Frame Relay

Thus far, we've talked about ISDN, a relatively cheap way of extending your LAN (apart from using modems, anyway), SMDS, a flexible way, and FNS, a super-fast way. Frame relay fills a different role for WANs, that of the efficient way. Operating on the principle that not every site with access to bandwidth will need all of that bandwidth at once, it interleaves data from a number of different sources, squeezing more use out of the bandwidth than it's technically capable of. Essentially, frame relay is a way of paying for less bandwidth and getting more, with one catch: sometimes you may not get anything at all.

What is frame relay? It's a wide area connection protocol (there is no such thing as a frame relay network, as such--it's only a way of accessing a network) that transmits variably sized packets called frames. The real trick to a frame relay connection is that it's designed to transmit more data than the bandwidth of the connection can actually accommodate. You can see a frame relay network in figure 4.14.

It does this by making use of a basic fact of networking: most of the time, if you're on a network, you're not transmitting data. You open files, you send e-mail, you access databases, but you don't do any of these things constantly. Now, if you're the only one accessing the network this doesn't matter. As this isn't the case, that means that while you're not transmitting data, your neighbors can. As you remember from earlier in this chapter, WANs divide bandwidth into channels, and in older technologies, each sender got one channel all the time, whether they were transmitting data or not. Thus, most of the time, the allocated bandwidth goes to waste. Given the high cost of WAN channels, this gets either very expensive or very slow. Frame relay, in contrast, gives the sender all the channels for the space of the transmission. Conceptually, the difference in transmission looks like figure 4.15.

Figure 4.14
A frame relay network lets the subscribers in the area share bandwidth so that all of them get more throughput from the bandwidth than it could accommodate if each subscriber had a dedicated channel for their exclusive use.

Figure 4.15
You can allocate channels either by time or by need.

The allocation method frame relay uses is called statistical multiplexing (often just stat muxing). Stat muxing sounds obscure, but it's only allocating bandwidth as needed, on a packet-by-packet basis. Using it, frame relay networks normally give you WAN speeds of about 2 Mbps; the exact speed depends on the vendor and the speed you buy. Technically, frame relay can achieve speeds of up to 50 Mbps, but as of mid-1995, I've never heard of this speed being offered outside the lab.

Frame relay is designed to be a fast and inexpensive method of accessing a WAN. To that end, it's got the following characteristics:

- One physical link can provide access to many locations
- No error-correcting checksums (unnecessary on reliable fiber lines) mean less overhead and a faster connection
- Optionally, has flow control or error checking at end units to increase reliability on more crowded connections

All of these characteristics mean that frame relay is good for applications that sporadically transmit smallish chunks of data and have access to reliable physical connections that don't need error-correcting capabilities like those of X.25 (described later in this chapter).

How Frame Relay Works. Highway traffic provides a useful analogy for describing the elements of frame relay:

- No dedicated channels
- A guaranteed rate of throughput
- Error-managing

Let's look at each of these elements in turn, using a highway analogy in which the available bandwidth is the highway, channels are lanes, and packets are cars.

Shared Bandwidth. First, there's the matter of lanes. Older WAN technologies divided the highway into static "lanes" (the channels) that belonged to a particular sender whether that sender was using them or not. This would be like saying that, in a highway that provides access from Springfield to Richmond, Fredericksburg, and Norfolk that traffic to each of those cities was restricted to its own lane--even if no one's going to Fredericksburg or Norfolk on a given morning, and the lane for Richmond is jammed, the Richmond traffic can't use the other lanes.

Clearly, this method of managing a highway doesn't get best use out of the available highway space. To enable more traffic to get to Richmond on Monday mornings, you'd have to build another road or widen the lane, either of which would be an expensive proposition. If few people travel to Fredericksburg or Norfolk, why not remove the barriers between the lanes and let all traffic, no matter what its destination, use the same lanes? This might not remove traffic problems, but it should alleviate them.

If the frames going to their various destinations are all jumbled up during transmission, how do they get sorted out for delivery? Each frame is identified by a part called the data link connection identifier (DLCI). These DLCIs work like unloading areas--a frame is sent to a location identified in the DLCI rather than to an address. When the loading area at the network node receives the frame, it looks at the DLCI and sees if it corresponds to an address accessible from that location. If so, the data gets routed to its final destination. If the frame was routed to that location in error because a bit got scrambled on the way, the frame is dropped and the recipient (not the frame relay access) must tell the sender to resend the data.

Guaranteed Throughput. Because frame relay thus utilizes all available space on the bandwidth, getting more throughput that you'd get from dividing the channels, some mechanism for making sure that at least some of the traffic gets to its destination is in order. For example, the highway department might say that cars going to Richmond are guaranteed to travel 60 miles in an hour. This guarantee, the committed information rate (CIR), doesn't mean that the cars will travel at 60 Mph--the CIR guarantees a distance to travel in a certain period, not a speed. Thus, the traffic might go 0 Mph at one time and 100 Mph at other times, but the highway department guarantees that it will travel 60 miles in one hour, even if that means forcing other cars off the road.

Should a car exceed 60 Mph, the highway department tickets it. If traffic gets too heavy, ticketed cars are the first ones forced off the road into the ditch. If traffic remains manageable, however, the ticketed cars reach their destination with no penalty. The tickets are only a way of marking who's expendable. It is the same with frames. If they exceed their CIR, they can be dropped if traffic gets too heavy. If there's enough bandwidth for them, they get through. (In addition, the network can optionally ticket lower-priority frames ahead of time so that if traffic's too heavy those frames will be dropped first.)

When you buy frame relay services, the CIR you get depends on what you pay for and what the vendor offers. The minimum CIR that you need is still a matter of debate. The cheapest CIR is 0, meaning that the vendor doesn't guarantee that any of your data will reach its destination. Not all vendors will sell you a CIR of 0, and you'll have to decide what your lowest acceptable rate is. It's not a hard-and-fast answer, as some people find that a low CIR gets them the throughput they need at a lower cost, while others demand more ensured reliability.

> NOTE: So long as usage of frame relay remains relatively low, a CIR of 0 may be acceptable because there's less competition for bandwidth among customers. As more subscribers begin jostling for space, however, you may want to increase your CIR to make sure that your data gets through.

Congestion Handling. What about those cars getting forced off the road? What happens to them? In frame relay, there's a couple of different ways of handling packets that are lost due to heavy traffic (forced off the road). These methods are not part of frame relay as such but are part of the end-user equipment that sends and receives the frames and the protocols on the connected LANs.

One type of congestion handling lets the destination handle traffic control. Part of a frame relay frame is a congestion information field. The sender can flip a bit (called the forward explicit congestion bit (FECN), if you're interested) in this field, and the recipient will monitor the number of bits it sees. If the number exceeds a certain density, the recipient will refuse to accept more frames until it has caught up. You can see how this works in figure 4.16.

Figure 4.16
How FECN congestion handling works.

Another method works in a similar manner, except that the bit to be flipped is called the backward explicit congestion bit (BECN). If the number of BECN bits exceeds a certain threshold, the recipient tells the sender to stop sending frames so quickly. Once the recipient has caught up, it notifies the sender that it can begin sending again (see fig. 4.17).

Both of these methods are called explicit, meaning that they take proactive measures to ensure that traffic never gets too bad. These methods, once again, are not part of frame relay--they're part of the protocols on either end of the connection, and the one used depends on the protocols you run, and not all protocols provide for either one.

There's one method of congestion handling that any frame relay connection can provide, however. If the user equipment is capable of measuring the number of dropped frames, it can determine when that number has exceeded a certain threshold and then tell the sender to slow down transmittal. This method isn't as good at congestion handling as the other two, as it only alleviates traffic problems after they've become big problems, but sometimes it's your only option. TCP/IP, for example, can only work with implicit congestion handling. Figure 4.18 shows how implicit congestion handling works.

Figure 4.17
How BECN congestion handling works.

If frames are dropped, it's the job of the end protocols to notice and request that they be resent. If you find that you're having to do a lot of congestion handling or are losing a lot of frames, it might be time to consider purchasing a higher CIR.

### X.25

Frame relay can do a wonderful job of connecting sites within the United States, where lines are essentially error-free. What about connecting sites in places with less reliable wide area connections? If you want to connect sites in areas where copper lines are still used, you'll need some extra protection to make sure that the data gets to its destination in one piece. That protection could come in the form of X.25.

Who's Using X.25? X.25 is not as popular in the United States as frame relay because it's not as fast (normally limited to a 64-256 Kbps connection, although some X.25 services can use T1 lines), but outside of the United States (including Europe), it's a very popular WAN type. It's available almost anywhere and its error-correcting capabilities make it very reliable.

Like frame relay, X.25 is good for applications that send a little bit of data in short bursts--what's known as "bursty" transmissions. Database entries, e-mail, and inventory systems are all good examples of this kind of transaction. X.25 is not suitable for long, continuous streams of data, like those used by video--its speed is too slow, so it's apt to make real-time data jerky.

Figure 4.18
How implicit congestion handling works.

What Is X.25? X.25 is not terribly complex. Like frame relay, X.25 is not a networking protocol per se; it's an access protocol, like an on-ramp that defines how data gets onto a packet-switched network and what information needs to accompany that data. It functions on three levels:

- The physical layer specifies the physical characteristics of the on-ramp
- The link layer packages the user data into the appropriate kind of frame and supervises the connection
- The network layer handles the task of transmitting the data and making sure that it reaches its destination

This sounds a little complex, but it's important for understanding how X.25 works and thus what you need to make it work.

The Physical Layer. To get the bits and bytes being transmitted on their way, X.25 uses an RS-232 serial connection, the same physical specifications that your modem uses. You don't have to worry about the specifics of RS-232 except that if you buy a router with the intention of plugging an X.25 connection into it, the router needs to have an RS-232 port.

This layer is responsible for making the sender and recipient able to talk to each other.

The Link Layer. The link layer's job is more complex than that of the physical layer. First, it defines how the sender's data gets put into a particular a frame to be sent on its way. Not all frames are alike because the requirements for user data and management data vary, but the basic elements are shown in figure 4.19.

Figure 4.19
An X.25 data frame contains addressing information and error-checking, in addition to the data itself.

Each part of the frame (apart from the data) has a role to play. The flags mark the beginning and end of the frame. The addressing information provides the destination of the frame. Error-control information is stored in two places in the frame: one field contains a function for the recipient to perform and the other the solution to the function.

The error control inherent in X.25 depends on those two fields. If the recipient gets an answer to match the one in the error-control field, then it sends a message (called an ACK, for acknowledge) to the sender confirming that the data got there in one piece. If, however, the function doesn't come out right, it's assumed that the data didn't either, and the recipient asks the sender to send the data again with another message, called a NAK. The sender doesn't dispose of its data until it received an ACK from the recipient, so if it gets a NAK back, the sender just resends the data.

The link layer is also responsible for making sure that the recipient never gets more data that it can handle at any given time, using a technique known as flow control. An ACK signals to the sender that the data arrived in one piece and that the recipient is ready for more, so if the recipient doesn't send back an ACK the sender holds off until it receives the okay message. In some systems, the recipient can actually automatically send the sender a message telling it to stop transmitting until the recipient clears its buffers.

Finally, the link layer is responsible for keeping track of the connection. If something should sever the connection at the physical layer, the link layer is responsible for remembering the status of the connection and sending the remainder of the data when the connection is restored. Remember, not all the data in any network transmission works in one chunk, so if the transmission gets interrupted it's important for it to be able to restore where it left off.

Overall, this layer is responsible for the link between the sender and the recipient.

The Network Layer. This level of X.25 is responsible for the fine details of how the data gets from its source to its destination. To this end, it must perform the following tasks:

- Establishes a connection between the sender and recipient
- Addresses and routes the packets
- Controls flow so that no data gets lost
- Recovers from any failure of the link layer
- Provides diagnostic information about the connection's status

Once the connection's up and running and the sender and recipient are linked, this layer gets to perform the task of getting the data to its destination. It establishes the virtual connection between the two points and lists the addresses of the sending and receiving nodes. From there, it can choose the best route for the data to travel, and instead of sending the address information, it includes a sort of "map" with the data, so as to reduce data overhead. During the flow of data, this layer makes sure that the recipient never gets more data than it can handle at once. When the transmission is complete, it sends an all-done message to the sender and closes the connection.

That's the normal procedure. Should something happen to the link before the recipient gets the all-done message, this layer is responsible for remembering the status of the transmission and continuing where it left off.

Using X.25 with Frame Relay. X.25 is essentially frame relay with error-correcting ability. It's possible, if you've got sites in Europe and sites in the United States, that you might want to use the best technology for each location and somehow blend X.25 and frame relay. Well, you can. The same body that defined how X.25 and frame relay work also defined a method to hook them together. At a very simple level, it works like this: An internetworking function (IWF) is positioned at the junction of the two networks. Frame relay and X.25 use slightly different forms of addressing information and overhead, so when either kind of packet comes to this junction, the IWF takes the packet, removes the extraneous information apart from the data, and then adds the information needed to transmit the data onto its new network. The IWF can connect to more than one virtual connection on each side, so you can have multiple X.25 connections and multiple frame relay connections. You can see how this works in figure 4.20.

Figure 4.20
Connecting frame relay and X.25.

## Summary: Choosing a WAN Type

In this chapter, you learned about what a WAN is, reviewed some concepts intrinsic to wide area technologies, and read about some of the WAN technologies that you're likely to consider. At this point, you don't know everything (entire books have been written about all of the WAN technologies discussed here), but you know enough to make a beginning. Just to refresh your memory, the data in this chapter is summarized in the following lists:

ISDN

- Provides a reliable low-speed (64-512 Kbps) connection most suited to LANs in close proximity to each other
- Is not available universally--even in all regions of the United States
- Is connection-oriented, meaning that a connection must be made before data can be transmitted
- Requires an IMAC, NT1, and a gateway machine

SMDS

- Provides a medium-to-high-speed (1.17-45 Mbps) connection between LANs in a LATA
- Is available, in 1996, in most major metropolitan areas of the United States
- Is not connection-oriented--that is, no connection between sites must be established before transmittal begins
- Requires a CSU/DSU and a SMDS-compatible router with one port for each connected site

FNS

- Provides a link between sites that is as fast as the LANs that you're connecting
- Is not currently widely available, even in the United States
- Requires almost no additional equipment--the connection looks like connecting one more node to your LAN
- Transmits LAN packets

Frame Relay

- Uses statistical multiplexing to allocate bandwidth to sites based on traffic; therefore, it is able to use bandwidth very efficiently (most commonly transmits around 2 Mbps)
- Transmits frames of varying sizes
- Most suitable for "bursty" traffic that is not time-sensitive
- Designed for reliable cabling, so it includes no error-checking information
- Widely available in the United States

X.25

- Uses statistical multiplexing to allocate bandwidth to sites based on traffic; therefore, it is able to use bandwidth very efficiently, although its additional overhead makes it slower than frame relay (64-256 Kbps)
- Incorporates error-control information into its frames so that it can transmit successfully over less-reliable cabling
- Most suitable for "bursty" traffic that is not time-sensitive
- Widely available globally (if there's any cabling in place at all)

After reading this chapter, you may have an idea of what WAN technology would suit the needs of your company best. Just to review, however, you need to consider the following questions when choosing a WAN type and vendor:

- The area that the WAN needs to cover
- The amount of data that will be transmitted at one time
- The type of data that the WAN will carry
- The lowest acceptable transmittal rate
- How much money is available for the project

### Area To Be Covered

WAN technologies are offered on an intra-LATA basis in the United States. If you plan to extend the WAN beyond the borders of the LATA, you'll have to purchase (or your vendor will) at least part of the service from one of the long-distance companies.

For some technologies, the smaller an area, the cheaper high speeds will be. For example, if you want the native LAN speeds of FNS, you'll have to lease multiple T1 circuits to maintain the high-speed connection over the border of a LATA (about seven T1s to keep up with 10 Mbps Ethernet). FNS within a LATA isn't cheap, but it's less expensive if you only need it locally.

And, once again, if your WAN will extend outside the United States you'll probably want to use X.25 for at least part of it. Outside the United States, many of these technologies aren't even offered, and when they are, they're not always reliable.

### Amount of Data

The more data to be transmitted at one time, the more bandwidth you'll need. Frame relay, as we've discussed, is designed to get more out of existing bandwidth than older technologies can, but this has its limitations. Keep in mind that people using networks aren't using the network part most of the time--they're working with data locally. Thus, you can get away with less bandwidth than you might think based on the speeds of your LAN.

### Type of Data

The technologies described in this chapter are, at this point, pretty much data-specific, although SMDS is technically capable of transmitting voice and data and frame relay product and service vendors are beginning to offer support for time-sensitive data. Even for static data, however, the type of data will affect the throughput you'll need. Complex graphics require more bandwidth than e-mail messages, for example.

If at all possible, don't run applications across a WAN (or use true client/server applications that make use of distributed processing). Use the WAN to access data, not the functionality of your software. Faster WANs have fewer problems in this regard, but keeping applications locally where feasible will make them easier to administer (and keep your users from screaming in frustration at their slow applications).

### How Much Money Is Available?

To a large extent, the more money you spend on networking, the better product you have. Bandwidth is expensive and so are some of the additional services you can buy from your vendor to help you manage your WAN. Before talking your boss into a blank check, however, think about what you're going to be doing with the WAN. More features or higher speed don't always translate into a better product, if it's more than you need right now. Just make sure that you buy a product that you can upgrade, if necessary.

Before choosing a WAN technology, draw up a list of what you need from the WAN (speed, error recovery, cost, and so forth) and keep it on hand when talking to vendors. Ask lots of questions, and don't be afraid to ask the vendors to clarify something if you don't understand. You might use a form like the one in figure 4.21 to help you prepare your questions before you call.

This checklist may not cover all the eventualities that apply to your particular situation, but it's a good start.

Never forget that you're the one buying the service and keeping them in business, so there's no such thing as a stupid question.

Figure 4.21
A WAN checklist like this one can help you organize your thinking and get the WAN type that best suits your company.

© Copyright, Macmillan Computer Publishing. All rights reserved.