ATM Testing Evolves to Measure Real-World Applications

Now that ATM has evolved from a concept to a shipping product, the emphasis of ATM testing has shifted from the cell layer to the packet layer. The reason for this change—packet-layer testing primarily analyzes the software on the ATM network that must be continually upgraded to accommodate new standards.

Cell-layer testing verifies and quantifies the transmission of cells across an ATM network. Because most of the cell-layer functions (switching, transport, packet assembly/disassembly) are accomplished in hardware, developers must optimize performance before committing to a particular design. This explains the early predominance of cell-layer testing. Higher-layer functionality cannot be tested until the hardware is available.

Packet-layer testing primarily analyzes the applications (software) running over an ATM network. When cells arrive at their destination, the ATM hardware reassembles them into packets according to one of the ATM adaptation layers. The resulting packet may be a high-level data structure such as an IP or IPX packet or an instruction to the ATM device such as an SVC setup message.

Software residing in the ATM device evaluates and processes these packets. Packet-layer testing verifies that the packets received conform to existing standards and optimizes the performance of the software.

The emphasis in ATM testing is shifting from the cell layer to the packet layer because, once the hardware is complete, the cell-layer capabilities of the device are largely fixed. The software must be upgraded continually to accommodate new standards and to improve the performance of ATM applications.

The importance of packet-layer testing is reinforced by the relative performance of the cell and packet layers. One of the most important features of ATM is the capability to create connections on demand (SVCs). The establishment and removal of these circuits are packet-layer functions of an ATM switch.

The cell delay through an ATM switch typically is measured in tens of microseconds. In contrast, the call setup time (the time required to establish a new SVC across the switch) is typically measured in tens (or hundreds) of milliseconds, an order of magnitude difference. Because of this, the performance of the packet layer is often more critical than that of the cell layer in determining the suitability of ATM for a particular application.

Another factor driving packet-level testing is the introduction of ATM into the end-user community. End users primarily are concerned with managing and troubleshooting their networks to ensure continued optimal operation.

Packet-level testing provides tools similar to those currently used with traditional WANs and LANs. Large end users and early adopters also may wish to test the relative performance of equipment from a variety of vendors and will require tools similar to those used by the developers.

Cell-Layer Testing

Cell-level testing is most important for determining the underlying performance of an ATM device. Developers use it to validate their designs and end users to evaluate the suitability of an ATM device to their needs.

Basic Operational Testing at the Cell Layer

As with any network, it must reliably deliver from the source to the destinations. The capability to verify that cells are correctly formatted and directed through an ATM network is the most basic test. It is of interest to developers during the earliest stage of design and to production to verify the basic functionality of an ATM device before shipping it to a customer.

Quality of Service

The QoS of an ATM connection defines its loss and delay parameters. The capabilities of an ATM device to specify and adhere to these parameters determine how well it transports different types of information such as voice, video, and computer data. These tests are important to developers benchmarking the performance of the equipment, service providers ensuring they can meet their customers needs, and end users evaluating the suitability of a particular product to their needs.

Packet-Layer Testing

Packet-layer testing is needed to evaluate, manage, and troubleshoot the interaction of ATM devices with each other and with new and existing applications.

Conformance Testing

The ATM standards bodies have a wide variety of protocols to define the services provided by ATM. These include encapsulation protocols such as RFC 1487 (multiprotocol encapsulation over ATM) and RFC 1577 (Classical IP and ARP over ATM); switching protocols such as UNI, IISP, PNNI, and B-ICI; and service protocols such as LANE and MPOA. An ATM device supporting any of these protocols must conform to the rules governing the formatting of the messages for each of these protocols and to the rules governing the interaction of these messages.

Two classes of tools perform conformance testing: analyzers and simulators. Analyzers are placed between two ATM devices to monitor the cells exchanged between them. These cells are then reassembled to the packet layer and decoded according to the appropriate standard. Then you can evaluate the structure of the messages and the interaction between the two devices.

Simulators connect to a single ATM device and interact with it using the protocol being tested. This provides a benchmark for evaluating the conformance of a device against a single known device and controls the introduction of errors to perform negative testing.

Conformance testing primarily is performed by developers to test products prior to field trials. Large end users and early adopters also may perform conformance testing to ensure that the equipment they select will operate in their production network.

Performance Testing

Most ATM applications require the ATM device to process some of the data passing though it. Examples include a switch establishing SVCs in response to user requests received on the signaling channel, an LEC joining an emulated LAN, or an ATM router updating its tables based upon the messages it receives from other stations. Since processing packets is much more time-consuming than processing cells, the packet performance of an ATM device is critical in evaluating its performance.

Typical performance tests might include:

How many calls per second an ATM switch can accommodate (Figure 1).

How many open calls it can sustain.

How long it takes for an LEC to join an emulated LAN.

How much bandwidth maintenance packets, such as signaling messages, Q.SAAL, and ILMI routing protocols, consume. As with conformance testing, both simulation and analysis tools may be used. Analyzers evaluate the performance achieved by two connected devices in a live network. Simulation tools determine the performance boundaries under various load conditions.

Performance testing is primarily interesting to developers evaluating the performance of their devices and to large end users determining the best equipment for their needs.

Troubleshooting and Management

Production networks are dynamic entities constantly adding new users and services. The effect of these changes must be monitored to prevent unacceptable service degradation and to forestall any operational problems. This function requires analysis tools to monitor the volume of different types of traffic on the network and to evaluate operational performance.

Despite the best management efforts, it is almost inevitable that things will occasionally go wrong with any network. These problems may result from failures or incompatibilities at any layer of the OSI stack.

To effectively troubleshoot an ATM network, examine the operation of the network at each of these layers. Since ATM networks will be used for legacy data traffic as well as ATM-specific functions, ATM analyzers must provide all of the functionality of traditional WAN/LAN analyzers along with support for ATM specific protocols and applications.

Since the cell is the fundamental building block of ATM, the need for cell-layer test sets is always present, particularly in the area of QoS measurements. However, the need for packet level is becoming far more important as additional ATM standards and applications are developed and as ATM migrates into operational networks.

Real-Time Decoding

Most ATM networks will be connected to a legacy LAN running traditional protocols, such as TCP/IP IPX, in addition to the new ATM protocols, such as LANE, PNNI or UNI 3.1. Coupled with the tremendous quantity of information that goes through a single ATM circuit, real-time protocol analysis and filtering provide network managers with an essential tool for solving problems and fine-tuning a network. It allows them to pinpoint and capture specific information easily and quickly (Figure 2).

About the Authors

Avi Zamir joined Radcom as president in 1992. From 1985 to 1992, he was director of engineering for RAD Data Communications and previously was one of that company’s first design engineers. Mr. Zamir has a practical engineering degree from Yad-Singalovski, Tel Aviv.

Fred R. Cerequas has been the director of technical support at Radcom since 1993. Before joining Radcom, he was a telecommunications consultant in New York City for eight years. Mr. Cerequas earned a B.S.E.E. degree from Stevens Institute.

Radcom Equipment, 900 Corporate Dr., Mahwah, NJ 07430, (201) 529-2020.

Sidebar

Glossary

ATM: Asynchronous Transfer Mode

ARP: Address Resolution Protocol

B-ICI: B-ISDN Inter-Carrier Interface

IISP: Information Infrastructure Standards Panel, ANSI

ILMI: Interim Link Management Interface

IP: Internet Protocol

IPX: Novel Internetwork Packet Exchange

LAN: Local Area Network

LANE: LAN Emulation