home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1944 < prev    next >
Text File  |  1996-05-17  |  66KB  |  1,684 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         S. Bradner
  8. Request for Comments: 1944                            Harvard University
  9. Category: Informational                                       J. McQuaid
  10.                                                             Bay Networks
  11.                                                                 May 1996
  12.  
  13.  
  14.        Benchmarking Methodology for Network Interconnect Devices
  15.  
  16. Status of This Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This document discusses and defines a number of tests that may be
  25.    used to describe the performance characteristics of a network
  26.    interconnecting  device.  In addition to defining the tests this
  27.    document also describes specific formats for reporting the results of
  28.    the tests.  Appendix A lists the tests and conditions that we believe
  29.    should be included for specific cases and gives additional
  30.    information about testing practices.  Appendix B is a reference
  31.    listing of maximum frame rates to be used with specific frame sizes
  32.    on various media and Appendix C gives some examples of frame formats
  33.    to be used in testing.
  34.  
  35. 1. Introduction
  36.  
  37.    Vendors often engage in "specsmanship" in an attempt to give their
  38.    products a better position in the marketplace.  This often involves
  39.    "smoke & mirrors" to confuse the potential users of the products.
  40.  
  41.    This document defines a specific set of tests that vendors can use to
  42.    measure and report the performance characteristics of network
  43.    devices.  The results of these tests will provide the user comparable
  44.    data from different vendors with which to evaluate these devices.
  45.  
  46.    A previous document, "Benchmarking Terminology for Network
  47.    Interconnect Devices" (RFC 1242), defined many of the terms that are
  48.    used in this document.  The terminology document should be consulted
  49.    before attempting to make use of this document.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Bradner & McQuaid            Informational                      [Page 1]
  59.  
  60. RFC 1944                Benchmarking Methodology                May 1996
  61.  
  62.  
  63. 2. Real world
  64.  
  65.    In producing this document the authors attempted to keep in mind the
  66.    requirement that apparatus to perform the described tests must
  67.    actually be built.  We do not know of "off the shelf" equipment
  68.    available to implement all of the tests but it is our opinion that
  69.    such equipment can be constructed.
  70.  
  71. 3. Tests to be run
  72.  
  73.    There are a number of tests described in this document.  Not all of
  74.    the tests apply to all types of devices under test (DUTs). Vendors
  75.    should perform all of the tests that can be supported by a specific
  76.    type of product.  The authors understand that it will take a
  77.    considerable period of time to perform all of the recommended tests
  78.    nder  all of the recommended conditions. We believe that the results
  79.    are worth the effort.  Appendix A lists some of the tests and
  80.    conditions that we believe should be included for specific cases.
  81.  
  82. 4. Evaluating the results
  83.  
  84.    Performing all of the recommended tests will result in a great deal
  85.    of data. Much of this data will not apply to the evaluation of the
  86.    devices under each circumstance.  For example, the rate at which a
  87.    router forwards IPX frames will be of little use in selecting a
  88.    router for an environment that does not (and will not) support that
  89.    protocol.  Evaluating even that data which is relevant to a
  90.    particular network installation will require experience which may not
  91.    be readily available. Furthermore, selection of the tests to be run
  92.    and evaluation of the test data must be done with an understanding of
  93.    generally accepted testing practices regarding repeatability,
  94.    variance and statistical significance of small numbers of trials.
  95.  
  96. 5. Requirements
  97.  
  98.    In this document, the words that are used to define the significance
  99.    of each particular requirement are capitalized. These words are:
  100.  
  101.     * "MUST" This word, or the words "REQUIRED" and "SHALL" mean that
  102.    the item is an absolute requirement of the specification.
  103.  
  104.     * "SHOULD" This word or the adjective "RECOMMENDED" means that there
  105.    may exist valid reasons in particular circumstances to ignore this
  106.    item, but the full implications should be understood and the case
  107.    carefully weighed before choosing a different course.
  108.  
  109.     * "MAY" This word or the adjective "OPTIONAL" means that this item
  110.    is truly optional.  One vendor may choose to include the item because
  111.  
  112.  
  113.  
  114. Bradner & McQuaid            Informational                      [Page 2]
  115.  
  116. RFC 1944                Benchmarking Methodology                May 1996
  117.  
  118.  
  119.    a particular marketplace requires it or because it enhances the
  120.    product, for example; another vendor may omit the same item.
  121.  
  122.    An implementation is not compliant if it fails to satisfy one or more
  123.    of the MUST requirements for the protocols it implements.  An
  124.    implementation that satisfies all the MUST and all the SHOULD
  125.    requirements for its protocols is said to be "unconditionally
  126.    compliant"; one that satisfies all the MUST requirements but not all
  127.    the SHOULD requirements for its protocols is said to be
  128.    "conditionally compliant".
  129.  
  130. 6. Test set up
  131.  
  132.    The ideal way to implement this series of tests is to use a tester
  133.    with both transmitting and receiving ports.  Connections are made
  134.    from the sending ports of the tester to the receiving ports of the
  135.    DUT and from the sending ports of the DUT back to the tester. (see
  136.    Figure 1)  Since the tester both sends the test traffic and receives
  137.    it back, after the traffic has been forwarded but the DUT, the tester
  138.    can easily determine if all of the transmitted packets were received
  139.    and verify that the correct packets were received.  The same
  140.    functionality can be obtained with separate transmitting and
  141.    receiving devices (see Figure 2) but unless they are remotely
  142.    controlled by some computer in a way that simulates the single
  143.    tester, the labor required to accurately perform some of the tests
  144.    (particularly the throughput test) can be prohibitive.
  145.  
  146.                             +------------+
  147.                             |            |
  148.                +------------|  tester    |<-------------+
  149.                |            |            |              |
  150.                |            +------------+              |
  151.                |                                        |
  152.                |            +------------+              |
  153.                |            |            |              |
  154.                +----------->|    DUT     |--------------+
  155.                             |            |
  156.                             +------------+
  157.                               Figure 1
  158.  
  159.          +--------+         +------------+          +----------+
  160.          |        |         |            |          |          |
  161.          | sender |-------->|    DUT     |--------->| receiver |
  162.          |        |         |            |          |          |
  163.          +--------+         +------------+          +----------+
  164.                               Figure 2
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Bradner & McQuaid            Informational                      [Page 3]
  171.  
  172. RFC 1944                Benchmarking Methodology                May 1996
  173.  
  174.  
  175. 6.1 Test set up for multiple media types
  176.  
  177.    Two different setups could be used to test a DUT which is used in
  178.    real-world networks to connect networks of differing media type,
  179.    local Ethernet to a backbone FDDI ring for example.  The tester could
  180.    support both media types in which case the set up shown in Figure 1
  181.    would be used.
  182.  
  183.    Two identical DUTs are used in the other test set up. (see Figure 3)
  184.    In many cases this set up may more accurately simulate the real
  185.    world.  For example, connecting two LANs together with a WAN link or
  186.    high speed backbone.  This set up would not be as good at simulating
  187.    a system where clients on a Ethernet LAN were interacting with a
  188.    server on an FDDI backbone.
  189.  
  190.                                +-----------+
  191.                                |           |
  192.          +---------------------|  tester   |<---------------------+
  193.          |                     |           |                      |
  194.          |                     +-----------+                      |
  195.          |                                                        |
  196.          |        +----------+               +----------+         |
  197.          |        |          |               |          |         |
  198.          +------->|  DUT 1   |-------------->|   DUT 2  |---------+
  199.                   |          |               |          |
  200.                   +----------+               +----------+
  201.  
  202.                                   Figure 3
  203.  
  204. 7. DUT set up
  205.  
  206.    Before starting to perform the tests, the DUT to be tested MUST be
  207.    configured following the instructions provided to the user.
  208.    Specifically, it is expected that all of the supported protocols will
  209.    be configured and enabled during this set up (See Appendix A).  It is
  210.    expected that all of the tests will be run without changing the
  211.    configuration or setup of the DUT in any way other than that required
  212.    to do the specific test.  For example, it is not acceptable to change
  213.    the size of frame handling buffers between tests of frame handling
  214.    rates or to disable all but one transport protocol when testing the
  215.    throughput of that protocol.  It is necessary to modify the
  216.    configuration when starting a test to determine the effect of filters
  217.    on throughput, but the only change MUST be to enable the specific
  218.    filter. The DUT set up SHOULD include the normally recommended
  219.    routing update intervals and keep alive frequency.  The specific
  220.    version of the software and the exact DUT configuration, including
  221.    what functions are disabled, used during the tests MUST be included
  222.    as part of the report of the results.
  223.  
  224.  
  225.  
  226. Bradner & McQuaid            Informational                      [Page 4]
  227.  
  228. RFC 1944                Benchmarking Methodology                May 1996
  229.  
  230.  
  231. 8. Frame formats
  232.  
  233.    The formats of the test frames to use for TCP/IP over Ethernet are
  234.    shown in Appendix C: Test Frame Formats.  These exact frame formats
  235.    SHOULD be used in the tests described in this document for this
  236.    protocol/media combination and that these frames will be used as a
  237.    template for testing other protocol/media combinations.  The specific
  238.    formats that are used to define the test frames for a particular test
  239.    series MUST be included in the report of the results.
  240.  
  241. 9. Frame sizes
  242.  
  243.    All of the described tests SHOULD be performed at a number of frame
  244.    sizes. Specifically, the sizes SHOULD include the maximum and minimum
  245.    legitimate sizes for the protocol under test on the media under test
  246.    and enough sizes in between to be able to get a full characterization
  247.    of the DUT performance.  Except where noted, at least five frame
  248.    sizes SHOULD be tested for each test condition.
  249.  
  250.    Theoretically the minimum size UDP Echo request frame would consist
  251.    of an IP header (minimum length 20 octets), a UDP header (8 octets)
  252.    and whatever MAC level header is required by the media in use.  The
  253.    theoretical maximum frame size is determined by the size of the
  254.    length field in the IP header.  In almost all cases the actual
  255.    maximum and minimum sizes are determined by the limitations of the
  256.    media.
  257.  
  258.    In theory it would be ideal to distribute the frame sizes in a way
  259.    that would evenly distribute the theoretical frame rates.  These
  260.    recommendations incorporate this theory but specify frame sizes which
  261.    are easy to understand and remember.  In addition, many of the same
  262.    frame sizes are specified on each of the media types to allow for
  263.    easy performance comparisons.
  264.  
  265.    Note: The inclusion of an unrealistically small frame size on some of
  266.    the media types (i.e. with little or no space for data) is to help
  267.    characterize the per-frame processing overhead of the DUT.
  268.  
  269.    9.1 Frame sizes to be used on Ethernet
  270.  
  271.        64, 128, 256, 512, 1024, 1280, 1518
  272.  
  273.       These sizes include the maximum and minimum frame sizes permitted
  274.       by the Ethernet standard and a selection of sizes between these
  275.       extremes with a finer granularity for the smaller frame sizes and
  276.       higher frame rates.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Bradner & McQuaid            Informational                      [Page 5]
  283.  
  284. RFC 1944                Benchmarking Methodology                May 1996
  285.  
  286.  
  287.    9.2 Frame sizes to be used on 4Mb and 16Mb token ring
  288.  
  289.        54, 64, 128, 256, 1024, 1518, 2048, 4472
  290.  
  291.       The frame size recommendations for token ring assume that there is
  292.       no RIF field in the frames of routed protocols.  A RIF field would
  293.       be present in any direct source route bridge performance test.
  294.       The minimum size frame for UDP on token ring is 54 octets.  The
  295.       maximum size of 4472 octets is recommended for 16Mb token ring
  296.       instead of the theoretical size of 17.9Kb because of the size
  297.       limitations imposed by many token ring interfaces.  The reminder
  298.       of the sizes are selected to permit direct comparisons with other
  299.       types of media.  An IP (i.e. not UDP) frame may be used in
  300.       addition if a higher data rate is desired, in which case the
  301.       minimum frame size is 46 octets.
  302.  
  303.    9.3 Frame sizes to be used on FDDI
  304.  
  305.        54, 64, 128, 256, 1024, 1518, 2048, 4472
  306.  
  307.       The minimum size frame for UDP on FDDI is 53 octets, the minimum
  308.       size of 54 is recommended to allow direct comparison to token ring
  309.       performance.  The maximum size of 4472 is recommended instead of
  310.       the theoretical maximum size of 4500 octets to permit the same
  311.       type of comparison. An IP (i.e. not UDP) frame may be used in
  312.       addition if a higher data rate is desired, in which case the
  313.       minimum frame size is 45 octets.
  314.  
  315.    9.4 Frame sizes in the presence of disparate MTUs
  316.  
  317.       When the interconnect DUT supports connecting links with disparate
  318.       MTUs, the frame sizes for the link with the *larger* MTU SHOULD be
  319.       used, up to the limit of the protocol being tested. If the
  320.       interconnect DUT does not support the fragmenting of frames in the
  321.       presence of MTU mismatch, the forwarding rate for that frame size
  322.       shall be reported as zero.
  323.  
  324.       For example, the test of IP forwarding with a bridge or router
  325.       that joins FDDI and Ethernet should use the frame sizes of FDDI
  326.       when going from the FDDI to the Ethernet link. If the bridge does
  327.       not support IP fragmentation, the forwarding rate for those frames
  328.       too large for Ethernet should be reported as zero.
  329.  
  330. 10. Verifying received frames
  331.  
  332.    The test equipment SHOULD discard any frames received during a test
  333.    run that are not actual forwarded test frames.  For example, keep-
  334.    alive and routing update frames SHOULD NOT be included in the count
  335.  
  336.  
  337.  
  338. Bradner & McQuaid            Informational                      [Page 6]
  339.  
  340. RFC 1944                Benchmarking Methodology                May 1996
  341.  
  342.  
  343.    of received frames.  In any case, the test equipment SHOULD verify
  344.    the length of the received frames and check that they match the
  345.    expected length.
  346.  
  347.    Preferably, the test equipment SHOULD include sequence numbers in the
  348.    transmitted frames and check for these numbers on the received
  349.    frames.  If this is done, the reported results SHOULD include in
  350.    addition to the number of frames dropped, the number of frames that
  351.    were received out of order, the number of duplicate frames received
  352.    and the number of gaps in the received frame numbering sequence.
  353.    This functionality is required for some of the described tests.
  354.  
  355. 11. Modifiers
  356.  
  357.    It might be useful to know the DUT performance under a number of
  358.    conditions; some of these conditions are noted below.  The reported
  359.    results SHOULD include as many of these conditions as the test
  360.    equipment is able to generate.  The suite of tests SHOULD be first
  361.    run without any modifying conditions and then repeated under each of
  362.    the conditions separately.  To preserve the ability to compare the
  363.    results of these tests any frames that are required to generate the
  364.    modifying conditions (management queries for example) will be
  365.    included in the same data stream as the normal test frames in place
  366.    of one of the test frames and not be supplied to the DUT on a
  367.    separate network port.
  368.  
  369.    11.1 Broadcast frames
  370.  
  371.       In most router designs special processing is required when frames
  372.       addressed to the hardware broadcast address are received.  In
  373.       bridges (or in bridge mode on routers) these broadcast frames must
  374.       be flooded to a number of ports.  The stream of test frames SHOULD
  375.       be augmented with 1% frames addressed to the hardware broadcast
  376.       address.  The frames sent to the broadcast address should be of a
  377.       type that the router will not need to process.  The aim of this
  378.       test is to determine if there is any effect on the forwarding rate
  379.       of the other data in the stream.  The specific frames that should
  380.       be used are included in the test frame format document. The
  381.       broadcast frames SHOULD be evenly distributed throughout the data
  382.       stream, for example, every 100th frame.
  383.  
  384.       The same test SHOULD be performed on bridge-like DUTs but in this
  385.       case the broadcast packets will be processed and flooded to all
  386.       outputs.
  387.  
  388.       It is understood that a level of broadcast frames of 1% is much
  389.       higher than many networks experience but, as in drug toxicity
  390.       evaluations, the higher level is required to be able to gage the
  391.  
  392.  
  393.  
  394. Bradner & McQuaid            Informational                      [Page 7]
  395.  
  396. RFC 1944                Benchmarking Methodology                May 1996
  397.  
  398.  
  399.       effect which would otherwise often fall within the normal
  400.       variability of the system performance.  Due to design factors some
  401.       test equipment will not be able to generate a level of alternate
  402.       frames this low.  In these cases the percentage SHOULD be as small
  403.       as the equipment can provide and that the actual level be
  404.       described in the report of the test results.
  405.  
  406.    11.2 Management frames
  407.  
  408.       Most data networks now make use of management protocols such as
  409.       SNMP.  In many environments there can be a number of management
  410.       stations sending queries to the same DUT at the same time.
  411.  
  412.       The stream of test frames SHOULD be augmented with one management
  413.       query as the first frame sent each second during the duration of
  414.       the trial.  The result of the query must fit into one response
  415.       frame. The response frame SHOULD be verified by the test
  416.       equipment. One example of the specific query frame that should be
  417.       used is shown in Appendix C.
  418.  
  419.    11.3 Routing update frames
  420.  
  421.       The processing of dynamic routing protocol updates could have a
  422.       significant impact on the ability of a router to forward data
  423.       frames.  The stream of test frames SHOULD be augmented with one
  424.       routing update frame transmitted as the first frame transmitted
  425.       during the trial.  Routing update frames SHOULD be sent at the
  426.       rate specified in Appendix C for the specific routing protocol
  427.       being used in the test. Two routing update frames are defined in
  428.       Appendix C for the TCP/IP over Ethernet example.  The routing
  429.       frames are designed to change the routing to a number of networks
  430.       that are not involved in the forwarding of the test data.  The
  431.       first frame sets the routing table state to "A", the second one
  432.       changes the state to "B".  The frames MUST be alternated during
  433.       the trial.
  434.  
  435.       The test SHOULD verify that the routing update was processed by
  436.       the DUT.
  437.  
  438.    11.4 Filters
  439.  
  440.       Filters are added to routers and bridges to selectively inhibit
  441.       the forwarding of frames that would normally be forwarded.  This
  442.       is usually done to implement security controls on the data that is
  443.       accepted between one area and another. Different products have
  444.       different capabilities to implement filters.
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Bradner & McQuaid            Informational                      [Page 8]
  451.  
  452. RFC 1944                Benchmarking Methodology                May 1996
  453.  
  454.  
  455.       The DUT SHOULD be first configured to add one filter condition and
  456.       the tests performed.  This filter SHOULD permit the forwarding of
  457.       the test data stream. In routers this filter SHOULD be of the
  458.       form:
  459.  
  460.        forward input_protocol_address to output_protocol_address
  461.  
  462.       In bridges the filter SHOULD be of the form:
  463.  
  464.        forward destination_hardware_address
  465.  
  466.       The DUT SHOULD be then reconfigured to implement a total of 25
  467.       filters.  The first 24 of these filters SHOULD be of the form:
  468.  
  469.        block input_protocol_address to output_protocol_address
  470.  
  471.       The 24 input and output protocol addresses SHOULD not be any that
  472.       are represented in the test data stream.  The last filter SHOULD
  473.       permit the forwarding of the test data stream.  By "first" and
  474.       "last" we mean to ensure that in the second case, 25 conditions
  475.       must be checked before the data frames will match the conditions
  476.       that permit the forwarding of the frame. Of course, if the DUT
  477.       reorders the filters or does not use a linear scan of the filter
  478.       rules the effect of the sequence in which the filters are input is
  479.       properly lost.
  480.  
  481.       The exact filters configuration command lines used SHOULD be
  482.       included with the report of the results.
  483.  
  484.       11.4.1 Filter Addresses
  485.  
  486.          Two sets of filter addresses are required, one for the single
  487.          filter case and one for the 25 filter case.
  488.  
  489.          The single filter case should permit traffic from IP address
  490.          198.18.1.2 to IP address 198.19.65.2 and deny all other
  491.          traffic.
  492.  
  493.          The 25 filter case should follow the following sequence.
  494.  
  495.           deny aa.ba.1.1 to aa.ba.100.1
  496.           deny aa.ba.2.2 to aa.ba.101.2
  497.           deny aa.ba.3.3 to aa.ba.103.3
  498.             ...
  499.           deny aa.ba.12.12 to aa.ba.112.12
  500.           allow aa.bc.1.2 to aa.bc.65.1
  501.           deny aa.ba.13.13 to aa.ba.113.13
  502.           deny aa.ba.14.14 to aa.ba.114.14
  503.  
  504.  
  505.  
  506. Bradner & McQuaid            Informational                      [Page 9]
  507.  
  508. RFC 1944                Benchmarking Methodology                May 1996
  509.  
  510.  
  511.             ...
  512.           deny aa.ba.24.24 to aa.ba.124.24
  513.           deny all else
  514.  
  515.          All previous filter conditions should be cleared from the
  516.          router before this sequence is entered.  The sequence is
  517.          selected to test to see if the router sorts the filter
  518.          conditions or accepts them in the order that they were entered.
  519.          Both of these procedures will result in a greater impact on
  520.          performance than will some form of hash coding.
  521.  
  522. 12. Protocol addresses
  523.  
  524.    It is easier to implement these tests using a single logical stream
  525.    of  data, with one source protocol address and one destination
  526.    protocol address, and for some conditions like the filters described
  527.    above, a practical requirement. Networks in the real world are not
  528.    limited to single streams of data. The test suite SHOULD be first run
  529.    with a single protocol (or hardware for bridge tests) source and
  530.    destination address pair.  The tests SHOULD then be repeated with
  531.    using a random destination address.  While testing routers the
  532.    addresses SHOULD be random and uniformly distributed over a range of
  533.    256 networks and random and uniformly distributed over the full MAC
  534.    range for bridges.  The specific address ranges to use for IP are
  535.    shown in Appendix C.
  536.  
  537. 13. Route Set Up
  538.  
  539.    It is not reasonable that all of the routing information necessary to
  540.    forward the test stream, especially in the multiple address case,
  541.    will be manually set up.  At the start of each trial a routing update
  542.    MUST be sent to the DUT. This routing update MUST include all of the
  543.    network addresses that will be required for the trial.  All of the
  544.    addresses SHOULD resolve to the same "next-hop". Normally this will
  545.    be the address of the receiving side of the test equipment. This
  546.    routing update will have to be repeated at the interval required by
  547.    the routing protocol being used.  An example of the format and
  548.    repetition interval of the update frames is given in Appendix C.
  549.  
  550. 14. Bidirectional traffic
  551.  
  552.    Normal network activity is not all in a single direction.  To test
  553.    the bidirectional performance of a DUT, the test series SHOULD be run
  554.    with the same data rate being offered from each direction. The sum of
  555.    the data rates should not exceed the theoretical limit for the media.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Bradner & McQuaid            Informational                     [Page 10]
  563.  
  564. RFC 1944                Benchmarking Methodology                May 1996
  565.  
  566.  
  567. 15. Single stream path
  568.  
  569.    The full suite of tests SHOULD be run along with whatever modifier
  570.    conditions that are relevant using a single input and output network
  571.    port on the DUT. If the internal design of the DUT has multiple
  572.    distinct pathways, for example, multiple interface cards each with
  573.    multiple network ports, then all possible types of pathways SHOULD be
  574.    tested separately.
  575.  
  576. 16. Multi-port
  577.  
  578.    Many current router and bridge products provide many network ports in
  579.    the same module. In performing these tests first half of the ports
  580.    are designated as "input ports" and half are designated as "output
  581.    ports".  These ports SHOULD be evenly distributed across the DUT
  582.    architecture. For example if a DUT has two interface cards each of
  583.    which has four ports, two ports on each interface card are designated
  584.    as input and two are designated as output.  The specified tests are
  585.    run using the same data rate being offered to each of the input
  586.    ports.  The addresses in the input data streams SHOULD be set so that
  587.    a frame will be directed to each of the output ports in sequence so
  588.    that all "output" ports will get an even distribution of packets from
  589.    this input.  The same configuration MAY be used to perform a
  590.    bidirectional multi-stream test.  In this case all of the ports are
  591.    considered both input and output ports and each data stream MUST
  592.    consist of frames addressed to all of the other ports.
  593.  
  594.    Consider the following 6 port DUT:
  595.  
  596.                               --------------
  597.                      ---------| in A  out X|--------
  598.                      ---------| in B  out Y|--------
  599.                      ---------| in C  out Z|--------
  600.                               --------------
  601.  
  602.    The addressing of the data streams for each of the inputs SHOULD be:
  603.  
  604.     stream sent to input A:
  605.       packet to out X, packet to out Y, packet to out Z
  606.     stream sent to input B:
  607.       packet to out X, packet to out Y, packet to out Z
  608.     stream sent to input C
  609.       packet to out X, packet to out Y, packet to out Z
  610.  
  611.    Note that these streams each follow the same sequence so that 3
  612.    packets will arrive at output X at the same time, then 3 packets at
  613.    Y, then 3 packets at Z. This procedure ensures that, as in the real
  614.    world, the DUT will have to deal with multiple packets addressed to
  615.  
  616.  
  617.  
  618. Bradner & McQuaid            Informational                     [Page 11]
  619.  
  620. RFC 1944                Benchmarking Methodology                May 1996
  621.  
  622.  
  623.    the same output at the same time.
  624.  
  625. 17. Multiple protocols
  626.  
  627.    This document does not address the issue of testing the effects of a
  628.    mixed protocol environment other than to suggest that if such tests
  629.    are wanted then frames SHOULD be distributed between all of the test
  630.    protocols.  The distribution MAY approximate the conditions on the
  631.    network in which the DUT would be used.
  632.  
  633. 18. Multiple frame sizes
  634.  
  635.    This document does not address the issue of testing the effects of a
  636.    mixed frame size environment other than to suggest that if such tests
  637.    are wanted then frames SHOULD be distributed between all of the
  638.    listed sizes for the protocol under test.  The distribution MAY
  639.    approximate the conditions on the network in which the DUT would be
  640.    used. The authors do not have any idea how the results of such a test
  641.    would be interpreted other than to directly compare multiple DUTs in
  642.    some very specific simulated network.
  643.  
  644. 19. Testing performance beyond a single DUT.
  645.  
  646.    In the performance testing of a single DUT, the paradigm can be
  647.    described as applying some input to a DUT and monitoring the output.
  648.    The results of which can be used to form a basis of characterization
  649.    of that device under those test conditions.
  650.  
  651.    This model is useful when the test input and output are homogenous
  652.    (e.g., 64-byte IP, 802.3 frames into the DUT; 64 byte IP, 802.3
  653.    frames out), or the method of test can distinguish between dissimilar
  654.    input/output. (E.g., 1518 byte IP, 802.3 frames in; 576 byte,
  655.    fragmented IP, X.25 frames out.)
  656.  
  657.    By extending the single DUT test model, reasonable benchmarks
  658.    regarding multiple DUTs or heterogeneous environments may be
  659.    collected. In this extension, the single DUT is replaced by a system
  660.    of interconnected network DUTs. This test methodology would support
  661.    the benchmarking of a variety of device/media/service/protocol
  662.    combinations. For example, a configuration for a LAN-to-WAN-to-LAN
  663.    test might be:
  664.  
  665.    (1) 802.3-> DUT 1 -> X.25 @ 64kbps -> DUT 2 -> 802.3
  666.  
  667.    Or a mixed LAN configuration might be:
  668.  
  669.    (2) 802.3 -> DUT 1 -> FDDI -> DUT 2 -> FDDI -> DUT 3 -> 802.3
  670.  
  671.  
  672.  
  673.  
  674. Bradner & McQuaid            Informational                     [Page 12]
  675.  
  676. RFC 1944                Benchmarking Methodology                May 1996
  677.  
  678.  
  679.    In both examples 1 and 2, end-to-end benchmarks of each system could
  680.    be empirically ascertained. Other behavior may be characterized
  681.    through the use of intermediate devices. In example 2, the
  682.    configuration may be used to give an indication of the FDDI to FDDI
  683.    capability exhibited by DUT 2.
  684.  
  685.    Because multiple DUTs are treated as a single system, there are
  686.    limitations to this methodology. For instance, this methodology may
  687.    yield an aggregate benchmark for a tested system. That benchmark
  688.    alone, however, may not necessarily reflect asymmetries in behavior
  689.    between the DUTs, latencies introduce by other apparatus (e.g.,
  690.    CSUs/DSUs, switches), etc.
  691.  
  692.    Further, care must be used when comparing benchmarks of different
  693.    systems by ensuring that the DUTs' features/configuration of the
  694.    tested systems have the appropriate common denominators to allow
  695.    comparison.
  696.  
  697. 20. Maximum frame rate
  698.  
  699.    The maximum frame rates that should be used when testing LAN
  700.    connections SHOULD be the listed theoretical maximum rate for the
  701.    frame size on the media.
  702.  
  703.    The maximum frame rate that should be used when testing WAN
  704.    connections SHOULD be greater than the listed theoretical maximum
  705.    rate for the frame size on that speed connection.  The higher rate
  706.    for WAN tests is to compensate for the fact that some vendors employ
  707.    various forms of header compression.
  708.  
  709.    A list of maximum frame rates for LAN connections is included in
  710.    Appendix B.
  711.  
  712. 21. Bursty traffic
  713.  
  714.    It is convenient to measure the DUT performance under steady state
  715.    load but this is an unrealistic way to gauge the functioning of a DUT
  716.    since actual network traffic normally consists of bursts of frames.
  717.    Some of the tests described below SHOULD be performed with both
  718.    steady state traffic and with traffic consisting of repeated bursts
  719.    of frames.  The frames within a burst are transmitted with the
  720.    minimum legitimate inter-frame gap.
  721.  
  722.    The objective of the test is to determine the minimum interval
  723.    between bursts which the DUT can process with no frame loss. During
  724.    each test the number of frames in each burst is held constant and the
  725.    inter-burst interval varied.  Tests SHOULD be run with burst sizes of
  726.    16, 64, 256 and 1024 frames.
  727.  
  728.  
  729.  
  730. Bradner & McQuaid            Informational                     [Page 13]
  731.  
  732. RFC 1944                Benchmarking Methodology                May 1996
  733.  
  734.  
  735. 22. Frames per token
  736.  
  737.    Although it is possible to configure some token ring and FDDI
  738.    interfaces to transmit more than one frame each time that the token
  739.    is received, most of the network devices currently available transmit
  740.    only one frame per token.  These tests SHOULD first be performed
  741.    while transmitting only one frame per token.
  742.  
  743.    Some current high-performance workstation servers do transmit more
  744.    than one frame per token on FDDI to maximize throughput.  Since this
  745.    may be a common feature in future workstations and servers,
  746.    interconnect devices with FDDI interfaces SHOULD be tested with 1, 4,
  747.    8, and 16 frames per token.  The reported frame rate SHOULD be the
  748.    average rate of frame transmission over the total trial period.
  749.  
  750. 23. Trial description
  751.  
  752.    A particular test consists of multiple trials.  Each trial returns
  753.    one piece of information, for example the loss rate at a particular
  754.    input frame rate.  Each trial consists of a number of phases:
  755.  
  756.     a) If the DUT is a router, send the routing update to the "input"
  757.    port and pause two seconds to be sure that the routing has settled.
  758.  
  759.     b)  Send the "learning frames" to the "output" port and wait 2
  760.    seconds to be sure that the learning has settled.  Bridge learning
  761.    frames are frames with source addresses that are the same as the
  762.    destination addresses used by the test frames.  Learning frames for
  763.    other protocols are used to prime the address resolution tables in
  764.    the DUT.  The formats of the learning frame that should be used are
  765.    shown in the Test Frame Formats document.
  766.  
  767.     c) Run the test trial.
  768.  
  769.     d) Wait for two seconds for any residual frames to be received.
  770.  
  771.     e) Wait for at least five seconds for the DUT to restabilize.
  772.  
  773. 24. Trial duration
  774.  
  775.    The aim of these tests is to determine the rate continuously
  776.    supportable by the DUT.  The actual duration of the test trials must
  777.    be a compromise between this aim and the duration of the benchmarking
  778.    test suite.  The duration of the test portion of each trial SHOULD be
  779.    at least 60 seconds.  The tests that involve some form of "binary
  780.    search", for example the throughput test, to determine the exact
  781.    result MAY use a shorter trial duration to minimize the length of the
  782.    search procedure, but  the final determination SHOULD be made with
  783.  
  784.  
  785.  
  786. Bradner & McQuaid            Informational                     [Page 14]
  787.  
  788. RFC 1944                Benchmarking Methodology                May 1996
  789.  
  790.  
  791.    full length trials.
  792.  
  793. 25. Address resolution
  794.  
  795.    The DUT SHOULD be able to respond to address resolution requests sent
  796.    by the DUT wherever the protocol requires such a process.
  797.  
  798. 26. Benchmarking tests:
  799.  
  800.    Note: The notation "type of data stream" refers to the above
  801.    modifications to a frame stream with a constant inter-frame gap, for
  802.    example, the addition of traffic filters to the configuration of the
  803.    DUT.
  804.  
  805.    26.1 Throughput
  806.  
  807.       Objective:
  808.       To determine the DUT throughput as defined in RFC 1242.
  809.  
  810.       Procedure:
  811.       Send a specific number of frames at a specific rate through the
  812.       DUT and then count the frames that are transmitted by the DUT. If
  813.       the count of offered frames is equal to the count of received
  814.       frames, the rate of the offered stream is raised and the test
  815.       rerun.  If fewer frames are received than were transmitted, the
  816.       rate of the offered stream is reduced and the test is rerun.
  817.  
  818.       The throughput is the fastest rate at which the count of test
  819.       frames transmitted by the DUT is equal to the number of test
  820.       frames sent to it by the test equipment.
  821.  
  822.       Reporting format:
  823.       The results of the throughput test SHOULD be reported in the form
  824.       of a graph. If it is, the x coordinate SHOULD be the frame size,
  825.       the y coordinate SHOULD be the frame rate.  There SHOULD be at
  826.       least two lines on the graph.  There SHOULD be one line showing
  827.       the theoretical frame rate for the media at the various frame
  828.       sizes.  The second line SHOULD be the plot of the test results.
  829.       Additional lines MAY be used on the graph to report the results
  830.       for each type of data stream tested.  Text accompanying the graph
  831.       SHOULD indicate the protocol, data stream format, and type of
  832.       media used in the tests.
  833.  
  834.       We assume that if a single value is desired for advertising
  835.       purposes the vendor will select the rate for the minimum frame
  836.       size for the media. If this is done then the figure MUST be
  837.       expressed in frames per second.  The rate MAY also be expressed in
  838.       bits (or bytes) per second if the vendor so desires.  The
  839.  
  840.  
  841.  
  842. Bradner & McQuaid            Informational                     [Page 15]
  843.  
  844. RFC 1944                Benchmarking Methodology                May 1996
  845.  
  846.  
  847.       statement of performance MUST include a/ the measured maximum
  848.       frame rate, b/ the size of the frame used, c/ the theoretical
  849.       limit of the media for that frame size, and d/ the type of
  850.       protocol used in the test.  Even if a single value is used as part
  851.       of the advertising copy, the full table of results SHOULD be
  852.       included in the product data sheet.
  853.  
  854.    26.2 Latency
  855.  
  856.       Objective:
  857.       To determine the latency as defined in RFC 1242.
  858.  
  859.       Procedure:
  860.       First determine the throughput for DUT at each of the listed frame
  861.       sizes. Send a stream of frames at a particular frame size through
  862.       the DUT at the determined throughput rate to a specific
  863.       destination.  The stream SHOULD be at least 120 seconds in
  864.       duration.  An identifying tag SHOULD be included in one frame
  865.       after 60 seconds with the type of tag being implementation
  866.       dependent. The time at which this frame is fully transmitted is
  867.       recorded (timestamp A).  The receiver logic in the test equipment
  868.       MUST recognize the tag information in the frame stream and record
  869.       the time at which the tagged frame was received (timestamp B).
  870.  
  871.       The latency is timestamp B minus timestamp A as per the relevant
  872.       definition frm RFC 1242, namely latency as defined for store and
  873.       forward devices or latency as defined for bit forwarding devices.
  874.  
  875.       The test MUST be repeated at least 20 times with the reported
  876.       value being the average of the recorded values.
  877.  
  878.       This test SHOULD be performed with the test frame addressed to the
  879.       same destination as the rest of the data stream and also with each
  880.       of the test frames addressed to a new destination network.
  881.  
  882.       Reporting format:
  883.       The report MUST state which definition of latency (from RFC 1242)
  884.       was used for this test.  The latency results SHOULD be reported
  885.       in the format of a table with a row for each of the tested frame
  886.       sizes.  There SHOULD be columns for the frame size, the rate at
  887.       which the latency test was run for that frame size, for the media
  888.       types tested, and for the resultant latency values for each
  889.       type of data stream tested.
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Bradner & McQuaid            Informational                     [Page 16]
  899.  
  900. RFC 1944                Benchmarking Methodology                May 1996
  901.  
  902.  
  903.    26.3 Frame loss rate
  904.  
  905.       Objective:
  906.       To determine the frame loss rate, as defined in RFC 1242, of a DUT
  907.       throughout the entire range of input data rates and frame sizes.
  908.  
  909.       Procedure:
  910.       Send a specific number of frames at a specific rate through the
  911.       DUT to be tested and count the frames that are transmitted by the
  912.       DUT.   The frame loss rate at each point is calculated using the
  913.       following equation:
  914.  
  915.        ( ( input_count - output_count ) * 100 ) / input_count
  916.  
  917.       The first trial SHOULD be run for the frame rate that corresponds
  918.       to 100% of the maximum rate for the frame size on the input media.
  919.       Repeat the procedure for the rate that corresponds to 90% of the
  920.       maximum rate used and then for 80% of this rate.  This sequence
  921.       SHOULD be continued (at reducing 10% intervals) until there are
  922.       two successive trials in which no frames are lost. The maximum
  923.       granularity of the trials MUST be 10% of the maximum rate, a finer
  924.       granularity is encouraged.
  925.  
  926.       Reporting format:
  927.       The results of the frame loss rate test SHOULD be plotted as a
  928.       graph.  If this is done then the X axis MUST be the input frame
  929.       rate as a percent of the theoretical rate for the media at the
  930.       specific frame size. The Y axis MUST be the percent loss at the
  931.       particular input rate.  The left end of the X axis and the bottom
  932.       of the Y axis MUST be 0 percent; the right end of the X axis and
  933.       the top of the Y axis MUST be 100 percent.  Multiple lines on the
  934.       graph MAY used to report the frame loss rate for different frame
  935.       sizes, protocols, and types of data streams.
  936.  
  937.       Note: See section 18 for the maximum frame rates that SHOULD be
  938.       used.
  939.  
  940.    26.4 Back-to-back frames
  941.  
  942.       Objective:
  943.       To characterize the ability of a DUT to process back-to-back
  944.       frames as defined in RFC 1242.
  945.  
  946.       Procedure:
  947.       Send a burst of frames with minimum inter-frame gaps to the DUT
  948.       and count the number of frames forwarded by the DUT.  If the count
  949.       of transmitted frames is equal to the number of frames forwarded
  950.       the length of the burst is increased and the test is rerun.  If
  951.  
  952.  
  953.  
  954. Bradner & McQuaid            Informational                     [Page 17]
  955.  
  956. RFC 1944                Benchmarking Methodology                May 1996
  957.  
  958.  
  959.       the number of forwarded frames is less than the number
  960.       transmitted, the length of the burst is reduced and the test is
  961.       rerun.
  962.  
  963.       The back-to-back value is the number of frames in the longest
  964.       burst that the DUT will handle without the loss of any frames.
  965.       The trial length MUST be at least 2 seconds and SHOULD be
  966.       repeated at least 50 times with the average of the recorded values
  967.       being reported.
  968.  
  969.       Reporting format:
  970.       The back-to-back results SHOULD be reported in the format of a
  971.       table with a row for each of the tested frame sizes.  There SHOULD
  972.       be columns for the frame size and for the resultant average frame
  973.       count for each type of data stream tested.  The standard deviation
  974.       for each measurement MAY also be reported.
  975.  
  976.    26.5 System recovery
  977.  
  978.       Objective:
  979.       To characterize the speed at which a DUT recovers from an overload
  980.       condition.
  981.  
  982.       Procedure:
  983.       First determine the throughput for a DUT at each of the listed
  984.       frame sizes.
  985.  
  986.       Send a stream of frames at a rate 110% of the recorded throughput
  987.       rate or the maximum rate for the media, whichever is lower, for at
  988.       least 60 seconds.  At Timestamp A reduce the frame rate to 50% of
  989.       the above rate and record the time of the last frame lost
  990.       (Timestamp B). The system recovery time is determined by
  991.       subtracting Timestamp B from Timestamp A.  The test SHOULD be
  992.       repeated a number of times and the average of the recorded values
  993.       being reported.
  994.  
  995.       Reporting format:
  996.       The system recovery results SHOULD be reported in the format of a
  997.       table with a row for each of the tested frame sizes.  There SHOULD
  998.       be columns for the frame size, the frame rate used as the
  999.       throughput rate for each type of data stream tested, and for the
  1000.       measured recovery time for each type of data stream tested.
  1001.  
  1002.    26.6 Reset
  1003.  
  1004.       Objective:
  1005.       To characterize the speed at which a DUT recovers from a device or
  1006.       software reset.
  1007.  
  1008.  
  1009.  
  1010. Bradner & McQuaid            Informational                     [Page 18]
  1011.  
  1012. RFC 1944                Benchmarking Methodology                May 1996
  1013.  
  1014.  
  1015.       Procedure:
  1016.       First determine the throughput for the DUT for the minimum frame
  1017.       size on the media used in the testing.
  1018.  
  1019.       Send a continuous stream of frames at the determined throughput
  1020.       rate for the minimum sized frames. Cause a reset in the DUT.
  1021.       Monitor the output until frames begin to be forwarded and record
  1022.       the time that the last frame (Timestamp A) of the initial stream
  1023.       and the first frame of the new stream (Timestamp B) are received.
  1024.       A power interruption reset test is performed as above except that
  1025.       the power to the DUT should be interrupted for 10 seconds in place
  1026.       of causing a reset.
  1027.  
  1028.       This test SHOULD only be run using frames addressed to networks
  1029.       directly connected to the DUT so that there is no requirement to
  1030.       delay until a routing update is received.
  1031.  
  1032.       The reset value is obtained by subtracting Timestamp A from
  1033.       Timestamp B.
  1034.  
  1035.       Hardware and software resets, as well as a power interruption
  1036.       SHOULD be tested.
  1037.  
  1038.       Reporting format:
  1039.       The reset value SHOULD be reported in a simple set of statements,
  1040.       one for each reset type.
  1041.  
  1042. 27. Security Considerations
  1043.  
  1044.    Security issues are not addressed in this document.
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Bradner & McQuaid            Informational                     [Page 19]
  1067.  
  1068. RFC 1944                Benchmarking Methodology                May 1996
  1069.  
  1070.  
  1071. 28. Editors' Addresses
  1072.  
  1073.    Scott Bradner
  1074.    Harvard University
  1075.    1350 Mass. Ave, room 813
  1076.    Cambridge, MA 02138
  1077.  
  1078.    Phone +1 617 495-3864
  1079.    Fax +1 617 496-8500
  1080.    EMail: sob@harvard.edu
  1081.  
  1082.  
  1083.    Jim McQuaid
  1084.    Bay Networks
  1085.    3 Federal Street
  1086.    Billerica, MA 01821
  1087.  
  1088.    Phone +1 508 436-3915
  1089.    Fax: +1 508 670-8145
  1090.    EMail: jmcquaid@baynetworks.com
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Bradner & McQuaid            Informational                     [Page 20]
  1123.  
  1124. RFC 1944                Benchmarking Methodology                May 1996
  1125.  
  1126.  
  1127. Appendix A: Testing Considerations
  1128.  
  1129. A.1 Scope Of This Appendix
  1130.  
  1131.    This appendix discusses certain issues in the benchmarking
  1132.    methodology where experience or judgment may play a role in the tests
  1133.    selected to be run or in the approach to constructing the test with a
  1134.    particular DUT.  As such, this appendix MUST not be read as an
  1135.    amendment to the methodology described in the body of this document
  1136.    but as a guide to testing practice.
  1137.  
  1138.    1. Typical testing practice has been to enable all protocols to be
  1139.       tested and conduct all testing with no further configuration of
  1140.       protocols, even though a given set of trials may exercise only one
  1141.       protocol at a time. This minimizes the opportunities to "tune" a
  1142.       DUT for a single protocol.
  1143.  
  1144.    2. The least common denominator of the available filter functions
  1145.       should be used to ensure that there is a basis for comparison
  1146.       between vendors. Because of product differences, those conducting
  1147.       and evaluating tests must make a judgment about this issue.
  1148.  
  1149.    3. Architectural considerations may need to be considered.  For
  1150.       example, first perform the tests with the stream going between
  1151.       ports on the same interface card and the repeat the tests with the
  1152.       stream going into a port on one interface card and out of a port
  1153.       on a second interface card. There will almost always be a best
  1154.       case and worst case configuration for a given DUT architecture.
  1155.  
  1156.    4. Testing done using traffic streams consisting of mixed protocols
  1157.       has not shown much difference between testing with individual
  1158.       protocols.  That is, if protocol A testing and protocol B testing
  1159.       give two different performance results, mixed protocol testing
  1160.       appears to give a result which is the average of the two.
  1161.  
  1162.    5. Wide Area Network (WAN) performance may be tested by setting up
  1163.       two identical devices connected by the appropriate short- haul
  1164.       versions of the WAN modems.  Performance is then measured between
  1165.       a LAN interface on one DUT to a LAN interface on the other DUT.
  1166.  
  1167.    The maximum frame rate to be used for LAN-WAN-LAN configurations is a
  1168.    judgment that can be based on known characteristics of the overall
  1169.    system including compression effects, fragmentation, and gross link
  1170.    speeds. Practice suggests that the rate should be at least 110% of
  1171.    the slowest link speed. Substantive issues of testing compression
  1172.    itself are beyond the scope of this document.
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Bradner & McQuaid            Informational                     [Page 21]
  1179.  
  1180. RFC 1944                Benchmarking Methodology                May 1996
  1181.  
  1182.  
  1183. Appendix B: Maximum frame rates reference
  1184.  
  1185.    (Provided by Roger Beeman, Cisco Systems)
  1186.  
  1187.      Size       Ethernet    16Mb Token Ring      FDDI
  1188.     (bytes)       (pps)           (pps)         (pps)
  1189.  
  1190.     64            14880           24691         152439
  1191.     128            8445           13793          85616
  1192.     256            4528            7326          45620
  1193.     512            2349            3780          23585
  1194.     768            1586            2547          15903
  1195.     1024           1197            1921          11996
  1196.     1280            961            1542           9630
  1197.     1518            812            1302           8138
  1198.  
  1199.    Ethernet size
  1200.     Preamble 64 bits
  1201.     Frame 8 x N bits
  1202.     Gap  96 bits
  1203.  
  1204.    16Mb Token Ring size
  1205.       SD               8 bits
  1206.       AC               8 bits
  1207.       FC               8 bits
  1208.       DA              48 bits
  1209.       SA              48 bits
  1210.       RI              48 bits ( 06 30 00 12 00 30 )
  1211.       SNAP
  1212.         DSAP           8 bits
  1213.         SSAP           8 bits
  1214.         Control        8 bits
  1215.         Vendor        24 bits
  1216.         Type          16 bits
  1217.       Data 8 x ( N - 18) bits
  1218.       FCS             32 bits
  1219.       ED               8 bits
  1220.       FS               8 bits
  1221.  
  1222.    Tokens or idles between packets are not included
  1223.  
  1224.    FDDI size
  1225.       Preamble        64 bits
  1226.       SD               8 bits
  1227.       FC               8 bits
  1228.       DA              48 bits
  1229.       SA              48 bits
  1230.       SNAP
  1231.  
  1232.  
  1233.  
  1234. Bradner & McQuaid            Informational                     [Page 22]
  1235.  
  1236. RFC 1944                Benchmarking Methodology                May 1996
  1237.  
  1238.  
  1239.         DSAP           8 bits
  1240.         SSAP           8 bits
  1241.         Control        8 bits
  1242.         Vendor        24 bits
  1243.         Type          16 bits
  1244.       Data 8 x ( N - 18) bits
  1245.       FCS             32 bits
  1246.       ED               4 bits
  1247.       FS              12 bits
  1248.  
  1249. Appendix C: Test Frame Formats
  1250.  
  1251.    This appendix defines the frame formats that may be used with these
  1252.    tests.  It also includes protocol specific parameters for TCP/IP over
  1253.    Ethernet to be used with the tests as an example.
  1254.  
  1255. C.1. Introduction
  1256.  
  1257.    The general logic used in the selection of the parameters and the
  1258.    design of the frame formats is explained for each case within the
  1259.    TCP/IP section.  The same logic has been used in the other sections.
  1260.    Comments are used in these sections only if there is a protocol
  1261.    specific feature to be explained.  Parameters and frame formats for
  1262.    additional protocols can be defined by the reader by using the same
  1263.    logic.
  1264.  
  1265. C.2. TCP/IP Information
  1266.  
  1267.    The following section deals with the TCP/IP protocol suite.
  1268.  
  1269.    C.2.1 Frame Type.
  1270.       An application level datagram echo request is used for the test
  1271.       data frame in the protocols that support such a function.  A
  1272.       datagram protocol is used to minimize the chance that a router
  1273.       might expect a specific session initialization sequence, as might
  1274.       be the case for a reliable stream protocol. A specific defined
  1275.       protocol is used because some routers verify the protocol field
  1276.       and refuse to forward unknown protocols.
  1277.  
  1278.       For TCP/IP a UDP Echo Request is used.
  1279.  
  1280.    C.2.2 Protocol Addresses
  1281.       Two sets of addresses must be defined: first the addresses
  1282.       assigned to the router ports, and second the address that are to
  1283.       be used in the frames themselves and in the routing updates.
  1284.  
  1285.       The network addresses 192.18.0.0 through 192.19.255.255 are have
  1286.       been assigned to the BMWG by the IANA for this purpose.  This
  1287.  
  1288.  
  1289.  
  1290. Bradner & McQuaid            Informational                     [Page 23]
  1291.  
  1292. RFC 1944                Benchmarking Methodology                May 1996
  1293.  
  1294.  
  1295.       assignment was made to minimize the chance of conflict in case a
  1296.       testing device were to be accidentally connected to part of the
  1297.       Internet.  The specific use of the addresses is detailed below.
  1298.  
  1299.       C.2.2.1 Router port protocol addresses
  1300.          Half of the ports on a multi-port router are referred to as
  1301.          "input" ports and the other half as "output" ports even though
  1302.          some of the tests use all ports both as input and output.  A
  1303.          contiguous series of IP Class C network addresses from
  1304.          198.18.1.0 to 198.18.64.0 have been assigned for use on the
  1305.          "input" ports.  A second series from 198.19.1.0 to 198.19.64.0
  1306.          have been assigned for use on the "output" ports. In all cases
  1307.          the router port is node 1 on the appropriate network.  For
  1308.          example, a two port DUT would have an IP address of 198.18.1.1
  1309.          on one port and 198.19.1.1 on the other port.
  1310.  
  1311.          Some of the tests described in the methodology memo make use of
  1312.          an SNMP management connection to the DUT.  The management
  1313.          access address for the DUT is assumed to be the first of the
  1314.          "input" ports (198.18.1.1).
  1315.  
  1316.       C.2.2.2 Frame addresses
  1317.          Some of the described tests assume adjacent network routing
  1318.          (the reboot time test for example).  The IP address used in the
  1319.          test frame is that of node 2 on the appropriate Class C
  1320.          network. (198.19.1.2 for example)
  1321.  
  1322.          If the test involves non-adjacent network routing the phantom
  1323.          routers are located at node 10 of each of the appropriate Class
  1324.          C networks.  A series of Class C network addresses from
  1325.          198.18.65.0 to 198.18.254.0 has been assigned for use as the
  1326.          networks accessible through the phantom routers on the "input"
  1327.          side of DUT.  The series of Class C networks from 198.19.65.0
  1328.          to 198.19.254.0 have been assigned to be used as the networks
  1329.          visible through the phantom routers on the "output" side of the
  1330.          DUT.
  1331.  
  1332.    C.2.3 Routing Update Frequency
  1333.  
  1334.       The update interval for each routing protocol is may have to be
  1335.       determined by the specifications of the individual protocol.  For
  1336.       IP RIP, Cisco IGRP and for OSPF a routing update frame or frames
  1337.       should precede each stream of test frames by 5 seconds.  This
  1338.       frequency is sufficient for trial durations of up to 60 seconds.
  1339.       Routing updates must be mixed with the stream of test frames if
  1340.       longer trial periods are selected.  The frequency of updates
  1341.       should be taken from the following table.
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Bradner & McQuaid            Informational                     [Page 24]
  1347.  
  1348. RFC 1944                Benchmarking Methodology                May 1996
  1349.  
  1350.  
  1351.        IP-RIP  30 sec
  1352.        IGRP  90 sec
  1353.        OSPF  90 sec
  1354.  
  1355.    C.2.4 Frame Formats - detailed discussion
  1356.  
  1357.       C.2.4.1 Learning Frame
  1358.          In most protocols a procedure is used to determine the mapping
  1359.          between the protocol node address and the MAC address.  The
  1360.          Address Resolution Protocol (ARP) is used to perform this
  1361.          function in TCP/IP.  No such procedure is required in XNS or
  1362.          IPX because the MAC address is used as the protocol node
  1363.          address.
  1364.  
  1365.          In the ideal case the tester would be able to respond to ARP
  1366.          requests from the DUT.  In cases where this is not possible an
  1367.          ARP request should be sent to the router's "output" port.  This
  1368.          request should be seen as coming from the immediate destination
  1369.          of the test frame stream. (i.e. the phantom router (Figure 2)
  1370.          or the end node if adjacent network routing is being used.) It
  1371.          is assumed that the router will cache the MAC address of the
  1372.          requesting device.  The ARP request should be sent 5 seconds
  1373.          before the test frame stream starts in each trial.  Trial
  1374.          lengths of longer than 50 seconds may require that the router
  1375.          be configured for an extended ARP timeout.
  1376.  
  1377.                       +--------+            +------------+
  1378.                       |        |            |  phantom   |------ P LAN
  1379.          A
  1380.             IN A------|   DUT  |------------|            |------ P LAN
  1381.          B
  1382.                       |        |   OUT A    |  router    |------ P LAN
  1383.          C
  1384.                       +--------+            +------------+
  1385.  
  1386.                                  Figure 2
  1387.  
  1388.            In the case where full routing is being used
  1389.  
  1390.       C.2.4.2 Routing Update Frame
  1391.          If the test does not involve adjacent net routing the tester
  1392.          must supply proper routing information using a routing update.
  1393.          A single routing update is used before each trial on each
  1394.          "destination" port (see section C.24).  This update includes
  1395.          the network addresses that are reachable through a phantom
  1396.          router on the network attached to the port.  For a full mesh
  1397.          test, one destination network address is present in the routing
  1398.          update for each of the "input" ports.  The test stream on each
  1399.  
  1400.  
  1401.  
  1402. Bradner & McQuaid            Informational                     [Page 25]
  1403.  
  1404. RFC 1944                Benchmarking Methodology                May 1996
  1405.  
  1406.  
  1407.          "input" port consists of a repeating sequence of frames, one to
  1408.          each of the "output" ports.
  1409.  
  1410.       C.2.4.3 Management Query Frame
  1411.          The management overhead test uses SNMP to query a set of
  1412.          variables that should be present in all DUTs that support SNMP.
  1413.          The variables for a single interface only are read by an NMS
  1414.          at the appropriate intervals.  The list of variables to
  1415.          retrieve follow:
  1416.  
  1417.           sysUpTime
  1418.           ifInOctets
  1419.           ifOutOctets
  1420.           ifInUcastPkts
  1421.           ifOutUcastPkts
  1422.  
  1423.       C.2.4.4 Test Frames
  1424.          The test frame is an UDP Echo Request with enough data to fill
  1425.          out the required frame size.  The data should not be all bits
  1426.          off or all bits on since these patters can cause a "bit
  1427.          stuffing" process to be used to maintain clock synchronization
  1428.          on WAN links.  This process will result in a longer frame than
  1429.          was intended.
  1430.  
  1431.       C.2.4.5 Frame Formats - TCP/IP on Ethernet
  1432.          Each of the frames below are described for the 1st pair of DUT
  1433.          ports, i.e. "input" port #1 and "output" port #1.  Addresses
  1434.          must be changed if the frame is to be used for other ports.
  1435.  
  1436.       C.2.6.1 Learning Frame
  1437.  
  1438.           ARP Request on Ethernet
  1439.  
  1440.           -- DATAGRAM HEADER
  1441.           offset data (hex)            description
  1442.           00     FF FF FF FF FF FF     dest MAC address send to
  1443.          broadcast address
  1444.           06     xx xx xx xx xx xx     set to source MAC address
  1445.           12     08 06                 ARP type
  1446.           14     00 01                 hardware type Ethernet = 1
  1447.           16     08 00                 protocol type IP = 800
  1448.           18     06                    hardware address length 48 bits
  1449.          on Ethernet
  1450.           19     04                    protocol address length 4 octets
  1451.          for IP
  1452.           20     00 01                 opcode request = 1
  1453.           22     xx xx xx xx xx xx     source MAC address
  1454.           28     xx xx xx xx           source IP address
  1455.  
  1456.  
  1457.  
  1458. Bradner & McQuaid            Informational                     [Page 26]
  1459.  
  1460. RFC 1944                Benchmarking Methodology                May 1996
  1461.  
  1462.  
  1463.           32     FF FF FF FF FF FF     requesting DUT's MAC address
  1464.           38     xx xx xx xx           DUT's IP address
  1465.  
  1466.       C.2.6.2 Routing Update Frame
  1467.  
  1468.           -- DATAGRAM HEADER
  1469.           offset data (hex)            description
  1470.           00     FF FF FF FF FF FF     dest MAC address is broadcast
  1471.           06     xx xx xx xx xx xx     source hardware address
  1472.           12     08 00                 type
  1473.  
  1474.           -- IP HEADER
  1475.           14     45                    IP version - 4, header length (4
  1476.          byte units) - 5
  1477.           15     00                    service field
  1478.           16     00 EE                 total length
  1479.           18     00 00                 ID
  1480.           20     40 00                 flags (3 bits) 4 (do not
  1481.          fragment),
  1482.                                        fragment offset-0
  1483.           22     0A                    TTL
  1484.           23     11                    protocol - 17 (UDP)
  1485.           24     C4 8D                 header checksum
  1486.           26     xx xx xx xx           source IP address
  1487.           30     xx xx xx              destination IP address
  1488.           33     FF                    host part = FF for broadcast
  1489.  
  1490.           -- UDP HEADER
  1491.           34     02 08                 source port 208 = RIP
  1492.           36     02 08                 destination port 208 = RIP
  1493.           38     00 DA                 UDP message length
  1494.           40     00 00                 UDP checksum
  1495.  
  1496.           -- RIP packet
  1497.           42     02                  command = response
  1498.           43     01                  version = 1
  1499.           44     00 00               0
  1500.  
  1501.           -- net 1
  1502.           46     00 02               family = IP
  1503.           48     00 00               0
  1504.           50     xx xx xx            net 1 IP address
  1505.           53     00                  net not node
  1506.           54     00 00 00 00         0
  1507.           58     00 00 00 00         0
  1508.           62     00 00 00 07         metric 7
  1509.  
  1510.           -- net 2
  1511.  
  1512.  
  1513.  
  1514. Bradner & McQuaid            Informational                     [Page 27]
  1515.  
  1516. RFC 1944                Benchmarking Methodology                May 1996
  1517.  
  1518.  
  1519.           66     00 02               family = IP
  1520.           68     00 00               0
  1521.           70     xx xx xx            net 2 IP address
  1522.           73     00                  net not node
  1523.           74     00 00 00 00         0
  1524.           78     00 00 00 00         0
  1525.           82     00 00 00 07         metric 7
  1526.  
  1527.           -- net 3
  1528.           86     00 02               family = IP
  1529.           88     00 00               0
  1530.           90     xx xx xx            net 3 IP address
  1531.           93     00                  net not node
  1532.           94     00 00 00 00         0
  1533.           98     00 00 00 00         0
  1534.           102    00 00 00 07         metric 7
  1535.  
  1536.           -- net 4
  1537.           106    00 02               family = IP
  1538.           108    00 00               0
  1539.           110    xx xx xx            net 4 IP address
  1540.           113    00                  net not node
  1541.           114    00 00 00 00         0
  1542.           118    00 00 00 00         0
  1543.           122    00 00 00 07         metric 7
  1544.  
  1545.           -- net 5
  1546.           126    00 02               family = IP
  1547.           128    00 00               0
  1548.           130    00                  net 5 IP address
  1549.           133    00                  net not node
  1550.           134    00 00 00 00         0
  1551.           138    00 00 00 00         0
  1552.           142    00 00 00 07         metric 7
  1553.  
  1554.           -- net 6
  1555.           146    00 02               family = IP
  1556.           148    00 00               0
  1557.           150    xx xx xx            net 6 IP address
  1558.           153    00                  net not node
  1559.           154    00 00 00 00         0
  1560.           158    00 00 00 00         0
  1561.           162    00 00 00 07         metric 7
  1562.  
  1563.       C.2.4.6 Management Query Frame
  1564.  
  1565.          To be defined.
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Bradner & McQuaid            Informational                     [Page 28]
  1571.  
  1572. RFC 1944                Benchmarking Methodology                May 1996
  1573.  
  1574.  
  1575.       C.2.6.4 Test Frames
  1576.               UDP echo request on Ethernet
  1577.  
  1578.           -- DATAGRAM HEADER
  1579.           offset data (hex)            description
  1580.           00     xx xx xx xx xx xx     set to dest MAC address
  1581.           06     xx xx xx xx xx xx     set to source MAC address
  1582.           12     08 00                 type
  1583.  
  1584.           -- IP HEADER
  1585.           14     45                    IP version - 4 header length 5 4
  1586.          byte units
  1587.           15     00                    TOS
  1588.           16     00 2E                 total length*
  1589.           18     00 00                 ID
  1590.           20     00 00                 flags (3 bits) - 0 fragment
  1591.          offset-0
  1592.           22     0A                    TTL
  1593.           23     11                    protocol - 17 (UDP)
  1594.           24     C4 8D                 header checksum*
  1595.           26     xx xx xx xx           set to source IP address**
  1596.           30     xx xx xx xx           set to destination IP address**
  1597.  
  1598.           -- UDP HEADER
  1599.           34     C0 20                 source port
  1600.           36     00 07                 destination port 07 = Echo
  1601.           38     00 1A                 UDP message length*
  1602.           40     00 00                 UDP checksum
  1603.  
  1604.           -- UDP DATA
  1605.           42     00 01 02 03 04 05 06 07    some data***
  1606.           50     08 09 0A 0B 0C 0D 0E 0F
  1607.  
  1608.          * - change for different length frames
  1609.  
  1610.          ** - change for different logical streams
  1611.  
  1612.          *** - fill remainder of frame with incrementing octets,
  1613.          repeated if required by frame length
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. Bradner & McQuaid            Informational                     [Page 29]
  1627.  
  1628. RFC 1944                Benchmarking Methodology                May 1996
  1629.  
  1630.  
  1631.    Values to be used in Total Length and UDP message length fields:
  1632.  
  1633.           frame size   total length  UDP message length
  1634.              64            00 2E          00 1A
  1635.              128           00 6E          00 5A
  1636.              256           00 EE          00 9A
  1637.              512           01 EE          01 9A
  1638.              768           02 EE          02 9A
  1639.              1024          03 EE          03 9A
  1640.              1280          04 EE          04 9A
  1641.              1518          05 DC          05 C8
  1642.  
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651.  
  1652.  
  1653.  
  1654.  
  1655.  
  1656.  
  1657.  
  1658.  
  1659.  
  1660.  
  1661.  
  1662.  
  1663.  
  1664.  
  1665.  
  1666.  
  1667.  
  1668.  
  1669.  
  1670.  
  1671.  
  1672.  
  1673.  
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Bradner & McQuaid            Informational                     [Page 30]
  1683.  
  1684.