Network communication device deployment method in SDN network and network communication device

Abstract

The application relates to the technical field of network communication, in particular to a network communication device deployment method in an SDN network and a network communication device. The method comprises the following steps: a controller detects the flow table capacity of an access switch, and establishes a unique identifier and a capacity archive; a service flow table request from an upper layer is analyzed, matching fields and action instructions are extracted, and the same action flow table is aggregated according to user groups / service categories, priority of the aggregated flow table is allocated, the usage rate of the flow table is monitored in real time, when the threshold is reached, the flow table with low priority and the latest missed flow table is unloaded and backed up, when the corresponding traffic is detected, the flow table is retransmitted and the current lowest level flow table is unloaded, the aggregated flow table is sent to a target switch and an acknowledgement is received, if the capacity is insufficient, dynamic scheduling is carried out, and after the success, relevant information is recorded. The process reduces the number of flow tables, guarantees core services, avoids flow table exhaustion, and realizes efficient service support under limited capacity.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, specifically to a method for deploying network communication equipment in an SDN network and the network communication equipment itself. Background Technology

[0002] In SDN network communication, some low-end physical switches or virtual switches, such as the lightweight version of OVS, have limited flow table capacity, such as only supporting 10,000 flow tables. If the controller issues a large number of fine-grained flow tables according to business needs, such as one flow table per user / one flow table, it will quickly exhaust the device's flow table resources, resulting in new flow tables being unable to be written, and subsequent business traffic being discarded due to "no matching flow table". Summary of the Invention

[0003] The purpose of this invention is to provide a method for deploying network communication equipment in an SDN network and the network communication equipment itself, so as to solve the problems mentioned in the background art.

[0004] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0005] The first aspect is the deployment method of network communication equipment in SDN networks, including the following steps:

[0006] The controller sends flow table capacity probe commands to all access switches to obtain the maximum number of flow table entries and the number of currently available entries for each device, and establishes and stores a unique identifier and flow table capacity file for each switch.

[0007] The controller parses the flow table requests from the upper-layer business and extracts matching fields and action instructions;

[0008] Aggregate flow tables containing unique user identifiers by user group, aggregate flow tables containing business type identifiers by business category, and merge flow tables with the same action into a single flow table with a group identifier.

[0009] The controller assigns priorities to the aggregated flow tables;

[0010] The controller monitors the flow table utilization of the switch in real time and triggers optimization when the total capacity threshold is reached.

[0011] Unload the lowest-level flow table that has not been hit recently according to priority and back up its matching characteristics and actions; when the corresponding traffic of the unloaded flow table is detected, reissue the flow table and unload the current lowest-level flow table.

[0012] The controller sends the aggregated flow table to the target switch and receives the write confirmation returned by the device;

[0013] If the write operation fails due to insufficient capacity, dynamic scheduling is triggered immediately; after a successful write operation, the flow table issuance time, priority, and associated business information are recorded.

[0014] Furthermore, the controller sends a flow table capacity probe command to all access switches to obtain the maximum number of flow table entries and the number of currently available entries for each device. It then establishes and stores a unique identifier and flow table capacity file for each switch. Specifically, the controller generates a flow table capacity probe command and broadcasts it to all access switches via a secure channel. Upon receiving the command, the switch queries and counts the maximum and available entries for each type of flow table, and returns an encrypted data packet containing its own identifier, device model, and flow table capacity data. After verifying the data integrity, the controller establishes and stores a flow table capacity file based on the switch identifier and flow table capacity data, while simultaneously setting up an update mechanism to dynamically refresh the file.

[0015] Furthermore, the controller parses the flow table distribution request from the upper-layer service, extracts matching fields and action instructions. Specifically, the controller receives the flow table distribution request from the upper-layer service through a preset northbound interface; first, it performs a validity check on the request, and if the check fails, it rejects the request; if the check passes, it parses the core content of the flow table; it extracts the set of matching fields and the sequence of action instructions; it synchronously records the service priority parameters and initially determines the category of the flow table request; and it temporarily stores the parsing results.

[0016] Furthermore, the process of aggregating flow tables containing unique user identifiers by user group and flow tables containing service type identifiers by service category, and merging flow tables with the same action into a single flow table with a group identifier, specifically involves the controller loading a preset user group mapping table and a service category classification table; for flow tables containing unique user identifiers, extracting the identifier to match the user group to which it belongs, merging flow tables with consistent action instructions within the same group into a single flow table with a user group identifier and retaining common matching fields; for flow tables containing service type identifiers, extracting the identifier to determine the service category to which it belongs, merging flow tables with consistent action instructions within the same category into a single flow table with a service category identifier and retaining common network layer matching fields; recording the mapping relationship between the original flow table and the aggregated flow table during aggregation and storing it in the flow table aggregation mapping library; after aggregation, verifying the validity of the aggregated flow table, marking it as pending issuance if it passes, and re-analyzing the aggregation rules if it fails.

[0017] Furthermore, the controller assigns priorities to the aggregated flow tables. Specifically, the controller first extracts the business priority parameters from the flow table issuance requests of the upper-layer business system as a basic reference; it constructs a multi-level priority determination model based on the aggregated flow table type and associated business attributes; it assigns aggregated flow tables associated with core businesses to the highest priority; ordinary business flow tables to the medium priority; and aggregated flow tables for temporary businesses and non-basic functional parts of general flow tables to the lowest priority; if an aggregated flow table is formed by merging multiple original flow tables, the highest business priority is taken as the benchmark; after the allocation is completed, the flow table priority is bound to the entry, and stored in the flow table information database along with the content and associated business identifiers and synchronized to the dynamic management module; at the same time, a priority evaluation cycle is set, and the priority is calibrated in each cycle according to the actual hit frequency of the flow table and changes in business importance.

[0018] Furthermore, the controller monitors the flow table usage rate of the switch in real time and triggers optimization when the total capacity threshold is reached. Specifically, the controller periodically receives flow table usage data from the switch through a real-time status synchronization channel and sets up immediate reporting conditions to handle sudden changes in usage rate; it parses the data and calculates the usage rate according to the flow table type; when the usage rate reaches a preset threshold, it sends an optimization trigger signal to the dynamic management module along with the switch identifier, flow table type, and usage data; the dynamic management module retrieves the flow table capacity file and priority data to sort the flow tables, filters low-priority candidate unloaded flow tables that have not been recently hit, excludes unloadable basic flow tables, and determines unloadable entries; the controller records the trigger time, usage rate, and reason in the monitoring log database.

[0019] Furthermore, the process involves unloading the lowest-level flow table that has recently been missed and backing up its matching features and actions. When traffic corresponding to the unloaded flow table is detected, the flow table is reissued and the current lowest-level flow table is unloaded. Specifically, after the controller's dynamic management module determines the candidate unloadable flow table, it checks its priority identifier and recent hit time. If it confirms that the flow table is the current lowest priority and meets the "recently missed" duration condition, it excludes flow tables that cannot be unloaded to ensure basic network connectivity. For flow tables that are confirmed to be unloadable, the complete matching feature set and action instruction sequence are extracted, along with the flow table's unique identifier, original priority, associated service identifier, and unloading time. The data is encrypted and stored in the flow table backup database. The controller continuously receives traffic data and unmatched packet characteristics reported by the switch through the traffic monitoring channel. When the traffic characteristics are found to match the characteristics of the backed-up unloaded flow table, it is determined to be the corresponding traffic. The dynamic management module retrieves the flow table information, first checks the flow table utilization rate of the switch, and if there is available capacity, it directly re-issues the flow table. If there is no available capacity, it filters the lowest priority flow table that has not been hit recently, repeatedly unloads the backup to release resources, and then issues the flow table again. After successful re-issuance, the flow table status is updated to "active" and the most recent issuance time is updated. At the same time, the newly unloaded flow table information is added to the backup database to ensure the continuity of flow table management and data integrity.

[0020] Furthermore, the controller sends aggregated flow tables to the target switch and receives write confirmations from the device. Specifically, the controller retrieves the aggregated flow table data to be sent from the flow table information database, determines the target switch based on the flow table capacity file, and sends a sending instruction containing the controller ID, timestamp, and verification information through a secure channel. The switch verifies the instruction; if successful, it writes the data into the flow table and records it; otherwise, it discards the data and returns a response. The switch encrypts and sends a confirmation packet containing its own identifier and the writing result. The controller verifies the confirmation packet; if successful, it updates and records the flow table status; if unsuccessful, it temporarily stores the record to provide a basis for subsequent dynamic flow table management.

[0021] Furthermore, if the write operation fails due to insufficient capacity, dynamic scheduling is immediately triggered. Specifically, after the controller receives the switch flow table write failure confirmation packet, it parses and confirms that the failure type is insufficient capacity. It then sends a scheduling trigger signal to the dynamic flow table management module, along with the aggregated flow table identifier, the target switch identifier, and the flow table usage status. The dynamic management module retrieves data, filters the lowest-priority and most recently unhitable unloadable flow tables according to priority, extracts and backs up the information, and sends an unload command to the switch. After the resources are released, the failed aggregated flow table is resent. If it still fails, the filtering and unloading process is repeated. The entire process, including the trigger time, unloading information, and resentment results, is recorded and stored in the monitoring log database.

[0022] Furthermore, after successful writing, the flow table issuance time, priority, and associated service information are recorded. Specifically, after successful flow table writing, the controller receives confirmation information from the switch, extracts the unique identifier of the aggregated flow table, issuance time, priority, associated service information, unique identifier of the target switch, flow table type attribute, and original flow table associated records; this information is structured and processed, and the flow table status in the flow table information database is synchronously updated to "issued and active," and stored as an independent log in the monitoring log database; this provides support for subsequent flow table statistical analysis, priority adjustment, and traceability of the relationship between services and flow tables, ensuring that key information is traceable.

[0023] Secondly, a network communication device is deployed using the aforementioned network communication device deployment method in an SDN network.

[0024] Compared with existing technologies, this invention has the following beneficial effects: By aggregating flow tables, this invention groups flow tables containing unique user identifiers by user group and flow tables containing service type identifiers by service category, merging flow tables with the same actions into a single flow table with a group identifier. This significantly reduces the actual number of flow tables issued, directly alleviating flow table capacity pressure. Through priority allocation, core service flow tables receive the highest priority, with ordinary and temporary flow tables decreasing in priority, ensuring that critical service flow tables are not overwhelmed and preventing core service traffic from being discarded. By monitoring flow table usage in real time, when a threshold is reached, low-priority flow tables that have not been recently hit are unloaded and backed up. Corresponding traffic is then retransmitted upon detection, while resources are dynamically scheduled and released to ensure that new flow tables can be written. Furthermore, by establishing a flow table capacity profile and updating device status in real time, this invention accurately matches resource allocation, preventing the exhaustion of flow table resources throughout the process, ensuring the normal forwarding of new service traffic, and achieving efficient service support under limited flow table capacity. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the deployment method of network communication devices in the SDN network of the present invention. Detailed Implementation

[0026] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments and accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] This application discloses a method for deploying network communication devices in an SDN network, such as... Figure 1 The steps include:

[0028] S100. The controller sends a flow table capacity probe command to all access switches to obtain the maximum number of flow table entries and the number of currently available entries for each device, and establishes and stores a unique identifier and flow table capacity file for each switch.

[0029] S200. The controller parses the flow table requests from the upper-layer business and extracts matching fields and action instructions;

[0030] S300. Aggregate flow tables containing unique user identifiers by user group, aggregate flow tables containing service type identifiers by service category, and merge flow tables with the same action into a single flow table with a group identifier.

[0031] S400. The controller assigns priorities to the aggregated flow tables;

[0032] The S500 controller monitors the flow table usage of the switch in real time and triggers optimization when the total capacity threshold is reached.

[0033] S600. Unload the lowest-level flow table that was recently not hit according to priority and back up its matching characteristics and actions; when the corresponding traffic of the unloaded flow table is detected, reissue the flow table and unload the current lowest-level flow table.

[0034] The S700 controller sends the aggregated flow table to the target switch and receives the write confirmation returned by the device.

[0035] S800. If the write operation fails due to insufficient capacity, dynamic scheduling is triggered immediately; after the write operation is successful, the flow table issuance time, priority, and associated business information are recorded.

[0036] In step S100, the controller sends a flow table capacity probe command to all access switches to obtain the maximum number of flow table entries and the number of currently available entries for each device. It then establishes and stores a unique identifier and flow table capacity file for each switch. Specifically, the flow table capacity probe command generated by the controller includes a command type identifier, a unique controller ID, and a timestamp, and is broadcast to all access switches via a secure channel. Upon receiving the command, the access switches immediately call their own hardware interfaces to query and count the maximum number of flow table entries corresponding to different flow table types (such as IPv4 forwarding flow tables, ACL flow tables, etc.), and simultaneously calculate the number of currently used entries and the remaining entries for each type of flow table. The remaining number of available entries is determined, and then a data packet containing its own hardware serial number, MAC address, device model, maximum number of entries for each type of flow table, current number of available entries, and response timestamp is encrypted and returned to the controller. After receiving the response data packet, the controller first verifies the data integrity through checksum, then extracts the hardware serial number and MAC address to generate a unique identifier for the switch. Based on the device model, flow table capacity data for each type, and the received timestamp, a flow table capacity file is created and stored in a local distributed database. At the same time, a timed update is set, and probe commands are repeatedly sent at preset intervals to dynamically refresh the file information, ensuring the real-time performance and accuracy of the flow table capacity data.

[0037] In S200, the controller parses the flow table distribution request from the upper-layer service and extracts matching fields and action instructions. Specifically, the controller receives the flow table distribution request submitted by the upper-layer service system through a preset northbound interface. The request data packet contains the service identifier, request timestamp, security verification information, and the core content of the flow table. The controller first verifies the validity of the request by verifying the authorization and data integrity of the request source through the security verification information. If the verification fails, the controller refuses to process the request and returns an error code. After the verification is successful, the controller parses the core content of the flow table and extracts the matching field set and action instruction sequence. The matching field set includes, but is not limited to, network layer fields such as source MAC address, destination MAC address, source IP address, destination IP address, port number, protocol type, and VLAN tag, as well as service layer fields such as user unique identifier (e.g., user account ID, terminal device unique number) and service type identifier (e.g., service category code, application service ID). The action instruction sequence includes, but is not limited to, operation instructions such as packet forwarding port, traffic shaping parameters, QoS marking, packet modification (e.g., TTL adjustment, VLAN tag change), and dropping.

[0038] During the parsing process, the controller synchronously records the business priority parameters (specified by the upper-layer business system) corresponding to each flow table request, and preliminarily determines the category of the flow table request based on the existence of the extracted user unique identifier and business type identifier fields, providing basic data support for subsequent flow table aggregation processing. At the same time, the parsing results are temporarily stored in the flow table request cache area, waiting for further processing.

[0039] In S300, flow tables containing unique user identifiers are aggregated by user group, and flow tables containing service type identifiers are aggregated by service category. Flow tables with the same action are merged into a single flow table with a group identifier. Specifically, in implementation, the controller first loads a preset user group mapping table and a service category classification table. The user group mapping table records the correspondence between unique user identifiers and user group identifiers (such as user groups divided by department, permission level, or region). The service category classification table defines the affiliation between service type identifiers and service categories (such as classifying video calls and voice calls as real-time communication, and file downloads and web browsing as data transmission).

[0040] For flow tables containing a unique user identifier, the unique user identifier is extracted from the flow table, and its corresponding user group identifier is matched through the user group mapping table. Then, the action instruction sequence of flow tables within the same user group is compared. If the action instructions are completely consistent (including all operations such as forwarding port, QoS tagging, and packet modification), these flow tables are merged into a single flow table. The matching field of the merged flow table is replaced with the user group identifier, and other common matching fields in the original flow table other than the unique user identifier (such as protocol type, VLAN tag, etc.) are retained.

[0041] For flow tables containing business type identifiers, the business type identifier is extracted, and its business category is determined based on the business category classification table. The action instruction sequence of flow tables within the same business category is compared. If the action instructions are completely identical, they are merged into a single flow table, and the matching field is updated to the business category identifier. Simultaneously, the common network layer matching field in the original flow table is retained. During aggregation, the controller records the mapping relationship between the original flow table and the aggregated flow table, storing it in the flow table aggregation mapping library for subsequent flow table hit analysis and possible split recovery. After aggregation is complete, the controller performs validity verification on the newly generated aggregated flow table, simulating matching tests to ensure it covers all business scenarios of the original flow table. If the verification passes, it is marked as a flow table to be issued; otherwise, the aggregation rules are re-analyzed.

[0042] In S400, the controller assigns priorities to the aggregated flow tables. Specifically, in implementation, the controller first extracts the business priority parameters carried in the flow table issuance request from the upper-layer business system, and uses this as the basic reference for flow table priority allocation.

[0043] Based on the type of the aggregated flow table and the associated business attributes, a multi-level priority determination model is constructed: For aggregated flow tables associated with core businesses (such as real-time transactions and critical communications), regardless of whether they are user group aggregations or business category aggregations, they are all assigned to the highest priority range (1-100). Among them, basic flow tables that directly affect the availability of core businesses (such as core server access flow tables) are assigned higher priority values ​​of 1-50.

[0044] For aggregated flow tables of routine business (such as daily office data transmission), they are assigned to the medium priority range (101-500), further subdivided into 101-300 (high-demand routine business) and 301-500 (general routine business) based on the importance of the business to the user. For aggregated flow tables of temporary business (such as temporary file sharing, short-term testing business) and the non-basic functional parts of general flow tables, they are assigned to the lowest priority range (501-1000).

[0045] During the allocation process, the controller synchronizes the original flow table information in the associated flow table aggregation mapping library. If the aggregated flow table is formed by merging multiple different original business flow tables, the highest business priority among them is taken as the base priority of the aggregated flow table.

[0046] After allocation is completed, a dynamic management module is pre-configured. The controller binds flow table priorities to flow table entries, storing them along with flow table content, associated service identifiers, and other information in the flow table information database. This information is then synchronously updated to the dynamic management module, serving as the basis for subsequent flow table monitoring, unloading, and re-issuance. Simultaneously, an initial priority evaluation cycle is set. Every 24 hours, the priorities are initially calibrated based on changes in the actual hit frequency of flow tables and the importance of the business, ensuring that priority allocation matches actual business needs.

[0047] In the S500, the controller monitors the flow table utilization rate of the switches in real time and triggers optimization when the total capacity threshold is reached. Specifically, the controller periodically receives flow table utilization data reported by each switch through a real-time status synchronization channel established with the switches. Simultaneously, it sets immediate reporting trigger conditions. When the flow table utilization rate suddenly changes, the switch actively pushes an update. The received data includes the number of used entries, the maximum number of entries, and the current status information of each flow table type, such as the number of hits and the most recent hit time. The controller parses the received data in real time and calculates the utilization rate (the ratio of used entries to the maximum number of entries) for each flow table type. When the utilization rate of any type of flow table reaches a preset threshold, it immediately sends an optimization trigger signal to the dynamic management module, along with the... Upon receiving a signal containing the switch's unique identifier, flow table type, and current detailed usage data, the dynamic management module first retrieves the switch's flow table capacity file and priority data from the flow table information database. It then sorts all currently active flow tables from lowest to highest priority, further sorting them by their most recent hit time from earliest to latest within the same priority flow table. The module then selects the lowest priority flow tables that have not been recently hit as candidate unloadable objects. Simultaneously, it checks whether these flow tables belong to non-unloadable basic function flow tables; if so, it skips them and checks the next level of candidates until a safe unloadable flow table entry is determined. Throughout this process, the controller synchronously records the trigger time, flow table usage rate at the time of triggering, and the trigger reason, storing these records in the monitoring log database to provide data support for subsequent adjustments to flow table management strategies.

[0048] In S600, the lowest-level flow table that has recently been missed is unloaded according to priority, and its matching characteristics and actions are backed up. When the traffic corresponding to the unloaded flow table is detected, the flow table is reissued and the current lowest-level flow table is unloaded. Specifically, after determining the candidate unloaded flow tables, the dynamic management module of the controller first checks the priority identifier and the recent hit time record of these flow tables to confirm that they all belong to the current lowest priority range and meet the preset "recent miss" duration condition. At the same time, flow tables that cannot be unloaded to ensure basic network connectivity are excluded to avoid affecting core network functions.

[0049] For flow tables that are confirmed to be unloadable, the dynamic management module extracts their complete set of matching features, including network layer fields such as source IP address, destination IP address, port number, and protocol type; service layer fields such as user group identifier and service category identifier; and corresponding action instruction sequences such as forwarding port, QoS flag, and packet modification operation. This information, along with the flow table's unique identifier, original priority, associated service identifier, and unloading time, is encrypted and stored in the flow table backup database to ensure complete recovery in the future.

[0050] The controller continuously receives traffic statistics and packet feature information of unmatched flow tables reported by the switch through a traffic monitoring channel that interacts with the switch in real time. When it identifies that the feature of a certain type of traffic is completely consistent with the matching feature of an offloaded flow table in the flow table backup database, it determines that the traffic corresponding to the offloaded flow table has been detected.

[0051] At this point, the dynamic management module immediately retrieves the complete information of the flow table from the backup database. It first checks the current flow table utilization rate of the target switch. If there is available capacity, the flow table is directly reissued to the switch. If the flow table utilization rate has reached the threshold and there is no available capacity, the flow table is sorted according to its current priority, and the flow table with the lowest priority and the most recently missed is selected. The aforementioned unloading and backup process is repeated to release the flow table resources before the flow table corresponding to the detected traffic is reissued.

[0052] After the flow table is successfully reissued, the dynamic management module updates the status of the flow table in the flow table information database to "active" and updates its most recent issuance time. At the same time, it supplements the information of the newly uninstalled flow table into the backup database to ensure the continuity of flow table management and data integrity.

[0053] The proposed "unload the lowest-level flow table that has recently been missed and back up its matching features and actions according to priority; when the corresponding traffic of the unloaded flow table is detected, reissue the flow table and unload the current lowest-level flow table" makes flow table unloading decisions based on "priority + recent miss time". Although it can be applied in practice, it also has the defects of being single-dimensional and static, and it is difficult to adapt to the dynamic fluctuations of network traffic in the long run.

[0054] Therefore, this application proposes a dynamic unloading and retransmission method based on flow table resource utility entropy. It introduces "flow table resource utility entropy," integrating information entropy theory with the real-time attributes of flow tables (such as hit stability, business dependency, and resource utilization efficiency) to construct a quantitative "necessity" evaluation index. The lower the resource utility entropy value, the more stable the resource utilization of the flow table and the stronger the business dependency, and the more it should be retained; the higher the entropy value, the more redundant the flow table, and the more preferentially it should be unloaded.

[0055] The dynamic offloading and retransmission method based on flow table resource utility entropy includes the following steps:

[0056] For each active flow table in the switch The following data is collected in real time:

[0057] Flow table In the sliding window (default The hit frequency sequence (unit: times / s) within the range reflects the hit stability;

[0058] Flow table The business dependency (calculated by the upper-layer system based on the number of business links associated with this flow table, or by using the number of active logical links, such as the core business domain). ordinary domain Temporary domain );

[0059] Flow table Idle time (current time - most recent hit time, unit: s);

[0060] Unremovable flag : Represents the basic connectivity flow table (cannot be unloaded). This indicates that it can be uninstalled;

[0061] Perform flow table resource utility entropy calculation, flow table resource utility entropy Calculated using the following formula (the lower the entropy value, the more necessary the flow table):

[0062] ;

[0063] Parameter meaning:

[0064] The dimensionless normalized information entropy corresponding to the information entropy of the hit frequency sequence is calculated using the following formula: , Let M be the information entropy of the hit frequency sequence, where M is the number of sampling points within the sliding window. ( For the first (Frequency percentage of each sampling point).

[0065] The smaller the value, the more stable the hit frequency (e.g., periodic flow), and the more important the flow table. This is a flow table resource occupancy duration coefficient, which directly reflects "the time required to occupy flow table resources to process a unit of traffic". ;

[0066] Flow table Entry size (unit: Byte); Flow table Traffic processed per unit time (unit: Byte / s); Unit: seconds (s), Physical meaning: Processing 1 byte of traffic requires occupying a flow table. seconds; the larger the value, the lower the flow table resource efficiency; max(C): the total number of active flow tables on the current switch. The maximum value is updated in real time every 10 seconds to ensure... And it matches the current equipment resources.

[0067] : Normalized value of business dependency (range [0,1]). It reflects the business independence; the smaller the value, the more business depends on the flow table.

[0068] : Normalized value of resource usage cost (range [0,1]), the larger the value, the lower the resource efficiency of the flow table;

[0069] Idle decay term ( , This is the time decay factor, such as the default. The longer the idle time, the closer this term is to 1, and the higher the entropy value.

[0070] Dynamic weights When network load is high Increase (prioritize unloading inefficient flow tables) during peak business periods Increase (prioritize retaining high-dependency flow tables).

[0071] Implement flow table offloading logic control. When the switch flow table utilization rate reaches a threshold, the offloading process is triggered.

[0072] exclude Non-unloadable flow tables;

[0073] For the remaining flow table Sort by size from largest to smallest (the higher the entropy value, the higher the priority for unloading).

[0074] Calculate the number of entries that need to be released. Select the top K flow tables as the unloading objects;

[0075] Extract matching features (network layer + business layer fields) and action command sequences from the unloading table, and compare them with the unique identifier in the flow table and the current... , Unload timestamps and store them in encrypted form to the flow table backup database.

[0076] When the controller detects unmatched traffic through the traffic monitoring channel, it extracts its characteristics and compares them with the backup database. If a match is found, the unloaded flow table is checked. Then the flow table is calculated in real time. Current resource utility entropy (at this time , Updated to the hit frequency sequence of the last 10 seconds);

[0077] If the switch has available capacity, simply retransmit the flow table. Update its status to "active" and record the resend time and ;

[0078] If no capacity is available, press the current active flow table. Sort the flow tables and select the ones with the highest entropy values. ,uninstall And back up, release resources and then resend the flow table. ;

[0079] After successful retransmission, update the flow table. of , Parameters such as these are used to synchronously update the flow table information database and backup database.

[0080] Then output:

[0081] Unload flow table set: ( For example, the unloading entropy threshold. (0.6)

[0082] Retransmission flow table flag: The corresponding traffic was detected and flow table .

[0083] This method, by fusing multi-dimensional dynamic features with resource utility entropy, overcomes the limitations of the original static priority technology. It can adapt to changes in network traffic stability, service dependencies, and resource efficiency, and achieve more accurate resource scheduling under the limited flow table capacity of low-end switches.

[0084] In S700, the controller sends an aggregated flow table to the target switch and receives a write confirmation from the device. Specifically, the controller retrieves the complete data of the aggregated flow table to be sent from the flow table information database, including the matching feature set, action instruction sequence, priority identifier, and associated service information of the aggregated flow table. At the same time, it determines the unique identifier of the target switch based on the flow table capacity file and sends the aggregated flow table sending instruction to the target switch through the previously established secure channel.

[0085] In addition to the core data of the aggregated flow table, the issued command also includes the controller's unique ID, command timestamp, and data verification information to ensure the security and uniqueness of data transmission. Upon receiving the command, the target switch first verifies the legitimacy of the command's source and the integrity of the data through the verification information. If the verification passes, it calls its own flow table management interface to write the aggregated flow table into the corresponding type of flow table storage area according to a preset format, while recording the flow table write time and initial state. If the verification fails, the command is discarded directly, and a verification failure response is returned to the controller.

[0086] After completing the flow table write operation, the switch generates an acknowledgment data packet containing its own unique identifier, the flow table's unique identifier, the write result (success or failure), the write timestamp, and the current flow table usage rate. This packet is then encrypted and sent back to the controller via a secure channel. Upon receiving the acknowledgment data packet, the controller first verifies its integrity, then extracts the write result and flow table information. If the write is successful, the controller updates the status of the corresponding flow table in the flow table information database to "distributed," synchronously records the distribution completion time, the target switch identifier, and associated service information, and associates this record with the monitoring log database. If an acknowledgment of a write failure is received, the controller temporarily stores the failure record to provide data for triggering the dynamic flow table management mechanism later, ensuring that the entire flow table distribution process is traceable and consistent with the overall flow table management logic.

[0087] In the S800, if a write operation fails due to insufficient capacity, dynamic scheduling is immediately triggered. Specifically, in implementation, a dynamic flow table management module is pre-configured. After the controller receives the flow table write failure confirmation data packet returned by the switch, it first parses the failure reason field in the data packet to confirm that the failure type is insufficient flow table capacity. Then, it sends a scheduling trigger signal to the dynamic flow table management module, along with the aggregated flow table identifier issued for the failure, the unique identifier of the target switch, and the current flow table usage status.

[0088] Upon receiving the signal, the dynamic flow table management module immediately retrieves the flow table information database of the target switch. According to the preset flow table priority system, it filters out the flow table with the lowest current priority that meets the condition of the most recent miss, while excluding flow tables that cannot be unloaded, such as basic connectivity flow tables. For the selected unloadable flow tables, it extracts their matching features, action instructions, and related information, encrypts and stores them in the flow table backup database, and then sends a flow table unload instruction to the target switch.

[0089] After the switch returns a confirmation of successful unloading and releases the flow table resources, the controller immediately re-issues the previously failed aggregated flow table to the switch. If the re-issuance is successful, the controller updates the status of the aggregated flow table in the flow table information database to "issued" and simultaneously records the re-issuance time and resource release status. If the re-issuance still fails due to insufficient capacity, the dynamic flow table management module repeats the above filtering, unloading, and backup process until the target switch has sufficient flow table capacity to complete the issuance of the aggregated flow table. Throughout the process, the controller records the scheduling trigger time, unloaded flow table information, and re-issuance results in real time and stores them in the monitoring log database to provide data support for subsequent flow table management strategy adjustments.

[0090] In S800, after a successful write, the flow table distribution time, priority, and associated service information are recorded. Specifically, after receiving the flow table write success confirmation from the switch, the controller first extracts the unique identifier of the aggregated flow table, simultaneously obtains the specific completion time of the flow table distribution (i.e., the flow table distribution time), and the priority information assigned to the flow table. It also retrieves the associated service information bound to the flow table, including the service identifier and service type. Furthermore, it records the unique identifier of the target switch and the type attribute of the flow table, i.e., whether it belongs to a user group aggregated flow table, a service category aggregated flow table, or a general flow table. Additionally, it associates the aggregated flow table with the original flow table association record in the flow table aggregation mapping library to ensure the completeness of the recorded information. Subsequently, the controller processes this integrated information in a structured manner according to a preset format. On the one hand, it synchronously updates the corresponding flow table entry in the flow table information database, updating the status of the flow table to "issued and active". On the other hand, it stores these records as an independent flow table operation log in the monitoring log database, providing basic data support for subsequent statistical analysis of flow table usage, dynamic adjustment of flow table priorities, and traceability of the correspondence between business and flow table, ensuring that key information in the entire flow table management process is searchable and traceable.

[0091] This application also protects a network communication device that is deployed using the network communication device deployment method in the aforementioned SDN network.

[0092] This application also protects a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the network communication device deployment method in an SDN network as provided in the embodiments of the present invention.

[0093] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system, or device.

[0094] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, system, or device.

[0095] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0096] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for deploying network communication equipment in an SDN network, characterized in that, Including the following steps: The controller sends flow table capacity probe commands to all access switches to obtain the maximum number of flow table entries and the number of currently available entries for each device, and establishes and stores a unique identifier and flow table capacity file for each switch. The controller parses the flow table requests from the upper-layer business and extracts matching fields and action instructions; Aggregate flow tables containing unique user identifiers by user group, aggregate flow tables containing business type identifiers by business category, and merge flow tables with the same action into a single flow table with a group identifier. The controller assigns priorities to the aggregated flow tables; The controller monitors the flow table utilization of the switch in real time and triggers optimization when the total capacity threshold is reached. Unload the lowest-level flow table that has not been hit recently according to priority and back up its matching characteristics and actions; when the corresponding traffic of the unloaded flow table is detected, reissue the flow table and unload the current lowest-level flow table. The controller sends the aggregated flow table to the target switch and receives the write confirmation returned by the device; If the write operation fails due to insufficient capacity, dynamic scheduling is triggered immediately; after a successful write operation, the flow table issuance time, priority, and associated business information are recorded.

2. The method for deploying network communication equipment in an SDN network according to claim 1, characterized in that, The controller sends a flow table capacity probe command to all access switches to obtain the maximum number of flow table entries and the number of currently available entries for each device. It then establishes and stores a unique identifier and flow table capacity file for each switch. Specifically, the controller generates a flow table capacity probe command and broadcasts it to all access switches via a secure channel. After receiving the command, the switch queries and counts the maximum and available entries for each type of flow table, and returns an encrypted data packet containing its own identifier, device model, and flow table capacity data. After verifying the data integrity, the controller establishes and stores a flow table capacity file based on the switch identifier and flow table capacity data, and simultaneously sets up an update mechanism to dynamically refresh the file.

3. The method for deploying network communication equipment in an SDN network according to claim 1, characterized in that, The controller parses the flow table distribution requests from the upper-layer services, extracts matching fields and action instructions. Specifically, the controller receives the flow table distribution requests from the upper-layer services through a preset northbound interface; first, it performs a validity check on the request; if the check fails, it rejects the request; if the check passes, it parses the core content of the flow table; it extracts the set of matching fields and the sequence of action instructions; it synchronously records the service priority parameters to preliminarily determine the category of the flow table request; and it temporarily stores the parsing results.

4. The method for deploying network communication equipment in an SDN network according to claim 1, characterized in that, The process of aggregating flow tables containing unique user identifiers by user group and flow tables containing business type identifiers by business category, and merging flow tables with the same action into a single flow table with a group identifier, specifically involves the controller loading a preset user group mapping table and a business category classification table; for flow tables containing unique user identifiers, extracting the identifier to match the user group to which it belongs, and merging flow tables with the same action instructions within the same group into a single flow table with a user group identifier and retaining common matching fields. For flow tables containing business type identifiers, extract the identifier to determine the business category to which it belongs. Flow tables with consistent action instructions within the same category are merged into a single flow table with the business category identifier, while retaining the common network layer matching field. In the aggregation process, the mapping relationship between the original flow table and the aggregated flow table is recorded and stored in the flow table aggregation mapping library. After aggregation, the validity of the aggregated flow table is verified. If it passes, it is marked as pending issuance; if it fails, the aggregation rules are re-analyzed.

5. The method for deploying network communication equipment in an SDN network according to claim 1, characterized in that, The controller assigns priorities to the aggregated flow tables. Specifically, the controller first extracts the business priority parameters from the flow table issuance requests of the upper-layer business system as a basic reference; it constructs a multi-level priority determination model based on the aggregated flow table type and associated business attributes; it assigns aggregated flow tables associated with core businesses to the highest priority; ordinary business flow tables to the medium priority; and aggregated flow tables for temporary businesses and non-basic functional parts of general flow tables to the lowest priority; if an aggregated flow table is formed by merging multiple original flow tables, the highest business priority is taken as the benchmark; after the allocation is completed, the flow table priority is bound to the entry, and the content and associated business identifier are stored in the flow table information database and synchronized to the dynamic management module; at the same time, a priority evaluation cycle is set, and the priority is calibrated in each cycle according to the actual hit frequency of the flow table and changes in business importance.

6. The method for deploying network communication equipment in an SDN network according to claim 1, characterized in that, The controller monitors the flow table usage rate of the switch in real time and triggers optimization when the total capacity threshold is reached. Specifically, the controller periodically receives flow table usage data from the switch through a real-time status synchronization channel and sets up immediate reporting conditions to deal with sudden changes in usage rate; it parses the data and calculates the usage rate according to the flow table type; when the usage rate reaches a preset threshold, it sends an optimization trigger signal to the dynamic management module along with the switch identifier, flow table type, and usage data; the dynamic management module retrieves the flow table capacity file and priority data to sort the flow tables, filters low-priority candidate unloaded flow tables that have not been recently hit, excludes unloadable basic flow tables, and determines unloadable entries; the controller records the trigger time, usage rate, and reason in the monitoring log database.

7. The method for deploying network communication equipment in an SDN network according to claim 1, characterized in that, The process involves prioritizing and unloading the lowest-level flow table that has recently failed to match, and backing up its matching features and actions. When traffic corresponding to the unloaded flow table is detected, the flow table is reissued and the current lowest-level flow table is unloaded. Specifically, after the controller's dynamic management module determines the candidate flow table to be unloaded, it checks its priority identifier and the most recent hit time. If it is confirmed to be the current lowest priority and meets the "most recent miss" duration condition, the unloadable flow table that ensures basic network connectivity is excluded. For the confirmed unloadable flow table, the complete matching feature set and action instruction sequence are extracted and encrypted and stored in the flow table backup database along with the flow table's unique identifier, original priority, associated service identifier, and unload time. The controller continuously receives traffic data and unmatched data packet features reported by the switch through the traffic monitoring channel. When the traffic characteristics are identified to match those of the backed-up unloaded flow table, it is determined to be the corresponding traffic. The dynamic management module retrieves the flow table information, first checks the switch flow table utilization rate, and if there is available capacity, it directly re-issues the flow table; if there is no available capacity, it filters the lowest priority flow table that has not been hit recently, repeatedly unloads the backup to release resources, and then issues the flow table again. After successful re-issuance, the flow table status is updated to "active" and the most recent issuance time is updated. At the same time, the newly unloaded flow table information is added to the backup database to ensure the continuity of flow table management and data integrity.

8. The method for deploying network communication equipment in an SDN network according to claim 1, characterized in that, The controller sends aggregated flow tables to the target switch and receives write confirmations from the device. Specifically, the controller retrieves the aggregated flow table data to be sent from the flow table information database, determines the target switch based on the flow table capacity file, and sends a sending instruction containing the controller ID, timestamp, and verification information through a secure channel. The switch verifies the instruction; if successful, it writes the data into the flow table and records it; otherwise, it discards the data and returns a response. The switch encrypts and sends an confirmation packet containing its own identifier and the writing result. The controller verifies the confirmation packet; if successful, it updates and records the flow table status; if unsuccessful, it temporarily stores the record to provide a basis for subsequent dynamic flow table management.

9. The method for deploying network communication equipment in an SDN network according to claim 1, characterized in that, If a write operation fails due to insufficient capacity, dynamic scheduling is immediately triggered. Upon successful write, the flow table distribution time, priority, and associated service information are recorded. Specifically, after the controller receives the flow table write failure confirmation packet from the switch, it parses and confirms the failure type as insufficient capacity. It then sends a scheduling trigger signal to the dynamic flow table management module, along with the aggregated flow table identifier, the target switch identifier, and the flow table usage status. The dynamic management module retrieves data, filters the lowest-priority and most recently unavailable unloadable flow tables according to priority, extracts and backs up the information, and sends an unload command to the switch. After resource release, the failed aggregated flow table is resent; if it still fails, the filtering process is repeated. The unloading process involves recording the trigger time, unloading information, and retransmission results throughout the entire process and storing them in the monitoring log database. After the flow table is successfully written, the controller receives confirmation information from the switch, extracts the unique identifier of the aggregated flow table, the distribution time, priority, associated service information, the unique identifier of the target switch, the flow table type attribute, and the original flow table associated records. This information is then structured and updated in the flow table information database to show the flow table status as "distributed and active," and stored as an independent log in the monitoring log database. This provides support for subsequent flow table statistical analysis, priority adjustment, and traceability of the relationship between services and flow tables, ensuring that key information is readily available.

Images