This repository contains the core framework of the paper Low Impact Tenant Code Updates on Multi-tenant Programmable Switches
where the first version was presented.
Meanwhile, extended versions of the core framework are added used in the paper Orchestrating Multi-Tenant Code Updates Across Multiple Programmable Switches
and Resilient Multi-Tenant Network Programmability for Adaptive Service Placement
.
As interface to use the Tofino 1 chip, the proposed Open-Tofino Code is used.
The framework proposed in the used proprietary software and APIs to initialize hardware, etc. after updating the hardware. Since these are licensed, this was removed, and must be added again or done manually, to get the full functional version used in the paper!
- Python 3.8
- Pip 3.21.1
- Kubernetes Distribution (e.g. K3s)
- Accelerator Hardware (Tofino 1 chip or BMv2)
As first step, we recommend to create virtual environment:
python3 -m venv .venv
source .venv.bin
Then, you need to install the python packages needed in this repository:
pip3 install -r requirements.txt
Also, you need to build and install OMuProCU-utils pip packages.
cd ../OMuProCU_utils
pip3 install -r requirements.txt
python3 setup.py sdist
pip3 install ../OMuProCU_utils
ATTENTION: The programmable switch must be started and ready for reconfiguration! This is not part of OMuProCU!
The orchstrator.py contains the mangement process which starts also all other components in the right order.
So running python3 orchestrator.py
will start the orchestrator with default parameters.
Parameter | Options | Description |
---|---|---|
--no_cleanup | --- | Disable the cleanup procedure if orchestrator is shutdown |
--experiment-protocol | ["TCP", "UDP" ] | Which protocol is used for the timemeasurement differentiation in the experiment (only for data collection) [Default: TCP] |
--dev-init-mode | ["0", "1" ] | Which dev-init-mode should be set to supported accelerators [Default: 0 (fast-reconfig)] |
The OMuProCU core consists of different microservices:
Also, there are some modules which are used from the OMuProCU-utils package like:
- Validator
- Persistor
- Tenant Communication Controller
- Protobuf Message Descriptions and its GRPC interfaces
The core of the OMuProCU is the Management Process which is covered in the orchestrator.py. It contains the submission process for TDCs and health check pipeline control.
The reconfiguration scheduler executes the deployment pipeline proposed in the paper. The implementation is covered in reconfig_scheduler.py
This component manages the Container deployment of the accelerated CNF. Its implementation is covered in nos_updater.py. The API implementation is done only for the Kubernetes API.
General abstraction for OTF code placement and accelerator code generation from TIF template and its compilation. Its implementation is covered in in_network_updater.py.
Abstraction component for applying the generated TIF and pulling the applied TIF to supported accelerated hardware or chips. In this implementation, BMv2 and Tofino 1 chip apply is available. Its implementation can be found in tif_updater.py
As described before, the Open-Tofino API is used for the configuration of the Tofino 1 chip. Due to license of some used APIs (e.g., proprietary SAL for Hardware initialization), these code parts are removed.
If you want to use BMv2, this must be built with GRPC support.
As new component of the paper Resilient Multi-Tenant Code Updates for Adaptive Network State Changes
, a rules updater is introduced which can add/update/delete rules for provider tables as well as tenant tables.
The communication is done via GRPC. The MOC Shell in the MD-OMuProCU repository can be used to use it.
In this file, the configuration for tenants is saved which consist of:
- Tenant ID as key (number)
- Name of the tenant
- VNIs which the tenant can use for its accelerated CNFs.
- Names of deployed TDCs
- Names of the main ingresses defined in the submitted TDCs (ATTENTION: This will be automatically configured!)
This contains the configuration of addresses and ports for GRPC server of the OMuProCU components.
The configuration In-Network Updater component can be done here. Mainly, new accelerators can be added or existing ones changed. If a new accelerator is added, the name (more precisely the key in the dict) must be added to the extern_blacklist.json!
Here is possible to configure the time measurement used for evaluating and experimenting in the paper.
If any extern should not be used by a tenant, this can be added into the list of the associated accelerator.