Commutateur réseau | EPFL Graph Search

Un commutateur réseau, ou switch, est un équipement qui relie plusieurs segments (câbles ou fibres) dans un réseau informatique et de télécommunication et qui permet de créer des circuits virtuels. La commutation est un des deux modes de transport de trame au sein des réseaux informatiques et de communication, l'autre étant le routage. Dans les réseaux locaux (LAN), il s'agit le plus souvent d'un boîtier disposant de plusieurs ports RJ45 (entre 4 et plusieurs centaines), il a donc la même apparence qu'un concentrateur (hub). Il existe aussi des commutateurs pour tous les types de réseau en mode point à point comme pour les réseaux ATM, relais de trames Principe de mise en œuvre Contrairement à un concentrateur, un commutateur ne reproduit pas sur tous les ports chaque trame qu'il reçoit : il sait déterminer sur quel port il doit envoyer une trame, en fonction de l'adresse de destination de cette trame. Les commutateurs sont souvent utilisés pour remplacer des concentra

Advancing the State of Network Switch ASIC Offloading in the Linux Kernel

Andy Roulin

Modern data-center network operating systems rely on proprietary user-space daemons wrapping SDKs from switch vendors. Linux-based variants of these operating systems have benefited from increasing and simplified dataplane offloading support in recent years: kernel resources such as routes and next hops are offloaded to hardware and the kernel can, e.g., learn new MAC entries seen from the hardware forwarding plane. However, the Linux kernel in these operating systems has to be extended and customized as it still lacks constructs (constructs exposed to user-space or in-kernel constructs) needed for complete control plane processing and dataplane offloading. Managing limited hardware resources and keeping the kernel and hardware forwarding planes equivalent are two examples of challenges where the lack of appropriate constructs forces switch operating systems to use user-space solutions coupled with proprietary SDKs and custom kernel modifications. Filling the gaps, i.e., designing and adding the missing constructs, would enable faster control plane processing (less user-kernel context switches) and faster dataplane configura- tion. It would also encourage in-tree kernel drivers from hardware vendors instead of the current closed-source user-space SDKs which would also improve performance while estab- lishing Linux as the standardized API for network switches. This thesis explores the different designs, performance challenges and trade-offs of completing the in-kernel switching API, starting from switch port configuration, faster control path packet processing and ending with in-kernel ASIC resource management. As most hardware vendors are not yet ready to open their drivers in the kernel, workarounds to still provide support for vendors’ SDKs through the same in-kernel API are presented as well. A user-space switch port driver for Mellanox switches was ported to kernel space in order to accelerate control plane processing and bootstrap the in-kernel switch port configuration design. A prefetching scheme which hides PCI latency was designed to manage limited and shared ASIC resources with synchronous feedback to user-space daemons in case of exhausted resources.

2018

Low-Latency High-Bandwidth Circuit and System Design for Trigger Systems in High Energy Physics

Marcos Vinícius Silva Oliveira

The increasing luminosity in HEP (High Energy Physics) colliders demands trigger systems to be more selective. First, more information from the detector is routed to the trigger system. Second, larger parts of this information are processed together. These two requirements introduce new challenges, such as higher bandwidth and higher integration, in terms of data transfer and processing of trigger systems. Both problems have to be addressed, ensuring that hardware and firmware have low and fixed latency, and are reliable. Low latency is essential due to the limited storage available in the detector front-end pipelined memories. Fixed latency is needed because the trigger processing is pipelined, and the inputs need to be time-aligned at every processing step. Reliability is important for high trigger efficiency. If the trigger is not reliable, rare events can be discarded, and uninteresting events accepted. This Ph.D. thesis presents the upgrade of part of the trigger system of ATLAS (A Toroidal LHC AparatuS). ATLAS is one of the detectors at the world's largest and most powerful particle collider, the LHC (Large Hadron Collider) at CERN (European Center of Nuclear Research). The online trigger system of ATLAS is segmented in two levels. The first level is implemented with custom electronics. For the parts of the first level trigger not exposed to radiation, digital processing is primarily implemented using FPGA (Field Programmable Gate Array) devices. FPGAs offer high processing capacity with low-latency and re-programmability, i.e., the capability of changing the implemented logic. The second level is built from commercial computers, network switches, and custom software. The rate of bunch of particles crossing in the interaction point is 40 MHz, and the first level (Level-1) trigger needs to reduce the rate down to 100 kHz with a very low latency of 2.5 us. Part of the Level-1 trigger system, the MUCTPI (Muon to Central Trigger Processor Interface) connects the output of the barrel and endcap muon trigger to the CTP (Central Trigger Processor), which takes the final Level-1 accept decision. The first part of this Ph.D. thesis addresses the work on the data transfer part of the MUCTPI. Latency optimized FPGA (Field Programmable Gate Array) MGT (Multi-Gigabit Transceiver) configurations have been found. Moreover, an IP (Intellectual Property) core to synchronize data from 208 SL inputs with low and fixed latency has been developed. The total data transfer and synchronization latency is below 125 ns, corresponding to 60% of the latency budget. All MUCTPI on-board and off-board high-speed serial links have been tested. The Bit Error Rate (BER) values for all links running at 12.8 Gb/s have been measured as lower than one bit error per day with a confidence level of 95%. This value is acceptable as it corresponds to only one potential fake trigger or lost event per day. The second part of this thesis covers the development of the MUCTPI sorting network and its FPGA implementation using RTL (Register-Transfer Level) and HLS (High-Level Synthesis) approaches. Both approaches achieved a very low latency value of 31.25 ns, corresponding to only 15% of the latency budget. HLS provided advantages such as requiring much less design effort, enabling early testing, and having slightly higher performance in terms of timing slack and logic resource usage.

EPFL2021

Automating the Testing of OpenFlow Applications

Marco Canini, Dejan Kostic, Jennifer Rexford

Software-defined networking, and the emergence of OpenFlow-capable switches, enables a wide range of new network functionality. However, enhanced programmability inevitably leads to more software faults (or bugs). We believe that tools for testing OpenFlow programs are critical to the success of the new technology. However, the way OpenFlow applications interact with the data plane raises several challenges. First, the space of possible inputs (e.g., packet headers and inter-packet timings) is huge. Second, the centralized controller has a indirect view of the traffic and experiences unavoidable delays in installing rules in the switches. Third, external factors like user behavior (e.g., mobility) and higher-layer protocols (e.g., the TCP state machine) affect the correctness of OpenFlow programs. In this work-in-progress paper, we extend techniques for symbolic execution to generate inputs that systematically explore the space of system executions. First, we analyze controller applications to identify equivalence classes of packets that exercise different parts of the code. Second, we propose several network models with increasing precision, ranging from simple traffic models to live testing on the target network. Initial experiences with our prototype, which symbolically executes OpenFlow applications written in Python, suggest that our techniques can help programmers identify bugs in their OpenFlow programs.

2011