-
Notifications
You must be signed in to change notification settings - Fork 10
IETF usage example 1
#5gtango/wp4/benchmark
The test setup uses two machines:
- VM in which tng-bench (the controller) is executed
- Physical server on which vim-emu (Containernet) is executed. On this machine the tested service, e.g., the Suricata VNF is deployed and tested using vim-emu. This process is controlled by tng-bench from machine 1.
+--------------------------------+ +--------------------------------+
| | | +----------------------------+ |
| | | |............................| |
| | | |...---------................| |
| | | |.( probe1 )-------+......| |
| | | |..`---------'........v......| |
| | | |.................---------..| |
| +-------------------------+ | | |...............( VNF )| |
| |.........................| | | |................`---------'.| |
| |.........................|<--+------+->.....................|......| |
| |.tng-bench...............| | | |...---------.........|......| |
| +-------------------------+ | | |.( probe2 )<------+......| |
| | | |..`---------'...............| |
| | | |............................| |
| | | |.vim-emu.(execution.env)....| |
| | | +----------------------------+ |
| | | |
| tng-bench controller machine | | test executor phys. machine(s) |
+--------------------------------+ +--------------------------------+
Our first example experiment tests a single VNF (Suricata) using iperf. To do so, two probes (iperf client and iparf server) are deployed alongside with the VNF. Probes and VNF are deployed as Docker containers. During the experiment we alter the available CPU time of the VNF.
Using the existing description approach of son-profile / tng-bench, we have the following artifacts describing the experiment:
- Network service to be tested: The Suricata network service, consisting of a single VNF (Suricata).
- Service is defined using ETSI-alligned 5GTANGO service descriptors (even if we test a single VNF, we always need a service to wrap it)
- NSD: https://github.com/sonata-nfv/tng-sdk-benchmark/blob/master/examples/services/ns-1vnf-ids-suricata/ns-1vnf-ids-suricata.yml
- VNFD: tng-sdk-benchmark/vnf-ids-suricata.yml at master · sonata-nfv/tng-sdk-benchmark · GitHub
- This is a normal network service that can also be deployed using the 5GTANGO orchestrator. It has nothing in it which is specific to VNF benchmarking.
- To benchmark the given Suricata service we have a PED (aka VNF BD) describing how the given service should be benchmarked.
- PED: https://github.com/sonata-nfv/tng-sdk-benchmark/blob/master/examples/peds/ped_suricata_tp_small.yml
- The PED links to the service
service_package: “../services/ns-1vnf-ids-suricata”
andservice: “de.upb.ns-1vnf-ids-suricata.0.1”
- The PED contains the additional info about the probes which should be deployed and used. The tng-bench tool then internally combines PED and service and instructs the target test machine (e.g., vim-emu) to execute everything.
- this is still the old definition approach not yet adapted to our VNF-BDs
- however, my plan is to continue with the notion that a PED (or VNF-BD) references a service to be tested (given e.g. as 5GTANGO/ETSI descriptors)
- I will use the node type field sin the VNF-BD et to
external
for this, as discussed in one of the last calls, i.e., the BD also can link the network service to be tested - tng-bench needs a pre-processor module to read in the VNF-BDs (as given here vnf-bench-model/parsed_vnf-bd.yaml at master · raphaelvrosa/vnf-bench-model · GitHub)
Once a user has the service and the PED (or VNF-BD) it is just a matter of starting vim-emu on the target test execution machine:
tng-bench-emusrv
and to run tng-bench to execute the experiment:
tng-bench -p examples/peds/ped_suricata_tp_small.yml
This runs all experiments defined in examples/peds/ped_suricata_tp_small.yml
.
There is still some code missing in tng-bench to do a full example run (mostly the monitoring and probe triggering), but the progress is going well. See: Execute/benchmark 5GTANGO package on vim-emu · Issue #17 · sonata-nfv/tng-sdk-benchmark · GitHub for details.