FPGA-based data packet parser and method

Abstract

The present application provides a FPGA-based data packet parser and a method. The parser comprises a first-level configurable packet parsing module and secondary configurable packet parsing modules which are connected in sequence. The first-level configurable packet parsing module is used for extracting a protocol field at the lowest layer of a packet, and outputting a match field, a header, a packet header vector, and a starting offset to the secondary configurable packet parsing modules; the plurality of secondary configurable packet parsing modules are connected in sequence; and the secondary configurable packet parsing modules are used for parsing the packet on the basis of a parsing action configured in a dynamic configuration message. The present application has the advantages of: adapting to the processing requirements of different protocols, reducing the interface bit width between extraction units, and reducing resource consumption; allowing a matching rule and a field set of each stage to be flexibly adjusted on the basis of requirements; supporting free combination of a plurality of parallel protocol field extraction units, greatly improving the parsing performance; and meeting different packet parsing requirements, and providing higher customization and adaptability.

Description

A data packet parser and method based on FPGA

[0001] Related applications

[0002] This application claims priority to Chinese patent application No. 2023112486931, entitled “A Packet Parser and Method Based on FPGA,” filed on September 26, 2023, which is hereby incorporated by reference. Technical Field

[0003] The present application relates to the field of network data packet processing, and specifically to an FPGA-based data packet parser and method. Background Art

[0004] In modern network communications, a large number of data packets need to be processed and forwarded by network devices. Packet parsing is a key function in network devices. It involves identifying and extracting key information from packets, such as protocol type, source address, and destination address, to facilitate forwarding and processing. Traditional packet parsing solutions are often based on fixed hardware logic or software implementations, which have certain limitations in performance and flexibility.

[0005] With the rapid development of network communications and the continuous emergence of new protocols, traditional parsing technology solutions can no longer meet the growing demand for data processing. Traditional parsing technology solutions have the following shortcomings:

[0006] 1. Insufficient scalability and flexibility: Traditional packet parsing solutions usually use hard-coded rules to match various fields of a packet. This approach requires writing a large number of rules when processing packets of different protocols and formats, and lacks scalability and flexibility.

[0007] 2. Low parsing efficiency: Traditional data packet parsing solutions usually use a linear scanning method to match rules field by field. This method will cause large performance overhead when processing large-scale data packets and low parsing efficiency.

[0008] 3. Insufficient reliability: Traditional data packet parsing solutions are usually based on text matching methods such as regular expressions. This method is prone to mismatches and missed matches when processing complex data packets, resulting in inaccurate parsing results.

[0009] 4. Poor maintainability: Traditional packet parsing solutions usually require embedding rules into the code. This approach requires modifying the code and recompiling and deploying it when the rules change, making maintenance more complicated.

[0010] Summary of the Invention

[0011] The purpose of this application is to overcome the shortcomings of existing data packet parsers, such as insufficient scalability and flexibility, and low parsing efficiency.

[0012] In order to achieve the above-mentioned purpose, the present application proposes a data packet parser based on FPGA, which comprises a first-level configurable packet parsing module and a secondary-level configurable packet parsing module connected in sequence; wherein,

[0013] The first-level configurable packet parsing module is used to extract the protocol fields at the bottom layer of the message and output the matching domain, header, packet header vector and starting offset to the secondary-level configurable packet parsing module;

[0014] Several of the secondary configurable packet parsing modules are connected in sequence; the secondary configurable packet parsing modules are used to parse the message according to the parsing action configured in the dynamic configuration message.

[0015] As an improvement to the above-mentioned parser, when the protocol contained in the message is of fixed length, one of the secondary configurable packet parsing modules parses one protocol; when the protocol contained in the message is of variable length, the parsing of the protocol is divided into multiple stages, one of the secondary configurable packet parsing modules parses part of the fields in the protocol, and multiple of the secondary configurable packet parsing modules work in sequence to complete the parsing of the entire protocol.

[0016] As an improvement to the above-mentioned parser, when multiple secondary configurable packet parsing modules parse the protocol in sequence, the most critical field in the protocol is parsed first, and then other fields in the protocol are processed; the most critical field is a part of the set field in the protocol. If the set field is not matched when being processed, there is no need to continue processing other fields of the protocol.

[0017] As an improvement of the above parser, the secondary configurable packet parsing module includes a TCAM-RAM unit, a matching domain extraction unit, an offset calculation unit and a message segmentation processing unit; wherein,

[0018] The TCAM-RAM unit is a storage unit that combines TCAM and RAM and is used to match and store rules of the secondary configurable packet parsing module;

[0019] The matching domain extraction unit is used to extract the matching domain of the next layer protocol;

[0020] The offset calculation unit is used to calculate the starting offset of the next layer protocol in the message;

[0021] The message segmentation processing unit is used to segment the message in a prescribed manner, extract different fields of the message, and then merge them into the final parsing result.

[0022] As an improvement of the above-mentioned parser, the first-level configurable packet parsing module includes the matching domain extraction unit, the offset calculation unit and the message segmentation processing unit.

[0023] As an improvement to the above parser, the matching domain extraction unit, the offset calculation unit and the message segmentation processing unit process data in parallel.

[0024] As an improvement of the above parser, the message segmentation processing unit includes a message segmentation subunit, several field extraction subunits and a field combination subunit, wherein:

[0025] The message segmentation subunit is used to segment the message in a prescribed manner and output the segmented message to the field extraction subunit;

[0026] The field extraction subunit is used to extract different fields of the message and output the extraction results to the field combination subunit;

[0027] The field combination subunit is used to combine the output results of each of the field extraction subunits to obtain a final parsing result.

[0028] As an improvement to the above-mentioned parser, the message segmentation subunit evenly divides the header into multiple Cell units, and outputs a single Cell unit or a combination of multiple Cell units to the field extraction subunit according to the needs of the field extraction subunit; several of the field extraction subunits process data in parallel.

[0029] As an improvement to the above-mentioned parser, the parser configures the table entries in the TCAM-RAM unit through FlowMod messages, and dynamically configures different protocol parsing rules.

[0030] The present application also provides an FPGA-based data packet parsing method, which is implemented based on the above-mentioned parser, and the method includes:

[0031] The first-level configurable packet parsing module extracts the lowest-level protocol fields of the message and provides matching domains, headers, packet header vectors and starting offsets for subsequent protocol parsing;

[0032] The plurality of secondary configurable packet parsing modules parse the message in sequence according to the parsing actions configured in the dynamic configuration message.

[0033] Compared with the existing technology, the advantages of this application are:

[0034] 1. Flexible data packet segmentation: Through protocol field segmentation extraction, data packets can be segmented according to predefined rules. This not only adapts to the processing requirements of different protocols, but also reduces the interface width between extraction units and reduces resource consumption.

[0035] 2. Dynamic Configuration and Adaptability: The packet parsing unit can be dynamically configured based on different configuration messages. This flexibility enables the packet parsing unit to adapt to different parsing requirements and protocol changes, improving the adaptability and scalability of the system.

[0036] 3. Efficient Phased Matching: A hierarchical approach to matching multiple protocol fields allows for phased matching and progressive execution, targeting specific sets of fields. This phased matching improves matching efficiency and allows for flexible adjustment of matching rules and field sets for each phase based on demand.

[0037] 4. Parallel parsing capability: supports the free combination of multiple parallel protocol field extraction units, greatly improving parsing performance.

[0038] 5. Dynamic Protocol Field Length Configuration: The protocol field length is determined based on the output header vector type, allowing the protocol field length to be dynamically configured based on the header vector type. This flexibility meets diverse packet parsing requirements and provides greater customization and adaptability. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 shows the structure of the configurable packet parsing module;

[0040] Figure 2 shows the structure of the first-level configurable packet parsing module;

[0041] FIG3 shows a flow chart of a data packet parsing method;

[0042] FIG4 is a schematic diagram showing a process of a data packet analysis method;

[0043] FIG5 is a schematic diagram showing a dynamic configuration parsing rule. DETAILED DESCRIPTION

[0044] As a configurable hardware platform, FPGAs offer flexibility and parallel processing capabilities, enabling customized hardware logic and algorithms. By offloading packet parsing to the FPGA, its highly parallel nature can be fully utilized to improve parsing performance and throughput. FPGAs are also programmable and can be dynamically configured and updated based on different protocol requirements, supporting the parsing and processing of new protocols and making network equipment more adaptable and scalable.

[0045] FPGA-based packet parser designs also offer the advantages of flexibility and customizability. Due to the programmability of FPGAs, they can be customized and optimized based on specific application and protocol requirements. Not only can they adapt to different protocol types and message formats, but parsing algorithms and logic can also be flexibly adjusted to provide more efficient and accurate parsing capabilities.

[0046] Therefore, designing an FPGA-based packet parsing method is crucial for achieving high-performance, high-flexibility, and programmable network packet processing. It can meet the ever-changing needs of network communications, support the parsing and processing of new protocols, and provide customized parsing capabilities, providing an important technical foundation for the development and innovation of network equipment.

[0047] This application addresses the problems existing in the current pipeline architecture packet parsing technology, such as poor static configuration flexibility and large interface bit width between parsing units. It proposes an FPGA-based data packet parser and method. The parser and parsing method make packet parsing flexible, efficient and configurable by adopting key technologies such as dynamic configuration, protocol segmentation and parallel processing, so as to be applied to high-speed network data packet processing scenarios.

[0048] The FPGA-based data packet parser provided in this application includes a first-level configurable packet parsing module and several configurable packet parsing modules.

[0049] The technical solution of this application is described in detail below with reference to the accompanying drawings.

[0050] As shown in Figure 1, the configurable packet parsing module includes a TCAM-RAM unit (Ternary Content Addressable Memory-Random Access Memory), a matching domain extraction unit, an offset calculation unit, a message segmentation unit, a field extraction unit, a field combination unit, and a delay unit.

[0051] In Figure 1, Header represents the header; PHV (Packet Header Vector) represents the packet header vector; starting offset represents the starting offset; Delay represents the delay module; key represents the matching domain; Mask represents the mask; Action represents the action information; Pro len represents the protocol length information; Extra info represents the field extraction information; key field represents the matching domain information; calculate offset represents the offset calculation unit; Extract from header represents extracting the field from the header; select key from header represents extracting the matching domain from the header; Gen key represents the matching domain extraction unit; split represents the message segmentation unit; cell_A, cell_B, cell_C, and cell_D represent the field extraction units; Accumulate represents the field combination unit; Offset represents the offset; length represents the length; Con_type represents the container type; and Con_index represents the container index.

[0052] The TCAM-RAM unit is a storage unit that combines TCAM and RAM. TCAM is used for high-speed packet matching operations, while RAM is used to store and access data. The TCAM-RAM unit is used to match and store rules for the packet parsing module.

[0053] The matching domain extraction unit is used to extract the matching domain of the next layer protocol.

[0054] The offset calculation unit is used to calculate the starting offset of the next layer protocol in the message.

[0055] The message segmentation unit is used to segment the message in a prescribed manner and output the segmented message to the field extraction unit.

[0056] The field extraction unit is used to extract different fields from the message header and output the extraction results to the field combination unit. The field extraction unit contains a narrow-width cross bar, which completes the field extraction work.

[0057] The field combination unit is used to merge the output results of each field extraction unit to obtain the final parsing result.

[0058] The delay unit is used to delay the input header, packet header vector and starting offset to ensure that the output result after searching with the matching domain signal is aligned and input to the subsequent module.

[0059] As shown in Figure 2, the first-level configurable packet parsing module is similar to the configurable packet parsing module. The difference is that since the input does not have a matching domain, starting offset, and packet header vector, the first-level configurable packet parsing module does not have a TCAM match and lacks a TCAM-RAM module in structure.

[0060] As shown in Figures 3 and 4, a method for parsing data packets using an FPGA-based packet parser is used to extract the required fields from high-speed network data packets for subsequent search and forwarding operations, including configuring parsing actions through dynamic configuration messages. The configuration message can contain information such as protocol field extraction rules, protocol type location, and protocol length. The dynamic configuration message will be parsed and written into the corresponding table entry in the TCAM-RAM unit to update the parsing logic. After caching the original message header, the input data stream extracts the Ethernet layer protocol type in the header through the first-level configurable packet parsing module. Next, the configurable packet parsing unit parses the remaining protocols of the data packet layer by layer. Finally, these key fields are combined into a packet header vector output.

[0061] In Figure 4, Extract_header represents the message cache module; header represents the header; Eth_parser represents the first-level configurable packet parsing module; PHV (Packet Header Vector) represents the packet header vector; starting offset represents the starting offset; Key represents the matching domain; TCAM-RAM (Ternary Content Addressable Memory-Random Access Memory) represents content address addressable memory-random access memory; Insert / Delete flowrule represents the insertion / deletion of FlowMod messages; Action_data represents action information; Action unit represents action unit; Parser_unit represents the configurable packet parsing module.

[0062] The method for parsing data packets using an FPGA-based data packet parser specifically includes:

[0063] First, the input data stream is cached and the required header length is extracted. Next, the first-level configurable packet parsing module extracts the protocol fields at the bottom layer of the message to provide basic information for subsequent parsing. The basic information includes the protocol fields and the starting offset of the subsequent configurable packet parsing module. Then, the configurable packet parsing module cooperates with multiple parallel processing units through the TCAM-RAM unit to independently and parallelly process various parts of the message and perform corresponding actions based on the matching results, such as extracting the protocol type and key fields. Multiple parallel processing units specifically refer to three parts of parallel processing. The first part is the offset calculation unit, the second part consists of the message segmentation unit, the field extraction unit and the field combination unit, and the third part is the matching domain extraction unit.

[0064] In the second parallel processing unit, the message segmentation unit divides the input message into fixed segments based on the protocol header information, allowing each field extraction unit to process only a portion of the message, achieving parallel processing. The field extraction units remain independent and do not interact with each other. After all field extraction units complete parsing, the field combination unit merges the results of each field extraction unit to obtain the final parsing result.

[0065] As shown in Figure 5, the packet parser of the present application has a dynamic configuration feature. By sending FlowMod (a message used to dynamically configure the table entries of the TCAM-RAM unit) messages to the table entries of the TCAM-RAM unit, the table entries in the TCAM-RAM unit are configured, enabling the packet parser to flexibly adapt to different protocols and service requirements.

[0066] In Figure 5, Packet represents a message; Extract_header represents a message buffer module; header represents a packet header; and Configuration represents dynamic configuration information, namely, the FlowMod message sent to the TCAM-RAM in each configurable packet parsing module.

[0067] The following is a detailed explanation of the packet parsing process using the Ethernet protocol as the underlying protocol:

[0068] The parsing method includes a message cache stage and several configurable packet parsing stages. First, the message cache module is used to extract the required header length from the cache. Then, the first-level configurable packet parsing module is used to parse the Ethernet layer protocol type. The subsequent configurable packet parsing modules at each level first perform TCAM-RAM matching (the field value to be matched is stored in the table entry of the TCAM-RAM, and the matching domain is compared in parallel with the field value in the TCAM. If a match is found in the TCAM match, the corresponding information stored in the RAM will be output according to the result of the match). If a match is found, parallel processing operations such as the protocol field extraction unit, the matching domain extraction unit, and the offset calculation unit are executed. The message segmentation unit segments the message and assigns it to the corresponding field extraction unit for processing to extract the protocol field. The matching domain extraction unit extracts the next layer protocol matching domain, and the offset calculation module calculates the corresponding offset. If a match miss occurs (a match miss means that no match is found during the TCAM-RAM match in the current configurable packet parsing stage. This does not mean that there is a problem with the packet itself, but rather that the matching rules in the current stage are not applicable to the packet. Data packets in the network can contain multiple protocol layers, each with its own header information and fields that need to be parsed. Even if no appropriate rules are matched in the current stage, it is still necessary to continue parsing subsequent protocol layers to ensure that all protocol headers and fields of the entire packet are fully parsed), the system directly enters the next level of configurable packet parsing and continues processing the next level of configurable packet parsing tasks.

[0069] The message buffer internally includes a data path and control logic. The control logic progressively parses the header according to predefined rules and stores the parsing results in internal registers. The control logic ensures data accuracy and integrity through state transitions and data transfer control. It determines whether the end of the header has been reached and asserts an output signal at the appropriate time to indicate that the header has been completely extracted. The control logic also handles errors caused by premature termination of header extraction.

[0070] The segmented protocol field extraction method (i.e., multiple field extraction units operate in parallel, extracting different fields from the message header) segments the input message header according to predefined rules and assigns the header to the corresponding extraction unit for processing. As an example, assuming the input header has a bit width of 1024 bits, according to one embodiment, the header can be evenly segmented into four Cell units: Cell_A, Cell_B, Cell_C, and Cell_D. The bit width of each cell corresponds to a different part of the header. For example, Cell_A represents the lower 256 bits of the header, Cell_B represents bits 256 to 511 of the header, Cell_C represents bits 512 to 767 of the header, and Cell_D represents bits 768 to 1023 of the header. In actual applications, the Cell units within each parsing layer can have different combinations. For example, when configuring protocol parsing at the first layer, only Cell_A or a combination of Cell_A and Cell_B may be required to extract the required protocol fields. The specific combination to use depends on the actual data packets to be parsed and the hardware resources occupied by each layer of parsing. Therefore, during design, it is necessary to determine the optimal combination based on specific needs and hardware resource limitations.

[0071] For fixed-length protocols, a single configurable packet parsing module can complete the parsing of a protocol. For variable-length protocols, multiple configurable packet parsing modules can be used to perform parsing using a phased matching approach. The protocol fields of the data packet are matched sequentially through multiple phases to achieve phased protocol processing. The phased matching approach is a matching strategy for complex protocols such as variable-length protocols. Taking the IPv4 protocol as an example, using the phased matching approach, the protocol type is first matched to see if it is IPv4, and then key fields such as the header length are further matched. This design can reduce unnecessary table resource consumption, improve parsing efficiency, and ensure that the corresponding processing logic is only executed for packets that meet the conditions.

[0072] The phased matching method specifically involves: First, in the first phase, protocol type matching is performed based on the protocol type field of the packet. If a match is successful, meaning the packet belongs to the target protocol type, the process proceeds to the next phase. Otherwise, the default processing logic can be executed or the packet can be passed to the next layer (the "next layer" refers to the next protocol layer in the protocol stack. In network communications, packets enter the protocol stack from the network interface layer, the lowest layer, and then pass through different protocol layers for processing and parsing until they reach the application layer. The next layer is the upper protocol layer in the protocol stack, determined by the specific protocol stack structure and design. Here, this refers to passing the packet to a higher-layer protocol for processing). Next, in the second phase, packets of specific protocol types are matched based on other protocol fields. These fields can be various protocol-related attributes, such as header length, protocol field length, and optional options. For each field, a corresponding table entry can be designed to store the field value and corresponding processing logic. If all protocol fields match successfully, meaning all conditions are met, the corresponding processing logic is executed. Otherwise, the default processing logic can be executed or the packet can be passed to the next layer for processing. By using a phased matching approach, the overall matching task can be broken down into multiple stages, first matching the most critical fields, and then further matching based on the results. This approach effectively reduces the number of table entries and storage overhead, while providing flexibility to adapt to the parsing needs of different protocols and field combinations. For example, when processing the IPv4 protocol, the protocol type is first matched as IPv4, and then key fields such as the header length are further matched, thus reducing unnecessary matching operations.

[0073] During protocol parsing, certain fields may be more important, allowing for more accurate determination of the protocol type or packet structure. Therefore, matching these key fields first can significantly improve parsing efficiency. By matching the most critical fields first, a preliminary judgment can be made quickly to determine the protocol type or structure that the packet may belong to. If the most critical fields are matched successfully, meaning the packet meets the expected protocol type or structure, the next stage can be entered for further matching operations. In subsequent stages, based on the matching results and the values ​​of other fields, the protocol length or other properties can be further refined for more accurate processing and parsing.

[0074] The dynamic protocol field length configuration method (dynamic protocol field length configuration method refers to configuring table entries within the TCAM-RAM unit through FlowMod messages. In the table entries within the TCAM-RAM unit, the protocol field length is indicated by the packet header vector type. For example, as shown in Figure 1, a Con_type of 0 represents a protocol field length of 1B, a Con_type of 1 represents a protocol field length of 2B, and a Con_type of 2 represents a protocol field length of 4B. Different protocol field lengths are represented by dynamically configuring the Con_type value through FlowMod messages) allows the protocol field length to be dynamically configured based on the packet header vector type. This dynamic configuration allows the protocol field length to flexibly adapt to different types of packet header vectors. For example, if the output packet header vectors have three types: 1B, 2B, and 4B, a 2-bit width can be used to represent the protocol field length configuration. In this way, only 2 bits are required in the RAM storing the protocol field length to represent the protocol field length corresponding to different packet header vector types. If the protocol field length of a particular packet header vector exceeds the maximum bit width (for example, exceeding 4B), a concatenation method using multiple sets of extraction rules can be used. By combining multiple extraction rules in a predetermined order, we can extract and process very long protocol fields. This approach is highly scalable, capable of handling protocol fields of varying lengths and flexibly adapting to changes in different header vector types.

[0075] The design steps of the FPGA-based packet parser are as follows:

[0076] S01: Determine the protocol set supported by the parser, divide the protocol layers, and add layers for tasks with multiple protocol field matching.

[0077] S02: Design the parsing unit level according to the hierarchical structure. Each level of the tree is a parsing level. Determine the number of levels of parsing units.

[0078] S03: Determine the bit width of the interface and packet header vector, and design the header segmentation method according to the characteristics of each layer protocol, as well as the free combination of Cell units inside the configurable packet parsing module.

[0079] S04: Design the table entry content of the TCAM-RAM unit according to the protocol field bit width and protocol format, including the matching rules of the protocol field, the matching bit width and the action of the matching result.

[0080] S05: Design a field extraction unit inside the configurable packet parsing module to extract the corresponding protocol field based on the data packet part after the header is segmented, and pass it to the subsequent processing unit.

[0081] S06: Design parallel processing units inside the configurable packet parsing module, such as Cell_A, Cell_B, Cell_C, and Cell_D, and allocate different data packet parts to corresponding field extraction units for processing according to the designed packet header vector.

[0082] S07: Design the control logic between configurable packet parsing modules to ensure the independence and collaborative work of the configurable packet parsing modules, including data transmission, result merging, etc.

[0083] S08: Configuring the table entries and parameters inside the configurable packet parsing module, including protocol field rules, table entry contents of the TCAM-RAM unit, configuration of the packet header vector, etc.

[0084] S09: Perform synthesis, placement and routing, and timing analysis to optimize the performance and resource usage of the configurable packet parsing module.

[0085] S10: Perform simulation and verification to verify whether the functions and performance of the configurable packet parsing module meet the requirements.

[0086] S11: Integrate the configurable packet parsing module into the entire data packet parser and perform system-level verification and testing.

[0087] S12: Perform performance tuning and optimization based on actual application scenarios to meet the requirements of high-speed network packet processing.

[0088] Finally, it should be noted that the above embodiments are intended only to illustrate the technical solutions of this application and are not intended to limit the scope of the present invention. Although this application has been described in detail with reference to the embodiments, it should be understood by those skilled in the art that modifications or equivalent substitutions to the technical solutions of this application do not depart from the spirit and scope of the technical solutions of this application and should be encompassed by the claims of this application.

Claims

1. A data packet parser based on FPGA, characterized in that: The parser includes a first-level configurable packet parsing module and a secondary-level configurable packet parsing module connected in sequence; wherein, The first-level configurable packet parsing module is used to extract the bottom-level protocol fields of the message and output the matching domain, header, packet header vector and starting offset to the secondary-level configurable packet parsing module; A plurality of the secondary configurable packet parsing modules are connected in sequence; the secondary configurable packet parsing modules are used to parse the message according to the parsing action configured by the dynamic configuration message.

2. The FPGA-based data packet parser according to claim 1, characterized in that: When the protocol contained in the message is of fixed length, one of the secondary configurable packet parsing modules parses one protocol; when the protocol contained in the message is of variable length, the parsing of the protocol is divided into multiple stages, one of the secondary configurable packet parsing modules parses part of the fields in the protocol, and multiple of the secondary configurable packet parsing modules work in sequence to complete the parsing of the entire protocol.

3. The FPGA-based data packet parser according to claim 2, characterized in that: When multiple secondary configurable packet parsing modules parse the protocol in sequence, the most critical field in the protocol is parsed first, and then other fields in the protocol are processed; the most critical field is a part of the set field in the protocol. If the set field is not matched when being processed, there is no need to continue processing other fields of the protocol.

4. The FPGA-based data packet parser according to claim 1, characterized in that: The secondary configurable packet parsing module includes a TCAM-RAM unit, a matching domain extraction unit, an offset calculation unit and a message segmentation processing unit; wherein, The TCAM-RAM unit is a storage unit that combines TCAM and RAM and is used to match and store rules of the secondary configurable packet parsing module; The matching domain extraction unit is used to extract the matching domain of the next layer protocol; The offset calculation unit is used to calculate the starting offset of the next layer protocol in the message; The message segmentation processing unit is used to segment the message in a prescribed manner, extract different fields of the message, and then merge them into a final parsing result.

5. The FPGA-based data packet parser according to claim 4, characterized in that: The first-level configurable packet parsing module includes the matching domain extraction unit, the offset calculation unit and the message segmentation processing unit.

6. The FPGA-based data packet parser according to claim 4, characterized in that: The matching domain extraction unit, the offset calculation unit and the message segmentation processing unit process data in parallel.

7. The FPGA-based data packet parser according to claim 5 or 6, characterized in that: The message segmentation processing unit includes a message segmentation subunit, a plurality of field extraction subunits and a field combination subunit, wherein: The message segmentation subunit is used to segment the message in a specified manner and output the segmented message to the field extraction subunit; The field extraction subunit is used to extract different fields of the message and output the extraction results to the field combination subunit; The field combination subunit is used to merge the output results of each of the field extraction subunits to obtain a final parsing result.

8. The FPGA-based data packet parser according to claim 7, characterized in that: The message segmentation subunit evenly divides the header into multiple Cell units, and outputs a single Cell unit or a combination of multiple Cell units to the field extraction subunit according to the needs of the field extraction subunit; several of the field extraction subunits process data in parallel.

9. The FPGA-based data packet parser according to claim 4, characterized in that: The parser configures the table entries in the TCAM-RAM unit through FlowMod messages, and dynamically configures different protocol parsing rules.

10. A data packet parsing method based on FPGA, implemented based on any parser described in claims 1-9, characterized in that: The method comprises: The first-level configurable packet parsing module extracts the lowest-level protocol fields of the message and provides matching domains, headers, packet header vectors and starting offsets for subsequent protocol parsing; The plurality of secondary configurable packet parsing modules parse the message in sequence according to the parsing actions configured in the dynamic configuration message.

Images