Complete product listing Excel spreadsheet that lists vendors and their wares. NOTE: We hope to soon have up an interactive version of this guide. Review of switches from FORE and Xylan Network World, 10/6/97.

By Edwin E. Mier
Network World, 10/6/97

ATM is a technology in transition. Standards are still evolving and, like it or not, so are today's ATM switches.

That's not to say ATM is unstable, or that it's too early to deploy ATM nets. In fact, the upside of all this change is it's bringing improved features and functions that are making ATM more efficient and capable. But the downside is the huge toll it exacts on multi-vendor interoperability and backward compatibility.

The upshot is that you need to consider several future-proofing factors when you're selecting an ATM switch.

New or added processing requirements

Scalability of switching fabric

Concurrent support for old and new standards

Determine the switch's role

Part of this distinction is historical. Prominent switch makers that traditionally targeted the carrier/telco central office marketplace are continuing that thrust with their latest brand of high-end ATM switches. These products tend to be modular, feature more redundancy options, support only WAN-oriented ATM interfaces such as ATM over DS-3 and T-1, and come with special software for detailed call accounting.

However, the biggest distinguisher of the carrier/telco ATM switch marketplace usually is price. These units carry the highest per-port price tags, as well as the highest profit margins . especially for vendors who sell to local phone companies and RBOCs.

Then there's the private sector. ATM switches take on several different flavors here.

Backbone switches tend to interconnect other switches instead of directly linking end users. Comprising the core of an ATM network, backbone switches have a variety of responsibilities. They need to address high switched call volumes in some environments, but in others they're charged with handling largely static connections. Backbone switches need to be prepared for a range of traffic loads and a large number of logical paths, as well as changing topology requirements.

Then there are workgroup switches, which handle direct station connections. These connections can be made via ATM or, more commonly, via an organization's existing LAN.

Legacy LAN-to-ATM switches, commonly known as edge switches, let LAN workstations connect to an ATM backbone via one or more ATM uplinks. (The term edge switch also has been used to refer to specialty switches that connect a private network or other premises equipment to a carrier's ATM-based network for wide area ATM service.)

Legacy LAN-to-ATM switches can be considered as a subset of workgroup switches because they're always handling data-only traffic and a fixed maximum number of client workstations (depending on the legacy LAN technology.)

When it comes to throughput and the number and type of supported LAN interfaces, legacy LAN-to-ATM switches are a diverse lot. Many edge switches aren't even cell switches; they're traditional frame- or packet-based store- and- forward switches, such as Fore Systems, Inc.'s ES3810. These poorer cousins are traditional frame- or packet-based, store-and-forward switches with one or more uplinks (usually ATM OC-3 155M bit/sec) to connect to an ATM backbone switch.

How much is enough?

Projecting your ATM bandwidth requirements for seven or 10 years, however, is difficult. The rule of thumb for packet data used to be that you could plan bandwidth requirements to double every five years. But measuring ATM bandwidth is a little different.

Unlike traditional shared medium LANs such as Ethernet and Token Rring, ATM is almost always full-duplex; that is, ATM connections entail separate paths for transmitting and receiving. But a full-duplex 100Base-T connection works pretty much like an ATM link.

A 155M bit/sec ATM link equates to 310M bit/sec of switching capacity because the switching fabric needs to be ready to handle a full load in either direction. Consequently, the switching capacity needed to support eight fully loaded 155M bit/sec ATM links is nearly 2.5G bit/sec. You may want to consider 2.5G bit/sec as the minimum capacity for a backbone switch. Backbone switches commonly need to support heavily loaded bi-directional links on a continuous basis because they tend to connect other switches instead of individual end points.

Make sure you thoroughly understand what expandability options are offered, if any. Expect to pay considerably more for a switch that can grow to, say, 10G bit/sec, even if you initially need only 2.5G bit/sec of switching capacity. Also know how the switching fabric expansion is handled architecturally. Find out if latency - the transit delay of cells traversing the switch - increases appreciably when the switching capacity expands.

You don't want end-to-end delay to vary more than 5% or cumulative delay to exceed 50 to 75 msec.

Features and capabilities

One metric you may want to ask vendors about is the switch's SVC call-processing capacity, usually measured in SVC call set-ups per second (or per minute). ATM clearly is evolving to SVCS from PVCs, which are fairly inefficient because chunks of bandwidth are allocated on a more or less permanent basis. All communication over ATM LAN Emulation 1.0 (LANE), for example, is done via SVCs. (LANE 1.0 is the current standard that defines how traffic from legacy LANs is handled over ATM backbones. It's now widely supported by switch vendors, but performance can vary considerably.)

A lot happens under the covers in an ATM switch, but some of the underlying mechanisms are implemented very differently from vendor to vendor, if they're implemented at all. Consider, for example, traffic policing and buffering.

Traffic policing is a worthwhile feature that compares the amount of bandwidth that's been reserved for a circuit or path with the bandwidth actually used. If congestion forces a switch to drop some traffic and a path exceeds its amount of reserved bandwidth, the switch will designate that traffic as eligible to be discarded.

Buffering is another mechanism to stop traffic loss; virtually all switches perform it to some degree. As a rule, the more buffers the better, but you may not want to necessarily buy the switch that has the most buffers. If the buffers aren't properly designed, they can result in other problems like variable cell delay.

Buffering ties in with other capabilities that the switch supports internally for flow and congestion management. A few techniques have been widely accepted and deployed for ATM flow and congestion management, such as one called dual leaky buckets. Understanding all the subtleties in this area requires a fair amount of education. Instead, you may ask the vendors if they have an independent third-party assessment of the switch's buffer or congestion-management architecture.

Some ATM switch operation areas haven't been fully standardized, so vendors take different approaches to implementing them. Take ATM switch management -. some vendors have based their management architecture on SNMP, while a few others, especially those targeting carriers/telcos, have based it on other arcane, quasi-standardized specifications like OSI/CMIP.

Multi-vendor interoperability

Clearly, a manager who shells out the dough for an ATM backbone expects the switch to interoperate with other vendors' equipment using accepted ATM standards. And most ATM vendors are moving to ensure their equipment complies with the standards and works with other vendors' ATM wares.

But the industry can't yet claim full interoperability of ATM switches. Roughly half of the ATM Forum's specified interfaces are solidified and mature enough to boast general interoperability between different vendors' implementations, while the other half can still present problems. Most designs keep new switch code in software, rather than committing it to firmware, so changes can be readily made.

To be sure, ATM products can already be considered interoperable with respect to a number of standards. These apply mainly to the end- user side of the network, such as UNI 3.0 and UNI 3.1 and even LANE 1.0 client implementations as found in ATM network interface card drivers and edge switches.

The further inside an ATM network you go, the more likely interoperability problems relating to the latest ATM standards will occur. For example, different vendors' switches may interoperate using an older, static-network protocol called Interim Inter-switch Signaling Protocol, but may not work together using the newer, dynamic-network Private Network- to- Network Interface protocol.

You can buy ATM today and build a network that, in all likelihood, will outperform any other technology. But be prepared for ATM's high cost and complexity and the need to keep pace with frequent changes as the technology matures.