OPNFV NFVbench Euphrates Design

Introduction

NFVbench can be decomposed in the following components: - Configuration - Staging - Traffic generation - Traffic generator results analysis

Configuration

This component is in charge of getting the configuration options from the user and consolidate them with the default configuration into a running configuration.

default configuration + user configuration options = running configuration

User configuration can come from: - CLI configuration shortcut arguments (e.g –frame-size) - CLI configuration file (–config [file]) - CLI configuration string (–config [string]) - REST request body - custom platform pluging

The precedence order for configuration is (from highest precedence to lowest precedence) - CLI confguration or REST configuration - custom platform plugin - default configuration

The custom platform plugin is an optional python class that can be used to override default configuration options with default platform options which can be either hardcoded or calculated at runtime from platform specific sources (such as platform deployment configuration files). A custom platform plugin class is a child of the parent class nfvbench.config_plugin.ConfigPlugin.

Staging

The staging component is in charge of staging the OpenStack resources that are used for the requested packet path. For example, for a PVP packet path, this module will create 2 Neutron networks and one VM instance connected to these 2 networks. Multi-chaining and VM placement is also handled by this module.

Main class: nfvbench.chain_managers.StageManager

Traffic Generation

The traffic generation component is in charge of contrilling the TRex traffic generator using its python API. It includes tasks such as: - traffic check end to end to make sure the packet path is clear in both directions before starting a benchmark - programming the Trex traffic flows based on requested parameters - fixed rate control - NDR/PDR binary search

Main class: nfvbench.traffic_client.TrafficClient

Traffic Generator Results Analysis

At the end of a traffic generation session, this component collects the results from TRex and packages them in a format that is suitable for the various output formats (JSON, REST, file, fluentd). In the case of multi-chaining, it handles aggregation of results across chains.

Main class: nfvbench.chain_managers.StatsManager

Versioning

NFVbench uses semver compatible git tags such as “1.0.0”. These tags are also called project tags and applied at important commits on the master branch exclusively. Rules for the version numbers follow the semver 2.0 specification (http://semver.org). These git tags are applied indepently of the OPNFV release tags which are applied only on the stable release branches (e.g. “opnfv-5.0.0”).

In general it is recommeneded to always have a project git version tag associated to any OPNFV release tag content obtained from a sync from master.

NFVbench Docker containers will be versioned based on the OPNF release tags or based on NFVbench project tags.

NDR/PDR Binary Search

Algorithm Outline

The ServiceChain class is responsible for calculating the NDR/PDR for all frame sizes requested in the configuration. Calculation for 1 frame size is delegated to the TrafficClient class.

Call chain for calculating the NDR-PDR for a list of frame sizes:

• ServiceChain.run()

  • ServiceChain._get_chain_results()

    • for every frame size:

      • ServiceChain.__get_result_per_frame_size()

        • TrafficClient.get_ndr_pdr()

          • TrafficClient.__range_search() recursive binary search

The search range is delimited by a left and right rate (expressed as a % of line rate per direction).

The load_epsilon configuration parameter defines the accuracy of the result as a % of line rate. The default value of 0.1 indicates for example that the measured NDR and PDR are within 0.1% of line rate of the actual NDR/PDR (e.g. 0.1% of 10Gbps is 10Mbps). It also determines how small the search range must be in the binary search.

The recursion narrows down the range by half and stops when: - the range is smaller than the configured load_epsilon value - or when the search hits 100% or 0% of line rate