Earlier in this book, we discussed how a star topology can make cabling and maintaining your network easier. Rather than snaking a cable through the office and connecting everyone in a long row, you can run lines from a central location to each workstation--easier to cable, and easier to isolate and fix cable problems. To work, a star topology requires an extra piece of hardware that bus networks don't. The extra piece, which connects all the members of the network, is generically known as a hub.
"Hub" is sort of a catch-all phrase for a device that connects other networked devices to each other. Therefore, hubs can range in complexity from unpowered patch panels to complicated devices that can connect several kinds of local area networks and even connect them to wide-area networks. Clearly, you won't use the same device to connect a small LAN as you would to connect your site network to the network in the building next door. Therefore, in this chapter, we'll talk about the wide range of smartness and flexibility that the various kinds of hubs can represent.
Because prices and capabilities change, making specific recommendations is difficult, but this chapter will alert you to some of your options and help you figure out which are best for your particular situation.
NOTE: Although not all hubs are created equal, ranging from simple punchdown blocks to complex network administration tools, their basic purpose is the same: to act as a distribution point for the network. The logical topology of the network and the cable that it's strung with are irrelevant to this definition.
The essentials of a hub are the ports that network nodes can plug into to connect with each other. Beyond that, you can add management module ports that allow you to connect the hub to other hubs or connection devices, and so forth, but the essential component of a hub is its connecting function. Even a separate chassis is not essential; as we'll discuss, you can buy hub cards that allow you to turn your server into a hub.
Most often, however, a hub looks like a box with ports for LAN nodes to plug into. The type of connector will depend on the network type and cabling used, but the essentials look something like the example shown in figure 13.1.
Figure 13.1
Most 10BaseT network hubs share basic features.
The basics of the chassis are the same; it's the specifics that vary. For example, powered hubs have status lights. What those status lights mean and can tell you depends on how much network management the hub is capable of.
A hub port will only accommodate a particular kind of cable jack; RG-58 coaxial has different connections than RJ-45 UTP, and UTP uses connections different from the DB-9 connector used in token-ring networks. As with other network devices, you can't plug physical devices into ports with which they're incompatible. However, hubs are also like other network devices in that their ports are physically compatible with other like ports. In other words, if you have a 10BaseT network to hook up, it shouldn't matter whether you buy your hub from 3Com or Akbar and Jeff's House of Hubs; the physical interface is the same.
CAUTION: One caution on this point: token-ring hubs take a DB-9 connector, just like a video connector. Just as you shouldn't plug your token-ring cable into your monitor--it will at least turn your screen purple and at most smoke your monitor--be careful about what DB-9 connector you plug into a physically compatible connection on a hub. Although you may not smoke anything, you'll confuse a passive MAU because the device plugged into the port will feel like a token-ring connection, although it's not. It won't be able to remove the alien connection from the ring or ignore it, so the network won't work.
It's probably pretty easy to see why this kind of physical compatibility among cable types is important; if not, consider what it would be like having to buy all your cable and all your network cards and all your hubs from the same vendor. If hubs used proprietary cable interfaces, then you'd have to.
Hubs that can connect more than one kind of physical network will have a variety of port types to accommodate the various kinds of cables. AS/400 connections, for example, are available but relatively rare. ARCnet hubs, on the other hand, are quite easy to find even though few new networks use ARCnet.
Ports in a hub won't do you any good unless they're connected in some way. Otherwise, the hub would work like a Roach Motel: data goes in, but it doesn't go out.
To let ports (and therefore, the nodes plugged into those ports) communicate with each other, you need some kind of bus system to transport the data between ports. One way for this to work is to build each port with a receiving connection and a sending connection. The receivers all connect to all the senders, so that the nodes can talk to each other.
The bus used will be the same speed as the network--if it's a fast token-ring hub, the bus will keep up with 16 Mbps; if Ethernet, 10 Mbps; and so forth.
Not all of the ports on a hub are for local network connections. Some models have an additional port, called the attachment unit interface (AUI), for connecting to other hubs or other connection devices like bridges or routers. (Models with an AUI port usually list the total number of ports something like this: 12+1. This port number indicates that there are 12 network ports and one AUI port.) The cable connection between networking devices is called the backbone. Depending on the kind of hub, the backbone can be thin Ethernet (10Base2), thick Ethernet (10Base5), or fiber. Higher-end hubs generally have the fiber connections, and the top models will have an AUI port that you can double-cable for fault tolerance. If one cable breaks, then the other can take up the slack until you replace the broken one.
Some hubs will also have an RS-232 serial port to connect to a PC or modem for remote management capability that isn't affected by network crashes. Management that takes place via the serial connection is called "out of band," as it's independent of the network transmissions. We'll talk more about "out of band" management later in this chapter.
If you want to be able to manage your hub, you've got two choices: buy an upgradeable hub or buy one with the management module already in place.
A hub's management capabilities are tied up in a piece of smart hardware. (With on-board upgradeable ROMs, the line between hardware and software gets more and more squishy.) In most models, the hardware is another module like the ones used for the ports. Therefore, if you want a managed hub, you can fill the slot with a management module; if port connections are more important to you, you can use the slot for another connection module. A few models, such as 3Com's, include a proprietary port in the back into which you can plug a management module, a bridging module (to turn the hub into a bridge), or a combination of the two. The add-in module is about the size and shape of a deck of cards, so it doesn't add much to the size of your hub.
Whether your hub's management capabilities come from internal or external modules, you'll have to contact the hub's vendor for intelligence hardware. You can't take a module from one vendor and plug it into a hub from another vendor.
Although the essential purpose of a hub remains the same no matter what kind of hub it is or what it can do, the fact remains that not all hubs are the same. Some can only provide a basic connection for the network, while others possess advanced troubleshooting capabilities. Some can amplify the signal to increase the span of the network, and others can only pass the signal along as it reaches them.
As we'll discuss, you can increase the intelligence of some hubs but not others. Some hubs will accept internal or external management hardware, and some of those have flash ROM that you can upgrade with software. (Software-upgradeable hubs are a really good thing to look for, as they extend the useful life of your hub by letting it take advantage of new information.) Upgradeability is a real issue if you expect your network to expand, so when you're buying, consider what your future needs will be, as well as your present needs.
A passive hub is only a contact point for the wires that make up the physical network. A punchdown block, one example of a passive hub, consists of a plastic, unpowered box that you can plug the cables of the network into, such as the RJ-45 cables used in a 10BaseT Ethernet network. When you plug in the cables, the wires inside the cable make positive contact with the punchdown block and, thereby, connect to the other cables used in the network.
Powered Passive Hubs. Not many networks use totally powerless passive hubs like punchdown blocks. More often, the center of each star will be a powered, but passive (non-repeating) hub, connected to any other hubs via a patch panel in a wiring closet.
In token-ring networks, a powered device called a multistation access unit (MAU) serves as the focal point of the network. MAUs are slightly smarter than punchdown blocks. Bypass circuitry is inherent in the design of these hubs, meaning that if a network node isn't communicating with the rest of the nodes plugged into the network--if the cable or its connection to the hub is dead--then the nonfunctioning member doesn't interfere with the rest of the nodes plugged into the hub. The dead node won't work, but the rest of the network will while you're figuring out what's wrong with that node.
Although brighter than punchdown blocks, ordinary MAUs don't have much intelligence built into them. They can distinguish between an active token-ring connection and a dead one, but they can't distinguish between an active 4 Mbps token-ring connection and the 16 Mbps one that should be there (for example), or between a token-ring connection and a video cable. Plug in a device that a passive MAU doesn't recognize, and the entire network may crash. The problem is that the MAU can't talk to a device that isn't using a signal that it recognizes, and a video cable or a token-ring connector set to the wrong speed doesn't communicate in any form that the MAU can recognize as a language. They don't have enough in common even to argue.
Applications for Passive Hubs. Like other network components, hubs are generally getting smarter as the price of computing intelligence drops, and performance and management standards get higher. Although passive hubs are still available on the market, they're not as common as they once were.
First of all, by definition, no Ethernet hub can be passive--every device connected to an Ethernet network (including the PCs) acts as a repeater for the signal. Repeating capability makes a hub active. Second, token-ring hubs are getting smarter. In the early 1990s IBM realized that they were going to lose market share to Ethernet if they didn't start making intelligent MAUs (like the intelligent hubs that the 10BaseT networks were using). Therefore, only older MAUs are passive hubs. We'll talk about the smart ones a little later in this chapter.
Passive hubs are a relatively inexpensive means of connecting your network, but they don't do anything in your network except provide a contact point for the network through which the nodes of the network can communicate with each other. With the growing importance of networks in the corporate world, that's rarely enough these days. If your network extends across a wide span and you're worried about signal degradation, or attenuation, you'll need a hub with repeating abilities to strengthen the signal--an active hub. For management capabilities, you'll need a hub with some smarts--an intelligent hub. Of course, a hub can be both. Although I haven't inventoried every commercially available hub, I can't imagine why someone would make an intelligent hub without repeating capabilities.
Punchdown blocks and other passive hubs don't do anything except provide a contact point for the network cables. Hubs that are a little smarter than passive hubs have repeating capabilities. Rather than just passing the signal from node to node, an active hub can regenerate the signal so that it maintains its strength. As we discussed in the previous section, all Ethernet hubs are active, as repeating is inherent to the bus logical topology.
Active hubs are often called concentrators (either because they concentrate and thus strengthen the signal or because they concentrate the capabilities of an entire LAN into a box--I've heard both theories). Concentrators can accommodate more than one set of network connections; you can add modules to them to add more ports or (depending on the model) different kinds of ports. Thus, a concentrator could offer a connection for both your token-ring network and your 10BaseT network, if you had modules to support both kinds of ports. This can save you the cost of another hub.
You can also add a module to plug in a high-speed connection to another hub, which is useful when your network expands beyond the physical limitations of cable length or you run out of slots in the concentrator.
Intelligent, or smart, hubs include some kind of software management to detect and isolate network problems. Some intelligent hubs are smarter than others, but anything called an intelligent hub will have some kind of management and monitoring capabilities.
From the earlier discussions, you can see that management capability can be essential to keeping your network up and running. If it's a small network with one hub and a few nodes, cable and port testing is not that big a deal--if a problem in the hub is keeping the network from functioning, isolating the problem in a ten-node network is a pain, but not impossible. A larger network of ten connected hubs with twelve nodes each would not be as simple, however, and the time and effort required to manually troubleshoot a downed network would be more than most network or system administrators can supply. Therefore, if your star network extends beyond a few nodes, you'll need some kind of intelligence built into the system if you want to keep your sanity.
Intelligent hubs can offer both monitoring and managing capabilities--that is, they can keep track of how the network's doing and also take action to correct problems. How capable they are depends on the intelligence of the individual hub. Not all intelligent hubs are equally intelligent. As mentioned before, the intelligence comes from internal or external modules that you can add to the hub. The ones that have flash ROM that you can upgrade with software are best, because they allow your network management abilities to grow with the technology.
SNMP. The most popular management protocol that intelligent hubs use is called SNMP, or Simple Network Management Protocol. Almost any manageable device you buy will include SNMP in its management suite. SNMP acts as a sort of poll taker, going around to the devices that it's managing and asking them how they're feeling. Whatever the response, SNMP notes it down in a management information base, or MIB. In case of trouble, the network administrator can review the contents of the MIB to isolate the problem child.
SNMP is the main management protocol that you'll see for just about any manageable device, but like many other network standards this one came about by default rather than as the result of any planning. As networks developed, it became obvious that if network administrators were going to get any sleep at night, some kind of remote administration was necessary. So a number of developers began working on high-powered management protocols (one of which was CMIP, discussed next). In the interim, however, administrators clamored for some kind of managing ability, so the developers put together SNMP to hold off the demands for better control until their versions were complete.
Of course, the end of the story is predictable: SNMP became the standard because it was available when nothing else was, and the more powerful management protocols became proprietary.
Please note that not all SNMP implementations are equal. First, only those SNMP devices that are MIB-2 compliant will talk to each other so that you can get a complete picture of your network. Devices following older standards or those including proprietary extensions that increase the management capabilities may not talk to each other. Second, even those that follow the industry standards may include different features. Two devices from different vendors that are both MIB-2 compliant may have completely different capabilities. When shopping for SNMP-managed devices, be sure to check for MIB-2 compliance and get a copy of the MIB to see what the device can monitor.
Several companies offer management software that works with SNMP-managed devices to give you a graphical view of the network without leaving your desk. Although GUI management software can be nice, be sure to evaluate it (or at least demo it) before buying. Some network management software is quite good; other products offer nothing more than pretty pictures that really don't tell you anything. If done right, network management software can save you time by putting the network in front of you without you having to leave your desk, but otherwise it's a waste of time and disk space. IBM's NetView and HP's OpenView are two examples of good SNMP management GUIs.
CMIP. The Common Management Information Protocol (CMIP) is a far less common network management tool than SNMP, but it has a small following. Using object- oriented descriptions, CMIP lets the network administrator define hundreds of parameters for the system to monitor, including physical problems, security breaches, heavy network traffic, and so forth.
It works like this: rather than the network management software polling the pieces of the network, they volunteer information based on the parameters set by the network administrator. A hub might tell CMIP that it's a 10BaseT hub hooked up to twelve normally functioning nodes, and that it's passing X number of packets per second.
The power of CMIP is that it provides the network administrator with the information that he or she needs. It has two major failings, however: it's a lot of work for the network administrator, and it requires many times more processing power than does SNMP.
How does CMIP represent more work for the network manager? Well, to get the network-specific information that the network manager needs to keep up with events, she has to define objects and parameters for each component of her network. If she replaces a component, then it needs a new object. For example, if you owned one CMIP-compliant hub and then replaced it with another model from the same manufacturer, you'd have to start from scratch to make the management system recognize it. You can't just tell CMIP, "Oh that? That's the new hub I bought. Treat it just like the old one."
The way that CMIP is customized for each network it manages means more work for the hardware, not just the humans. CMIP must be able to communicate specifically with each component, so generic responses from the network components are not possible. This means that CMIP-compliant devices need more on-board memory than SNMP-compliant devices, thus slowing down acceptance because of the larger costs involved.
Proprietary Management Protocols. It's hard to generalize about the way in which proprietary management works, as it's fine-tuned to the hardware it's meant to run on. Because the hardware and management are made for each other, they can sometimes do things that less specific management utilities can't. The details of what they do and how they do it depend on the vendor.
Proprietary protocols may be more efficient than general ones, but they've got the disadvantage of all proprietary components: they lock you into one vendor. This isn't necessarily a bad thing, as long as you're happy with your vendor and willing (and able) to buy all managed hardware from them, but it will limit your choices.
Can You Mix Managed Devices? Well, sort of. You can mix them, but whether or not you can manage them as a unit is another question entirely. (A question worth answering, if you're going to the expense of buying a managed hub.)
The problem is that the smarter a device gets, the more there is involved to make it compatible with like devices for management purposes. Fairly dumb devices, like network cards, can be mixed on the network because they function at a fairly low level on the OSI model. Smarter devices, like managed hubs and other network connectivity hardware, function at a much higher level--in some cases, at the application layer on top of the chart. To work together, the devices must only be able to communicate at the data link layer, but to be managed together requires the devices to be much more in sync.
As one 3Com representative pointed out, once the various vendors began creating their own management platforms, it was not to their advantage to make them compatible with devices from other manufacturers. The only person who would benefit from such cooperation is the user.
As always, the answer to this question depends on your situation and network requirements. A few thoughts, however:
Because of their place in the network, hubs have an inherent, serious failing: they present a single point of failure in the network. If the hub goes down, it drags the rest of the network with it, because no information can pass from node to node. Period.
Therefore, it's in your best interest to make sure that the hub keeps functioning. That means taking a few questions into account:
As in every aspect of networking, one of the most important questions is how to keep power running to your system and how to ensure that it's the clean power that electronics prefer. This isn't just about blackouts, which are easy to see the effects of; it's about making sure that the hub isn't damaged by power surges or sags. Although a complete discussion on power is reserved for elsewhere in this book, it's worthwhile to make a couple of points about power here:
So power quality is going to get worse before it gets better, and bad power kills network components. (This isn't limited to network devices, obviously; bad power is just as bad for stand-alone devices.) What can you do to keep good power running to your hub?
Isolate Hub Power. First of all, try to keep your hub on a circuit away from devices that dirty the power supply. That means no heating elements and no big motors, so coffee makers, refrigerators, and laser printers are no good. If you're not sure how the wiring in your building is arranged, check with the building manager or maintenance people and get the wiring blueprints. If you can't get the wiring blueprints, you can either guess or test the circuits some weekend when/if you can shut down parts of the power to the office and see what outlets are on the same circuits.
CAUTION: If you're not sure of what you're doing and don't have permission from the building management or your boss, do not flip circuit breakers to see what outlets are on the same lines. Shutting down some systems (servers, for one) without adequate preparations can be extremely bad for the devices you're shutting down. It can also be bad for your job security.
Checking the plugs to make sure that they're wired properly isn't a bad idea either. Sometimes, even three-prong plugs aren't grounded properly, or the polarities are reversed, or some such thing. Not all problems are bad enough to cause immediate problems on the order of explosions (in fact, if they're that bad, they generally get fixed fairly quickly), but you can find more minor problems that could turn out to be serious with the wrong set of circumstances. The testers don't cost much--I got mine for about $5. Plug it into an outlet, and the status lights will show you if the outlet is wired properly, or if not, what's wrong with it.
Regulating Hub Power. Sometimes, complete power protection in a star topology requires double protection: you need to protect both your hub and the data lines connecting the nodes to the hub. On the hub side, you can buy a UPS or SPS to plug into the serial port. You can determine the size of the device by the wattage that the hub uses. If the UPS or SPS includes a power conditioner, then your hub is protected from sags and surges as well.
The hub isn't the only vulnerable part of the network, however. The data lines can pick up electromagnetic pulses (EMPs) from nearby lightning strikes and conduct the pulses to the network nodes. This is odd but true. APC, for example, started developing data line protection after some of its customers who'd bought UPSs called to complain that they'd plugged everything in properly but a power surge had killed a network card anyway. On investigation, it turned out that the power surge had come from the air. Lightning in the area hadn't affected the power supply to the building, but the data line had picked up the EMP and conducted it to the network node.
This doesn't happen often, but it happens. Network cables extended more than about fifteen feet (which describes many networks designed in a star topology) make good antennae, and in locations with lots of electrical storms that can be dangerous. The damage could fry just the NIC, or it could fry the motherboard. To protect the data line, you can plug a small surge protector directly into the network card and then plug the line into the surge protector. To ground the surge protector, connect another cable to a properly grounded source, such as the computer chassis or (to be extra careful) the screw in the wall of a properly grounded outlet. APC only makes single data line protectors, but you can also buy protectors into which you can plug several nodes at once--the only difference is that those devices plug into the hub, rather than the NIC.
What kind of power protection should you get? It depends on your circumstances. If your network uses passive hubs, it might be cheaper to keep a replacement or two on hand than to buy a UPS for every hub. As for data line protection, it's not really necessary in most of the United States, but take the weather conditions into account when deciding whether you need it. The devices are very popular in Florida, due to the high number of electrical storms in the area.
You can read more about power protection in chapter 18, "Backup Technology: Uninterruptible Power Supplies."
Simple problems, like disconnected nodes, shouldn't affect any hub. If nothing is connected to a port, or the connection isn't communicating with the hub, then the hub ignores that port and keeps the good ports connected.
Some problems aren't quite that cut and dried, however. For example, if a node on a token-ring network starts jabbering (sending streams of noise that tie up the network), then a passive hub or active hub without management capabilities can't shut up the offending node.
Remote Hub Administration. Some higher-end hubs are equipped with serial ports via which you can work with the hub even if the network is down. You can perform "out of band" management either from a PC connected to the hub with a serial cable or via a modem connected to the serial port. Using Telnet or (if supported) a GUI like OpenView, you can dial into the hub and operate it from across the telephone wire. The advantages to out-of-band management are twofold: first, you're not dependent upon a functioning network to access the hub, and second, you can manage hubs in another building without having to physically go to them.
Network nodes plug into the hub via LAN modules. The number of modules in the hub depends on the hub design. Although it is possible (and cheaper) to plug a number of nodes into the same module, if that module fails, so does the hub. For better fault tolerance, the higher the ratio of modules to nodes, the better off you are. The fewer nodes that you have plugged into each module, the fewer nodes will be affected in case of a module failure.
For extra fault tolerance, you can provide important nodes with more than one LAN module. You'll need one link to each module, so it's a little more complicated than a normal network connection, but it's possible. A transceiver splits the links from the network node to the two modules, so that the redundancy doesn't cause any confusion on the network. This also works to connect a node to more than one hub to get the ultimate redundancy. That way, if one hub fails, the node will still be connected to the network via the other hub.
If your network includes more than one hub and these hubs are in a connected star topology, then you can build redundancy into your network with double cables. Only one of the cables is necessary for transmission, so if one cable breaks, the other cable can route the traffic between the hubs.
Although most hubs are stand-alone machines with their own chassis, they don't have to be--a few vendors sell hub cards that you can put in your file server (for small networks) or a dedicated hub machine (for larger networks) and thus lower the cost of a star topology. Unsurprisingly, card hubs are cheaper than stand-alones. Card hubs also have the advantage of instant intelligence, too. One model (now discontinued for reasons we'll get to in a minute) operated in cooperation with NetWare, so to make your dumb hub intelligent all you had to do was load an NLM (NetWare Loadable Module) for management capabilities.
A hub card fits into a slot on your motherboard like a network card. On the back, where a NIC would have one connector, the hub card has as many as twelve, sometimes with an AUI connection available for attachment to another hub. Like any other card, the RAM on the board itself makes a difference in speed, as does the speed of the hub server's CPU, but the biggest bottleneck in hub speed comes at the bus type. All other things being equal, the larger the data path, the better network throughput will be.
If you've made your file server do double duty before, perhaps as a print server, it's no surprise that placing the hub in a non-dedicated server (one not used only as a hub) does not do good things for either network performance or server accesses. The burden of handling all the network traffic in addition to dispensing information can really slow your server down. If you've got more than a few nodes on your network, it's better to dedicate a machine to being a hub. For that matter, that's probably the reason why stand-alone hubs are more common than hub modules that fit into a bus slot--once you've moved the hub capabilities to another machine, the cost savings realized from not buying the stand-alone disappear. For example, Intel discontinued their EtherExpress TPE 10BaseT card hubs two years after announcing them, because they couldn't compete with stand-alone models.
Essentially, card hubs are a good idea for a very specific set of conditions (a small network that wants the management ease of a star topology but can't afford a stand-alone hub), but beyond that set of circumstances a stand-alone hub probably will work better.
To close this discussion of hubs, we'll discuss a relative newcomer to the hub market: the ATM switch. It's not a hub, but it can provide a high-speed backbone for hubs.
If you've worked with networks for any period, it's no surprise to you that the demands placed on networking are growing. E-mail isn't enough anymore--we want to transfer big documents, complex images, and real-time video with sound attached, and we don't want to have to wait for it. Asynchronous Transfer Mode (ATM) can make all this possible. Of course, ATM equipment is quite expensive at the moment (as is the equipment required to produce the kinds of complex files that need ATM to quickly get them from point A to point B), so don't look for ATM switches to be a part of Everyman's office for awhile. But the technology to connect LANs using ATM is available, and it's worth knowing about for the time when your data transfer needs expand to fit ATM, and the technology becomes a bit more affordable.
Although a detailed discussion of ATM is beyond the scope of this book (the topic hasn't been exhausted by the dozens of books written about it, so we're not going to cover it all in one portion of a chapter), we'll discuss some of the basic characteristics of ATM and ATM switches here.
ATM is a connection-oriented networking technology, operating at the lowest layer of the OSI model (described in chapter 3, "The OSI Model: Bringing Order to Chaos"). The ATM switch converts the data transferred to it into 53-byte cells. To transmit those cells, the transmitting node must set up a connection with the receiving node. Once the connection is accepted, the cells are shoved along a high-speed cable (most often fiber, but sometimes Category 5 twisted pair) to the next ATM switch, where the cells are reassembled into their original form. The cells carry routing and data type information within themselves so that they can get to where they're going without help from other devices, and so the switch can sort them out into their various types once they arrive at their destination. This mode of data transfer is called cell relay. It's not entirely a physical standard--ATM is not locked into one kind of cable--but it's close.
NOTE: For purposes of describing how cell relay works, the lowest layer of the OSI model, the physical layer, is divided into two sub-layers: the transmission convergence (TC) layer and the physical medium dependent (PMD) layer. The TC layer is sort of the mail handler for the physical connection--it packages data into cells, sorts received cells into their appropriate categories, and performs flow control. The PMD carries the data.
Cell relay has two main advantages: it's very fast (ATM runs at 155 Mbps--more than fifteen times faster than Ethernet) and it can handle any kind of data that you throw at it: voice, data, or real-time video. Each of the cells includes a header that identifies the kind of data in the cell, so the switch on the other end can sort out the various kinds of data. The sorting-out part of the equation is where the money comes in: to avoid mixing up the various kinds of information, and to do this quickly, requires a lot of intelligence on the part of the switch doing the sorting. The intelligence and high-speed cables required to make ATM work are expensive, and that's held up the implementation of ATM on a wide-area basis. (Some vendors, such as AT&T, are offering it on a beta basis to a few customers, but that's about it as of early 1996.)
ATM has been an "emerging" technology for quite a few years now, but its use currently and in the near future is mainly for providing high-speed backbones for hubs. You can insert ATM cards into high-powered workstations or servers and make them into ATM switches between hubs in a company's networking background.
A number of companies offer ATM cards that can provide speeds ranging from 155 Mbps to more than 2 Gbps. What characterizes these cards? Here are a few items:
What drives these characteristics?
Operating Environment. Most ATM cards operate in UNIX boxes. Although as noted earlier, NetWare and NT Server are beginning to be supported, the problem with these operating systems has been that their "native" protocols aren't really compatible with ATM; NetBEUI isn't routable unless it's encapsulated in TCP/IP, and IPX was originally designed for connectionless networking, which doesn't work very well with a connection-oriented technology like ATM. The difference? In a nutshell, a connectionless communication doesn't require any call setup before the message begins. Connection-oriented communications require the node that wants to send data to arrange a link with the node that it wants to send data to. Without the previous arrangement, the nodes can't communicate. In other words, ATM requires a connection-oriented routable protocol, like TCP/IP.
Management Protocols. We've discussed in this chapter the reasons why SNMP can be an easier management protocol to implement within a LAN than CMIP is, and how proprietary management protocols can lock you into one vendor. Therefore, the fact that all the ATM cards listed in the 1994 LAN Magazine Buyer's Guide use SNMP as their primary management protocol shouldn't be much of a surprise. If you're going to use a switch with a proprietary management protocol, then buy from someone whom you're certain a) will be around in years to come, and b) has good support so you'll be happy with the product. Otherwise, you'll be left with the choice of keeping unsupported equipment or buying new switches when the first vendor jumps ship--not an attractive thought.
Although SNMP is becoming the de facto standard for LAN management, there's been some discussion of the possibility of CMIP being used for wide-area ATM management (when ATM WANs become a reality, that is). This could work well. As discussed earlier, CMIP can provide more information about a network's operation than SNMP because it's so tuned to the network that it's managing, and since the devices used in an ATM WAN are less likely to change than those used in a LAN, the housekeeping shouldn't be as much of a problem for the WAN administrators.
Cable Types. Most full-speed ATM runs over fiber (often multimode fiber); some runs over Category 5 UTP. None support coaxial, as it can't keep up with the transmission speeds required by ATM.
The bottom line here is that an ATM switch will use either fiber or high-speed UTP. Because of the distance limits inherent in UTP, you might be better off with fiber unless your hubs will be quite close together.
Bus Types. There's no real generalizations about bus type in ATM cards--they pretty much run the gamut of the high-speed buses. I expect to see more PCI buses used for PC ATM cards. Because there's little point in having a narrow data path for a high-throughput card, the 32-bit and 64-bit cards should squeeze out the few 16-bit cards on the market.
As of this writing, ATM's main role in networking is to provide a switching point on a high-speed backbone for a LAN. The switch doesn't replace the hub, it connects the hubs. Take a look at figure 13.2 to see how this works:
Figure 13.2
An ATM switch in an Ethernet network often provides a high-speed backbone connection.
For this to work, the ATM switches have to do something called "LAN emulation" in which the Ethernet packets are divided into cells and then reassembled for the hubs to route. More vendors support Ethernet than token ring, so ATM will be more useful for 10BaseT networks than token-passing ones.
What about ATM to the desktop? Well, in theory it's supposed to work like a token-ring network in which all stations think that they've got the token. Each workstation taps into an ATM switch via UTP (as low as Category 3) and can send data at any time because they're all fooled into thinking that they've got the token. (Token ring works, recall, by passing a token around the network that can be either free or busy. If a node has a free token and needs to send data, it can do so as long as it's got the token. If the token is busy when it passes the node, the node cannot transmit.) The ATM switch is in charge of filtering the cells sent to it from the various nodes, determining which are local traffic and which need to be sent to another switch. If traffic gets heavy, then the switch can get overwhelmed and drop packets, and due to the nature of ATM, there's no error- correcting ability--lost packets stay lost.
The biggest problem with ATM to the desktop, however, is that the benefits to be realized from using the existing cabling infrastructure, although significant in terms of cost, aren't enough for the increase in speed that you get. ATM to the desktop runs at 25 Mbps, not 155 Mbps, and it still requires a hardware investment in the form of an ATM switch and ATM cards for the workstations. If 16 Mbps isn't fast enough for you, how long will it take for 25 Mbps to not be fast enough?
The bottom line is that ATM in a LAN probably will be used to switch traffic quickly between connected hubs, not to bring ATM to each station.
You should buy ATM switches by the same rules as those you use to buy other connection hardware--think about what you're going to do with it a year or two down the line. The one thing all networks have in common is growth. This is especially true if your network needs are great enough that you need a high-speed backbone to the network. If you need ATM in your building now, you're surely going to want to expand ATM capability to other sites when ATM over the WAN becomes available.
First, make sure that the box has WAN capabilities. Wide-area ATM won't be around next year, but it's a good bet that it will be commercially available in the not-too-distant future.
Second, make sure that the vendor is going to be around in a few years. Ask for references. As a systems engineer friend of mine observes, companies should be glad to provide references, because that gives them an opportunity to show off how well they've been able to help someone else. If a company doesn't want you to talk to its other clients (with their permission, of course), then it might be worthwhile to wonder why. This is especially true because the standards for ATM are still in flux. As buying from a single vendor is currently the only way to really ensure interoperability between your ATM devices, you'd better be happy with the vendor.
Hubs provide a central connection point to a network. This connection can either be a purely physical relay for network signals, or it can incorporate management features to help you control and troubleshoot your network. Some hubs even offer "out of band" management, so the network does not have to be running to let you dial into the hub.
ATM switches can provide a high-speed backbone to connect a series of hubs. This is currently the most common use for ATM, as ATM to the desktop does not represent enough of a performance increase to justify the additional costs to most buyers, and wide-area ATM is not really commercially available.
© Copyright, Macmillan Computer Publishing. All rights reserved.