docs: updates and move traffic gens to separate doc

Move the traffic gen instructions to a separate user guide and add
information on usage of the Dummy traffic generator. Update docs
to fix PDF build failure and do general clean-up. Removed the numbering
from the LTD and added the numbered directive to automate numbering for
sections and headers. Add comment anchors that reflect the section
numbers.

Change-Id: I984ca38456a891c439697ebc1da041bc1d828a15
Signed-off-by: Maryam Tahhan <maryam.tahhan@intel.com>

22 files changed, 754 insertions, 404 deletions

diff --git a/docs/all/index.rst b/docs/all/index.rst
new file mode 100755
index 00000000..5032b00c
--- /dev/null
+++ b/docs/all/index.rst
@@ -0,0 +1,33 @@
+.. OPNFV VSPERF Documentation master file.
+
+======
+VSPERF
+======
+Welcome to VSPERF's documentation !
+
+.. _VSPERF: https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases
+.. _REPO: https://gerrit.opnfv.org/gerrit/#/q/vswitchperf
+
+VSPERF_ is an OPNFV testing project.
+
+VSPERF will develop a generic and architecture agnostic vSwitch testing
+framework and associated tests, that will serve as a basis for validating the
+suitability of different vSwitch implementations in a Telco NFV deployment
+environment. The output of this project will be utilized by the OPNFV
+Performance and Test group and its associated projects, as part of OPNFV
+Platform and VNF level testing and validation.
+
+.. toctree::
+   :maxdepth: 3
+   :numbered: 5
+
+   User Guides <http://artifacts.opnfv.org/vsperf/docs/userguides/index.html>
+   Design <http://artifacts.opnfv.org/vswitchperf/docs/designindex.html>
+   Test Specification <http://artifacts.opnfv.org/vswitchperf/docs/requirements/index.html>
+   Release Information <http://artifacts.opnfv.org/vswitchperf/docs/release/index.html>
+
+
+Indices
+=======
+* :ref:`search`
+
diff --git a/docs/images/factory_and_loader.png b/docs/design/factory_and_loader.png
index 290c0af6..290c0af6 100644
--- a/docs/images/factory_and_loader.png
+++ b/docs/design/factory_and_loader.png
diff --git a/docs/design/index.rst b/docs/design/index.rst
index c93d6719..bb189cb0 100755
--- a/docs/design/index.rst
+++ b/docs/design/index.rst
@@ -1,13 +1,9 @@
-=============
+**************
 VSPERF Design
-=============
+**************
 
 .. toctree::
    :numbered:
-   :maxdepth: 4
+   :maxdepth: 3
 
    vswitchperf_design.rst
-
-Revision: _sha1_
-
-Build date: |today|
diff --git a/docs/images/traffic_controller.png b/docs/design/traffic_controller.png
index 598296ec..598296ec 100644
--- a/docs/images/traffic_controller.png
+++ b/docs/design/traffic_controller.png
diff --git a/docs/images/vsperf.png b/docs/design/vsperf.png
index 4af2ac62..4af2ac62 100644
--- a/docs/images/vsperf.png
+++ b/docs/design/vsperf.png
diff --git a/docs/design/vswitchperf_design.rst b/docs/design/vswitchperf_design.rst
index d7fa67c3..3096b1a6 100755
--- a/docs/design/vswitchperf_design.rst
+++ b/docs/design/vswitchperf_design.rst
@@ -1,7 +1,13 @@
+======================
+VSPERF Design Document
+======================
+
 Intended Audience
 =================
 
-This document is intended to aid those who want to modify the vsperf code. Or to extend it - for example to add support for new traffic generators, deployment scenarios and so on.
+This document is intended to aid those who want to modify the vsperf code. Or
+to extend it - for example to add support for new traffic generators,
+deployment scenarios and so on.
 
 Usage
 =====
@@ -21,13 +27,16 @@ Run all tests that have ``tput`` in their name - ``p2p_tput``, ``pvp_tput`` etc.
 
    $ ./vsperf  --tests 'tput'
 
-As above but override default configuration with settings in 'my_settings.py'. This is useful as modifying configuration directly in the configuration files in ``conf/NN_*.py`` shows up as changes under git source control:
+As above but override default configuration with settings in 'my_settings.py'.
+This is useful as modifying configuration directly in the configuration files
+in ``conf/NN_*.py`` shows up as changes under git source control:
 
   .. code-block:: console
 
    $ ./vsperf  --conf-file my_settings.py --tests 'tput'
 
-Override specific test parameters. Useful for shortening the duration of tests for development purposes:
+Override specific test parameters. Useful for shortening the duration of tests
+for development purposes:
 
   .. code-block:: console
 
@@ -38,15 +47,18 @@ Typical Test Sequence
 
 This is a typical flow of control for a test.
 
-.. image:: ../images/vsperf.png
+.. image:: vsperf.png
 
 
 Configuration
 =============
 
-The conf package contains the configuration files (``*.conf``) for all system components, it also provides a ``settings`` object that exposes all of these settings.
+The conf package contains the configuration files (``*.conf``) for all system
+components, it also provides a ``settings`` object that exposes all of these
+settings.
 
-Settings are not passed from component to component. Rather they are available globally to all components once they import the conf package.
+Settings are not passed from component to component. Rather they are available
+globally to all components once they import the conf package.
 
   .. code-block:: python
 
@@ -54,7 +66,8 @@ Settings are not passed from component to component. Rather they are available g
    ...
    log_file = settings.getValue('LOG_FILE_DEFAULT')
 
-Settings files (``*.conf``) are valid python code so can be set to complex types such as lists and dictionaries as well as scalar types:
+Settings files (``*.conf``) are valid python code so can be set to complex
+types such as lists and dictionaries as well as scalar types:
 
   .. code-block:: python
 
@@ -63,9 +76,16 @@ Settings files (``*.conf``) are valid python code so can be set to complex types
 Configuration Procedure and Precedence
 --------------------------------------
 
-Configuration files follow a strict naming convention that allows them to be processed in a specific order. All the .conf files are named ``NN_name.conf``, where NN is a decimal digit. The files are processed in order from 00_name.conf to 99_name.conf so that if the name setting is given in both a lower and higher numbered conf file then the higher numbered file is the effective setting as it is processed after the setting in the lower numbered file.
+Configuration files follow a strict naming convention that allows them to be
+processed in a specific order. All the .conf files are named ``NN_name.conf``,
+where NN is a decimal number. The files are processed in order from 00_name.conf
+to 99_name.conf so that if the name setting is given in both a lower and higher
+numbered conf file then the higher numbered file is the effective setting as it
+is processed after the setting in the lower numbered file.
 
-The values in the file specified by ``--conf-file`` takes precedence over all the other configuration files and does not have to follow the naming convention.
+The values in the file specified by ``--conf-file`` takes precedence over all
+the other configuration files and does not have to follow the naming
+convention.
 
 
 Other Configuration
@@ -76,13 +96,16 @@ Other Configuration
 VM, vSwitch, Traffic Generator Independence
 ===========================================
 
-VSPERF supports different vSwithes, Traffic Generators and VNFs by using standard object-oriented polymorphism:
+VSPERF supports different vSwithes, Traffic Generators and VNFs by using
+standard object-oriented polymorphism:
 
   * Support for vSwitches is implemented by a class inheriting from IVSwitch.
-  * Support for Traffic Generators is implemented by a class inheriting from ITrafficGenerator.
+  * Support for Traffic Generators is implemented by a class inheriting from
+    ITrafficGenerator.
   * Support for VNF is implemented by a class inheriting from IVNF.
 
-By dealing only with the abstract interfaces the core framework can support many implementations of different vSwitches, Traffic Generators and VNFs.
+By dealing only with the abstract interfaces the core framework can support
+many implementations of different vSwitches, Traffic Generators and VNFs.
 
 IVSwitch
 --------
@@ -143,62 +166,89 @@ IVnf
 Controllers
 -----------
 
-Controllers are used in conjunction with abstract interfaces as way of decoupling the control of vSwtiches, VNFs and TrafficGenerators from other components.
+Controllers are used in conjunction with abstract interfaces as way of
+decoupling the control of vSwtiches, VNFs and TrafficGenerators from other
+components.
 
-The controlled classes provide basic primitive operations. The Controllers sequence and co-ordinate these primitive operation in to useful actions. For instance the vswitch_controller_PVP can be used to bring any vSwitch (that implements the primitives defined in IVSwitch) into the configuration required by the Phy-to-Phy  Deployment Scenario.
+The controlled classes provide basic primitive operations. The Controllers
+sequence and co-ordinate these primitive operation in to useful actions. For
+instance the vswitch_controller_PVP can be used to bring any vSwitch (that
+implements the primitives defined in IVSwitch) into the configuration required
+by the Phy-to-Phy  Deployment Scenario.
 
-In order to support a new vSwitch only a new implementation of IVSwitch needs be created for the new vSwitch to be capable of fulfilling all the Deployment Scenarios provided for by existing or future vSwitch Controllers.
+In order to support a new vSwitch only a new implementation of IVSwitch needs
+be created for the new vSwitch to be capable of fulfilling all the Deployment
+Scenarios provided for by existing or future vSwitch Controllers.
 
-Similarly if a new Deployment Scenario is required it only needs to be written once as a new vSwitch Controller and it will immediately be capable of controlling all existing and future vSwitches in to that Deployment Scenario.
+Similarly if a new Deployment Scenario is required it only needs to be written
+once as a new vSwitch Controller and it will immediately be capable of
+controlling all existing and future vSwitches in to that Deployment Scenario.
 
-Similarly the Traffic Controllers can be used to co-ordinate basic operations provided by implementers of ITrafficGenerator to provide useful tests. Though traffic generators generally already implement full test cases i.e. they both generate suitable traffic and analyse returned traffic in order to implement a test which has typically been predefined in an RFC document. However the Traffic Controller class allows for the possibility of further enhancement - such as iterating over tests for various packet sizes or creating new tests.
+Similarly the Traffic Controllers can be used to co-ordinate basic operations
+provided by implementers of ITrafficGenerator to provide useful tests. Though
+traffic generators generally already implement full test cases i.e. they both
+generate suitable traffic and analyse returned traffic in order to implement a
+test which has typically been predefined in an RFC document. However the
+Traffic Controller class allows for the possibility of further enhancement -
+such as iterating over tests for various packet sizes or creating new tests.
 
 Traffic Controller's Role
 -------------------------
 
-.. image:: ../images/traffic_controller.png
+.. image:: traffic_controller.png
 
 
 Loader & Component Factory
 --------------------------
 
-The working of the Loader package (which is responsible for *finding* arbitrary classes based on configuration data) and the Component Factory which is responsible for *choosing* the correct class for a particular situation - e.g. Deployment Scenario can be seen in this diagram.
+The working of the Loader package (which is responsible for *finding* arbitrary
+classes based on configuration data) and the Component Factory which is
+responsible for *choosing* the correct class for a particular situation - e.g.
+Deployment Scenario can be seen in this diagram.
 
-.. image:: ../images/factory_and_loader.png
+.. image:: factory_and_loader.png
 
 Routing Tables
 ==============
 
-Vsperf uses a standard set of routing tables in order to allow tests to easily mix and match Deployment Scenarios (PVP, P2P topology), Tuple Matching and Frame Modification requirements.
-
-::
-
-                    +--------------+
-                    |              |
-                    | Table 0      |  table#0 - Match table. Flows designed to force 5 & 10 tuple matches go here.
-                    |              |
-                    +--------------+
-                          |
-                          |
-                          v
-                    +--------------+  table#1 - Routing table. Flows to route packets between ports goes here.
-                    |              |  The chosen port is communicated to subsequent tables by setting the
-                    | Table 1      |  metadata value to the egress port number. Generally this table
-                    |              |  is set-up by by the vSwitchController.
-                    +--------------+
-                          |
-                          |
-                          v
-                    +--------------+  table#2 - Frame modification table. Frame modification flow rules are
-                    |              |  isolated in this table so that they can be turned on or off
-                    | Table 2      |  without affecting the routing or tuple-matching flow rules.
-                    |              |  This allows the frame modification and tuple matching required by the
-                    +--------------+  tests in the VSWITCH PERFORMANCE FOR TELCO NFV test specification
-                          |           to be independent of the Deployment Scenario set up by the vSwitchController.
-                          |
-                          v
-                    +--------------+
-                    |              |
-                    | Table 3      |  table#3 - Egress table. Egress packets on the ports setup in Table 1.
-                    |              |
-                    +--------------+
+Vsperf uses a standard set of routing tables in order to allow tests to easily
+mix and match Deployment Scenarios (PVP, P2P topology), Tuple Matching and
+Frame Modification requirements.
+
+.. code-block:: console
+
+      +--------------+
+      |              |
+      | Table 0      |  table#0 - Match table. Flows designed to force 5 & 10
+      |              |  tuple matches go here.
+      |              |
+      +--------------+
+             |
+             |
+             v
+      +--------------+  table#1 - Routing table. Flows to route packets between
+      |              |  ports goes here.
+      | Table 1      |  The chosen port is communicated to subsequent tables by
+      |              |  setting the metadata value to the egress port number.
+      |              |  Generally this table is set-up by by the
+      +--------------+  vSwitchController.
+             |
+             |
+             v
+      +--------------+  table#2 - Frame modification table. Frame modification
+      |              |  flow rules are isolated in this table so that they can
+      | Table 2      |  be turned on or off without affecting the routing or
+      |              |  tuple-matching flow rules. This allows the frame
+      |              |  modification and tuple matching required by the tests
+      |              |  in the VSWITCH PERFORMANCE FOR TELCO NFV test
+      +--------------+  specification to be independent of the Deployment
+             |          Scenario set up by the vSwitchController.
+             |
+             v
+      +--------------+
+      |              |
+      | Table 3      |  table#3 - Egress table. Egress packets on the ports
+      |              |  setup in Table 1.
+      +--------------+
+
+
diff --git a/docs/guides/index.rst b/docs/guides/index.rst
deleted file mode 100755
index bf049fbb..00000000
--- a/docs/guides/index.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-==============================
-VSPERF Guides and Installation
-==============================
-
-.. toctree::
-   :numbered:
-   :maxdepth: 4
-
-   quickstart.rst
-   installation.rst
-
-Revision: _sha1_
-
-Build date: |today|
diff --git a/docs/index.rst b/docs/index.rst
deleted file mode 100755
index ec5176c9..00000000
--- a/docs/index.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-======
-VSPERF
-======
-
-.. toctree::
-   :maxdepth: 4
-   :titlesonly:
-
-   guides/index
-   design/index
-   test_spec/index
-   updates/index
-
-Revision: _sha1_
-
-Build date: |today|
diff --git a/docs/updates/NEWS.rst b/docs/release/NEWS.rst
index 5618455c..f9520ff2 100755
--- a/docs/updates/NEWS.rst
+++ b/docs/release/NEWS.rst
@@ -1,3 +1,7 @@
+===========
+VSPERF NEWS
+===========
+
 November 2015
 ==============
 New
diff --git a/docs/release/index.rst b/docs/release/index.rst
new file mode 100644
index 00000000..10294294
--- /dev/null
+++ b/docs/release/index.rst
@@ -0,0 +1,9 @@
+***********
+VSPERF News
+***********
+
+.. toctree::
+   :numbered:
+   :maxdepth: 3
+
+   NEWS.rst
diff --git a/docs/test_spec/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-00.xml b/docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-00.xml
index b5f7f833..b5f7f833 100755
--- a/docs/test_spec/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-00.xml
+++ b/docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-00.xml
diff --git a/docs/test_spec/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.txt b/docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.txt
index 81ae96c0..b282bbb6 100755
--- a/docs/test_spec/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.txt
+++ b/docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.txt
@@ -54,7 +54,7 @@ Status of This Memo
 
 
 Tahhan, et al.           Expires April 16, 2016                 [Page 1]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -110,7 +110,7 @@ Table of Contents
 
 
 Tahhan, et al.           Expires April 16, 2016                 [Page 2]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -166,7 +166,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                 [Page 3]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -222,7 +222,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                 [Page 4]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -278,7 +278,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                 [Page 5]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -334,7 +334,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                 [Page 6]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -390,7 +390,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                 [Page 7]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -446,7 +446,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                 [Page 8]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -502,7 +502,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                 [Page 9]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -558,7 +558,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                [Page 10]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -614,7 +614,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                [Page 11]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -670,7 +670,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                [Page 12]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -726,7 +726,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                [Page 13]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -782,7 +782,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                [Page 14]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -838,7 +838,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                [Page 15]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -894,7 +894,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                [Page 16]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -950,7 +950,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                [Page 17]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -1006,7 +1006,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                [Page 18]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -1062,7 +1062,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                [Page 19]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -1118,7 +1118,7 @@ Internet-Draft           Benchmarking vSwitches             October 2015
 
 
 Tahhan, et al.           Expires April 16, 2016                [Page 20]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
@@ -1174,7 +1174,7 @@ Authors' Addresses
 
 
 Tahhan, et al.           Expires April 16, 2016                [Page 21]
-
+
 Internet-Draft           Benchmarking vSwitches             October 2015
 
 
diff --git a/docs/test_spec/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.xml b/docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.xml
index b5f7f833..b5f7f833 100755
--- a/docs/test_spec/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.xml
+++ b/docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.xml
diff --git a/docs/requirements/index.rst b/docs/requirements/index.rst
new file mode 100644
index 00000000..3b5683f3
--- /dev/null
+++ b/docs/requirements/index.rst
@@ -0,0 +1,10 @@
+******************************
+VSPERF LEVEL TEST DESIGN (LTD)
+******************************
+
+.. toctree::
+   :maxdepth: 3
+   :numbered: 5
+
+   vswitchperf_ltd.rst
+
diff --git a/docs/test_spec/vswitchperf_ltd.rst b/docs/requirements/vswitchperf_ltd.rst
index 7adc864f..065851c3 100644
--- a/docs/test_spec/vswitchperf_ltd.rst
+++ b/docs/requirements/vswitchperf_ltd.rst
@@ -1,9 +1,8 @@
-CHARACTERIZE VSWITCH PERFORMANCE FOR TELCO NFV USE CASES LEVEL TEST DESIGN
-==========================================================================
 
-.. contents:: Table of Contents
+.. 3.1
 
-1. Introduction
+===============
+Introduction
 ===============
 
 The objective of the OPNFV project titled
@@ -19,8 +18,10 @@ the `Document identifier <#DocId>`__ and the `Scope <#Scope>`__.
 
 This document is currently in draft form.
 
-1.1. Document identifier
-------------------------
+.. 3.1.1
+
+Document identifier
+=========================
 
 The document id will be used to uniquely
 identify versions of the LTD. The format for the document id will be:
@@ -29,8 +30,10 @@ status is one of: draft, reviewed, corrected or final. The document id
 for this version of the LTD is:
 OPNFV\_vswitchperf\_LTD\_ver\_1.6\_Jan\_15\_DRAFT.
 
-1.2. Scope
-----------
+.. 3.1.2
+
+Scope
+==========
 
 The main purpose of this project is to specify a suite of
 performance tests in order to objectively measure the current packet
@@ -46,8 +49,10 @@ Continuous Integration Test Framework and/or the Platform Functionality
 Test Framework - if a vSwitch becomes a standard component of an OPNFV
 release.
 
-1.3. References
----------------
+.. 3.1.3
+
+References
+===============
 
 *  `RFC 1242 Benchmarking Terminology for Network Interconnection
    Devices <http://www.ietf.org/rfc/rfc1242.txt>`__
@@ -66,17 +71,24 @@ release.
 *  `RFC 6201 Device Reset
    Characterization <http://tools.ietf.org/html/rfc6201>`__
 
-2. Details of the Level Test Design
+.. 3.2
+
+===================================
+Details of the Level Test Design
 ===================================
 
-This section describes the features to be tested (`cf. 2.1
-<#FeaturesToBeTested>`__), the test approach (`cf. 2.2 <#Approach>`__);
-it also identifies the sets of test cases or scenarios (`cf. 2.3
-<#TestIdentification>`__) along with the pass/fail criteria (`cf. 2.4
-<#PassFail>`__) and the test deliverables (`cf. 2.5 <#TestDeliverables>`__).
+This section describes the features to be tested (
+:ref:_FeaturesToBeTested), the test approach (:ref:_Approach);
+it also identifies the sets of test cases or scenarios (
+:ref:_TestIdentification) along with the pass/fail criteria and
+the test deliverables.
 
-2.1. Features to be tested
---------------------------
+.. 3.2.1
+
+.. _FeaturesToBeTested:
+
+Features to be tested
+==========================
 
 Characterizing virtual switches (i.e. Device Under Test (DUT) in this document)
 includes measuring the following performance metrics:
@@ -133,14 +145,19 @@ includes measuring the following performance metrics:
   - Includes headroom of VM workload processing cores (i.e. available
     for applications).
 
+.. 3.2.2
+
+.. _Approach:
 
-2.2. Approach
+Approach
 ==============
 
 In order to determine the packet transfer characteristics of a virtual
 switch, the tests will be broken down into the following categories:
 
-2.2.1 Test Categories
+.. 3.2.2.1
+
+Test Categories
 ----------------------
 - **Throughput Tests** to measure the maximum forwarding rate (in
   frames per second or fps) and bit rate (in Mbps) for a constant load
@@ -177,15 +194,19 @@ switch, the tests will be broken down into the following categories:
 the combined results would be insightful, for example Packet/Frame Delay
 and Scalability.
 
-2.2.2 Deployment Scenarios
+.. 3.2.2.2
+
+Deployment Scenarios
 --------------------------
 The following represents possible deployments which can help to
 determine the performance of both the virtual switch and the datapath
 into the VNF:
 
+.. 3.2.2.2.1
+
 Physical port → vSwitch → physical port
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  .. code-block:: console
+.. code-block:: console
 
                                                             _
        +--------------------------------------------------+  |
@@ -204,10 +225,11 @@ Physical port → vSwitch → physical port
        |                                                  |
        +--------------------------------------------------+
 
+.. 3.2.2.2.2
 
 Physical port → vSwitch → VNF → vSwitch → physical port
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  .. code-block:: console
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. code-block:: console
 
                                                              _
        +---------------------------------------------------+  |
@@ -242,11 +264,12 @@ Physical port → vSwitch → VNF → vSwitch → physical port
        |                                                  |
        +--------------------------------------------------+
 
+.. 3.2.2.2.3
 
 Physical port → vSwitch → VNF → vSwitch → VNF → vSwitch → physical port
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-  .. code-block:: console
+.. code-block:: console
 
                                                        _
     +----------------------+  +----------------------+  |
@@ -281,10 +304,12 @@ Physical port → vSwitch → VNF → vSwitch → VNF → vSwitch → physical p
     |                                                  |
     +--------------------------------------------------+
 
+.. 3.2.2.2.4
+
 Physical port → VNF → vSwitch → VNF → physical port
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-  .. code-block:: console
+.. code-block:: console
 
                                                         _
     +----------------------+  +----------------------+   |
@@ -324,10 +349,12 @@ Physical port → VNF → vSwitch → VNF → physical port
     |                                                  |
     +--------------------------------------------------+
 
+.. 3.2.2.2.5
+
 Physical port → vSwitch → VNF
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-  .. code-block:: console
+.. code-block:: console
 
                                                           _
     +---------------------------------------------------+  |
@@ -362,10 +389,12 @@ Physical port → vSwitch → VNF
     |                                                  |
     +--------------------------------------------------+
 
+.. 3.2.2.2.6
+
 VNF → vSwitch → physical port
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-  .. code-block:: console
+.. code-block:: console
 
                                                           _
     +---------------------------------------------------+  |
@@ -400,10 +429,12 @@ VNF → vSwitch → physical port
     |                                                  |
     +--------------------------------------------------+
 
+.. 3.2.2.2.7
+
 VNF → vSwitch → VNF → vSwitch
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-  .. code-block:: console
+.. code-block:: console
 
                                                              _
     +-------------------------+  +-------------------------+  |
@@ -430,14 +461,15 @@ VNF → vSwitch → VNF → vSwitch
     |                     vswitch                           |  |
     +-------------------------------------------------------+ _|
 
-HOST 1(Physical port → virtual switch → VNF → virtual switch →
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Physical port) → HOST 2(Physical port → virtual switch → VNF →
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-virtual switch → Physical port)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. 3.2.2.2.8
 
-  .. code-block:: console
+HOST 1(Physical port → virtual switch → VNF → virtual switch → Physical port)
+→ HOST 2(Physical port → virtual switch → VNF → virtual switch → Physical port)
+
+HOST 1 (PVP) → HOST 2 (PVP)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: console
 
                                                        _
     +----------------------+  +----------------------+  |
@@ -490,7 +522,9 @@ or cache capacity testing, an additional port from the vSwitch must be
 connected to the test device. This port is used to listen for flooded
 frames.
 
-2.2.3 General Methodology:
+.. 3.2.2.3
+
+General Methodology:
 --------------------------
 To establish the baseline performance of the virtual switch, tests would
 initially be run with a simple workload in the VNF (the recommended
@@ -504,7 +538,9 @@ the context of higher level Telco NFV use cases, and prove that its
 underlying characteristics and behaviour can be measured and validated.
 Suitable real Telco workload VNFs are yet to be identified.
 
-2.2.3.1 Default Test Parameters
+.. 3.2.2.3.1
+
+Default Test Parameters
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The following list identifies the default parameters for suite of
@@ -551,7 +587,9 @@ configurations should ensure that traffic traverses the installed flows
 through the virtual switch, i.e. flows are installed and have an appropriate
 time out that doesn't expire before packet transmission starts.
 
-2.2.3.2 Flow Classification
+.. 3.2.2.3.2
+
+Flow Classification
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Virtual switches classify packets into flows by processing and matching
@@ -571,7 +609,9 @@ particular flow will install the flow in the vSwitch which adds an
 additional latency, subsequent packets of the same flow are not subject
 to this latency if the flow is already installed on the vSwitch.
 
-2.2.3.3 Test Priority
+.. 3.2.2.3.3
+
+Test Priority
 ~~~~~~~~~~~~~~~~~~~~~
 
 Tests will be assigned a priority in order to determine which tests
@@ -583,16 +623,20 @@ immediately. - High: Must be implemented in the next release. - Medium:
 May be implemented after the release. - Low: May or may not be
 implemented at all.
 
-2.2.3.4 SUT Setup
-~~~~~~~~~~~~~~~~~
+.. 3.2.2.3.4
+
+SUT Setup
+~~~~~~~~~~~~~~~~~~
 
 The SUT should be configured to its "default" state. The
 SUT's configuration or set-up must not change between tests in any way
 other than what is required to do the test. All supported protocols must
 be configured and enabled for each test set up.
 
-2.2.3.4.1 Port Configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+.. 3.2.2.3.5
+
+Port Configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The DUT should be configured with n ports where
 n is a multiple of 2. Half of the ports on the DUT should be used as
@@ -606,74 +650,82 @@ output a packet to port 2 followed by a packet to port 3. The traffic
 stream directed at port 1 should also output a packet to port 2 followed
 by a packet to port 3.
 
-2.2.3.4.2 Frame Formats
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+.. 3.2.2.3.6
+
+Frame Formats
+~~~~~~~~~~~~~~~~~~~~~
+
+**Frame formats Layer 2 (data link layer) protocols**
 
-Frame formats Layer 2 (data link layer) protocols
-++++++++++++++++++++++++++++++++++++++++++++++++++
 -  Ethernet II
 
-  .. code-block:: console
+.. code-block:: console
 
-     +---------------------+--------------------+-----------+
-     |   Ethernet Header   |       Payload      | Check Sum |
-     +---------------------+--------------------+-----------+
-     |_____________________|____________________|___________|
-           14 Bytes            46 - 1500 Bytes      4 Bytes
+     +---------------------------+-----------+
+     | Ethernet Header | Payload | Check Sum |
+     +-----------------+---------+-----------+
+     |_________________|_________|___________|
+           14 Bytes     46 - 1500   4 Bytes
+                          Bytes
 
-Layer 3 (network layer) protocols
-++++++++++++++++++++++++++++++++++
+
+**Layer 3 (network layer) protocols**
 
 -  IPv4
 
-  .. code-block:: console
+.. code-block:: console
 
-     +---------------------+--------------------+--------------------+-----------+
-     |   Ethernet Header   |      IP Header     |       Payload      | Check Sum |
-     +---------------------+--------------------+--------------------+-----------+
-     |_____________________|____________________|____________________|___________|
-           14 Bytes            20 bytes             26 - 1480 Bytes      4 Bytes
+     +-----------------+-----------+---------+-----------+
+     | Ethernet Header | IP Header | Payload | Checksum  |
+     +-----------------+-----------+---------+-----------+
+     |_________________|___________|_________|___________|
+           14 Bytes       20 bytes  26 - 1480   4 Bytes
+                                      Bytes
 
 -  IPv6
 
-  .. code-block:: console
+.. code-block:: console
+
+     +-----------------+-----------+---------+-----------+
+     | Ethernet Header | IP Header | Payload | Checksum  |
+     +-----------------+-----------+---------+-----------+
+     |_________________|___________|_________|___________|
+           14 Bytes       40 bytes  26 - 1460   4 Bytes
+                                      Bytes
 
-     +---------------------+--------------------+--------------------+-----------+
-     |   Ethernet Header   |      IP Header     |       Payload      | Check Sum |
-     +---------------------+--------------------+--------------------+-----------+
-     |_____________________|____________________|____________________|___________|
-           14 Bytes            40 bytes             26 - 1460 Bytes      4 Bytes
+**Layer 4 (transport layer) protocols**
 
-Layer 4 (transport layer) protocols
-++++++++++++++++++++++++++++++++++++
   - TCP
   - UDP
   - SCTP
 
-  .. code-block:: console
+.. code-block:: console
+
+     +-----------------+-----------+-----------------+---------+-----------+
+     | Ethernet Header | IP Header | Layer 4 Header  | Payload | Checksum  |
+     +-----------------+-----------+-----------------+---------+-----------+
+     |_________________|___________|_________________|_________|___________|
+           14 Bytes      40 bytes      20 Bytes       6 - 1460   4 Bytes
+                                                       Bytes
+
 
-     +---------------------+--------------------+-----------------+--------------------+-----------+
-     |   Ethernet Header   |      IP Header     | Layer 4 Header  |       Payload      | Check Sum |
-     +---------------------+--------------------+-----------------+--------------------+-----------+
-     |_____________________|____________________|_________________|____________________|___________|
-           14 Bytes            40 bytes               20 Bytes       6 - 1460 Bytes      4 Bytes
+**Layer 5 (application layer) protocols**
 
-Layer 5 (application layer) protocols
-+++++++++++++++++++++++++++++++++++++
   - RTP
   - GTP
 
-  .. code-block:: console
+.. code-block:: console
 
-     +---------------------+--------------------+-----------------+--------------------+-----------+
-     |   Ethernet Header   |      IP Header     | Layer 4 Header  |       Payload      | Check Sum |
-     +---------------------+--------------------+-----------------+--------------------+-----------+
-     |_____________________|____________________|_________________|____________________|___________|
-           14 Bytes            20 bytes               20 Bytes         Min 6 Bytes       4 Bytes
+     +-----------------+-----------+-----------------+---------+-----------+
+     | Ethernet Header | IP Header | Layer 4 Header  | Payload | Checksum  |
+     +-----------------+-----------+-----------------+---------+-----------+
+     |_________________|___________|_________________|_________|___________|
+           14 Bytes      20 bytes     20 Bytes        >= 6 Bytes   4 Bytes
 
+.. 3.2.2.3.7
 
-2.2.3.4.3 Packet Throughput
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Packet Throughput
+~~~~~~~~~~~~~~~~~~~~~~~~~
 There is a difference between an Ethernet frame,
 an IP packet, and a UDP datagram. In the seven-layer OSI model of
 computer networking, packet refers to a data unit at layer 3 (network
@@ -704,8 +756,10 @@ Therefore, Maximum Frame Rate (64B Frames)
 = 10,000,000,000 / 672
 = 14,880,952.38 frame per second (fps)
 
-2.2.3.4.4 System isolation and validation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+.. 3.2.2.3.8
+
+System isolation and validation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A key consideration when conducting any sort of benchmark is trying to
 ensure the consistency and repeatability of test results between runs.
@@ -716,8 +770,8 @@ their effects. In addition, this section will outline some system tests
 to validate the platform and the VNF before conducting any vSwitch
 benchmarking tests.
 
-System Isolation
-++++++++++++++++
+**System Isolation:**
+
 When conducting a benchmarking test on any SUT, it is essential to limit
 (and if reasonable, eliminate) any noise that may interfere with the
 accuracy of the metrics collected by the test. This noise may be
@@ -756,8 +810,8 @@ test results, including:
    virtualization optimization technologies should be enabled, and
    hyperthreading should also be enabled.
 
-System Validation
-+++++++++++++++++
+**System Validation:**
+
 System validation is broken down into two sub-categories: Platform
 validation and VNF validation. The validation test itself involves
 verifying the forwarding capability and stability for the sub-system
@@ -824,8 +878,8 @@ points to understand the overhead introduced by the virtual switch.
        +--------------------------------------------------+
 
 
-Methodology to benchmark Platform/VNF forwarding capability
-++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+**Methodology to benchmark Platform/VNF forwarding capability**
+
 
 The recommended methodology for the platform/VNF validation and
 benchmark is: - Run `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__
@@ -850,8 +904,10 @@ platform should be configured for every test after this
 (# of vCPUs, vNICs, Memory, affinitization…) is how it should be
 configured for every test that uses a VNF after this.
 
-2.2.4 RFCs for testing virtual switch performance
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. 3.2.2.4
+
+RFCs for testing virtual switch performance
+--------------------------------------------------
 
 The starting point for defining the suite of tests for benchmarking the
 performance of a virtual switch is to take existing RFCs and standards
@@ -861,16 +917,20 @@ a fair comparison between the performance of virtual and physical
 switches. This section outlines the RFCs that are used by this
 specification.
 
+.. 3.2.2.4.1
+
 RFC 1242 Benchmarking Terminology for Network Interconnection
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Devices RFC 1242 defines the terminology that is used in describing
 performance benchmarking tests and their results. Definitions and
 discussions covered include: Back-to-back, bridge, bridge/router,
 constant load, data link frame size, frame loss rate, inter frame gap,
 latency, and many more.
 
+.. 3.2.2.4.2
+
 RFC 2544 Benchmarking Methodology for Network Interconnect Devices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 RFC 2544 outlines a benchmarking methodology for network Interconnect
 Devices. The methodology results in performance metrics such as latency,
 frame loss percentage, and maximum data throughput.
@@ -906,7 +966,8 @@ Types of tests are:
    condition.
 
 6. Reset to characterize speed of recovery from device or software
-   reset. This type of test has been updated by `RFC6201 <https://www.rfc-editor.org/rfc/rfc6201.txt>`__ as such,
+   reset. This type of test has been updated by `RFC6201
+   <https://www.rfc-editor.org/rfc/rfc6201.txt>`__ as such,
    the methodology defined by this specification will be that of RFC 6201.
 
 Although not included in the defined RFC 2544 standard, another crucial
@@ -914,45 +975,59 @@ measurement in Ethernet networking is packet delay variation. The
 definition set out by this specification comes from
 `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__.
 
+.. 3.2.2.4.3
+
 RFC 2285 Benchmarking Terminology for LAN Switching Devices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 RFC 2285 defines the terminology that is used to describe the
 terminology for benchmarking a LAN switching device. It extends RFC
 1242 and defines: DUTs, SUTs, Traffic orientation and distribution,
 bursts, loads, forwarding rates, etc.
 
+.. 3.2.2.4.4
+
 RFC 2889 Benchmarking Methodology for LAN Switching
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 RFC 2889 outlines a benchmarking methodology for LAN switching, it
 extends RFC 2544. The outlined methodology gathers performance
 metrics for forwarding, congestion control, latency, address handling
 and finally filtering.
 
+.. 3.2.2.4.5
+
 RFC 3918 Methodology for IP Multicast Benchmarking
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 RFC 3918 outlines a methodology for IP Multicast benchmarking.
 
+.. 3.2.2.4.6
+
 RFC 4737 Packet Reordering Metrics
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 RFC 4737 describes metrics for identifying and counting re-ordered
 packets within a stream, and metrics to measure the extent each
 packet has been re-ordered.
 
+.. 3.2.2.4.7
+
 RFC 5481 Packet Delay Variation Applicability Statement
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 RFC 5481 defined two common, but different forms of delay variation
 metrics, and compares the metrics over a range of networking
 circumstances and tasks. The most suitable form for vSwitch
 benchmarking is the "PDV" form.
 
+.. 3.2.2.4.8
+
 RFC 6201 Device Reset Characterization
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 RFC 6201 extends the methodology for characterizing the speed of
 recovery of the DUT from device or software reset described in RFC
 2544.
 
-2.2.5 Details of the Test Report
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. 3.2.2.5
+
+Details of the Test Report
+---------------------------------
 
 There are a number of parameters related to the system, DUT and tests
 that can affect the repeatability of a test results and should be
@@ -1024,17 +1099,26 @@ it is recommended that the test report includes the following information:
 **Note**: Tests that require additional parameters to be recorded will
 explicitly specify this.
 
-2.3. Test identification
-------------------------
-2.3.1 Throughput tests
-~~~~~~~~~~~~~~~~~~~~~~
+.. _TestIdentification:
+
+.. 3.2.3
+
+Test identification
+=========================
+
+.. 3.2.3.1
+
+Throughput tests
+----------------------
 The following tests aim to determine the maximum forwarding rate that
 can be achieved with a virtual switch. The list is not exhaustive but
 should indicate the type of tests that should be required. It is
 expected that more will be added.
 
+.. 3.2.3.1.1
+
 Test ID: LTD.Throughput.RFC2544.PacketLossRatio
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC 2544 X% packet loss ratio Throughput and Latency Test
 
     **Prerequisite Test**: N/A
@@ -1062,7 +1146,8 @@ Test ID: LTD.Throughput.RFC2544.PacketLossRatio
     **Expected Result**: At the end of each trial, the presence or absence
     of loss determines the modification of offered load for the next trial,
     converging on a maximum rate, or
-    `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ Throughput with X% loss.
+    `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ Throughput with X%
+    loss.
     The Throughput load is re-used in related
     `RFC2544 <https://www.rfc-editor.org/rfc/rfc2544.txt>`__ tests and other
     tests.
@@ -1080,8 +1165,10 @@ Test ID: LTD.Throughput.RFC2544.PacketLossRatio
     -  CPU and memory utilization may also be collected as part of this
        test, to determine the vSwitch's performance footprint on the system.
 
+.. 3.2.3.1.2
+
 Test ID: LTD.Throughput.RFC2544.PacketLossRatioFrameModification
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC 2544 X% packet loss Throughput and Latency Test with
     packet modification
 
@@ -1148,8 +1235,10 @@ Test ID: LTD.Throughput.RFC2544.PacketLossRatioFrameModification
     -  CPU and memory utilization may also be collected as part of this
        test, to determine the vSwitch's performance footprint on the system.
 
+.. 3.2.3.1.3
+
 Test ID: LTD.Throughput.RFC2544.Profile
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC 2544 Throughput and Latency Profile
 
     **Prerequisite Test**: N/A
@@ -1201,8 +1290,10 @@ Test ID: LTD.Throughput.RFC2544.Profile
        when the offered load is above Maximum Throughput MUST be recorded
        and reported with the results.
 
+.. 3.2.3.1.4
+
 Test ID: LTD.Throughput.RFC2544.SystemRecoveryTime
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC 2544 System Recovery Time Test
 
     **Prerequisite Test** LTD.Throughput.RFC2544.PacketLossRatio
@@ -1251,8 +1342,10 @@ Test ID: LTD.Throughput.RFC2544.SystemRecoveryTime
 
     -  Physical → virtual switch → physical.
 
+.. 3.2.3.1.5
+
 Test ID: LTD.Throughput.RFC2544.BackToBackFrames
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC2544 Back To Back Frames Test
 
     **Prerequisite Test**: N
@@ -1292,8 +1385,10 @@ Test ID: LTD.Throughput.RFC2544.BackToBackFrames
 
     -  Physical → virtual switch → physical.
 
+.. 3.2.3.1.6
+
 Test ID: LTD.Throughput.RFC2889.MaxForwardingRateSoak
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC 2889 X% packet loss Max Forwarding Rate Soak Test
 
     **Prerequisite Test** LTD.Throughput.RFC2544.PacketLossRatio
@@ -1332,11 +1427,14 @@ Test ID: LTD.Throughput.RFC2889.MaxForwardingRateSoak
        PDV form of delay variation on the traffic flow,
        using the 99th percentile.
 
+.. 3.2.3.1.7
+
 Test ID: LTD.Throughput.RFC2889.MaxForwardingRateSoakFrameModification
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC 2889 Max Forwarding Rate Soak Test with Frame Modification
 
-    **Prerequisite Test**: LTD.Throughput.RFC2544.PacketLossRatioFrameModification (0% Packet Loss)
+    **Prerequisite Test**:
+    LTD.Throughput.RFC2544.PacketLossRatioFrameModification (0% Packet Loss)
 
     **Priority**:
 
@@ -1381,11 +1479,14 @@ Test ID: LTD.Throughput.RFC2889.MaxForwardingRateSoakFrameModification
 
     -  CPU and memory utilization may also be collected as part of this
        test, to determine the vSwitch's performance footprint on the system.
-    -  The `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__ PDV form of delay variation on the traffic flow,
-       using the 99th percentile.
+    -  The `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__
+       PDV form of delay variation on the traffic flow, using the 99th
+       percentile.
+
+.. 3.2.3.1.8
 
 Test ID: LTD.Throughput.RFC6201.ResetTime
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC 6201 Reset Time Test
 
     **Prerequisite Test**: N/A
@@ -1411,9 +1512,12 @@ Test ID: LTD.Throughput.RFC6201.ResetTime
     flows are passing through the DUT, the DUT should be reset and the Reset
     time measured. The Reset time is the total time that a device is
     determined to be out of operation and includes the time to perform the
-    reset and the time to recover from it (cf. `RFC6201 <https://www.rfc-editor.org/rfc/rfc6201.txt>`__).
+    reset and the time to recover from it (cf. `RFC6201
+    <https://www.rfc-editor.org/rfc/rfc6201.txt>`__).
+
+    `RFC6201 <https://www.rfc-editor.org/rfc/rfc6201.txt>`__ defines two methods
+    to measure the Reset time:
 
-    `RFC6201 <https://www.rfc-editor.org/rfc/rfc6201.txt>`__ defines two methods to measure the Reset time:
       - Frame-Loss Method: which requires the monitoring of the number of
         lost frames and calculates the Reset time based on the number of
         frames lost and the offered rate according to the following
@@ -1433,37 +1537,47 @@ Test ID: LTD.Throughput.RFC6201.ResetTime
         is received after the reset. The Reset time is the difference between
         these two timestamps.
 
-    According to `RFC6201 <https://www.rfc-editor.org/rfc/rfc6201.txt>`__ the choice of method depends on the test
-    tool's capability; the Frame-Loss method SHOULD be used if the test tool
-    supports: - Counting the number of lost frames per stream. -
-    Transmitting test frame despite the physical link status.
+    According to `RFC6201 <https://www.rfc-editor.org/rfc/rfc6201.txt>`__ the
+    choice of method depends on the test tool's capability; the Frame-Loss
+    method SHOULD be used if the test tool supports:
+
+     * Counting the number of lost frames per stream.
+     * Transmitting test frame despite the physical link status.
 
-    whereas the Timestamp method SHOULD be used if the test tool supports: -
-    Timestamping each frame. - Monitoring received frame's timestamp. -
-    Transmitting frames only if the physical link status is up.
+    whereas the Timestamp method SHOULD be used if the test tool supports:
+     * Timestamping each frame.
+     * Monitoring received frame's timestamp.
+     * Transmitting frames only if the physical link status is up.
 
     **Expected Result**:
 
     **Metrics collected**
 
-    The following are the metrics collected for this test: - Average Reset
-    Time over the number of trials performed.
+    The following are the metrics collected for this test:
+
+     * Average Reset Time over the number of trials performed.
 
-    Results of this test should include the following information: - The
-    reset method used. - Throughput in Fps and Mbps. - Average Frame Loss
-    over the number of trials performed. - Average Reset Time in
-    milliseconds over the number of trials performed. - Number of trials
-    performed. - Protocol: IPv4, IPv6, MPLS, etc. - Frame Size in Octets -
-    Port Media: Ethernet, Gigabit Ethernet (GbE), etc. - Port Speed: 10
-    Gbps, 40 Gbps etc. - Interface Encapsulation: Ethernet, Ethernet VLAN,
-    etc.
+    Results of this test should include the following information:
+
+     * The reset method used.
+     * Throughput in Fps and Mbps.
+     * Average Frame Loss over the number of trials performed.
+     * Average Reset Time in milliseconds over the number of trials performed.
+     * Number of trials performed.
+     * Protocol: IPv4, IPv6, MPLS, etc.
+     * Frame Size in Octets
+     * Port Media: Ethernet, Gigabit Ethernet (GbE), etc.
+     * Port Speed: 10 Gbps, 40 Gbps etc.
+     * Interface Encapsulation: Ethernet, Ethernet VLAN, etc.
 
     **Deployment scenario**:
 
-    -  Physical → virtual switch → physical.
+    * Physical → virtual switch → physical.
+
+.. 3.2.3.1.9
 
 Test ID: LTD.Throughput.RFC2889.MaxForwardingRate
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC2889 Forwarding Rate Test
 
     **Prerequisite Test**: LTD.Throughput.RFC2544.PacketLossRatio
@@ -1499,14 +1613,13 @@ Test ID: LTD.Throughput.RFC2889.MaxForwardingRate
     ends.
 
     **Expected Result**: According to
-    `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__ The Max Forwarding Rate
-    is the highest forwarding rate of a DUT taken from an iterative set of
-    forwarding rate measurements. The iterative set of forwarding rate
-    measurements are made by setting the intended load transmitted from an
-    external source and measuring the offered load (i.e what the DUT is
-    capable of forwarding). If the Throughput == the Maximum Offered Load,
-    it follows that Max Forwarding Rate is equal to the Maximum Offered
-    Load.
+    `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__ The Max Forwarding
+    Rate is the highest forwarding rate of a DUT taken from an iterative set of
+    forwarding rate measurements. The iterative set of forwarding rate measurements
+    are made by setting the intended load transmitted from an external source and
+    measuring the offered load (i.e what the DUT is capable of forwarding). If the
+    Throughput == the Maximum Offered Load, it follows that Max Forwarding Rate is
+    equal to the Maximum Offered Load.
 
     **Metrics Collected**:
 
@@ -1523,9 +1636,10 @@ Test ID: LTD.Throughput.RFC2889.MaxForwardingRate
        benchmarks, and scenarios with both 2 and 4 ports should be tested.
        In any case, the number of ports used must be reported.
 
+.. 3.2.3.1.10
 
 Test ID: LTD.Throughput.RFC2889.ForwardPressure
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC2889 Forward Pressure Test
 
     **Prerequisite Test**: LTD.Throughput.RFC2889.MaxForwardingRate
@@ -1557,9 +1671,10 @@ Test ID: LTD.Throughput.RFC2889.ForwardPressure
 
     -  Physical → virtual switch → physical.
 
+.. 3.2.3.1.11
 
 Test ID: LTD.Throughput.RFC2889.ErrorFramesFiltering
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC2889 Error Frames Filtering Test
 
     **Prerequisite Test**: N/A
@@ -1592,8 +1707,10 @@ Test ID: LTD.Throughput.RFC2889.ErrorFramesFiltering
 
     -  Physical → virtual switch → physical.
 
+.. 3.2.3.1.12
+
 Test ID: LTD.Throughput.RFC2889.BroadcastFrameForwarding
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC2889 Broadcast Frame Forwarding Test
 
     **Prerequisite Test**: N
@@ -1632,18 +1749,22 @@ Test ID: LTD.Throughput.RFC2889.BroadcastFrameForwarding
     **Deployment scenario**:
 
     -  Physical → virtual switch 3x physical. In the Broadcast rate testing,
-    four test ports are required. One of the ports is connected to the test
-    device, so it can send broadcast frames and listen for miss-routed frames.
+       four test ports are required. One of the ports is connected to the test
+       device, so it can send broadcast frames and listen for miss-routed frames.
 
-2.3.2 Packet Latency tests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. 3.2.3.2
+
+Packet Latency tests
+---------------------------
 These tests will measure the store and forward latency as well as the packet
 delay variation for various packet types through the virtual switch. The
 following list is not exhaustive but should indicate the type of tests
 that should be required. It is expected that more will be added.
 
+.. 3.2.3.2.1
+
 Test ID: LTD.PacketLatency.InitialPacketProcessingLatency
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: Initial Packet Processing Latency
 
     **Prerequisite Test**: N/A
@@ -1689,8 +1810,10 @@ Test ID: LTD.PacketLatency.InitialPacketProcessingLatency
 
     -  Physical → Virtual Switch → Physical.
 
+.. 3.2.3.2.2
+
 Test ID: LTD.PacketDelayVariation.RFC3393.Soak
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: Packet Delay Variation Soak Test
 
     **Prerequisite Tests**: LTD.Throughput.RFC2544.PacketLossRatio (0% Packet Loss)
@@ -1720,15 +1843,19 @@ Test ID: LTD.PacketDelayVariation.RFC3393.Soak
     -  CPU and memory utilization may also be collected as part of this
        test, to determine the vSwitch's performance footprint on the system.
 
-2.3.3 Scalability tests
-~~~~~~~~~~~~~~~~~~~~~~~~
+.. 3.2.3.3
+
+Scalability tests
+------------------------
 The general aim of these tests is to understand the impact of large flow
 table size and flow lookups on throughput. The following list is not
 exhaustive but should indicate the type of tests that should be required.
 It is expected that more will be added.
 
+.. 3.2.3.3.1
+
 Test ID: LTD.Scalability.RFC2544.0PacketLoss
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC 2544 0% loss Scalability throughput test
 
     **Prerequisite Test**: LTD.Throughput.RFC2544.PacketLossRatio, IF the
@@ -1780,8 +1907,10 @@ Test ID: LTD.Scalability.RFC2544.0PacketLoss
        specified number of flows and the specified frame size, with zero
        packet loss.
 
+.. 3.2.3.3.2
+
 Test ID: LTD.MemoryBandwidth.RFC2544.0PacketLoss.Scalability
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC 2544 0% loss Memory Bandwidth Scalability test
 
     **Prerequisite Tests**: LTD.Throughput.RFC2544.PacketLossRatio, IF the
@@ -1824,15 +1953,20 @@ Test ID: LTD.MemoryBandwidth.RFC2544.0PacketLoss.Scalability
 
     The following are the metrics collected for this test:
 
-    -  The DUT's 0% packet loss throughput in the presence of cache sharing and memory bandwidth between processes.
+    -  The DUT's 0% packet loss throughput in the presence of cache sharing and
+       memory bandwidth between processes.
+
+.. 3.2.3.4
 
-2.3.4 Activation tests
-~~~~~~~~~~~~~~~~~~~~~~~~
+Activation tests
+-----------------------
 The general aim of these tests is to understand the capacity of the
-and speed with which the vswitch can accomodate new flows.
+and speed with which the vswitch can accommodate new flows.
+
+.. 3.2.3.4.1
 
 Test ID: LTD.Activation.RFC2889.AddressCachingCapacity
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC2889 Address Caching Capacity Test
 
     **Prerequisite Test**: N/A
@@ -1881,8 +2015,10 @@ Test ID: LTD.Activation.RFC2889.AddressCachingCapacity
 
     -  Physical → virtual switch → 2 x physical (one receiving, one listening).
 
+.. 3.2.3.4.2
+
 Test ID: LTD.Activation.RFC2889.AddressLearningRate
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC2889 Address Learning Rate Test
 
     **Prerequisite Test**: LTD.Memory.RFC2889.AddressCachingCapacity
@@ -1916,16 +2052,19 @@ Test ID: LTD.Activation.RFC2889.AddressLearningRate
 
     -  Physical → virtual switch → 2 x physical (one receiving, one listening).
 
+.. 3.2.3.5
 
-2.3.5 Coupling between control path and datapath Tests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Coupling between control path and datapath Tests
+-------------------------------------------------------
 The following tests aim to determine how tightly coupled the datapath
 and the control path are within a virtual switch. The following list
 is not exhaustive but should indicate the type of tests that should be
 required. It is expected that more will be added.
 
+.. 3.2.3.5.1
+
 Test ID: LTD.CPDPCouplingFlowAddition
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: Control Path and Datapath Coupling
 
     **Prerequisite Test**:
@@ -1970,15 +2109,19 @@ Test ID: LTD.CPDPCouplingFlowAddition
 
     -  Physical → virtual switch → physical.
 
-2.3.6 CPU and memory consumption
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. 3.2.3.6
+
+CPU and memory consumption
+---------------------------------
 The following tests will profile a virtual switch's CPU and memory
 utilization under various loads and circumstances. The following
 list is not exhaustive but should indicate the type of tests that
 should be required. It is expected that more will be added.
 
+.. 3.2.3.6.1
+
 Test ID: LTD.CPU.RFC2544.0PacketLoss
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     **Title**: RFC 2544 0% Loss Compute Test
 
     **Prerequisite Test**:
@@ -2009,8 +2152,10 @@ Test ID: LTD.CPU.RFC2544.0PacketLoss
     -  The configuration of the stress tool (for example the command line
        parameters used to start it.)
 
-2.3.7 Summary List of Tests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. 3.2.3.7
+
+Summary List of Tests
+----------------------------
 1. Throughput tests
 
   - Test ID: LTD.Throughput.RFC2544.PacketLossRatio
diff --git a/docs/test_spec/index.rst b/docs/test_spec/index.rst
deleted file mode 100755
index e36b7d85..00000000
--- a/docs/test_spec/index.rst
+++ /dev/null
@@ -1,17 +0,0 @@
-=========================
-VSPERF Test Specification
-=========================
-
-.. toctree::
-   :numbered:
-   :maxdepth: 4
-
-   quickstart.rst
-   installation.rst
-   NEWS.rst
-   vswitchperf_ltd.rst
-   vswitchperf_design.rst
-
-Revision: _sha1_
-
-Build date: |today|
diff --git a/docs/updates/index.rst b/docs/updates/index.rst
deleted file mode 100755
index 6e261623..00000000
--- a/docs/updates/index.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-===========
-VSPERF News
-===========
-
-.. toctree::
-   :numbered:
-   :maxdepth: 4
-
-   NEWS.rst
-
-Revision: _sha1_
-
-Build date: |today|
diff --git a/docs/images/TCLServerProperties.png b/docs/userguides/TCLServerProperties.png
index 682de7c5..682de7c5 100644
--- a/docs/images/TCLServerProperties.png
+++ b/docs/userguides/TCLServerProperties.png
diff --git a/docs/userguides/index.rst b/docs/userguides/index.rst
new file mode 100644
index 00000000..c796e6c3
--- /dev/null
+++ b/docs/userguides/index.rst
@@ -0,0 +1,11 @@
+******************************
+VSPERF Guides and Installation
+******************************
+
+.. toctree::
+   :numbered:
+   :maxdepth: 3
+
+   quickstart.rst
+   installation.rst
+   trafficgen.rst
diff --git a/docs/guides/installation.rst b/docs/userguides/installation.rst
index 5047dce4..96970bdb 100755
--- a/docs/guides/installation.rst
+++ b/docs/userguides/installation.rst
@@ -1,12 +1,11 @@
+======================
 Installing vswitchperf
 ======================
 
 The test suite requires Python 3.3 and relies on a number of other
 packages. These need to be installed for the test suite to function. To
 install Python 3.3 in CentOS 7, an additional repository, Software
-Collections (see
-https://www.softwarecollections.org/en/scls/rhscl/python33) should be
-enabled.
+Collections (`a link`_) should be enabled.
 
 Installation of required packages and preparation of Python 3 virtual
 environment is performed by systems/build_base_machine.sh. It should be
@@ -46,3 +45,5 @@ running any of the above. For example:
 
     export http_proxy=proxy.mycompany.com:123
     export https_proxy=proxy.mycompany.com:123
+
+.. _a link: http://www.softwarecollections.org/en/scls/rhscl/python33/
diff --git a/docs/guides/quickstart.rst b/docs/userguides/quickstart.rst
index b85b3c8a..91162f88 100755
--- a/docs/guides/quickstart.rst
+++ b/docs/userguides/quickstart.rst
@@ -1,3 +1,4 @@
+=============================
 Getting Started with 'vsperf'
 =============================
 
@@ -8,7 +9,7 @@ VSPERF requires one of the following traffic generators to run tests:
 
 - IXIA traffic generator (IxNetwork hardware) and a machine that runs the IXIA client software
 - Spirent traffic generator (TestCenter hardware chassis or TestCenter virtual in a VM) and a
-VM to run the Spirent Virtual Deployment Service image, formerly known as "Spirent LabServer".
+  VM to run the Spirent Virtual Deployment Service image, formerly known as "Spirent LabServer".
 
 Both test configurations, above, also require a CentOS Linux release 7.1.1503 (Core) host.
 
@@ -20,79 +21,11 @@ The vSwitch must support Open Flow 1.3 or greater.
 Installation
 ------------
 
-Follow the `installation instructions <installation.html>`__ to install.
-
-IXIA Setup
-----------
-
-On the CentOS 7 system
-~~~~~~~~~~~~~~~~~~~~~~
-
-You need to install IxNetworkTclClient$(VER\_NUM)Linux.bin.tgz.
-
-On the IXIA client software system
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Find the IxNetwork TCL server app (start -> All Programs -> IXIA ->
-IxNetwork -> IxNetwork\_$(VER\_NUM) -> IxNetwork TCL Server)
-
-Right click on IxNetwork TCL Server, select properties - Under shortcut tab in
-the Target dialogue box make sure there is the argument "-tclport xxxx"
-where xxxx is your port number (take note of this port number you will
-need it for the 10\_custom.conf file).
-
-|Alt text|
-
-Hit Ok and start the TCL server application
-
-Spirent Setup
--------------
-
-Spirent installation files and instructions are available on the
-Spirent support website at:
-
-http://support.spirent.com
-
-Select a version of Spirent TestCenter software to utilize. This example
-will use Spirent TestCenter v4.57 as an example. Substitute the appropriate
-version in place of 'v4.57' in the examples, below.
+Follow the `installation instructions <http://artifacts.opnfv.org/vswitchperf/docs/docs/guides/index.html>`__ to install.
 
-On the CentOS 7 System
-~~~~~~~~~~~~~~~~~~~~~~
-
-Download and install the following:
-
-Spirent TestCenter Application, v4.57 for 64-bit Linux Client
-
-Spirent Virtual Deployment Service (VDS)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Spirent VDS is required for both TestCenter hardware and virtual
-chassis in the vsperf environment. For installation, select the version
-that matches the Spirent TestCenter Application version. For v4.57,
-the matching VDS version is 1.0.55. Download either the ova (VMware)
-or qcow2 (QEMU) image and create a VM with it. Initialize the VM
-according to Spirent installation instructions.
-
-Using Spirent TestCenter Virtual (STCv)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-STCv is available in both ova (VMware) and qcow2 (QEMU) formats. For
-VMware, download:
-
-Spirent TestCenter Virtual Machine for VMware, v4.57 for Hypervisor - VMware ESX.ESXi
-
-Virtual test port performance is affected by the hypervisor configuration. For
-best practice results in deploying STCv, the following is suggested:
-
-- Create a single VM with two test ports rather than two VMs with one port each
-- Set STCv in DPDK mode
-- Give STCv 2*n + 1 cores, where n = the number of ports. For vsperf, cores = 5.
-- Turning off hyperthreading and pinning these cores will improve performance
-- Give STCv 2 GB of RAM
-
-To get the highest performance and accuracy, Spirent TestCenter hardware is
-recommended. vsperf can run with either stype test ports.
+Traffic Generator Setup
+-----------------------
+Follow the `Traffic generator instructions <http://artifacts.opnfv.org/vswitchperf/docs/docs/guides/trafficgen.html>`__ to install and configure a suitable traffic generator.
 
 Cloning and building src dependencies
 -------------------------------------
@@ -125,6 +58,7 @@ access method, use:
 
 To build everything: Vanilla OVS, OVS with vhost_user as the guest access
 method and OVS with vhost_cuse access simply:
+
   .. code-block:: console
 
      make
@@ -243,6 +177,7 @@ step 1.
 
 2. Update your ''10_custom.conf'' file to use the appropriate variables
 for Vanilla OVS:
+
   .. code-block:: console
 
    VSWITCH = 'OvsVanilla'
@@ -266,7 +201,7 @@ set the ports.
     ./vsperf --vswitch OvsVanilla
 
 
-    Executing PVP and PVVP tests
+Executing PVP and PVVP tests
 ----------------------------
 To run tests using vhost-user as guest access method:
 
@@ -417,6 +352,4 @@ an appropriate amount of memory:
 
     VSWITCHD_DPDK_ARGS = ['-c', '0x4', '-n', '4', '--socket-mem 1024,0']
 
---------------
 
-.. |Alt text| image:: ../images/TCLServerProperties.png
diff --git a/docs/userguides/trafficgen.rst b/docs/userguides/trafficgen.rst
new file mode 100644
index 00000000..1bb09103
--- /dev/null
+++ b/docs/userguides/trafficgen.rst
@@ -0,0 +1,218 @@
+===========================
+'vsperf' Traffic Gen Guide
+===========================
+
+Overview
+---------------------
+VSPERF supports the following traffic generators:
+
+  * Dummy (DEFAULT): Allows you to use your own external
+    traffic generator.
+  * IXIA (IxNet and IxOS)
+  * Spirent TestCenter
+
+To see the list of traffic gens from the cli:
+
+  .. code-block:: console
+
+    ./vsperf --list-trafficgens
+
+This guide provides the details of how to install
+and configure the various traffic generators.
+
+Background Information
+----------------------
+The traffic default configuration can be found in
+tools/pkt_gen/trafficgen/trafficgenhelper.py, and is configured as
+follows:
+
+  .. code-block:: console
+
+    TRAFFIC_DEFAULTS = {
+        'l2': {
+            'framesize': 64,
+            'srcmac': '00:00:00:00:00:00',
+            'dstmac': '00:00:00:00:00:00',
+            'srcport': 3000,
+            'dstport': 3001,
+        },
+        'l3': {
+            'proto': 'tcp',
+            'srcip': '1.1.1.1',
+            'dstip': '90.90.90.90',
+        },
+        'vlan': {
+            'enabled': False,
+            'id': 0,
+            'priority': 0,
+            'cfi': 0,
+        },
+    }
+
+The framesize paramter can be overridden from the configuration
+files by adding the following to your custom configuration file
+``10_custom.conf``:
+
+  .. code-block:: console
+
+    TRAFFICGEN_PKT_SIZES = (64, 128,)
+
+OR from the commandline:
+
+  .. code-block:: console
+
+    ./vsperf --test-param "pkt_sizes=x,y" $TESTNAME
+
+You can also modify the traffic transmission duration and the number
+of trials run by the traffic generator by extending the example
+commandline above to:
+
+  .. code-block:: console
+
+    ./vsperf --test-param "pkt_sizes=x,y;duration=10;rfc2455_trials=3" $TESTNAME
+
+Dummy Setup
+------------
+To select the Dummy generator please add the following to your
+custom configuration file ``10_custom.conf``.
+
+
+  .. code-block:: console
+
+     TRAFFICGEN = 'Dummy'
+
+OR run ``vsperf`` with the ``--trafficgen`` argument
+
+  .. code-block:: console
+
+    ./vsperf --trafficgen Dummy $TESTNAME
+
+Where $TESTNAME is the name of the vsperf test you would like to run.
+This will setup the vSwitch and the VNF (if one is part of your test)
+print the traffic configuration and prompt you to transmit traffic
+when the setup is complete.
+
+  .. code-block:: console
+
+    Please send 'continuous' traffic with the following stream config:
+    30mS, 90mpps, multistream False
+    and the following flow config:
+    {
+        "flow_type": "port",
+        "l3": {
+            "srcip": "1.1.1.1",
+            "proto": "tcp",
+            "dstip": "90.90.90.90"
+        },
+        "traffic_type": "continuous",
+        "multistream": 0,
+        "bidir": "True",
+        "vlan": {
+            "cfi": 0,
+            "priority": 0,
+            "id": 0,
+            "enabled": false
+        },
+        "frame_rate": 90,
+        "l2": {
+            "dstport": 3001,
+            "srcport": 3000,
+            "dstmac": "00:00:00:00:00:00",
+            "srcmac": "00:00:00:00:00:00",
+            "framesize": 64
+        }
+    }
+    What was the result for 'frames tx'?
+
+When your traffic gen has completed traffic transmission and provided
+the results please input these at the vsperf prompt. vsperf will try
+to verify the input:
+
+  .. code-block:: console
+
+    Is '$input_value' correct?
+
+Please answer with y OR n.
+
+VPSERF will ask you for:
+  * Result for 'frames tx'
+  * Result for 'frames rx'
+  * Result for 'min latency'
+  * Result for 'max latency'
+  * Result for 'avg latency'
+
+Finally vsperf will print out the results for your test and generate the
+appropriate logs and csv files.
+
+
+IXIA Setup
+----------
+
+On the CentOS 7 system
+~~~~~~~~~~~~~~~~~~~~~~
+
+You need to install IxNetworkTclClient$(VER\_NUM)Linux.bin.tgz.
+
+On the IXIA client software system
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Find the IxNetwork TCL server app (start -> All Programs -> IXIA ->
+IxNetwork -> IxNetwork\_$(VER\_NUM) -> IxNetwork TCL Server)
+
+Right click on IxNetwork TCL Server, select properties - Under shortcut tab in
+the Target dialogue box make sure there is the argument "-tclport xxxx"
+where xxxx is your port number (take note of this port number you will
+need it for the 10\_custom.conf file).
+
+.. image:: TCLServerProperties.png
+
+Hit Ok and start the TCL server application
+
+Spirent Setup
+-------------
+
+Spirent installation files and instructions are available on the
+Spirent support website at:
+
+http://support.spirent.com
+
+Select a version of Spirent TestCenter software to utilize. This example
+will use Spirent TestCenter v4.57 as an example. Substitute the appropriate
+version in place of 'v4.57' in the examples, below.
+
+On the CentOS 7 System
+~~~~~~~~~~~~~~~~~~~~~~
+
+Download and install the following:
+
+Spirent TestCenter Application, v4.57 for 64-bit Linux Client
+
+Spirent Virtual Deployment Service (VDS)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Spirent VDS is required for both TestCenter hardware and virtual
+chassis in the vsperf environment. For installation, select the version
+that matches the Spirent TestCenter Application version. For v4.57,
+the matching VDS version is 1.0.55. Download either the ova (VMware)
+or qcow2 (QEMU) image and create a VM with it. Initialize the VM
+according to Spirent installation instructions.
+
+Using Spirent TestCenter Virtual (STCv)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+STCv is available in both ova (VMware) and qcow2 (QEMU) formats. For
+VMware, download:
+
+Spirent TestCenter Virtual Machine for VMware, v4.57 for Hypervisor - VMware ESX.ESXi
+
+Virtual test port performance is affected by the hypervisor configuration. For
+best practice results in deploying STCv, the following is suggested:
+
+- Create a single VM with two test ports rather than two VMs with one port each
+- Set STCv in DPDK mode
+- Give STCv 2*n + 1 cores, where n = the number of ports. For vsperf, cores = 5.
+- Turning off hyperthreading and pinning these cores will improve performance
+- Give STCv 2 GB of RAM
+
+To get the highest performance and accuracy, Spirent TestCenter hardware is
+recommended. vsperf can run with either stype test ports.