edit

Experiment definition

The experiment is defined using Topology and Orchestration Specification for Cloud Applications (TOSCA). In particular, the Experimenter has to create a CSAR zip file containing all the necessary files and definitions for letting the ExperimentManager (EM) instantiate everything. The structure of the CSAR is defined as following:

├── Definitions
|   └── experiment.yaml
├── Files
|   └── nsd.csar
└── TOSCA-Metadata
    ├── Metadata.yaml
    └── TOSCA.meta
There are three two mandatory folders plus one optional. Definitions and TOSCA-Metadata are mandatory folder containing the metadata files and the experiment definition, as described in the following sections. the Files folder contains some additional files needed in case some resources specifies extra requirements.

TOSCA-Metadata

The TOSCA-Metadata folder contains the TOSCA.meta file and the Metadata.yaml file. The TOSCA.meta file must contain the reference to the template in this case Entry-Definitions: Definitions/experiment.yaml. For example:

TOSCA-Meta-File-Version: 1.0
CSAR-Version: 1.1
Created-By: MyCompany
Entry-Definitions: Definitions/experiment.yaml

The Metadata.yaml contains experiment meta information:

  • the name
  • the start date
  • the end date

Note

Please use ISO format dates (YYYY-MM-DD).

Note

These dates are general for the whole experiment, but you can specify specific dates per resource. The specific dates of the resources override these ones.

As follows:

name: Experiment Name
start-date: "2017-07-28"
end-date: "2017-07-30"

Where:

  • name: simple name of your experiment
  • start-date: start date of your experiment.
  • end-date: end date of your experiment.

Definitions

The experiment.yaml must follow a specific structure. An example is shown in the following lines:

tosca_definitions_version: tosca_simple_yaml_1_0

description: Template for SoftFIRE yaml resource request definition

imports:
  - softfire_node_types: http://docs.softfire.eu/etc/softfire_node_types.yaml

topology_template:
  node_templates:
    zabbix_server:
      type: MonitoringResource
      properties:
        resource_id: monitor
        testbed: ericsson

    sdn_ericsson:
      type: SdnResource
      properties:
        resource_id: sdn_ericsson
        testbed: ericsson

    iperf:
      type: NfvResource
      properties:
        resource_id: iperf
        nsd_name: The Iperf NSD
        testbeds: { ANY: ericsson }

As shown in the example, the SoftFIRE experiment yaml file must contain the TOSCA definition version as tosca_definitions_version: tosca_simple_yaml_1_0. This line is followed by a description of the experiment.

The imports section must be specified as in the example because the EM will only accept specific node types defined in this document

Each node type specifies a resource_id that must be chosen from the available resources. The node name is arbitrary. Each node type can have some additional properties and they can be different from each others. Check the node type specification to understand all the node types. However, each node type is specified in the specific manager page:

Topology Template

The topology template describe the actual experiment. The required nodes are listed in this section. The types are defined in the node types definitions, please refer to the specific manager page for the description of the type.

Files

This folder contains an inner CSAR of a NS. This is only used in case the NFV Resource you want to deploy is not one of the preconfigured one. In this case, the how to build this CSAR is explained in the Open Baton CSAR tutorial. And the NfvResource file_name field must point to this file. An example of two Ubuntu 16.04 VNFs can be found here

Example

A full example using iperf can be found here. A full example uploading two simple Ubuntu VNFs can be found here