Wiki

The traffic generator working group is an adhoc, interdisciplinary working group focused on addressing the challenges of traffic generation, particularly as it relates to the challenges of test automation. It is not currently an approved OPNVF project nor is there a proposal planned at this time.

The need for traffic generation is an implicit requirement for testing in OPNFV. Unfortunately there is no standard mechanism defined to support this, leaving each project to develop its own strategy. The challenge is further complicated by the fact that the various PODs are not necessarily consistent and may ( or may not ) have one or more traffic generators installed.

The problem is further complicated by the installation and configuration of required packages for managing external devices. Many of these are proprietary, licensed software which may not be freely distributed and even if they can be distributed many of labs or 3rd party users may not have the physical devices.

Additionally it is a common practice to install these on the DUT where they conflict with or impede performance and, at the very least, will compete for system resources. It also makes it impossible to automate the installation process in a way that will work for all users.

1. The traffic generator platform should be supported as a separate, supported device type
   • Because of the requirements for 3rd party vendors such as IXIA and Spirent we can recognize that the installation may never be fully automated but significant progress can still be made
2. It should be integrated with the existing installers such as Fuel and Compass to create a standardized basic install
   • The installer should lay down:
     • The base OS installation
     • Any supported Open Source software packet generators such as Moongen
     • Any supported 3rd party client libraries that can be legally distributed
     • The OPNFV traffic generator REST API for abstracting the TG interface

A standardized TG platform is not, of itself, a complete solution. Traditional solutions would normally include some sort of client solution for the DUT or other test bed. The REST API proposal is intended to provide a standardized solution which can be leveraged by each project in a method consistent with that projects overall architecture and implementation.

The basic assumptions of the REST API are:

• The primary output from a traffic generator is a data stream
• There are a finite number of data streams used by testing, these can be identified in advance
• The test infrastructure does not care about the underlying traffic generator implementation, they are only concerned with starting ( and stopping ) traffic in a particular data stream
• The REST API implementation should also not be concerned with the underlying implementation

Based on these assumptions the REST API has two components.

• There is a standard REST API running on port 80 ( or whatever ) of the TG platform. This provides a uniform interface for OPNFV test infrastructures to leverage in a variety of ways including discovery of the installed traffic generators.
• There is also a python based interface that provides the implementation solution. A preliminary version of this was developed by the VSPERF TOIT infrastructure and can be seen here: traffic_controller.py