Merge "TestSpec: Add LTD.Throughput.RFC2889.ForwardPressure"
[vswitchperf.git] / test_spec / vswitchperf_ltd.md
old mode 100644 (file)
new mode 100755 (executable)
index 63b72cb..84d946f
@@ -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.
@@ -636,9 +640,156 @@ The following represents possible deployments which can help to determine the pe
    - 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/>
+
+ - #####Test ID: LTD.Throughput.RFC2889.ForwardingRate
+
+  **Title**: RFC2889 Forwarding Rate Test
+
+  **Prerequisite Test**: LTD.Throughput.RFC2544.PacketLossRatio
+
+  **Priority**:
+
+  **Description**:
+
+  This test measures the DUT's Max Forwarding Rate when the Offered Load is varied between the throughput and the Maximum Offered Load for fixed length frames at a fixed time interval. The selected frame sizes are those previously defined under [Default Test Parameters](#DefaultParams). The throughput is the maximum offered load with 0% frame loss (measured by the prerequisite test), and the Maximum Offered Load (as defined by [RFC2885]) is _"the highest number of frames per second that an external source can transmit to a DUT/SUT for forwarding to a specified output interface or interfaces"_.
+
+  Traffic should be sent to the DUT at a particular rate (TX rate) starting with TX rate equal to the throughput rate. The rate of successfully received frames at the destination counted (in FPS). If the RX rate is equal to the TX rate, the TX rate should be increased by a fixed step size and the RX rate measured again until the Max Forwarding Rate is found.
+
+  The trial duration for each iteration should last for the period of time needed for the system to reach steady state for the frame size being tested. Under [RFC2889] test methodology, the test duration should run for a minimum period of 30 seconds, regardless whether the system reaches steady state before the minimum duration ends.
+
+  **Expected Result**:
+  According to [RFC2889] The Max Forwarding Rate is the highest forwarding rate of a DUT taken from an iterative set of forwarding rate measurements. The iterative set of forwarding rate measurements are made by setting the intended load transmitted from an external source and measuring the offered load (i.e what the DUT is capable of forwarding). If the Throughput == the Maximum Offered Load, it follows that Max Forwarding Rate is equal to the Maximum Offered Load.
+
+  **Metrics Collected**:
+
+  The following are the metrics collected for this test:
+
+   - The Max Forwarding Rate for the DUT for each packet size.
+
+<br/>
+ - #####Test ID: LTD.Throughput.RFC2889.ForwardPressure
+  **Title**: RFC2889 Forward Pressure Test
+
+  **Prerequisite Test**: LTD.Throughput.RFC2889.ForwardingRate
+
+  **Priority**:
+
+  **Description**:
+
+  The aim of this test is to determine if the DUT transmits frames with an inter-frame gap that is less than 12 bytes. This test overloads the DUT and measures the output for forward pressure. Traffic should be transmitted to the DUT with an inter-frame gap of 11 bytes, this will overload the DUT by 1 byte per frame. The forwarding rate of the DUT should be measured.
+
+  **Expected Result**:
+  The forwarding rate should not exceed the maximum forwarding rate of the DUT collected by LTD.Throughput.RFC2889.ForwardingRate.
+
+  **Metrics collected**
+
+  The following are the metrics collected for this test:
+
+   - Forwarding rate of the DUT.
+
+  **Deployment scenario**:
+
+   - Physical → virtual switch → physical.
+
 <br/>
 [RFC1242]:(http://www.ietf.org/rfc/rfc1242.txt)
 [RFC2544]:(http://www.ietf.org/rfc/rfc2544.txt)
+[RFC2885]:(http://www.ietf.org/rfc/rfc2885.txt)
+[RFC2889]:(http://www.ietf.org/rfc/rfc2889.txt)
 [RFC5481]:(http://www.ietf.org/rfc/rfc5481.txt)
 [RFC6201]:(http://www.ietf.org/rfc/rfc6201.txt)
 [DPDK]:http://www.dpdk.org/