A method, device and storage medium for network logical flow table hot addition

Abstract

The application discloses a network logic flow table hot adding method and device and a storage medium, and applies to the software technical field.The method pre-adds a logic flow table entry in a northbound database, and writes a flow table data field in the logic flow table entry in advance according to needs.Then, the flow table data field can be directly obtained in the logic flow table entry of the northbound database; the obtained flow table data field is spliced into a flow table string; and the spliced flow table string is filled into a southbound database to obtain a logic flow table.The application realizes the hot addition of the logic flow table by modifying code logic, developers can modify the forwarding logic of a message in real time, and the development and test work is more convenient, and the work efficiency is greatly improved.The application is directed to bottom development and test personnel, completely eliminates the complexity of debugging a flow table function, further optimizes the function of a virtualization system, effectively reduces the research and development cost, greatly promotes the development of a product, and improves the product competitiveness.

Description

Technical Field

[0001] This application relates to the field of software technology, and in particular to a method, apparatus, and storage medium for hot-adding network logical flow tables. Background Technology

[0002] Currently, software-defined data centers (SDNs) are a hot technology. They allow applications and all their required resources to be defined through software, including virtualization of servers, storage, network, and security functions. All elements are then combined to create a software-defined data center, visualized based on abstract concepts such as compute nodes, management nodes, storage pools, and network pools. Virtualization significantly reduces server deployment time and costs, improves server flexibility, maximizes resource utilization, and allows for customized environments when configuring virtual machines. In a software-defined data center, virtual machines can cross physical subnet boundaries. Simultaneously, with technological advancements, network requirements are increasing. Next-generation networks need programmable, on-demand customization, centralized unified management, dynamic traffic policing, and automated deployment, leading to the emergence of Software Defined Networking (SDN). Virtual machines on virtualization platforms naturally choose distributed SDN network solutions. For SDN network development, testing, and operations personnel, flow tables are a familiar term; all forwarding rules in the network follow flow tables. As a crucial component of SDN networks, flow tables hold irreplaceable significance.

[0003] However, for technical personnel, the rules for distributing flow tables can only be determined when writing code, and cannot be modified in real time during runtime. This is too cumbersome for debugging, as every time there is a test requirement to modify the flow table, the code needs to be recompiled and packaged, which is costly and affects the efficiency of developers.

[0004] Therefore, improving the work efficiency of developers is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a method, apparatus, and storage medium for hot-adding network logical flow tables to improve the work efficiency of developers.

[0006] To address the aforementioned technical problems, this application provides a method for hot-adding network logical flow tables, comprising:

[0007] Obtain flow table data fields from the logical flow table entries in the northbound database; wherein, the logical flow table entries are pre-added to the northbound database; and the flow table data fields are pre-written into the logical flow table entries as needed.

[0008] The obtained flow table data fields are concatenated into a flow table string;

[0009] The concatenated flow table string is then filled into the southbound database to obtain the logical flow table.

[0010] Preferably, the logical flow table entry includes the following flow table data field parameters: database entry name, logical flow table entry ID, logical flow table priority, logical flow table matching item, and logical flow table action item.

[0011] Preferably, after filling the concatenated flow table string into the southbound database to obtain the logical flow table, the method further includes:

[0012] If the hot-added logical flow table functions correctly, then the code should be modified accordingly to use the default added logical flow table.

[0013] Preferably, after filling the concatenated flow table string into the southbound database to obtain the logical flow table, the method further includes:

[0014] The logical flow table is provided to the computing node so that the computing node can convert the logical flow table into an OpenFlow flow table after obtaining it.

[0015] Preferably, after filling the concatenated flow table string into the southbound database to obtain the logical flow table, the method further includes:

[0016] If the logical flow table is no longer in use, the corresponding logical flow table will be hot-deleted.

[0017] Preferably, before retrieving the flow table data field from the logical flow table entry in the northbound database, the method further includes:

[0018] Analyze network traffic flow;

[0019] After confirming the port to which the traffic from the IP segment is flowing, use the corresponding command to hot-add the logical flow table.

[0020] Preferably, the step of filling the concatenated flow table string into the southbound database to obtain a logical flow table and the step of hot-deleting the corresponding logical flow table if it is no longer in use include:

[0021] The corresponding number of the logical flow table is determined based on the data path type and the direction of the flow.

[0022] Hot-adding and hot-deleting of the logical flow table are performed based on the determined number corresponding to the logical flow table.

[0023] To address the aforementioned technical problems, this application also provides an apparatus for hot-adding network logic flow tables, characterized in that it comprises:

[0024] The acquisition module is used to acquire flow table data fields from logical flow table entries in the northbound database; wherein, the logical flow table entries are pre-added to the northbound database; and the flow table data fields are pre-written into the logical flow table entries as needed.

[0025] The concatenation module is used to concatenate the acquired flow table data fields into a flow table string;

[0026] The filling module is used to fill the concatenated flow table string into the southbound database to obtain a logical flow table.

[0027] Preferably, the device for hot-adding network logical flow tables further includes: a modification module, used to modify the code layer to the default added logical flow table after the concatenated flow table string is filled into the southbound database to obtain the logical flow table, if the hot-added logical flow table functions normally.

[0028] Preferably, the device for hot-adding network logical flow tables further includes: a sending module, used to provide the logical flow table to the computing node after the concatenated flow table string is filled into the southbound database to obtain the logical flow table, so that the computing node can convert the logical flow table into an OpenFlow flow table after obtaining the logical flow table.

[0029] Preferably, the device for hot-adding network logical flow tables further includes a deletion module, used to hot-delete the corresponding logical flow table after the concatenated flow table string is filled into the southbound database to obtain the logical flow table, if the logical flow table has been used up.

[0030] Preferably, the device for hot-adding network logical flow tables further includes: a sorting module, used to sort out the network traffic flow direction before obtaining the flow table data field in the logical flow table entry of the northbound database; and a confirmation module, used to perform hot-adding of the logical flow table using the corresponding command after confirming the port of the traffic flow direction of the IP segment.

[0031] To address the aforementioned technical problems, this application also provides an apparatus for hot-adding network logical flow tables, comprising: a memory for storing computer programs;

[0032] A processor, used to implement the steps of the above-described method for hot-adding network logic flow tables when executing a computer program.

[0033] To address the aforementioned technical problems, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described method for hot-adding network logical flow tables.

[0034] This application provides a method for hot-adding network logical flow tables, achieving hot-adding and hot-deleting functionality without altering the characteristics of the SDN controller itself, thus providing convenience for SDN underlying development and testing personnel. The core solution involves pre-adding logical flow table entries to the northbound database and writing flow table data fields into these entries as needed. Then, flow table data fields can be directly retrieved from the logical flow table entries in the northbound database; these retrieved data fields are concatenated into a flow table string; and the concatenated flow table string is then filled into the southbound database to obtain the logical flow table. Based on a virtualization platform and distributed SDN network architecture, this application achieves hot-adding and hot-deleting of logical flow tables by modifying the SDN controller code logic. Developers can modify packet forwarding logic in real time, facilitating development and testing and significantly improving work efficiency. The core technology of this application lies in the SDN controller database operation, specifically the strict data conversion from the northbound database to the southbound database. The innovation lies in the roundabout way the flow tables are distributed. Instead of directly filling the southbound database (which is theoretically possible but violates the design principles of SDN controllers), the flow tables are forwarded through the northbound database, achieving the effect of hot-adding flow tables. This application improves SDN controllers on virtualization platforms, completely eliminating the tediousness of debugging flow table functions for low-level developers and testers. It further optimizes the functionality of virtualization systems, effectively reduces development costs, greatly promotes product development, and enhances product competitiveness.

[0035] This application also provides a device and a computer-readable storage medium for hot-adding network logical flow tables, which correspond to the above method and therefore have the same beneficial effects as the above method. Attached Figure Description

[0036] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 A flowchart illustrating a method for hot-adding network logical flow tables, provided in an embodiment of this application;

[0038] Figure 2 A structural diagram of the device for hot-adding network logic flow tables provided in an embodiment of this application;

[0039] Figure 3 A structural diagram of a device for hot-adding network logic flow tables according to another embodiment of this application. Detailed Implementation

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

[0041] The core of this application is to provide a method, apparatus, and storage medium for hot-adding network logical flow tables, thereby improving the work efficiency of developers. To enable those skilled in the art to better understand the present application, the following detailed description, in conjunction with the accompanying drawings and specific embodiments, is provided.

[0042] The SDN network used in this application is implemented based on OVS-OVN. Open Virtual Network (OVN) is used as a lightweight SDN controller, and a set of logical flow tables is designed. These can be converted into standard OpenFlow code to control the flow table logic and various network functions. Under normal circumstances, the OVN component retrieves logical network resources (virtual switches, virtual routers, etc.) from the Northbound database and writes the logical flow tables to the Southbound database according to traditional network forwarding rules. Therefore, for users, the resources they can create, delete, and edit are only abstract network devices; they are completely unaware of the flow tables. This has no impact on ordinary users, but it is slightly inconvenient for developers. Based on this, this application proposes a scheme for hot-adding and hot-deleting logical flow tables. Since OVN provides user operation interfaces through a northbound database (e.g., the creation of virtual switches and virtual routers is initially written to the northbound database), to avoid altering OVN's design philosophy, this paper does not directly insert flow tables into the southbound database. Instead, it writes the specific fields of the flow tables that need to be hot-added into the northbound database, and then, through code logic transformation, OVN automatically hot-adds the flow tables into the southbound database. Specifically, Figure 1 A flowchart illustrating a method for hot-adding network logical flow tables provided in this application embodiment; as follows: Figure 1 As shown, the method includes the following steps:

[0043] S10: Retrieve flow table data fields from logical flow table entries in the northbound database.

[0044] S11: Concatenate the obtained flow table data fields into a flow table string.

[0045] S12: Fill the concatenated flow table string into the southbound database to obtain the logical flow table.

[0046] The logical flow table entries are pre-added to the northbound database; the flow table data fields are pre-written into the logical flow table entries as needed.

[0047] This application provides a specific implementation scheme:

[0048] Modify the OVN northbound database table structure and add a new table entry, lflow (i.e., a logical flow table entry). The entry has five parameters: Name: Database table entry name (id); Table_id: Logical flow table entry id; Priority: Logical flow table priority; Match: Logical flow table matching item; Actions: Logical flow table action items.

[0049] Add logic to the OVN theme code to concatenate flow table strings. This involves retrieving flow table data fields from the northbound database, assembling them into a flow table string, and then populating it into the southbound database. Each compute node then retrieves the logical flow table from the southbound database and converts it into an OpenFlow flow table. Here's a concrete example: Name: test; Table_id: 524; Priority: 50; Match: ip4.macst||ip6.mcast; Actions: next. This will be converted to: table = 12(lr_in_arp_resolve), priority = 50, match = (ip4.mcast||ip6.mcast), action = (next;).

[0050] Additionally, it's important to note that the Table_id in the database mentioned above differs from the Table_id value in the actual flow table. This is because the logical flow table has two datapath types and two traffic directions (pipelines). Specifically, it corresponds to the ingress and egress of the logical switch, and the ingress and egress of the logical router. Each table has a unique corresponding value, which needs to be calculated manually in this solution. The calculation method is as follows:

[0051] ((DP_TYPE)<<9)|((PIPELINE)<<8)|(TABLE)

[0052] Wherein, DP_TYPE stands for datapath type, which is an enumerated type:

[0053]

[0054] PIPELINE is also an enumeration type:

[0055]

[0056] TABLE is the Table_id in the southbound database.

[0057] In summary:

[0058] The logical switch ingress table 0-20 corresponds to the values ​​0-20;

[0059] The logical switch egress table 0-10 corresponds to values ​​256-266;

[0060] The logical router ingress table 0-16 corresponds to values ​​512-528;

[0061] The logical router egress table 0-3 corresponds to values ​​768-771.

[0062] In practical applications, it's crucial that all entries populated in the northbound database strictly adhere to the logical flow table specification. After filling the concatenated flow table string into the southbound database to obtain the logical flow table, if the logical flow table is no longer needed, it should be hot-deleted. Specifically, the fields in the northbound database must be deleted first, then OVN should be compared. If inconsistencies exist between the northbound and southbound databases, the fields in the southbound database should be deleted. Furthermore, hot deletion is limited to deleting hot-added entries; it cannot delete hot-added flow tables.

[0063] This section provides a scenario for adding flow tables. For example, when a customer encounters a special situation where a single host is connected to two routing ports, and since Linux systems only have one default route, the customer needs to configure policy-based routing to ensure that corresponding traffic flows to the corresponding port. A flow table can be temporarily added to fulfill this requirement. Once the customer's special environment disappears, the flow table can be deleted. The process of adding a flow table involves first analyzing network traffic flow to confirm that traffic from a certain IP segment should flow to a specific port. Then, a command is used to add the flow table. Key parameters include the IP segment, destination port, source port, and flow table ID. As long as the parameters are valid, this application can add a new flow table to the existing flow table.

[0064] Furthermore, this function can also be used for testing during product development. If the hot-added flow table function works correctly, it can be modified in the code to be the default added (cold-added) flow table, ensuring it always exists within the system (e.g., in the development of policy routing functionality). After filling the concatenated flow table string into the southbound database to obtain the logical flow table, the process also includes: if the hot-added logical flow table function works correctly, modifying the code accordingly to be the default added logical flow table, ensuring it always exists within the system (e.g., in the development of policy routing functionality).

[0065] The above embodiments mention data path types and two directions of traffic. A datapath is a data path, which has two types: switch type and router type, which can be intuitively understood as a switch or a router. A pipeline represents the two directions of traffic, specifically the inflow direction and the outflow direction. In simple terms, for example, for a network port, traffic flows in from the left and out from the right; the left side can be understood as the ingress, and the right side as the egress. Each combination of datapath and pipeline has its own set of flow tables. The number of flow tables varies in each set, but each flow table has a fixed corresponding number at the underlying level. For example, the ingress of a switch-type datapath has 21 flow tables, with flow table numbers ranging from 0 to 20. Therefore, in actual operation, to accurately insert or delete a flow table, the corresponding flow table number must be calculated. This application provides a preferred implementation scheme, which involves filling the concatenated flow table string into the southbound database to obtain a logical flow table, and performing hot deletion of the corresponding logical flow table if it is no longer in use. This includes: determining the number corresponding to the logical flow table based on the data path type and the direction of traffic; and performing hot addition and hot deletion of the logical flow table based on the determined number corresponding to the logical flow table.

[0066] Here are some preferred solutions. In application, before retrieving flow table data fields from the logical flow table entries in the northbound database, it is necessary to first analyze the network traffic flow direction. After confirming the port to which the traffic flows from the IP segment, the corresponding command is used to hot-add the logical flow table. Additionally, after filling the concatenated flow table string into the southbound database to obtain the logical flow table, the process also includes: providing the logical flow table to the compute nodes so that the compute nodes can obtain the logical flow table and convert it into an OpenFlow flow table.

[0067] This application relates to the field of software-defined data centers, keeping pace with the trend of convergence of computing, storage, and networking technologies. It makes significant improvements to SDN controllers on virtualization platforms, completely eliminating the tediousness of debugging flow table functions for low-level development and testing personnel. It further optimizes the functionality of virtualization systems, effectively reduces R&D costs, and greatly promotes product development and enhances product competitiveness. The method for hot-adding network logical flow tables provided in this application's embodiments has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for helping to understand the method and core ideas of this application; at the same time, for those skilled in the art, there will be changes in specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0068] This application provides a method for hot-adding network logical flow tables, achieving hot-adding and hot-deleting of logical flow tables without altering the characteristics of the SDN controller itself, thus providing convenience for SDN underlying development and testing personnel. The core solution involves pre-adding logical flow table entries to the northbound database and writing flow table data fields into these entries as needed. Then, flow table data fields can be directly retrieved from the logical flow table entries in the northbound database; these retrieved data fields are concatenated into a flow table string; and the concatenated flow table string is filled into the southbound database to obtain the logical flow table. Based on a virtualization platform and a distributed SDN network architecture, this application achieves hot-adding and hot-deleting of logical flow tables by modifying the SDN controller code logic. Developers can modify packet forwarding logic in real time, facilitating development and testing and greatly improving work efficiency. The core technology of this application lies in the SDN controller database operation, specifically the strict data conversion from the northbound database to the southbound database. The innovation lies in the roundabout way the flow tables are distributed. Instead of directly filling the southbound database (which is theoretically possible but violates the design principles of SDN controllers), the flow tables are forwarded through the northbound database, achieving the effect of hot-adding flow tables. This application's embodiments improve upon SDN controllers on virtualization platforms, targeting low-level development and testing personnel. It completely eliminates the tediousness of debugging flow table functions, further optimizes the functionality of virtualization systems, effectively reduces development costs, greatly promotes product development, and enhances product competitiveness.

[0069] In practical implementation, logical flow table entries include the following flow table data field parameters: database entry name, logical flow table entry ID, logical flow table priority, logical flow table matching item, and logical flow table action item. The five parameters mentioned in the above embodiment for adding a new entry `lflow` are: Name: database entry name (id); Table_id: logical flow table entry ID; Priority: logical flow table priority; Match: logical flow table matching item; Actions: logical flow table action item. In actual applications, the above scheme is not limited, and adjustments can be made according to the actual situation.

[0070] In addition, after filling the concatenated flow table string into the southbound database to obtain the logical flow table, the logical flow table needs to be provided to the compute nodes so that the compute nodes can obtain the logical flow table and convert it into an OpenFlow flow table.

[0071] This section provides a scenario for adding flow tables. For example, when a customer encounters a special situation where a single host is connected to two routing ports, and since Linux systems only have one default route, the customer needs to configure policy-based routing to ensure that corresponding traffic flows to the corresponding port. A flow table can be temporarily added to fulfill this requirement. Once the customer's special environment disappears, the flow table can be deleted. The process of adding a flow table involves first analyzing network traffic flow to confirm that traffic from a certain IP segment should flow to a specific port. Then, a command is used to add the flow table. Key parameters include the IP segment, destination port, source port, and flow table ID. As long as the parameters are valid, this application can add a new flow table to the existing flow table.

[0072] Furthermore, this function can also be used for testing during product development. If the hot-added flow table function works correctly, it can be modified in the code to be the default added (cold-added) flow table, ensuring it always exists within the system (e.g., in the development of policy routing functionality). After filling the concatenated flow table string into the southbound database to obtain the logical flow table, the process also includes: if the hot-added logical flow table function works correctly, modifying the code accordingly to be the default added logical flow table, ensuring it always exists within the system (e.g., in the development of policy routing functionality).

[0073] Additionally, it's important to note that the `Table_id` in the database mentioned above differs from the `Table_id` value in the actual flow table. This is because the logical flow table has two datapath types and two traffic directions (pipelines). Specifically, it represents the ingress and egress of a logical switch, and the ingress and egress of a logical router. Each table has a unique corresponding value, which needs to be calculated manually in this solution. The above embodiment mentions datapath types and two traffic directions. `datapath` refers to the data path, which has two types: switch type and router type, which can be intuitively understood as a switch or router. `pipeline` represents the two traffic directions, specifically the inflow direction and the outflow direction. In simple terms, for example, for a network port, traffic flows in from the left and out from the right; the left side can be understood as the ingress, and the right side as the egress. Each combination of datapath and pipeline has its own set of flow tables. The number of flow tables varies in each set, but each flow table has a fixed corresponding number at the underlying level. For example, the ingress of the datapath type of a switch has 21 flow tables, with flow table numbers ranging from 0 to 20. Therefore, in actual operation, to accurately insert or delete a flow table, the corresponding flow table number must be calculated. This application provides a preferred implementation scheme, which involves filling the concatenated flow table string into the southbound database to obtain logical flow tables, and performing hot deletion of the corresponding logical flow tables if they are no longer in use. This includes: determining the corresponding number of the logical flow table based on the data path type and the direction of traffic; and performing hot addition and hot deletion of the logical flow table based on the determined number. The specific calculation method for the number has been explained in the above embodiments and will not be repeated here.

[0074] Currently, it's possible to define applications and all their required resources through software, including virtualization of servers, storage, network, and security functions. All elements are then combined to create a software-defined data center, visualized based on abstract concepts such as compute nodes, management nodes, storage pools, and network pools. Virtualization significantly reduces server deployment time and costs, improves server flexibility, maximizes resource utilization, and allows for customized environments when deploying virtual machines. In a software-defined data center, virtual machines can cross physical subnet boundaries. Simultaneously, with technological advancements, network requirements are increasing. Next-generation networks demand programmable, on-demand customization, centralized management, dynamic traffic policing, and automated deployment, leading to the emergence of software-defined networking. Virtual machines on virtualization platforms naturally opt for distributed SDN network solutions. For SDN network development, testing, and operations personnel, flow tables are a familiar term; all forwarding rules in the network follow flow tables. As a crucial component of SDN networks, flow tables hold irreplaceable significance. However, for technical personnel, flow tables can only determine their distribution rules when writing code, and cannot be modified in real time during runtime. This is too cumbersome for debugging, as each test requirement to modify the flow table necessitates recompiling and repackaging the code, which is costly and impacts developer efficiency. This application modifies the OVN northbound database table structure by adding a new entry, lflow (i.e., a logical flow table entry). Then, flow table strings are concatenated into logic in the OVN theme code. Specifically, flow table data fields are retrieved from the northbound database, concatenated into a flow table string, and populated into the southbound database. This allows each compute node to retrieve the logical flow table from the southbound database and convert it into an OpenFlow flow table. The specific steps of this application are as follows: Obtain flow table data fields from the logical flow table entries in the northbound database. Concatenate the obtained flow table data fields into a flow table string. Populate the concatenated flow table string into the southbound database to obtain the logical flow table. The logical flow table entries are pre-added to the northbound database; the flow table data fields are pre-written into the logical flow table entries as needed.

[0075] The SDN architecture adopted in this application is divided into three planes from bottom to top (from south to north): data plane, control plane, and application plane. The data plane consists of general-purpose network hardware such as switches, with various network devices connected via SDN data paths formed by different rules. The control plane contains a logically central SDN controller, which manages global network information and is responsible for controlling various forwarding rules. The application plane contains various SDN-based network applications, allowing users to program and deploy new applications without needing to understand the underlying details. OVN is an SDN controller developed by the OpenvSwitch project team for OpenvSwitch. Compared to other SDN products, OVN offers better compatibility and performance with OpenvSwitch and OpenStack. In practice, flow table matching follows two principles: When priorities differ, higher priority entries are matched first, and lower priority entries are matched later. Priority values ​​range from 0 to 66535, with larger numbers indicating higher priority. When priorities are the same, and flow table entries have the same priority, the same actions, but different matching field granularities, matching is performed according to the order in which the flow table entries were added. The earliest added flow table entry is matched first, meaning matching is performed according to the order of addition. The OVN Northbound Database serves as an intermediate representation for receiving logical network configurations from the OVN / CMS plugin. Its database schema is impedance-matched to the concepts used in CMS, thus directly supporting concepts such as logical switches and routers. The OVN Northbound Database has two clients: the OVN / CMS plugin on top of it and ovn-northd below it. ovn-northd connects to the OVN Northbound Database and to the OVN Southbound Database. It converts the logical network configuration obtained from the traditional network concepts in the Northbound Database into logical data path flows that the Southbound Database below it can understand. The OVN southbound database client includes ovn-northd on it, and ovn-controller on each transport node below it. The OVN southbound database contains three types of data: physical network tables: specifying how to access the hypervisor and other nodes; logical network tables: describing the logical network using logical data path flows; and binding tables: linking the locations of logical network components to the physical network. The performance of the OVN southbound database must vary with the transport nodes. The above provides a detailed description of the method for hot-adding network logical flow tables provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for helping to understand the method and its core ideas; at the same time, for those skilled in the art, based on the ideas of this application, there will be changes in specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

[0076] In the above embodiments, the method for hot-adding network logical flow tables has been described in detail. This application also provides embodiments corresponding to the apparatus for hot-adding network logical flow tables. It should be noted that this application describes the embodiments of the apparatus from two perspectives: one is based on functional modules, and the other is based on hardware.

[0077] From the perspective of functional modules, this embodiment provides a device for hot-adding network logic flow tables. Figure 2 A structural diagram of the device for hot-adding network logic flow tables provided in the embodiments of this application is shown below. Figure 2 As shown, the device includes:

[0078] The acquisition module 10 is used to retrieve flow table data fields from the logical flow table entries in the northbound database; wherein, the logical flow table entries are pre-added to the northbound database; and the flow table data fields are pre-written into the logical flow table entries as needed.

[0079] The concatenation module 11 is used to concatenate the acquired flow table data fields into a flow table string;

[0080] The filling module 12 is used to fill the concatenated flow table string into the southbound database to obtain the logical flow table.

[0081] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0082] As a preferred embodiment, the device for hot-adding network logical flow tables further includes: a modification module, which, after filling the concatenated flow table string into the southbound database to obtain the logical flow table, modifies the code layer accordingly to the default added logical flow table if the hot-added logical flow table functions normally.

[0083] As a preferred embodiment, the apparatus for hot-adding network logical flow tables further includes: a sending module, used to provide the logical flow table to the compute node after filling the concatenated flow table string into the southbound database to obtain the logical flow table, so that the compute node can convert the logical flow table into an OpenFlow flow table after obtaining the logical flow table.

[0084] As a preferred embodiment, the device for hot-adding network logical flow tables further includes a deletion module, which is used to hot-delete the corresponding logical flow table after filling the concatenated flow table string into the southbound database to obtain the logical flow table, if the logical flow table has been used up.

[0085] As a preferred embodiment, the device for hot-adding network logical flow tables further includes: a sorting module, used to sort out the network traffic flow direction before obtaining the flow table data field from the logical flow table entries in the northbound database; and a confirmation module, used to perform hot-adding of the logical flow table using the corresponding command after confirming the port of the traffic flow direction of the IP segment.

[0086] The device for hot-adding network logical flow tables provided in this embodiment achieves hot-adding and hot-deleting functions of logical flow tables without changing the characteristics of the SDN controller itself, providing convenience for SDN underlying development and testing personnel. The core solution is to pre-add logical flow table entries to the northbound database and pre-write flow table data fields into these entries as needed. Then, the acquisition module can directly retrieve the flow table data fields from the logical flow table entries in the northbound database; the concatenation module concatenates the retrieved flow table data fields into a flow table string; and the filling module fills the concatenated flow table string into the southbound database to obtain the logical flow table. This embodiment, based on a virtualization platform and a distributed SDN network architecture, achieves hot-adding and hot-deleting of logical flow tables by modifying the SDN controller code logic. Developers can modify packet forwarding logic in real time, making development and testing more convenient and greatly improving work efficiency. The core technology of this application lies in the SDN controller database operation, specifically the strict data conversion from the northbound database to the southbound database. The innovation lies in the roundabout way the flow tables are distributed. Instead of directly filling the southbound database (which is theoretically possible but violates the design principles of SDN controllers), the flow tables are forwarded through the northbound database, achieving the effect of hot-adding flow tables. This application's embodiments improve upon SDN controllers on virtualization platforms, targeting low-level development and testing personnel. It completely eliminates the tediousness of debugging flow table functions, further optimizes the functionality of virtualization systems, effectively reduces development costs, greatly promotes product development, and enhances product competitiveness.

[0087] From a hardware perspective, this embodiment provides another device for hot-adding network logical flow tables. Figure 3 A structural diagram of a device for hot-adding network logic flow tables according to another embodiment of this application is shown below. Figure 3 As shown, the device for hot-adding network logic flow tables includes: a memory 20 for storing computer programs;

[0088] The processor 21 is configured to implement the steps of the method for hot-adding network logical flow tables as described in the above embodiments when executing a computer program.

[0089] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0090] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of the hot-adding method for network logical flow tables disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, the data involved in the hot-adding method for network logical flow tables.

[0091] In some embodiments, the device for hot-adding network logic flow tables may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0092] Those skilled in the art will understand that the structure shown in the figure does not constitute a limitation on the means of hot-adding network logic flow tables, and may include more or fewer components than shown.

[0093] The apparatus for hot-adding network logical flow tables provided in this application includes a memory and a processor. When the processor executes a program stored in the memory, it can implement the following method: a method for hot-adding network logical flow tables.

[0094] The device for hot-adding network logical flow tables provided in this embodiment achieves hot-adding and hot-deleting functions of logical flow tables without changing the characteristics of the SDN controller itself, providing convenience for SDN underlying development and testing personnel. The core solution is to pre-add logical flow table entries to the northbound database and pre-write flow table data fields into the logical flow table entries as needed. Then, the flow table data fields can be directly obtained from the logical flow table entries in the northbound database; the obtained flow table data fields are concatenated into a flow table string; and the concatenated flow table string is filled into the southbound database to obtain the logical flow table. This embodiment is based on a virtualization platform and a distributed SDN network architecture. By modifying the SDN controller code logic, it achieves hot-adding and hot-deleting of logical flow tables. Developers can modify the packet forwarding logic in real time, making development and testing more convenient and greatly improving work efficiency. The core technology of this application lies in the SDN controller database operation, specifically the strict data conversion from the northbound database to the southbound database. The innovation lies in the roundabout way the flow tables are distributed. Instead of directly filling the southbound database (which is theoretically possible but violates the design principles of SDN controllers), the flow tables are forwarded through the northbound database, achieving the effect of hot-adding flow tables. This application's embodiments improve upon SDN controllers on virtualization platforms, targeting low-level development and testing personnel. It completely eliminates the tediousness of debugging flow table functions, further optimizes the functionality of virtualization systems, effectively reduces development costs, greatly promotes product development, and enhances product competitiveness.

[0095] Finally, this application also provides an embodiment corresponding to a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps described in the above method embodiments.

[0096] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0097] The computer-readable storage medium provided in this embodiment implements hot-adding and hot-deleting functions for logical flow tables without changing the characteristics of the SDN controller itself, providing convenience for SDN underlying development and testing personnel. The core solution is to pre-add logical flow table entries to the northbound database and pre-write flow table data fields into these entries as needed. Then, flow table data fields can be directly retrieved from the logical flow table entries in the northbound database; the retrieved flow table data fields are concatenated into a flow table string; and the concatenated flow table string is filled into the southbound database to obtain the logical flow table. This embodiment, based on a virtualization platform and a distributed SDN network architecture, achieves hot-adding and hot-deleting of logical flow tables by modifying the SDN controller code logic. Developers can modify packet forwarding logic in real time, making development and testing more convenient and greatly improving work efficiency. The core technology of this application lies in the SDN controller database operation, specifically the strict data conversion from the northbound database to the southbound database. The innovation lies in the roundabout way the flow tables are distributed. Instead of directly filling the southbound database (which is theoretically possible but violates the design principles of SDN controllers), the flow tables are forwarded through the northbound database, achieving the effect of hot-adding flow tables. This application's embodiments improve upon SDN controllers on virtualization platforms, targeting low-level development and testing personnel. It completely eliminates the tediousness of debugging flow table functions, further optimizes the functionality of virtualization systems, effectively reduces development costs, greatly promotes product development, and enhances product competitiveness.

[0098] The foregoing has provided a detailed description of a method, apparatus, and storage medium for hot-adding network logical flow tables. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

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

Claims

1. A method for hot-adding network logical flow tables, characterized in that, include: Obtain flow table data fields from the logical flow table entries in the northbound database; wherein, the logical flow table entries are pre-added to the northbound database; the flow table data fields are pre-written into the logical flow table entries as needed; the logical flow table entries include the following flow table data field parameters: database entry name, logical flow table entry ID, logical flow table priority, logical flow table matching item, and logical flow table action item; The obtained flow table data fields are concatenated into a flow table string; The concatenated flow table string is filled into the southbound database to obtain the logical flow table; If the logical flow table is no longer in use, the corresponding logical flow table will be hot-deleted. The steps of filling the concatenated flow table string into the southbound database to obtain a logical flow table and hot-deleting the corresponding logical flow table when it is no longer in use include: determining the number corresponding to the logical flow table based on the data path type and the direction of traffic; and hot-adding and hot-deleting the logical flow table based on the determined number corresponding to the logical flow table. The number is calculated as ((DP_TYPE)<<9)|((PIPELINE)<<8)|(TABLE), where DP_TYPE is the data path type, PIPELINE is the direction of flow, and both DP_TYPE and PIPELINE are enumeration types, and TABLE is the logical flow table entry ID in the southbound database. The hot deletion includes: first deleting the fields in the northbound database, and then deleting the fields in the southbound database if there are inconsistent fields between the northbound database and the southbound database; and the hot deletion is limited to the deletion of table entries that have been hot-added.

2. The method for hot-adding network logical flow tables according to claim 1, characterized in that, After filling the concatenated flow table string into the southbound database to obtain the logical flow table, the process further includes: If the hot-added logical flow table functions correctly, then the code should be modified accordingly to use the default added logical flow table.

3. The method for hot-adding network logical flow tables according to claim 2, characterized in that, After filling the concatenated flow table string into the southbound database to obtain the logical flow table, the process further includes: The logical flow table is provided to the computing node so that the computing node can convert the logical flow table into an OpenFlow flow table after obtaining it.

4. The method for hot-adding network logical flow tables according to claim 1, characterized in that, Before retrieving the flow table data fields from the logical flow table entries in the northbound database, the process also includes: Analyze network traffic flow; After confirming the port to which the traffic from the IP segment is flowing, use the corresponding command to hot-add the logical flow table.

5. A device for hot-adding network logic flow tables, characterized in that, include: The acquisition module is used to acquire flow table data fields from logical flow table entries in the northbound database; wherein, the logical flow table entries are pre-added to the northbound database; the flow table data fields are pre-written into the logical flow table entries as needed; the logical flow table entries include the following flow table data field parameters: database entry name, logical flow table entry ID, logical flow table priority, logical flow table matching item, and logical flow table action item; The concatenation module is used to concatenate the acquired flow table data fields into a flow table string; The filling module is used to fill the concatenated flow table string into the southbound database to obtain a logical flow table; The deletion module is used to hot delete the corresponding logical flow table when the logical flow table is no longer in use; The filling module and the deletion module are used to determine the number corresponding to the logical flow table according to the data path type and the direction of the flow, and to perform hot addition and hot deletion of the logical flow table according to the determined number corresponding to the logical flow table. The number is calculated as ((DP_TYPE)<<9)|((PIPELINE)<<8)|(TABLE), where DP_TYPE is the data path type, PIPELINE is the direction of traffic, and both DP_TYPE and PIPELINE are enumeration types. TABLE is the logical flow table entry ID in the southbound database. When the deletion module performs hot deletion, it first deletes the fields in the northbound database. If there are inconsistent fields between the northbound and southbound databases, it then deletes the fields in the southbound database. The hot deletion is limited to the deletion of entries that have already been hot-added.

6. A device for hot-adding network logic flow tables, characterized in that, Includes memory used to store computer programs; A processor, configured to implement the steps of the method for hot-adding network logical flow tables as described in any one of claims 1 to 4 when executing the computer program.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method for hot-adding network logical flow tables as described in any one of claims 1 to 4.

Images