FPGA-based dhcp server offloading method and device

Abstract

The application relates to a DHCP server offloading method and device based on FPGA, which comprises the following steps: screening a UDP message from an original Ethernet message, screening a DHCP request message from the UDP message; performing protocol processing on the DHCP request message according to a state machine corresponding to a DHCP protocol to obtain a message processing result; generating a corresponding DHCP response message and encapsulating the DHCP response message into an application layer message according to the message processing result; adding a transport layer UDP header, a network layer IP header and a data link layer Ethernet header on the application layer message layer by layer to form a complete Ethernet response message and send the Ethernet response message externally.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a DHCP server unloading method and apparatus based on FPGA. Background Technology

[0002] As the core technology for dynamic IP address allocation in networks, the DHCP protocol's software implementation needs to be adapted to applications across all scenarios, from embedded devices to large servers. Therefore, a comprehensive trade-off must be made between functionality, stability, security, and performance. Currently, most mainstream DHCP protocol processing schemes rely on the CPU to implement the process in software. This approach, with its good compatibility and flexibility, is widely used in low-to-medium traffic scenarios.

[0003] However, software implementation of the DHCP protocol has many inherent drawbacks: First, the system call process consumes hundreds of CPU clock cycles, resulting in significant processing overhead; second, the CPU cycle consumption of memory copy operations is proportional to the amount of data, which can easily exhaust CPU resources in high-speed network scenarios of 10 Gigabit and above, and increase data transmission latency; third, each DHCP packet triggers a hardware interrupt, causing the CPU to frequently perform context switching, interrupting the execution of the original task; in addition, the complex protocol processing logic and lock contention issues further exacerbate performance degradation.

[0004] The aforementioned issues directly lead to excessively high latency in the software-implemented DHCP protocol. At the same time, limited CPU resources, buffer overflows, queue management congestion, and inefficient packet processing result in low throughput, making it unable to meet the application requirements of high-traffic scenarios above 10Gbps. This has become a key bottleneck restricting network expansion and transmission performance improvement. Summary of the Invention

[0005] To address the issue of excessive latency in existing software-implemented DHCP protocols, coupled with factors such as limited CPU resources, buffer overflows, queue management congestion, and inefficient packet processing, which further result in low throughput and fail to meet the application requirements of high-traffic scenarios exceeding 10Gbps, this has become a key bottleneck restricting network expansion and transmission performance improvement. This application provides an FPGA-based DHCP server offloading method, apparatus, electronic device, and storage medium. The specific technical solution is as follows: In a first aspect of this application, a DHCP server offloading method based on FPGA is provided, the method comprising: Filter UDP packets from the raw Ethernet packets, and then filter DHCP request packets from the UDP packets; According to the state machine corresponding to the DHCP protocol, the DHCP request message is processed to obtain the message processing result; Based on the message processing result, a corresponding DHCP response message is generated and encapsulated into an application layer message; Based on the application layer message, a transport layer UDP header, a network layer IP header, and a data link layer Ethernet header are added layer by layer to form a complete Ethernet response message and send it outward.

[0006] In an optional implementation, the step of filtering UDP packets from the raw Ethernet packets includes: Extract the source host MAC address information from the data link layer and the triplet from the network layer of the original Ethernet packet according to the DHCP protocol; Based on the triplet, determine whether the original Ethernet packet is a UDP candidate packet; If the original Ethernet packet is a UDP candidate packet, store the source host MAC address information; By removing the data link layer and the network layer, UDP packets at the transport layer and above are obtained.

[0007] In an optional implementation, the step of filtering DHCP request messages from the UDP messages includes: Extract the source port and destination port from the transport layer of the UDP packet; If the source port is a preset first port and the destination port is a preset second port, the UDP packet will be identified as a DHCP request packet.

[0008] In one optional implementation, the state machine includes a system initial state, a decision state, and multiple processing states; The step of processing the DHCP request message according to the state machine corresponding to the DHCP protocol to obtain the message processing result includes: In the initial state of the system, the DHCP request message is received, and the state machine transitions to the decision state; In the decision state, the request instruction carried in the DHCP request message is parsed, and the state machine jumps to the corresponding processing state according to the type of the request instruction; In the processing state, protocol processing is performed to obtain the message processing result.

[0009] In an optional implementation, the processing status includes a discovery query status; In the processing state, protocol processing is performed to obtain message processing results, including: In the discovery query state, a client identifier is generated based on the source host MAC address information; The client identifier is hashed to obtain the hash bucket address, and the first client identifier under the hash bucket address is searched in the first hash bucket; If the first client identifier under the hash bucket address is empty, the state machine jumps to the state of discovering a new table entry; If the first client identifier under the hash bucket address is the same as the client identifier, the hash bucket address will be used as the information bucket query address. If the first client identifier under the hash bucket address is different from the client identifier, search for multiple second client identifiers under the hash bucket address from the first overflow bucket; If multiple second client identifiers do not match the client identifier, the state machine jumps to the state of discovering a new table entry; If the target client identifier matches the client identifier, extract the information bucket index corresponding to the target client identifier in the first overflow bucket, and use the information bucket index as the information bucket query address; Wherein, the target client identifier is any one of a plurality of second client identifiers; Search the first information bucket for the IP address and lease information under the query address of the information bucket; If the IP address is empty or the lease information indicates that the lease has expired, the state machine transitions to the state of discovering a new entry. If the IP address is not empty and the lease information indicates that the lease has not expired, the state machine transitions to the framing state.

[0010] In an optional implementation, the method further includes: When a new table entry is discovered, the client identifier is hashed to obtain the hash bucket address, and the hash bucket address is searched in the first hash bucket. If the hash bucket address is empty, the client identifier is written into the hash bucket address in the first hash bucket, and the hash bucket address is used as the information bucket writing address; If a historical client identifier has already been written to the hash bucket address, write the client identifier to the hash bucket address in the first overflow bucket; Add a new information bucket index for the client identifier, write the new information bucket index into the first overflow bucket, and use the new information bucket index as the information bucket write address; Write the pre-allocated table entry information to the information bucket write address in the first information bucket, and the state machine jumps to the providing frame state.

[0011] In an optional implementation, the method further includes: In the framing state, if a new IP address is assigned to the client that provides the source host's MAC address information, the newly assigned IP address and lease information are written to the application layer, and the state machine transitions to the waiting-to-send state. If the client with the source host MAC address information has been assigned an IP address and the lease information indicates that the lease has not expired, the assigned IP address and lease information are written to the application layer, and the state machine transitions to the state of providing a wait-to-send state. If the client with the source host MAC address information has been assigned an IP address and the lease information indicates that the lease has expired, or there are no more IP addresses available for assignment in the IP pool, a DHCP-NAK message is sent, and the state machine transitions to the initial system state. While in a state of waiting to send, the system listens for a sendable instruction. If a sendable instruction is detected, the system executes the instruction, and the state machine transitions to the initial state of the system.

[0012] In an optional implementation, the processing state includes a selection query state; In the processing state, protocol processing is performed to obtain message processing results, including: In the selected query state, a client identifier is generated based on the source host MAC address information; The client identifier is hashed to obtain the hash bucket address, and the first client identifier under the hash bucket address is searched in the first hash bucket; If the first client identifier under the hash bucket address is empty, the state machine jumps to the system initial state; If the first client identifier under the hash bucket address is the same as the client identifier, the hash bucket address will be used as the information bucket query address. If the first client identifier under the hash bucket address is different from the client identifier, search for multiple second client identifiers under the hash bucket address from the first overflow bucket; If multiple second client identifiers do not match the client identifier, the state machine jumps to the system initial state; If the target client identifier matches the client identifier, extract the information bucket index corresponding to the target client identifier in the first overflow bucket, and use the information bucket index as the information bucket query address; Wherein, the target client identifier is any one of a plurality of second client identifiers; Search the first information bucket for the IP address and lease information under the query address of the information bucket; If the IP and lease information are empty, the state machine jumps to the system initial state; If the IP matches an assigned IP, the state machine transitions to the select relay state.

[0013] In an optional implementation, the method further includes: In the selected relay state, after waiting for several FPGA cycles, the state machine jumps to the ACK packet state; In the ACK packet state, when querying the routing table, if the route is found to be unreachable, a DHCP-NAK message is returned, and the state machine jumps to the system initial state; If the route is displayed as reachable and an ICMP PING message for that IP is sent and a response is received, then a DHCP-NAK message is returned and the state machine transitions to the initial system state. If the route is reachable and no response is received after sending an ICMP PING message for that IP address, a DHCP-ACK message is returned, and the state machine transitions to the ACK response confirmation state. In the ACK response confirmation state, it confirms whether the DHCP-ACK message was sent correctly, and the state machine jumps to the system initial state.

[0014] In a second aspect of this application, an FPGA-based DHCP server offloading device is also provided, the device comprising: The message filtering module is used to filter UDP messages from raw Ethernet messages, and to filter DHCP request messages from the UDP messages. The message processing module is used to process the DHCP request message according to the state machine corresponding to the DHCP protocol and obtain the message processing result. The message generation module is used to generate a corresponding DHCP response message and encapsulate it into an application layer message based on the message processing result. The message sending module is used to add transport layer UDP header, network layer IP header and data link layer Ethernet header layer by layer on the application layer message to form a complete Ethernet response message and send it outward.

[0015] In a third aspect of the embodiments of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When the processor executes a program stored in memory, it implements the FPGA-based DHCP server offloading method described in any of the first aspects above.

[0016] In a fourth aspect of the embodiments of this application, a storage medium is also provided, the storage medium storing instructions that, when run on a computer, cause the computer to execute any of the FPGA-based DHCP server unloading methods described in the first aspect above.

[0017] In a fifth aspect of the embodiments of this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the above-described FPGA-based DHCP server unloading methods.

[0018] The technical solution provided in this application embodiment filters UDP packets from the original Ethernet packets, filters DHCP request packets from the UDP packets, performs protocol processing on the DHCP request packets according to the state machine corresponding to the DHCP protocol, obtains the packet processing result, generates the corresponding DHCP response packet according to the packet processing result and encapsulates it into an application layer packet, and adds a transport layer UDP header, a network layer IP header and a data link layer Ethernet header layer by layer on the application layer packet to form a complete Ethernet response packet and send it outward.

[0019] By offloading the entire DHCP server process through FPGA hardware, the FPGA replaces the CPU to complete the hierarchical filtering of DHCP messages, protocol state machine processing, and layer-by-layer packet assembly and sending of response messages. This completely eliminates the inherent overhead of system calls, memory copying, interrupts and context switching in software implementation, effectively reducing the processing latency of the DHCP protocol, significantly improving message throughput, and freeing up CPU core resources, enabling the DHCP server to efficiently adapt to high-traffic network scenarios of 10Gbps and above. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0023] Figure 1 This is a schematic diagram of an FPGA-based DHCP server offloading framework shown in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the implementation process of an FPGA-based DHCP server offloading method in an embodiment of this application. Figure 3 This is a schematic diagram illustrating the transitions between states of a state machine in an embodiment of this application; Figure 4 This is a schematic diagram illustrating a hash query in an embodiment of this application; Figure 5 This is a schematic diagram illustrating a hash write operation in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an FPGA-based DHCP server offloading device shown in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0026] like Figure 1 The diagram shown is a schematic of an FPGA-based DHCP server offloading framework provided in this application embodiment. It employs a multi-stage pipelined scheme for DHCP protocol messages. During data flow in, out, and processing, clock domain conversion, five-tuple filtering, UDP extraction, DHCP server-side message splitting with other messages, MAC and IP information lookup, information caching, UDP packet assembly for responses, queue management, and clock domain conversion for transmission are performed sequentially. The framework as a whole adopts a pipelined design to fully utilize network throughput. The core modules incorporate state machines and parallel processing techniques. Furthermore, a hash algorithm with collision detection is used in the IP allocation and lease renewal processes to effectively reduce overall latency.

[0027] The framework comprises the following functional modules: receive preprocessing, UDP processing, DHCP server, MAC pool storage, IP pool storage, UDP packet assembly, queue management, send preprocessing, and other message processing modules. The main functions of each module are described in detail below.

[0028] Based on the above, such as Figure 2 The diagram shown illustrates the implementation flow of a DHCP server offloading method based on FPGA according to an embodiment of this application. This method is applied to an FPGA and specifically includes the following steps: S201 filters UDP packets from raw Ethernet packets and then filters DHCP request packets from UDP packets.

[0029] In this embodiment, the receiving preprocessing module is responsible for FPGA clock domain conversion (to determine the receiving frequency of the message) and filtering UDP packets from the original Ethernet packets. Specifically, it extracts the source host MAC address information from the data link layer and the triplet from the network layer of the original Ethernet packet according to the DHCP protocol. Based on the triplet, it determines whether the original Ethernet packet is a UDP candidate packet. If the original Ethernet packet is a UDP candidate packet, it stores the source host MAC address information, removes the data link layer and network layer, and obtains UDP packets at the transport layer and above.

[0030] For example, the source host MAC address information from the data link layer and the triple (source IP address, destination IP address, and protocol number) from the network layer are extracted according to the DHCP protocol. The triple is then used to filter and select the UDP candidate packets needed by the current host. At the same time, the data link layer and network layer are removed from the original packet, and the remaining data above the transport layer is reassembled and concatenated into a UDP packet and passed to the subsequent module.

[0031] The UDP processing module is responsible for filtering DHCP request messages from UDP packets. This involves parsing transport layer information, extracting the source and destination ports, and performing secondary filtering based on these ports to select messages that need to be sent to the DHCP server. Unnecessary messages are then routed to other message processing modules.

[0032] Specifically, when the source port is a preset first port and the destination port is a preset second port, the UDP packet is identified as a DHCP request packet. For example, the DHCP protocol stipulates that the DHCP server uses UDP port 67 as the destination port to listen for requests, and the DHCP client uses UDP port 68 as the source port to send requests. Therefore, when the source port is UDP port 68 and the destination port is UDP port 67, the UDP packet is identified as a DHCP request packet and sent to the DHCP server; otherwise, unnecessary packets are diverted to other packet processing modules.

[0033] S202, according to the state machine corresponding to the DHCP protocol, perform protocol processing on the DHCP request message to obtain the message processing result.

[0034] In this embodiment of the application, the DHCP server is the core functional module of this framework, responsible for processing DHCP request messages sent by DHCP clients and returning corresponding response messages based on the processing and query results.

[0035] In this regard, based on the low-latency requirements of the core functions of the DHCP server, a state machine corresponding to the DHCP protocol was configured, such as... Figure 3 As shown, the state machine has, but is not limited to, 17 states, of which 10 states have fast callback interfaces designed to ensure that the machine can quickly return to the initial state in any abnormal situation.

[0036] Based on this, the DHCP server is responsible for processing DHCP request messages according to the state machine corresponding to the DHCP protocol, and obtaining the message processing result. The state machine includes the system initial state, the decision state, and multiple processing states.

[0037] In the initial state of the system (e.g., as Figure 3 In state 0 (as shown), all processing logic is in a stopped state, only listening for DHCP request messages from the preceding module. Upon receiving a DHCP request message, it immediately jumps to the decision state (e.g., ...). Figure 3 In state 5, the message type is determined.

[0038] In the decision state, the system determines what request command is carried in the message sent by the DHCP client. Specifically, it parses the request command carried in the DHCP request message and, based on the type of request command, the state machine jumps to the corresponding processing state. In the processing state, protocol processing is performed to obtain the message processing result.

[0039] For example, upon receiving a DHCP-DISCOVER command, the state machine transitions to state 1; upon receiving a SELECTING command from a client's DHCP-REQUEST, the state machine transitions to state 6; upon receiving a RENEW command from a client's DHCP-REQUEST, the state machine transitions to state 10; upon receiving an INIT-REBOOT command from a client on the same subnet, the state machine transitions to state 13; and upon receiving an INIT-REBOOT command from a client on a different subnet, the state machine transitions to state 15.

[0040] One of the processing states is the discovery query state (e.g., ... Figure 3As shown in state 1 (DISCOVER query state), the DHCP server processes the DHCP-DISCOVER request packet sent by the DHCP client, selects the MAC address extracted by the receiving preprocessing module as the client ID of the source host, and queries the client information in the MAC pool storage module based on the client ID.

[0041] Among them, such as Figure 4 As shown, the query algorithm uses a fast hash algorithm based on CRC16, and the algorithm sets up hash buckets, overflow buckets, and information buckets. The hash bucket uses the CRC16 calculation result as the address index and stores a single client ID; the overflow bucket stores multiple client IDs after CRC16 collisions and their corresponding indexes in the information bucket; the information bucket stores the client IP and lease information entries.

[0042] Specifically, based on the source host MAC address information, a client identifier is generated; the client identifier is hashed to obtain the hash bucket address, and the first client identifier under the hash bucket address is searched in the first hash bucket; if the first client identifier under the hash bucket address is empty, the state machine jumps to the state of discovering a new table entry (e.g., ...). Figure 3 (State 2 shown) If the first client identifier under the hash bucket address is the same as the client identifier, the hash bucket address is used as the information bucket query address; if the first client identifier under the hash bucket address is different from the client identifier, multiple second client identifiers under the hash bucket address are searched from the first overflow bucket; if multiple second client identifiers do not match the client identifier, the state machine jumps to the state of discovering a new table entry; if the target client identifier matches the client identifier, the information bucket index corresponding to the target client identifier is extracted from the first overflow bucket, and the information bucket index is used as the information bucket query address; where the target client identifier is any of the multiple second client identifiers; the IP and lease information under the information bucket query address are searched in the first information bucket; if the IP is empty or the lease information indicates that the lease has expired, the state machine jumps to the state of discovering a new table entry; if the IP is not empty and the lease information indicates that the lease has not expired, the state machine jumps to the state of providing framing (e.g., as shown in the previous text). Figure 3 State 3 is shown.

[0043] For example, in state 1: DISCOVER query state, the query and state transition process is as follows: (1) After obtaining the MAC address transmitted by the receiving preprocessing module, generate a client id corresponding to the MAC address with a length of 6 bytes, and input the client id into the CRC16 calculation module to generate a hash bucket address with a length of 2 bytes.

[0044] (2) Search for the cache information of the corresponding address in the hash bucket: If the cache information under the address is empty, the cache miss is not found and the state machine jumps to state 2; If the cached client id under the address is exactly the same as the input client id, the cache hit is found and there is no collision. Extract the hash bucket address as the information bucket query address and proceed to step (4); If the cached client id under the address is different from the input client id, the cache hit is found but there is a collision, and proceed to step (3).

[0045] (3) Query the cached information with the same address in the overflow bucket: If multiple client IDs in the overflow bucket do not match, the state machine jumps to state 2; if there is a matching client ID in the overflow bucket, the information bucket index cached in the overflow bucket is extracted as the information bucket query address, and step (4) is entered.

[0046] (4) Query the IP and lease information entries in the information bucket: If the IP is empty or the lease has expired, the state machine jumps to state 2; if the IP is not empty and the lease has not expired, the machine jumps to state 3.

[0047] (5) Query ends.

[0048] Upon discovering a new table entry, the client identifier is hashed to obtain a hash bucket address, and the hash bucket address is searched in the first hash bucket. If the hash bucket address is empty, the client identifier is written to the hash bucket address in the first hash bucket, and the hash bucket address is used as the information bucket write address. If the hash bucket address has already been written with a historical client identifier, the client identifier is written to the hash bucket address in the first overflow bucket. An information bucket index is added to the client identifier (e.g., by sequential encoding to obtain the information bucket index), the new information bucket index is written to the first overflow bucket, and the new information bucket index is used as the information bucket write address. The pre-allocated table entry information is written to the information bucket write address in the first information bucket, and the state machine transitions to the providing frame state.

[0049] For example, state 2: DISCOVER creates a new table entry, responsible for generating a table entry related to the client ID. Figure 5 As shown, a fast hash algorithm based on CRC16 is used for the new write operation. The specific new operation process is as follows: (1) Input the client ID into the CRC16 calculation module to generate a 2-byte hash bucket address; (2) Search for the address in the hash bucket: If the address is empty, there is no collision. Write the client ID to the hash bucket and write the pre-allocated table entry information to the information bucket using the hash bucket address as the address; if the address has already been written with the client ID, there is a collision. Write the client ID to the overflow bucket using the hash bucket address as the address, and write the newly added information bucket index to the overflow bucket as well. At the same time, write the pre-allocated table entry information to the information bucket using the newly added information bucket index as the address; (3) While writing data, the state machine jumps to state 3.

[0050] In the framing state, if a new IP address is assigned to the client with the source host's MAC address information, the newly assigned IP address and lease information are written to the application layer, and the state machine transitions to the "Waiting to Send" state. If the client with the source host's MAC address information has already been assigned an IP address and the lease information indicates that the lease has not expired, the assigned IP address and lease information are written to the application layer, and the state machine transitions to the "Waiting to Send" state. If the client with the source host's MAC address information has already been assigned an IP address and the lease information indicates that the lease has expired, or there are no more assignable IP addresses in the IP pool, a DHCP-NAK message is sent, and the state machine transitions to the system initial state. In the "Waiting to Send" state, the system listens for sendable commands, and if a sendable command is detected, it executes the sendable command, and the state machine transitions to the system initial state.

[0051] For example, in state 3: OFFER framing state, the corresponding network packet application layer data is assembled according to the IP allocation. If the client has been assigned an IP and the lease has expired, or there are no more IPs to allocate in the IP pool, then the server sends a DHCP-NAK message, and the state machine jumps back to state 0; if a new IP is assigned, then the IP and lease information are written into the network packet application layer, and the state machine jumps to state 4.

[0052] State 4: OFFER (Waiting to send) state. In this state, the system listens for sendable commands from the UDP packet assembly module.

[0053] In addition, one processing state is the selection query state (e.g., ... Figure 3 As shown in state 6 (SELECTING query state), this state is responsible for handling the IP usage request returned by the client and performing corresponding query and processing operations.

[0054] Therefore, in the query state, a client identifier is generated based on the source host MAC address information; the client identifier is hashed to obtain a hash bucket address, and the first client identifier under the hash bucket address is searched in the first hash bucket; if the first client identifier under the hash bucket address is empty, the state machine jumps to the system initial state; if the first client identifier under the hash bucket address is the same as the client identifier, the hash bucket address is used as the information bucket query address; if the first client identifier under the hash bucket address is different from the client identifier, multiple second client identifiers under the hash bucket address are searched from the first overflow bucket; if multiple second client identifiers do not match the client identifier, the state machine jumps to the system initial state; if the target client identifier matches the client identifier, the information bucket index corresponding to the target client identifier is extracted from the first overflow bucket, and the information bucket index is used as the information bucket query address; where the target client identifier is any one of the multiple second client identifiers; the IP and lease information under the information bucket query address are searched in the first information bucket; if the IP and lease information are empty, the state machine jumps to the system initial state; if the IP matches the assigned IP, the state machine jumps to the transit selection state.

[0055] For example, state 6: SELECTING query state. This state is responsible for handling the IP usage request returned by the client and performing corresponding query and processing operations. The specific processing flow is as follows: (1) After obtaining the MAC address transmitted by the receiving preprocessing module, generate a client id corresponding to the MAC address with a length of 6 bytes, and input the client id into the CRC16 calculation module to generate a hash bucket address with a length of 2 bytes.

[0056] (2) Search for the cache information of the corresponding address in the hash bucket: If the cache information under the address is empty, the cache miss is not found and the state machine jumps to state 0; If the cached client id under the address is exactly the same as the input client id, the cache hit is found and there is no collision. Extract the hash bucket address as the information bucket query address and proceed to step (4); If the cached client id under the address is different from the input client id, the cache hit is found but there is a collision and proceed to step (3).

[0057] (3) Query the cached information with the same address in the overflow bucket: If multiple client IDs in the overflow bucket do not match, the state machine jumps to state 0: If there is a matching client ID in the overflow bucket, extract the information bucket index cached in the overflow bucket as the information bucket query address, and proceed to step (4).

[0058] (4) Query the IP and lease information entries in the information bucket: If the pre-allocated entry is empty, the state machine jumps to state 0; if the pre-allocated entry matches, it jumps to state 7.

[0059] In the selected relay state, after waiting for several FPGA cycles, the state machine transitions to the ACK packet state. In the ACK packet state, when querying the routing table (using the source IP and destination IP to check if the route exists), if the route is unreachable, a DHCP-NAK message is returned, and the state machine transitions to the system initial state. If the route is reachable and an ICMP PING message about the IP is sent and an acknowledgment is received, a DHCP-NAK message is returned, and the state machine transitions to the system initial state. If the route is reachable and an ICMP PING message about the IP is sent but no acknowledgment is received, a DHCP-ACK message is returned, and the state machine transitions to the ACK acknowledgment state. In the ACK acknowledgment state, the DHCP-ACK message is checked to confirm that it was sent correctly, and the state machine transitions to the system initial state.

[0060] For example, state 7: SELECTING relay state. This state is the front-end relay state of ACK packet assembly. It takes 1 FPGA cycle to copy the relevant registers and listen for jump instructions of multiple states. After 1 FPGA cycle, it directly jumps to state 8.

[0061] State 8: ACK packet state. After the DHCP client's client ID matches the IP address in the pre-assignment table, the DHCP server sends an ACK packet to the DHCP client in response, notifying the client that the assigned IP address can be used and returning a new lease. Simultaneously, the assigned IP address and lease information are written to the MAC pool and IP pool for future reference; the specific writing operation is similar to state 2. However, before responding, several pieces of information need to be considered: When querying the routing table, if the route is unreachable, a DHCP-NAK message is returned and the state machine transitions to state 0; if the route is reachable and an ICMP PING message about the IP is sent and an acknowledgment is received, a DHCP-NAK message is returned and the state machine transitions to state 0; if the route is reachable and an ICMP PING message about the IP is sent but no acknowledgment is received, a DHCP-ACK message is returned and the state machine transitions to state 9.

[0062] State 9: ACK response confirmation state. The DHCP-ACK response message is quite important. Therefore, this application embodiment specifically sets state 9 to confirm whether the response message has been sent correctly and to ensure that the state machine jumps back to state 0 in a timely manner.

[0063] In addition, one processing state is a lease renewal indication state (e.g., ... Figure 3State 10 (RENEW indicator state) is shown. This state caches the DHCP client's client ID and source IP and issues a query command. The state machine then transitions to the lease renewal query state (e.g., as shown in the image). Figure 3 The status shown is 11, RENEW query status.

[0064] For example, state 10: RENEW indicator state, which is responsible for handling the RENEW request from the client's DHCP-REQUEST. Upon receiving the request, it immediately caches the client ID and source IP, issues a query command, and the state machine jumps to state 11.

[0065] During the lease renewal query state, the MAC pool and IP pool entries are queried in parallel. After the query is completed, the system transitions to the lease renewal verification state (e.g., ...). Figure 3 (State 12 shown, RENEW verification state). The MAC pool query process is as follows: Hash the client identifier to obtain the hash bucket address, and search for the first client identifier under the hash bucket address in the first hash bucket; if the first client identifier under the hash bucket address is empty, return a null value; if the first client identifier under the hash bucket address is the same as the client identifier, use the hash bucket address as the information bucket query address; if the first client identifier under the hash bucket address is different from the client identifier, search for multiple second client identifiers under the hash bucket address in the first overflow bucket; if none of the multiple second client identifiers match the client identifier, return a null value; if the target client identifier matches the client identifier, extract the information bucket index corresponding to the target client identifier in the first overflow bucket, and use the information bucket index as the information bucket query address; where the target client identifier is any one of the multiple second client identifiers; search for the IP and lease information under the information bucket query address in the first information bucket.

[0066] The IP pool query process is as follows: The source IP is hashed to obtain another hash bucket address, and the first IP under the aforementioned hash bucket address is searched in the second hash bucket. If the first IP is empty, a null value is returned. If the first IP is the same as the source IP, the other hash bucket address is used as the query address for another information bucket. If the first IP is different from the source IP, multiple second IPs under the other hash bucket address are searched in the second overflow bucket. If none of the multiple second IPs match the source IP, a null value is returned. If the target IP matches the source IP, the index of the other information bucket corresponding to the target IP is extracted from the second overflow bucket, and the index of the other information bucket is used as the query address for another information bucket. The target IP is any of the multiple second IPs. The lease information of the target IP under the query address is searched in the second information bucket.

[0067] For example, in state 11: RENEW query state, the MAC pool and IP pool entries are queried in parallel. After the query is completed, the system transitions to state 12. The MAC pool query process is as follows: (1) Obtain the client ID cached in state 10, input the client ID into the CRC16 calculation module, and generate a hash bucket address with a length of 2 bytes.

[0068] (2) Search for the cache information of the corresponding address in the hash bucket: If the cache information under the address is empty, the cache is not hit and an empty value is returned; if the client id cached under the address is exactly the same as the input client id, the cache is hit and there is no collision, extract the hash bucket address as the information bucket query address, return the query value, and proceed to step (4); if the client id cached under the address is different from the input client id, the cache is hit but there is a collision, and proceed to step (3).

[0069] (3) Query the cached information with the same address in the overflow bucket: If multiple client IDs in the overflow bucket do not match, return an empty value; if there is a matching client ID in the overflow bucket, extract the information bucket index cached in the overflow bucket as the information bucket query address, return the query value, and proceed to step (4).

[0070] (4) Query the IP and lease information entries in the information bucket and cache the query results.

[0071] (5) Query ends.

[0072] The IP pool query process is as follows: (1) Obtain the source IP of the state 10 cache and input the IP into the CRC16 calculation module to generate a hash bucket address with a length of 2 bytes.

[0073] (2) Search for the cache information of the corresponding address in the hash bucket: If the cache information under the address is empty, the cache is not hit and an empty value is returned; if the IP cached under the address is exactly the same as the input IP, the cache is hit and there is no collision, extract the hash bucket address as the information bucket query address, return the query value, and proceed to step (4); if the IP cached under the address is different from the input IP, the cache is hit but there is a collision, and proceed to step (3).

[0074] (3) Query the cached information with the same address in the overflow bucket: If multiple IPs in the overflow bucket do not match, return an empty value; if there is a matching IP in the overflow bucket, extract the information bucket index in the overflow bucket as the information bucket query address, return the query value, and proceed to step (4).

[0075] (4) Go to the lease information table entry of the IP in the information bucket and cache the query results.

[0076] (5) Query ends.

[0077] State 12: RENEW verification state. This state is responsible for verifying the multiple query results returned in state 11 and cached, and making corresponding decisions. The specific decision rules are as follows: If the MAC pool returns an empty value, no action is taken, and the state machine returns directly to state 0. If the MAC pool returns a valid query value, but the IP pool returns an empty value, no action is taken, and the state machine returns directly to state 0. If both the MAC pool and the IP pool return valid query values, but their cached values ​​are inconsistent, no action is taken, and the state machine returns directly to state 0. If both the MAC pool and the IP pool return valid query values, and their cached values ​​are consistent, the process transitions to state 7, preparing to extend the lease for the client.

[0078] In addition, one processing state is the initialization restart state (e.g., ... Figure 3 State 13 (INIT-REBOOT query state) is shown. In this state, the system receives the INIT-REBOOT command from the client's DHCP-REQUEST and performs parallel queries of the MAC pool and IP pool entries. The state machine then transitions to state 14. The specific process is as follows: (1) Parse and cache the client ID and IP information in the INIT-REBOOT command packet; (2) Input the client id and IP into the CRC16 calculation module to generate a 2-byte hash bucket address; (3) Perform MAC pool query and IP pool query respectively. For details, refer to the MAC pool query and IP pool query in state 12 above. Query the client ID, IP and lease information in the MAC information bucket, and query the client ID and lease information in the IP information bucket. (4) Return the query results for the MAC pool and IP pool.

[0079] Status 14: INIT-REBOOT verification status. This status is responsible for verifying whether the query results from status 13 match the expected results. The specific verification rules are as follows: If the client ID returned by the MAC pool does not match the cached value, no action is taken, and the state machine returns directly to state 0. If the client ID returned by the MAC pool matches the cached value, but the IP does not match, or if the client ID returned by the IP pool does not match the cached value, the state machine transitions to state 15. If the return values ​​from both the MAC pool and the IP pool match the cached value and are consistent, the machine transitions to state 7, preparing to extend the lease for the client.

[0080] State 15: INIT-REBOOT response state. In this state, the system will decide whether to send a DHCP-NAK response message or a DHCP-ACK response message based on the available information. The specific decision rules are as follows: If the subnet verification fails (meaning the DHCP client and DHCP server are not on the same subnet), a DHCP-NAK reply message is sent, and the state machine transitions to state 0. If the subnet verification passes, but an abnormal instruction is detected in the preceding state, a DHCP-NAK reply message is sent, and the state machine transitions to state 0. If the subnet verification passes, there is no abnormal instruction in the preceding state, and an ACK reply request is received, a DHCP-ACK reply message is sent, and the state machine transitions to state 16.

[0081] State 16: INIT-REBOOT Response Confirmation State. This state is used to confirm whether the DHCP-ACK response message under the INIT-REBOOT request has been sent correctly and to ensure that the state machine jumps back to state 0 in a timely manner.

[0082] S203: Based on the message processing result, generate the corresponding DHCP response message and encapsulate it into an application layer message.

[0083] S204 adds a transport layer UDP header, a network layer IP header, and a data link layer Ethernet header to the application layer message, forming a complete Ethernet response message and sending it outward.

[0084] In this embodiment, the UDP packet assembly module is responsible for processing the packet assembly instructions transmitted by the DHCP server module. Based on the message processing results returned by the state machine, it generates corresponding DHCP response messages (for example, according to different instruction response requirements, the UDP packet assembly module can generate DHCP-OFFER response packets, DHCP-ACK confirmation packets, and DHCP-NAK rejection packets) and encapsulates them into application layer messages. On the basis of the application layer messages, it adds transport layer UDP headers, network layer IP headers, and data link layer Ethernet headers layer by layer to form a complete Ethernet response message and sends it to the queue management module.

[0085] Meanwhile, the UDP packet assembly module generates status signals upon receiving a packet assembly command and after sending a message, which are used to instruct the DHCP server module's state machine to correctly transition and recover.

[0086] The queue management module uses a strict priority algorithm to coordinate the messages sent by each module. Messages that arrive first are sent first, and messages that arrive later wait for the previous message to be sent before entering the sending queue. Messages that arrive at the same time are also subject to weight arbitration, and messages with higher configured weights are sent first.

[0087] The preprocessing module is responsible for FPGA clock domain conversion (used to determine the message transmission frequency), adding the synchronization header and FCS check bit required for MAC transmission, and converting the final output data into a standard Ethernet data stream.

[0088] This multi-level pipeline framework, which segments network packets step by step and extracts key information, facilitates an increase in the overall system operating frequency. The use of FPGA state machines and parallel processing enables rapid processing of DHCP messages, achieving nanosecond-level responses. The adoption of a hash algorithm with collision detection to control writing and querying significantly reduces the time for DHCP server IP allocation and lease renewal, achieving ultra-low latency offloading. Ten of the 17 states in the state machine have interfaces for directly jumping back to the initial state, allowing for rapid recovery within one cycle in abnormal situations.

[0089] Corresponding to the above method embodiments, this application also provides an FPGA-based DHCP server offloading device, such as... Figure 6 As shown, the device may include: a message filtering module 610, a message processing module 620, a message generation module 630, and a message sending module 640.

[0090] The message filtering module 610 is used to filter UDP messages from raw Ethernet messages and to filter DHCP request messages from the UDP messages. The message processing module 620 is used to process the DHCP request message according to the state machine corresponding to the DHCP protocol and obtain the message processing result. The message generation module 630 is used to generate a corresponding DHCP response message and encapsulate it into an application layer message based on the message processing result. The message sending module 640 is used to add a transport layer UDP header, a network layer IP header, and a data link layer Ethernet header layer by layer to the application layer message to form a complete Ethernet response message and send it outward.

[0091] This application also provides an electronic device, such as... Figure 7 As shown, it includes a processor 71, a communication interface 72, a memory 73, and a communication bus 74. The processor 71, the communication interface 72, and the memory 73 communicate with each other through the communication bus 74. Memory 73 is used to store computer programs; When processor 71 executes the program stored in memory 73, it performs the following steps: UDP packets are filtered from the original Ethernet packets, and DHCP request packets are then filtered from the UDP packets. The DHCP request packets are processed according to the state machine corresponding to the DHCP protocol to obtain the packet processing result. Based on the packet processing result, a corresponding DHCP response packet is generated and encapsulated as an application layer packet. A transport layer UDP header, a network layer IP header, and a data link layer Ethernet header are added layer by layer to the application layer packet to form a complete Ethernet response packet, which is then sent outwards.

[0092] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0093] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0094] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0095] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0096] In another embodiment provided in this application, a storage medium is also provided, which stores instructions that, when run on a computer, cause the computer to execute any of the FPGA-based DHCP server unloading methods described in the above embodiments.

[0097] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the FPGA-based DHCP server unloading methods described in the above embodiments.

[0098] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a storage medium or transmitted from one storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0099] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0100] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0101] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A DHCP server unloading method based on FPGA, characterized in that, The method includes: Filter UDP packets from the raw Ethernet packets, and then filter DHCP request packets from the UDP packets; According to the state machine corresponding to the DHCP protocol, the DHCP request message is processed to obtain the message processing result; Based on the message processing result, a corresponding DHCP response message is generated and encapsulated into an application layer message; Based on the application layer message, a transport layer UDP header, a network layer IP header, and a data link layer Ethernet header are added layer by layer to form a complete Ethernet response message and send it outward.

2. The method according to claim 1, characterized in that, The step of filtering UDP packets from raw Ethernet packets includes: Extract the source host MAC address information from the data link layer and the triplet from the network layer of the original Ethernet packet according to the DHCP protocol; Based on the triplet, determine whether the original Ethernet packet is a UDP candidate packet; If the original Ethernet packet is a UDP candidate packet, store the source host MAC address information; By removing the data link layer and the network layer, UDP packets at the transport layer and above are obtained.

3. The method according to claim 1, characterized in that, The step of filtering DHCP request messages from the UDP messages includes: Extract the source port and destination port from the transport layer of the UDP packet; If the source port is a preset first port and the destination port is a preset second port, the UDP packet will be identified as a DHCP request packet.

4. The method according to claim 2, characterized in that, The state machine includes the system initial state, the decision state, and multiple processing states; The step of processing the DHCP request message according to the state machine corresponding to the DHCP protocol to obtain the message processing result includes: In the initial state of the system, the DHCP request message is received, and the state machine transitions to the decision state; In the decision state, the request instruction carried in the DHCP request message is parsed, and the state machine jumps to the corresponding processing state according to the type of the request instruction; In the processing state, protocol processing is performed to obtain the message processing result.

5. The method according to claim 4, characterized in that, The processing status includes the discovery query status; In the processing state, protocol processing is performed to obtain message processing results, including: In the discovery query state, a client identifier is generated based on the source host MAC address information; The client identifier is hashed to obtain the hash bucket address, and the first client identifier under the hash bucket address is searched in the first hash bucket; If the first client identifier under the hash bucket address is empty, the state machine jumps to the state of discovering a new table entry; If the first client identifier under the hash bucket address is the same as the client identifier, the hash bucket address will be used as the information bucket query address. If the first client identifier under the hash bucket address is different from the client identifier, search for multiple second client identifiers under the hash bucket address from the first overflow bucket; If multiple second client identifiers do not match the client identifier, the state machine jumps to the state of discovering a new table entry; If the target client identifier matches the client identifier, extract the information bucket index corresponding to the target client identifier in the first overflow bucket, and use the information bucket index as the information bucket query address; Wherein, the target client identifier is any one of a plurality of second client identifiers; Search the first information bucket for the IP address and lease information under the query address of the information bucket; If the IP address is empty or the lease information indicates that the lease has expired, the state machine transitions to the state of discovering a new entry. If the IP address is not empty and the lease information indicates that the lease has not expired, the state machine transitions to the framing state.

6. The method according to claim 5, characterized in that, The method further includes: When a new table entry is discovered, the client identifier is hashed to obtain the hash bucket address, and the hash bucket address is searched in the first hash bucket. If the hash bucket address is empty, the client identifier is written into the hash bucket address in the first hash bucket, and the hash bucket address is used as the information bucket writing address; If a historical client identifier has already been written to the hash bucket address, write the client identifier to the hash bucket address in the first overflow bucket; Add a new information bucket index for the client identifier, write the new information bucket index into the first overflow bucket, and use the new information bucket index as the information bucket write address; Write the pre-allocated table entry information to the information bucket write address in the first information bucket, and the state machine jumps to the providing frame state.

7. The method according to claim 5 or 6, characterized in that, The method further includes: In the framing state, if a new IP address is assigned to the client that provides the source host's MAC address information, the newly assigned IP address and lease information are written to the application layer, and the state machine transitions to the waiting-to-send state. If the client with the source host MAC address information has been assigned an IP address and the lease information indicates that the lease has not expired, the assigned IP address and lease information are written to the application layer, and the state machine transitions to the state of providing a wait-to-send state. If the client with the source host MAC address information has been assigned an IP address and the lease information indicates that the lease has expired, or there are no more IP addresses available for assignment in the IP pool, a DHCP-NAK message is sent, and the state machine transitions to the initial system state. While in a state of waiting to send, the system listens for a sendable instruction. If a sendable instruction is detected, the system executes the instruction, and the state machine transitions to the initial state of the system.

8. The method according to claim 4, characterized in that, The processing status includes the query selection status; In the processing state, protocol processing is performed to obtain message processing results, including: In the selected query state, a client identifier is generated based on the source host MAC address information; The client identifier is hashed to obtain the hash bucket address, and the first client identifier under the hash bucket address is searched in the first hash bucket; If the first client identifier under the hash bucket address is empty, the state machine jumps to the system initial state; If the first client identifier under the hash bucket address is the same as the client identifier, the hash bucket address will be used as the information bucket query address. If the first client identifier under the hash bucket address is different from the client identifier, search for multiple second client identifiers under the hash bucket address from the first overflow bucket; If multiple second client identifiers do not match the client identifier, the state machine jumps to the system initial state; If the target client identifier matches the client identifier, extract the information bucket index corresponding to the target client identifier in the first overflow bucket, and use the information bucket index as the information bucket query address; Wherein, the target client identifier is any one of a plurality of second client identifiers; Search the first information bucket for the IP address and lease information under the query address of the information bucket; If the IP and lease information are empty, the state machine jumps to the system initial state; If the IP matches an assigned IP, the state machine transitions to the select relay state.

9. The method according to claim 8, characterized in that, The method further includes: In the selected relay state, after waiting for several FPGA cycles, the state machine jumps to the ACK packet state; In the ACK packet state, when querying the routing table, if the route is found to be unreachable, a DHCP-NAK message is returned, and the state machine jumps to the system initial state; If the route is displayed as reachable and an ICMP PING message for that IP is sent and a response is received, then a DHCP-NAK message is returned and the state machine transitions to the initial system state. If the route is reachable and no response is received after sending an ICMP PING message for that IP address, a DHCP-ACK message is returned, and the state machine transitions to the ACK response confirmation state. In the ACK response confirmation state, it confirms whether the DHCP-ACK message was sent correctly, and the state machine jumps to the system initial state.

10. A DHCP server offloading device based on FPGA, characterized in that, The device includes: The message filtering module is used to filter UDP messages from raw Ethernet messages, and to filter DHCP request messages from the UDP messages. The message processing module is used to process the DHCP request message according to the state machine corresponding to the DHCP protocol and obtain the message processing result. The message generation module is used to generate a corresponding DHCP response message and encapsulate it into an application layer message based on the message processing result. The message sending module is used to add transport layer UDP header, network layer IP header and data link layer Ethernet header layer by layer on the application layer message to form a complete Ethernet response message and send it outward.

Images