diff options
Diffstat (limited to 'test_spec/vswitchperf_ltd.md')
| -rw-r--r-- | test_spec/vswitchperf_ltd.md | 123 |
1 files changed, 123 insertions, 0 deletions
diff --git a/test_spec/vswitchperf_ltd.md b/test_spec/vswitchperf_ltd.md index f63a39e2..7cbbed2b 100644 --- a/test_spec/vswitchperf_ltd.md +++ b/test_spec/vswitchperf_ltd.md @@ -498,7 +498,9 @@ The following represents possible deployments which can help to determine the pe This test determines the DUT's maximum forwarding rate with X% traffic loss for a constant load (fixed length frames at a fixed interval time). The default loss percentages to be tested are: - X = 0% - X = 10^-7% + Note: Other values can be tested if required by the user. + The selected frame sizes are those previously defined under [Default Test Parameters](#DefaultParams). The test can also be used to determine the average latency of the traffic. Under the [RFC2544] test methodology, the test duration will include a number of trials; each trial should run for a minimum period of 60 seconds. A binary search methodology must be applied for each trial to obtain the final result. @@ -526,7 +528,9 @@ The following represents possible deployments which can help to determine the pe This test determines the DUT's maximum forwarding rate with X% traffic loss for a constant load (fixed length frames at a fixed interval time). The default loss percentages to be tested are: - X = 0% - X = 10^-7% + Note: Other values can be tested if required by the user. + The selected frame sizes are those previously defined under [Default Test Parameters](#DefaultParams). The test can also be used to determine the average latency of the traffic. Under the [RFC2544] test methodology, the test duration will include a number of trials; each trial should run for a minimum period of 60 seconds. A binary search methodology must be applied for each trial to obtain the final result. @@ -611,6 +615,125 @@ The following represents possible deployments which can help to determine the pe - Physical → virtual switch → physical. <br/> + - #####Test ID: LTD.Throughput.RFC2544.Soak + **Title**: RFC 2544 X% packet loss Throughput Soak Test + + **Prerequisite Test** LTD.Throughput.RFC2544.PacketLossRatio + + **Priority**: + + **Description**: + + The aim of this test is to understand the Throughput stability over an extended test duration in order to uncover any outliers. To allow for an extended test duration, the test should ideally run for 24 hours or, if this is not possible, for at least 6 hour. For this test, each frame size must be sent at the highest Throughput with X% packet loss, as determined in the prerequisite test. The default loss percentages to be tested are: + - X = 0% + - X = 10^-7% + + Note: Other values can be tested if required by the user. + + **Expected Result**: + + **Metrics Collected**: + + The following are the metrics collected for this test: + + - Throughput stability of the DUT. + - Any outliers in the Throughput stability. + - Any unexpected variation in Throughput stability. + +<br/> + + - #####Test ID: LTD.Throughput.RFC2544.SoakFrameModification + **Title**: RFC 2544 X% packet loss Throughput Soak Test with Frame Modification + + **Prerequisite Test** LTD.Throughput.RFC2544.PacketLossRatioFrameModification + + **Priority**: + + **Description**: + + The aim of this test is to understand the Throughput stability over an extended test duration in order to uncover any outliers. To allow for an extended test duration, the test should ideally run for 24 hours or, if this is not possible, for at least 6 hour. For this test, each frame size must be sent at the highest Throughput with X% packet loss, as determined in the prerequisite test. The default loss percentages to be tested are: + - X = 0% + - X = 10^-7% + + Note: Other values can be tested if required by the user. + + During this test, the DUT must perform the following operations on the traffic flow: + + - Perform packet parsing on the DUT's ingress port. + - Perform any relevant address look-ups on the DUT's ingress ports. + - Modify the packet header before forwarding the packet to the DUT's egress port. Packet modifications include: + - Modifying the Ethernet source or destination MAC address. + - Modifying/adding a VLAN tag. + - Modifying/adding a MPLS tag. + - Modifying the source or destination ip address. + - Modifying the TOS/DSCP field. + - Modifying the source or destination ports for UDP/TCP/SCTP (Recommended). + - Modifying the TTL. + + **Expected Result**: + + **Metrics Collected**: + + The following are the metrics collected for this test: + + - Throughput stability of the DUT. + - Any outliers in the Throughput stability. + - Any unexpected variation in Throughput stability. + +<br/> + + - #####Test ID: LTD.Throughput.RFC6201.ResetTime + **Title**: RFC 6201 Reset Time Test + + **Prerequisite Test**: N\A + + **Priority**: + + **Description**: + + The aim of this test is to determine the length of time it takes the DUT to recover from a reset. For each frame size previously defined under [Default Test Parameters](#DefaultParams), traffic should be sent to the DUT under normal conditions. During the duration of the test and while the traffic flows are passing through the DUT, the DUT should be reset and the Reset time measured. The Reset time is the total time that a device is determined to be out of operation and includes the time to perform the reset and the time to recover from it (cf. [RFC6201]) + + [RFC6201] defines two methods to measure the Reset time: + - Frame-Loss Method: which requires the monitoring of the number of lost frames and calculates the Reset time based on the number of frames lost and the offered rate according to the following formula: + <pre><code> + Frames_lost (packets) + Reset_time = ------------------------------------- + Offered_rate (packets per second) + </code></pre> + - Timestamp Method: which measures the time from which the last frame is forwarded from the DUT to the time the first frame is forwarded after the reset. This involves time-stamping all transmitted frames and recording the timestamp of the last frame that was received prior to the reset and also measuring the timestamp of the first frame that is received after the reset. The Reset time is the difference between these two timestamps. + + According to [RFC6201] the choice of method depends on the test tool's capability; the Frame-Loss method SHOULD be used if the test tool supports: + - Counting the number of lost frames per stream. + - Transmitting test frame despite the physical link status. + + whereas the Timestamp method SHOULD be used if the test tool supports: + - Timestamping each frame. + - Monitoring received frame's timestamp. + - Transmitting frames only if the physical link status is up. + + **Expected Result**: + + **Metrics collected** + + The following are the metrics collected for this test: + - Average Reset Time. + + Results of this test should include the following information: + - Throughput in Fps and Mbps. + - Average Frame Loss. + - Average Reset Time in milliseconds. + - Number of trials. + - Protocol: IPv4, IPv6, MPLS, etc. + - Frame Size in Octets + - Port Media: Ethernet, Gigabit Ethernet (GbE), etc. + - Port Speed: 10 Gbps, 40 Gbps etc. + - Interface Encapsulation: Ethernet, Ethernet VLAN, etc. + + **Deployment scenario**: + + - Physical → virtual switch → physical. + +<br/> [RFC1242]:(http://www.ietf.org/rfc/rfc1242.txt) [RFC2544]:(http://www.ietf.org/rfc/rfc2544.txt) [RFC5481]:(http://www.ietf.org/rfc/rfc5481.txt) |