docs/vswitchperf_ltd.rst

   1 CHARACTERIZE VSWITCH PERFORMANCE FOR TELCO NFV USE CASES LEVEL TEST DESIGN
   2 ==========================================================================
   3
   4 .. contents:: Table of Contents
   5
   6 1. Introduction
   7 ===============
   8
   9 The objective of the OPNFV project titled
  10 **“Characterize vSwitch Performance for Telco NFV Use Cases”**, is to
  11 evaluate a virtual switch to identify its suitability for a Telco
  12 Network Function Virtualization (NFV) environment. The intention of this
  13 Level Test Design (LTD) document is to specify the set of tests to carry
  14 out in order to objectively measure the current characteristics of a
  15 virtual switch in the Network Function Virtualization Infrastructure
  16 (NFVI) as well as the test pass criteria. The detailed test cases will
  17 be defined in `Section 2 <#DetailsOfTheLevelTestDesign>`__, preceded by
  18 the `Document identifier <#DocId>`__ and the `Scope <#Scope>`__.
  19
  20 This document is currently in draft form.
  21
  22 1.1. Document identifier
  23 ------------------------
  24
  25 The document id will be used to uniquely
  26 identify versions of the LTD. The format for the document id will be:
  27 OPNFV\_vswitchperf\_LTD\_ver\_NUM\_MONTH\_YEAR\_STATUS, where by the
  28 status is one of: draft, reviewed, corrected or final. The document id
  29 for this version of the LTD is:
  30 OPNFV\_vswitchperf\_LTD\_ver\_1.6\_Jan\_15\_DRAFT.
  31
  32 1.2. Scope
  33 ----------
  34
  35 The main purpose of this project is to specify a suite of
  36 performance tests in order to objectively measure the current packet
  37 transfer characteristics of a virtual switch in the NFVI. The intent of
  38 the project is to facilitate testing of any virtual switch. Thus, a
  39 generic suite of tests shall be developed, with no hard dependencies to
  40 a single implementation. In addition, the test case suite shall be
  41 architecture independent.
  42
  43 The test cases developed in this project shall not form part of a
  44 separate test framework, all of these tests may be inserted into the
  45 Continuous Integration Test Framework and/or the Platform Functionality
  46 Test Framework - if a vSwitch becomes a standard component of an OPNFV
  47 release.
  48
  49 1.3. References
  50 ---------------
  51
  52 *  `RFC 1242 Benchmarking Terminology for Network Interconnection
  53    Devices <http://www.ietf.org/rfc/rfc1242.txt>`__
  54 *  `RFC 2544 Benchmarking Methodology for Network Interconnect
  55    Devices <http://www.ietf.org/rfc/rfc2544.txt>`__
  56 *  `RFC 2285 Benchmarking Terminology for LAN Switching
  57    Devices <http://www.ietf.org/rfc/rfc2285.txt>`__
  58 *  `RFC 2889 Benchmarking Methodology for LAN Switching
  59    Devices <http://www.ietf.org/rfc/rfc2889.txt>`__
  60 *  `RFC 3918 Methodology for IP Multicast
  61    Benchmarking <http://www.ietf.org/rfc/rfc3918.txt>`__
  62 *  `RFC 4737 Packet Reordering
  63    Metrics <http://www.ietf.org/rfc/rfc4737.txt>`__
  64 *  `RFC 5481 Packet Delay Variation Applicability
  65    Statement <http://www.ietf.org/rfc/rfc5481.txt>`__
  66 *  `RFC 6201 Device Reset
  67    Characterization <http://tools.ietf.org/html/rfc6201>`__
  68
  69 2. Details of the Level Test Design
  70 ===================================
  71
  72 This section describes the features to be tested (`cf. 2.1
  73 <#FeaturesToBeTested>`__), the test approach (`cf. 2.2 <#Approach>`__);
  74 it also identifies the sets of test cases or scenarios (`cf. 2.3
  75 <#TestIdentification>`__) along with the pass/fail criteria (`cf. 2.4
  76 <#PassFail>`__) and the test deliverables (`cf. 2.5 <#TestDeliverables>`__).
  77
  78 2.1. Features to be tested
  79 --------------------------
  80
  81 Characterizing virtual switches (i.e. Device Under Test (DUT) in this document)
  82 includes measuring the following performance metrics:
  83
  84 - **Throughput** as defined by `RFC1242
  85   <https://www.rfc-editor.org/rfc/rfc1242.txt>`__: The maximum rate at which
  86   **none** of the offered frames are dropped by the DUT. The maximum frame
  87   rate and bit rate that can be transmitted by the DUT without any error
  88   should be recorded. Note there is an equivalent bit rate and a specific
  89   layer at which the payloads contribute to the bits. Errors and
  90   improperly formed frames or packets are dropped.
  91 - **Packet delay** introduced by the DUT and its cumulative effect on
  92   E2E networks. Frame delay can be measured equivalently.
  93 - **Packet delay variation**: measured from the perspective of the
  94   VNF/application. Packet delay variation is sometimes called "jitter".
  95   However, we will avoid the term "jitter" as the term holds different
  96   meaning to different groups of people. In this document we will
  97   simply use the term packet delay variation. The preferred form for this
  98   metric is the PDV form of delay variation defined in `RFC5481
  99   <https://www.rfc-editor.org/rfc/rfc5481.txt>`__.
 100 - **Packet loss** (within a configured waiting time at the receiver): All
 101   packets sent to the DUT should be accounted for.
 102 - **Burst behaviour**: measures the ability of the DUT to buffer packets.
 103 - **Packet re-ordering**: measures the ability of the device under test to
 104   maintain sending order throughout transfer to the destination.
 105 - **Packet correctness**: packets or Frames must be well-formed, in that
 106   they include all required fields, conform to length requirements, pass
 107   integrity checks, etc.
 108 - **Availability and capacity** of the DUT i.e. when the DUT is fully “up”
 109   and connected:
 110
 111   - Includes power consumption of the CPU (in various power states) and
 112     system.
 113   - Includes CPU utilization.
 114   - Includes the number of NIC interfaces supported.
 115   - Includes headroom of VM workload processing cores (i.e. available
 116     for applications).
 117
 118
 119 2.2. Approach
 120 ==============
 121
 122 In order to determine the packet transfer characteristics of a virtual
 123 switch, the tests will be broken down into the following categories:
 124
 125 2.2.1 Test Categories
 126 ----------------------
 127 - **Throughput Tests** to measure the maximum forwarding rate (in
 128   frames per second or fps) and bit rate (in Mbps) for a constant load
 129   (as defined by `RFC1242 <https://www.rfc-editor.org/rfc/rfc1242.txt>`__)
 130   without traffic loss.
 131 - **Packet and Frame Delay Tests** to measure average, min and max
 132   packet and frame delay for constant loads.
 133 - **Stream Performance Tests** (TCP, UDP) to measure bulk data transfer
 134   performance, i.e. how fast systems can send and receive data through
 135   the switch.
 136 - **Request/Response Performance** Tests (TCP, UDP) the measure the
 137   transaction rate through the switch.
 138 - **Packet Delay Tests** to understand latency distribution for
 139   different packet sizes and over an extended test run to uncover
 140   outliers.
 141 - **Scalability Tests** to understand how the virtual switch performs
 142   as the number of flows, active ports, complexity of the forwarding
 143   logic's configuration... it has to deal with increases.
 144 - **Control Path and Datapath Coupling** Tests, to understand how
 145   closely coupled the datapath and the control path are as well as the
 146   effect of this coupling on the performance of the DUT.
 147 - **CPU and Memory Consumption Tests** to understand the virtual
 148   switch’s footprint on the system, this includes:
 149
 150   * CPU utilization
 151   * Cache utilization
 152   * Memory footprint
 153   * Time To Establish Flows Tests.
 154
 155 - **Noisy Neighbour Tests**, to understand the effects of resource
 156   sharing on the performance of a virtual switch.
 157
 158 **Note:** some of the tests above can be conducted simultaneously where
 159 the combined results would be insightful, for example Packet/Frame Delay
 160 and Scalability.
 161
 162 2.2.2 Deployment Scenarios
 163 --------------------------
 164 The following represents possible deployments which can help to
 165 determine the performance of both the virtual switch and the datapath
 166 into the VNF:
 167
 168 Physical port → vSwitch → physical port
 169 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 170   .. code-block:: console
 171
 172                                                             _
 173        +--------------------------------------------------+  |
 174        |              +--------------------+              |  |
 175        |              |                    |              |  |
 176        |              |                    v              |  |  Host
 177        |   +--------------+            +--------------+   |  |
 178        |   |   phy port   |  vSwitch   |   phy port   |   |  |
 179        +---+--------------+------------+--------------+---+ _|
 180                   ^                           :
 181                   |                           |
 182                   :                           v
 183        +--------------------------------------------------+
 184        |                                                  |
 185        |                traffic generator                 |
 186        |                                                  |
 187        +--------------------------------------------------+
 188
 189
 190 Physical port → vSwitch → VNF → vSwitch → physical port
 191 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 192   .. code-block:: console
 193
 194                                                              _
 195        +---------------------------------------------------+  |
 196        |                                                   |  |
 197        |   +-------------------------------------------+   |  |
 198        |   |                 Application               |   |  |
 199        |   +-------------------------------------------+   |  |
 200        |       ^                                  :        |  |
 201        |       |                                  |        |  |  Guest
 202        |       :                                  v        |  |
 203        |   +---------------+           +---------------+   |  |
 204        |   | logical port 0|           | logical port 1|   |  |
 205        +---+---------------+-----------+---------------+---+ _|
 206                ^                                  :
 207                |                                  |
 208                :                                  v         _
 209        +---+---------------+----------+---------------+---+  |
 210        |   | logical port 0|          | logical port 1|   |  |
 211        |   +---------------+          +---------------+   |  |
 212        |       ^                                  :       |  |
 213        |       |                                  |       |  |  Host
 214        |       :                                  v       |  |
 215        |   +--------------+            +--------------+   |  |
 216        |   |   phy port   |  vSwitch   |   phy port   |   |  |
 217        +---+--------------+------------+--------------+---+ _|
 218                   ^                           :
 219                   |                           |
 220                   :                           v
 221        +--------------------------------------------------+
 222        |                                                  |
 223        |                traffic generator                 |
 224        |                                                  |
 225        +--------------------------------------------------+
 226
 227
 228 Physical port → vSwitch → VNF → vSwitch → VNF → vSwitch → physical port
 229 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 230
 231   .. code-block:: console
 232
 233                                                        _
 234     +----------------------+  +----------------------+  |
 235     |   Guest 1            |  |   Guest 2            |  |
 236     |   +---------------+  |  |   +---------------+  |  |
 237     |   |  Application  |  |  |   |  Application  |  |  |
 238     |   +---------------+  |  |   +---------------+  |  |
 239     |       ^       |      |  |       ^       |      |  |
 240     |       |       v      |  |       |       v      |  |  Guests
 241     |   +---------------+  |  |   +---------------+  |  |
 242     |   | logical ports |  |  |   | logical ports |  |  |
 243     |   |   0       1   |  |  |   |   0       1   |  |  |
 244     +---+---------------+--+  +---+---------------+--+ _|
 245             ^       :                 ^       :
 246             |       |                 |       |
 247             :       v                 :       v        _
 248     +---+---------------+---------+---------------+--+  |
 249     |   |   0       1   |         |   3       4   |  |  |
 250     |   | logical ports |         | logical ports |  |  |
 251     |   +---------------+         +---------------+  |  |
 252     |       ^       |                 ^       |      |  |  Host
 253     |       |       L-----------------+       v      |  |
 254     |   +--------------+          +--------------+   |  |
 255     |   |   phy ports  | vSwitch  |   phy ports  |   |  |
 256     +---+--------------+----------+--------------+---+ _|
 257             ^       :                 ^       :
 258             |       |                 |       |
 259             :       v                 :       v
 260     +--------------------------------------------------+
 261     |                                                  |
 262     |                traffic generator                 |
 263     |                                                  |
 264     +--------------------------------------------------+
 265
 266
 267 Physical port → vSwitch → VNF
 268 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 269
 270   .. code-block:: console
 271
 272                                                           _
 273     +---------------------------------------------------+  |
 274     |                                                   |  |
 275     |   +-------------------------------------------+   |  |
 276     |   |                 Application               |   |  |
 277     |   +-------------------------------------------+   |  |
 278     |       ^                                           |  |
 279     |       |                                           |  |  Guest
 280     |       :                                           |  |
 281     |   +---------------+                               |  |
 282     |   | logical port 0|                               |  |
 283     +---+---------------+-------------------------------+ _|
 284             ^
 285             |
 286             :                                            _
 287     +---+---------------+------------------------------+  |
 288     |   | logical port 0|                              |  |
 289     |   +---------------+                              |  |
 290     |       ^                                          |  |
 291     |       |                                          |  |  Host
 292     |       :                                          |  |
 293     |   +--------------+                               |  |
 294     |   |   phy port   |  vSwitch                      |  |
 295     +---+--------------+------------ -------------- ---+ _|
 296                ^
 297                |
 298                :
 299     +--------------------------------------------------+
 300     |                                                  |
 301     |                traffic generator                 |
 302     |                                                  |
 303     +--------------------------------------------------+
 304
 305 VNF → vSwitch → physical port
 306 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 307
 308   .. code-block:: console
 309
 310                                                           _
 311     +---------------------------------------------------+  |
 312     |                                                   |  |
 313     |   +-------------------------------------------+   |  |
 314     |   |                 Application               |   |  |
 315     |   +-------------------------------------------+   |  |
 316     |                                          :        |  |
 317     |                                          |        |  |  Guest
 318     |                                          v        |  |
 319     |                               +---------------+   |  |
 320     |                               | logical port  |   |  |
 321     +-------------------------------+---------------+---+ _|
 322                                                :
 323                                                |
 324                                                v         _
 325     +------------------------------+---------------+---+  |
 326     |                              | logical port  |   |  |
 327     |                              +---------------+   |  |
 328     |                                          :       |  |
 329     |                                          |       |  |  Host
 330     |                                          v       |  |
 331     |                               +--------------+   |  |
 332     |                     vSwitch   |   phy port   |   |  |
 333     +-------------------------------+--------------+---+ _|
 334                                            :
 335                                            |
 336                                            v
 337     +--------------------------------------------------+
 338     |                                                  |
 339     |                traffic generator                 |
 340     |                                                  |
 341     +--------------------------------------------------+
 342
 343 VNF → vSwitch → VNF → vSwitch
 344 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 345
 346   .. code-block:: console
 347
 348                                                              _
 349     +-------------------------+  +-------------------------+  |
 350     |   Guest 1               |  |   Guest 2               |  |
 351     |   +-----------------+   |  |   +-----------------+   |  |
 352     |   |   Application   |   |  |   |   Application   |   |  |
 353     |   +-----------------+   |  |   +-----------------+   |  |
 354     |                :        |  |       ^                 |  |
 355     |                |        |  |       |                 |  |  Guest
 356     |                v        |  |       :                 |  |
 357     |     +---------------+   |  |   +---------------+     |  |
 358     |     | logical port 0|   |  |   | logical port 0|     |  |
 359     +-----+---------------+---+  +---+---------------+-----+ _|
 360                     :                    ^
 361                     |                    |
 362                     v                    :                    _
 363     +----+---------------+------------+---------------+-----+  |
 364     |    |     port 0    |            |     port 1    |     |  |
 365     |    +---------------+            +---------------+     |  |
 366     |              :                    ^                   |  |
 367     |              |                    |                   |  |  Host
 368     |              +--------------------+                   |  |
 369     |                                                       |  |
 370     |                     vswitch                           |  |
 371     +-------------------------------------------------------+ _|
 372
 373 HOST 1(Physical port → virtual switch → VNF → virtual switch →
 374 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 375 Physical port) → HOST 2(Physical port → virtual switch → VNF →
 376 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 377 virtual switch → Physical port)
 378 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 379
 380   .. code-block:: console
 381
 382
 383     +--------------------------------------------+   +------------------------------------------+
 384     |   +---------------------------------+      |   |    +--------------------------------+    |
 385     |   |          Application            |      |   |    |         Application            |    |
 386     |   +----------------------------+----+      |   |    +-------------------------+------+    |
 387     |         ^                      |           |   |           ^                  |           |
 388     |         |                      v           |   |           |                  v           |
 389     | +------------------+  +------------------+ |   | +------------------+  +----------------+ |
 390     | | Logical port 0   |  | Logical port 1   | |   | | Logical port 0   |  | Logical port 1 | |
 391     +-+------------------+--+------------------+-+   +-+------------------+--+----------------+-+
 392               ^                      |                          ^                  |
 393               |                      |                          |                  |
 394               |                      v                          |                  v
 395     +-+------------------+--+------------------+-+   +-+------------------+--+----------------+-+
 396     | | Logical port 0   |  |  Logical port 1  | |   | | Logical port 0   |  | Logical port 1 | |
 397     | +------------------+  +------------------+ |   | +------------------+  +----------------+ |
 398     |          ^                       |         |   |          ^                  |            |
 399     |          |                       |         |   |          |                  |            |
 400     |          |       vswitch         v         |   |          |     vswitch      v            |
 401     | +--------+---------+  +------------------+ |   | +------------------+  +----------------+ |
 402     | |    phy port      |  |    phy port      | |   | |  phy port        |  |  phy port      | |
 403     +-+------------------+--+------------------+-+   +-+------------------+--+----------------+-+
 404                ^                       |                        ^                  |
 405                |                       |                        |                  |
 406                |                        ------------------------                   v
 407     +-------------------------------------------------------------------------------------------+
 408     |                                                                                           |
 409     |                                    traffic generator                                      |
 410     |                                                                                           |
 411     +-------------------------------------------------------------------------------------------+
 412
 413 **Note:** For tests where the traffic generator and/or measurement
 414 receiver are implemented on VM and connected to the virtual switch
 415 through vNIC, the issues of shared resources and interactions between
 416 the measurement devices and the device under test must be considered.
 417
 418 2.2.3 General Methodology:
 419 --------------------------
 420 To establish the baseline performance of the virtual switch, tests would
 421 initially be run with a simple workload in the VNF (the recommended
 422 simple workload VNF would be `DPDK <http://www.dpdk.org/>`__'s testpmd
 423 application forwarding packets in a VM or vloop\_vnf a simple kernel
 424 module that forwards traffic between two network interfaces inside the
 425 virtualized environment while bypassing the networking stack).
 426 Subsequently, the tests would also be executed with a real Telco
 427 workload running in the VNF, which would exercise the virtual switch in
 428 the context of higher level Telco NFV use cases, and prove that its
 429 underlying characteristics and behaviour can be measured and validated.
 430 Suitable real Telco workload VNFs are yet to be identified.
 431
 432 2.2.3.1 Default Test Parameters
 433 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 434
 435 The following list identifies the default parameters for suite of
 436 tests:
 437
 438 -  Reference application: Simple forwarding or Open Source VNF.
 439 -  Frame size (bytes): 64, 128, 256, 512, 1024, 1280, 1518, 2K, 4k OR
 440    Packet size based on use-case (e.g. RTP 64B, 256B).
 441 -  Reordering check: Tests should confirm that packets within a flow are
 442    not reordered.
 443 -  Duplex: Unidirectional / Bidirectional. Default: Full duplex with
 444    traffic transmitting in both directions, as network traffic generally
 445    does not flow in a single direction. By default the data rate of
 446    transmitted traffic should be the same in both directions, please
 447    note that asymmetric traffic (e.g. downlink-heavy) tests will be
 448    mentioned explicitly for the relevant test cases.
 449 -  Number of Flows: Default for non scalability tests is a single flow.
 450    For scalability tests the goal is to test with maximum supported
 451    flows but where possible will test up to 10 Million flows. Start with
 452    a single flow and scale up. By default flows should be added
 453    sequentially, tests that add flows simultaneously will explicitly
 454    call out their flow addition behaviour. Packets are generated across
 455    the flows uniformly with no burstiness.
 456 -  Traffic Types: UDP, SCTP, RTP, GTP and UDP traffic.
 457 -  Deployment scenarios are:
 458 -  Physical → virtual switch → physical.
 459 -  Physical → virtual switch → VNF → virtual switch → physical.
 460 -  Physical → virtual switch → VNF → virtual switch → VNF → virtual
 461    switch → physical.
 462 -  Physical → virtual switch → VNF.
 463 -  VNF → virtual switch → Physical.
 464 -  VNF → virtual switch → VNF.
 465
 466 Tests MUST have these parameters unless otherwise stated. **Test cases
 467 with non default parameters will be stated explicitly**.
 468
 469 **Note**: For throughput tests unless stated otherwise, test
 470 configurations should ensure that traffic traverses the installed flows
 471 through the switch, i.e. flows are installed and have an appropriate
 472 time out that doesn't expire before packet transmission starts.
 473
 474 2.2.3.2 Flow Classification
 475 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 476
 477 Virtual switches classify packets into flows by processing and matching
 478 particular header fields in the packet/frame and/or the input port where
 479 the packets/frames arrived. The vSwitch then carries out an action on
 480 the group of packets that match the classification parameters. Thus a
 481 flow is considered to be a sequence of packets that have a shared set of
 482 header field values or have arrived on the same port and have the same
 483 action applied to them. Performance results can vary based on the
 484 parameters the vSwitch uses to match for a flow. The recommended flow
 485 classification parameters for L3 vSwitch performance tests are: the
 486 input port, the source IP address, the destination IP address and the
 487 Ethernet protocol type field. It is essential to increase the flow
 488 time-out time on a vSwitch before conducting any performance tests that
 489 do not measure the flow set-up time. Normally the first packet of a
 490 particular flow will install the flow in the vSwitch which adds an
 491 additional latency, subsequent packets of the same flow are not subject
 492 to this latency if the flow is already installed on the vSwitch.
 493
 494 2.2.3.3 Test Priority
 495 ~~~~~~~~~~~~~~~~~~~~~
 496
 497 Tests will be assigned a priority in order to determine which tests
 498 should be implemented immediately and which tests implementations
 499 can be deferred.
 500
 501 Priority can be of following types: - Urgent: Must be implemented
 502 immediately. - High: Must be implemented in the next release. - Medium:
 503 May be implemented after the release. - Low: May or may not be
 504 implemented at all.
 505
 506 2.2.3.4 SUT Setup
 507 ~~~~~~~~~~~~~~~~~
 508
 509 The SUT should be configured to its "default" state. The
 510 SUT's configuration or set-up must not change between tests in any way
 511 other than what is required to do the test. All supported protocols must
 512 be configured and enabled for each test set up.
 513
 514 2.2.3.4.1 Port Configuration
 515 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 516
 517 The DUT should be configured with n ports where
 518 n is a multiple of 2. Half of the ports on the DUT should be used as
 519 ingress ports and the other half of the ports on the DUT should be used
 520 as egress ports. Where a DUT has more than 2 ports, the ingress data
 521 streams should be set-up so that they transmit packets to the egress
 522 ports in sequence so that there is an even distribution of traffic
 523 across ports. For example, if a DUT has 4 ports 0(ingress), 1(ingress),
 524 2(egress) and 3(egress), the traffic stream directed at port 0 should
 525 output a packet to port 2 followed by a packet to port 3. The traffic
 526 stream directed at port 1 should also output a packet to port 2 followed
 527 by a packet to port 3.
 528
 529 2.2.3.4.2 Frame Formats
 530 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 531
 532 Frame formats Layer 2 (data link layer) protocols
 533 ++++++++++++++++++++++++++++++++++++++++++++++++++
 534 -  Ethernet II
 535
 536   .. code-block:: console
 537
 538      +---------------------+--------------------+-----------+
 539      |   Ethernet Header   |       Payload      | Check Sum |
 540      +---------------------+--------------------+-----------+
 541      |_____________________|____________________|___________|
 542            14 Bytes            46 - 1500 Bytes      4 Bytes
 543
 544 Layer 3 (network layer) protocols
 545 ++++++++++++++++++++++++++++++++++
 546
 547 -  IPv4
 548
 549   .. code-block:: console
 550
 551      +---------------------+--------------------+--------------------+-----------+
 552      |   Ethernet Header   |      IP Header     |       Payload      | Check Sum |
 553      +---------------------+--------------------+--------------------+-----------+
 554      |_____________________|____________________|____________________|___________|
 555            14 Bytes            20 bytes             26 - 1480 Bytes      4 Bytes
 556
 557 -  IPv6
 558
 559   .. code-block:: console
 560
 561      +---------------------+--------------------+--------------------+-----------+
 562      |   Ethernet Header   |      IP Header     |       Payload      | Check Sum |
 563      +---------------------+--------------------+--------------------+-----------+
 564      |_____________________|____________________|____________________|___________|
 565            14 Bytes            40 bytes             26 - 1460 Bytes      4 Bytes
 566
 567 Layer 4 (transport layer) protocols
 568 ++++++++++++++++++++++++++++++++++++
 569   - TCP
 570   - UDP
 571   - SCTP
 572
 573   .. code-block:: console
 574
 575      +---------------------+--------------------+-----------------+--------------------+-----------+
 576      |   Ethernet Header   |      IP Header     | Layer 4 Header  |       Payload      | Check Sum |
 577      +---------------------+--------------------+-----------------+--------------------+-----------+
 578      |_____________________|____________________|_________________|____________________|___________|
 579            14 Bytes            40 bytes               20 Bytes       6 - 1460 Bytes      4 Bytes
 580
 581 Layer 5 (application layer) protocols
 582 +++++++++++++++++++++++++++++++++++++
 583   - RTP
 584   - GTP
 585
 586   .. code-block:: console
 587
 588      +---------------------+--------------------+-----------------+--------------------+-----------+
 589      |   Ethernet Header   |      IP Header     | Layer 4 Header  |       Payload      | Check Sum |
 590      +---------------------+--------------------+-----------------+--------------------+-----------+
 591      |_____________________|____________________|_________________|____________________|___________|
 592            14 Bytes            20 bytes               20 Bytes         Min 6 Bytes       4 Bytes
 593
 594
 595 2.2.3.4.3 Packet Throughput
 596 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 597 There is a difference between an Ethernet frame,
 598 an IP packet, and a UDP datagram. In the seven-layer OSI model of
 599 computer networking, packet refers to a data unit at layer 3 (network
 600 layer). The correct term for a data unit at layer 2 (data link layer) is
 601 a frame, and at layer 4 (transport layer) is a segment or datagram.
 602
 603 Important concepts related to 10GbE performance are frame rate and
 604 throughput. The MAC bit rate of 10GbE, defined in the IEEE standard 802
 605 .3ae, is 10 billion bits per second. Frame rate is based on the bit rate
 606 and frame format definitions. Throughput, defined in IETF RFC 1242, is
 607 the highest rate at which the system under test can forward the offered
 608 load, without loss.
 609
 610 The frame rate for 10GbE is determined by a formula that divides the 10
 611 billion bits per second by the preamble + frame length + inter-frame
 612 gap.
 613
 614 The maximum frame rate is calculated using the minimum values of the
 615 following parameters, as described in the IEEE 802 .3ae standard:
 616
 617 -  Preamble: 8 bytes \* 8 = 64 bits
 618 -  Frame Length: 64 bytes (minimum) \* 8 = 512 bits
 619 -  Inter-frame Gap: 12 bytes (minimum) \* 8 = 96 bits
 620
 621 Therefore, Maximum Frame Rate (64B Frames)
 622 = MAC Transmit Bit Rate / (Preamble + Frame Length + Inter-frame Gap)
 623 = 10,000,000,000 / (64 + 512 + 96)
 624 = 10,000,000,000 / 672
 625 = 14,880,952.38 frame per second (fps)
 626
 627 2.2.3.4.4 System isolation and validation
 628 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 629
 630 A key consideration when conducting any sort of benchmark is trying to
 631 ensure the consistency and repeatability of test results between runs.
 632 When benchmarking the performance of a virtual switch there are many
 633 factors that can affect the consistency of results. This section
 634 describes these factors and the measures that can be taken to limit
 635 their effects. In addition, this section will outline some system tests
 636 to validate the platform and the VNF before conducting any vSwitch
 637 benchmarking tests.
 638
 639 System Isolation
 640 ++++++++++++++++
 641 When conducting a benchmarking test on any SUT, it is essential to limit
 642 (and if reasonable, eliminate) any noise that may interfere with the
 643 accuracy of the metrics collected by the test. This noise may be
 644 introduced by other hardware or software (OS, other applications), and
 645 can result in significantly varying performance metrics being collected
 646 between consecutive runs of the same test. In the case of characterizing
 647 the performance of a virtual switch, there are a number of configuration
 648 parameters that can help increase the repeatability and stability of
 649 test results, including:
 650
 651 -  OS/GRUB configuration:
 652
 653    -  maxcpus = n where n >= 0; limits the kernel to using 'n'
 654       processors. Only use exactly what you need.
 655    -  isolcpus: Isolate CPUs from the general scheduler. Isolate all
 656       CPUs bar one which will be used by the OS.
 657    -  use taskset to affinitize the forwarding application and the VNFs
 658       onto isolated cores. VNFs and the vSwitch should be allocated
 659       their own cores, i.e. must not share the same cores. vCPUs for the
 660       VNF should be affinitized to individual cores also.
 661    -  Limit the amount of background applications that are running and
 662       set OS to boot to runlevel 3. Make sure to kill any unnecessary
 663       system processes/daemons.
 664    -  Only enable hardware that you need to use for your test – to
 665       ensure there are no other interrupts on the system.
 666    -  Configure NIC interrupts to only use the cores that are not
 667       allocated to any other process (VNF/vSwitch).
 668
 669 -  NUMA configuration: Any unused sockets in a multi-socket system
 670    should be disabled.
 671 -  CPU pinning: The vSwitch and the VNF should each be affinitized to
 672    separate logical cores using a combination of maxcpus, isolcpus and
 673    taskset.
 674 -  BIOS configuration: BIOS should be configured for performance where
 675    an explicit option exists, sleep states should be disabled, any
 676    virtualization optimization technologies should be enabled, and
 677    hyperthreading should also be enabled.
 678
 679 System Validation
 680 +++++++++++++++++
 681 System validation is broken down into two sub-categories: Platform
 682 validation and VNF validation. The validation test itself involves
 683 verifying the forwarding capability and stability for the sub-system
 684 under test. The rationale behind system validation is two fold. Firstly
 685 to give a tester confidence in the stability of the platform or VNF that
 686 is being tested; and secondly to provide base performance comparison
 687 points to understand the overhead introduced by the virtual switch.
 688
 689 * Benchmark platform forwarding capability: This is an OPTIONAL test
 690   used to verify the platform and measure the base performance (maximum
 691   forwarding rate in fps and latency) that can be achieved by the
 692   platform without a vSwitch or a VNF. The following diagram outlines
 693   the set-up for benchmarking Platform forwarding capability:
 694
 695   .. code-block:: console
 696
 697                                                             __
 698        +--------------------------------------------------+   |
 699        |   +------------------------------------------+   |   |
 700        |   |                                          |   |   |
 701        |   |          l2fw or DPDK L2FWD app          |   |  Host
 702        |   |                                          |   |   |
 703        |   +------------------------------------------+   |   |
 704        |   |                 NIC                      |   |   |
 705        +---+------------------------------------------+---+ __|
 706                   ^                           :
 707                   |                           |
 708                   :                           v
 709        +--------------------------------------------------+
 710        |                                                  |
 711        |                traffic generator                 |
 712        |                                                  |
 713        +--------------------------------------------------+
 714
 715 * Benchmark VNF forwarding capability: This test is used to verify
 716   the VNF and measure the base performance (maximum forwarding rate in
 717   fps and latency) that can be achieved by the VNF without a vSwitch.
 718   The performance metrics collected by this test will serve as a key
 719   comparison point for NIC passthrough technologies and vSwitches. VNF
 720   in this context refers to the hypervisor and the VM. The following
 721   diagram outlines the set-up for benchmarking VNF forwarding
 722   capability:
 723
 724   .. code-block:: console
 725
 726                                                             __
 727        +--------------------------------------------------+   |
 728        |   +------------------------------------------+   |   |
 729        |   |                                          |   |   |
 730        |   |                 VNF                      |   |   |
 731        |   |                                          |   |   |
 732        |   +------------------------------------------+   |   |
 733        |   |          Passthrough/SR-IOV              |   |  Host
 734        |   +------------------------------------------+   |   |
 735        |   |                 NIC                      |   |   |
 736        +---+------------------------------------------+---+ __|
 737                   ^                           :
 738                   |                           |
 739                   :                           v
 740        +--------------------------------------------------+
 741        |                                                  |
 742        |                traffic generator                 |
 743        |                                                  |
 744        +--------------------------------------------------+
 745
 746
 747 Methodology to benchmark Platform/VNF forwarding capability
 748 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 749
 750 The recommended methodology for the platform/VNF validation and
 751 benchmark is: - Run `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__
 752 Maximum Forwarding Rate test, this test will produce maximum
 753 forwarding rate and latency results that will serve as the
 754 expected values. These expected values can be used in
 755 subsequent steps or compared with in subsequent validation tests. -
 756 Transmit bidirectional traffic at line rate/max forwarding rate
 757 (whichever is higher) for at least 72 hours, measure throughput (fps)
 758 and latency. - Note: Traffic should be bidirectional. - Establish a
 759 baseline forwarding rate for what the platform can achieve. - Additional
 760 validation: After the test has completed for 72 hours run bidirectional
 761 traffic at the maximum forwarding rate once more to see if the system is
 762 still functional and measure throughput (fps) and latency. Compare the
 763 measure the new obtained values with the expected values.
 764
 765 **NOTE 1**: How the Platform is configured for its forwarding capability
 766 test (BIOS settings, GRUB configuration, runlevel...) is how the
 767 platform should be configured for every test after this
 768
 769 **NOTE 2**: How the VNF is configured for its forwarding capability test
 770 (# of vCPUs, vNICs, Memory, affinitization…) is how it should be
 771 configured for every test that uses a VNF after this.
 772
 773 2.2.4 RFCs for testing switch performance
 774 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 775
 776 The starting point for defining the suite of tests for benchmarking the
 777 performance of a virtual switch is to take existing RFCs and standards
 778 that were designed to test their physical counterparts and adapting them
 779 for testing virtual switches. The rationale behind this is to establish
 780 a fair comparison between the performance of virtual and physical
 781 switches. This section outlines the RFCs that are used by this
 782 specification.
 783
 784 RFC 1242 Benchmarking Terminology for Network Interconnection
 785 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 786 Devices RFC 1242 defines the terminology that is used in describing
 787 performance benchmarking tests and their results. Definitions and
 788 discussions covered include: Back-to-back, bridge, bridge/router,
 789 constant load, data link frame size, frame loss rate, inter frame gap,
 790 latency, and many more.
 791
 792 RFC 2544 Benchmarking Methodology for Network Interconnect Devices
 793 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 794 RFC 2544 outlines a benchmarking methodology for network Interconnect
 795 Devices. The methodology results in performance metrics such as latency,
 796 frame loss percentage, and maximum data throughput.
 797
 798 In this document network “throughput” (measured in millions of frames
 799 per second) is based on RFC 2544, unless otherwise noted. Frame size
 800 refers to Ethernet frames ranging from smallest frames of 64 bytes to
 801 largest frames of 4K bytes.
 802
 803 Types of tests are:
 804
 805 1. Throughput test defines the maximum number of frames per second
 806    that can be transmitted without any error.
 807
 808 2. Latency test measures the time required for a frame to travel from
 809    the originating device through the network to the destination device.
 810    Please note that RFC2544 Latency measurement will be superseded with
 811    a measurement of average latency over all successfully transferred
 812    packets or frames.
 813
 814 3. Frame loss test measures the network’s
 815    response in overload conditions - a critical indicator of the
 816    network’s ability to support real-time applications in which a
 817    large amount of frame loss will rapidly degrade service quality.
 818
 819 4. Burst test assesses the buffering capability of a switch. It
 820    measures the maximum number of frames received at full line rate
 821    before a frame is lost. In carrier Ethernet networks, this
 822    measurement validates the excess information rate (EIR) as defined in
 823    many SLAs.
 824
 825 5. System recovery to characterize speed of recovery from an overload
 826    condition.
 827
 828 6. Reset to characterize speed of recovery from device or software
 829    reset. This type of test has been updated by `RFC6201 <https://www.rfc-editor.org/rfc/rfc6201.txt>`__ as such,
 830    the methodology defined by this specification will be that of RFC 6201.
 831
 832 Although not included in the defined RFC 2544 standard, another crucial
 833 measurement in Ethernet networking is packet delay variation. The
 834 definition set out by this specification comes from
 835 `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__.
 836
 837 RFC 2285 Benchmarking Terminology for LAN Switching Devices
 838 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 839 RFC 2285 defines the terminology that is used to describe the
 840 terminology for benchmarking a LAN switching device. It extends RFC
 841 1242 and defines: DUTs, SUTs, Traffic orientation and distribution,
 842 bursts, loads, forwarding rates, etc.
 843
 844 RFC 2889 Benchmarking Methodology for LAN Switching
 845 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 846 RFC 2889 outlines a benchmarking methodology for LAN switching, it
 847 extends RFC 2544. The outlined methodology gathers performance
 848 metrics for forwarding, congestion control, latency, address handling
 849 and finally filtering.
 850
 851 RFC 3918 Methodology for IP Multicast Benchmarking
 852 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 853 RFC 3918 outlines a methodology for IP Multicast benchmarking.
 854
 855 RFC 4737 Packet Reordering Metrics
 856 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 857 RFC 4737 describes metrics for identifying and counting re-ordered
 858 packets within a stream, and metrics to measure the extent each
 859 packet has been re-ordered.
 860
 861 RFC 5481 Packet Delay Variation Applicability Statement
 862 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 863 RFC 5481 defined two common, but different forms of delay variation
 864 metrics, and compares the metrics over a range of networking
 865 circumstances and tasks. The most suitable form for vSwitch
 866 benchmarking is the "PDV" form.
 867
 868 RFC 6201 Device Reset Characterization
 869 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 870 RFC 6201 extends the methodology for characterizing the speed of
 871 recovery of the DUT from device or software reset described in RFC
 872 2544.
 873
 874 2.2.5 Details of the Test Report
 875 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 876
 877 There are a number of parameters related to the system, DUT and tests
 878 that can affect the repeatability of a test results and should be
 879 recorded. In order to minimise the variation in the results of a test,
 880 it is recommended that the test report includes the following information:
 881
 882 -  Hardware details including:
 883
 884    -  Platform details.
 885    -  Processor details.
 886    -  Memory information (see below)
 887    -  Number of enabled cores.
 888    -  Number of cores used for the test.
 889    -  Number of physical NICs, as well as their details (manufacturer,
 890       versions, type and the PCI slot they are plugged into).
 891    -  NIC interrupt configuration.
 892    -  BIOS version, release date and any configurations that were
 893       modified.
 894
 895 -  Software details including:
 896
 897    -  OS version (for host and VNF)
 898    -  Kernel version (for host and VNF)
 899    -  GRUB boot parameters (for host and VNF).
 900    -  Hypervisor details (Type and version).
 901    -  Selected vSwitch, version number or commit id used.
 902    -  vSwitch launch command line if it has been parameterised.
 903    -  Memory allocation to the vSwitch – which NUMA node it is using,
 904       and how many memory channels.
 905    -  Where the vswitch is built from source: compiler details including
 906       versions and the flags that were used to compile the vSwitch.
 907    -  DPDK or any other SW dependency version number or commit id used.
 908    -  Memory allocation to a VM - if it's from Hugpages/elsewhere.
 909    -  VM storage type: snapshot/independent persistent/independent
 910       non-persistent.
 911    -  Number of VMs.
 912    -  Number of Virtual NICs (vNICs), versions, type and driver.
 913    -  Number of virtual CPUs and their core affinity on the host.
 914    -  Number vNIC interrupt configuration.
 915    -  Thread affinitization for the applications (including the vSwitch
 916       itself) on the host.
 917    -  Details of Resource isolation, such as CPUs designated for
 918       Host/Kernel (isolcpu) and CPUs designated for specific processes
 919       (taskset).
 920
 921 -  Memory Details
 922
 923    -  Total memory
 924    -  Type of memory
 925    -  Used memory
 926    -  Active memory
 927    -  Inactive memory
 928    -  Free memory
 929    -  Buffer memory
 930    -  Swap cache
 931    -  Total swap
 932    -  Used swap
 933    -  Free swap
 934
 935 -  Test duration.
 936 -  Number of flows.
 937 -  Traffic Information:
 938
 939    -  Traffic type - UDP, TCP, IMIX / Other.
 940    -  Packet Sizes.
 941
 942 -  Deployment Scenario.
 943
 944 **Note**: Tests that require additional parameters to be recorded will
 945 explicitly specify this.
 946
 947 2.3. Test identification
 948 ------------------------
 949 2.3.1 Throughput tests
 950 ~~~~~~~~~~~~~~~~~~~~~~
 951 The following tests aim to determine the maximum forwarding rate that
 952 can be achieved with a virtual switch. The list is not exhaustive but
 953 should indicate the type of tests that should be required. It is
 954 expected that more will be added.
 955
 956 Test ID: LTD.Throughput.RFC2544.PacketLossRatio
 957 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 958     **Title**: RFC 2544 X% packet loss ratio Throughput and Latency Test
 959
 960     **Prerequisite Test**: N/A
 961
 962     **Priority**:
 963
 964     **Description**:
 965
 966     This test determines the DUT's maximum forwarding rate with X% traffic
 967     loss for a constant load (fixed length frames at a fixed interval time).
 968     The default loss percentages to be tested are: - X = 0% - X = 10^-7%
 969
 970     Note: Other values can be tested if required by the user.
 971
 972     The selected frame sizes are those previously defined under `Default
 973     Test Parameters <#DefaultParams>`__. The test can also be used to
 974     determine the average latency of the traffic.
 975
 976     Under the `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__
 977     test methodology, the test duration will
 978     include a number of trials; each trial should run for a minimum period
 979     of 60 seconds. A binary search methodology must be applied for each
 980     trial to obtain the final result.
 981
 982     **Expected Result**: At the end of each trial, the presence or absence
 983     of loss determines the modification of offered load for the next trial,
 984     converging on a maximum rate, or
 985     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ Throughput with X% loss.
 986     The Throughput load is re-used in related
 987     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ tests and other
 988     tests.
 989
 990     **Metrics Collected**:
 991
 992     The following are the metrics collected for this test:
 993
 994     -  The maximum forwarding rate in Frames Per Second (FPS) and Mbps of
 995        the DUT for each frame size with X% packet loss.
 996     -  The average latency of the traffic flow when passing through the DUT
 997        (if testing for latency, note that this average is different from the
 998        test specified in Section 26.3 of
 999        `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__).
1000     -  CPU and memory utilization may also be collected as part of this
1001        test, to determine the vSwitch's performance footprint on the system.
1002
1003 Test ID: LTD.Throughput.RFC2544.PacketLossRatioFrameModification
1004 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1005     **Title**: RFC 2544 X% packet loss Throughput and Latency Test with
1006     packet modification
1007
1008     **Prerequisite Test**: N/A
1009
1010     **Priority**:
1011
1012     **Description**:
1013
1014     This test determines the DUT's maximum forwarding rate with X% traffic
1015     loss for a constant load (fixed length frames at a fixed interval time).
1016     The default loss percentages to be tested are: - X = 0% - X = 10^-7%
1017
1018     Note: Other values can be tested if required by the user.
1019
1020     The selected frame sizes are those previously defined under `Default
1021     Test Parameters <#DefaultParams>`__. The test can also be used to
1022     determine the average latency of the traffic.
1023
1024     Under the `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__
1025     test methodology, the test duration will
1026     include a number of trials; each trial should run for a minimum period
1027     of 60 seconds. A binary search methodology must be applied for each
1028     trial to obtain the final result.
1029
1030     During this test, the DUT must perform the following operations on the
1031     traffic flow:
1032
1033     -  Perform packet parsing on the DUT's ingress port.
1034     -  Perform any relevant address look-ups on the DUT's ingress ports.
1035     -  Modify the packet header before forwarding the packet to the DUT's
1036        egress port. Packet modifications include:
1037
1038        -  Modifying the Ethernet source or destination MAC address.
1039        -  Modifying/adding a VLAN tag. (**Recommended**).
1040        -  Modifying/adding a MPLS tag.
1041        -  Modifying the source or destination ip address.
1042        -  Modifying the TOS/DSCP field.
1043        -  Modifying the source or destination ports for UDP/TCP/SCTP.
1044        -  Modifying the TTL.
1045
1046     **Expected Result**: The Packet parsing/modifications require some
1047     additional degree of processing resource, therefore the
1048     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__
1049     Throughput is expected to be somewhat lower than the Throughput level
1050     measured without additional steps. The reduction is expected to be
1051     greatest on tests with the smallest packet sizes (greatest header
1052     processing rates).
1053
1054     **Metrics Collected**:
1055
1056     The following are the metrics collected for this test:
1057
1058     -  The maximum forwarding rate in Frames Per Second (FPS) and Mbps of
1059        the DUT for each frame size with X% packet loss and packet
1060        modification operations being performed by the DUT.
1061     -  The average latency of the traffic flow when passing through the DUT
1062        (if testing for latency, note that this average is different from the
1063        test specified in Section 26.3 of
1064        `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__).
1065     -  The `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__
1066        PDV form of delay variation on the traffic flow,
1067        using the 99th percentile.
1068     -  CPU and memory utilization may also be collected as part of this
1069        test, to determine the vSwitch's performance footprint on the system.
1070
1071 Test ID: LTD.Throughput.RFC2544.Profile
1072 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1073     **Title**: RFC 2544 Throughput and Latency Profile
1074
1075     **Prerequisite Test**: N/A
1076
1077     **Priority**:
1078
1079     **Description**:
1080
1081     This test reveals how throughput and latency degrades as the offered
1082     rate varies in the region of the DUT's maximum forwarding rate as
1083     determined by LTD.Throughput.RFC2544.PacketLossRatio (0% Packet Loss).
1084     For example it can be used to determine if the degradation of throughput
1085     and latency as the offered rate increases is slow and graceful or sudden
1086     and severe.
1087
1088     The selected frame sizes are those previously defined under `Default
1089     Test Parameters <#DefaultParams>`__.
1090
1091     The offered traffic rate is described as a percentage delta with respect
1092     to the DUT's maximum forwarding rate as determined by
1093     LTD.Throughput.RFC2544.PacketLoss Ratio (0% Packet Loss case). A delta
1094     of 0% is equivalent to an offered traffic rate equal to the maximum
1095     forwarding rate; A delta of +50% indicates an offered rate half-way
1096     between the maximum forwarding rate and line-rate, whereas a delta of
1097     -50% indicates an offered rate of half the maximum rate. Therefore the
1098     range of the delta figure is natuarlly bounded at -100% (zero offered
1099     traffic) and +100% (traffic offered at line rate).
1100
1101     The following deltas to the maximum forwarding rate should be applied:
1102
1103     -  -50%, -10%, 0%, +10% & +50%
1104
1105     **Expected Result**: For each packet size a profile should be produced
1106     of how throughput and latency vary with offered rate.
1107
1108     **Metrics Collected**:
1109
1110     The following are the metrics collected for this test:
1111
1112     -  The forwarding rate in Frames Per Second (FPS) and Mbps of the DUT
1113        for each delta to the maximum forwarding rate and for each frame
1114        size.
1115     -  The average latency for each delta to the maximum forwarding rate and
1116        for each frame size.
1117     -  CPU and memory utilization may also be collected as part of this
1118        test, to determine the vSwitch's performance footprint on the system.
1119     -  Any failures experienced (for example if the vSwitch crashes, stops
1120        processing packets, restarts or becomes unresponsive to commands)
1121        when the offered load is above Maximum Throughput MUST be recorded
1122        and reported with the results.
1123
1124 Test ID: LTD.Throughput.RFC2544.SystemRecoveryTime
1125 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1126     **Title**: RFC 2544 System Recovery Time Test
1127
1128     **Prerequisite Test** LTD.Throughput.RFC2544.PacketLossRatio
1129
1130     **Priority**:
1131
1132     **Description**:
1133
1134     The aim of this test is to determine the length of time it takes the DUT
1135     to recover from an overload condition for a constant load (fixed length
1136     frames at a fixed interval time). The selected frame sizes are those
1137     previously defined under `Default Test Parameters <#DefaultParams>`__,
1138     traffic should be sent to the DUT under normal conditions. During the
1139     duration of the test and while the traffic flows are passing though the
1140     DUT, at least one situation leading to an overload condition for the DUT
1141     should occur. The time from the end of the overload condition to when
1142     the DUT returns to normal operations should be measured to determine
1143     recovery time. Prior to overloading the DUT, one should record the
1144     average latency for 10,000 packets forwarded through the DUT.
1145
1146     The overload condition SHOULD be to transmit traffic at a very high
1147     frame rate to the DUT (150% of the maximum 0% packet loss rate as
1148     determined by LTD.Throughput.RFC2544.PacketLossRatio or line-rate
1149     whichever is lower), for at least 60 seconds, then reduce the frame rate
1150     to 75% of the maximum 0% packet loss rate. A number of time-stamps
1151     should be recorded: - Record the time-stamp at which the frame rate was
1152     reduced and record a second time-stamp at the time of the last frame
1153     lost. The recovery time is the difference between the two timestamps. -
1154     Record the average latency for 10,000 frames after the last frame loss
1155     and continue to record average latency measurements for every 10,000
1156     frames, when latency returns to within 10% of pre-overload levels record
1157     the time-stamp.
1158
1159     **Expected Result**:
1160
1161     **Metrics collected**
1162
1163     The following are the metrics collected for this test:
1164
1165     -  The length of time it takes the DUT to recover from an overload
1166        condition.
1167     -  The length of time it takes the DUT to recover the average latency to
1168        pre-overload conditions.
1169
1170     **Deployment scenario**:
1171
1172     -  Physical → virtual switch → physical.
1173
1174 Test ID: LTD.Throughput.RFC2544.BackToBackFrames
1175 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1176     **Title**: RFC2544 Back To Back Frames Test
1177
1178     **Prerequisite Test**: N
1179
1180     **Priority**:
1181
1182     **Description**:
1183
1184     The aim of this test is to characterize the ability of the DUT to
1185     process back-to-back frames. For each frame size previously defined
1186     under `Default Test Parameters <#DefaultParams>`__, a burst of traffic
1187     is sent to the DUT with the minimum inter-frame gap between each frame.
1188     If the number of received frames equals the number of frames that were
1189     transmitted, the burst size should be increased and traffic is sent to
1190     the DUT again. The value measured is the back-to-back value, that is the
1191     maximum burst size the DUT can handle without any frame loss.
1192
1193     **Expected Result**:
1194
1195     Tests of back-to-back frames with physical devices have produced
1196     unstable results in some cases. All tests should be repeated in multiple
1197     test sessions and results stability should be examined.
1198
1199     **Metrics collected**
1200
1201     The following are the metrics collected for this test:
1202
1203     -  The back-to-back value, which is the the number of frames in the
1204        longest burst that the DUT will handle without the loss of any
1205        frames.
1206     -  CPU and memory utilization may also be collected as part of this
1207        test, to determine the vSwitch's performance footprint on the system.
1208
1209     **Deployment scenario**:
1210
1211     -  Physical → virtual switch → physical.
1212
1213 Test ID: LTD.Throughput.RFC2889.Soak
1214 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1215     **Title**: RFC 2889 X% packet loss Throughput Soak Test
1216
1217     **Prerequisite Test** LTD.Throughput.RFC2544.PacketLossRatio
1218
1219     **Priority**:
1220
1221     **Description**:
1222
1223     The aim of this test is to understand the Throughput stability over an
1224     extended test duration in order to uncover any outliers. To allow for an
1225     extended test duration, the test should ideally run for 24 hours or, if
1226     this is not possible, for at least 6 hours. For this test, each frame
1227     size must be sent at the highest Throughput with X% packet loss, as
1228     determined in the prerequisite test. The default loss percentages to be
1229     tested are: - X = 0% - X = 10^-7%
1230
1231     Note: Other values can be tested if required by the user.
1232
1233     **Expected Result**:
1234
1235     **Metrics Collected**:
1236
1237     The following are the metrics collected for this test:
1238
1239     -  Throughput stability of the DUT.
1240
1241        -  This means reporting the number of packets lost per time interval
1242           and reporting any time intervals with packet loss. The
1243           `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__
1244           Forwarding Rate shall be measured in each interval.
1245           An interval of 60s is suggested.
1246
1247     -  CPU and memory utilization may also be collected as part of this
1248        test, to determine the vSwitch's performance footprint on the system.
1249     -  The `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__
1250        PDV form of delay variation on the traffic flow,
1251        using the 99th percentile.
1252
1253 Test ID: LTD.Throughput.RFC2889.SoakFrameModification
1254 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1255     **Title**: RFC 2889 Throughput Soak Test with Frame Modification
1256
1257     **Prerequisite Test**: LTD.Throughput.RFC2544.PacketLossRatioFrameModification (0% Packet Loss)
1258
1259     **Priority**:
1260
1261     **Description**:
1262
1263     The aim of this test is to understand the throughput stability over an
1264     extended test duration in order to uncover any outliers. To allow for an
1265     extended test duration, the test should ideally run for 24 hours or, if
1266     this is not possible, for at least 6 hour. For this test, each frame
1267     size must be sent at the highest Throughput with 0% packet loss, as
1268     determined in the prerequisite test.
1269
1270     During this test, the DUT must perform the following operations on the
1271     traffic flow:
1272
1273     -  Perform packet parsing on the DUT's ingress port.
1274     -  Perform any relevant address look-ups on the DUT's ingress ports.
1275     -  Modify the packet header before forwarding the packet to the DUT's
1276        egress port. Packet modifications include:
1277
1278        -  Modifying the Ethernet source or destination MAC address.
1279        -  Modifying/adding a VLAN tag (**Recommended**).
1280        -  Modifying/adding a MPLS tag.
1281        -  Modifying the source or destination ip address.
1282        -  Modifying the TOS/DSCP field.
1283        -  Modifying the source or destination ports for UDP/TCP/SCTP.
1284        -  Modifying the TTL.
1285
1286     **Expected Result**:
1287
1288     **Metrics Collected**:
1289
1290     The following are the metrics collected for this test:
1291
1292     -  Throughput stability of the DUT.
1293
1294        -  This means reporting the number of packets lost per time interval
1295           and reporting any time intervals with packet loss. The
1296           `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__
1297           Forwarding Rate shall be measured in each interval.
1298           An interval of 60s is suggested.
1299
1300     -  CPU and memory utilization may also be collected as part of this
1301        test, to determine the vSwitch's performance footprint on the system.
1302     -  The `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__ PDV form of delay variation on the traffic flow,
1303        using the 99th percentile.
1304
1305 Test ID: LTD.Throughput.RFC6201.ResetTime
1306 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1307     **Title**: RFC 6201 Reset Time Test
1308
1309     **Prerequisite Test**: N/A
1310
1311     **Priority**:
1312
1313     **Description**:
1314
1315     The aim of this test is to determine the length of time it takes the DUT
1316     to recover from a reset.
1317
1318     Two reset methods are defined - planned and unplanned. A planned reset
1319     requires stopping and restarting the virtual switch by the usual
1320     'graceful' method defined by it's documentation. An unplanned reset
1321     requires simulating a fatal internal fault in the virtual switch - for
1322     example by using kill -SIGKILL on a Linux environment.
1323
1324     Both reset methods SHOULD be exercised.
1325
1326     For each frame size previously defined under `Default Test
1327     Parameters <#DefaultParams>`__, traffic should be sent to the DUT under
1328     normal conditions. During the duration of the test and while the traffic
1329     flows are passing through the DUT, the DUT should be reset and the Reset
1330     time measured. The Reset time is the total time that a device is
1331     determined to be out of operation and includes the time to perform the
1332     reset and the time to recover from it (cf. `RFC6201 <https://www.rfc-editor.org/rfc/rfc6201.txt>`__).
1333
1334     `RFC6201 <https://www.rfc-editor.org/rfc/rfc6201.txt>`__ defines two methods to measure the Reset time:
1335       - Frame-Loss Method: which requires the monitoring of the number of
1336         lost frames and calculates the Reset time based on the number of
1337         frames lost and the offered rate according to the following
1338         formula:
1339
1340         .. code-block:: console
1341
1342                                     Frames_lost (packets)
1343                  Reset_time = -------------------------------------
1344                                 Offered_rate (packets per second)
1345
1346       - Timestamp Method: which measures the time from which the last frame
1347         is forwarded from the DUT to the time the first frame is forwarded
1348         after the reset. This involves time-stamping all transmitted frames
1349         and recording the timestamp of the last frame that was received prior
1350         to the reset and also measuring the timestamp of the first frame that
1351         is received after the reset. The Reset time is the difference between
1352         these two timestamps.
1353
1354     According to `RFC6201 <https://www.rfc-editor.org/rfc/rfc6201.txt>`__ the choice of method depends on the test
1355     tool's capability; the Frame-Loss method SHOULD be used if the test tool
1356     supports: - Counting the number of lost frames per stream. -
1357     Transmitting test frame despite the physical link status.
1358
1359     whereas the Timestamp method SHOULD be used if the test tool supports: -
1360     Timestamping each frame. - Monitoring received frame's timestamp. -
1361     Transmitting frames only if the physical link status is up.
1362
1363     **Expected Result**:
1364
1365     **Metrics collected**
1366
1367     The following are the metrics collected for this test: - Average Reset
1368     Time over the number of trials performed.
1369
1370     Results of this test should include the following information: - The
1371     reset method used. - Throughput in Fps and Mbps. - Average Frame Loss
1372     over the number of trials performed. - Average Reset Time in
1373     milliseconds over the number of trials performed. - Number of trials
1374     performed. - Protocol: IPv4, IPv6, MPLS, etc. - Frame Size in Octets -
1375     Port Media: Ethernet, Gigabit Ethernet (GbE), etc. - Port Speed: 10
1376     Gbps, 40 Gbps etc. - Interface Encapsulation: Ethernet, Ethernet VLAN,
1377     etc.
1378
1379     **Deployment scenario**:
1380
1381     -  Physical → virtual switch → physical.
1382
1383 Test ID: LTD.Throughput.RFC2889.MaxForwardingRate
1384 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1385     **Title**: RFC2889 Forwarding Rate Test
1386
1387     **Prerequisite Test**: LTD.Throughput.RFC2544.PacketLossRatio
1388
1389     **Priority**:
1390
1391     **Description**:
1392
1393     This test measures the DUT's Max Forwarding Rate when the Offered Load
1394     is varied between the throughput and the Maximum Offered Load for fixed
1395     length frames at a fixed time interval. The selected frame sizes are
1396     those previously defined under `Default Test
1397     Parameters <#DefaultParams>`__. The throughput is the maximum offered
1398     load with 0% frame loss (measured by the prerequisite test), and the
1399     Maximum Offered Load (as defined by
1400     `RFC2285 <https://www.rfc-editor.org/rfc/rfc2285.txt>`__) is *"the highest
1401     number of frames per second that an external source can transmit to a
1402     DUT/SUT for forwarding to a specified output interface or interfaces"*.
1403
1404     Traffic should be sent to the DUT at a particular rate (TX rate)
1405     starting with TX rate equal to the throughput rate. The rate of
1406     successfully received frames at the destination counted (in FPS). If the
1407     RX rate is equal to the TX rate, the TX rate should be increased by a
1408     fixed step size and the RX rate measured again until the Max Forwarding
1409     Rate is found.
1410
1411     The trial duration for each iteration should last for the period of time
1412     needed for the system to reach steady state for the frame size being
1413     tested. Under `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__
1414     (Sec. 5.6.3.1) test methodology, the test
1415     duration should run for a minimum period of 30 seconds, regardless
1416     whether the system reaches steady state before the minimum duration
1417     ends.
1418
1419     **Expected Result**: According to
1420     `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__ The Max Forwarding Rate
1421     is the highest forwarding rate of a DUT taken from an iterative set of
1422     forwarding rate measurements. The iterative set of forwarding rate
1423     measurements are made by setting the intended load transmitted from an
1424     external source and measuring the offered load (i.e what the DUT is
1425     capable of forwarding). If the Throughput == the Maximum Offered Load,
1426     it follows that Max Forwarding Rate is equal to the Maximum Offered
1427     Load.
1428
1429     **Metrics Collected**:
1430
1431     The following are the metrics collected for this test:
1432
1433     -  The Max Forwarding Rate for the DUT for each packet size.
1434     -  CPU and memory utilization may also be collected as part of this
1435        test, to determine the vSwitch's performance footprint on the system.
1436
1437 Test ID: LTD.Throughput.RFC2889.ForwardPressure
1438 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1439     **Title**: RFC2889 Forward Pressure Test
1440
1441     **Prerequisite Test**: LTD.Throughput.RFC2889.MaxForwardingRate
1442
1443     **Priority**:
1444
1445     **Description**:
1446
1447     The aim of this test is to determine if the DUT transmits frames with an
1448     inter-frame gap that is less than 12 bytes. This test overloads the DUT
1449     and measures the output for forward pressure. Traffic should be
1450     transmitted to the DUT with an inter-frame gap of 11 bytes, this will
1451     overload the DUT by 1 byte per frame. The forwarding rate of the DUT
1452     should be measured.
1453
1454     **Expected Result**: The forwarding rate should not exceed the maximum
1455     forwarding rate of the DUT collected by
1456     LTD.Throughput.RFC2889.MaxForwardingRate.
1457
1458     **Metrics collected**
1459
1460     The following are the metrics collected for this test:
1461
1462     -  Forwarding rate of the DUT in FPS or Mbps.
1463     -  CPU and memory utilization may also be collected as part of this
1464        test, to determine the vSwitch's performance footprint on the system.
1465
1466     **Deployment scenario**:
1467
1468     -  Physical → virtual switch → physical.
1469
1470 Test ID: LTD.Throughput.RFC2889.AddressCachingCapacity
1471 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1472     **Title**: RFC2889 Address Caching Capacity Test
1473
1474     **Prerequisite Test**: N/A
1475
1476     **Priority**:
1477
1478     **Description**:
1479
1480     Please note this test is only applicable to switches that are capable of
1481     MAC learning. The aim of this test is to determine the address caching
1482     capacity of the DUT for a constant load (fixed length frames at a fixed
1483     interval time). The selected frame sizes are those previously defined
1484     under `Default Test Parameters <#DefaultParams>`__.
1485
1486     In order to run this test the aging time, that is the maximum time the
1487     DUT will keep a learned address in its flow table, and a set of initial
1488     addresses, whose value should be >= 1 and <= the max number supported by
1489     the implementation must be known. Please note that if the aging time is
1490     configurable it must be longer than the time necessary to produce frames
1491     from the external source at the specified rate. If the aging time is
1492     fixed the frame rate must be brought down to a value that the external
1493     source can produce in a time that is less than the aging time.
1494
1495     Learning Frames should be sent from an external source to the DUT to
1496     install a number of flows. The Learning Frames must have a fixed
1497     destination address and must vary the source address of the frames. The
1498     DUT should install flows in its flow table based on the varying source
1499     addresses. Frames should then be transmitted from an external source at
1500     a suitable frame rate to see if the DUT has properly learned all of the
1501     addresses. If there is no frame loss and no flooding, the number of
1502     addresses sent to the DUT should be increased and the test is repeated
1503     until the max number of cached addresses supported by the DUT
1504     determined.
1505
1506     **Expected Result**:
1507
1508     **Metrics collected**:
1509
1510     The following are the metrics collected for this test:
1511
1512     -  Number of cached addresses supported by the DUT.
1513     -  CPU and memory utilization may also be collected as part of this
1514        test, to determine the vSwitch's performance footprint on the system.
1515
1516     **Deployment scenario**:
1517
1518     -  Physical → virtual switch → physical.
1519
1520 Test ID: LTD.Throughput.RFC2889.AddressLearningRate
1521 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1522     **Title**: RFC2889 Address Learning Rate Test
1523
1524     **Prerequisite Test**: LTD.Memory.RFC2889.AddressCachingCapacity
1525
1526     **Priority**:
1527
1528     **Description**:
1529
1530     Please note this test is only applicable to switches that are capable of
1531     MAC learning. The aim of this test is to determine the rate of address
1532     learning of the DUT for a constant load (fixed length frames at a fixed
1533     interval time). The selected frame sizes are those previously defined
1534     under `Default Test Parameters <#DefaultParams>`__, traffic should be
1535     sent with each IPv4/IPv6 address incremented by one. The rate at which
1536     the DUT learns a new address should be measured. The maximum caching
1537     capacity from LTD.Memory.RFC2889.AddressCachingCapacity should be taken
1538     into consideration as the maximum number of addresses for which the
1539     learning rate can be obtained.
1540
1541     **Expected Result**: It may be worthwhile to report the behaviour when
1542     operating beyond address capacity - some DUTS may be more friendly to
1543     new addresses than others.
1544
1545     **Metrics collected**:
1546
1547     The following are the metrics collected for this test:
1548
1549     -  The address learning rate of the DUT.
1550
1551     **Deployment scenario**:
1552
1553     -  Physical → virtual switch → physical.
1554
1555 Test ID: LTD.Throughput.RFC2889.ErrorFramesFiltering
1556 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1557     **Title**: RFC2889 Error Frames Filtering Test
1558
1559     **Prerequisite Test**: N/A
1560
1561     **Priority**:
1562
1563     **Description**:
1564
1565     The aim of this test is to determine whether the DUT will propagate any
1566     erroneous frames it receives or whether it is capable of filtering out
1567     the erroneous frames. Traffic should be sent with erroneous frames
1568     included within the flow at random intervals. Illegal frames that must
1569     be tested include: - Oversize Frames. - Undersize Frames. - CRC Errored
1570     Frames. - Dribble Bit Errored Frames - Alignment Errored Frames
1571
1572     The traffic flow exiting the DUT should be recorded and checked to
1573     determine if the erroneous frames where passed through the DUT.
1574
1575     **Expected Result**: Broken frames are not passed!
1576
1577     **Metrics collected**
1578
1579     No Metrics are collected in this test, instead it determines:
1580
1581     -  Whether the DUT will propagate erroneous frames.
1582     -  Or whether the DUT will correctly filter out any erroneous frames
1583        from traffic flow with out removing correct frames.
1584
1585     **Deployment scenario**:
1586
1587     -  Physical → virtual switch → physical.
1588
1589 Test ID: LTD.Throughput.RFC2889.BroadcastFrameForwarding
1590 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1591     **Title**: RFC2889 Broadcast Frame Forwarding Test
1592
1593     **Prerequisite Test**: N
1594
1595     **Priority**:
1596
1597     **Description**:
1598
1599     The aim of this test is to determine the maximum forwarding rate of the
1600     DUT when forwarding broadcast traffic. For each frame previously defined
1601     under `Default Test Parameters <#DefaultParams>`__, the traffic should
1602     be set up as broadcast traffic. The traffic throughput of the DUT should
1603     be measured.
1604
1605     The test should be conducted with at least 4 physical ports on the DUT.
1606     The number of ports used MUST be recorded.
1607
1608     As broadcast involves forwarding a single incoming packet to several
1609     destinations, the latency of a single packet is defined as the average
1610     of the latencies for each of the broadcast destinations.
1611
1612     The incoming packet is transmitted on each of the other physical ports,
1613     it is not transmitted on the port on which it was received. The test MAY
1614     be conducted using different broadcasting ports to uncover any
1615     performance differences.
1616
1617     **Expected Result**:
1618
1619     **Metrics collected**:
1620
1621     The following are the metrics collected for this test:
1622
1623     -  The forwarding rate of the DUT when forwarding broadcast traffic.
1624     -  The minimum, average & maximum packets latencies observed.
1625
1626     **Deployment scenario**:
1627
1628     -  Physical → virtual switch 3x physical.
1629
1630 2.3.2 Packet Latency tests
1631 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
1632 These tests will measure the store and forward latency as well as the packet
1633 delay variation for various packet types through the virtual switch. The
1634 following list is not exhaustive but should indicate the type of tests
1635 that should be required. It is expected that more will be added.
1636
1637 Test ID: LTD.PacketLatency.InitialPacketProcessingLatency
1638 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1639     **Title**: Initial Packet Processing Latency
1640
1641     **Prerequisite Test**: N/A
1642
1643     **Priority**:
1644
1645     **Description**:
1646
1647     In some virtual switch architectures, the first packets of a flow will
1648     take the system longer to process than subsequent packets in the flow.
1649     This test determines the latency for these packets. The test will
1650     measure the latency of the packets as they are processed by the
1651     flow-setup-path of the DUT. There are two methods for this test, a
1652     recommended method and a nalternative method that can be used if it is
1653     possible to disable the fastpath of the virtual switch.
1654
1655     Recommended method: This test will send 64,000 packets to the DUT, each
1656     belonging to a different flow. Average packet latency will be determined
1657     over the 64,000 packets.
1658
1659     Alternative method: This test will send a single packet to the DUT after
1660     a fixed interval of time. The time interval will be equivalent to the
1661     amount of time it takes for a flow to time out in the virtual switch
1662     plus 10%. Average packet latency will be determined over 1,000,000
1663     packets.
1664
1665     This test is intended only for non-learning switches; For learning
1666     switches use RFC2889.
1667
1668     For this test, only unidirectional traffic is required.
1669
1670     **Expected Result**: The average latency for the initial packet of all
1671     flows should be greater than the latency of subsequent traffic.
1672
1673     **Metrics Collected**:
1674
1675     The following are the metrics collected for this test:
1676
1677     -  Average latency of the initial packets of all flows that are
1678        processed by the DUT.
1679
1680     **Deployment scenario**:
1681
1682     -  Physical → Virtual Switch → Physical.
1683
1684 Test ID: LTD.PacketDelayVariation.RFC3393.Soak
1685 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1686     **Title**: Packet Delay Variation Soak Test
1687
1688     **Prerequisite Tests**: LTD.Throughput.RFC2544.PacketLossRatio (0% Packet Loss)
1689
1690     **Priority**:
1691
1692     **Description**:
1693
1694     The aim of this test is to understand the distribution of packet delay
1695     variation for different frame sizes over an extended test duration and
1696     to determine if there are any outliers. To allow for an extended test
1697     duration, the test should ideally run for 24 hours or, if this is not
1698     possible, for at least 6 hour. For this test, each frame size must be
1699     sent at the highest possible throughput with 0% packet loss, as
1700     determined in the prerequisite test.
1701
1702     **Expected Result**:
1703
1704     **Metrics Collected**:
1705
1706     The following are the metrics collected for this test:
1707
1708     -  The packet delay variation value for traffic passing through the DUT.
1709     -  The `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__
1710        PDV form of delay variation on the traffic flow,
1711        using the 99th percentile, for each 60s interval during the test.
1712     -  CPU and memory utilization may also be collected as part of this
1713        test, to determine the vSwitch's performance footprint on the system.
1714
1715 2.3.3 Scalability tests
1716 ~~~~~~~~~~~~~~~~~~~~~~~~
1717 The general aim of these tests is to understand the impact of large flow
1718 table size and flow lookups on throughput. The following list is not
1719 exhaustive but should indicate the type of tests that should be required.
1720 It is expected that more will be added.
1721
1722 Test ID: LTD.Scalability.RFC2544.0PacketLoss
1723 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1724     **Title**: RFC 2544 0% loss Scalability throughput test
1725
1726     **Prerequisite Test**:
1727
1728     **Priority**:
1729
1730     **Description**:
1731
1732     The aim of this test is to measure how throughput changes as the number
1733     of flows in the DUT increases. The test will measure the throughput
1734     through the fastpath, as such the flows need to be installed on the DUT
1735     before passing traffic.
1736
1737     For each frame size previously defined under `Default Test
1738     Parameters <#DefaultParams>`__ and for each of the following number of
1739     flows:
1740
1741     -  1,000
1742     -  2,000
1743     -  4,000
1744     -  8,000
1745     -  16,000
1746     -  32,000
1747     -  64,000
1748     -  Max supported number of flows.
1749
1750     The maximum 0% packet loss throughput should be determined in a manner
1751     identical to LTD.Throughput.RFC2544.PacketLossRatio.
1752
1753     **Expected Result**:
1754
1755     **Metrics Collected**:
1756
1757     The following are the metrics collected for this test:
1758
1759     -  The maximum number of frames per second that can be forwarded at the
1760        specified number of flows and the specified frame size, with zero
1761        packet loss.
1762
1763 Test ID: LTD.MemoryBandwidth.RFC2544.0PacketLoss.Scalability
1764 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1765     **Title**: RFC 2544 0% loss Memory Bandwidth Scalability test
1766
1767     **Prerequisite Tests**:
1768
1769     **Priority**:
1770
1771     **Description**:
1772
1773     The aim of this test is to understand how the DUT's performance is
1774     affected by cache sharing and memory bandwidth between processes.
1775
1776     During the test all cores not used by the vSwitch should be running a
1777     memory intensive application. This application should read and write
1778     random data to random addresses in unused physical memory. The random
1779     nature of the data and addresses is intended to consume cache, exercise
1780     main memory access (as opposed to cache) and exercise all memory buses
1781     equally. Furthermore: - the ratio of reads to writes should be recorded.
1782     A ratio of 1:1 SHOULD be used. - the reads and writes MUST be of
1783     cache-line size and be cache-line aligned. - in NUMA architectures
1784     memory access SHOULD be local to the core's node. Whether only local
1785     memory or a mix of local and remote memory is used MUST be recorded. -
1786     the memory bandwidth (reads plus writes) used per-core MUST be recorded;
1787     the test MUST be run with a per-core memory bandwidth equal to half the
1788     maximum system memory bandwidth divided by the number of cores. The test
1789     MAY be run with other values for the per-core memory bandwidth. - the
1790     test MAY also be run with the memory intensive application running on
1791     all cores.
1792
1793     Under these conditions the DUT's 0% packet loss throughput is determined
1794     as per LTD.Throughput.RFC2544.PacketLossRatio.
1795
1796     **Expected Result**:
1797
1798     **Metrics Collected**:
1799
1800     The following are the metrics collected for this test:
1801
1802     -  The DUT's 0% packet loss throughput in the presence of cache sharing and memory bandwidth between processes.
1803
1804 2.3.5 Coupling between control path and datapath Tests
1805 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1806 The following tests aim to determine how tightly coupled the datapath
1807 and the control path are within a virtual switch. The following list
1808 is not exhaustive but should indicate the type of tests that should be
1809 required. It is expected that more will be added.
1810
1811 Test ID: LTD.CPDPCouplingFlowAddition
1812 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1813     **Title**: Control Path and Datapath Coupling
1814
1815     **Prerequisite Test**:
1816
1817     **Priority**:
1818
1819     **Description**:
1820
1821     The aim of this test is to understand how exercising the DUT's control
1822     path affects datapath performance.
1823
1824     Initially a certain number of flow table entries are installed in the
1825     vSwitch. Then over the duration of an RFC2544 throughput test
1826     flow-entries are added and removed at the rates specified below. No
1827     traffic is 'hitting' these flow-entries, they are simply added and
1828     removed.
1829
1830     The test MUST be repeated with the following initial number of
1831     flow-entries installed: - < 10 - 1000 - 100,000 - 10,000,000 (or the
1832     maximum supported number of flow-entries)
1833
1834     The test MUST be repeated with the following rates of flow-entry
1835     addition and deletion per second: - 0 - 1 (i.e. 1 addition plus 1
1836     deletion) - 100 - 10,000
1837
1838     **Expected Result**:
1839
1840     **Metrics Collected**:
1841
1842     The following are the metrics collected for this test:
1843
1844     -  The maximum forwarding rate in Frames Per Second (FPS) and Mbps of
1845        the DUT.
1846     -  The average latency of the traffic flow when passing through the DUT
1847        (if testing for latency, note that this average is different from the
1848        test specified in Section 26.3 of
1849        `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__).
1850     -  CPU and memory utilization may also be collected as part of this
1851        test, to determine the vSwitch's performance footprint on the system.
1852
1853     **Deployment scenario**:
1854
1855     -  Physical → virtual switch → physical.
1856
1857 2.3.4 CPU and memory consumption
1858 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1859 The following tests will profile a virtual switch's CPU and memory
1860 utilization under various loads and circumstances. The following
1861 list is not exhaustive but should indicate the type of tests that
1862 should be required. It is expected that more will be added.
1863
1864 Test ID: LTD.CPU.RFC2544.0PacketLoss
1865 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1866     **Title**: RFC 2544 0% Loss Compute Test
1867
1868     **Prerequisite Test**:
1869
1870     **Priority**:
1871
1872     **Description**:
1873
1874     The aim of this test is to understand the overall performance of the
1875     system when a CPU intensive application is run on the same DUT as the
1876     Virtual Switch. For each frame size, an
1877     LTD.Throughput.RFC2544.PacketLossRatio (0% Packet Loss) test should be
1878     performed. Throughout the entire test a CPU intensive application should
1879     be run on all cores on the system not in use by the Virtual Switch. For
1880     NUMA system only cores on the same NUMA node are loaded.
1881
1882     It is recommended that stress-ng be used for loading the non-Virtual
1883     Switch cores but any stress tool MAY be used.
1884
1885     **Expected Result**:
1886
1887     **Metrics Collected**:
1888
1889     The following are the metrics collected for this test:
1890
1891     -  CPU utilization of the cores running the Virtual Switch.
1892     -  The number of identity of the cores allocated to the Virtual Switch.
1893     -  The configuration of the stress tool (for example the command line
1894        parameters used to start it.)
1895
1896 2.3.9 Summary List of Tests
1897 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
1898 1. Throughput tests
1899
1900   - Test ID: LTD.Throughput.RFC2544.PacketLossRatio
1901   - Test ID: LTD.Throughput.RFC2544.PacketLossRatioFrameModification
1902   - Test ID: LTD.Throughput.RFC2544.Profile
1903   - Test ID: LTD.Throughput.RFC2544.SystemRecoveryTime
1904   - Test ID: LTD.Throughput.RFC2544.BackToBackFrames
1905   - Test ID: LTD.Throughput.RFC2889.Soak
1906   - Test ID: LTD.Throughput.RFC2889.SoakFrameModification
1907   - Test ID: LTD.Throughput.RFC6201.ResetTime
1908   - Test ID: LTD.Throughput.RFC2889.MaxForwardingRate
1909   - Test ID: LTD.Throughput.RFC2889.ForwardPressure
1910   - Test ID: LTD.Throughput.RFC2889.AddressCachingCapacity
1911   - Test ID: LTD.Throughput.RFC2889.AddressLearningRate
1912   - Test ID: LTD.Throughput.RFC2889.ErrorFramesFiltering
1913   - Test ID: LTD.Throughput.RFC2889.BroadcastFrameForwarding
1914
1915 2. Packet Latency tests
1916
1917   - Test ID: LTD.PacketLatency.InitialPacketProcessingLatency
1918   - Test ID: LTD.PacketDelayVariation.RFC3393.Soak
1919
1920 3. Scalability tests
1921
1922   - Test ID: LTD.Scalability.RFC2544.0PacketLoss
1923   - Test ID: LTD.MemoryBandwidth.RFC2544.0PacketLoss.Scalability
1924
1925 4. Coupling between control path and datapath Tests
1926
1927   - Test ID: LTD.CPDPCouplingFlowAddition
1928
1929 5. CPU and memory consumption
1930
1931   - Test ID: LTD.CPU.RFC2544.0PacketLoss