Frames And Cells: What's The Difference?
There are two basic types of switches in the world of ATM: frame switches and cell switches. They are very different internally, and their internal architecture can have a serious impact on your network.
In a cell switch, data coming into every switch port is passed through a segmentation-and-reassembly (SAR) chip, where the packets are converted from frames into cells. These cells are then shoved onto the backplane of the switch, where they can be forwarded to their destination. In contrast, a frame switch takes in packet
s from its switch ports and passes them into an ASIC or other packet-processing hardware, where they are forwarded to their destination.
The big difference between the two devices is the location of the bottleneck. In a cell switch, the speed of the SAR chip is the primary limitation of the switch. A secondary limitation in the cell-based architecture regards how much memory the SAR chip can address. Since everything is framed in smaller cell-based units, the buffers for a cell switch tend to be smaller, but the need for them is lessened.
The advantage of a cell switch is its backplane is passive and simple to build; it deals with only one type of object: the cell.
In contrast, a frame switch is limited by the ASIC, which processes the frames on the backplane. Frame switches generally have more complex backplanes and larger buffers, which may increase production costs.
The primary advantage of a frame switch is there are plenty
of ASICs that implement the technology, so development costs tend to be less. In addition, SAR chips are usually expensive to design and manufacture, and the frame switch needs only one for each ATM port, while the cell switch needs one for each port that must be translated into cells.
Which device is
better? The answer depends on your environment. If large numbers of small packets proliferate on your network, a frame switch may start dropping cells. On the other hand, if your network is overburdened with large packets, a cell switch may have a hard time keeping up with the traffic. If the switch is well designed, neither type should show significant degradation with normal network traffic.
At the University of Wisconsin lab in Madison, we analyzed a typical FDDI backbone running IP with no IP fragmentation and IPX, and noted the traffic distribution depicted (see chart, above left). If you assume the average segment runs at 30 percent utilization during the day, then for each 100-Mbps port installed
in a frame switch, you would want about 20,000 packets per second (pps) of throughput. If you expect more traffic, then you would need to adjust that percentage accordingly.
At The Edge With ATM: How We Tested
The goal of our benchmarks was to demonstrate how well ATM edge switches work in a multihomed, load-balanced ATM environment. We tested 3Com Corp., Bay Networks and FORE Systems devices in both single-vendor and multivendor environments.
The switches we tested are marketed as high-bandwidth solutions for the edge or back end of an ATM network. At the edge, these devices support 48 or more 10BASE-T Ethernets, and at least two OC-3 155-Mbps uplinks. Alternatively, they can be configured for at least eight 100BASE-TX switched ports, which are appropriate for file servers or high-performance workstations. We benchmarked the boxes in both scenarios using Netcom Systems' SmartBits traffic analyzers, for a total of 40 analyzer ports. We measured performance using the S
mart Applications benchmark portion of SmartBits. We also tested each switch's ability to recover from a link failure. Finally, we investigated interoperability issues among the three vendors' products. The charts below and right show how well each switch performed.
Using a SmartBits analyzer to measure through
put is one way to see how much juice an ATM edge switch has. However, you should keep in mind that traditional network traffic will never consist of 100 percent unidirectional traffic, nor will it consist of packets with identical sizes (see "Frames and Cells: What's the Difference"). For our tests, we set up 20 streams from Switch A through a 3Com CELLplex 7000 and out to Switch B (see diagram at left). We measured performance as a percentage of maximum packets per second (pps). We also looked at how efficiently the ATM edge device was loading the dual OC-3 pipes.
To test fail-over capability, we used the SmartBits traffic analyzer to generate 1,518-byte packet load cells at 25 percent of maxi
mum rate. We set up two of these load streams in each direction, and then attached a pair of workstations to the switched network. Using TCP/IP ping packets, we observed how long it took the ATM edge device to recover from pulling out the active OC-3 connection.
When it came to testing interoperability, we tried to use every device on the edge of the other devices in the network--with the exception that FORE Systems' equipment was tested with a FORE ASX-200BX ATM switch.
The results explain themselves; ATM devices, though standards based, need some work to be 100 percent hassle-free and user-friendly. After six days of trying to get these devices to work, with some of the best engineers from each company on site, we were unable to get a few combinations to work. FORE Systems acknowledged a bug in its latest beta version of code that caused a lack of interoperability with the Centillion 100. We were unable to get the 3Com CELLplex 7000 to use the LAN Emulation services on the Centillion 100.
Perfor
mance was measured in maximum percentage of traffic passed on one link versus two, for varying numbers of Ethernet and Fast Ethernet streams. The performance charts depict how well each vendor deals with high-volume traffic as generated by the SmartBits analyzer.
We'd like to thank Netcom Systems for providing the Sm
artBits analyzer used during our tests, and LANCAST for providing us with Media Independent Interface (MII)-to-100BASE-FX Fast Ethernet transceivers for the SmartBits analyzer.
To download an Adobe Acrobat .pdf format version of the "How We Tested" sidebar, complete with graphics, click here.
|
REPORTS
ANALYTICS
Follow 
