Building Confidence in Your Network Design

Network designers frequently are called upon to maximize the performance of their networks, yet they often do not have a clear, consistent methodology or the proper equipment for measuring this performance. The situation quickly becomes exacerbated, not to mention expensive, when network problems crop up after deployment.

Ideally, you should be able to identify and isolate potential problems in the design and evaluation stage of network development. This predeployment approach to network optimization would go a long way toward eliminating rude surprises and angry phone calls at the help desk.

However, the process of devising a set of parametric tests and creating the equipment for measuring performance often is beyond the capabilities and scope of duties for the typical network designer. Fortunately, a number of companies specialize in the development of network performance measurement equipment.

Additionally, many industry-recognized methodologies can be used to provide a set of fair and consistent tests across a wide variety of network vendors’ equipment. The combination of equipment and methodologies provides a complete answer for anyone who needs fair and accurate network performance measurement.

Test Objectives

Stated simply, the objective of any test is to justify confidence in the network design. To qualify the validity of a set of tests, engineers must ensure that they test against the anticipated failure modes. This requires them to logically analyze the network design for potential errors and come up with a set of specific test methodologies.

Since there are nearly an infinite number of network topologies, it is impractical to devise a set of industry-standard tests to address each topology. Instead, the Internet Engineering Task Force (IETF) has produced a set of requests for comment (RFCs) that addresses a wide range of testing issues down to the resolution of a network test element. At this level, it is anticipated that all network elements, such as switches and routers, hold similar objectives and can be tested with a common methodology.

In general, network test methodologies consist of the following categories:

• Throughput—The device under test (DUT) must faithfully deliver all frames of information to the proper destination.
• Latency—The DUT must deliver frames of information within a reasonable period of time.
• Jitter—The variation in latency over time, also known as latency jitter, must be bound to predictable limits.
• Integrity—The DUT must deliver its frames without corrupting any of the contents.
• Order—The DUT may have restrictions on whether or not frames of information can be re-ordered as they traverse the system.
• Priority—The DUT may have to prioritize different types of frames so that only lower priority frames are dropped during times of peak congestion.

This list is not exhaustive. It simply addresses test objectives for some of the more common network errors.

To test against these categories, use test equipment that can operate beyond the limits of the DUT. This eliminates doubt about whether any anomalies were due to the DUT or the test equipment itself.

It rapidly becomes clear that the test equipment must consist of specially designed hardware created for the specific purpose of testing network equipment. In other words, a network interface card (NIC) in a PC simply won’t have the capacity to sufficiently test a DUT with the desired margin.

To address the test categories, the test equipment must be capable of the following:

1. Generate frames at speeds at or above the theoretical maximum for the media over which the test is being conducted, count incoming frames from the DUT, and ensure that all transmitted frames have been received.
2. Insert an accurate time-stamp into the data portion of transmitted frames, receive and analyze time-stamp information embedded in received frames, and calculate the corresponding latency.
3. Compile latency statistics from item 2 so that latency variation over time can be illustrated.
4. Within transmitted frames, encapsulate the field(s) inside an envelope with proper error-checking codes. Typically, a cyclic redundancy code (CRC) can be used for this purpose. On received frames, check the error code to ensure that the encapsulated field is uncorrupted.
5. Insert a counter into transmitted frames and check the value of counters in received frames. Inconsistencies in the received count value generally are indicative of problems with frame ordering. Maintain the capability to distinguish between missing frames and frame order errors.
6. Transmit various types of frames with different priorities. For example, this may be accomplished by altering type-of-service (TOS) bits in an Internet protocol (IP) header. Intentionally overwhelm the DUT with such traffic, forcing it to engineer its traffic according to frame priorities. Separate incoming frames from the DUT based on priority. Count frames associated with each priority to determine whether or not the DUT correctly engineered the traffic.

These objectives place some challenging requirements on the design of the associated test equipment. Consider that each frame must be created and analyzed in real time. Also consider that today’s optical networks are running at speeds up to and beyond 10 Gb/s. Even at 10-Mb local area network (LAN) speeds, you would need to create and analyze frames at speeds beyond 14,000 frames/s.

The trend among test-equipment vendors is to make use of field programmable gate arrays (FPGA) that can be programmed on the fly to generate and analyze traffic at the required speeds. Since these FPGAs are field programmable, they can be reprogrammed onsite for custom applications. Finally, software for such systems generally allows network designers to execute industry-standard methodologies as well as customize the operation to address any special testing needs as required by an implementation.

Examples

Figure 1 (see below) depicts a typical test scenario where the throughput of a Layer 3 DUT is determined. This figure itself is very simple because the test equipment plays both ends of the field, such as submitting frames on one side and collecting frames on the other side.

Figure 1. A simple test setup for qualifying a single network element.