RFC2544 Standard Test


    This time, the time has come to consider the standard test RFC2544: what is used, how is it carried out, its advantages and disadvantages.

    Since the last article, I received feedback from colleagues with a proposal to write closer to the point: less water - more specificity. So I propose to consider this article experimental. At the end of the material a short survey.


    Recommendation RFC2544 was developed in 1999 and adopted by the IETF . There is a translation into Russian. Now this recommendation is practically a de facto standard, due to wide distribution and free access. The recommendation “describes and defines a set of tests for determining the characteristics of interconnect devices”, describes formats for presenting test results.

    Methodology Structure

    Testing by RFC2544 methodology is reduced to performing a set of tests, four of which are present at most manufacturers of measuring equipment, and two are quite rare (the last ones in the list).

    • Throughput
      • determines DUT throughput as recommended by RFC1242
      • determines the load at which there is no packet loss

    • Latency
      • determines latency, as recommended by RFC1242
      • measures frame delay selectively

    • Frame loss
      • determines the frame loss rate, according to RFC1242, in the entire range of data rates and frame sizes
      • determines the dependence of losses on load

    • Back to back
      • determines the DUT's ability to process back-to-back frames, as recommended by RFC1242
      • measures the duration of work at a given load

    • System Restore
      • determines the speed of DUT recovery after traffic congestion

    • Reboot
      • determines the speed of DUT recovery after a software or hardware reset


    The maximum number of frames per second that the device can transmit without errors is determined. Speed ​​is determined by bisection. The test starts at maximum speed. In case of losses, the speed is halved. If there are no losses, then the speed doubles compared to the previous one. Etc. The maximum speed is determined by the stability of the work (no loss) for 60 seconds. Testing is conducted for each frame size. Dimensions are specified in the RFC2544 test parameters before starting.


    The test builds on the previous throughput measurement. For each packet size with the corresponding maximum speed, a data stream is generated. The stream must have a duration of at least 120 seconds. After 60 seconds, a time stamp is inserted into 1 packet. On the transmitting side, the time the packet was sent is recorded. At the receiving side, the sender’s label is determined and the time it takes to receive the packet is recorded. Delay is the difference between the time it receives and the time it sends it. The test should be repeated at least 20 times. The average delay is calculated from the measurement results.

    Packet loss

    The percentage of packet loss (the ratio of lost to sent) is calculated. Measurement starts at maximum speed and decreases with each next attempt by 10% (or less). The speed decreases until two measurements in a row pass without loss.


    The test consists in checking the equipment to process frames coming with a minimum frame interval, i.e. back to back (back-to-back). Starts with the number of frames set in the RFC2544 test parameters. If losses are not observed (for at least 2 seconds), then the number of frames increases, if present, then decreases. Based on the results of at least 50 measurements, the average value is calculated.

    The disadvantages of the method

    The testing methodology is old (developed in 1999) and today no longer meets the requirements of the market. Among the shortcomings stand out:
    it is impossible to constantly measure the delay (Frame Transfer Delay, FTD) there is
    no measurement of the delay variation (Frame Delay Variation, FDV)
    there is no multithreading, everything is performed in turn
    a long test (based on the previous paragraph)

    Additions to the methodology

    To expand the functionality and compensate for the shortcomings developed add-ons:
    • jitter measurement
    • complex traffic


    Packet jitter is the absolute difference in the propagation delay of two consecutively received packets belonging to the same data stream.
    The ideal option is a complete lack of jitter:
    A possible option is a different delay between adjacent packets:

    Complex traffic

    The test allows you to generate and receive multiple streams of test traffic.
    It measures the throughput and the amount of frame loss (Frame Loss Rate, FLR), but doesn’t allow you to continuously measure the delay (FTD) and delay variation (FDV).


    The RFC2544 technique is now present in the equipment of most manufacturers, primarily historically, and we can say that today it is the same basic test for packet Ethernet networks as BERT for TDM networks. But it is worth remembering that RFC2544 does not conduct comprehensive testing, and even if all tests pass successfully, a situation may arise that the network will not function as expected.
    The RFC2544 technique is being replaced by Y1564, which I am going to devote to the next article.

    My other articles

    1. The quality of data networks. Software and hardware measurements
    2. The quality of data networks. Transport

    Only registered users can participate in the survey. Please come in.

    Your opinion on all articles

    • 50.4% Material useful and interesting, continue on 56
    • 9.9% Material is useful, but boring (please provide details in the comments) 11
    • 7.2% It is necessary to supplement, because little theory 8
    • 18.9% Must be supplemented, as little practice 21
    • 10.8% Nothing is clear, give more pictures 12
    • 2.7% Such material is not needed, not interesting (please indicate what would be interesting) 3

    Also popular now: