Newer
Older
Carlos Natalino
committed
This functional test reproduces the experimental assessment of *Experimental
Demonstration of Transport Network Slicing with SLA Using the TeraFlowSDN Controller*
presented at [ECOC'22](https://www.optica.org/en-us/events/topical_meetings/ecoc/schedule/?day=Tuesday#Tuesday).
Carlos Natalino
committed
This functional test can be found in folder `./src/tests/ecoc22/`.
A convenience alias `./ecoc22/` pointing to that folder has been defined.
Carlos Natalino
committed
This functional test has only been tested with emulated devices;
however, if you have access to real devices, you can modify the files
`./ecoc22/tests/Objects.py` and `./ecoc22/tests/Credentials.py` to point to your devices,
and map to your network topology.
Otherwise, you can modify the `./ecoc22/tests/descriptors_emulated.json` that is
designed to be uploaded through the WebUI instead of using the command line scripts.
Carlos Natalino
committed
__Important__: The device drivers operating with real devices, e.g., OpenConfigDriver,
P4Driver, and TransportApiDriver, have to be considered as experimental.
The configuration and monitoring capabilities they support are
limited or partially implemented/tested. Use them with care.
## 2.4.3. Deployment and Dependencies
Carlos Natalino
committed
To run this functional test, it is assumed you have deployed a MicroK8s-based Kubernetes
environment and a TeraFlowSDN controller instance as described in the
[Tutorial: Deployment Guide](./1-0-deployment.md), and you configured the Python
[Tutorial: Run Experiments Guide > 2.1. Configure Python Environment](./2-1-python-environment.md).
Remember to source the scenario settings, e.g., `cd ~/tfs-ctrl && source ecoc22/deploy_specs.sh`
in each terminal you open.
Then, re-build the protocol buffers code from the proto files:
`./proto/generate_code_python.sh`
When the deployment completes, you can connect to the TeraFlowSDN WebUI as described in
[Tutorial: Deployment Guide > 1.4. Access TeraFlowSDN WebUI and Grafana Dashboards](./1-4-access-webui.md)
Notes:
- this experiment does not make use of Monitoring, so Grafana is not used.
- the default credentials for the Grafana Dashboard is user/pass: `admin`/`admin123+`.
- this functional test does not involve the Monitoring component, so no monitoring
data is plotted in Grafana.
## 2.4.5. Test execution
To execute this functional test, four main steps needs to be carried out:
1. Device bootstrapping
2. L2VPN Slice and Services creation
3. L2VPN Slice and Services removal
Carlos Natalino
committed
Upon the execution of each test progresses, a report will be generated indicating
*PASSED* / *FAILED* / *SKIPPED*.
If there is some error during the execution, you should see a detailed report on the
error.
See the troubleshooting section if needed.
You can check the logs of the different components using the appropriate
`scripts/show_logs_[component].sh` scripts after you execute each step.
Carlos Natalino
committed
This step configures some basic entities (Context and Topology), the devices, and the
links in the topology.
The expected results are:
- The devices to be added into the Topology.
Carlos Natalino
committed
- The devices to be pre-configured and initialized as *ENABLED* by the Automation component.
To run this step, you can do it from the WebUI by uploading the file
`./ecoc22/tests/descriptors_emulated.json` that contains the descriptors of the contexts,
topologies, devices, and links, or by executing the `./ecoc22/run_test_01_bootstrap.sh` script.
Carlos Natalino
committed
In the WebUI, select the *admin* Context.
Then, in the *Devices* tab you should see that 5 different emulated devices have been
created and activated: 4 packet routers, and 1 optical Open Line System (OLS) controller.
Carlos Natalino
committed
Besides, in the *Services* tab you should see that there is no service created.
Carlos Natalino
committed
This step configures a new service emulating the request an OSM WIM would make by means
of a Mock OSM instance.
To run this step, execute the `./ecoc22/run_test_02_create_service.sh` script.
When the script finishes, check the WebUI *Slices* and *Services* tab.
You should see that, for the connectivity service requested by MockOSM, one slice has
been created, three services have been created (two for the optical layer and another
for the packet layer).
Note that the two services for the optical layer correspond to the primary (service_uuid
ending with ":0") and the backup (service_uuid ending with ":1") services.
Each of the services indicates the connections and sub-services that are supporting them.
Carlos Natalino
committed
Besides, you can check the *Devices* tab to see the configuration rules that have been
configured in each device.
This step deconfigures the previously created slices and services emulating the request
an OSM WIM would make by means of a Mock OSM instance.
Carlos Natalino
committed
To run this step, execute the `./ecoc22/run_test_03_delete_service.sh` script, or delete
When the script finishes, check the WebUI *Slices* and *Services* tab. You should see
that the slice and the services have been removed.
Carlos Natalino
committed
Besides, in the *Devices* tab you can see that the appropriate configuration rules have
been deconfigured.
Carlos Natalino
committed
This last step performs a cleanup of the scenario removing all the TeraFlowSDN entities
for completeness.
To run this step, execute the `./ecoc22/run_test_04_cleanup.sh` script.
When the script finishes, check the WebUI *Devices* tab, you should see that the devices
Carlos Natalino
committed
have been removed.
Besides, in the *Slices* and *Services* tab you can see that the *admin* Context has no services
Carlos Natalino
committed
given that that context has been removed.