+ - CPU and memory utilization may also be collected as part of this test, to determine the vSwitch's performance footprint on the system.
+
+<br/>
+ - #####Test ID: LTD.Throughput.RFC2889.ForwardPressure
+ **Title**: RFC2889 Forward Pressure Test
+
+ **Prerequisite Test**: LTD.Throughput.RFC2889.MaxForwardingRate
+
+ **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.MaxForwardingRate.
+
+ **Metrics collected**
+
+ The following are the metrics collected for this test:
+
+ - Forwarding rate of the DUT in FPS or Mbps.
+ - CPU and memory utilization may also be collected as part of this test, to determine the vSwitch's performance footprint on the system.
+
+ **Deployment scenario**:
+
+ - Physical → virtual switch → physical.
+
+<br/>
+ - #####Test ID: LTD.Throughput.RFC2889.AddressCachingCapacity
+ **Title**: RFC2889 Address Caching Capacity Test
+
+ **Prerequisite Test**: N\A
+
+ **Priority**:
+
+ **Description**:
+
+ Please note this test is only applicable to switches that are capable of MAC learning. The aim of this test is to determine the address caching capacity of the DUT for a constant load (fixed length frames at a fixed interval time). The selected frame sizes are those previously defined under [Default Test Parameters](#DefaultParams).
+
+ In order to run this test the aging time, that is the maximum time the DUT will keep a learned address in its flow table, and a set of initial addresses, whose value should be >= 1 and <= the max number supported by the implementation must be known. Please note that if the aging time is configurable it must be longer than the time necessary to produce frames from the external source at the specified rate. If the aging time is fixed the frame rate must be brought down to a value that the external source can produce in a time that is less than the aging time.
+
+ Learning Frames should be sent from an external source to the DUT to install a number of flows. The Learning Frames must have a fixed destination address and must vary the source address of the frames. The DUT should install flows in its flow table based on the varying source addresses.
+ Frames should then be transmitted from an external source at a suitable frame rate to see if the DUT has properly learned all of the addresses. If there is no frame loss and no flooding, the number of addresses sent to the DUT should be increased and the test is repeated until the max number of cached addresses supported by the DUT determined.
+
+ **Expected Result**:
+
+ **Metrics collected**:
+
+ The following are the metrics collected for this test:
+
+ - Number of cached addresses supported by the DUT.
+ - CPU and memory utilization may also be collected as part of this test, to determine the vSwitch's performance footprint on the system.
+
+ **Deployment scenario**:
+
+ - Physical → virtual switch → physical.
+
+<br/>
+ - #####Test ID: LTD.Throughput.RFC2889.AddressLearningRate
+ **Title**: RFC2889 Address Learning Rate Test
+
+ **Prerequisite Test**: LTD.Memory.RFC2889.AddressCachingCapacity
+
+ **Priority**:
+
+ **Description**:
+
+ Please note this test is only applicable to switches that are capable of MAC learning. The aim of this test is to determine the rate of address learning of the DUT for a constant load (fixed length frames at a fixed interval time). The selected frame sizes are those previously defined under [Default Test Parameters](#DefaultParams), traffic should be sent with each IPv4/IPv6 address incremented by one. The rate at which the DUT learns a new address should be measured. The maximum caching capacity from LTD.Memory.RFC2889.AddressCachingCapacity should be taken into consideration as the maximum number of addresses for which the learning rate can be obtained.
+
+ **Expected Result**:
+ It may be worthwhile to report the behaviour when operating beyond address capacity - some DUTS may be more friendly to new addresses than others.
+
+ **Metrics collected**:
+
+ The following are the metrics collected for this test:
+
+ - The address learning rate of the DUT.
+
+ **Deployment scenario**:
+
+ - Physical → virtual switch → physical.
+
+<br/>
+ - #####Test ID: LTD.Throughput.RFC2889.ErrorFramesFiltering
+ **Title**: RFC2889 Error Frames Filtering Test
+
+ **Prerequisite Test**: N\A
+
+ **Priority**:
+
+ **Description**:
+
+ The aim of this test is to determine whether the DUT will propagate any erroneous frames it receives or whether it is capable of filtering out the erroneous frames. Traffic should be sent with erroneous frames included within the flow at random intervals. Illegal frames that must be tested include:
+ - Oversize Frames.
+ - Undersize Frames.
+ - CRC Errored Frames.
+ - Dribble Bit Errored Frames
+ - Alignment Errored Frames
+
+ The traffic flow exiting the DUT should be recorded and checked to determine if the erroneous frames where passed through the DUT.
+
+ **Expected Result**:
+ Broken frames are not passed!
+
+ **Metrics collected**
+
+ No Metrics are collected in this test, instead it determines:
+
+ - Whether the DUT will propagate erroneous frames.
+ - Or whether the DUT will correctly filter out any erroneous frames from traffic flow with out removing correct frames.
+
+ **Deployment scenario**:
+
+ - Physical → virtual switch → physical.
+
+<br/>
+ - #####Test ID: LTD.Throughput.RFC2889.BroadcastFrameForwarding
+ **Title**: RFC2889 Broadcast Frame Forwarding Test
+
+ **Prerequisite Test**: N\A
+
+ **Priority**:
+
+ **Description**:
+
+ The aim of this test is to determine the maximum forwarding rate of the DUT when forwarding broadcast traffic. For each frame previously defined under [Default Test Parameters](#DefaultParams), the traffic should be set up as broadcast traffic. The traffic throughput of the DUT should be measured.
+
+ **Expected Result**:
+
+ **Metrics collected**
+
+ The following are the metrics collected for this test:
+
+ - The forwarding rate of the DUT when forwarding broadcast traffic.
+
+<br/>
+ - #####Test ID: LTD.MemoryBandwidth.RFC2544.0PacketLoss.Scalability
+ **Title**: RFC 2544 0% loss Memory Bandwidth Scalability test
+
+ **Prerequisite Tests**:
+
+ **Priority**:
+
+ **Description**:
+
+ The aim of this test is to understand how the DUT's performance is affected by cache sharing and memory bandwidth between processes.
+
+ During the test all cores not used by the vSwitch should be running a memory intensive application. This application should read and write random data to random addresses in unused physical memory. The random nature of the data and addresses is intended to consume cache, exercise main memory access (as opposed to cache) and exercise all memory buses equally. Furthermore:
+ - the ratio of reads to writes should be recorded. A ratio of 1:1 SHOULD be used.
+ - the reads and writes MUST be of cache-line size and be cache-line aligned.
+ - in NUMA architectures memory access SHOULD be local to the core's node. Whether only local memory or a mix of local and remote memory is used MUST be recorded.
+ - the memory bandwidth (reads plus writes) used per-core MUST be recorded; the test MUST be run with a per-core memory bandwidth equal to half the maximum system memory bandwidth divided by the number of cores. The test MAY be run with other values for the per-core memory bandwidth.
+ - the test MAY also be run with the memory intensive application running on all cores.
+
+ Under these conditions the DUT's 0% packet loss throughput is determined as per LTD.Throughput.RFC2544.PacketLossRatio.
+
+ **Expected Result**:
+
+ **Metrics Collected**:
+
+ The following are the metrics collected for this test:
+
+ - The DUT's 0% packet loss throughput in the presence of cache sharing and memory bandwidth between processes.
+----
+<a name="LatencyTests"></a>
+####2.3.2 Packet Latency tests
+ These tests will measure the store and forward latency as well as the packet delay variation for various packet types through the virtual switch.
+
+ The following list is not exhaustive but should indicate the type of tests that should be required. It is expected that more will be added.
+
+ - #####Test ID: LTD.PacketLatency.InitialPacketProcessingLatency
+ **Title**: Initial Packet Processing Latency
+
+ **Prerequisite Test**: N\A
+
+ **Priority**:
+
+ **Description**:
+
+ In some virtual switch architectures, the first packets of a flow will take the system longer to process than subsequent packets in the flow. This test determines the latency for these packets. The test will measure the latency of the packets as they are processed by the flow-setup-path of the DUT. This test will send a single packet to the DUT after a fixed interval of time. The time interval will be equivalent to the amount of time it takes for a flow to time out in the virtual switch. Average packet latency will be determined over 1,000,000 packets.
+
+ For this test, only unidirectional traffic is required.
+
+ **Expected Result**:
+ The average latency for the initial packet of all flows should be greater than the latency of subsequent traffic.
+
+ **Metrics Collected**:
+
+ The following are the metrics collected for this test:
+
+ - Average latency of the initial packets of all flows that are processed by the DUT.
+
+ **Deployment scenario**:
+
+ - Physical → Virtual Switch → Physical.
+<br/>
+ - #####Test ID: LTD.PacketDelayVariation.RFC3393.Soak
+ **Title**: Packet Delay Variation Soak Test
+
+ **Prerequisite Tests**: LTD.Throughput.RFC2544.PacketLossRatio (0% Packet Loss)
+
+ **Priority**:
+
+ **Description**:
+
+ The aim of this test is to understand the distribution of packet delay variation for different frame sizes over an extended test duration and to determine if there are 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 possible throughput with 0% packet loss, as determined in the prerequisite test.
+
+ **Expected Result**:
+
+ **Metrics Collected**:
+
+ The following are the metrics collected for this test:
+
+ - The packet delay variation value for traffic passing through the DUT.
+ - The [RFC5481] PDV form of delay variation on the traffic flow, using the 99th percentile, for each 60s interval during the test.
+ - CPU and memory utilization may also be collected as part of this test, to determine the vSwitch's performance footprint on the system.
+
+
+<br/>
+----
+<a name="ScalabilityTests"></a>
+####2.3.3 Scalability tests
+
+ The general aim of these tests is to understand the impact of large flow table size and flow lookups on throughput.
+
+ The following list is not exhaustive but should indicate the type of tests that should be required. It is expected that more will be added.
+
+<br/>
+ - #####Test ID: LTD.Scalability.RFC2544.0PacketLoss
+
+ **Title**: RFC 2544 0% loss Scalability throughput test
+
+ **Prerequisite Test**:
+
+ **Priority**:
+
+ **Description**:
+
+ The aim of this test is to measure how throughput changes as the number of flows in the DUT increases.
+
+ For each frame size previously defined under [Default Test Parameters](#DefaultParams) and for each of the following number of flows:
+
+ - 1,000
+ - 2,000
+ - 2,000
+ - 4,000
+ - 8,000
+ - 16,000
+ - 32,000
+ - 64,000
+
+ The maximum 0% packet loss throughput should be determined in a manner identical to LTD.Throughput.RFC2544.PacketLossRatio.
+
+ **Expected Result**:
+
+ **Metrics Collected**:
+
+ The following are the metrics collected for this test: