BR102019009234A2 - network device and method for dynamically processing network traffic with sdn structure and protocol independent - Google Patents

Abstract

The proposed technology presents an SDN (Software-Defined Networking) device implemented in hardware and a method to process traffic on a network device with SDN structure in a dynamic and protocol-independent way. An architecture is proposed to be applied to a network device, it uses eBPF (extended Berkeley Packet Filter) instructions generated from programs in C or P4 language created by the user. The technical effects achieved by the proposed technology are: 1) Data plan fully programmable via control plan (user space) without the user having knowledge in hardware programming. 2) Possibility of using new dynamically defined fields and protocols, without the need to recompile or restart the router when the user changes, at run time, the way the flows must be processed, providing zero downtime of the device. The proposed device can also be used as a switch or network interface.

Description

NETWORK DEVICE AND METHOD FOR PROCESSING NETWORK TRAFFIC WITH SDN STRUCTURE IN A DYNAMIC AND PROTOCOL-INDEPENDENT MODE

[01] The proposed technology features an SDN (Software-Defined Networking) device implemented in hardware and a method to process traffic on a network device with SDN structure in a dynamic and protocol-independent manner. An architecture is proposed to be applied to a network device, it uses eBPF (extended Berkeley Packet Filter) instructions generated from programs in C or P4 language created by the user. The technical effects achieved by the proposed technology are: 1) Data plan fully programmable via control plan (user space) without the user having knowledge in hardware programming; 2) Possibility of using new dynamically defined fields and protocols, without the need to recompile or restart the router when the user changes, at run time, the way the flows must be processed, providing zero downtime of the device. The proposed device can also be used as a switch or network interface.

[02] The OpenFlow standard [McKeown et al. 2008] is an example of SDN, which has grown significantly since the launch of its first version in 2008 until the release of the current version (1.5) [Kreutz et al. 2015]. The first version of OpenFlow came up with a matching table containing only ten fields and evolved into multiple tables with 44 different fields [Kreutz et al. 2015]. However, the number of fields supported by OpenFlow is constantly being updated to support new fields and protocols such as the IPv6 protocol. Unfortunately, OpenFlow has a protocol-dependent data plan with analysis, matching and fixed actions, making it difficult to support new fields and protocols [Jouet and Pezaros 2017]. (McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S., and Turner, J. (2008). Openflow: Enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev., 38 (2): 69-74.). (Kreutz, D., Ramos, FMV, Veríssimo, PE, Rothenberg, CE, Azodolmolky, S., and Uhlig, S. (2015). Software-defined networking: A comprehensive survey. Proceedings of the IEEE, 103 (1): 14-76.). (Jouet, S. and Pezaros, DP (2017). Bpfabric: Data plane programmability for software defined In Proceedings of the Symposium on Architectures for Networking and Communications Systems, ANCS '17, pages 38-48, Piscataway, NJ, USA. IEEE Press.)

[03] The technology proposed by Jouet and Pezaros (2017) presents a protocol, platform and SDN environment independent of protocol (BPFabric) to centrally program and monitor the data plan. BPFabric takes advantage of eBPF (extended Berkeley Packet Filter), a set of protocol and platform independent instructions to define the data plan packet processing and routing functionality. We introduced a control plan API that allows data plan functions to be deployed in uptime. However, the technology described by Jouet and Pezaros (2017) differs from the technology proposed in this patent application because it does not describe any specific technical details about the hardware implementation of the proposed system and method.

[04] The document US2018041450 (A1), entitled "Protocol independent programmable switch (pips) for software defined data center networks", with priority date of 12/30/2013, presents system and software defined network method (SDN) with one or more input ports, a programmable analyzer, a plurality of programmable search and decision engines (LDEs), programmable search memories, programmable counters, a programmable re-enrollment block and one or more output ports . The analyzer's programming capabilities, LDEs, search memories, counters and rewrite block allow a user to customize data analysis needs, package processing functions and other functions as desired. In addition, the same microchip can be dynamically reprogrammed for other purposes and / or optimizations. However, US2018041450 (A1) technology differs from the technology proposed in this patent application because it does not describe any specific technical details about the hardware implementation of the proposed system and method.

[05] Thus, none of the technologies belonging to the state of the art simultaneously provide the technical effects achieved by the proposed technology, which are: 1) Data plan fully programmable via the control plan (user space) without the user having knowledge in programming. hardware. 2) Possibility of using new dynamically defined fields and protocols, without the need to recompile or restart the router when the user changes, at run time, the way the flows must be processed, providing zero downtime of the device.

BRIEF DESCRIPTION OF THE FIGURES

[06] FIGURE 1 - Figure 1 shows a possible, but not limiting, configuration of the technology. The diagram in the figure allows visualizing the architecture that has a logically centralized controller (13) that communicates through a socket (16) with the network elements (routers and switches). Between the controller and the router there is an API that allows the controller to send platform-independent programs and protocols within the user space (14) (Ex .: C and P4 languages).

[07] FIGURE 2 - Figure 2 shows a possible, but not limiting, technology configuration of the network device formed by the following modules: input arbiter (001), output port lookup (002) and output queues (003) together with technical elements that are exclusive to the proposed invention: 1) a finite state machine (004) for removing packages from a row; 2) an instruction memory (007) to store eBPF instructions that define the behavior of the device's data plane; 3) an eBPF processor (005) to determine network analysis, matching and packet operations; 4) a module (006) of action on the packages to carry out the analysis, matching and package actions of the network.

[08] FIGURE 3 - Figure 3 shows a possible, but not limiting, configuration of the eBPF processor (005) composed of: a program counter (008), a register bank (012), an arithmetic logic unit ( 010), an instruction memory (007), a data memory (011), a control module (009), an input for the clock or reset signal (015), a socket (016) of communication between processor ( 005) and a software controller (013) to define the behavior of the device's data plane. Figure caption: CLK: Clock; RST Reset; Reg_dst: Destination register; Reg_orig: Source register.

[09] FIGURE 4 - Figure 4 (a) shows the synchronism of the NetFPGA modules that work in a standardized way with the respective signals in the hardware. The write (wr) and ready (rdy) signals control the communication between the modules. The wr signal informs when the previous module is ready to transmit (has content to transmit) and the rdy signal informs that the posterior module is ready to receive. The transfer of data between modules only occurs if both signals are active. Each module contains an input queue and a state machine. The internal queue is used to temporarily store the data and ctrl signal until the module's state machine can remove the word and the control from the queue to begin processing. The state machine (004) of each module has a specific behavior, for example, the output port lookup module defines the output port according to the input port.

DETAILED TECHNOLOGY DESCRIPTION

[010] The proposed technology features an SDN network device implemented in hardware and a method to process traffic on a network device with an SDN (Software-Defined Networking) structure in a dynamic and protocol-independent manner. An architecture is proposed to be applied to a network device, it uses eBPF instructions generated from programs in C or P4 language created by the user.

[011] Figure 1 shows a possible configuration, but not limiting the technology. The diagram in the figure allows visualizing the architecture that has a controller (013) logically centralized that communicates through a socket (016) with the network elements (routers and switches). Between the controller and the router there is an API that allows the controller to send platform-independent programs and protocols within the user space (014) (Ex .: C and P4 languages). The proposed device and process are presented below:

[012] The network device with SDN structure that processes the network traffic in a dynamic and protocol-independent way comprises the following elements: 1) a finite state machine (004) to remove packets from a queue; 2) an instruction memory (007) to store eBPF instructions that define the behavior of the device's data plane; 3) an eBPF processor (005) to determine network analysis, matching and package operations, consisting of: a program counter (008), a register bank (012), an arithmetic logic unit (010), an instruction memory (007), a data memory (011), a control module (009), an input for the clock or reset signal (015), a socket (016) for communication between processor (005) and a software controller (013) for defining the behavior of the device's data plane; 3) a module (006) of action on the packages to carry out the analysis, matching and package actions of the network.

• a) armazenar instruções eBPF para definir o comportamento do plano de dados que são geradas compilando e executando programas eBPF desenvolvidos usando linguagens de alto nível criados pelo usuário;
• b) utilizar uma máquina (004) de estados finitos para retirar o pacote da fila interna do módulo output port lookup (encaminhado pelo módulo input arbiter);
• c) armazenar o pacote retirado da fila obtido na etapa “b” e armazená-lo na memória de dados (011) do processador eBPF (005), inicializar o processador;
• d) realizar operações de análise, casamento e ações, geradas no processador eBPF (005) com base nas instruções eBPF instaladas na memória de instruções (007) obtidas na etapa “a” utilizando o módulo (006) de ação nos pacotes;
• e) encaminhar o pacote obtido na etapa “c” para filas de saída do dispositivo através do módulo output port ou descartá-lo conforme o valor lido no banco de registradores (012) obtido após o término da execução do programa eBPF pelo processador eBPF (005).

[013] The method for processing packages on a device with an SDN structure comprises the following steps:

• a) store eBPF instructions to define the behavior of the data plan that are generated by compiling and running eBPF programs developed using high level languages created by the user;
• b) use a finite state machine (004) to remove the package from the internal queue of the output port lookup module (forwarded by the input arbiter module);
• c) store the package removed from the queue obtained in step “b” and store it in the data memory (011) of the eBPF processor (005), initialize the processor;
• d) perform analysis, matching and action operations, generated in the eBPF processor (005) based on the eBPF instructions installed in the instruction memory (007) obtained in step “a” using the action module (006) in the packages;
• e) forward the package obtained in step “c” to the device's output queues through the output port module or discard it according to the value read in the register bank (012) obtained after the eBPF program is finished running by the eBPF processor ( 005).

[014] In step “a”, the high-level languages used to generate the eBPF instructions are the languages C and P4. The proposed device and process apply to switch or network interface.

[015] The proposed SDN router design can vary as follows: 1) the device can have an eBPF processor for each input queue using a shared instruction memory; 2) TCAM / SRAM memories can be inserted as tables for matching flows in the device; 3) The device can also be used as a switch or network interface 4) the method can implement hash functions to identify and classify flows; 5) Expand in the method the number of metadata fields to perform tasks of measurement and monitoring of the network performance.

[016] The technology can be better understood through the example below, without limitation:

[017] Example: Prototype implemented on the NetFPGA 1G platform 1. Implementation

[018] Figure 2 presents an overview of the implementation of the SDN router on the NetFPGA platform. The implementation of the SDN router is composed of two components: data plan and user space tools. The data plan contains hardware modules that belong to the NetFPGA standard library (gray modules) and specific SDN router modules (orange modules). The tools in the user space are composed by a controller responsible for defining how the data plan will forward the packages, and software to configure the data plan functionalities, according to the C and P4 programs created by the users.

1.1 Data plan

[019] The NetFPGA standard library provides the following modules: input arbiter [001], output port lookup [002] and output queue [003].

[020] Input arbiter: Receives packets from the network (via MAC interface) or from the PCI bus (via CPU) in 64-bit word format and stores them in internal queues of the module. Then, the words are removed from the queues using the round robin algorithm, and forward them to the output port lookup module.

[021] Output port lookup: Defines which port the packet will be sent based on the properties of the packet, for example, gateway or destination address. The outgoing port of all incoming packets is configured in the outgoing metadata port field.

[022] Output queue: Decides which output queue the packet will be stored based on the metadata output port field. The SDN router extends the NetFPGA data path with three hardware modules (orange): eBPF processor [005], action in the [006] package and instruction memory [007].

[023] eBPF processor: It is responsible for performing the analysis, matching and actions using the instructions stored in the instruction memory. In addition, the processor communicates with the control plane through a socket.

[024] Action on the package: Forward or discard the package according to the value stored in register r0 after processing the eBPF instructions.

[025] Instruction memory: In the instruction memory, the eBPF instructions generated from the C and P4 codes created by the user are stored. These instructions define the behavior of the data plan.

1.1.1 State machine

• a) Aguarda o cabeçalho do pacote;
• b) Armazena o cabeçalho e metadado na memória do processador eBPF;
• c) Armazena o Payload do pacote na memória do processador eBPF;
• d) Inicializa o processador eBPF;
• e) Espera o processador eBPF terminar de processar o pacote;
• f) Retira o cabeçalho e o payload da memória do processador eBPF;
• g) Encaminha o cabeçalho e o payload;

[026] The state machine (004) (finite state machine, FSM) in the output port lookup module controls the entire operation of packet processing. It removes the package from the module's internal queue (forwarded by the input arbiter module), starts the execution of the eBPF instructions and forwards the package to the next module (action in the package) when the last eBPF instruction (output) is executed. The functioning of the WSF follows the following steps:

• a) Awaits the package header;
• b) Stores the header and metadata in the eBPF processor memory;
• c) Stores the Payload of the package in the eBPF processor memory;
• d) Initializes the eBPF processor;
• e) Wait for the eBPF processor to finish processing the package;
• f) Remove the header and payload from the eBPF processor memory;
• g) Forward the header and payload;

1.1.2 eBPF processor

[027] The eBPF processor is responsible for performing the analysis, matching and actions according to the eBPF instructions generated from the C or P4 code created by the user in the user space. Before starting the operation of the SDN router, the user must load the eBPF instructions in the instruction memory to define the behavior of the data plan of the router.

[028] Figure 3 shows the data and control path of the eBPF processor at register transfer level (RTL) containing five functional units: program counter [008], instruction memory [007], control [009], arithmetic logic unit (ALU) [010] and data memory [011].

[029] Program Counter: Defines which instruction will be selected in the instruction memory.

[030] Control: The controller receives the operation code and forwards the control signals to the functional units, defining the behavior of each unit. For example, instructions from the ALU class (logical and arithmetic unit) do not use the data memory, so the read / write signals are not active in the data memory.

[031] Arithmetic logic unit: The ALP of the eBPF processor is capable of performing arithmetic and logic operations based on the signal sent by the control. The ALU result can be forwarded as a data memory address or as a writing data of the destination register in the register bank.

[032] Data memory: The data memory has the function of storing the metadata and words of the package so that the eBPF processor performs the actions in the package according to the eBPF instructions. The size of the data memory of the eBPF processor has a capacity of up to 256 64-bit words. With this capability, only one metadata and a packet of up to 1,500 bytes can be stored. We defined the data memory with this capacity due to the little logical resource (53,000 logical cells) available in the FPGA of NetFPGA 1G.

[033] Bank of Registrars: Reading and writing operations are carried out on the registrars. In the read operation, the register bank receives the addresses of the destination / origin register and forwards the data referring to the addresses to ALU. The write operation in the register bank is performed after reading the data in the data memory or ALU operation. Table 1 describes the functionality of each eBPF recorders.
Table 1: Description of the eBPF register set.

1.1.3 Instruction set architecture

[034] After leaving the instruction from the instruction memory [007], the instruction is divided into five parts: operation code (opcode), destination register address and origin register, offset and immediate. Each part of the instruction is sent to a specific unit.

[035] The eBPF opcode is divided into seven classes: immediate load, load, immediate store, store, logical and arithmetic operations, deviations, 64-bit logical and arithmetic operations, and the other class is reserved for future use. The eBPF processor has a 64-bit instruction, 32 bits for representing an immediate number (imm), 16 bits for the offset, 4 bits for the origin register, 4 bits for the destination register and, finally, the operation code 8-bit. The opcode can be divided depending on the class of the instruction. For load and store, the opcode has 3 most significant bits for memory access mode, 2 bits for word size and 3 bits for instruction class. For the arithmetic and logic bypass instructions, the 4 most significant bits specify what the operation is, 1 bit to specify whether the instruction is carried out with the immediate value or with the original operand and finally 3 less significant bits for the class instruction.

[036] The eBPF processor has a set of instructions responsible for reading and writing data memory with the following types of size: 8 bits (byte (B)), 16 bits (half-word (H)), 32 bits ( word (w)), and 64 bits (double word (DW)). In order to be able to read and write data of varying sizes in the data memory, it was necessary to create control signals responsible for controlling the data memory module that specified the block size to be read.

1.1.4 Action in the package

[037] The return value of the eBPF engine, which is stored in register r0, is used to determine what action should be performed on the package. Table 2 describes the return values of the eBPF and their respective actions performed in the package. After eBPF finishes computing, the packet can: be forwarded to the exit port; forwarded to the controller; be discarded; do the flood.
Table 2: Actions performed on the package.

[038] NetFPGA hardware consists of four Ethernet ports. Each port contains two MAC and CPU queues (figure 2) where the packet can be forwarded. The encoding values of the respective actions are based on the number of ports on the NetFPGA platform.

1.1.5 Instruction memory

[039] eBPF instructions define the behavior of how the eBPF processor will process packets. Instructions are inserted into the instruction memory via the NetFPGA register interface. Software recorders have been created to insert the eBPF instructions into the processor's instruction memory. Instructions are received at the router via a message sent by the controller. The instructions are then written to the software registers and forwarded to instruction memory via the hardware PCI bus.

[040] As a design decision we decided to place the instruction memory outside the eBPF processor with the aim of, in the future, connecting several processors using an instruction memory in a shared way. By increasing the number of eBPF processors in the SDN router's data path, more packets can be processed, contributing to increased router throughput.
1.1.6 Metadata
Table 3: Metadata: Information taken from the package and stored in the data memory of the eBPF processor.

[041] The data plane receives the packet through the input interface and stores the packet in the input queue with some additional information called metadata. Table 3 shows the stored structure. First the metadata is received, then the Ethernet frame or IP packet. Pre-fixed metadata can also be used by the eBPF program just like any other protocol field. The currently defined metadata is the destination port, the packet size in multiples of 64 bits, the source port, the packet size in bytes, the timestamp in seconds and nanoseconds. The 64-bit and byte packet size fields were included because the input queue module already provided this information.

1.2 Hardware instance

[042] The proposed SDN router was implemented on the NetFPGA 1G hardware. The NetFPGA1G hardware has four 1 Gbps Ethernet ports. NetFPGA has a Vertex-II Pro 50 FPGA with 53,136 logic cells, a 4 KiB SRAM with 219 lines and an 8 ns (125 MHz) clock cycle.

[043] Packets on the NetFPGA are processed in the form of 64-bit words and 8-bit control to identify the type of word (data or metadata). Words are transmitted by the data signal and the control by the ctrl signal. If the control signal is equal to zero it means that the words in the packet are being transmitted, otherwise the words are from the metadata.

[044] The synchronization of NetFPGA modules works in a standardized way. Figure 4 shows the synchronism of the modules with the respective signals in the hardware. The write (wr) and ready (rdy) signals control the communication between the modules. The wr signal informs when the previous module is ready to transmit (has content to transmit) and the rdy signal informs that the posterior module is ready to receive. The transfer of data between modules only occurs if both signals are active.

[045] Each module contains an input queue and a state machine. The internal queue is used to temporarily store the data and ctrl signal until the module's state machine can remove the word and the control from the queue to begin processing. The state machine of each module has a specific behavior, for example, the output port lookup module defines the output port according to the input port.

Claims (8)

Network device for processing network traffic with SDN structure in a dynamic and protocol-independent manner characterized by comprising the following elements: 1) a finite state machine (004) for removing packets from a queue; 2) an instruction memory (007) to store eBPF instructions that define the behavior of the device's data plane; 3) an eBPF processor (005) to determine network analysis, matching and package operations, consisting of: a program counter (008), a register bank (012), an arithmetic logic unit (010), an instruction memory (007), a data memory (011), a control module (009), an input for the clock or reset signal (015), a socket (016) for communication between processor (005) and a software controller (013) for defining the behavior of the device's data plane; 3) a module (006) of action on the packages to carry out the analysis, matching and package actions of the network. Network device to process network traffic with SDN structure in a dynamic and protocol-independent manner, according to claim 1, characterized by being applied to a network switch or interface. Network device for processing network traffic with SDN structure in a dynamic and protocol-independent manner, according to claim 1, characterized by having an eBPF processor for each input queue using a shared instruction memory. Network device for processing network traffic with SDN structure in a dynamic and protocol-independent manner, according to claim 1, characterized by inserting TCAM / SRAM memories as tables for matching flows. Method for processing network traffic with SDN structure in a dynamic and protocol-independent manner characterized by understanding the following steps:

• a) store eBPF instructions to define the behavior of the data plan that are generated by compiling and running eBPF programs developed using high level languages created by the user;
• b) use a finite state machine (004) to remove the package from the internal queue of the output port lookup module (forwarded by the input arbiter module);
• c) store the package removed from the queue obtained in step “b” and store it in the data memory (011) of the eBPF processor (005), initialize the processor;
• d) perform analysis, matching and action operations, generated in the eBPF processor (005) based on the eBPF instructions installed in the instruction memory (007) obtained in step “a” using the action module (006) in the packages;
• e) forward the package obtained in step “c” to the device's output queues through the output port module or discard it according to the value read in the register bank (012) obtained after the eBPF program is finished running by the eBPF processor ( 005).

Method for processing network traffic with SDN structure in a dynamic and protocol-independent manner, according to claim 5, step “a”, characterized by the high-level languages used to generate the eBPF instructions being the C and P4 languages. Method for processing network traffic with SDN structure in a dynamic and protocol-independent manner, according to claim 5, characterized by Implementing hash functions to identify and classify flows. Method for processing network traffic with SDN structure in a dynamic and protocol-independent manner, according to claim 5, characterized by expanding the number of metadata fields to perform tasks for measuring and monitoring network performance.

Images