If you use a network that is based on ATM, or have an ATM network being installed near you, you've probably wondered what Linux support is available and what you can do with it. The ATM support for Linux has at last been integrated into the standard kernel and will be a key feature of the 2.4 series Linux kernels.
The "ATM on Linux" project has been running steadily since 1995 under the leadership of Werner Almesberger. It was originally developed as a research and teaching resource for the Laboratoire de Réseaux de Communication (LRC) of the École Polytechnique Fédérale de Lausanne (EPFL). Significant contributions have been made by the Finnish Tampere University of Technology, the University of Kansas, and a number of individuals.
The Linux ATM support is a combination of kernel drivers, userspace utilities, and daemon programs. Any code warranting high performance is kernel based, while anything complex and called infrequently has been left in userspace.
If you're already familiar with ATM, skip ahead; but if you've got no idea what ATM actually is, then it's worth spending a moment or two reviewing the basic concepts of it so you can properly appreciate the importance of the ATM support for Linux.
ATM is an acronym of "Asynchronous Transfer Mode," the name given to a new network architecture that blends some of the manageability of traditional circuit-switched networks with the flexibility of packet-switched networks like X.25 and the Internet. The basic unit of data transfer on an ATM network is the "cell," which is a fixed-length block of data, always 53 bytes. Data from end users is broken up into chunks, has some protocol headers added to it, and is transmitted as cells across the network from node to node until it arrives at the intended destination. To understand how this helps anybody, it is helpful to understand the problems experienced with other network technologies.
Traditional circuit-switched networks allocate a fixed quantity of network bandwidth to each "call" or connection between two hosts. This can lead to gross inefficiencies when used for data transmission because it is common for there to be significant gaps in data flow for many types of network application while the end user reads or decides what to do next. Consider how much time your PPP dial-up service spends idle when you are logged in, especially in the forward direction. The bandwidth you use when the service is busy is wasted when it is idle because no one else can make use of it -- it is reserved for you. While there is no data being transferred, the network bandwidth sits idle and is wasted. On the flip side, packet-switched networks have traditionally suffered performance problems as a result of congestion and the time it takes to switch large blocks of data from router to router across the network. It is difficult to manage the performance of packet-switched networks because it is difficult to ensure that appropriate bandwidth will be available at the specific instant of time it is required by real-time applications like Voice over IP (VoIP) or streaming video. For other application such as real-time games, robotic control, or remote control of delicate instruments, the variation in packet delivery time is important and again extremely difficult to control with traditional packet-switched networks.
ATM finds a middle ground. It is circuit switched; that is, you make calls across it just like you make telephone calls across a telephone network, and it provides a mechanism for providing reserved bandwidth (constant bitrate) or variable bandwidth (variable bitrate) connections between hosts. Because cells are all of fixed length, it is possible to conveniently schedule their transmission to ensure that bandwidth is available when it is needed. Scheduling of cell transmission also makes it is possible to reduce the variation in delivery times. Cells are quite short in length compared to the datagrams or packets of other network technologies, and this allows them to be transmitted in a very short time across each switch and link in the network. Finally, while the IP community struggles to manage quality of service issues, the flexibility of ATM provides a sensible way of mixing network applications requiring real-time performance with those that don't, with guaranteed quality of service for each.
The connections made across an ATM network are called virtual circuits. They are virtual because, while data may flow host to host, it isn't done on any reserved network links or cables -- that is, it isn't like a circuit in the electrical sense; instead it is a series of associations that enable data to be passed from host to switch, switch to switch, and switch to host in a manner that acts like a circuit. A permanent virtual circuit is like a connection between two hosts that is always present; it is established automatically and cannot be disconnected without deconfiguring it. A switched virtual circuit is like a telephone or ISDN call: A request must be made to have it established, and, similarly, it can be torn down at any time to free the resources it used. ATM hosts are addressable using a 20-byte address called a Network Service Access Point, or NSAP for short -- no shortage of addresses there.
Summary of Functional Features
Raw ATM sockets
SVC (Switched Virtual Circuits)
PVC (Permanent Virtual Circuits)
CLIP (Classic IP over ATM) (RFC 1577)
LANE (LAN Emulation)
MPOA (Multi-Protocol Over ATM) Client
ILMI (Interim Local Management Interface) (automatic address configuration)
ATM Name Service (and /etc/hosts.atm)
Test and diagnostic tools
ATM isn't perfect. It's still relatively new technology, and it hasn't been accepted in the way the vendors of ATM switches might have originally hoped. The original vision was "ATM to the desktop," whereas in reality today it's not really common to see "ATM on the campus." ATM technology is still relatively expensive to acquire and deploy. Some standards have been slow coming and in some instances are still nonexistent. To compound these problems, there is a growing perception that the ATM protocol overhead is prohibitive and consumes as much bandwidth as the allocation efficiencies were supposed to save.
All that being said, ATM is here, and you will see more of it. It suits the requirements of telecommunications carriers, and they will deploy large scale ATM networks. A growing provider market will generate a decrease in cost, and people not using it now will begin to use it. The ATM vision might yet come to fruition. If it's going to happen then we'll want Linux there right along with it, and that's what the "ATM on Linux" project is all about.
The Linux support for ATM is now quite usable and offers Linux users the opportunity to deploy a Linux-based machine as either an ATM-connected host or as an edge device on an ATM network, providing transparent protocol encapsulation and gateway features.
Summary of Supported Hardware
Efficient Networks ENI155P-based adapters
FORE Systems 200E-series adapters
IDT 77105-based adapters
IDT 77201/77211-based adapters "NICStAR"
Interphase ATM PCI adapters
Madge Ambassador and Horizon ATM adapters
NEC uPD98402-based adapters
PMC PM5346 SUNI adapters
ZeitNet ZN122x adapters
The basic Linux support provides two new socket types to support switched and permanent virtual circuits, AF_ATMSVC and AF_ATMPVC respectively. While these could be used to directly support network applications, you'll probably be more interested in carrying TCP/IP, at least until useful native ATM applications begin to appear.
There are at least three common ways of carrying TCP/IP over ATM networks, and Linux supports each of them. The first is called "Classic IP over ATM" or CLIP for short and is described by RFC-1577. The second is to have the ATM network pretend to be a Local Area Network using a technique called LAN Emulation or LANE. Finally, a third technique exists called Multi-Protocol Over ATM (MPOA) that is more generic and more flexible. MPOA allows you to specify policy that allows for all sorts of tricks to be performed between pairs of hosts or networks to optimize performance. The Linux MPOA support currently provides only for an MPOA client, but that is what most of you will be wanting in any case. You can configure and use any of these with the Linux support available today.
To make life easier, there are a couple of other features implemented. The first, the Interim Local Management Interface (ILMI), is used primarily as a means of automated address configuration. The second, a nameserver, is as useful to ATM as it is to IP. If you think a dotted decimal IP address is hard to remember, try keeping a collection of numbers that look like 47.0005.80FFE1000000F21A26D8.0020D4102A80.00 in your head! The ATM Name Service (ANS) is based on the BIND name server popularly used for Internet naming and is included in the toolkit for Linux on ATM.
Finally there is a suite of test and diagnostic tools including a modified version of the tcpdump utility to provide tracing of ATM circuits.
Other experimental features are in development.
A growing range of ATM adapter hardware is supported. All of the supported cards are PCI cards, and more drivers are being developed. The hardware drivers are kernel based just as for any other hardware, and some may be configured as loadable kernel modules.
ATM on Linux home page
ATM documentation is available at the web site of the ATM forum
If you want to try the latest ATM code today you'll need a copy of the 2.3.99-pre5 kernel source and the ATM tools package atm-0.76.tar.gz available from the ATM on Linux home page. At this site you'll also find documentation about the project and related software and information.
If you've been waiting to try ATM on Linux, now is the time to quit waiting and try it out. As for any free software project, participation, feedback, and contribution are welcomed by the development team. Join the mailing list by sending a message containing "subscribe linux-atm" to firstname.lastname@example.org and join in the fun.
Terry Dawson is the author of a number of network-related HOWTO documents for the Linux Documentation Project, a co-author of the 2nd edition of O'Reilly's Linux Network Administrators Guide, and is an active participant in a number of other Linux projects.
Read more Linux Network Administration columns.
Discuss this article in the O'Reilly Network Linux Forum.
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.