A method for improving edge network element data forwarding efficiency

Abstract

This application relates to a method for improving the efficiency of edge network data forwarding. It involves deploying kernel protocol stack forwarding instances and DPDK forwarding instances in parallel on edge network elements to handle encrypted data streams and high-speed forwarding data streams respectively, forming a redundant resource pool. An independent state detection module monitors instance performance metrics in real time. The state machine is adjusted based on monitoring data-driven strategies; a mode switch is triggered when a link failure is detected, and configuration adjustments are performed when performance degrades. Before adjustment, forwarding rules are backed up using Redis, and rules are dynamically injected using netlink messages to establish xfrm strategies. Three strategy types are supported: mode switching, configuration adjustment, and fault rollback. Finally, performance data is fed back to a machine learning module, and strategy thresholds are dynamically optimized through regression analysis and gradient descent algorithms.

Description

Technical Field

[0001] This application relates to the field of information transmission technology, specifically to a method for improving the efficiency of edge network metadata forwarding. Background Technology

[0002] In the current context of network digitization, edge network elements, as key devices in these networks, undertake the important tasks of data forwarding, processing, and storage. Their data forwarding efficiency, security, and stability directly affect the overall operation of the large network, leading to increasingly stringent requirements for edge network data forwarding. Existing data forwarding technologies mainly rely on the following two methods: 1. Data forwarding is typically performed using kernel protocol frameworks such as sockets and XFRM; 2. DPDK (Data Plane Development Kit); Existing technologies typically use a fixed method for data forwarding, namely, using the kernel protocol stack or DPDK, which has the following limitations: The forwarding method is relatively fixed and lacks flexible switching means. Switching usually involves a system restart. There is a lack of redundant backup mechanism. The forwarding modes are usually unrelated to each other, resulting in poor fault recovery capability. When efficient data forwarding fails, there is usually no backup data or backup mode. To address the shortcomings of the prior art, the present invention proposes a solution that achieves flexible switching between multiple forwarding methods and mutual redundancy backups of these methods through state detection, adjustment strategies, implementation strategies, and reliability and security assurance. Summary of the Invention

[0003] In order to solve the problems existing in the prior art, the purpose of this application is to provide a method to improve the efficiency of edge network metadata forwarding.

[0004] The method for improving the metadata forwarding efficiency of an edge network as described in this application includes the following steps: S101. Run kernel protocol stack forwarding instances in parallel in edge network elements, using socket forwarding, XFRM rule encryption and DPDK forwarding instances to process different user data streams respectively, and obtain mutually redundant forwarding resources. S102. Continuously monitor the connectivity status of each instance in step S101 through the independent state detection module, and detect the performance index values ​​of XFRMpolicy and state activity, DPDK connectivity, including uplink and downlink forwarding count, forwarding rate, packet loss count, and packet loss rate. S103. Based on the state detection results of step S102, adjust the state machine according to the following steps: If a chain break occurs in the application of preset rules, switch modes; if performance degrades, adjust the configuration. S104. Before making adjustments, perform the following steps: Save the current forwarding rules using the Redis backup system, and retrieve the target rules from Redis during the switch: Inject rules into DPDK instances, switch DPDK to the kernel, and establish XFRM policy and state rules through netlink messages; S105. Perform the following steps according to the policy type: In mode switching, after successfully establishing a new rule, clear the original rule, verify the path, and notify completion. In configuration adjustment, perform the following processing: Expansion: Create a new data instance and register it to the edge network element control layer distribution list; Migration: Back up some rules from the source instance to the target instance, and retrieve the rules from Redis to clear the source rules; Deletion: Remove the instance from the control layer distribution list. S106. Record alarms and logs during the policy implementation process through the fault detection module, and trigger failure rollback: if the switch fails, perform mode rollback to restore the original forwarding rules; if the configuration adjustment fails, perform configuration restoration. S107. Feed back the performance data after the strategy is implemented to the machine learning module to dynamically optimize and adjust the strategy threshold.

[0005] Preferably, in step S101, the edge network element acquires the user data stream, processes it through a classification algorithm, and then splits it into streams. The data stream that needs to be encrypted is encrypted through the kernel protocol stack combined with XFRM rules. For streams requiring high-speed forwarding, they are distributed to DPDK instances. Subsequently, based on the load balancing algorithm, encrypted streams and high-speed stream forwarding streams are allocated to parallel instances to form a data stream mapping. The instance status is monitored, and if overloaded, the resource allocation scheme is optimized. For the optimization scheme, consistent hash mapping is used to determine redundant paths for redundant resources, and the utilization rate of edge network element resources is evaluated. If the threshold is exceeded, the number of parallel instances is dynamically adjusted. Finally, the final data flow forwarding scheme is determined based on the updated instance configuration and deployment.

[0006] Preferably, in step S102, the state detection module monitors the status of the forwarding instance, judges the activity of the XFRM policy based on a preset threshold, outputs the detection result, and if the activity is abnormal, the XFRM policy is reset and a new status is obtained. Then, the performance indicators (uplink and downlink forwarding count, rate) of the DPDK instance are extracted, and the K-means algorithm is used for cluster analysis. If the clustering result shows that the packet loss rate exceeds the limit, the load balancing module adjusts the DPDK resource allocation. Based on the optimized resource configuration, the status detection module uses a consistent hashing algorithm to map data streams to instances, monitors the instance running status, and assesses whether the uplink and downlink forwarding numbers are balanced. If they are unbalanced, the resource scheduling module dynamically adjusts the instance priority to form the final configuration.

[0007] Preferably, in step S103, the status detection module extracts real-time data of the instance based on the updated configuration, judges the stability of the data stream according to a preset threshold, and if there is an anomaly, the traffic allocation module reallocates the data stream, then obtains the instance performance data, classifies it using the support vector machine algorithm, and if the classification indicates insufficient resources, the resource scheduling module adjusts the allocation of computing resources. Extract runtime latency data. If the latency exceeds the threshold, the latency optimization module adjusts the data stream priority. Based on the optimized configuration, the consistent hashing algorithm is used to map the data stream to the instance to achieve balanced allocation. Finally, the instance status is monitored to evaluate whether the resource utilization is balanced and output the resource balance result.

[0008] Preferably, in step S104, the Redis backup system stores and forwards rules, and after obtaining the target rule, it injects it into the DPDK instance through a netlink message and establishes an XFRM policy rule. It extracts the instance initialization status, uses the support vector machine algorithm for classification to determine stability, and if the status is abnormal, the traffic allocation module adjusts the data flow, obtains the instance running status data, and uses the consistent hashing algorithm to map it to the instance to achieve balanced allocation. The status detection module monitors resource utilization. If the utilization exceeds the threshold, the resource scheduling module reallocates computing resources.

[0009] Preferably, in step S105, the current mode configuration is obtained based on the strategy type, and the new rule data of the target instance is obtained after parsing. If the format is correct, it is injected into the target instance through a netlink message. Then, a ping test is performed to verify the path connectivity. If it is normal, the original rule data in Redis is cleared, the notification parameters are extracted, and a completion notification is sent through a message queue. To meet configuration requirements, the distribution list is obtained from the control layer, new instances are allocated using a consistent hashing algorithm, and instance status is extracted. If migration is required, the rules are backed up from the source instance to the target instance and the source rules are cleared.

[0010] Preferably, in step S106, the fault detection module acquires alarm and log data, parses error codes and timestamps to determine the failure type. If it is a mode switching failure, it extracts the original forwarding rules from the backup storage according to the version identifier, injects the original rules into the target instance through netlink messages to restore the forwarding table, extracts the instance status, performs ping detection to verify the path connectivity, if normal, it obtains the distribution list backup from the control layer, compares the differences using a consistent hash algorithm, adjusts the distribution list accordingly (removes abnormal instances, registers restored instances), and finally sends a completion notification containing the restored configuration and updated list through a message queue.

[0011] Preferably, in step S107, the performance monitoring module collects latency, throughput, and resource utilization data after the strategy is implemented. If the latency or resource utilization exceeds the threshold, the performance change trend is fitted through regression analysis. Based on this trend, the strategy threshold (latency threshold, resource allocation ratio) is optimized using a gradient descent algorithm. The optimized threshold is distributed to the strategy execution module through a message queue for updating, and the updated running status (response time, error rate) is obtained. If the error rate meets the standard, the consistency hashing algorithm is used to verify the consistency of instance allocation, and the edge network element distribution list and instance registration information are adjusted according to the verification result.

[0012] The method for improving edge network metadata forwarding efficiency described in this application has the advantages of improving data forwarding stability: by using multiple modes for mutual redundancy and backup, it ensures timely adjustment and switching to the backup mode when a certain forwarding mode fails, ensuring that data forwarding is not interrupted. It introduces machine learning technology and sets flexible adjustment strategies, dynamically adjusting the strategy according to the current state and historical data, including not only mode switching, but also forwarding instance expansion and migration. By introducing a state detection framework, it enriches the real-time operation parameter detection of the forwarding module. Currently, this solution has comprehensively considered various factors, combined with the actual development of the project, and considered the feasibility of implementation and system stability. Attached Figure Description

[0013] Figure 1 This application describes a method for improving the efficiency of edge network metadata forwarding. Figure 1 ; Figure 2 This application describes a method for improving the efficiency of edge network metadata forwarding. Figure 2 . Detailed Implementation

[0014] like Figures 1-2 As shown, the method for improving the metadata forwarding efficiency of an edge network according to this application includes the following steps: like Figures 1-2 As shown, S101, the kernel protocol stack forwarding instance runs in parallel in the edge network element, using socket forwarding and XFRM rule encryption and DPDK forwarding instances to process different user data streams respectively, resulting in mutually redundant forwarding resources; Further, in step S101, user data streams are obtained through edge network elements, and a classification algorithm is used to determine the data stream type to obtain a set of classified data streams; For the categorized data stream set, if the data stream needs to be encrypted, the kernel protocol stack is used to call socket forwarding, and data encryption is performed in combination with XFRM rules to obtain encrypted data streams; If the data stream needs to be forwarded at high speed, it will be distributed to a DPDK forwarding instance to obtain a high-speed forwarded data stream; Based on the encrypted data stream and the high-speed forwarding data stream, a load balancing algorithm is used to distribute the data streams to the forwarding instances running in parallel, resulting in the allocated data stream mapping. The running status of the forwarding instance is obtained from the allocated data stream mapping. It is determined whether the forwarding instance is overloaded. If it is overloaded, the data stream distribution is adjusted through resource allocation to obtain an optimized data stream distribution scheme. For the optimized data stream distribution scheme, a consistent hashing algorithm is used to map to redundant resources, determine redundant forwarding paths, and obtain redundant mapping results; By using the redundancy mapping results, the resource utilization rate of edge network elements is obtained, and it is determined whether the resource utilization rate exceeds the preset threshold. If it does, the number of forwarding instances running in parallel is dynamically adjusted to obtain the adjusted instance configuration. Based on the adjusted instance configuration, update the forwarding instance deployment of the edge network element to determine the final data flow forwarding scheme.

[0015] Specifically, in step S101, kernel protocol stack forwarding instances and DPDK forwarding instances are run in parallel in edge network elements to achieve redundant forwarding resources. First, data flow distribution is achieved by configuring network interfaces. For example, configure an Intel X710 network card and set up two virtual functions (VFs), namely VF0 and VF1, where VF0 is bound to the kernel protocol stack and VF1 is bound to DPDK; The SR-IOV technology is used to divide the physical functions of the network card, and the bandwidth is allocated as VF0 10Gbps and VF1 10Gbps to ensure resource balance. The kernel protocol stack instance uses socket forwarding, with the TCP socket buffer size configured to be 64KB, and receives user data stream A (assuming the traffic is 500Mbps, including HTTP requests). IPSec encryption is implemented using the XFRM framework in the Linux kernel, with the AES-256-CBC algorithm set and a key length of 256 bits. After encryption, the data packet size increases by about 10%, or 550Mbps. The encryption process involves block ciphers, with each 128-bit data block processed using the AES algorithm, resulting in an encryption delay of approximately 0.1ms. The DPDK instance then processes data stream B (assuming a traffic of 600Mbps, including video stream) through user-space polling and distributes it to 4 CPU cores using RSS (Receive Side Scaling), with each core processing 150Mbps. DPDK uses the rte_flow API to configure flow rules, directing data flow B to a specific queue with a queue depth of 1024 to reduce packet loss rate. DPDK forwarding latency is approximately 0.05ms, which is better than kernel instances; To ensure redundancy, a heartbeat detection mechanism is deployed with a cycle of 100ms. If VF0 fails (packet loss rate > 5%), data stream A is switched to VF1, and the switching time is controlled within 50ms. Analysis shows that kernel instances are suitable for low-speed, encrypted control flows, while DPDK is suitable for high-speed, real-time flows. Redundancy design ensures service continuity in the event of a failure, and the overall throughput reaches 1.1Gbps, meeting the needs of edge network elements.

[0016] In one embodiment, the definition of terms includes: Edge network element: refers to network device located at the network edge, responsible for data forwarding, processing or storage; EPDG: Evolved Packet Data Gateway, responsible for the connection between the mobile network and external data networks; UPF: User Plane Function, a functional module in the core network responsible for user plane data processing, mainly supporting packet routing and forwarding, policy execution, and protocol adaptation; DPDK acceleration technology: Data plane development kit used to improve packet processing speed; XFRM encryption: An encryption framework in the Linux kernel used for encrypting and decrypting data packets; socket: A network programming interface used for inter-process communication or network communication.

[0017] like Figures 1-2 As shown in step S102, the connectivity status of each instance in step S101 is continuously monitored through the independent state detection module. The performance index values ​​of XFRM policy and state activity and DPDK connectivity are detected. The performance index values ​​include uplink and downlink forwarding count, forwarding rate, packet loss count, and packet loss rate.

[0018] Further, in step S102, the running status data of each forwarding instance is obtained through the status detection module, and a preset threshold is used to determine whether the XFRM strategy activity is normal, so as to obtain the activity detection result. If the XFRM policy activity is abnormal, the XFRM policy configuration is reset through the status detection module, and the policy status after the reset is obtained. The performance metrics of DPDK instances are extracted from the reset policy state by the state detection module. The K-means algorithm is used to perform cluster analysis on the uplink forwarding count, downlink forwarding count, and forwarding rate to obtain the performance metric classification results. Based on the performance metric classification results, if the packet loss rate exceeds the preset threshold, the resource allocation of the DPDK instance will be adjusted through the load balancing module to obtain an optimized resource configuration. The connectivity data of the optimized resource configuration is obtained through the state detection module, and the data flow is mapped to the forwarding instance using the consistent hashing algorithm to obtain the data flow allocation scheme. Based on the data flow allocation scheme, the running status of the forwarding instances is monitored through the status detection module to determine whether the number of uplink forwardings and downlink forwardings are balanced, and the forwarding balance result is obtained. If forwarding is unbalanced based on the forwarding balance results, the priority of forwarding instances will be dynamically adjusted through the resource scheduling module to obtain the final forwarding instance configuration.

[0019] Specifically, in step S102, an independent state detection module is deployed in the edge network element to continuously monitor the connectivity status of the kernel protocol stack and DPDK instance. The specific implementation includes the detection of XFRM policy and state activity as well as DPDK performance indicators. For the XFRM policy, the module periodically queries the Linux kernel's XFRM status table, checking the policy table and status table every 200ms to verify the activity of the IPSec tunnel. For example, check if the tunnel is in the UP state, confirm whether the key exchange is complete, and count the number of encrypted packets passing through the tunnel per second. Assume that the detected uplink forwarding rate is 1000 packets / s and the downlink forwarding rate is 950 packets / s. If a rule in the policy table is not triggered (e.g., the match packet count is 0), it is marked as inactive and an alarm is triggered. Packet loss rate is calculated by comparing the input and output packet counts. The formula is: Packet loss rate = (Number of input packets - Number of output packets) / Number of input packets × 100%. If a packet loss rate of 2% is detected, it is recorded as an anomaly. For DPDK instances, the module uses the rte_eth_stats API to obtain network interface statistics, collecting data every 100ms to monitor uplink and downlink forwarding rates and packet loss. For example, assuming the uplink forwarding rate is 800Mbps, the downlink forwarding rate is 780Mbps, and the number of packets lost is 50 packets / s, the packet loss rate is calculated using the formula (50 / 800000)×100%=0.00625%. The detection module also analyzes the DPDK queue status and uses rte_flow_query to check the number of packets matching the flow rules. Assuming that each of the four queues matches 200Mbps of traffic, the total is 800Mbps. If a queue matches 0 packets, it is marked as an exception. All detected data is stored in a time-series database. Thresholds are set (such as packet loss rate > 1% or forwarding rate < 500Mbps) to trigger automatic alarms. Alarms are sent to the management platform via REST API. Logically, XFRM detection ensures the stability of the encrypted channel, while DPDK detection guarantees high-speed forwarding performance. The combination of the two forms a complete monitoring chain, ensuring the high availability of forwarding resources for edge network elements.

[0020] like Figures 1-2 As shown, S103, based on the state detection result of step S2, adjust the state machine according to the strategy. The specific steps are as follows: if a chain break occurs in the application of preset rules, switch modes; if the performance degrades, adjust the configuration.

[0021] Further, in step S103, the real-time running data of the forwarding instance is extracted from the updated configuration state by the state detection module, and the stability of the data flow is judged by a preset threshold to obtain the stability judgment result. Based on the stability assessment results, if the data flow is not stable, the data flow will be reallocated to the forwarding instance through the traffic allocation module to obtain the reallocated traffic configuration. The performance data of the forwarding instances is obtained from the reallocated traffic configuration through the state detection module, and the performance data is classified using the support vector machine algorithm to obtain the performance classification result. Based on the performance classification results, if the performance classification indicates insufficient resources, the computing resources of the forwarding instance are adjusted through the resource scheduling module to obtain the adjusted resource allocation; The state detection module extracts the runtime latency data of the forwarding instance from the adjusted resource allocation. If the runtime latency exceeds the preset threshold, the latency optimization module adjusts the data flow priority to obtain the optimized priority configuration. The state detection module obtains the balanced data of the forwarding instances from the optimized priority configuration, and uses the consistent hashing algorithm to map the data stream to the forwarding instances to obtain the balanced data stream allocation scheme. Based on the balanced data flow allocation scheme, the running status of the forwarding instances is monitored by the status detection module to determine whether the resource utilization is balanced, and the resource balance result is obtained.

[0022] Specifically, in step S103, based on the state detection results of edge network elements, the system automatically optimizes network performance by adjusting the state machine through strategy. When a link failure is detected, the system triggers a mode switching mechanism to automatically switch traffic from the faulty link to the backup link. For example, if the primary link is interrupted, the system analyzes the BGP routing table and detects that the primary link RTT exceeds 500ms, and immediately switches the traffic to the backup link, with the switching time controlled within 100ms. The switching algorithm uses the shortest path first, combined with link bandwidth utilization (assuming the backup link bandwidth is 1Gbps and the current utilization is 30%), to ensure stable traffic after the switch. After the switchover, the system verified the connectivity of the new link through a ping test, recording an RTT of 20ms and a packet loss rate of 0.01%. If performance degrades, for example, if a network card's forwarding rate is detected to drop to 600Mbps (below the threshold of 800Mbps), the system will initiate a configuration adjustment process. First, by analyzing the network card queue statistics, it was found that the processing latency of queue 1 was 50us, which was higher than the normal value of 20us. The system automatically adjusted the priority of the DPDK polling thread, increased the thread priority of queue 1 by 20%, and reallocated the CPU cores, binding them to the idle core 3. After the adjustment, the queue latency dropped to 25µs, and the forwarding rate was restored to 820Mbps; All adjustments are recorded in the log database, and performance data is correlated with timestamps to generate trend analysis; For example, the system calculates the average forwarding rate over the past hour (750Mbps) and the adjusted peak rate (820Mbps) to confirm the optimization effect; If the adjustment still fails to meet the target, the system dynamically adjusts the MTU value from 1500 bytes to 1400 bytes by calling the kernel API, reducing fragmentation overhead and lowering the packet loss rate to 0.005%. All operations are executed automatically through internal scripts, and logs are uploaded to the management platform via the gRPC interface, forming a closed-loop optimization.

[0023] like Figures 1-2 As shown in S104, before performing the adjustment, the following steps are specifically performed: save the current forwarding rules through the Redis backup system, obtain the target rules from Redis when switching: inject rules into the DPDK instance, switch DPDK to the kernel, and establish XFRM policy and state rules through netlink messages.

[0024] Further, in step S104, the backed-up rule configuration data is obtained by storing and forwarding the Redis backup system rules. The target forwarding rule is obtained from the backed-up rule configuration data, and injected into the DPDK instance via netlink message to obtain the injected DPDK configuration. The XFRM policy rules are established based on the injected DPDK configuration using netlink messages, and the XFRMpolicy configuration data is obtained. The initialization state of the forwarding instance is extracted from the XFRM policy configuration data. The initialization state is classified using the support vector machine algorithm to determine whether it meets the stability requirements and obtain the initialization stability result. If the initial stability result indicates an abnormal state, the data flow is adjusted to the forwarding instance through the traffic allocation module to obtain the adjusted traffic configuration; The running status data of the forwarding instances is obtained from the adjusted traffic configuration, and the running status data is mapped to the forwarding instances using a consistent hashing algorithm to obtain a balanced data flow allocation scheme. The state detection module extracts the resource utilization data of forwarding instances from the balanced data flow allocation scheme. If the resource utilization exceeds the preset threshold, the resource scheduling module reallocates computing resources to obtain an optimized resource configuration.

[0025] Specifically, in step S104, before performing the adjustment, the system backs up the current forwarding rules through Redis. The specific method is to serialize the forwarding rules of the existing DPDK instance into JSON format and store them in a Redis key-value pair. The key name is "forwarding_rules_20250721", and the value includes the VLAN configuration (VLAN ID 100), ACL rules (allowing TCP port 80 and 443 traffic), and QoS policy (bandwidth limit to 2Gbps) of the current network card. The stored procedure is implemented using the Redis SETEX command, with an expiration time set to 3600 seconds to ensure that the backup data is valid for 1 hour; The system then retrieves the target rule from Redis and injects the new rule into the DPDK instance; For example, retrieve the rule set with the key "target_rules_edge1", which contains the new VLAN ID 200 and the updated ACL rule (adding UDP port 53). The injection process is completed through DPDK's RTE_ACL API. The system first parses the JSON rules and generates the ACL context, which takes about 10ms. Next, the system establishes XFRM policy and state rules via netlink messages; For example, configure an XFRM policy for an IPSec tunnel, specifying the source IP as 192.168.1.1, the destination IP as 192.168.2.1, the encryption algorithm as AES-CBC (key length 256 bits), and set the SPI value to 0x1000; The netlink message is sent via the libnl library. The system analyzes the returned ACK message and confirms that the rule application takes 15ms. If a Redis backup failure is detected (for example, if the Redis response time exceeds 50ms), the system automatically switches to local file backup, with the storage path " / var / rules / backup.json", and records the failure log to Syslog. All operations are executed automatically through internal Go scripts. The scripts query the Redis status via the gRPC interface, ensuring the atomicity of backups and rule injection, thus forming a closed-loop management system.

[0026] like Figures 1-2 As shown in S105, perform the following steps according to the policy type: In mode switching, after the new rule is successfully established, the original rule is cleared, and the completion is notified after the path is verified. In configuration adjustment, the following processes are performed: Expansion: Create a new data instance and register it to the edge network element control layer distribution list; Migration: Back up some rules of the source instance to the target instance, and obtain the rules from Redis to clear the source rules; Deletion: Remove the instance from the control layer distribution list.

[0027] Further, in step S105, the current mode configuration is obtained from the policy type, and the configuration is parsed using the mode switching policy to obtain the new rule data for the target instance; If the new rule data conforms to the preset format, the new rule data is injected into the target instance via a netlink message to obtain the injected instance configuration; Based on the injected instance configuration, ping is used to verify the path connectivity and obtain path status data. If the path status data indicates normal connectivity, the original rule data is cleared from Redis to obtain the updated rule storage status. Extract notification parameters from the updated rule storage state, send a completion notification through the message queue, and obtain notification confirmation data; To address configuration adjustment requirements, the distribution list is obtained from the edge network element control layer, and new data instances are allocated to the distribution list using a consistent hashing algorithm, resulting in an updated distribution list. Extract the instance status from the updated distribution list. If the instance status indicates that migration is required, back up the source instance rules to the target instance and clear the source instance rules to obtain the adjusted instance configuration.

[0028] Specifically, in step S105, after the system successfully establishes a new rule during mode switching, it automatically clears the original rule; For example, when an edge network element receives a new traffic scheduling policy, which includes the source IP range 10.0.0.0 / 24, the destination IP range 172.16.0.0 / 16, and a bandwidth allocation of 3.5Gbps, the new rule is injected through the DPDK's RTE_FLOW API, taking 8ms. The system then verifies the new rule path by sending an ICMP probe packet (TTL set to 64, packet size 128 bytes). After confirming that the round-trip latency is less than 20ms, the old rule is deleted via kernel netlink messages (using the libnl3 library). For example, the source IP (10.0.1.0 / 24 policy) took 5ms; After the cleanup is complete, the system sends an acknowledgment message to the control layer via the gRPC interface. The message format is Protobuf and includes the timestamp 20250721182600 and the node ID edge2. Configuration adjustments are underway; expansion operations are creating new data instances. For example, a virtual instance with 4 CPU cores and 8GB of memory is allocated and registered to the control layer distribution list. The list is stored in etcd with the key "edge_instances_20250721" and the value includes the instance ID instance_003 and the bandwidth capacity of 5Gbps. The registration takes 12ms. During the migration operation, the source instance (ID instance_001) will have some rules applied; For example, the ACL of VLAN ID 300 and TCP port 8080 is serialized into Protobuf format and stored in the key "migration_rules_001" using the Redis SET command, with an expiration time of 7200 seconds; The target instance (ID instance_002) retrieves the rule from Redis, parses it, and applies it via the RTE_ACL API, which takes 9ms. Subsequently, the source instance clears the corresponding rule, freeing up approximately 2MB of memory. The delete operation removes the instance from the etcd distribution list; For example, removing the record with ID instance_004 is executed via the etcd DELETE command, taking 4ms and logging it to the Kafka topic "instance_ops". The log includes the operation time 20250721182605 and the result status "success". All operations are executed automatically via Python scripts, which query etcd status via a REST API to ensure atomicity of operations and rule validation failures. For example, when the ICMP packet loss rate exceeds 5%, the system rolls back to the previous state, with the rollback taking 15ms, thus forming a closed-loop management system.

[0029] like Figures 1-2 As shown in S106, the alarms and logs of the policy implementation process are recorded through the fault detection module, and a failure rollback is triggered: if the switch fails, the mode rollback is executed to restore the original forwarding rules; if the configuration adjustment fails, the configuration is restored.

[0030] Further, in step S106, alarm data and log data are obtained from the fault detection module, and the error codes and timestamps in the alarm data are parsed to obtain failure classification data; If the failure classification data indication mode switching fails, the version identifier of the original forwarding rule is queried from the backup storage, and the original forwarding rule is extracted by the version identifier to obtain the original forwarding rule dataset; The original forwarding rule dataset is injected into the target instance via netlink messages, the instance's forwarding table is updated, and the restored instance configuration is obtained. Extract instance status parameters from the restored instance configuration, and use ping to verify the instance's path connectivity to obtain path status data; If the path status data indicates normal connectivity, a backup of the distribution list is obtained from the edge network element control layer. The consistent hashing algorithm is used to compare the current distribution list with the backup to obtain the distribution list difference data. Based on the differences in the distribution list, the distribution list of the edge network element control layer is adjusted, abnormal instances are removed and recovery instances are registered to obtain the updated distribution list status. A recovery completion notification is sent via a message queue, containing the restored instance configuration and the updated distribution list status, and confirmation data is received.

[0031] Specifically, in step S106, the system records alarms and logs during the policy implementation process through the fault detection module, and performs a rollback operation for failed switching or configuration adjustments to ensure the stability of the edge network. For example, when the system implements a new traffic scheduling strategy, the detection module collects key indicators of edge network elements through Prometheus, including CPU utilization (threshold set to 85%), memory usage (threshold 4GB) and network bandwidth utilization (threshold 4Gbps). When an anomaly is detected, such as bandwidth usage reaching 4.2Gbps, the system triggers an alarm and pushes logs to Elasticsearch via Fluentd. The log content includes the timestamp 20250721183000, the node ID edge3, and the anomaly description "bandwidth exceeded". After the alarm is triggered, the system uses a consistent hashing algorithm (1024 hash points) to locate the affected instance (ID instance_005) and uses a Python script to call the REST API to query the current rule status stored in etcd. The key is "traffic_rules_20250721" and the value contains the source IP range 192.168.1.0 / 24 and the destination port 443. The analysis process revealed that after the rule was applied, the ICMP probe packet (packet size 256 bytes, TTL set to 128) packet loss rate reached 7%, exceeding the threshold of 5%, and was judged as a handover failure; The system then initiated a rollback mode, retrieving backup rules (key "backup_rules_20250721") from etcd and restoring the original rules (such as the forwarding policy for source IP 192.168.2.0 / 24) using the RTE_FLOW API, which took 10ms. After the rollback is complete, the system sends a status update via gRPC. The message includes the timestamp 20250721183005 and the status "rollback_success". For configuration adjustment failures, such as failure to register a newly created instance (allocated 6 CPU cores and 12GB memory) to etcd during expansion (timeout threshold 15ms, actual time taken 20ms), the system detects etcd response status code 503 and triggers configuration recovery. Remove unregistered instance records (key "edge_instances_20250721", value "instance_006") by calling the etcd DELETE command through a Python script, and log the operation to the Kafka topic "config_ops" with the operation time 20250721183010 and the status "revert_success"; All operations are executed through automated scripts to ensure atomicity. Log analysis shows a rollback success rate of 99.8%, forming a closed-loop management system.

[0032] like Figures 1-2 As shown in step S107, the performance data after the strategy is implemented is fed back to the machine learning module to dynamically optimize and adjust the strategy threshold.

[0033] Further, in step S107, performance data after the strategy implementation is collected from the performance monitoring module, and the latency index, throughput index and resource utilization rate in the performance data are analyzed to obtain a performance feature dataset; If the latency or resource utilization rate in the performance feature dataset exceeds the preset threshold, the performance feature dataset is fitted by a regression analysis model to obtain the performance change trend. Based on the performance change trend, the gradient descent algorithm is used to optimize the strategy threshold parameters, and the latency threshold and resource allocation ratio are adjusted to obtain the optimized threshold parameter set. The optimized threshold parameter set is distributed to the policy execution module via a message queue to update the policy configuration and obtain threshold update confirmation data. The updated policy running status is obtained from the policy execution module, and the instance response time and error rate in the running status are analyzed to obtain the policy adjustment result data. If the error rate in the policy adjustment result data is lower than the preset threshold, the consistency of instance allocation in the policy execution module is verified by the consistent hashing algorithm to obtain the instance allocation status data. Based on the instance allocation status data, adjust the distribution list of edge network elements, update the instance registration information, and obtain the optimized distribution list status data.

[0034] Specifically, in step S107, the system feeds back the performance data after the strategy is implemented to the machine learning module, dynamically optimizes and adjusts the strategy threshold, and ensures that the performance of the edge network is adaptively adjusted. The system uses Prometheus to collect key performance indicators of edge nodes, including latency (target threshold 50ms), throughput (target threshold 5Gbps), and number of connections (target threshold 10000). For example, after a certain edge node (ID edge7) implemented a new traffic allocation policy, Prometheus recorded a latency of 55ms, a throughput of 4.8Gbps, and a connection count of 12000. Data is transmitted to the machine learning module via the Kafka topic "perf_metrics", and the message contains the timestamp 20250721183500 and the node ID; The machine learning module uses the XGBoost algorithm (tree depth 5, learning rate 0.1) to analyze historical performance data (last 7 days, sample size 10000) to predict the relationship between latency and connection count, and concludes that when the latency exceeds 50ms, the connection count threshold should be adjusted to 9500. The analysis revealed that the current number of connections (12,000) was causing queue congestion and increasing latency to 55ms. The model was optimized using gradient descent (100 iterations), and it was recommended to lower the connection threshold to 9,500. The system calls etcd (key "threshold_rules_20250721") via gRPC to update the connection threshold to 9500, with the value including the IP range 192.168.3.0 / 24 and port 80; After the update, the system used a TCP probe (packet size 512 bytes, timeout 3 seconds) to verify the effect of the adjustment, and the latency was reduced to 48ms and the throughput increased to 5.1Gbps; Performance data is fed back to the machine learning module via Kafka, and optimization logs are recorded in Elasticsearch (index "opt_logs"), including timestamp 20250721183510 and status "threshold_updated". If the latency remains higher than 50ms after adjustment, the system will further analyze throughput fluctuations, use K-means clustering (3 clusters) to identify abnormal nodes, automatically adjust the load balancing weights (e.g., reduce the edge7 weight from 0.3 to 0.2), and update the configuration via REST API (key "load_balance_20250721"). All operations are executed automatically by Python scripts, and logs show an optimization success rate of 99.5%, forming a dynamic adjustment closed loop.

[0035] For those skilled in the art, various other corresponding changes and modifications can be made based on the technical solutions and concepts described above, and all such changes and modifications should fall within the protection scope of the claims of this application.

Claims

1. A method for improving edge network element data forwarding efficiency, characterized in that, Includes the following steps: S101. Run kernel protocol stack forwarding instances and DPDK forwarding instances in parallel in edge network elements to process different user data streams, thereby obtaining redundant forwarding resources. S102. Continuously monitor the connectivity status of each forwarding instance in step S101 through the independent state detection module, and detect the XFRMpolicy and state activity, and the performance index values ​​of the DPDK forwarding instance. S103. Based on the state detection in step S102, according to the preset rules, if a disconnection occurs, a bidirectional mode switch is performed between the kernel protocol stack forwarding instance and the DPDK forwarding instance; if the performance degrades, the configuration is adjusted. S104. Before performing the adjustment, the current forwarding rules are saved through the Redis backup system. When switching, the target forwarding rules are obtained from the Redis backup system, the target forwarding rules are injected into the DPDK forwarding instance, the DPDK forwarding instance and the kernel protocol stack forwarding instance are switched bidirectionally, and the XFRM policy and state rules are established through netlink messages. S105. During mode switching, after the new forwarding rule is successfully established, the original forwarding rule is cleared, and after the path is verified, the edge network element control layer is notified of completion; during configuration adjustment, expansion, migration and deletion are performed. S106. Record alarms and logs during the mode switching and configuration adjustment strategy implementation process through the fault detection module, and trigger failure rollback: if the switching fails, perform mode rollback and restore the original forwarding rules from the Redis backup system; if the configuration adjustment fails, perform configuration recovery. S107. Feed back the performance data after mode switching, configuration adjustment and failure rollback to the machine learning module to dynamically optimize and adjust the policy threshold.

2. The method of claim 1, wherein, Step S101 specifically includes: The user data stream is divided by a classification algorithm. The data stream that needs to be encrypted is encrypted by the kernel protocol stack in combination with XFRM rules. The data stream that needs to be forwarded at high speed is distributed to DPDK forwarding instances. Based on a load balancing algorithm, encrypted streams and high-speed streams are distributed to parallel forwarding instances to form a data stream mapping. If the forwarding instances are overloaded, the resource allocation scheme is optimized by using a consistent hashing algorithm to map redundant resources and dynamically adjusting the number of parallel forwarding instances.

3. The method of claim 1, wherein, Step S102 specifically includes: The status detection module periodically queries the Linux kernel XFRM status table to detect policy activity and uses the rte_eth_stats API of the DPDK forwarding instance to obtain network interface statistics. The K-means algorithm is used to cluster the performance indicators. If the packet loss rate exceeds the threshold, the resource allocation of the DPDK forwarding instance is adjusted. Data streams are mapped to forwarding instances based on a consistent hashing algorithm, and the priority of forwarding instances is dynamically adjusted through a resource scheduling module.

4. The method of claim 1, wherein, Step S103 specifically includes: The support vector machine algorithm is used to classify the performance data of forwarding instances, and the allocation of computing resources is adjusted if resources are insufficient. If the runtime latency exceeds the threshold, the data stream priority is adjusted through the latency optimization module.

5. The method of claim 1, wherein, Step S104 specifically includes: Forwarding rules are stored in JSON format in the Redis backup system, and their expiration time is set using the SETEX command; The forwarding rule injection process includes: parsing JSON rules to generate the ACL context of the DPDK forwarding instance, and establishing the XFRM policy by sending netlink messages through the libnl library; If the Redis backup system fails, it will switch to local file backup and log the changes.

6. The method of claim 1, wherein, Step S105 specifically includes: When switching modes, new forwarding rules are injected through the RTE_FLOW API of the DPDK forwarding instance, and the original forwarding rules are cleared after ICMP probes verify the path. The expansion operation includes allocating CPU / memory resources and registering them with the etcd storage's distribution list; The migration operation serializes the forwarding rules into Protobuf format and stores them in the Redis backup system. After the target forwarding instance obtains the forwarding rules, it clears the forwarding rules of the source forwarding instance.

7. The method of claim 1, wherein, Step S106 specifically includes: The fault detection module collects CPU utilization, memory usage, and network bandwidth metrics through Prometheus. During mode rollback, the backup forwarding rules are obtained from the Redis backup system, and the original forwarding strategy is restored through the RTE_FLOW API. Configuration recovery includes removing unregistered forwarding instances and logging them to Kafka using the DELETE command in etcd.

8. The method of claim 1, wherein, Step S107 specifically includes: The machine learning module uses the XGBoost algorithm to analyze historical performance data and optimizes the iterative threshold parameters through gradient descent. The optimized threshold is updated to the etcd storage via gRPC calls; K-means clustering is used to identify abnormal nodes and automatically adjust the load balancing weights.

Images