If you’re not a network engineer and my generation or older, “ATM” means Automatic Teller Machine. If you’re younger, you don’t know what that means because you’ve never paid for anything in cash. If you’re a network engineer of a certain age, ATM means something else: Asynchronous Transfer Mode. ATM was a potential god technology back in the 1990’s. For a while, we all heard that ATM would take over, replace Fram Relay, replace Ethernet, replace IP, and replace generally everything. It was the one thing you needed to know, but it was also confusing as heck. ATM was real, and it was big for a while, before vanishing into the dustbin of obsolete technologies. As we suffer through a little bit of hype around certain technologies, ATM is a lesson in the fickleness of technology and its adoption.
To understand ATM and its origins, it’s important to consider the telecom landscape of the time. Voice networks had been in place for a long time and used circuit switching. Large central office switches like the DMS-100 and 5ESS would take an incoming call and establish a path to its destination for the duration of a call, tearing it down when the call was over. Various methods of in-band and out-of-band signaling were used to set up, tear down, manage, and bill these calls.
In the 1990’s, with the rise of the “Information Superhighway”, engineers correctly predicted that data networks would be used eventually to carry voice. This brings a number of challenges. How do we emulate circuit-switched calling on packet-switched networks? And importantly: how do we provide a quality of service adequate for real-time interactive voice traffic? Wikipedia highlights the problem:
At 155 Mbit/s, a typical full-length 1,500 byte Ethernet frame would take 77.42 μs to transmit. On a lower-speed 1.544 Mbit/s T1 line, the same packet would take up to 7.8 milliseconds…This was considered unacceptable for speech traffic.
ATM proposed using 53-byte cells to transmit data–48 bytes of data, 5 of header. A Virtual Path and Virtual Channel Identifier are used for addressing: A virtual path can contain multiple virtual channels. The rest of the header consisted mainly of QoS-related data.
ATM had a variety of “ATM Adaptation Layers” which were used to map different types of traffic into the ATM scheme. For example, AAL 0 was used for raw cells, whereas AAL 2 supported variable bit-rate, connection-oriented traffic, and AAL 3/4 was for “supports VBR, data traffic, connection-oriented, asynchronous traffic (e.g. X.25 data) or connectionless packet data…” Simple, eh?
At first glance ATM seems like a wide-area technology for service providers, a replacement for Frame Relay, and that’s largely how it was used. If you read the trade publications at the time, however, you’d think there was nothing ATM couldn’t do. Excited by its prospects for voice, video, and data convergence, vendors and engineers thought everything would be ATM. Remember that back in the early days of networking, the Ethernet/IP dominance was far from certain, and there were many competing technologies. (Token Ring, FDDI, Banyan Vines, IPX, AppleTalk, CLNS, etc.)
Thus, instead of being confined to the WAN, various vendors began offering ATM to the desktop. In an old article, we read that “ATM technology has to make its way to the desktop, and that journey has begun. Prodan [a marketing guy] says that the number of Fore’s ATM adapters sold jumped from 1200 in 1993 to 5680 in 1994.” The promise of ATM was not only higher speeds and voice/data integration, but the fact that you could use the exact same technology on the LAN and WAN. As a result “routers and translation devices are no longer needed” to connect LAN to WAN. Those pesky routers would be a thing of the past!
As if ATM weren’t confusing enough, some were proposing it would even replace IP. I remember being baffled by this as a young network engineer. It seemed like ATM was a layer 2 WAN technology–how could it possibly replace something like IP? While I couldn’t find a source article arguing in favor of this position, Terry Gray’s informative 1999 article “Why not ATM?” refers to “the vision of ATM domination (end-to-end, completely replacing IP)…”
I never actually encountered an ATM LAN in the wild, although one of my peer network engineers in the early 2000’s came from a company that used it. I did have to configure ATM for my 2004 CCIE Routing and Switching lab, but it was very performative. You were given one end of an ATM link and told to configure an SVC. It was so unimportant to the test that I never acquired ATM for my lab. (Also because it was prohibitively expensive.) In TAC I took a handful of cases that involved ATM, but I never really knew what to do. Actually, I did know what to do: call Masood S.
Masood was a cryptic as ATM. His last name, even in the company directory, was simply “S”. He had a cubicle on the third floor of building K in San Jose, with a bunch of stuff in it, but I saw him there maybe twice in two years. But Masood loved ATM. If you had a case at 2 o’clock in the morning that involved ATM, you’d ping Masood and he’d jump in, full of energy and ready to troubleshoot. I can’t tell you the feeling of relief I’d experience as Masood jumped into Lightstream switches and started explaining the complexities of ATM Adaptation Layers and CBR-vBR-ABR-whatever-weird-QoS-ATM-uses. I also can’t tell you the feeling of dread that came across our team when we heard the words, “Masood is on PTO.” You prayed you didn’t get an ATM case for two weeks. (Masood knew a lot about a lot of other things too. We used to tag-team interviews grilling TAC candidates on routing protocols. Back when I actually knew something.)
If ATM was poised to conquer the world, why don’t we use it today? Several reasons.
First, it was quite expensive for local-area networking. Ethernet was far cheaper. Back in the day, we had to hard wire computers and we needed to buy a network-interface card to do so. By the time Terry Gray was writing in 2000, a 100 Mbps Ethernet card could be purchased for $10, versus $700 for an ATM NIC. That points to another major problem for ATM–Ethernet quickly eliminated many of ATM’s advantages by allowing for faster speeds, over copper, and by introducing switching. (Previously Ethernet networks mostly used hubs.)
Second, in the WAN space, other technologies like MPLS began to take hold and replace older-school virtual-circuit technologies like ATM and Frame Relay. A service provider could just give you an Ethernet circuit (when metro-E showed up) and then you would just peer at layer 3 with the provider for MPLS service. (For the record, I hated SP-managed layer 3 MPLS. It put you in the position of having to negotiate with your provider to add another prefix to your route advertisement or enable a feature like multicast. If they even supported it.) Interestingly enough, in the early days is was possible to do MPLS over ATM, called “cell mode.” My copy of the 2001 book “MPLS and VPN Architectures” by Peplnjak/Guichard describes it. Apparently it wasn’t easy: “The ATM technology design and architecture present a number of challenges to an ATM implementation of MPLS technology,” the authors tell us. What follows is a complex discussion of a type of MPLS implementation that I never saw in two years in routing protocol TAC. I don’t know how many customers did cell-mode MPLS, but I never encountered those who did.
Finally, as I said at the beginning, ATM was confusing. The basic cell-switching and forwarding model was simple enough. But the multiple adaptation layers, alphabet-soup QoS system, and attempts to shoehorn it into places it wasn’t designed for…all these ended up making it a beast to learn and baffling to many younger engineers like myself.
As it is, ATM had a successful run, mostly as a technology internal to service provider networks. It never, however, became the “god technology” that many proponents envisioned. As we live through another technology hype-cycle, it would be good to remember the lesson of ATM. It was neither vaporware nor the solution to everything. As with most technologies, it sat somewhere in between.