BUYERS GUIDEATM NICs And Switches: Is It Buy Or Bye?by Art Wittmann |
|
|
If you're thinking about ATM but haven't watched the technology's evolution, prepare yourself for an alphabet soup unlike anything you've seen before. If you thought Ethernet or Token-Ring came with a learning curve, get ready for one with a much steeper grade. This technology is the first in quite some time to have the attention of both the local-area and wide-area data network designers as well as the telephone company standardizers. If you haven't been following ATM, this article won't be able to bring you up to speed on its own. Visit Network Computing Online, at www.NetworkComputing.com, and take a look at articles that have appeared during the past year or so. In particular, look at associate technology editor Joel Conover's ATM edge-switch shoot-out, at techweb.cmp.com/nc/711/711f1.html.
Switched networks make sense--no doubt about it. Providing dedicated bandwidth to users certainly will result in desktop computing being used in new ways. The problem is, we're not sure how switched networks should be built. Is desktop videoconferencing really going to become a de facto standard anytime soon? I doubt it. Will we replace the phone on your de sk with some card that goes in your computer, sending your digitized voice over your local data network? It probably won't happen any time soon. On the other hand, distance learning and video and audio delivery over the Net are interesting ideas that will leverage an investment in an ATM switched network. Whatever the reason you're considering ATM, be aware that the standards are still evolving, so asking vendors questions about the life span of your ATM investment should be high on your list. If you want a standardized way to support many subnets on a single backbone, ATM offers that. If, on the other hand, you are looking for a degree of control over traffic on your network, the ATM standards aren't yet there. Switched Ethernet and Fast Ethernet, ATM's chief competitors, rely on higher-level standards to provide traffic control. TCP/IP's Resource Reservation Protocol (RSVP) is an example. Because of the lack of ATM standards, if you think you're going to build the next Internet purely on ATM, you'll probably be disappointed with the technology's scalability. You can build flatter networks (ones with few routers), but completely doing away with routers in your network, and their utility for protocols such as RSVP, is another story. Here are some questions you'll want to research: · How complete is the ATM standard and what should you watch for when considering the technology? · How upgradable is the vendor's product? Can it support evolving standards or will it be obsolete with new versions of standards such as LAN Emulation (LANE), Multiprotocol Over ATM (MPOA), User-Network Interface (UNI), Available Bit Rate (ABR) or Integrated Private Network-to-Network Interface (I-PNNI)? · How many virtual circuits can the device support? Each VLAN connection can require a number of virtual circuits, so this number should be fairly large for backbone switches. Even server NICs should be able to support a good number of virtual circuits. · For switches, particularly those that will act as LANE servers, how much time is required to build and tear down virtual circuits? What about redundant LANE services? It's not part of LANE 1.0, but many vendors have developed (proprietary) schemes to build in redundancy. · For edge switches, can the switch automatically configure ports to match network requirements of mobile users? · Will the vendor guarantee that your hardware will support evolving standards such as LANE 2.0, ABR and MPOA? If the vendor does offer you a guarantee, will you be expected to pay for some level of hardware upgrade? · For modular switches, what about support for various speeds and wiring support? Depending on your needs, you may want fiber and twisted-pair, 25-, 155- and 622-Mbps options all in the same switch. The past year has seen some interesting skirmishes in the ATM standardization process. LANE needed an upgrade to support MPOA. I-PNNI was proposed and cast doubt on the need for MPOA. ABR offered a way to get data networks the performance characteristics they want while still providing other network users, such as voice and video, all the performance guarantees they need. ABR: Is It Important to You? Although many of these standards may be important to you, it is unlikely that all are--particularly on campus networks. The important difference is that on local networks, it is fairly easy to overbuy performance. However, on WANs, where every ounce of performance costs money, overbuying is a bad idea--the kind that could cost you your job. So ABR and other congestion-control mechanisms will likely be important only on wide-area links. ABR doesn't work unless the station at which an application is run participates in the ABR-negotiation process.
MPOA: Better Than LANE? MPOA is one of those specifications that sounds "so good," but may not be such a windfall in practice. If you understand LANE, you know that it enables you to create subnetworks on your ATM backbone, but the traffic that flows between subnets must still be handled by a router. The router can be conventional with lots of Ethernet ports--each connected to a distinct LANE subnet--or it can be a one-armed router, with an ATM card and virtual circuits to each subnet. MPOA's improvement on this concept is that routing decisions are pushed down to the edge switches. Rather than using a router that can become a bottleneck, MPOA uses a route server, which builds routing tables and pushes them down to switches. The switches then use the table to make routing decisions, resulting in traffic never being routed, at least in the classical sense of going through a router. Although MPOA makes perfect sense and should result in a more scalable network, there are problems with it. One issue is protocol support. At first, MPOA probably will support only TCP/IP, with IPX support following later--maybe. If you need AppleTalk or DECnet, you may be in for quite a wait. Furthermore, if you use lots of the bells and whistles that come along with high-end routers, you may find yourself missing them on the first round or two of MPOA gear. Finally, if you've purchased LANE 1.0-compliant ATM hardware, you may have to throw it away if you want the improvements that embody LANE 2.0 and MPOA. LANE 1.0 hardware will work in a LANE 2.0 and MPOA environment, but at diminished functionality. The Bottom Line ATM is not for the faint of heart or the light of wallet. It is an expensive technology that is evolving. Although bus speeds, processor architectures, numbers and types of ports and standards support are critically important, in the end ATM begs you to consider other technologies. Fast Ethernet, Switched FDDI and Gigabit Ethernet ar e reasonable alternatives. Gigabit Ethernet isn't here yet, but probably will be a stable technology soon enough. Using any of these technologies may necessitate a slightly different architecture for your network, but you might get much of the function of ATM without the hassles and uncertainties. Art Wittmann is the editor of new CMP Media online products serving enterprise computing. He can be reached at awittman@cmp.com. |
Updated October 8, 1996

Does your network need ABR? If you plan to run applications that negotiate for bandwidth across a WAN, then ABR is probably important. What that application might be, I can't say. Except for experimental and custom apps, I can't think of anyth
ing that will likely support ABR signaling in the near term.











