The C files in this directory are used to experiment with VLAN configurations within the switch and endpoints to understand their impact on the latency and packet-drop rate. There are no TSN-specific mechanisms used or configured within these files, although it is a useful diagnostic when configuring the TSN switch.
NB: The interfaces, IP addresses, VLAN ID's, etc. are set in constants.h. This should be modified to match the names and addresses of the machines used in your system. We recommend designating one device to each role.
The network in this application consists of 3 endpoints (11th gen NUC mini-PC's with Intel i225-LM NICs) running Ubuntu 20.04 LTS. Each endpoint is directly connected to a TSN-enabled switch. One endpoint is a data source, periodically producing information that needs to get to another endpoint that is acting as the data sink. At the same time, a jammer injects meaningless data into the network, ideally sent to the sink to saturate that link and prevent source-data from getting there. Note that in the network used for testing, there is only 1 switch. This is a test of the Switch's ability to prioritize traffic sent across one link. The sink device MUST be capable of hardware time-stamping and must also be tightly synchronized with the source (see ptp config).
To get a measure of latency, the source sends data with a recent timestamp and the sink retrieves a hardware timestamp from when that message was received. Note that the source is not using the actual time of sending, but just before - using the real TX time would require a follow-up message containing that value (similar to PTP). The sink will store TX-RX latency, along with a frame-counter, experiment ID, and priority into a CSV file, which can be analyzed and plotted using some latency processing python scripts.
Note that while the jammer is active, an SSH session served through the same link may become unresponsive and fail. It is helpful to use a separate interface, such as Wi-Fi, for the remote session.
There are implementations using Raw (Ethernet), UDP, and TCP sockets as we were exploring how to configure and use VLANs to prioritize and shape traffic through the switch. We'll explain any intricacies below.
Run make all from this directory to compile the source, sink, and jammer executables.
Most of the executables do not take/need command line arguments, although you can override the default priority with an integer between 0 and 7 to the XYZ_source.out* executable.
It is recommended to start the sink first, since the latency processing will calculate a packet drop rate, assuming that frame/packet ID 0 was sent after the sink program started. For a full test involving the jammer, that should also be started before the source. The source and sink will print some information for every message send and received, respectively. The sink will automatically exit after it receives 1000 frames.
Either jammer (Ethernet or UDP) may be used to the same effect. However, the source and sink should use the same type of socket (Ethernet, UDP, or TCP).
The Ethernet example uses Raw Sockets to send directly from the MAC address of the source to the MAC of the sink. The switch will forward this information and preserve VLAN tags if configured as per the instructions.
Like UDP, there is no such thing as a connection for Raw sockets. The source socket sends frames to a MAC address (which is also manually added to the first few bytes of the frame's header) with an ethernet frame type (see if_ether for examples), and a sink socket declares a frame type that it wishes to receive.
The Ethernet jammer will also attempt to send directly to the sink's MAC address. The jammer can be slowed down using a few global variables defined in the first few lines of the C code. Traffic must go through the switch.
The UDP example uses UDP sockets to send from the source to the sink through a VLAN. Both the source and sink must bind to the IP provided to the VLAN of interest, although they need not connect. Binding will force Linux to tag outgoing frames with the corresponding VLAN ID and priority (based on the socket priority and the VLAN's egress-qos-mapping).
The UDP jammer will attempt to send to the sink using one of it's IP addresses. The sink IP used should either be a different VLAN's IP or it's generic IP. Note that if using a generic IP, it may travel along a strange path (e.g., through the switch to a Wi-Fi router to the sink) such that it does not jam the link that data from the source will take (linux tool nload is helpful for checking per-interface network load). The jammer can be slowed down using a few global variables defined in the first few lines of the C code.
The TCP example uses TCP sockets for the source and sink. Importantly, both sockets must be on the same VLAN and be given the same priority for traffic to be prioritized. If these mismatch, acknowledgements may fail to arrive when a jammer is present, despite arrival of packets carrying application data. Note that the source will fail immediately if the source is not started first, as it will fail to connect.
There is no TCP jammer implemented, as that may be artificially slowed based on the sink's ability to receive messages and respond with acknowledge or any other control messages.