docs/testing/user/userguide/12-nsb-overview.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International
   2 .. License.
   3 .. http://creativecommons.org/licenses/by/4.0
   4 .. (c) OPNFV, 2016-2017 Intel Corporation.
   5
   6 .. Convention for heading levels in Yardstick documentation:
   7
   8    =======  Heading 0 (reserved for the title in a document)
   9    -------  Heading 1
  10    ^^^^^^^  Heading 2
  11    +++++++  Heading 3
  12    '''''''  Heading 4
  13
  14    Avoid deeper levels because they do not render well.
  15
  16 ===================================
  17 Network Services Benchmarking (NSB)
  18 ===================================
  19
  20 .. _Yardstick: https://wiki.opnfv.org/display/yardstick
  21 .. _`ETSI GS NFV-TST001`: http://www.etsi.org/deliver/etsi_gs/NFV-TST/001_099/001/01.01.01_60/gs_nfv-tst001v010101p.pdf
  22
  23 Abstract
  24 --------
  25
  26 This chapter provides an overview of the NSB, a contribution to OPNFV
  27 Yardstick_ from Intel.
  28
  29 Overview
  30 --------
  31
  32 Network Services Benchmarking (:term:`NSB`) uses the :term:`Yardstick`
  33 framework for performing :term:`VNF` and :term:`NFVI` characterisation in an
  34 :term:`NFV` environment.
  35
  36 For VNF characterisation, NSB will onboard a VNF, source and sink traffic to it
  37 via traffic generators, and collect a variety of key performance indicators
  38 (:term:`KPI`) during VNF execution. The stream of KPI data is stored in a
  39 database, and it is visualized in a performance-visualization dashboard.
  40
  41 For NFVI characterisation, a fixed test VNF, called :term:`PROX` is used.
  42 PROX implements a suite of test cases and visualizes the output data of the
  43 test suite. The PROX test cases implement various execution kernels found in
  44 real-world VNFs, and the output of the test cases provides an indication of
  45 the fitness of the infrastructure for running NFV services, in addition to
  46 indicating potential performance optimizations for the NFVI.
  47
  48 NSB extends the Yardstick framework to do VNF characterization in three
  49 different execution environments - bare metal i.e. native Linux environment,
  50 standalone virtual environment and managed virtualized environment (e.g.
  51 OpenStack). It also brings in the capability to interact with external traffic
  52 generators, both hardware and software based, for triggering and validating the
  53 traffic according to user defined profiles.
  54
  55 NSB extension includes:
  56
  57 * Generic data models of Network Services, based on ETSI spec
  58   `ETSI GS NFV-TST 001`_
  59 * Standalone :term:`context` for VNF testing SRIOV, OVS, OVS-DPDK, etc
  60 * Generic VNF configuration models and metrics implemented with Python
  61   classes
  62 * Traffic generator features and traffic profiles
  63
  64     * L1-L3 stateless traffic profiles
  65     * L4-L7 state-full traffic profiles
  66     * Tunneling protocol/network overlay support
  67
  68 * Test case samples
  69
  70     * Ping
  71     * Trex
  72     * vPE, vCGNAT, vFirewall etc - ipv4 throughput, latency etc
  73
  74 * Traffic generators i.e. Trex, ab/nginx, ixia, iperf, etc
  75 * KPIs for a given use case:
  76
  77     * System agent support for collecting NFVi KPI. This includes:
  78
  79         * CPU statistic
  80         * Memory BW
  81         * OVS-DPDK Stats
  82
  83     * Network KPIs e.g. inpackets, outpackets, thoughput, latency
  84     * VNF KPIs e.g. packet_in, packet_drop, packet_fwd
  85
  86 Architecture
  87 ------------
  88
  89 The Network Service (NS) defines a set of Virtual Network Functions (VNF)
  90 connected together using NFV infrastructure.
  91
  92 The Yardstick NSB extension can support multiple VNFs created by different
  93 vendors including traffic generators. Every VNF being tested has its
  94 own data model. The Network service defines a VNF modelling on base of
  95 performed network functionality. The part of the data model is a set of the
  96 configuration parameters, number of connection points used and flavor including
  97 core and memory amount.
  98
  99 ETSI defines a Network Service as a set of configurable VNFs working in some
 100 NFV Infrastructure connecting each other using Virtual Links available through
 101 Connection Points. The ETSI MANO specification defines a set of management
 102 entities called Network Service Descriptors (NSD) and VNF Descriptors (VNFD)
 103 that define real Network Service. The picture below makes an example how the
 104 real Network Operator use-case can map into ETSI Network service definition.
 105
 106 Network Service framework performs the necessary test steps. It may involve:
 107
 108 * Interacting with traffic generator and providing the inputs on traffic
 109   type / packet structure to generate the required traffic as per the
 110   test case. Traffic profiles will be used for this.
 111 * Executing the commands required for the test procedure and analyses the
 112   command output for confirming whether the command got executed correctly
 113   or not e.g. as per the test case, run the traffic for the given
 114   time period and wait for the necessary time delay.
 115 * Verify the test result.
 116 * Validate the traffic flow from SUT.
 117 * Fetch the data from SUT and verify the value as per the test case.
 118 * Upload the logs from SUT onto the Test Harness server
 119 * Retrieve the KPI's provided by particular VNF
 120
 121 Components of Network Service
 122 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 123
 124 .. TODO: provide a list of components in this section and describe them in
 125    later sub-sections
 126
 127 .. Components are the methodology, TGs, framework extensions, KPI collection,
 128    Testcases, SampleVNFs
 129 .. Framework extentions include: VNF models, NSPerf Scenario, contexts
 130
 131 * *Models for Network Service benchmarking*: The Network Service benchmarking
 132   requires the proper modelling approach. The NSB provides models using Python
 133   files and defining of NSDs and VNFDs.
 134
 135 The benchmark control application being a part of OPNFV Yardstick can call
 136 that Python models to instantiate and configure the VNFs. Depending on
 137 infrastructure type (bare-metal or fully virtualized) that calls could be
 138 made directly or using MANO system.
 139
 140 * *Traffic generators in NSB*: Any benchmark application requires a set of
 141   traffic generator and traffic profiles defining the method in which traffic
 142   is generated.
 143
 144 The Network Service benchmarking model extends the Network Service
 145 definition with a set of Traffic Generators (TG) that are treated
 146 same way as other VNFs being a part of benchmarked network service.
 147 Same as other VNFs the traffic generator are instantiated and terminated.
 148
 149 Every traffic generator has own configuration defined as a traffic profile
 150 and a set of KPIs supported. The python models for TG is extended by
 151 specific calls to listen and generate traffic.
 152
 153 * *The stateless TREX traffic generator*: The main traffic generator used as
 154   Network Service stimulus is open source TREX tool.
 155
 156 The TREX tool can generate any kind of stateless traffic.
 157
 158 .. code-block:: console
 159
 160         +--------+      +-------+      +--------+
 161         |        |      |       |      |        |
 162         |  Trex  | ---> |  VNF  | ---> |  Trex  |
 163         |        |      |       |      |        |
 164         +--------+      +-------+      +--------+
 165
 166 Supported testcases scenarios:
 167
 168 * Correlated UDP traffic using TREX traffic generator and replay VNF.
 169
 170     * using different IMIX configuration like pure voice, pure video traffic etc
 171     * using different number IP flows e.g. 1, 1K, 16K, 64K, 256K, 1M flows
 172     * Using different number of rules configured e.g. 1, 1K, 10K rules
 173
 174 For UDP correlated traffic following Key Performance Indicators are collected
 175 for every combination of test case parameters:
 176
 177 * RFC2544 throughput for various loss rate defined (1% is a default)
 178
 179 KPI Collection
 180 ^^^^^^^^^^^^^^
 181
 182 KPI collection is the process of sampling KPIs at multiple intervals to allow
 183 for investigation into anomalies during runtime. Some KPI intervals are
 184 adjustable. KPIs are collected from traffic generators and NFVI for the SUT.
 185 There is already some reporting in NSB available, but NSB collects all KPIs for
 186 analytics to process.
 187
 188 Below is an example list of basic KPIs:
 189 * Throughput
 190 * Latency
 191 * Packet delay variation
 192 * Maximum establishment rate
 193 * Maximum tear-down rate
 194 * Maximum simultaneous number of sessions
 195
 196 Of course, there can be many other KPIs that will be relevant for a specific
 197 NFVI, but in most cases these KPIs are enough to give you a basic picture of
 198 the SUT. NSB also uses :term:`collectd` in order to collect the KPIs. Currently
 199 the following collectd plug-ins are enabled for NSB testcases:
 200
 201 * Libvirt
 202 * Interface stats
 203 * OvS events
 204 * vSwitch stats
 205 * Huge Pages
 206 * RAM
 207 * CPU usage
 208 * Intel® PMU
 209 * Intel(r) RDT
 210
 211 Graphical Overview
 212 ------------------
 213
 214 NSB Testing with Yardstick framework facilitate performance testing of various
 215 VNFs provided.
 216
 217 .. code-block:: console
 218
 219   +-----------+
 220   |           |                                             +-------------+
 221   |   vPE     |                                          -->| TGen Port 0 |
 222   | TestCase  |                                          |  +-------------+
 223   |           |                                          |
 224   +-----------+     +---------------+      +-------+     |
 225                     |               | ---> |  VNF  | <--->
 226   +-----------+     |   Yardstick   |      +-------+     |
 227   | Test Case | --> |  NSB Testing  |                    |
 228   +-----------+     |               |                    |
 229         |           |               |                    |
 230         |           +---------------+                    |
 231   +-----------+                                          |  +-------------+
 232   |   Traffic |                                          -->| TGen Port 1 |
 233   |  patterns |                                             +-------------+
 234   +-----------+
 235
 236               Figure 1: Network Service - 2 server configuration
 237
 238 VNFs supported for chracterization
 239 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 240
 241 1. CGNAPT - Carrier Grade Network Address and port Translation
 242 2. vFW - Virtual Firewall
 243 3. vACL - Access Control List
 244 4. PROX - Packet pROcessing eXecution engine:
 245      * VNF can act as Drop, Basic Forwarding (no touch),
 246        L2 Forwarding (change MAC), GRE encap/decap, Load balance based on
 247        packet fields, Symmetric load balancing
 248      * QinQ encap/decap IPv4/IPv6, ARP, QoS, Routing, Unmpls, Policing, ACL
 249 5. UDP_Replay