A network testing system based on Fast platform

Abstract

The present invention relates to a network test system based on Fast platform, including software part and hardware part, the hardware part includes data packet generation module, statistics collection module and multiplexer module, the data packet generation module is located between the general forwarding action module and the general output engine module, and is used to generate messages and notify the relevant parameters of message sending under the control of the software part; the statistics collection module is located between the general matching engine module and the general forwarding action module, and is used to update the register recording the test result; the multiplexer module is located between the data packet generation module and the general output engine module, and is used to allocate the forwarding of different messages from the data packet generation module; the software part is used to control the hardware part and configure parameters to realize the test of multi-dimensional performance indicators in the network. The present invention can complete the test of multi-dimensional performance indicators of the network at a lower cost.

Description

Technical Field

[0001] The present invention relates to the technical field of network testing, and in particular to a network testing system based on a Fast platform. Background Art

[0002] At present, in many research works, it is necessary to use network testers to test and verify the performance and functions of equipment. Most of the testing and verification work is completed based on network testers. However, commercial network testers are expensive equipment, and many research institutions find it difficult to purchase and use them in large quantities, but they need network testers to test the performance and functions of the tested equipment; in addition, most commercial network testers are difficult to carry, which causes certain difficulties for users; thirdly, with the accelerated update and iteration of network technology, commercial network testers are difficult to keep up with the development of network technology (such as new network protocols), which requires users to purchase new products, resulting in high costs.

[0003] On the other hand, as industrial control networks and weapon equipment networks require more and more deterministic data transmission, network testing often needs to cover time-sensitive network (TSN) scenarios. For example, the basic scenario of time-sensitive network performance testing requires the tester to generate time-sensitive flows and other priority background flows at the same time, and test the relevant performance indicators of time-sensitive flows. However, the current mainstream commercial network testers do not have testing functions for time-sensitive network environments. Summary of the invention

[0004] The technical problem to be solved by the present invention is to provide a network testing system based on the Fast platform, which can complete the testing of multi-dimensional performance indicators of the network at a lower cost.

[0005] The technical solution adopted by the present invention to solve its technical problem is: to provide a network test system based on a Fast platform, including a software part and a hardware part, the hardware part is a FAST pipeline, including a general packet parsing module, a general keyword extraction module, a general matching engine module, a general forwarding action module and a general output engine module connected in sequence, the hardware part also includes a data packet generation module, a statistics collection module and a multiplexer module, the data packet generation module is located between the general forwarding action module and the general output engine module, and is used to generate a message under the control of the software part and notify the relevant parameters of the message sending; the statistics collection module is located between the general matching engine module and the general forwarding action module, and is used to update the register recording the test results; the multiplexer module is located between the data packet generation module and the general output engine module, and is used to coordinate the forwarding of different messages from the data packet generation module; the software part is used to control the hardware part and configure parameters to realize the test of multi-dimensional performance indicators in the network.

[0006] The data packet generation module comprises:

[0007] A message parsing unit, used to parse the received template message and store the parsed template message in a corresponding message storage unit according to the parsing result;

[0008] The first message storage unit, the second message storage unit and the third message storage unit are used to store the template message of the first message type, the template message of the second message type and the template message of the third message type respectively;

[0009] A first message sending unit, used to read a message from the first message storage unit at a preset rate, modify a preset field in the read message according to a preset rule, and send the modified message;

[0010] A second message sending unit, used to read the message from the second message storage unit at a preset rate, modify the preset field in the read message according to a preset rule, and send the modified message;

[0011] The third message sending unit is used to read the message from the third message storage unit at a preset rate, modify the preset field in the read message according to the preset rule, and send the modified message.

[0012] The statistics collection module includes:

[0013] A receiving unit, used for receiving a test message;

[0014] A storage unit is used to store the message type, data of interest and processing requirements required for the test;

[0015] A judgment processing unit is used to judge the type of the test message, and when the type of the test message is the message type required for the test, parse the test message;

[0016] A counting unit, used to count the data of interest in the parsed message;

[0017] The marking unit is used to mark the statistically counted messages according to processing requirements.

[0018] The multiplexer module comprises:

[0019] A message receiving unit, used for receiving the message sent by the data packet generating module;

[0020] A priority determination module, used to determine the priority of a received message;

[0021] The message sending module is used to determine the message sending order according to the message priority and send the message according to the sending order.

[0022] The software part is used to control the hardware part and configure parameters to implement the packet loss rate test of the network, specifically:

[0023] The software part configures the sending parameters to the hardware part and initializes the registers specified by all the collection parameters; when the fast packet arrives at the pipeline, the data packet generation module will determine whether the message feature field in the metadata of the message is set. If it is set, the message will be cached and sent at a specified rate under the control of the relevant registers, and the relevant fields in the message header-field will be updated before each transmission; each time a message is sent, the counter configured by the data packet generation module will be updated;

[0024] Before the test, the software part informs the statistical collection module of the protocol type and starting sequence number of the received message to be monitored by configuring the register; after receiving the configuration, the statistical collection module will update the configured counter after receiving the specified message, and set the DISCARD position of the metadata of the received message to 1, so that the message is discarded in the UDO module.

[0025] The software part is used to control the hardware part and configure parameters to implement a throughput test on the network, specifically:

[0026] The software part configures the packet loss rate test related parameters to the hardware part through FASTAPI according to the user configuration; the software part writes the initial value of the sending rate and the single-round test time into the data packet generation module; the software part sends the cached message to the data packet generation module through FASTAPI, and sets the test start flag to 1; when the timer in the data packet generation module checks that the packet sending time has reached the single-round test time, the test start flag is set to 0, the software part reads the relevant counter values, and updates the corresponding packet loss rate of the current round and the current iteration round; if the set round has not been reached, the packet sending rate and related registers of the next round are updated through "binary search" to trigger a new round of testing, until the number of iterations reaches the set number and stops, at which time the software part will read the relevant counter values ​​and simultaneously return the last round of packet loss rate and the final throughput to the user.

[0027] The software part is used to control the hardware part and configure parameters to implement the network delay test, specifically:

[0028] The software part configures the hardware part according to the parameters listed in the parameter table, and sends a filtering rule to the general matching engine module, so that all tag messages can be received by the statistics collection module and the accurate delay can be calculated based on the receiving / sending timestamps;

[0029] After the setup is completed, the software part sends the initial message to the data packet generation module through FASTAPI and sets the test start flag to 1. After the test starts, the timer controls the sending of a tag message at a fixed time t and records the sending time in the UDO module. When the statistics collection module receives the tag message, it subtracts the receiving timestamp recorded in the metadata from the sending timestamp in the message and enters it into the corresponding register. After the test is completed, the data packet generation module sets the test start flag to 0. At this time, the software part reads the relevant register value to obtain the test result.

[0030] The software part is used to control the hardware part and configure parameters to implement time-sensitive network testing without background flow, specifically:

[0031] The software part configures the hardware part according to the parameters listed in the parameter table, and sends a filtering rule to the general matching engine module, so that all tag messages can be received by the statistics collection module and the accurate delay can be calculated based on the receiving / sending timestamps;

[0032] After the setup is completed, the software part sends the time-sensitive message template to the data packet generation module through FASTAPI, stores it in the data packet generation module, and sets the test start flag to 1. After the test starts, the timer controls the sending of a tag message at a fixed time t and records the sending time in the UDO module; when the statistics collection module receives the tag message, it obtains the packet loss rate, throughput rate and latency through the data recorded in the metadata, and records them in the corresponding registers; when the test is completed, the data packet generation module sets the test start flag to 0, at which time the software part reads the relevant register values ​​to obtain the test results.

[0033] The software part is used to control the hardware part and configure parameters to implement time-sensitive network testing with background flow, specifically:

[0034] The software part configures the hardware part according to the parameters listed in the parameter table, and sends a filtering rule to the general matching engine module, so that all tag messages can be received by the statistics collection module and the accurate delay can be calculated based on the receiving / sending timestamps;

[0035] After the setup is completed, the software part sends the initial message template and the interference message template to the data packet generation module through FASTAPI, stores them in the data packet generation module, and sets the test start flag to 1. After the test starts, the timer controls the sending of a tag message at fixed intervals of t and records the sending time in the UDO module. At the same time, the timer controls the sending of interference messages at irregular intervals without statistics. When the statistics collection module receives the tag message, it obtains the packet loss rate, throughput rate and delay through the data recorded in the metadata, and counts them into the corresponding registers. When the test is completed, the data packet generation module sets the test start flag to 0. At this time, the software part reads the relevant register values ​​to obtain the test results.

[0036] Beneficial Effects

[0037] Due to the adoption of the above-mentioned technical scheme, the present invention has the following advantages and positive effects compared with the prior art: based on the FAST platform, the present invention uses the data structure, access hardware register interface function and complete or partial code of FPGAOS and UM pipeline provided by FAST at the software and hardware levels to provide network testing functions. At the same time, with the help of the programmability of the FAST platform, it supports the simultaneous generation of time-sensitive flows and other background flows, and supports the deterministic sending of time-sensitive flows and the sending of background flows with customized bandwidth characteristics. On this basis, it supports the frame deprivation mechanism of time-sensitive flows for background flows on the same port, so as to generate multiple flows concurrently without affecting the generation and testing of time-sensitive flows, so as to meet the needs of time-sensitive network scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 is a hardware schematic diagram of an embodiment of the present invention;

[0039] Figure 2 is a schematic diagram of a data packet generation module in an embodiment of the present invention;

[0040] Figure 3 It is a structural schematic diagram of a data packet generation module in an embodiment of the present invention;

[0041] Figure 4 is a schematic diagram of a state machine of a message parsing unit in an embodiment of the present invention;

[0042] Figure 5 is a schematic diagram of a state machine of a first message sending unit in an embodiment of the present invention;

[0043] Figure 6 is a schematic diagram of a state machine of a second message sending unit in an embodiment of the present invention;

[0044] Figure 7 is a schematic diagram of a state machine of a third message sending unit in an embodiment of the present invention;

[0045] Figure 8 is a schematic diagram of a statistics collection module in an embodiment of the present invention;

[0046] Fig. 9 is a schematic diagram of the structure of a statistics collection module in an embodiment of the present invention;

[0047] Fig.10 is an interface signal relationship diagram of a statistics collection module in an embodiment of the present invention;

[0048] Fig.11 is a schematic diagram of a state machine of a statistics collection module in an embodiment of the present invention;

[0049] Fig.12 is a schematic diagram of a multiplexer module in an embodiment of the present invention;

[0050] Fig.13 is an interface signal relationship diagram of a multiplexer module in an embodiment of the present invention;

[0051] Fig.14 is a schematic diagram of a state machine of a multiplexer module in an embodiment of the present invention;

[0052] Fig.15 is a flow chart of packet loss rate testing performed in an embodiment of the present invention;

[0053] Fig.16 is a flow chart of a throughput test performed in an embodiment of the present invention;

[0054] Fig.17 is a flow chart of delay testing performed in an embodiment of the present invention;

[0055] Fig.18 is a flow chart of a time-sensitive network test (without background flow) according to an embodiment of the present invention;

[0056] Fig.19 It is a flow chart of performing a time-sensitive network test (with background flow) according to an embodiment of the present invention. DETAILED DESCRIPTION

[0057] The present invention will be further described below in conjunction with specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and are not intended to limit the scope of the present invention. In addition, it should be understood that after reading the content taught by the present invention, those skilled in the art can make various changes or modifications to the present invention, and these equivalent forms fall within the scope limited by the appended claims of the application equally.

[0058] The embodiment of the present invention relates to a network testing system based on the Fast platform, which includes a software part and a hardware part.

[0059] The hardware part of this embodiment is a Fast pipeline, including a general packet parsing module (GPP), a general keyword extraction module (GKE), a general matching engine module (GME), a general forwarding action module (GAC) and a general output engine module (GOE) connected in sequence. In order to support the functions of message generation and data collection, a statistics collection module (SCM) and a data packet generation module (PGM) are added to the Fast pipeline respectively.

[0060] Among them, the PGM module is located between the GAC module and the GOE module, and is used to generate messages under the control of the software part and notify the relevant parameters of message sending. In order to make full use of the flexibility of the software part and the characteristics of hardware time precision and better performance, the initial message generation will be completed by the software part and sent to the PGM module through FASTAPI. The PGM module stores and controls the sending of received messages, which involves the update mode of IPD (Inter-Packet-Delay) and related HF (Header Fields), which can be realized by configuring the relevant registers of the PGM module through software.

[0061] Its principle is as follows Figure 2As shown. First, the software part will send the message to be sent (in Fast message format) to Fast UM through PCIe through the send method provided by Fast, and specify the destination mid as the PGM module in the metadata carried by the message; at the same time, the software part will also write the IPD and HF update modes of the message sent into the relevant registers of the PGM module through the reg_write method provided by Fast. According to the update mode of IPD and HF set by the software part, the PGM module generates messages at the IPD interval and modifies the relevant fields, then sends them to the GOE module and outputs them to the FPGA OS. In addition, if the sent message needs to record the timestamp (for delay testing, etc.), the software also writes the relevant registers of the UDO module to describe the protocol type of the message, thereby supporting UDO to record the sent timestamp in the message payload (but the UDO module has not yet been added to FAST).

[0062] like Figure 3 As shown, the PGM module of this embodiment includes: a message parsing unit (PGM_WR), which is used to parse the received template message and store the parsed template message in the corresponding message storage unit according to the parsing result; a first message storage unit (PGM_RAM0), a second message storage unit (PGM_RAM1) and a third message storage unit (PGM_RAM2), which are respectively used to store the template message of the first message type, the template message of the second message type and the template message of the third message type; a first message sending unit (PGM_RD0), which is used to send the template message of the first message type, the template message of the second message type and the template message of the third message type according to the preset rate. A message is read from a message storage unit, a preset field in the read message is modified according to a preset rule, and the modified message is sent; a second message sending unit (PGM_RD1) is used to read a message from a second message storage unit at a preset rate, and then modify the preset field in the read message according to the preset rule, and send the modified message; a third message sending unit (PGM_RD2) is used to read a message from a third message storage unit at a preset rate, and then modify the preset field in the read message according to the preset rule, and send the modified message.

[0063] Among them, the PGM_WR unit, PGM_RD0 unit, PGM_RD1 unit and PGM_RD2 unit are all configured with counters and registers that can be read and written by the software side. The counters and registers can be used to configure various functions and obtain test results. Each module can address the counters and registers separately. Among them, the virtual address space definition is shown in Table 1.

[0064] Table 1 Virtual address space definition table

[0065]

[0066]

[0067] The input and output signal definitions of the PGM_WR unit are shown in Table 2, the input and output signal definitions of the PGM_RD0 unit are shown in Table 3, the input and output signal definitions of the PGM_RD1 unit are shown in Table 4, and the input and output signal definitions of the PGM_RD2 unit are shown in Table 4.

[0068] Table 2 Input and output signal definition table of PGM_WR unit

[0069]

[0070]

[0071] Table 3 Input and output signal definition table of PGM_RD0 unit

[0072]

[0073]

[0074] Table 4 PGM_RD1 unit input and output signal definition table

[0075] Signal name direction width Signal Description clk input 1 Clock signal rst_n input 1 Reset signal in_rd1_valid input 1 Data valid signal from PGM_WR in_rd1_valid_wr input 1 Data valid write enable signal from PGM_WR in_rd1_alf input 1 Data back pressure signal from MUX pgm_sent_start_flag input 1 Packet start signal from PGM_WR ram1_to_rd1_rdata input 144 Message data from PGM_RAM1 cin_rd1_data input 134 Control message data from PGM_WR cin_rd1_data_wr input 1 Control message data write enable signal from PGM_WR cin_rd1_ready input 1 Ready signal from MUX timestamp2rd1 input 32 Timestamp from UM in_rd1_sent_time_reg input 64 Total test time from PGM_WR out_rd1_data ouput 128 Message data sent to GOE out_rd1_data_wr ouput 1 Message data write enable signal sent to GOE out_rd1_valid output 1 Data valid signal sent to MUX out_rd1_valid_wr output 1 Data valid write enable signal sent to MUX rd1_to_ram1_rd output 1 Message read enable signal sent to PGM_RAM1 rd1_to_ram1_addr output 1 Message read address sent to PGM_RAM1 cout_rd1_data output 134 Control message data sent to MUX cout_rd1_data_wr output 1 Control message data write enable signal sent to MUX cout_rd1_ready output 1 Ready signal to PGM_WR

[0076] Table 4 PGM_RD2 unit input and output signal definition table

[0077]

[0078]

[0079] The PGM_WR unit is used to parse the received template message and store the template message in the corresponding message storage unit according to the parsing result. Its status is as follows: Figure 4The PGM_WR unit is initially in the idle_s state. If it receives a non-test template message, it jumps to the sent_s state and performs normal forwarding operations, sending the message and metadata with pfv, and returns to the idle_s state after the execution is completed. When a test template message is received and in_wr_data[49:32]==pkt_priority0, it will jump to the store0_s state and store the received data in the PGM_RAM0 unit. When the end of the message is read, protocol_num_cnt<=protocol_num_cnt+1, and it is determined whether protocol_num_cnt>=protocol_num_reg is satisfied. If so, pgm_sent_start_flag is set and the state is jumped to the wait_s state, otherwise it jumps to the idle_s state. When a test template message is received and in_wr_data[49:32]==pkt_priority1, it will jump to the store1_s state and store the received data in the PGM_RAM1. When the end of the message is read, protocol_num_cnt<=protocol_num_cnt+1, and it is determined whether protocol_num_cnt>=protocol_num_reg is satisfied. If so, pgm_sent_start_flag is set and the state is jumped to the wait_s state, otherwise it jumps to the idle_s state. protocol_num_cnt+1, determine whether protocol_num_cnt>=protocol_num_reg is satisfied. If so, set pgm_sent_start_flag and jump to wait_s state, otherwise jump to idle_s state; and when the test template message is received and in_wr_data[49:32]==pkt_priority2, it will jump to store2_s state and store the received data in PGM_RAM2. When the end of the message is read, protocol_num_cnt<=protocol_num_cnt+1, determine whether protocol_num_cnt>=protocol_num_reg is satisfied. If so, set pgm_sent_start_flag and jump to wait_s state, otherwise jump to idle_s state. In the wait_s state, the PRM_WR unit will start timing, and when the timer reaches test_time_cnt>=test_time_reg, it will set pgm_sent_finish_flag and jump to the idle_s state, thereby notifying the PGM_RD0 unit, the PGM_RD1 unit and the PGM_RD2 unit to stop sending messages.

[0080] The PGM_RD0 unit is the core sub-unit in the PGM module. It reads packets from the PGM_RAM0 unit at a certain rate and modifies specific fields in the packets according to certain rules to achieve the function of packet sending. It is also responsible for passing non-test packets normally. Its status is as Figure 5 shown. The predetermined rate and the predetermined rules can be pre-stored in the registers configured for the PGM_RD0 unit. The PGM_RD0 unit is initially in the idle_s state. When it receives the bypass signal from the PGM_WR unit and signals such as md, pfv, and data are valid, it jumps to the sent_s state and directly forwards the packet without any processing. When it reaches the end of the packet, it jumps back to the idle_s state. When it receives the message to start packet sending, it jumps to the read0_s state and reads a complete packet from the PGM_RAM0 unit for sending. When it reaches the end of the packet, if sent_time_cnt < sent_time_reg, it jumps to the wait_s state; when sent_time_cnt >= sent_time_reg, it jumps to the fin_s state. When the PGM_RD0 unit is in the fin_s state, it will send a notification packet (toCPU) to the software side. After receiving it, the software side will read the result data from the PGM module and set the soft_reset in the PGM module, thereby triggering all registers to be cleared and returning to the idle_s state.

[0081] Compared with the PGM_RD0 unit, the PGM_RD1 unit and the PGM_RD2 unit do not undertake the task of passing non-test packets and phv. As Figure 6 and Figure 7 shown, the state changes of the PGM_RD1 unit and the PGM_RD2 unit are equivalent to the PGM_RD0 unit without the sent state, but the number of beats between two consecutive packets will fluctuate within a certain range.

[0082] The PGM_RAM0 unit, PGM_RAM1 unit and PGM_RAM2 unit in this embodiment can all use a 144*128 RAM generated by a standard IP core. The RAM can store an Ethernet message of up to 1500B, that is, the maximum message size from the CPU. When the PGM_WR unit receives the test message, it will store it in the PGM_RAM0 unit, PGM_RAM1 unit or PGM_RAM2 unit according to the type of the test message, and the PGM_RD0 unit, PGM_RD1 unit and PGM_RD2 unit will continuously read out and send the stored message. It should be noted that the rate at which the message is read from the PGM_RAM0 unit, PGM_RAM1 unit or PGM_RAM2 unit is controlled by the registers configured in the PGM_RD0 unit, PGM_RD1 unit and PGM_RD2 unit, and the registers also control how to modify the message.

[0083] The SCM module is located between the GME module and the GAC module, and is used to update the registers that record the test results. Since the network test system of this embodiment needs to support active measurement, placing the PGM module after the GAC module can avoid conflicts between the message generation function and the message collection and parsing function in the pipeline; and placing the SCM module between the GME module and the GAC module can not only use the metadata and PFV to parse the relevant domains, but also use the GME module to perform customized filtering on the required received messages.

[0084] The working principle of SCM module is as follows Figure 8 As shown. It is located between the GME module and the GAC module, and uses the metadata and PFV generated by the UDP module to record the relevant information of the received message. Specifically, first, the software part will call the reg_write method to specify the message type (specific protocol, flow, etc.) to be tested and the indicators to be recorded (number of packet losses, number of received packets, delay, etc.) for the SCM module. When the Fast pipeline receives the message, the timestamp will first be recorded in the metadata before the message header in FPGAOS, and after entering the UM pipeline, the GAC module will first parse and update the metadata and generate PFV. These contents may be used by the SCM module to count the received messages (such as the total number of TCP messages received, etc.), and write the results to the relevant counters. At the same time, the discard position in the metadata will be set to 1, so that the message is discarded in the GAC, so that the sending and receiving of packets can be completed in the pipeline at the same time. After the test is completed, the software part will obtain the value of the relevant counter in the SCM module through the reg_read method and use it to calculate the test results.

[0085] like Fig. 9 As shown, the SCM module of this embodiment includes: a receiving unit for receiving a test message; a storage unit for storing the message type, data of interest, and processing requirements required for the test; a judgment processing unit for judging the type of the test message, and parsing the test message when the type of the test message is the message type required for the test; a counting unit for counting the data of interest in the parsed message; and a marking unit for marking the message after statistics according to the processing requirements. When parsing the test message, the judgment processing unit records the timestamp in the metadata before the test message header, and then uses the metadata and PFV data message to obtain the parsing results of the relevant fields. The counting unit can update the saved test results according to the relevant statistical information. In addition, the message after statistics is marked by the marking unit to instruct the subsequent processing module to discard or send the message.

[0086] The signal interface of the SCM module matches the output signal of the original GME module to the GAC module and the input signal of the GAC module from the GME module in the FAST pipeline, thereby reducing the updating and modification of the two modules, and also conforms to the interface definition specifications between modules in the FASTUM pipeline. Fig.11 This is the interface signal relationship diagram of the SCM module, and its interface signal definitions are shown in Table 5.

[0087] Table 5 Interface signal definition table of SCM module

[0088]

[0089]

[0090] The SCM module of this embodiment includes five states, namely, IDLE_S state, SEND_S state, CNT_S state, WAIT_S state and FETCH_S state. The specific state transitions are as follows: Fig.11 Shown

[0091] a) IDLE_S state:

[0092] This state is the initial state of the SCM module. At this time, the data signal and enable signal in the SCM module are set to 0.

[0093] When the test is not started, the SCM module acts as a forwarding module and forwards the received data to the next module normally. At this time, the state jumps to the SEND_S state.

[0094] When the test starts, it jumps to the CNT_S state upon receiving the gac2scm_sent_start signal.

[0095] b)SEND_S status:

[0096] In this state, the SCM module acts as a forwarding module and forwards the received data to the next module normally.

[0097] When forwarding is completed, it jumps to the IDLE_S state.

[0098] c) CNT_S status:

[0099] In this state, the SCM module tests the statistical state. At this time, the SCM module modifies the corresponding counter according to the analysis and statistics of the received test messages. For non-test messages, they are forwarded normally and jump to the SEND_S state when forwarding.

[0100] When receiving the gac2scm_sent_end signal, jump to the WAIT_S state.

[0101] d) WAIT_S state:

[0102] This state is the waiting reception statistics termination state of the SCM module. In this state, the SCM module stops receiving test messages after n round trip times (RTT) after receiving the gac2scm_sent_end signal, that is, it times out and jumps to the FETCH_S state.

[0103] If there are still test messages within n RTTs, the test messages are still parsed and counted in the WAIT_S state, and the state is jumped to the SEND_S state for forwarding.

[0104] e)FETCH_S:

[0105] In this state, the control end can obtain the value of the counting unit of the SCM module, and when determining that a new test starts, it receives a statistic_reset signal, clears the counting unit, and jumps to the IDLE_S state.

[0106] The hardware part of this embodiment is also provided with a multiplexer module (MUX), which is located between the PGM module and the GOE module, and is used to coordinate the forwarding of three different messages rd0, rd1 and rd2 from the PGM module. Since the network test system of this embodiment needs to support the forwarding of multiple messages of multiple types, there is priority processing for the three message types. The MUX module is responsible for forwarding multiple messages from the PGM module under different circumstances to prevent message conflicts and give priority to the transmission of time-sensitive message types.

[0107] The working principle of the MUX module is as follows Fig.12As shown, it is located between the PGM module and the GOE module. It first receives the message from the PGM module, uses the priority of the message in the PGM module to determine the sending order, and then sends the message to the GOE module in sequence and outputs it to the FPGA OS. If there is a control message from the PGM module, it is directly forwarded to the GOE module to ensure the normal processing and sending of the subsequent message.

[0108] The MUX module in this embodiment includes: a message receiving unit, which is used to receive the message sent by the data packet generation module; a priority judgment module, which is used to judge the priority of the received message; and a message sending module, which is used to determine the message sending order according to the message priority and send the message according to the sending order. In essence, it is an output port aggregation module responsible for coordinating the sending of three types of messages. Fig.13 As shown in Table 6, the signal interface of the MUX module matches the output signal of the original GAC module to the GOE module in the FAST pipeline and the input signal of the GOE module from the GAC module, thereby reducing the update and modification of the two modules before and after, and also conforming to the interface definition specification between modules in the FAST UM pipeline. The interface signal definition of the MUX module is shown in Table 6.

[0109] Table 6 MUX module input and output signal definition table

[0110]

[0111]

[0112] The state machine of the MUX module contains four states: OPERATE0_S, OPERATE1_S, OPERATE2_S and IDLE_S. The specific state transitions are as follows: Fig.14 shown.

[0113] IDLE_S: The initial state of the MUX module. When no message in rd0, rd1, or rd2 is received or the received message is processed, the state jumps back to IDLE_S.

[0114] OPERATE0_S: When the MUX module receives a message from rd0 and a write enable signal, it jumps to the OPERATE0_S state to forward the message in rd0. If there are messages from rd1 and rd2 at the same time, they are directly discarded. When the end of the message is read, it jumps back to the IDLE_S state.

[0115] OPERATE1_S: When the MUX module does not receive the rd0 message but receives the write enable signal in rd1 and the rd1 message, it jumps to the OPERATE1_S state to forward the message in rd1, and jumps back to the IDLE_S state when it reads the end of the message; if the MUX module is in the OPERATE1_S state and receives the message in rd0 at this time, it will discard the current rd1 message, send the rd0 message, and switch to the OPERATE0_S state;

[0116] OPERATE2_S: When the message in rd0 and the message in rd1 are not received but the message in rd2 and the write enable signal in rd2 are received, it jumps to the OPERATE2_S state to forward the message in rd2, and jumps back to the IDLE_S state when forwarding to the end of the message; if the MUX module is in the OPERATE2_S state, and the message in rd0 is received at this time, the current rd2 message will be discarded, the rd0 message will be sent, and it will be converted to the OPERATE0_S state.

[0117] The software part of this embodiment is used to control the hardware part and configure parameters to realize the testing of multi-dimensional performance indicators in the network, including but not limited to: packet loss rate test, throughput test, latency test, time-sensitive network test (without background flow) and time-sensitive network test (with background flow).

[0118] In order to support the measurement of packet loss rate, in addition to the specific message content, the software also needs to configure parameters such as protocol type, header-field update mode, sending rate, IPD, and sending mode in the SCM module and PGM module. In addition, it is also necessary to set multiple counters for counting the total number of bits sent and received, the total number of messages, and real-time bps / pps. Finally, it is also necessary to provide a running status flag to modify the state machine of the SCM module and PGM module to meet the needs.

[0119] In order to support the measurement of throughput, in addition to the above registers and counters, it is also necessary to set counters such as the current running time and the single-round iteration time to support the measurement of throughput using the "binary method". It should be noted that timing is mainly achieved by multiplying the clock cycle counter with a single time slice (in an FPGA with a clock frequency of 125M, the size of a single time slice is about 8ns, and on an FPGA with a clock frequency of 100M, the size of a single time slice is about 10ns). It should also be noted that in the throughput test, the iteration round record and the rate adjustment using the "binary method" are implemented through the SENT sw function, thereby simplifying the hardware design.

[0120] In order to support the measurement of latency, the PGM module needs to send a latency measurement message with a timestamp in the payload every fixed number of messages. This function needs to add a register for the number of messages to be spaced, and a counter to compare whether the current number of messages in the interval has reached n, on the basis of supporting packet loss rate measurement. At the same time, it is necessary to identify the probe message in the UDP module, and modify a bit in the second beat of the metadata according to the probe message to mark the probe message. The SCM module identifies the probe message for latency measurement based on the metadata, and modifies the action field so that it is uploaded to the UA module. The UA module calculates the latency based on the timestamp in the message body.

[0121] When performing a packet loss rate test in this embodiment, the sending parameters and data collection parameters that need to be set are shown in Table 7.

[0122] Table 7 Packet loss rate test supported message sending and data collection parameters

[0123]

[0124] The overall process of packet loss rate testing is as follows: Fig.15 As shown. First, the software part configures the above sending parameters to the FPGA and initializes the registers specified by all the collection parameters. When fast_packet arrives at the pipeline, the PGM module will determine whether the from_CPU field in the metadata of the message is set. If it is set, the message will be cached in the PGM_RAM, and the message will be sent at the specified rate under the control of the relevant registers, and the relevant fields in the message header-field will be updated before each transmission. Each time a message is sent, the above 6 counters of the PGM module need to be updated.

[0125] At the same time, the software part will also inform the SCM module of the protocol type and starting sequence number of the received message to be monitored by configuring registers before the test. After receiving these configurations, the SCM module will first update the above 12 counters after receiving the specified message, and set the DISCARD position of the metadata of the received message to 1, so that the message is discarded in the UDO module to prevent the impact on the packet sending rate of the pipeline.

[0126] This implementation method is based on the packet loss rate test function when performing the throughput test, and the parameters that need to be configured are shown in Table 8.

[0127] Table 8 Configurable and return value parameters supported by throughput test

[0128]

[0129] The overall process of throughput testing is as follows: Fig.16 As shown, first, the software part configures the packet loss rate test related parameters to the hardware through FASTAPI according to the user configuration; then the initial value of the sending rate and the single-round test time are written to the PGM module; the software part sends the cached message to the PGM module through FASTAPI, and sets the test start flag to 1; when the timer in the PGM module checks that the packet sending time has reached the single-round test time, the test start flag is set to 0, the software part reads the relevant counter value, and updates the corresponding packet loss rate of the current round in the web interface, and updates the current iteration round; if the set round (N) has not been reached, the packet sending rate and related registers of the next round are updated through "binary search" to trigger a new round of testing, until the number of iterations reaches N and stops, at which time, the software part will read the relevant counter value and simultaneously return the last round of packet loss rate and the final throughput to the user through the web interface.

[0130] The delay test of this implementation can be performed after the throughput test. First, when the device under test reaches the full rate, a special message with a sending timestamp is sent at a fixed interval. When the test system receives a message with a timestamp returned from the device under test again, the timestamp is recorded again when receiving, so as to obtain the forwarding delay of the message in the device under test by comparing the difference between the two timestamps (ignoring the transmission time of the message in the copper cable). The parameters that need to be configured are shown in Table 9.

[0131] Table 9 Delay test supported configuration parameters and return parameters

[0132]

[0133] The overall process of delay testing is as follows: Fig.17 As shown, before measuring the forwarding delay of the device under test, its real throughput needs to be obtained, and then the packet can be sent at the full line rate of the device under test to measure the forwarding delay of the message in this case. First, the software part configures the FPGA according to the parameters listed in the parameter table, and at the same time, a filtering rule will be sent to the GME module (the source port number of the tag message is set to 8888 in this implementation), so that all tag messages can be received by the SCM module and the accurate delay can be calculated according to the receiving / sending timestamp.

[0134] After the above settings are completed, the software part sends the initial message to the PGM module through FASTAPI and sets the test start flag to 1. After the test starts, the timer controls the sending of a tag message (used to record the receiving / sending timestamp) at a fixed time t and records the sending time in the UDO module. When the SCM module receives the tag message, it subtracts the receiving timestamp recorded in the metadata from the sending timestamp in the message and enters it into the corresponding register. When the test is completed, the PGM module sets the test start flag to 0. At this time, the software part reads the relevant register values ​​and returns the test results to the web client.

[0135] In the time-sensitive network test (without background flow), this implementation method will send tag messages at a certain rate and a constant period. The test measures the time-sensitive network by finally obtaining indicators such as the packet loss rate, throughput rate and latency of the time-sensitive message. Before the test starts, the tag message is stored in the RAM0 of the PGM module. After the storage is completed, the test starts. After the test starts, the message is sent at a constant rate and a constant period through PGM_RD0. The time-sensitive message returns to the SCM module of FAST through the TSN network, and the parameters such as packet loss rate, throughput rate, and latency are counted. The statistical method for packet loss rate, throughput rate and latency is the same as above.

[0136] Table 10 Delay test supported configuration parameters and return parameters

[0137]

[0138] The overall process of time-sensitive network testing (without background flow) is as follows Fig.18 First, the software configures the FPGA according to the parameters listed in the parameter table (see Table 10), and sends a filtering rule to the GME module, so that all tag messages can be received by the SCM module and the accurate delay can be calculated based on the receiving / sending timestamps.

[0139] After the above settings are completed, the software part sends the time-sensitive message (tag message) template to the PGM module through FASTAPI, stores it in the PGM module, and sets the test start flag to 1. After the test starts, the timer controls the sending of a tag message (used to record the receiving / sending timestamp) at a fixed time t and records the sending time in the UDO module. When the SCM module receives the tag message, it obtains the packet loss rate, throughput rate and latency through the data recorded in the metadata, and counts them into the corresponding registers. When the test is completed, the PGM module sets the test start flag to 0. At this time, the software part reads the relevant register values ​​and returns the test results to the web client.

[0140] This embodiment sends tag messages at a certain rate during the time-sensitive network test (with background flow), and simulates the interference background flow situation with multiple rate fluctuations to perform time-sensitive network testing. The test measures the time-sensitive network by finally obtaining indicators such as packet loss rate, throughput rate and latency of the time-sensitive message. In the PGM_RAM0 of the PGM module, the tag message is stored. After the test starts, the message is sent at a constant rate and a constant period through PGM_RD0; at the same time, the sending rate of PGR_RD1 and PGM_RD2 fluctuates in a certain range, and the interference message with changing period is sent to simulate the background flow. In addition, in the MUX module, the frame preemption method is used to ensure that the tag message is sent first. The statistical method of packet loss rate, throughput rate and latency is consistent with the above.

[0141] Table 11 Delay test supported configuration parameters and return parameters

[0142]

[0143] The overall process of time-sensitive network testing (without background flow) is as follows Fig.19 First, the software configures the FPGA according to the parameters listed in the parameter table (see Table 11), and sends a filtering rule to the GME module, so that all tag messages can be received by the SCM module and the accurate delay can be calculated based on the receiving / sending timestamps.

[0144] After the above settings are completed, the software part sends the initial message template and the interference message template to the PGM module through FASTAPI, stores them in the PGM module, and sets the test start flag to 1. After the test starts, the timer controls the sending of a tag message (used to record the receiving / sending timestamp) at fixed intervals of t and records the sending time in the UDO module. At the same time, the timer controls the sending of interference messages at irregular intervals, but does not make statistics. When the SCM module receives the tag message, it obtains the packet loss rate, throughput rate and latency through the data recorded in the metadata, and counts them into the corresponding registers. When the test is completed, the PGM module sets the test start flag to 0. At this time, the software part reads the relevant register values ​​and returns the test results to the web client.

[0145] It is not difficult to find that the present invention is based on the FAST platform and makes use of the data structure, hardware register access interface function and complete or partial code of FPGA OS and UM pipeline provided by FAST at the software and hardware levels to provide network testing functions. At the same time, with the help of the programmability of the FAST platform, it supports the simultaneous generation of time-sensitive flows and other background flows, and supports the deterministic sending of time-sensitive flows and the sending of background flows with customized bandwidth characteristics. On this basis, it supports the frame deprivation mechanism of time-sensitive flows for background flows on the same port, so as to generate multiple flows concurrently without affecting the generation and testing of time-sensitive flows, so as to meet the needs of time-sensitive network scenarios.

Claims

1. A network testing system based on the Fast platform, comprising a software part and a hardware part, wherein the hardware part is a FAST pipeline, comprising a general packet parsing module, a general keyword extraction module, a general matching engine module, a general forwarding action module and a general output engine module connected in sequence, characterized in that: The hardware part also includes a data packet generation module, a statistics collection module and a multiplexer module. The data packet generation module is located between the general forwarding action module and the general output engine module, and is used to generate a message and send relevant parameters of the message under the control of the software part, and the relevant parameters include collection parameters and sending parameters; the statistics collection module is located between the general matching engine module and the general forwarding action module, and is used to update the register recording the test results; The multiplexer module is located between the data packet generation module and the universal output engine module, and is used to coordinate the forwarding of different messages from the data packet generation module; The software part sends relevant parameters to the hardware part to implement the test of multi-dimensional performance indicators in the network, and the software part sends relevant parameters to the hardware part to implement time-sensitive network testing without background flow, specifically: The software part configures the hardware part according to the parameters listed in the parameter table, and sends a filtering rule to the general matching engine module, so that all tag messages can be received by the statistics collection module and the accurate delay can be calculated based on the receiving / sending timestamps; After the setup is completed, the software sends the time-sensitive message template to the data packet generation module through FASTAPI, stores it in the data packet generation module, and sets the test start flag to 1. After the test starts, the timer controls the sending of a tag message at a fixed time t and records the sending time in the data packet generation module. When the statistics collection module receives the tag message, it obtains the packet loss rate, throughput rate and latency through the data recorded in the metadata, and enters them into the corresponding registers. When the test is completed, the data packet generation module sets the test start flag to 0. At this time, the software part reads the relevant register value to obtain the test result; The software part sends relevant parameters to the hardware part to implement a time-sensitive network test with background flow, specifically: The software part configures the hardware part according to the parameters listed in the parameter table, and sends a filtering rule to the general matching engine module, so that all tag messages can be received by the statistics collection module and the accurate delay can be calculated according to the receiving / sending timestamp; after the setting is completed, the software part sends the initial message template and the interference message template to the data packet generation module through FASTAPI, and stores them in the data packet generation module, and sets the test start flag to 1. After the test starts, the timer controls the sending of a tag message at a fixed time t and records the sending time in the data packet generation module. At the same time, the timer controls the sending of interference messages at irregular intervals, and does not make statistics; when the statistics collection module receives the tag message, it obtains the packet loss rate, throughput rate and delay through the data recorded in the metadata, and enters them into the corresponding registers; When the test is completed, the data packet generation module sets the test start flag to 0. At this time, the software part reads the relevant register value to obtain the test result.

2. The network testing system based on the Fast platform according to claim 1, characterized in that: The data packet generation module comprises: A message parsing unit, used to parse the received template message and store the parsed template message in a corresponding message storage unit according to the parsing result; The first message storage unit, the second message storage unit and the third message storage unit are used to store the template message of the first message type, the template message of the second message type and the template message of the third message type respectively; A first message sending unit, used to read a message from the first message storage unit at a preset rate, modify a preset field in the read message according to a preset rule, and send the modified message; A second message sending unit, used to read the message from the second message storage unit at a preset rate, modify the preset field in the read message according to a preset rule, and send the modified message; The third message sending unit is used to read the message from the third message storage unit at a preset rate, modify the preset field in the read message according to the preset rule, and send the modified message.

3. The network testing system based on the Fast platform according to claim 1, characterized in that: The statistics collection module includes: A receiving unit, used for receiving a test message; A storage unit is used to store the message type, data of interest and processing requirements required for the test; A judgment processing unit is used to judge the type of the test message, and when the type of the test message is the message type required for the test, parse the test message; A counting unit, used to count the data of interest in the parsed message; The marking unit is used to mark the statistically counted messages according to processing requirements.

4. The network testing system based on the Fast platform according to claim 1, characterized in that: The multiplexer module comprises: A message receiving unit, used for receiving the message sent by the data packet generating module; A priority determination module, used to determine the priority of a received message; The message sending module is used to determine the message sending order according to the message priority and send the message according to the sending order.

5. The network testing system based on the Fast platform according to claim 1, characterized in that: The software part sends relevant parameters to the hardware part to implement a packet loss rate test on the network, specifically: The software part configures the hardware part by sending parameters and initializes the registers specified by all the collection parameters; when the fast packet arrives at the pipeline, the data packet generation module will determine whether the message feature field in the metadata of the message is set. If it is set, the message will be cached, and the message will be sent at a specified rate under the control of relevant registers, and the relevant fields in the message header-field will be updated before each sending; the counter configured by the data packet generation module will be updated once each time a message is sent, and the sending parameters include protocol type, packet format, packet length, update mode, sending rate, IPD, sending mode, duration and total number of packets, and the collection parameters include real-time bps, average bps, total bits and total pkt; Before testing, the software part informs the statistics collection module of the protocol type and starting sequence number of the received message to be monitored by configuring the register; After receiving the specified message, the statistics collection module updates the configured counter and sets the DISCARD position of the metadata of the received message to 1, so that the message is discarded in the data packet generation module.

6. The network testing system based on the Fast platform according to claim 1, characterized in that: The software part sends relevant parameters to the hardware part to implement a throughput test on the network, specifically: The software part configures the packet loss rate test related parameters to the hardware part through FASTAPI according to the user configuration; the software part writes the initial value of the sending rate and the single round test time into the data packet generation module; The software part sends the message to be cached to the data packet generation module through FASTAPI and sets the test start flag to 1; When the timer in the data packet generation module checks that the packet sending time has reached the single-round test time, the test start flag is set to 0, the software part reads the relevant counter value, and updates the corresponding packet loss rate of the current round and the current iteration round; if the set round has not been reached, the packet sending rate and related registers of the next round are updated through "binary division" to trigger a new round of testing, until the number of iterations reaches the set number and stops. At this time, the software part will read the relevant counter value and return the last round of packet loss rate and final throughput to the user at the same time.

7. The network testing system based on the Fast platform according to claim 1, characterized in that: The software part sends relevant parameters to the hardware part to implement the delay test of the network, specifically: The software part configures the hardware part according to the parameters listed in the parameter table, and sends a filtering rule to the general matching engine module, so that all tag messages can be received by the statistics collection module and the accurate delay can be calculated based on the receiving / sending timestamps; After the setup is completed, the software part sends the initial message to the data packet generation module through FASTAPI and sets the test start flag to 1. After the test starts, the timer controls the sending of a tag message at a fixed time t and records the sending time in the data packet generation module. When the statistics collection module receives the tag message, it subtracts the receiving timestamp recorded in the metadata from the sending timestamp in the message and enters it into the corresponding register. After the test is completed, the data packet generation module sets the test start flag to 0. At this time, the software part reads the relevant register values ​​to obtain the test results.

Images