JarCastingSBI
This project implement an OpenFlow 1.0 controller southbound interface (SBI) using the ECES framework.
The module corresponds to the reference implementation of the SBI of the network controller for the Chameleon networking system for predictable latency in programmable networks published in:
Usage
The project can be downloaded from maven central using:
<dependency>
<groupId>de.tum.ei.lkn.eces</groupId>
<artifactId>sbi</artifactId>
<version>X.Y.Z</version>
</dependency>
The module can for example be started with the following snippet:
Set<ExpectedHost> hosts = new HashSet<>();
hosts.add(new ExpectedHost(InetAddress.getByName("scholes.forschung.lkn.ei.tum.de"), "0000:04.00.0"));
hosts.add(new ExpectedHost(InetAddress.getByName("kane.forschung.lkn.ei.tum.de"), "0000:04.00.0"));
hosts.add(new ExpectedHost(InetAddress.getByName("gerrard.forschung.lkn.ei.tum.de"), "0000:04.00.0"));
Set<InetAddress> switches = new HashSet<>();
switches.add(InetAddress.getByName("leicester.forschung.lkn.ei.tum.de"));
switches.add(InetAddress.getByName("watford.forschung.lkn.ei.tum.de"));
switches.add(InetAddress.getByName("newcastle.forschung.lkn.ei.tum.de"));
switches.add(InetAddress.getByName("tottenham.forschung.lkn.ei.tum.de"));
switches.add(InetAddress.getByName("liverpool.forschung.lkn.ei.tum.de"));
switches.add(InetAddress.getByName("mancity.forschung.lkn.ei.tum.de"));
switches.add(InetAddress.getByName("westham.forschung.lkn.ei.tum.de"));
switches.add(InetAddress.getByName("fulham.forschung.lkn.ei.tum.de"));
switches.add(InetAddress.getByName("chelsea.forschung.lkn.ei.tum.de"));
new SBISystem(controller, networkingSystem, network, hosts, switches, 10, 3, false);
Architecture
Chameleon relies on source routing for providing predictable latency in programmable networks. Servers (i.e., end hosts) run virtual machines (VMs) that wish to communicate with each other in the network.
Packets sent by VMs are captured in a virtual switch that is responsible for tagging (with VLAN tags) and shaping flows. The tags the virtual switch adds correspond to the successive actions the switches in the network must take when they receive the packet. Each time a switch receives a packet, it outputs it to a particular output port and queue based on the outermost VLAN tag and pops the latter.
The switches are configured at the startup of the network with static rules: a particular outermost VLAN tag corresponds to a particular output port and queue. The configuration of a new flow simply requires to update the tagging rules in the virtual switch of the source VM.
More details about the architecture, the implementation, the goal, and the performance of Chameleon can be found in the 2020 CoNEXT article where the system was originally published. Section 4.1 focuses on the implementation of the control part.
Operations
- Upon startup, the module connects to the
ExpectedHosts passed as parameter and checks that they satisfy all the requirements (see below). - The module then waits for all the expected switches passed as parameter to initiate an OpenFlow 1.0 connection.
- When a switch successfully connects, the module installs the static rules that match each output port / queue combination to a VLAN tag.
- When all the expected switches are connected, the module starts topology discovery by sending LLDP packets (see send-lldp.py script) from the servers into the network and from each switch to all its neighbor switches. The discovered topology is created in the network module.
- Once the topology is discovered, the module starts the Chameleon virtual switch on all the servers (see start-dpdk-application.sh script).
- Once all the virtual switches are started, the module waits for events from the tenant manager module:
- When a new
VirtualMachineis created by the tenant manager, the SBI module actually spins up the VM on the corresponding server (see the create-vm script). - When a new
Flowis created by the tenant manager and routed by the routing module, the SBI module configures the corresponding matching rule in the virtual switch of the source VM (using the update-matching-table.py script).
- When a new
Requirements
The Chameleon code and scripts for the end hosts, their VMs, and the Chameleon virtual switch are available here.
For end hosts (checks for that are implemented at startup in the checkDependenciesOnExpectedHostsAndInitialize method of the SBISystem):
- They are supposed to be reachable over
sshasrootand using the private key stored in~/.ssh/id_rsa. - They must have
perl,python3,scapy,docker, andvagrantinstalled (see the install-dependencies.sh script). - They must have the Chameleon
start-dpdk-tagging(starts the Chameleon virtual switch),stop-dpdk-tagging,create-vm,delete-vm, andlist-vmsscripts installed under/usr/bin(see the deploy-scripts.sh script). - The base vagrant box must be already created (using the create-base-box.sh script).
- See also the Chameleon virtual switch README for the configurations to ensure that the virtual switch exhibits a predictable latency.
The switches must be OpenFlow 1.0 switches that support priority queuing, and VLAN matching and popping.
Relevant switch performance parameters (processing time, priority queuing overhead, number of queues, and per-queue buffer size) must be configured in the SwitchCapabilities class. The parameters configured in this repository corresponds to those measured for our switches in our article: