ATM in the Internet

Communications News, Jan, 1998 by Bob Sullebarger

The Internet's unprecedented popularity is causing substantial congestion. The problem begins in the public switched telephone network -- where call-duration for data is 10 times that of voice traffic -- and extends through the WAN backbone, where routers are crashing with increasing frequency.

The only long-term solution is a more streamlined infrastructure that adds capacity based on more throughput from switching, and not merely on more nodes that route.

With a new user every 30 seconds and multimedia applications on the way, the Internet is in desperate need of an enduring, scalable foundation. The unpalatable alternative would be to limit the Internet's size and application potential to roughly what it is today. There really is no other viable option: the Internet needs switching, and ATM is made to order.

The original design concept of ATM aimed for scalability, affordability, and the ability to accommodate both circuit-oriented and packet-based networking protocols.

Circuits and packets are like oil and water: they cannot and will not mix well. So it was necessary to invent the cell, a fixed-length packet that can behave like a circuit through switching fabric.

Cells make it possible to create high-speed switching engines capable of passing traffic in the multiple gigabits-per-second range. Even more important, these engines can be implemented in silicon, making them both scalable and inexpensive. And these little engines replace a lot of complex and costly circuitry that is required in a conventional router.

The IP switch, built around this ATM engine, creates a network architecture that is simple yet elegant, powerful yet affordable. Even with its "cell tax" of 10%, ATM's generous bandwidth makes for the fastest solution available.

IP exists at Layer 3, the networking layer, as defined by the International Standards Organization (ISO). ATM exists at Layer 2 protocol link and media access control layer. IP cannot operate without a Layer2 protocol like ATM, and ATM could not handle a single application without higher layer protocols like TCP/IP.

In fact, IP already depends on a number of Layer2 protocols, with Ethernet and PPP (the Point-to-Point Protocol) the two most Popular in the LAN and WAN, respectively, ATM is just like any other Layer 2 protocol with two important exceptions: ATM is more flexible and capable.

The Internet and ATM will come together, but not until the IETF (Internet Engineering Task Force) and the ATM Forum are forced to resolve their differences. Service providers are already deploying IP over ATM.

ATM accommodates routers, IP switches, virtual circuits, frame relay and more -- all at very high speeds. IP switching over an ATM foundation is the next logical step in the evolution of the Internet.

Frame relay also helps make the Internet more robust by supporting a logical rather than a physical meshing, of routers, but it alone cannot meet the many demands of the Internet. Indeed, frame relay needs ATM to scale from today's OC-12 (622 Mbps) to OC-48 (2.5 Gbps) and beyond.

While the merits of ATM as a LAN technology are being debated, numerous service providers have been quietly building an extensive ATM infrastructure in the WAN.

These are not trials -- they are production networks from UUNet, AGIS, MCI, SAVVIS, Skyscape, ATMnet and others that already handle a substantial portion of the Internet's traffic. If you use the Internet, you have undoubtedly sent or received IP traffic via this ATM infrastructure.

Naturally, one of the issues that must be resolved is an industry standard for IP switching over ATM. Early indications are that Multi-Protocol Label Switching (MPLS) will win. The IETF has begun work on MPLS, and early implementations are available now in some IP switching solutions.

Another issue to be resolved between IP and ATM is how to take advantage of ATM's ability to deliver different classes of service. ATM offers a constant bit rate (CBR) that performs like a dedicated circuit, as well as an available bit rate (ABR) that supplies bandwidth as available, as the name implies.

In between are two types of variable bit rate (VBR) services for real-time and non-real-time traffic, and at the low-end is an unspecified bit rate (UBR) for non-critical applications.

ATM, of course, has certain mechanisms for controlling the various bit rate services end-to-end in the network. But the IETF is also defining the Resource ReSerVation Protocol (RSVP), which is a means for controlling IP service levels.

RSVP does not yet fit "hand in glove" with ATM, but efforts to permit seamless integration are underway.

While the marriage of IP and ATM is inevitable, it will not be monogamous. IP will need to support different service levels when operating over Ethernet, frame relay and other LAN and WAN protocols. And ATM will need to deliver different service levels for non-IP applications, including IBM's SNA and voice, to name just two.

But for ATM to serve IP well, it will need to support RSVP.

Once the class-of-service issue is resolved, the Internet's capabilities will be dramatically expanded in two ways. The first involves service-level agreements (SLAs) where service providers will be able to assure sustained throughput for a customer.