Test network components from the bottom up

Switches and access devices need testing from the physical layer through the application layer.

Martin Rowe, Senior Technical Editor -- Test & Measurement World, 4/1/2001

Verifying the design of network components is quite different from testing the networks themselves. Network engineers test from the top down. If they encounter a problem, they look only as far down the Open Systems Interconnection (OSI) protocol stack as needed to locate it. In contrast, engineers who design and test network components in the lab start testing at the physical layer and work up to the application layer.

In my March article, “Networks converge,” I described a network that carries voice, data, and video encapsulated into Internet Protocol (IP) packets that in turn ride in asynchronous transfer mode (ATM) cells over physical interfaces such as T1, DS3, and OC-12 (Ref. 1). To test network components, you must begin at their transmitters and receivers and measure signal shape, jitter, and bit error rate (BER). To start your tests, you need to capture waveforms that represent bits with a digital oscilloscope and compare the waveforms to masks (Ref. 2).

Electrical and optical signals are based on standards that define the limits of bit-signal shapes (Ref. 3). Many digital scopes have mask test options for standard telecom signals. If the waveform exceeds limits defined by the mask, it may indicate that the line-driver ICs in your physical interface aren’t the right parts for the job.

The signals that traverse a network need clock synchronization. So, a network component must extract a clock signal from the received data stream. Jitter on the extracted clock has a direct effect on how well the switch, digital subscriber line access multiplexer (DSLAM), or integrated access device (IAD) can send and receive bits.

Figure 1. Eye masks define the limits of acceptable clock jitter. Courtesy of LeCroy .

Eye diagrams let you see the effects of clock jitter. The blue hexagon in the center of Figure 1 marks the smallest acceptable eye opening for an OC-12 optical signal. You might observe this 622-Mbps signal running between ATM switches in a core transport network. In Figure 1, the signal is well outside its minimum eye opening.

In a data stream with more clock jitter, the scope traces will appear wider, resulting in a smaller eye opening, one that’s closer to the mask limit. Think of the signal trace as the iris of your eye where brighter light makes the iris appear larger than it appears in dim light. In an eye diagram, if the waveform infringes on the hexagon, then a receiver may interpret a bit incorrectly or lose clock synchronization.

If the received signals fall within eye masks and bit masks, then you know you’ve designed the line interface properly. Otherwise, you may need a more stable clock or a different line driver IC.

Once you’re convinced that a network component can send and receive bits within specifications, you can move to BER tests. Start with loopback tests between the switch under test and a BER tester. To perform a loopback test, connect a BER tester to the input of a line-interface card and measure the card’s output characteristics. If the test results show that the BER is within the product’s design specifications, you should daisy-chain more line cards to the BER tester. Increase bit rates until the BER exceeds acceptable limits. This test will tell you how well the line-interface cards perform under high traffic conditions, and it will help you decide if the card will function properly in a live network.

Proceed upward

After you’ve proven the integrity of the waveforms and demonstrated acceptable BER, you can move to testing of structured bits. Layer 2 protocols such as ATM bring order to the bits by placing them into cells. Testing at layer 2, the Data Link Layer, involves protocol analysis. Many converged networks segment their traffic into ATM cells, which carry packets and frames from the higher layers.

Before an ATM-based network can transport cells, its components must establish a call. When establishing a call across a network, the network components negotiate with each other for bandwidth and switching sequences. Exercising an ATM-based device’s call setup and breakdown abilities tests the protocol’s user-network interface (UNI) and private network-to-network interface (PNNI) sublayers. When testing a DSLAM, edge switch, ATM switch, or IP services switch, you must verify that your switch will communicate with other network components.

Using an ATM generator and analyzer, you should generate calls that test a network component’s UNI and PNNI sublayers. Edge switches, which aggregate and segment traffic from other networks into ATM cells for transport, use the ATM protocol’s UNI sublayer to convert other protocols such as Ethernet or Frame Relay into ATM.

When testing any network component that carries ATM cells, you must verify that the component can properly segment and reassemble its payloads. Start by using an ATM network simulator, which lets you control how many switches are in your “network.” If your UUT doesn’t send cells across a network, it could indicate a software problem in the code that implements ATM in your device.

ATM-based switches use the protocol’s UNI and PNNI sublayers to negotiate a quality of service (QoS) agreement across a network. Cells that carry voice or video, for example, get a higher priority than cells carrying data files. To maintain that priority, ATM switches can “police” the network and adjust their cell transmit rate to maintain QoS agreements. If cells are coming into an ATM switch too quickly, the switch will drop cells to protect the upstream switches. Because the 48-byte payload of an ATM cell carries just a small portion of a layer-3 IP packet, one dropped cell can corrupt an entire IP frame.

Figure 2. Protocol analyzers decode transmissions into their respective protocols.

Figure 2 shows a protocol analyzer display; you can see that transmission control protocol (TCP) frames, a layer 4 protocol, are encapsulated into IP packets that are segmented into ATM cells. The TCP stack will force a retransmission of a corrupted IP packet. In a retransmission, the network must resend an entire IP packet when as little as 48 bytes (one ATM cell payload) of the original packet (up to 65,535 bytes) may have been corrupted.

The retransmission greatly reduces usable throughput of a network. A little congestion at the ATM layer can cause IP traffic to drop to nearly zero. Therefore, you must use an ATM analyzer to measure dropped cells across a switch or DSLAM while testing it with simulated traffic. Connect the ATM analyzer across the ingress (input) and egress (output) of your UUT. The analyzer will tell you if errors introduced in your device violate the QoS agreement.  

Mike Ott, director of product management at Oresis Communications (Beaverton, OR), recommends you create cells with bit errors and see how well an ATM device adheres to its QoS contract. ATM test equipment should verify that an ATM switch assigns a constant bit rate (CBR) quality to voice and video traffic while data can use variable bit rate (VBR) quality as part of its QoS agreements with the network’s other switches. Cell delay variation tells you how much an ATM network component stresses other ATM network components. ATM network emulators let you inject cell errors. Look at the results in the IP layer to see how many IP frames get corrupted.

Measure parameters such as framing errors and severely errored seconds. Inject noise into the system to test the system’s ability to recover from errors. Test the interface card’s IC line drivers with realistic cable lengths. Ott recommends about 900 ft of electrical or optical cable, which is typical in an installation at a telephone company’s central office (CO).

Network components such as edge switches perform internetworking functions. Edge switches convert services such as Frame Relay, ISDN, and ATM on the customer side to ATM on the network side for long-haul transport over a core network. You should connect Frame Relay analyzers, ISDN testers, and ATM analyzers to the switch under test and verify that the edge switch can correctly perform segmentation and reassembly at the switch’s highest rated speed.

Figure 3. You can test a multiservice edge switch’s ability to communicate with other networks by simulating and monitoring traffic through the switch.

Figure 3 shows an internetworking test configuration diagram, and Figure 4 shows a lab test setup. The switch under test (middle rack) in Figure 4 is an Oresis Communications ISIS-700. The test setup uses two Acterna (formerly TTC) FireBerd frame-relay analyzers on the left of the switch. On the right is an ATM analyzer from Spirent Communications—Adtech. In the lower left corner is a Digital Lightwave field tester that generates ATM cells over SONET, DS1, and DS3 interfaces. The test rack also consists of several patch panels that let engineers connect the switch’s line cards to test equipment and other network components.

Engineers at Oresis use the test setup to perform BER tests, QoS tests, and internetworking tests. As part of the tests, the engineers test the edge switch for memory leaks. Memory leaks can occur when a switch, DSLAM, or IAD establishes a connection, or call, between two points. Each call uses memory in each network component. When the call terminates, the component should release all of the memory it allocated to the call so the memory becomes available to other calls. 

Waiting for a crash isn’t the only way to test for memory leaks, though. Network components often have management software applications that include diagnostics for their products. Those diagnostic routines can keep track of available system resources. If you’re involved in testing network components, make sure your software engineers write diagnostic code for lab use. That code needn’t go into the final shipping product, but you should use it for design verification. If available memory steadily declines as calls originate and terminate, then the switch’s internal software has a bug.

Switches often have provisions for reporting fault conditions. Most switches have a configuration port that lets you configure the switch with a PC through either a graphical or command-line interface. The switch can report fault conditions to the PC. When you test a switch, program it to report faults such as lost ATM cells. You should also program the switch to generate alarms on failures.

The switch can report the probable cause of an error. For example, if the switch discovers corrupted IP frames, the error message can point you to the ATM layer (layer 2) or the physical layer. If the problem is at the physical layer, you’ll need to perform a BER test to find a bad line or a bad interface card.

Jump to the top

Many of the applications that converged networks carry, such as transporting pages or files or carrying voice, reside in layer 7—the applications layer. These applications ride directly on top of TCP, at layer 4. As a result, network testing often jumps from layer 4 to layer 7 because few protocols fall in layers 5 and 6. In an IP network (even if ATM carries IP packets), layer 7 contains protocols such as hypertext transfer protocol (HTTP) or file transfer protocol (FTP) for data transmissions and H.323 for voice transmissions. At the top of the protocol stack, testing turns more functional than at lower layers.

When testing at the application layer, you must generate enough voice, video, and data traffic to fully test the device. You can test an access device or switch by forcing FTP downloads of megabyte-size files. At the same time, you can send voice calls through the device and measure the audio and video quality. Be sure to vary the speed and types of traffic you send through the switch. Add cell delays with an ATM analyzer and monitor an application’s performance. If you find application problems, then you must drill down through the layers to find the cause.

When you test voice transmissions and the protocols that carry them, you must test audio quality. The converged network may replace the public switched telephone network (PSTN) for carrying voice calls, but first it must transmit and receive audio calls with the same or better quality than the PSTN provides. Because the converged network transmits audio in packets rather than in switched connections, it has more opportunities to introduce audio problems. Audio testing at the application layer is still evolving. New methods for quantifying voice quality have emerged and more are in development.

Perceptual speech quality measure (PSQM) is the de facto standard for voice-quality testing of packet networks, according to Rob Brown, senior network architect at Sedona Networks (Kanata, ON, Canada). In a PSQM test, you send a sound file through a network and measure the sound quality at the other end. The software that analyzes the received sound assigns it a value between 0 and 6.5, with 0 representing a perfect match to the original sound. According to Brown, Sedona’s customers insist the company perform PSQM tests on its IADs and switches. While other test methods exist, Brown believes that PSQM’s head start will make it difficult to replace.

Others disagree. Another voice-quality standard, perceptual analysis/measurement system (PAMS) is making headway, according to Oded Agam, vice president of testing solutions at RadCom (Paramus, NJ). PAMS—developed by British Telecom—uses a different algorithm than PSQM (Ref. 4). Like PSQM, PAMS compares received audio to its source, but PAMS also can provide information that points to the source of poor audio quality. Agam said he expects PAMS to replace PSQM as the standard for testing audio quality in packet networks. He said he thinks PAMS will eventually be superceded by perceptual evaluation of speech quality (PESQ), another audio testing algorithm on the horizon.

Right now, PESQ is an ITU-T draft document (P.862) and isn’t available to the public. To learn about PESQ, you can order a copy of “PESQ—The New ITU Standard for End-to-End Speech Quality Assessment,” from the Audio Engineering Society (Ref. 5).

Simulate your customers

Voice, video, and data originate in computers, phones, and video servers. In a converged network, a small business may install an IAD to connect phones and computers to the access. An IAD can connect POTS, Ethernet, and T1 lines to a CO, usually over a DSL or T1 connection.

To test IADs, you’ll need several test-equipment configurations. Start by testing data transmissions before moving to voice. A data simulator can generate IP packets for the IAD’s Ethernet interface, then extract the IP packets from the ATM cells in the IAD’s T1 network interface.

Figure 5. To test an IAD’s DSL loop, connect it to a DSLAM through a line simulator. Monitor the data on both sides of the IAD with protocol analyzers.

Use a protocol analyzer to measure how many IP packets get lost through the IAD. Then, look at TCP retransmissions. Use a line simulator to add noise and other impairments to the DSL or T1 line, the IAD’s network connection. When testing the IAD’s DSL network connection (Figure 5), add a DSLAM to demodulate the DSL traffic to ATM traffic. Manufacturers of IADs, DSLAMs, and stand-alone DSL modems perform several physical-layer tests. The tests include spectral power, noise ratio, cross modulation, frequency response, and a control interface test. The article “ADSL Testing Moves Out of the Lab” (Ref. 6) describes these tests and provides more references.

When testing voice traffic through an IAD, you’ll need to add a known-working voice gateway to the DSLAM’s network interface. The voice gateway in Figure 3 produces voice signals you can then analyze with a voice-quality tester. The voice-quality tester should generate digitized voice signals that travel over a T1 line on the IAD’s customer side. The test simulates traffic over a private branch exchange (PBX).

After you verify that the IAD can pass voice and data, you need to stress the device. Simulate as many calls as possible over the plain old telephone service (POTS), T1, and Ethernet customer connections. According to Sedona’s Brown, fax calls over a POTS line more strenuously test an IAD than voice calls. Voice calls have silent spots and the IAD may use silence suppression to compress the audio into fewer bits. Fax calls have no silent periods, so they require more network bandwidth. At the same time you run the fax calls, transfer large data files (several megabytes) through the IAD.

Testing network components such as IADs, DSLAMs, and switches requires you to work through the protocol stack from the bottom up. Simulate heavy traffic in the lab, and you’ll eliminate bugs before production. Test your product under as many error conditions as possible to increase your confidence in your product before you test it on real-world networks. T&MW

References

1. Rowe, Martin, “Networks converge,” Test & Measurement World, March 2001. p. 16.

2. Rowe, Martin, “Pulse Masks Define Signal Limits,” Test & Measurement World, September 1999. p. 15.

3. Freeman, Roger L., Reference Manual for Telecommunications Engineering, 2nd ed., Chapter 7: Multiplexing Techniques, New York, John Wiley & Sons, 1994.

4. White Paper: “Using PSQM to Test Packetized Speech,” Spirent Communications-Zarak Systems, 2000. www.psqm.com.

5. Rix, Anthony W., Michael P. Hollier, John G. Beerends, and Andries P. Hekstra, “PESQ—The New ITU Standard for End-to-End Speech Quality Assessment,” preprint number 5260, AES 109th Convention, Audio Engineering Society, New York, NY. www.aes.org/publications/preprints/search.html.

6. Rowe, Martin, “ADSL Testing Moves Out of the Lab,” Test & Measurement World, April 1999. p. 46.  

For further reading

Acterna has application notes pertaining to testing DSL, ATM, Frame Relay, ISDN, and VoIP networks at www.acterna.com/technical_resources. Click on “App Notes” for testing or “White Papers” for technology overviews.

“Evaluating ATM Switch Performance Using the HP E5200A Broadband Service Analyzer,” Application note, Agilent Technologies, Santa Clara, CA, November 1996. www.educatorscorner.com/tools/lectures/appnotes/pdf. The site also contains links to other telecom-related application notes. Editor's Note 10/24/03: This site is no longer available.

RadCom has several application notes on ATM testing. See www.radcom.com/radcom/technlgy/tech.htm. Editor's Note 10/24/03: This page has moved: http://www.radcom.com/radcom/test/atm.htm.

Martin Rowe has a BSEE from Worcester Polytechnic Institute and an MBA from Bentley College. Before joining T&MW in 1992, he worked for 12 years as a design engineer for manufacturers of semiconductor process equipment and as an applications engineer for manufacturers of measurement and control equipment. E-mail: m.rowe@tmworld.com.