A dpi offloading device rule management system and method

Abstract

The application is specifically a DPI shunt device rule management system and method, the system comprising: a service configuration table, wherein each service configuration item has a unique service ID; a rule configuration table, wherein each rule configuration item has a unique rule ID; a rule hash table, which quickly retrieves the rule ID by hashing the rule matching content; a policy control server, which issues service configurations to the DPI shunt device through a remote procedure call (RPC) interface, and the DPI shunt device splits the service configurations into one or more rule configurations according to a splitting algorithm; and a Redis database, which is used to persistently store the contents of the service configuration table, the rule configuration table and the rule hash table. The application has the advantages that: the table items of each management module are designed to be loosely coupled, allowing them to be independently developed and debugged; and the dual-ID management mode has good scalability and can be compatible with traditional single-ID rule management systems.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet, in particular to a DPI offloading device rule management system and method. BACKGROUND

[0002] In telecom value-added services, deep packet inspection (DPI) devices are responsible for identifying and forwarding data traffic according to service types. This is usually achieved by setting multiple rules on the device, because a single service may require multiple rules to describe, and rules for different services may overlap. In this case, the priority of the rules becomes particularly important.

[0003] In the application of deep packet inspection (DPI) services, a policy control server sends service configurations to a DPI offloading device through a remote procedure call (RPC) interface. Once the DPI offloading device receives these configurations, it must decompose the service configurations into one or more rule configurations and send them to the processing chip. Since all configurations need to be able to be queried and modified, a management system is needed to manage service configurations and rule configurations.

[0004] Compared with conventional rule management systems, the rule management system of a DPI offloading device faces two challenges:

[0005] 1. In conventional systems, only rule configurations are present without service configurations, so only one index item indexed by rule ID needs to be maintained. However, in the system of a DPI offloading device, both service configurations and rule configurations are present, so two index items are needed: one indexed by service ID and the other indexed by rule ID.

[0006] 2. The DPI offloading device encounters two scenarios: scenario one is that a service configuration is decomposed into multiple rule configurations; scenario two is that some rule configurations decomposed from multiple service configurations have the same matching content. In scenario one, one service ID needs to be associated with multiple rule IDs; in scenario two, one rule ID may need to be associated with multiple service IDs, at which time the priority of the service configurations needs to be considered, and the traffic is processed and forwarded according to the forwarding behavior of the service configuration with the highest priority. In the application scenario of service rules, the relationship between service configurations and rule configurations is crucial. See Figure 1 .

[0007] In order to cope with complex service and rule configurations in actual applications, it is urgent to design a DPI offloading device double-id rule management system and method. The management system needs to be able to realize the mutual association between services and rules, support the flexible addition, deletion and query of service configurations and rule configurations with small memory occupation, and also support the backup and recovery functions of the configurations. SUMMARY

[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide a DPI splitting device rule management system and method, so that the business configuration table and the rule configuration table can be managed separately and each can perform table item operation management independently; a flexible table item allocation strategy is adopted, and table item records are associated through linked lists to save memory space; and the Redis database is used reasonably to solve the configuration disk storage problem without affecting the business activation speed.

[0009] To achieve the above objectives, a DPI traffic splitting device rule management system is designed, comprising: a service configuration table for storing service priorities, forwarding behaviors, and rules into which the service is split, wherein each service configuration item has a unique service ID; a rule configuration table for storing the specific matching content of a rule, the corresponding service into which the rule is split, and the highest priority service ID, wherein each rule configuration item has a unique rule ID; and a rule hash table for quickly retrieving rule IDs through hash mapping of rule matching content, wherein the key of the rule hash table is the rule matching content, the value is the rule ID, and the rule_entry is reused in the rule configuration table and the rule hash table. The `rule_entry` table allocates space only once, and both tables access the same address when retrieving `rule_entry`. The policy control server, when issuing service configurations to the DPI splitting device via a Remote Procedure Call (RPC) interface, splits the service configurations into one or more rule configurations according to a splitting algorithm. During the splitting process, the DPI splitting device checks if a rule already exists in the rule hash table: if the rule exists, the corresponding rule ID is reused; if the rule does not exist, a new rule ID is assigned, and a key-value mapping for that rule is added to the rule hash table. Finally, the service-related configurations are filled into the service configuration table according to the service ID. The split rule configurations are populated into the rule configuration table according to the rule ID, and the business ID list and valid business ID in the rule configuration table are refreshed as needed. When the policy control server issues a delete business configuration operation through the RPC interface, the DPI splitting device retrieves the business configuration table according to the issued business ID, obtains the corresponding rule ID list, and iterates through the rule ID list one by one: It retrieves the rule configuration table according to the rule ID, removes the business ID to be deleted from the business ID list, and recalculates the valid business ID; if the business ID list is empty after removal, the storage space corresponding to the rule ID in the rule configuration table is cleared, and the rule_ of that rule is deleted from the rule hash table. The entry node is used as the key; finally, the storage space corresponding to the business ID in the business configuration table is cleared; when the policy control server sends a query request through the RPC interface, the DPI distribution device retrieves the business configuration table according to the business ID, obtains the rule ID list, and retrieves the rule configuration table according to the rule ID to obtain the entries of each rule, thereby restoring the business configuration according to the rule reorganization algorithm and returning it to the policy control server; the Redis database is used to persistently store the contents of the business configuration table, rule configuration table and rule hash table to ensure that the configuration in memory can be restored after the device is powered off and restarted, and the write operations of the Redis database are asynchronously sent to reduce communication latency.

[0010] This invention also provides a DPI splitting device rule management method using the aforementioned management system, comprising: a service distribution method: S1. After the service configuration is distributed from the policy control server to the DPI splitting device, the management system first performs parameter validity verification; S2. After successful verification, storage space is allocated in the corresponding position of the service configuration table, and the priority and action information in the service configuration are directly filled into the table. Then, according to the service splitting algorithm, the service matching content is split into multiple internal rules; S3. After retrieving the rule matching content rule_entry, the rule hash table is queried using the rule_entry group key to see if other services have previously split this internal rule. If the hash table returns a result, it indicates that it has been added before. In this case, the management system selects the rule with the highest priority and writes it into the hardware; S4. If the rule has not been added before, the management system first retrieves a free `rule_id` from the `rule_id` resource pool and assigns it to the rule. Then, using this `rule_id` as an index, it allocates storage space in the corresponding position in the rule configuration table, directly appends the business ID to the `business_id_list` list, assigns the business ID to `effect_business_id`, and then requests a storage space for the `rule_entry`, filling the memory address into the `rule_entry` field of the rule configuration table. Then, using the memory of this `rule_entry` as the key and `rule_id` as the value, it inserts it into the rule hash table. Here, `rule_entry` only uses one storage space. Finally, it retrieves the priority and action information of the newly added business ID from the business configuration table and sends it to the hardware along with the `rule_entry` of this rule; S5.If the hash table shows that this rule has been added before, the previously added and assigned `rule_id` is retrieved directly from the hash table's hit results. Then, using this `rule_id` as an index, the corresponding storage space is found in the rule configuration table, and the business ID to be added this time is appended to the `business_id_list`. At this point, the `business_id_list` contains at least two business IDs. The management system selects the business ID with the highest priority and fills it into `effect_business_id`. After determining the priority, if the `effect_business_id` of all the highest-priority businesses that have been split from this rule has changed, then the logic for issuing the rule to the hardware mentioned above needs to be reused. The priority and action information corresponding to `effect_business_id` is refreshed to the hardware to ensure that traffic that hits the rule is forwarded according to the forwarding behavior of the highest-priority business. If `effect_business_id` has not changed, there is no need to refresh the hardware configuration, and traffic that hits this rule is forwarded according to the previous forwarding behavior. S6. The operations related to this splitting rule in the rule configuration table have been completed. Next, the `rule_id` of this rule needs to be appended to the `rule_id_list` in the business configuration table. This allows the system to retrieve splitting rules by business ID. Then, it's determined whether the currently processed splitting rule is the last one among all splitting rules. If not, the matching content of the next rule is retrieved, and the above steps are repeated until all splitting rules have been traversed.

[0011] Preferably, the method provided by the present invention also includes other technical features, including: a business deletion method: S1. Query the rule configuration table according to rule_id, retrieve the business_id_list list, and determine whether there is only one id in the list, which is the business id that needs to be deleted; S2. If there is only one id in the business_id_list list, then this rule can be deleted directly. First, clear the management memory, delete the node with the rule_entry as the key in the rule hash table, release the memory space allocated for the rule_entry, release the storage space of the rule in the rule configuration table, and then delete the rule in hardware; S3. If there are multiple ids in the business_id_list list, it means that this rule has been split from multiple business configurations. First, remove the business id that needs to be deleted from the business_id_list list, and then calculate the highest priority business id among these business ids according to the priority calculation algorithm in the new business_id_list list and fill it into the effect. In t_business_id, if effect_business_id changes, the priority and action information of the new highest priority business ID are refreshed to the hardware. If effect_business_id does not change, there is no need to update the hardware configuration. This logic is reused from the logic used when effect_business_id changes during business deployment. S4. After processing this rule, the rule_id of this rule is removed from the rule_id_list in the business configuration table. Then, it is checked whether there are any remaining rule_ids in the rule_id_list. If there are, the next rule_id is retrieved, and the above steps are repeated until the rule_id_list is empty.

[0012] Preferably, the method provided by the present invention also includes other technical features, including: a business query method, which firstly verifies the validity of parameters. After verification, the rule_id_list list in the business configuration table is retrieved based on the business ID. All rule_ids in the rule_id_list list are retrieved, the rule configuration table is queried, and the rule_entry of all rules is obtained. Then, the business configuration is restored according to the rule reorganization algorithm. Finally, the business configuration is returned to the policy control server, and the process ends.

[0013] Compared with the prior art, the advantages of this invention are:

[0014] 1. The table entries of each management module are designed to be loosely coupled, allowing them to be developed and debugged independently.

[0015] 2. The dual-ID management mode has good scalability and is compatible with traditional single-ID rule management systems.

[0016] 3. Applicable to a variety of business scenarios, from simple to complex, enabling rule management to maintain flexibility and high efficiency in different business environments. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of existing technology business configuration scenarios;

[0018] Figure 2 This is a flowchart of the business issuance and processing.

[0019] Figure 3 This is a flowchart of the business deletion process;

[0020] Figure 4 This is a flowchart of the business query processing. Detailed Implementation

[0021] To make the purpose, principle and structure of the present invention clearer, the following description is provided in conjunction with the accompanying drawings and specific embodiments.

[0022] Example 1:

[0023] This invention provides a DPI splitting device rule management system, including: a service configuration table for maintaining service configuration and a rule configuration table for configuring rules, wherein the descriptions of each variable in the service configuration table and the rule configuration table are shown in the table below.

[0024] Table 1 is a description of the variables in the business configuration table.

[0025] Business configuration table content Meaning business_id A unique id used to index the business in the business configuration table, also called business id in this invention rule_id_list A list used to store the rule ids of the rules that the business is split into priority Used to represent the priority, when a flow hits multiple businesses at the same time, the flow is forwarded according to the business with the highest priority, the smaller the priority, the higher the priority action Used to store the forwarding behavior of the flow that hits the business

[0026] Table 2 is a description of each variable in the rule configuration table.

[0027] Rule configuration table content Meaning rule_id A unique id used to index the rule in the rule configuration table, also called rule id in this invention business_id_list A list used to store the business ids of all the businesses that the rule is split into effect_business_id The business id of the business with the highest priority in the business id list that actually takes effect rule_entry Used to store the matching content of the rule

[0028] Table 3 is a description of the variables in the regular hash table.

[0029] Rule hash table content Specific content Meaning Key rule_entry The part involved in the hash calculation, the matching content of the rule Value rule_id Rule id

[0030] The priority of a service, its forwarding behavior, and the rules into which the service is split are stored in the service configuration table (see Table 1); the specific matching content of the rule, which services were split into the rule, and the highest priority service ID among these services are stored in the rule configuration table (see Table 2).

[0031] Furthermore, to enable quick retrieval of rule IDs based on rule matching content, this invention introduces a third table—the rule hash table (see Table 3), where the key is the rule matching content and the value is the rule ID. The `rule_entry` is reused in both the rule configuration table and the rule hash table. To save storage space, `rule_entry` is allocated space only once, and both tables access the same address when retrieving `rule_entry`.

[0032] It also includes a policy control server. When the policy control server sends business configurations to the DPI distribution device via the RPC interface, it splits the business configurations into one or more rule configurations according to the splitting algorithm. It queries the rule hash table to see if these rules have been added before. If they have been added, the previous rule_id is reused. If they have not been added, a new rule_id is assigned, and the key-value mapping of the rule is added to the rule hash table. Then, the business-related configurations are filled into the business configuration table according to the business ID, and the split rule configurations are filled into the rule configuration table according to the rule_id. If a rule has been split from another business before, then the business_id_list and effect_business_id in the rule configuration table should be refreshed.

[0033] When the policy control server issues a delete service configuration operation via RPC interface, in this embodiment, it retrieves the service configuration table based on the issued service ID to obtain the `rule_id_list`. Then, it iterates through the rule IDs in `rule_id_list`, retrieves the rule configuration table based on the rule ID, removes the service ID to be deleted from `business_id_list`, and recalculates `effect_business_id`. If `business_id_list` is empty after removing the service ID to be deleted, the storage space corresponding to that `rule_id` in the rule configuration table is cleared, and the node with the rule `rule_entry` as the key is deleted from the rule hash table. After processing the rule-related table entries, the storage space corresponding to that service ID in the service configuration table is finally cleared.

[0034] When the policy control server sends a query request through the RPC interface, this embodiment retrieves the business configuration table based on the sent business ID to obtain the rule_id_list. Then, it iterates through the rule IDs in the rule_id_list one by one, retrieves the rule configuration table based on the rule ID, obtains the rule_entry for each rule, and then restores the business configuration according to the rule reorganization algorithm and returns it to the policy control server.

[0035] The management of the business configuration table, rule configuration table, and rule hash table are all in-memory operations, ensuring the speed at which business operations take effect. However, to ensure that the configuration can be recovered after a power outage and restart, this invention introduces a Redis database. The business configuration table, rule configuration table, and rule hash table are saved to disk through the Redis disk storage mechanism. When the device loses power and restarts, the software can restore the in-memory business configuration table, rule configuration table, and rule hash table through Redis. To ensure that Redis operations do not affect the speed at which business operations take effect, this invention adopts the following two strategies: 1. Only at the end of each business add / delete operation, only the modified entries in the tables are saved to Redis disk, and the Redis append operation is used, requiring only one inter-process communication; 2. Redis write operations are performed asynchronously, which can greatly reduce the communication latency caused by inter-process communication.

[0036] Example 2:

[0037] This embodiment provides a method for managing DPI splitting device rules using the management system described in Embodiment 1, as follows:

[0038] I. Business Notice Issuance:

[0039] The service configuration issued by the policy control server includes three elements: service matching content, priority information, and forwarding action information. The service matching content is further transformed at the DPI (Driving Point Inversion) device into multiple internal rules that match different packet characteristics. For the specific process of the DPI device management system handling service issuance, please refer to [link to documentation]. Figure 2 .

[0040] After the business configuration is distributed from the policy control server to the DPI distribution device, the management system first performs parameter validity checks, including the validity of the business ID, the validity of the business matching fields, and the validity of the priority and action parameters. If the parameter validity check fails, the corresponding error code is directly returned to the policy control server. Subsequently, using the business ID as an index, storage space is allocated in the corresponding position in the business configuration table, and the priority and action information from the business configuration are directly filled into the table. Then, according to the business splitting algorithm, the business matching content is split into multiple internal rules, and the split rule content is retrieved sequentially and the following operations are performed:

[0041] After retrieving the rule matching content (rule_entry), the rule hash table is queried using the rule_entry group key to see if any other business has previously split this internal rule. If the hash table returns a result, it means that it has been added before. Here, a priority issue is involved because the hardware device only allows one addition for the same rule_entry. If multiple rules need to be added, the management system needs to help select the rule with the highest priority and write it into the hardware.

[0042] Here, we first discuss the scenario where the hash table query reveals that this rule hasn't been added before. If the rule hasn't been added, the management system first retrieves a free `rule_id` from the `rule_id` resource pool and allocates it to this rule. Then, using this `rule_id` as an index, it allocates storage space in the corresponding position in the rule configuration table, directly appends the business ID to the `business_id_list`, and assigns the business ID to `effect_business_id`. Next, it allocates storage space for `rule_entry`, fills the memory address into the `rule_entry` field of the rule configuration table, and then inserts it into the rule hash table using this `rule_entry` memory as the key and `rule_id` as the value. Here, `rule_entry` only uses one storage space, saving some memory. Then, `effect_business_id`, which is actually the business ID added this time, is retrieved from the priority and action information in the business configuration table and sent to the hardware along with the `rule_entry` of this rule. The reason for doing this is to allow this logic to be reused in other scenarios discussed later.

[0043] Next, let's discuss the scenario where the hash table reveals that this rule has been added before. In this scenario, this invention directly retrieves the previously added and assigned `rule_id` from the hash table's hit results. Then, using this `rule_id` as an index, it finds the corresponding storage space in the rule configuration table and appends the business ID to the `business_id_list`. At this point, the `business_id_list` will definitely contain at least two business IDs. Therefore, there is a priority issue here. The management system needs to select the business ID with the highest priority and fill it into `effect_business_id`. Usually, the priority is determined based on the `priority` field in the business configuration. However, the policy control server sometimes requires users to determine the priority of businesses based on other criteria, such as the order in which businesses are added or the business type. The implementation of this priority determination is an independent component with mode selection, which will not be discussed in detail here. After determining the priority, if the highest priority business ID (effect_business_id) of all the businesses that were split into this rule changes, then the logic for issuing the rule to the hardware mentioned above needs to be reused to refresh the priority and action information corresponding to effect_business_id into the hardware, ensuring that traffic that is hit is forwarded according to the forwarding behavior of the highest priority business; if effect_business_id has not changed, then there is no need to refresh the hardware configuration, and traffic that hits this rule will still be forwarded according to the previous forwarding behavior.

[0044] After completing the above processing flow, the relevant operations for this splitting rule in the rule configuration table are finished. Next, the rule_id of this rule needs to be appended to the rule_id_list in the business configuration table, so that the system can retrieve splitting rules by business ID. Then, it is determined whether the currently processed splitting rule is the last one among all splitting rules. If it is not the last one, the matching content of the next rule is retrieved, and the above steps are repeated until all splitting rules have been traversed.

[0045] After traversing all the splitting rules, it is necessary to save the business configuration table, rule configuration table, and rule hash table to disk. In order to avoid the loss of configuration after the device is powered off and restarted, after saving, the management system can read the data from the hard drive to restore the memory of the business configuration table, rule configuration table, and rule hash table after restarting.

[0046] This invention uses a Redis database and its automatic save function to store data. To avoid frequent Redis operations affecting the business delivery rate, this embodiment adopts the following two strategies: 1. Only at the end of each business add / delete operation, only the modified points in the table entries are saved to Redis, and the Redis append operation is used to perform only one inter-process communication; 2. Redis write operations are delivered asynchronously, which can greatly reduce the communication latency caused by inter-process communication.

[0047] Finally, the process ends when the processing result is returned to the policy control server.

[0048] II. Service Deletion

[0049] After receiving a request from the policy control server to delete a service configuration, the DPI splitter manages the system's specific processing flow. (See [link to relevant documentation]). Figure 3 .

[0050] Similar to the business deployment process, upon receiving a business deletion request, the management system first performs parameter validity verification, primarily checking the validity of the business ID. If the parameter validity verification fails, the corresponding error code is directly returned to the policy control server. Subsequently, this invention uses the business ID as an index to find the corresponding storage location in the business configuration table, retrieves the rule_id_list list from it, and then iterates through the rule_ids in the list, performing the following operations:

[0051] Look up the rule configuration table based on rule_id, retrieve the business_id_list list from it, and determine if there is only one id in the list. That is the business id that needs to be deleted.

[0052] If the `business_id_list` contains only one ID, then this rule can be deleted directly. In this embodiment, the management memory needs to be cleared first, which requires the following operations: delete the node with the `rule_entry` of this rule as the key in the rule hash table; release the memory space allocated for the `rule_entry` of this rule; release the storage space of this rule in the rule configuration table. Then, in this embodiment, the rule needs to be deleted in hardware.

[0053] If multiple IDs exist in the business_id_list, it means that this rule has been split from multiple business configurations. In this embodiment, the business IDs that need to be deleted are first removed from the business_id_list. Then, based on the new business_id_list and the priority calculation algorithm mentioned earlier, the highest priority business ID is calculated from these business IDs and filled into effect_business_id. If effect_business_id has changed, then in this embodiment, the priority and action information of the new highest priority business ID needs to be refreshed to the hardware. If effect_business_id has not changed, there is no need to update the hardware configuration. This part of the logic is the same logic reused when effect_business_id changes during business deployment.

[0054] After processing this rule, in this embodiment, the rule_id of this rule needs to be removed from the rule_id_list in the business configuration table. Then, it is determined whether there are any remaining rule_ids in the rule_id_list. If there are, the next rule_id is retrieved, and the above steps are repeated until the rule_id_list is empty.

[0055] After processing all rules, in this embodiment, the storage space allocated to the business ID in the business configuration table can be released. Then, modifications to the business configuration table, rule configuration table, and rule hash table are saved to Redis. Finally, the process ends by returning the processing result to the policy control server.

[0056] III. Business Inquiry

[0057] After receiving a request from the policy control server to query service configuration, the DPI splitting device manages the specific processing flow of the system. (See [link to relevant documentation]). Figure 4 .

[0058] The process begins with parameter validity verification. After successful verification, the `rule_id_list` list is retrieved from the business configuration table based on the business ID. All `rule_id` values ​​in the `rule_id_list` are then retrieved, and the `rule_entry` for each rule is obtained from the rule configuration table. Next, the business configuration is restored according to the rule reorganization algorithm, which is a separate function related to the business logic. Finally, the business configuration is returned to the policy control server, and the process ends.

[0059] The above description is merely a specific embodiment of the invention, but the scope of protection of the invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the technical scope disclosed in the invention, based on the technical solutions and novel concepts of the invention, should be covered within the scope of protection of the invention.

Claims

1. A DPI splitting device rule management system, characterized in that, include: The service configuration table stores the service's priority, forwarding behavior, and the rules by which the service is broken down. Each service configuration item has a unique service ID. The rule configuration table stores the specific matching content of the rule, the corresponding business segmentation of the rule, and the highest priority business ID. Each rule configuration item has a unique rule ID. The rule hash table quickly retrieves the rule ID by hashing the rule matching content. The key of the rule hash table is the rule matching content, and the value is the rule ID. The rule_entry is reused in the rule configuration table and the rule hash table. The rule_entry is allocated space only once, and the two tables access the same address when retrieving the rule_entry. Policy control server, When the policy control server sends service configuration to the DPI splitting device through the remote procedure call (RPC) interface, the DPI splitting device splits the service configuration into one or more rule configurations according to the splitting algorithm. During the splitting process, the DPI splitting device checks whether the rule already exists by querying the rule hash table: If a rule already exists, the corresponding rule ID will be reused; If the rule does not exist, a new rule ID is assigned, and the key-value mapping for that rule is added to the rule hash table; Fill the business-related configurations into the business configuration table by business ID, and fill the split rule configurations into the rule configuration table by rule ID. Refresh the business ID list and valid business IDs in the rule configuration table as needed. When the policy control server issues a delete service configuration operation via the RPC interface, the DPI splitter device retrieves the service configuration table based on the issued service ID, obtains the corresponding rule ID list, and iterates through the rule ID list one by one: Retrieve the rule configuration table based on the rule ID, remove the business ID that needs to be deleted from the business ID list, and recalculate the valid business IDs; If the list of business IDs is empty after removal, clear the storage space corresponding to the rule ID in the rule configuration table, and delete the node with the rule_entry as the key in the rule hash table. Finally, clear the storage space corresponding to the business ID in the business configuration table; When the policy control server sends a query request through the RPC interface, the DPI splitting device retrieves the service configuration table based on the service ID, obtains the rule ID list, and retrieves the rule configuration table based on the rule ID to obtain the entries of each rule. Then, it restores the service configuration according to the rule reorganization algorithm and returns it to the policy control server. The Redis database is used to persistently store the contents of the business configuration table, rule configuration table, and rule hash table to ensure that the configuration in memory can be restored after the device loses power and restarts. The write operations of the Redis database are asynchronous to reduce communication latency.

2. A method for managing DPI splitting device rules using the management system described in claim 1, characterized in that, include Service delivery method: S1. After the service configuration is distributed from the policy control server to our DPI distribution device, the management system must first verify the validity of the parameters; S2. After the verification is passed, allocate storage space in the corresponding position in the business configuration table, directly fill the priority and action information in the business configuration into the table, and then split the business matching content into multiple internal rules according to the business splitting algorithm. S3. After retrieving the rule matching content rule_entry, use the rule_entry group key to query the rule hash table to see if other businesses have previously split this internal rule. If the hash table returns a result, it means that it has been added before. Then, the management system selects the rule with the highest priority and writes it into the hardware. S4. If the rule has not been added before, the management system will first take an idle rule_id from the rule_id resource pool and allocate it to this rule. Then, using this rule_id as an index, it will allocate storage space in the corresponding position in the rule configuration table, directly append the business ID to the business_id_list list, and then assign the business ID to effect_business_id. Next, it will request a storage space for rule_entry, fill the memory address into the rule_entry field of the rule configuration table, and then insert it into the rule hash table with the memory of this rule_entry as the key and rule_id as the value. Here, rule_entry only uses one storage space. Then, the priority and action information of the business ID added this time will be retrieved from the business configuration table and sent to the hardware together with the rule_entry of this rule. S5. If the hash table shows that this rule has been added before, retrieve the previously added and assigned rule_id directly from the hash table's hit results. Then, using this rule_id as an index, find the corresponding storage space in the rule configuration table and append the business ID to the business_id_list. At this point, the business_id_list contains at least two business IDs. The management system selects the business ID with the highest priority and fills it into effect_business_id. After determining the priority, if the effect_business_id of all the highest-priority businesses that have been split into this rule has changed, then the logic for rule distribution to hardware mentioned above needs to be reused. The priority and action information corresponding to effect_business_id should be flushed to the hardware to ensure that traffic is forwarded according to the forwarding behavior of the highest-priority business after a hit. If effect_business_id has not changed, there is no need to refresh the hardware configuration, and traffic that hits this rule will still be forwarded according to the previous forwarding behavior. S6. The relevant operations for this splitting rule in the rule configuration table have been completed. Next, the rule_id of this rule needs to be appended to the rule_id_list in the business configuration table. This is used to manage the system to retrieve splitting rules by business ID. Then, it is determined whether the currently processed splitting rule is the last one among all splitting rules. If it is not the last one, the matching content of the next rule is taken, and the above steps are repeated until all splitting rules have been traversed.

3. The DPI splitting device rule management method as described in claim 2, characterized in that, Also includes Service deletion method: S1. Look up the rule configuration table based on rule_id, retrieve the business_id_list list from it, and determine whether there is only one id in the list, which is the business id that needs to be deleted; S2. If the business_id_list list contains only one id, then this rule can be deleted directly. First, clear the management memory, delete the node with the rule_entry as the key in the rule hash table, release the memory space allocated for the rule_entry, release the storage space of the rule in the rule configuration table, and then delete the rule in the hardware. S3. If there are multiple IDs in the business_id_list, it means that this rule has been split from multiple business configurations. First, remove the business IDs that need to be deleted from the business_id_list. Then, according to the new business_id_list, calculate the highest priority business ID among these business IDs and fill it into effect_business_id. If effect_business_id has changed, refresh the priority and action information of the new highest priority business ID to the hardware. If effect_business_id has not changed, there is no need to update the hardware configuration. This part of the logic is the same logic reused when effect_business_id changes during business deployment. S4. After processing this rule, remove the rule_id from the rule_id_list in the business configuration table. Then check if there are any remaining rule_ids in the rule_id_list. If there are, take the next rule_id and repeat the above steps until the rule_id_list is empty.

4. The DPI splitting device rule management method as described in claim 2, characterized in that, Also includes The business query method first involves validating the parameters. After successful validation, the rule_id_list list is retrieved from the business configuration table based on the business ID. All rule_ids in the rule_id_list list are then retrieved. The rule configuration table is queried to obtain the rule_entry for all rules. The algorithm is then reorganized according to the rules to restore the business configuration. Finally, the business configuration is returned to the policy control server, and the process ends.

Images