旧版广域网测试方法RFC1944

Network Working Group S. Bradner

Request for Comments: 1944 Harvard University

Category: Informational J. McQuaid

Bay Networks

May 1996

Benchmarking Methodology for Network Interconnect Devices

Status of This Memo

This memo provides information for the Internet community. This memo

does not specify an Internet standard of any kind. Distribution of

the tests. Appendix A lists the tests and conditions that we believe

should be included for specific cases and gives additional

information about testing practices. Appendix B is a reference

listing of maximum frame rates to be used with specific frame sizes

on various media and Appendix C gives some examples of frame formats

to be used in testing.

1. Introduction

Vendors often engage in "specsmanship" in an attempt to give their

products a better position in the marketplace. This often involves

"smoke & mirrors" to confuse the potential users of the products.

used in this document. The terminology document should be consulted

before attempting to make use of this document.

Bradner & McQuaid Informational [Page 1]

RFC 1944 Benchmarking Methodology May 1996

2. Real world

In producing this document the authors attempted to keep in mind the

requirement that apparatus to perform the described tests must

actually be built. We do not know of "off the shelf" equipment

available to implement all of the tests but it is our opinion that

such equipment can be constructed.

3. Tests to be run

There are a number of tests described in this document. Not all of

the tests apply to all types of devices under test (DUTs). Vendors

should perform all of the tests that can be supported by a specific

type of product. The authors understand that it will take a

considerable period of time to perform all of the recommended tests

are worth the effort. Appendix A lists some of the tests and

devices under each circumstance. For example, the rate at which a

router forwards IPX frames will be of little use in selecting a

router for an environment that does not (and will not) support that

protocol. Evaluating even that data which is relevant to a

particular network installation will require experience which may not

be readily available. Furthermore, selection of the tests to be run

and evaluation of the test data must be done with an understanding of

generally accepted testing practices regarding repeatability,

5. Requirements

item, but the full implications should be understood and the case

carefully weighed before choosing a different course.

RFC 1944 Benchmarking Methodology May 1996

a particular marketplace requires it or because it enhances the

An implementation is not compliant if it fails to satisfy one or more

of the MUST requirements for the protocols it implements. An

implementation that satisfies all the MUST and all the SHOULD

requirements for its protocols is said to be "unconditionally

compliant"; one that satisfies all the MUST requirements but not all

the SHOULD requirements for its protocols is said to be

"conditionally compliant".

6. Test set up

The ideal way to implement this series of tests is to use a tester

with both transmitting and receiving ports. Connections are made

DUT and from the sending ports of the DUT back to the tester. (see

it back, after the traffic has been forwarded but the DUT, the tester

controlled by some computer in a way that simulates the single

tester, the labor required to accurately perform some of the tests

(particularly the throughput test) can be prohibitive.

+------------+

| |

+------------| tester |<-------------+

| | | |

| |

| +------------+ |

| | | |

+--------+ +------------+ +----------+

| | | | | |

+--------+ +------------+ +----------+

Figure 2

RFC 1944 Benchmarking Methodology May 1996

6.1 Test set up for multiple media types

Two different setups could be used to test a DUT which is used in

real-world networks to connect networks of differing media type,

local Ethernet to a backbone FDDI ring for example. The tester could

support both media types in which case the set up shown in Figure 1

would be used.

Two identical DUTs are used in the other test set up. (see Figure 3)

In many cases this set up may more accurately simulate the real

world. For example, connecting two LANs together with a WAN link or

high speed backbone. This set up would not be as good at simulating

a system where clients on a Ethernet LAN were interacting with a

server on an FDDI backbone.

| |

| | | |

+------->| DUT 1 |-------------->| DUT 2 |---------+

| | | |

+----------+ +----------+

Figure 3

7. DUT set up

configured following the instructions provided to the user.

Specifically, it is expected that all of the supported protocols will

be configured and enabled during this set up (See Appendix A). It is

throughput of that protocol. It is necessary to modify the

filter. The DUT set up SHOULD include the normally recommended

routing update intervals and keep alive frequency. The specific

version of the software and the exact DUT configuration, including

RFC 1944 Benchmarking Methodology May 1996

8. Frame formats

The formats of the test frames to use for TCP/IP over Ethernet are

shown in Appendix C: Test Frame Formats. These exact frame formats

SHOULD be used in the tests described in this document for this

protocol/media combination and that these frames will be used as a

template for testing other protocol/media combinations. The specific

formats that are used to define the test frames for a particular test

series MUST be included in the report of the results.

9. Frame sizes

All of the described tests SHOULD be performed at a number of frame

sizes. Specifically, the sizes SHOULD include the maximum and minimum

legitimate sizes for the protocol under test on the media under test

of the DUT performance. Except where noted, at least five frame

length field in the IP header. In almost all cases the actual

maximum and minimum sizes are determined by the limitations of the

media.

In theory it would be ideal to distribute the frame sizes in a way

that would evenly distribute the theoretical frame rates. These

recommendations incorporate this theory but specify frame sizes which

are easy to understand and remember. In addition, many of the same

easy performance comparisons.

Note: The inclusion of an unrealistically small frame size on some of

64, 128, 256, 512, 1024, 1280, 1518

by the Ethernet standard and a selection of sizes between these

extremes with a finer granularity for the smaller frame sizes and

higher frame rates.