|
|
|
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) / [IEEEXplore](https://ieeexplore.ieee.org/abstract/document/9979396).
|
|
|
|
|
|
|
|
The main features demonstrated are:
|
|
|
|
- Disjoint DC-2-DC L2VPN Service management
|
|
|
|
- Integration with ETSI OpenSourceMANO
|
|
|
|
|
|
|
|
|
|
|
|
## Functional test folder
|
|
|
|
|
|
|
|
This functional test can be found in folder `./src/tests/ecoc22/`.
|
|
|
|
|
|
|
|
## Execute with real devices
|
|
|
|
|
|
|
|
This functional test has only been tested with emulated devices;
|
|
|
|
however, if you have access to real devices, you can modify the files
|
|
|
|
`./src/tests/ecoc22/tests/Objects.py` and `./src/tests/ecoc22/tests/Credentials.py` to point to your devices,
|
|
|
|
and map to your network topology.
|
|
|
|
Otherwise, you can modify the `./src/tests/ecoc22/tests/descriptors_emulated.json` that is
|
|
|
|
designed to be uploaded through the WebUI instead of using the command line scripts.
|
|
|
|
|
|
|
|
__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.
|
|
|
|
|
|
|
|
|
|
|
|
## Deployment and Dependencies
|
|
|
|
|
|
|
|
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.-Deployment-Guide), and you configured the Python
|
|
|
|
environment as described in
|
|
|
|
[Tutorial: Development Guide > Configure Environment > Python](/2.-Development-Guide/2.1.-Configure-Environment/2.1.1.-Python).
|
|
|
|
|
|
|
|
## Access to the WebUI
|
|
|
|
|
|
|
|
When the deployment completes, you can connect to the TeraFlowSDN WebUI as described in
|
|
|
|
[Tutorial: Deployment Guide > WebUI and Grafana Dashboards](/1.-Deployment-Guide/1.4.-WebUI-and-Grafana-Dashboards)
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
## Test execution
|
|
|
|
|
|
|
|
Before executing the tests, we need to prepare a few things.
|
|
|
|
|
|
|
|
First, you need to make sure that you have all the gRPC-generate code in your folder. To do so, run:
|
|
|
|
|
|
|
|
```
|
|
|
|
proto/generate_code_python.sh
|
|
|
|
```
|
|
|
|
|
|
|
|
Second, it is time to deploy TeraFlowSDN with the correct specification for this scenario. Make sure to load your deployment variables for this scenario by:
|
|
|
|
|
|
|
|
```
|
|
|
|
source src/tests/ecoc22/deploy_specs.sh
|
|
|
|
```
|
|
|
|
|
|
|
|
Then, you need to deploy the components by running:
|
|
|
|
|
|
|
|
```
|
|
|
|
./deploy/all.sh
|
|
|
|
```
|
|
|
|
|
|
|
|
After the deployment is finished, you need to load the environment variables to support the execution of the tests by:
|
|
|
|
|
|
|
|
```
|
|
|
|
source tfs_runtime_env_vars.sh
|
|
|
|
```
|
|
|
|
|
|
|
|
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
|
|
|
|
4. Cleanup
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
### Device bootstrapping
|
|
|
|
|
|
|
|
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.
|
|
|
|
- The devices to be pre-configured and initialized as *ENABLED* by the Automation component.
|
|
|
|
- The links to be added to the topology.
|
|
|
|
|
|
|
|
To run this step, you can do it from the WebUI by uploading the file
|
|
|
|
`./src/tests/ecoc22/tests/descriptors_emulated.json` that contains the descriptors of the contexts,
|
|
|
|
topologies, devices, and links, or by executing the `./src/tests/ecoc22/run_test_01_bootstrap.sh` script.
|
|
|
|
|
|
|
|
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.
|
|
|
|
Besides, in the *Services* tab you should see that there is no service created.
|
|
|
|
|
|
|
|
|
|
|
|
### L2VPN Slice and Services creation
|
|
|
|
|
|
|
|
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 `./src/tests/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.
|
|
|
|
Besides, you can check the *Devices* tab to see the configuration rules that have been
|
|
|
|
configured in each device.
|
|
|
|
|
|
|
|
|
|
|
|
### L2VPN Slice and Services removal
|
|
|
|
|
|
|
|
This step deconfigures the previously created slices and services emulating the request
|
|
|
|
an OSM WIM would make by means of a Mock OSM instance.
|
|
|
|
|
|
|
|
To run this step, execute the `./src/tests/ecoc22/run_test_03_delete_service.sh` script, or delete
|
|
|
|
the slice from the WebUI.
|
|
|
|
|
|
|
|
When the script finishes, check the WebUI *Slices* and *Services* tab. You should see
|
|
|
|
that the slice and the services have been removed.
|
|
|
|
Besides, in the *Devices* tab you can see that the appropriate configuration rules have
|
|
|
|
been deconfigured.
|
|
|
|
|
|
|
|
|
|
|
|
### Cleanup
|
|
|
|
|
|
|
|
This last step performs a cleanup of the scenario removing all the TeraFlowSDN entities
|
|
|
|
for completeness.
|
|
|
|
|
|
|
|
To run this step, execute the `./src/tests/ecoc22/run_test_04_cleanup.sh` script.
|
|
|
|
|
|
|
|
When the script finishes, check the WebUI *Devices* tab, you should see that the devices
|
|
|
|
have been removed.
|
|
|
|
Besides, in the *Slices* and *Services* tab you can see that the *admin* Context has no services
|
|
|
|
given that that context has been removed. |
