4 files changed, 117 insertions, 0 deletions
diff --git a/docs/scenario/featurematrix.rst b/docs/scenario/featurematrix.rst
new file mode 100644
index 000000000..5b79028d8
--- /dev/null
+++ b/docs/scenario/featurematrix.rst
@@ -0,0 +1,27 @@
+Each scenario provides a set of platform capabilities and features that it supports.  It is
+possible to identify which features are provided by reviewing the scenario name, however
+not all features and capabilities are discernible from the name itself.
+
+Scenario Naming
+^^^^^^^^^^^^^^^
+
+In OPNFV, scenarios are identified by short scenario names.  These names follow a scheme that
+identifies the key components and behaviours of the scenario, the rules for scenario naming are as follows:
+
+  os-[controller]-[feature]-[mode]-[option]
+
+For example: *os-nosdn-kvm-noha* provides an OpenStack based deployment using neutron including
+the OPNFV enhanced KVM hypervisor.
+
+The [feature] tag in the scenario name describes the main feature provided by the scenario.
+This scenario may also provide support for advanced fault management features which is not apparent
+in the scenario name.  The following section describes the features available in each scenario.
+
+Brahmaputra feature support matrix
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following table provides an overview of the available scenarios and supported features
+in the Brahmaputra release of OPNFV.
+
+.. image:: ../images/brahmaputrafeaturematrix.jpg
+   :alt: OPNFV Brahmaputra Feature Matrix
diff --git a/docs/scenario/scenariointro.rst b/docs/scenario/scenariointro.rst
new file mode 100644
index 000000000..dd808432b
--- /dev/null
+++ b/docs/scenario/scenariointro.rst
@@ -0,0 +1,13 @@
+OPNFV Scenarios
+---------------
+
+The OPNFV project provides an integration and deployment environment for a variety of components
+that can make up a virtualisation platform.  OPNFV identifies these variations on the composition of
+the platform as scenarios.
+
+A scenario in OPNFV can be defined as "a deployment of a specific set of platform components".  The
+composition of a scenario may include specific SDN controller technologies, specific accelerate
+switching technologies, or even specific configurations of components to achieve targeted platform
+capabilities.  Each scenario behaves differetly and it is important to understand the behaviour you
+want in order to target the specific scenario you wish to deploy prior to working with the
+OPNFV platform.
diff --git a/docs/scenario/scenariomatrix.rst b/docs/scenario/scenariomatrix.rst
new file mode 100644
index 000000000..5769fa8d9
--- /dev/null
+++ b/docs/scenario/scenariomatrix.rst
@@ -0,0 +1,77 @@
+Scenarios are implemented as deployable compositions through integration with an installation tool.
+OPNFV supports multiple installation tools and for any given release not all tools will support all
+scenarios.  While our target is to establish parity across the installation tools to ensure they
+can provide all scenarios, the practical challenge of achieving that goal for any given feature and
+release results in some disparity.
+
+Scenario Naming
+^^^^^^^^^^^^^^^
+
+In OPNFV scenarios are identified by short scenario names, these names follow a scheme that
+identifies the key components and behaviours of the scenario.  The rules for scenario naming are as follows:
+
+  os-[controller]-[feature]-[mode]-[option]
+
+Details of the fields are
+  * os: mandatory
+
+    * Refers to the platform type used
+    * possible value: os (OpenStack)
+
+* [controller]: mandatory
+
+    * Refers to the SDN controller integrated in the platform
+    * example values: nosdn, ocl, odl, onos
+
+  * [feature]: mandatory
+
+    * Refers to the feature projects supported by the scenario
+    * example values: nofeature, kvm, ovs
+
+  * [mode]: mandatory
+
+    * Refers to the deployment type, which may include for instance high availability
+    * possible values: ha, noha
+
+  * [option]: optional
+
+    * Used for the scenarios those do not fit into naming scheme.
+    * The optional field in the short scenario name should not be included if there is no optional scenario.
+
+Some examples of supported scenario names are:
+
+  * os-nosdn-kvm-noha
+
+    * This is an OpenStack based deployment using neutron including the OPNFV enhanced KVM hypervisor
+
+  * os-odl_l2-nofeature-ha
+
+    * This is an OpenStack deployment in high availability mode including OpenDaylight layer2 networking
+
+  * os-onos-kvm_ovs-noha
+
+    * This is an OpenStack deployment using ONOS including OPNFV enhanced KVM and OVS versions
+
+Installing your scenario
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+There are two main methods of deploying your target scenario, one method is to follow this guide which will
+walk you through the process of deploying to your hardware using scripts or ISO images, the other method is
+to set up a Jenkins slave and connect your infrastructure to the OPNFV Jenkins master.
+
+For the purposes of evaluation and development a number of Brahmaputra scenarios are able to be deployed
+virtually to mitigate the requirements on physical infrastructure.  Details and instructions on performing
+virtual deployments can be found in the installer specific installation instructions.
+
+To set up a Jenkins slave for automated deployment to your lab, refer to the `Jenkins slave connect guide.
+<http://artifacts.opnfv.org/brahmaputra.1.0/docs/opnfv-jenkins-slave-connection.brahmaputra.1.0.html>`_
+
+Brahmaputra scenario overeview
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following table provides an overview of the installation tools and available scenario's
+in the Brahmaputra release of OPNFV.
+
+.. image:: ../images/brahmaputrascenariomatrix.jpg
+   :alt: OPNFV Brahmaputra Scenario Matrix
+
diff --git a/docs/scenario/scenariovalidation.rst b/docs/scenario/scenariovalidation.rst
new file mode 100644
index 000000000..e69de29bb
--- /dev/null
+++ b/docs/scenario/scenariovalidation.rst