CN109725925B - Method for detecting conflicts between multiple Software Defined Network (SDN) applications - Google Patents
Method for detecting conflicts between multiple Software Defined Network (SDN) applications Download PDFInfo
- Publication number
- CN109725925B CN109725925B CN201811504826.6A CN201811504826A CN109725925B CN 109725925 B CN109725925 B CN 109725925B CN 201811504826 A CN201811504826 A CN 201811504826A CN 109725925 B CN109725925 B CN 109725925B
- Authority
- CN
- China
- Prior art keywords
- output
- openflow message
- openflow
- sdn
- message set
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 62
- 238000012545 processing Methods 0.000 claims abstract description 34
- 230000015572 biosynthetic process Effects 0.000 claims description 9
- 238000003786 synthesis reaction Methods 0.000 claims description 9
- 230000006855 networking Effects 0.000 claims 2
- 239000002131 composite material Substances 0.000 description 17
- 238000010586 diagram Methods 0.000 description 9
- 239000000203 mixture Substances 0.000 description 9
- 238000012795 verification Methods 0.000 description 5
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 239000002184 metal Substances 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000004880 explosion Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000011895 specific detection Methods 0.000 description 1
- 230000002194 synthesizing effect Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a method for detecting conflicts among a plurality of Software Defined Network (SDN) applications. The method processes each input OpenFlow message of each SDN application in a plurality of SDN applications to be tested by using a symbol execution tool, and detects whether conflicts exist between every two SDN applications based on a processing result, so that whether conflicts exist between the SDN applications can be detected in advance before the SDN applications are deployed, and the method has a good application prospect.
Description
Technical Field
The invention relates to the technical field of Software Defined Network (SDN) verification, in particular to a method for detecting conflicts among multiple SDN applications.
Background
The software defined network SDN is a novel network innovation architecture proposed by Emulex, and simplifies forwarding of a data plane and provides programmability for the control plane by decoupling the control plane and the data plane of a network device, thereby greatly facilitating development and deployment of novel network functions. Users may implement a wide variety of policies by developing and deploying SDN applications to ensure availability and security of the network. With the development of various SDN resource controllers (e.g., ONOS, Floodlight), more and more SDN applications are developed and deployed.
The OpenFlow protocol defines the message types and formats of Controller (Controller) and Switch (Switch) communication procedures. The SDN application manages different aspects of the network by the controller issuing or deleting a flow table for defining a message forwarding rule to the switch. To implement a wide variety of network policies, many SDN applications (e.g., firewalls (firewalls), Load balancers (Load balancers), etc.) are deployed onto the same controller. In fact, SDN applications from different parties will complicate the control logic of the network and may intentionally or unintentionally install rules with the same matching field (match) and conflicting action fields (action) on the same switch, resulting in conflicts between multiple SDN applications, causing network failure or network performance degradation. Currently, this problem is common in the SDN field, and some SDN controller systems rely on priorities between SDN applications to avoid collisions. However, even if each SDN application has an explicit priority, how to process the output of each SDN application with the priority is still a tricky issue. Therefore, to avoid unexpected behavior of users after deployment of multiple SDN applications, pre-detecting conflicts between multiple SDN applications is the only solution.
Previously, researchers have proposed some schemes to verify the correctness of SDN applications. For example, 1) a verification tool represented by NICE and Vericon, which verifies whether the correctness attribute of the network is violated based on a formalization method such as model detection or theorem proof, but the verification tool only verifies a single SDN application and cannot verify the correctness between multiple SDN applications; 2) a validation tool represented by VMN and HSA for validating whether a flow table of a data plane violates a correctness attribute of a network, but it cannot detect a conflict between a plurality of SDN applications in advance before the SDN application is deployed; 3) the verification is performed by using a new controller represented by Netcore and Frenetic, and the controller uses a formalization method such as model detection in a compiler to avoid that the SDN application installs rules which may cause conflict on a switch, however, the verification method can only support a certain northbound interface language and cannot support the application of the existing controller (such as ONOS, flodlight and the like) on the compiler. It follows that none of the above methods can detect in advance a conflict between multiple SDN applications.
In order to solve the above technical problem, the present invention provides a method for detecting a conflict between multiple Software Defined Network (SDN) applications, which can detect a conflict between multiple SDN applications in advance before deploying the multiple SDN applications without changing a controller kernel.
Disclosure of Invention
The technical problem to be solved by the invention is as follows: the prior art methods are not able to detect conflicts between multiple SDN applications in advance before deploying them.
In order to solve the above technical problem, the present invention provides a method for detecting a conflict between a plurality of Software Defined Network (SDN) applications, including:
for each SDN application in a plurality of SDN applications to be tested, executing the following operations:
acquiring a source code and all input OpenFlow messages of the SDN application;
determining input OpenFlow messages to be processed by each event processor according to attribute information of each event processor contained in a source code of the SDN application, wherein the sum of the input OpenFlow messages to be processed by each event processor forms all the input OpenFlow messages;
for each incoming OpenFlow message, the following operations are performed:
processing the input OpenFlow message by using a symbol execution tool corresponding to the language type of the source code to obtain a plurality of executable paths corresponding to the input OpenFlow message, path constraint conditions corresponding to each executable path in the executable paths, and a first output OpenFlow message set corresponding to each executable path, wherein the first output OpenFlow message set is a set of output OpenFlow messages corresponding to each executable path;
respectively solving the path constraint conditions corresponding to each executable path by using a constraint solver, and processing each output OpenFlow message in a first output OpenFlow message set corresponding to each executable path based on a solving result to obtain a second output OpenFlow message set corresponding to each executable path, wherein the second output OpenFlow message set is a set of output OpenFlow messages obtained after processing each output OpenFlow message in the first output OpenFlow message set;
processing each output OpenFlow message in a second output OpenFlow message set corresponding to each executable path to obtain a third output OpenFlow message set corresponding to each executable path, wherein the third output OpenFlow message set is a set of output OpenFlow messages obtained after processing each output OpenFlow message in the second output OpenFlow message set;
and detecting whether conflicts exist between every two SDN applications by utilizing each output OpenFlow message in a third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of each SDN application.
In a preferred embodiment of the present invention, processing an input OpenFlow message by using a symbolic execution tool corresponding to a language type of the source code to obtain a plurality of executable paths corresponding to the input OpenFlow message, a path constraint condition corresponding to each executable path in the plurality of executable paths, and a first output OpenFlow message set corresponding to each executable path, includes:
using a symbolic execution tool corresponding to a language type of source code of the SDN application, designating relevant variables contained in each input OpenFlow message of the SDN application as symbolic variables, wherein the relevant variables are variables required to be used in a process of detecting conflicts among a plurality of SDN applications;
and running each event processor contained in the source code of the SDN application by using the symbol execution tool to obtain a plurality of executable paths corresponding to each input OpenFlow message of the SDN application, a path constraint condition corresponding to each executable path in the executable paths and a first output OpenFlow message set corresponding to each executable path.
In a preferred embodiment of the present invention, the method further comprises: and assigning specific values to independent variables contained in each input OpenFlow message of the SDN application, wherein the independent variables are variables which are not needed to be used in the process of detecting the conflict among the plurality of SDN applications.
In a preferred embodiment of the present invention, the method further comprises: according to the specific meaning of each domain of a flow table contained in each input OpenFlow message of the SDN application in the software defined network SDN, limiting the value range of each symbol variable contained in each input OpenFlow message of the SDN application in a preset range.
In a preferred embodiment of the present invention, solving the path constraint condition corresponding to each executable path by using a constraint solver, and processing each output OpenFlow message in the first output OpenFlow message set corresponding to each executable path based on the solved result to obtain a second output OpenFlow message set corresponding to each executable path, includes:
for each executable path corresponding to each input OpenFlow message of each SDN application, performing the following operations:
solving the path constraint condition corresponding to the executable path by using a constraint solver;
under the condition that the return result of the constraint solver is a solution, giving a specific value obtained by solving to each symbol variable contained in each output OpenFlow message in a first output OpenFlow message set corresponding to the executable path to obtain a second output OpenFlow message set corresponding to the executable path;
and under the condition that the result returned by the constraint solver is not a solution, removing the first output OpenFlow message set corresponding to the executable path to obtain a second output OpenFlow message set corresponding to the executable path, wherein the second output OpenFlow message set is an empty set.
In a preferred embodiment of the present invention, the flow table included in the output OpenFlow message includes an action field containing a reset action or does not contain a reset action.
In a preferred embodiment of the present invention, processing each output OpenFlow message in the second output OpenFlow message set corresponding to each executable path to obtain a third output OpenFlow message set corresponding to each executable path includes:
for a second set of output OpenFlow messages corresponding to each executable path corresponding to each input OpenFlow message of each SDN application, performing the following operations:
classifying each output OpenFlow message in the second output OpenFlow message set according to the attribute information of each output OpenFlow message in the second output OpenFlow message set;
and processing each output OpenFlow message in the second output OpenFlow message set according to the classification result to obtain a third output OpenFlow message set corresponding to the executable path to which the second output OpenFlow message set belongs.
In a preferred embodiment of the present invention, processing each output OpenFlow message in the second output OpenFlow message set according to the classification result to obtain a third output OpenFlow message set corresponding to an executable path to which the second output OpenFlow message set belongs includes:
when the action fields of the flow tables contained in the output OpenFlow messages in the second output OpenFlow message set do not contain reset actions, if the output OpenFlow messages in the second output OpenFlow message set are kept unchanged, the output OpenFlow messages contained in a third output OpenFlow message set corresponding to the executable path to which the second output OpenFlow message set belongs are kept consistent with the output OpenFlow messages contained in the second output OpenFlow message set;
when the action fields of the flow tables included in the output OpenFlow messages in the second output OpenFlow message set all contain reset actions, if the output OpenFlow messages in the second output OpenFlow message set are removed, the third output OpenFlow message set corresponding to the executable path to which the second output OpenFlow message set belongs is an empty set.
In a preferred embodiment of the present invention, processing each output OpenFlow message in the second output OpenFlow message set according to the classification result to obtain a third output OpenFlow message set corresponding to an executable path to which the second output OpenFlow message set belongs, further includes:
and under the condition that the action domain of the flow table contained in one part of the output OpenFlow messages in the second output OpenFlow message set contains a reset action and the action domain of the flow table contained in the other part of the output OpenFlow messages does not contain the reset action, processing each output OpenFlow message in the second output OpenFlow message set by using a preset synthesis rule to obtain a third output OpenFlow message set corresponding to the executable path to which the second output OpenFlow message set belongs.
In a preferred embodiment of the present invention, detecting whether a conflict exists between each two SDN applications by using each output OpenFlow message in a third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of each SDN application includes:
obtaining a first SDN application and a second SDN application from any two SDN applications in a plurality of SDN applications to be tested;
acquiring each output OpenFlow message in a third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of the first SDN application, and each output OpenFlow message in the third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of the second SDN application;
respectively obtaining a first output OpenFlow message and a second output OpenFlow message from a third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of the first SDN application and from any output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of the second SDN application;
and judging whether the first SDN application and the second SDN application have conflict or not by utilizing a preset judgment rule according to the attribute information of the first output OpenFlow message and the second output OpenFlow message.
Compared with the prior art, one or more embodiments in the above scheme can have the following advantages or beneficial effects:
by applying the method for detecting the conflict among the plurality of Software Defined Network (SDN) applications, which is provided by the embodiment of the invention, each input OpenFlow message of each SDN application in the plurality of SDN applications to be detected is processed by utilizing the symbol execution tool, and whether the conflict exists between every two SDN applications is detected based on the processing result, so that whether the conflict exists among the SDN applications is detected in advance before the SDN applications are deployed, and the method has a good application prospect.
Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.
Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention and not to limit the invention. In the drawings:
fig. 1 is a schematic flowchart illustrating a method for detecting a conflict between multiple software defined network SDN applications according to an embodiment of the present invention;
FIG. 2 is a schematic diagram of the detailed process of step S103 in FIG. 1;
FIG. 3 is a schematic diagram of the detailed process of step S104 in FIG. 1;
FIG. 4 is a schematic diagram of the detailed process of step S105 in FIG. 1;
FIG. 5 is a schematic diagram of the detailed process of step S106 in FIG. 1;
fig. 6 is a schematic diagram of a scenario in which multiple SDN applications coexist in an application example one of the present invention;
fig. 7 is a schematic diagram of a result obtained by operating an event processor for processing an OpenFlow message input as packet _ in by using a symbol execution tool, and solving a path constraint condition corresponding to each executable path by using a constraint solver, respectively;
FIG. 8 is a graph showing the results of FIG. 7;
fig. 9 is a schematic diagram showing a process of synthesizing each output OpenFlow message in the second output OpenFlow message set corresponding to each executable path.
Detailed Description
The following detailed description of the embodiments of the present invention will be provided with reference to the drawings and examples, so that how to apply the technical means to solve the technical problems and achieve the technical effects can be fully understood and implemented. It should be noted that, as long as there is no conflict, the embodiments and the features of the embodiments of the present invention may be combined with each other, and the technical solutions formed are within the scope of the present invention.
In order to solve the technical problem that a method in the prior art cannot detect a conflict between multiple SDN applications in advance before the multiple SDN applications are deployed, an embodiment of the present invention provides a method for detecting a conflict between multiple software defined network SDN applications.
SDN applications are used to process various OpenFlow messages sent by switches, which are referred to as input OpenFlow messages for SDN applications since they are input with respect to SDN applications. The SDN application is an event-driven mode that processes the input OpenFlow message through each event handler included in the source code and issues or deletes a flow table to the switch by outputting the OpenFlow message. In general, the flow table includes information of a matching field, an action field, a priority field, a counter, a timeout time, an affiliation attribute, and the like. Event handlers contained in the source code of the SDN application may respond to various network events, such as packet arrivals, links, switch failures, etc.
As will be understood by those skilled in the art, the input OpenFlow message of the SDN application contains information such as a packet, and the output OpenFlow message of the SDN application contains information such as which flow table is issued for which switch.
Fig. 1 is a schematic specific flowchart of a method for detecting a conflict between multiple software defined network SDN applications according to an embodiment of the present invention.
As shown in fig. 1, the method for detecting a conflict between multiple software defined network SDN applications according to an embodiment of the present invention mainly includes the following steps S101 to S106.
For each SDN application in a plurality of SDN applications to be tested, executing the following operations:
in step S101, a source code of the SDN application and all input OpenFlow messages are acquired.
In step S102, input OpenFlow messages to be processed by the event processors are determined according to attribute information of the event processors included in the source code of the SDN application, where a sum of the input OpenFlow messages to be processed by the event processors constitutes all the input OpenFlow messages.
For each input OpenFlow message in step S102, the following operations are performed:
in step S103, the input OpenFlow message is processed by using a symbolic execution tool corresponding to the language type of the source code, so as to obtain a plurality of executable paths corresponding to the input OpenFlow message, a path constraint condition corresponding to each executable path in the plurality of executable paths, and a first output OpenFlow message set corresponding to each executable path. The first set of output OpenFlow messages is a set of output OpenFlow messages corresponding to each executable path, and the output OpenFlow messages include flow tables with or without reset actions in action fields. The specific process is shown in fig. 2.
In step S1031, a symbolic variable is designated as a related variable included in each input OpenFlow message of the SDN application by using a symbolic execution tool corresponding to the language type of the source code of the SDN application. The relevant variable is a variable that needs to be used in detecting a conflict between multiple SDN applications, for example, a source IP address, a destination IP address, and the like.
In step S1032, each event handler included in the source code of the SDN application is run by using a symbol execution tool, and a plurality of executable paths corresponding to each input OpenFlow message of the SDN application, a path constraint condition corresponding to each executable path of the plurality of executable paths, and a first output OpenFlow message set corresponding to each executable path are obtained.
In a preferred embodiment of the present invention, the method further comprises: and assigning specific values to independent variables contained in each input OpenFlow message of the SDN application. Wherein the independent variable is a variable that is not required to be used in detecting a conflict between multiple SDN applications. For example, an input OpenFlow message of a certain SDN application under test is packet _ in, the message content contained in the input OpenFlow message is packet header and payload, and if the function of the SDN application under test is not related to the payload (that is, the payload is an independent variable), the payload may be assigned with a specific value. By the arrangement, the symbol execution efficiency can be effectively improved.
In a preferred embodiment of the present invention, the method further comprises: according to the specific meaning of each domain of a flow table contained in each input OpenFlow message of the SDN application in the software defined network SDN, limiting the value range of each symbol variable contained in each input OpenFlow message of the SDN application in a preset range. Each field of the flow table included in each input OpenFlow message has a minimum value range, and the preset range corresponds to the minimum value range. For example, the input OpenFlow message includes a symbol variable "eth _ type" field value having a minimum value range of (0-64).
According to the invention, each input OpenFlow message of each SDN application is processed by utilizing the symbolic execution tool, so that the problem of state space explosion caused by traversing each SDN application state can be effectively avoided, and the coverage rate of a source code of each SDN application can be ensured.
In step S104, a constraint solver is used to respectively solve the path constraint condition corresponding to each executable path, and based on the solved result, each output OpenFlow message in the first output OpenFlow message set corresponding to each executable path is processed to obtain a second output OpenFlow message set corresponding to each executable path, where the second output OpenFlow message set is a set of output OpenFlow messages obtained by processing each output OpenFlow message in the first output OpenFlow message set. The specific process is shown in fig. 3.
For each executable path corresponding to each input OpenFlow message of each SDN application, performing the following operations:
in step S1041, a path constraint condition corresponding to the executable path is solved by a constraint solver.
If the constraint solver returns a solution, step S1042 is executed: and assigning the solved specific value to each symbol variable contained in each output OpenFlow message in the first output OpenFlow message set corresponding to the executable path to obtain a second output OpenFlow message set corresponding to the executable path.
For example, the path constraint condition corresponding to executable path 1 is solved by a constraint solver to obtain λI. If the output OpenFlow message in the first output OpenFlow message set corresponding to the executable path 1 is (add, sw)1,e8((p.src＝λ.src,p.dst＝ServerD) → fwd (3))), the solved specific value is given to the symbolic variable (p.src) contained in the output OpenFlow message, and the output OpenFlow message (add, sw) is obtained1,e8((p.src＝HostI,p.dst＝ServerD) → fwd (3))), which is the output OpenFlow message in the second set of output OpenFlow messages corresponding to executable path 1.
If the return result of the constraint solver is no solution, step S1043 is executed: and removing the first output OpenFlow message set corresponding to the executable path to obtain a second output OpenFlow message set corresponding to the executable path, wherein the second output OpenFlow message set is an empty set.
In step S105, each output OpenFlow message in the second output OpenFlow message set corresponding to each executable path is processed to obtain a third output OpenFlow message set corresponding to each executable path, where the third output OpenFlow message set is a set of output OpenFlow messages obtained after each output OpenFlow message in the second output OpenFlow message set is processed. The specific process is shown in fig. 4.
For a second set of output OpenFlow messages corresponding to each executable path corresponding to each input OpenFlow message of each SDN application, performing the following operations:
in step S1051, each output OpenFlow message in the second output OpenFlow message set is classified according to the attribute information of each output OpenFlow message in the second output OpenFlow message set. The attribute information indicates whether or not a reset operation is included in the operation field of the flow table included in each output OpenFlow message.
In step S1052, each output OpenFlow message in the second output OpenFlow message set is processed according to the classification result, so as to obtain a third output OpenFlow message set corresponding to the executable path to which the second output OpenFlow message set belongs.
Specifically, when none of the action fields of the flow tables included in each of the second set of output OpenFlow messages contains a reset action, each of the second set of output OpenFlow messages remains unchanged. That is, each output OpenFlow message included in the third output OpenFlow message set corresponding to the executable path to which the second output OpenFlow message set belongs is consistent with each output OpenFlow message included in the second output OpenFlow message set.
When the action fields of the flow tables included in the output OpenFlow messages in the second output OpenFlow message set all contain reset actions, if the output OpenFlow messages in the second output OpenFlow message set are removed, the third output OpenFlow message set corresponding to the executable path to which the second output OpenFlow message set belongs is an empty set.
And under the condition that the action domain of the flow table contained in one part of the output OpenFlow messages in the second output OpenFlow message set contains a reset action and the action domain of the flow table contained in the other part of the output OpenFlow messages does not contain the reset action, processing each output OpenFlow message in the second output OpenFlow message set by using a preset synthesis rule to obtain a third output OpenFlow message set corresponding to the executable path to which the second output OpenFlow message set belongs. The specific treatment process is as follows:
first, each output OpenFlow message in the second output OpenFlow message set is divided into two groups, the first group: the action field of the flow table included in the output OpenFlow message contains a reset action, and the second group: the flow table included in the output OpenFlow message does not include a reset action in the action field.
Then, any one of the OpenFlow messages is output from the first group, and is marked as message 1. And outputting the OpenFlow message from any one of the second group, and recording the OpenFlow message as a message 2.
Next, the matching field of the flow table included in the message 1 and the action field are combined to obtain a combined matching field of the flow table included in the message 1.
If neither the action field of the flow table included in the message 1 nor the action field of the flow table included in the message 2 contains a delete action, the matching field of the flow table included in the message 2 belongs to the composite matching field of the flow table included in the message 1, and both the message 1 and the message 2 are operated on the same switch, the matching field, the action field, and the priority field of the flow table included in the message 1 and the flow table included in the message 2 are composited. The specific process is as follows:
composite match fields of the flow table contained in message 1 and the flow table contained in message 2: if the scope of the reset action of the flow table included in message 1 (the action field of the flow table included therein includes the reset action) is the destination address field, the destination address fields of the composite matching field of the flow table included in message 1 and the flow table included in message 2 are: the destination address field of the flow table contained in message 1 (which contains a reset action in the action field of the flow table contained therein), the source address field of the composite match field of the flow table contained in message 1 and the flow table contained in message 2 are: message 2 (which contains a flow table whose action field does not contain a reset action) contains the source address field of the flow table.
If the scope of the reset action of the flow table included in message 1 (which contains the reset action in the action field of the flow table included therein) is the source address field, the destination address fields of the flow table included in message 1 and the composite matching field of the flow table included in message 2 are: the destination address field of the flow table included in message 2 (which includes a flow table whose action field does not include a reset action), and the source address fields of the composite matching fields of the flow table included in message 1 and the flow table included in message 2 are: message 1 (which contains a reset action in the action field of the flow table) contains the source address field of the flow table.
The composition priority field of the flow table contained in message 1 and the flow table contained in message 2 is: the smaller one of the priority domain value of the flow table included in message 1 (which contains a reset action in the action domain of the flow table) and the priority domain value of the flow table included in message 2 (which does not contain a reset action in the action domain of the flow table included in it).
The composite action fields of the flow table contained in message 1 and the flow table contained in message 2 are: message 2 (which contains a flow table whose action field does not contain a reset action) contains the action field value of the flow table.
Based on this, the composition of the matching field, the action field, and the priority field for the flow table included in message 1 and the flow table included in message 2 has been completed, resulting in message 3, and message 3 is added to the second group. Message 1 is removed from the first group because the flow table contained in message 3 already includes the forwarding logic of the flow table contained in message 1.
The above process is repeated until the flow table included in each output OpenFlow message in the first group and the flow table included in each output OpenFlow message in the second group are synthesized in pairs.
It should be noted that, after the flow table included in each output OpenFlow message in the first group and the flow table included in each output OpenFlow message in the second group are synthesized, the output OpenFlow message is also included in the first group, and then the output OpenFlow message is deleted.
Based on this, the flow table included in each output OpenFlow message in the third output OpenFlow message set corresponding to the executable path to which the second output OpenFlow message set belongs does not include a reset action in the action field.
Note that, if the deletion action is included in the action field of the flow table included in the message 1 and/or the action field of the flow table included in the message 2, the message 1 and/or the message 2 is deleted. In this case, the other messages are reselected from the first group and/or the second group.
If neither the action field of the flow table included in the message 1 nor the action field of the flow table included in the message 2 contains a deletion action, and the matching field of the flow table included in the message 2 does not belong to the synthesis matching field of the flow table included in the message 1, the flow table included in the message 1 and the flow table included in the message 2 cannot be synthesized. In this case, it is necessary to newly select other messages from the first group and the second group. At this time, message 1 may be selected from the first group, and messages other than message 2 may be selected from the second group; it is also possible to select messages other than message 1 from the first group and message 2 from the second group.
If neither the action field of the flow table included in the message 1 nor the action field of the flow table included in the message 2 contains a delete action, the matching field of the flow table included in the message 2 belongs to the synthesis matching field of the flow table included in the message 1, and the message 1 and the message 2 are not operated on the same switch, the flow table included in the message 1 and the flow table included in the message 2 cannot be synthesized. In this case, it is necessary to newly select other messages from the first group and the second group. At this time, message 1 may be selected from the first group, and messages other than message 2 may be selected from the second group; it is also possible to select messages other than message 1 from the first group and message 2 from the second group.
In step S106, it is detected whether a conflict exists between each two SDN applications by using each output OpenFlow message in the third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of each SDN application. The specific process is shown in fig. 5.
In step S1061, a first SDN application and a second SDN application are obtained from any two SDN applications from a plurality of SDN applications to be tested.
In step S1062, output OpenFlow messages in a third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of the first SDN application and output OpenFlow messages in a third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of the second SDN application are obtained.
In step S1063, an output OpenFlow message is obtained from any one of a third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of the first SDN application and a third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of the second SDN application, respectively, to obtain a first output OpenFlow message and a second output OpenFlow message.
In step S1064, according to the attribute information of the first output OpenFlow message and the second output OpenFlow message, a preset determination rule is used to determine whether a conflict exists between the first SDN application and the second SDN application.
Specifically, if information included in the first output OpenFlow message and information included in the second output OpenFlow message are both flow tables issued to the same switch, and a source address field and a destination address field of the flow tables included in the first output OpenFlow message and the second output OpenFlow message are respectively intersected, and the action fields are different, it is determined that the first SDN application and the second SDN application have a conflict. Otherwise, judging that the first SDN application and the second SDN application do not have conflict.
That is, two SDN applications may generate a conflict only if they simultaneously satisfy the following three conditions: firstly, information contained in output OpenFlow messages of two SDN applications is a flow table issued to the same switch; respectively intersecting a source address domain and a destination address domain of a flow table contained in an output OpenFlow message of the two SDN applications; and the action domains of the flow tables contained in the output OpenFlow messages of the two SDN applications are different. If it cannot satisfy any of the above three conditions at the same time, the two SDN applications will not generate a conflict.
Further, if the priority domain of the flow table included in the first output OpenFlow message is different from the priority domain of the flow table included in the second output OpenFlow message, both the flow table included in the first output OpenFlow message and the flow table included in the second output OpenFlow message can be installed on the switch. However, an action generated by an output OpenFlow message with a higher priority field of the included flow table overwrites an action generated by an output OpenFlow message with a lower priority field of the included flow table, and therefore, an action generated by an output OpenFlow message with a lower priority field of the included flow table is disabled.
For example, it is assumed that the flow table included in the first output OpenFlow message is flow table 1, the priority field value of the flow table 1 is 1, and the matching field is λC,λ.dst＝HostEThe action field is fwd (3); the second output OpenFlow message includes a flow table 2, the priority field value of the flow table 2 is 2, and the matching field is λC,λ.dst＝HostEThe action domain is drop. Therefore, both the flow table 1 and the flow table 2 can be mounted on the switch. When a certain input OpenFlow message contains a message (the source address of the message is Host)CThe destination address is HostE) When the switch is reached, the switch checks the flow table with the higher priority domain value, and checks whether the source address and the destination address of the message meet the matching domain of the flow table. In this example, since the priority field value of flow table 2 is higher than that of flow table 1, the switch first checks flow table 2 and finds that the source address and the destination address of the packet satisfy the matching field of flow table 2, then performs the action included in the action field of flow table 2 and discards the packet. Since the priority field value of flow table 1 is lower than the priority field value of flow table 2, the switch cannot forward the packet according to the action contained in the action field of flow table 1.
It should be noted that, according to the OpenFlow protocol standard, if the priority domain value of the flow table included in the first output OpenFlow message is different from the priority domain value of the flow table included in the second output OpenFlow message, both the flow table included in the first output OpenFlow message and the flow table included in the second output OpenFlow message can be installed. But the installation order depends on the time sequence of the arrival of the first output OpenFlow message and the second output OpenFlow message at the switch, and is not related to the priority field value of the flow table.
In the case where the priority domain value of the flow table included in the first output OpenFlow message is the same as the priority domain value of the flow table included in the second output OpenFlow message, and the matching domain of the flow table included in the first output OpenFlow message is the same as the matching domain of the flow table included in the second output OpenFlow message, the flow table included in the first output OpenFlow message and the flow table included in the second output OpenFlow message cannot be installed.
Further, if the priority domain value of the flow table included in the first output OpenFlow message is the same as the priority domain value of the flow table included in the second output OpenFlow message, the flow table included in the output OpenFlow message that arrives at the switch later cannot be installed on the switch. That is, of the two SDN applications, the flow table included in the output OpenFlow message of the SDN application with the lower priority cannot be installed on the switch.
For example, it is assumed that the flow table included in the first output OpenFlow message is flow table 1, the priority field value of the flow table 1 is 1, and the matching field is λC,λ.dst＝HostEThe action field is fwd (3); the second output OpenFlow message includes a flow table 2, the priority field value of the flow table 2 is 1, and the matching field is λC,λ.dst＝HostEThe action domain is drop. If the first output OpenFlow message arrives at the switch first and the second output OpenFlow message arrives at the switch later, flow table 1 is installed on the switch, but flow table 2 cannot be installed on the switch.
In this way, steps S1063 to S1064 are repeatedly executed until each output OpenFlow message included in the first SDN application and each output OpenFlow message included in the second SDN application are taken out and determined.
It should be noted that, if it can be determined that a conflict exists between the first SDN application and the second SDN application through a certain output OpenFlow message of the first SDN application and a certain output OpenFlow message of the second SDN application, another output OpenFlow message needs to be selected from the first SDN application and the second SDN application again, and re-determination is performed by using the selected output OpenFlow message until each output OpenFlow message of the first SDN application and each output OpenFlow message of the second SDN application are taken out and determined between each two output OpenFlow messages.
The steps S1061 to S1064 are repeated in this way until every two SDN applications to be tested are detected.
In order to facilitate a better understanding of the present invention, the following detailed description of the technical solutions of the present invention is given by way of application examples.
Application example 1
Fig. 6 is a schematic diagram of a scenario in which multiple SDN applications coexist in the present example. In fig. 6, a first SDN application (firewall) and a second SDN application (insecure application) run simultaneously on the same controller. First SDN application (firewall) at switch sw1Install Rule 1 on to isolate external HostCTo an internal network Server (Server)D) Traffic of (2), second SDN application (unsecure application) at switch sw1Rule2, Rule3 and Rule4 are installed. Wherein the meaning of Rule2 is: arriving switch sw1If the source address (src) of the input OpenFlow message is the HostCAddress of (2), switch sw1Resetting the source address (src) of the message contained in the incoming OpenFlow message to the HostEAfter the address is received, continuing to send the message contained in the input OpenFlow message to the switch sw1The other rules above are matched. The meaning of Rule3 is: arriving switch sw1If the destination address (dst) of the message contained in the input OpenFlow message is the HostFAddress of (2), switch sw1Resetting a destination address (dst) of a packet included in the input OpenFlow message to a network Server (Server)D) After the address is received, continuing to send the message contained in the input OpenFlow message to the switch sw1The other rules above are matched. The meaning of Rule4 is: arriving switch sw1If the source address (src) of the input OpenFlow message is the HostEThe destination address (dst) is a network Server (Server)D) The address of (3) is then forwarded out the message contained in the input OpenFlow message through the port 3. Therefore, if the source address (src) of the packet included in the input OpenFlow message is the HostCThe destination address (dst) is the HostFThe message contained in the input OpenFlow message reaches a network Server (Server) after passing through rules Rule2, Rule3 and Rule4D). That is, the HostCThe message contained in the input OpenFlow message finally reaches a network Server (Server)D) This is in conflict with Rule 1 of the first SDN application (firewall). The specific detection process is as follows:
for a first SDN application (firewall) and a second SDN application (insecure application) to be tested, the following operations are executed:
here, for the sake of simplicity, the second SDN application (unsecure application) is explained as an example below.
In step S101, a source code of the SDN application and all input OpenFlow messages are acquired.
In step S102, input OpenFlow messages to be processed by the event processors are determined according to attribute information of the event processors included in the source code of the SDN application, where a sum of the input OpenFlow messages to be processed by the event processors constitutes all the input OpenFlow messages.
For each incoming OpenFlow message, the following operations are performed:
in step S103, the input OpenFlow message is processed by using a symbolic execution tool corresponding to the language type of the source code, so as to obtain a plurality of executable paths corresponding to the input OpenFlow message, a path constraint condition corresponding to each executable path in the plurality of executable paths, and a first output OpenFlow message set corresponding to each executable path, where the first output OpenFlow message set is a set of output OpenFlow messages corresponding to each executable path.
In step S104, a constraint solver is used to respectively solve the path constraint condition corresponding to each executable path, and based on the solved result, each output OpenFlow message in the first output OpenFlow message set corresponding to each executable path is processed to obtain a second output OpenFlow message set corresponding to each executable path, where the second output OpenFlow message set is a set of output OpenFlow messages obtained by processing each output OpenFlow message in the first output OpenFlow message set.
Fig. 7 is a schematic diagram of a result obtained by operating an event processor for processing an OpenFlow message input as packet _ in by using a symbol execution tool and solving a path constraint condition corresponding to each executable path by using a constraint solver.
Specifically, in step S1031, a relevant variable p included in the input OpenFlow message packet _ in of the SDN application is specified as a symbolic variable λ, that is, the variable p is represented by λ, by using a symbolic execution tool corresponding to the language type of the source code of the second SDN application (insecure application).
In step S1032, the symbol execution tool is utilized to run an event handler for processing the input OpenFlow message as packet _ in, and a plurality of executable paths corresponding to the input OpenFlow message packet _ in, a path constraint condition corresponding to each executable path in the plurality of executable paths, and a first output OpenFlow message set corresponding to each executable path are obtained.
In this example, when λCIs false and λ dst ═ HostFIf false, it corresponds to the first executable path (i.e., the left branch in FIG. 7). When λ, src ═ HostCIs false and λ dst ═ HostFTrue, corresponds to the second executable path (i.e., the second left branch in FIG. 7). When λ, src ═ HostCIs true and λFTrue, corresponds to the third executable path (i.e., the right branch in FIG. 7). When λ, src ═ HostCIs true and λFIf false, it corresponds to the fourth executable path (i.e., the right two branch in FIG. 7). The first executable path to the fourth executable path are multiple executable paths corresponding to the input OpenFlow message packet _ in, and the path constraint condition corresponding to the first executable path is as follows: λ src ═ HostCIs false and λ dst ═ HostFFor false, the path constraint corresponding to the second executable path is: λ src ═ HostCIs false and λ dst ═ HostFThe path constraint corresponding to the third executable path is true: λ src ═ HostCIs true and λFThe path constraint corresponding to the fourth executable path is true: λ src ═ HostCIs true and λFIs false.
The second set of outgoing OpenFlow messages corresponding to the first executable path is an empty set, not shown in fig. 8. A second output OpenFlow message set corresponding to the second executable path is shown in the third row in fig. 8, a second output OpenFlow message set corresponding to the third executable path is shown in the fourth row in fig. 8, and a second output OpenFlow message set corresponding to the fourth executable path is shown in the second row in fig. 8.
It should be noted that the source code of the second SDN application may have thousands of lines, and includes a series of event handlers such as switch _ on, link _ up, etc., and the description is given by taking only an event handler for handling an OpenFlow message as packet _ in as an example.
The contents shown in the following block of fig. 7 are pseudo code of the above-described processing procedure, which means the following:
if the source address (src) of the packet included in the input OpenFlow message packet _ in is the HostCThe address of (1), the second SDN application (unsecure application) inputs OpenFlow message packet _ in to the switch sw1Issue flow table e4((p.src＝HostC,p.dst＝*)→Set(p.src＝HostE) Output (table)). The meaning of the flow table is: arriving switch sw1If the source address (src) of the input OpenFlow message is the HostCAddress of (2), switch sw1Resetting the source address (src) of the message contained in the incoming OpenFlow message to the HostEAfter the address is received, continuing to send the message contained in the input OpenFlow message to the switch sw1The other rules above are matched.
If the destination address (dst) of the message contained in the input OpenFlow message packet _ in is the HostFThe address of (1), the second SDN application (unsecure application) inputs OpenFlow message packet _ in to the switch sw1Issue flow table e5((p.src＝*,p.dst＝HostF)→Set(p.dst＝ServerD) Output (table)). The meaning of the flow table is: arriving switch sw1If the destination address (dst) of the message contained in the input OpenFlow message is the HostFAddress of (2), switch sw1The destination address of the message contained in the input OpenFlow message(dst) reset to network Server (Server)D) After the address is received, continuing to send the message contained in the input OpenFlow message to the switch sw1The other rules above are matched.
If the source address (src) of the packet included in the input OpenFlow message packet _ in is the HostEThe destination address (dst) is a network Server (Server)D) The address of (1), the second SDN application (unsecure application) inputs OpenFlow message packet _ in to the switch sw1Issue flow table e6((p.src＝HostE,p.dst＝ServerD) → fwd (3)). The meaning of the flow table is: arriving switch sw1If the source address (src) of the input OpenFlow message is the HostEThe destination address (dst) is a network Server (Server)D) The address of (3) is then forwarded out the message contained in the input OpenFlow message through the port 3.
In step S105, each output OpenFlow message in the second output OpenFlow message set corresponding to each executable path is processed to obtain a third output OpenFlow message set corresponding to each executable path, where the third output OpenFlow message set is a set of output OpenFlow messages obtained after each output OpenFlow message in the second output OpenFlow message set is processed.
For a second output OpenFlow message set corresponding to each executable path corresponding to an input OpenFlow message packet _ in of a second SDN application (unsecure application), performing the following operations:
here, for the sake of simplicity, the second output OpenFlow message set corresponding to the third executable path is described below as an example.
As can be seen from fig. 8, the second output OpenFlow message set corresponding to the third executable path outputs OpenFlow messages: (
And
) Inclusion in action field of included flow tableWith reset action, output OpenFlow message
The action field of the included flow table does not contain a reset action, and therefore, it is necessary to perform an output OpenFlow message in the second output OpenFlow message set by using a preset composition rule: (
And
) And (6) processing. The specific processing procedure is shown in fig. 9.
First, output OpenFlow messages in the second output OpenFlow message set are output (
And
) It is divided into two groups. First group
Including an outgoing OpenFlow message of
And
the flow table contained in these two outgoing OpenFlow messages contains a reset action in the action field. Second group
Including an outgoing OpenFlow message of
The flow table included in the output OpenFlow message does not include a reset action in the action field.
Then, from the first group
And a second group
Any one of the two output OpenFlow messages is taken, and the two taken output OpenFlow messages are combined. In this example, two combinations may be formed: the combination 1 is:
and
the combination 2 is:
and
then, to
Synthesizing the matching field and the action field of the included flow table to obtain
Composite matching field of included flow table (λ. src ═ Host)Eλ. To pair
Synthesizing the matching field and the action field of the included flow table to obtain
Composite matching field (λ src ═ and λ ═ Server) of the contained flow tablesD)。
For the combination 1, because
Action fields of included flow tables and
none of the action fields of the included flow table contains a delete (del) action, and
the matching field of the included flow table belongs to
A composition matching field of the included flow table, and
and
are all paired switches sw1Operation, then pair
An included flow table and
the matching field, the action field, and the priority field of the included flow table are synthesized. The specific process is as follows:
Based on this, the pair is completed
An included flow table and
the synthesis of the matching field, the action field and the priority field of the included flow table is obtained
(add,sw1,e((λ.src＝HostC,λ.dst＝ServerD) → fwd (3))), and will be removed
Adding to the second group
In (1). Because of the fact that
The included flow table already includes
Forwarding logic of the included flow table, and therefore, will
From the first group
And (4) removing.
For the combination 2, because
Action fields of included flow tables and
none of the action fields of the included flow table contains a delete (del) action, and
the matching field of the included flow table belongs to
A composition matching field of the included flow table, and
and
are all paired switches sw1Operation, then pair
An included flow table and
the matching field, the action field, and the priority field of the included flow table are synthesized. The specific process is as follows:
Based on this, the pair is completed
An included flow table and
the synthesis of the matching field, the action field and the priority field of the included flow table is obtained
(add,sw1,e((λ.src＝HostE,λ.dst＝HostF) → fwd (3))), and will be removed
Adding to the second group
In (1). Because of the fact that
The included flow table already includes
Forwarding logic of the included flow table, and therefore, will
From the first group
And (4) removing.
Based on this, the output OpenFlow message in the third output OpenFlow message set corresponding to the third executable path is:
and
none of the flow tables contained in these outgoing OpenFlow messages contain a reset action in the action field.
The steps are repeatedly executed until the synthesis of each output OpenFlow message in the second output OpenFlow message set corresponding to the second executable path and the synthesis of each output OpenFlow message in the second output OpenFlow message set corresponding to the fourth executable path are completed.
Similarly, respective output OpenFlow messages in a third set of output OpenFlow messages corresponding to each executable path corresponding to each input OpenFlow message of a first SDN application (firewall) may be obtained, as shown in fig. 8.
In step S106, it is detected whether a conflict exists between each two SDN applications by using each output OpenFlow message in the third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of each SDN application.
In this example, the third output OpenFlow message set corresponding to the third executable path corresponding to the input OpenFlow message packet _ in of the second SDN application (unsecure application) contains
(add,sw1,e((λ.src＝HostC,λ.dst＝ServerD) → fwd (3))), a third output OpenFlow message set corresponding to a certain executable path corresponding to a certain input OpenFlow message of a first SDN application (firewall) contains
(add,sw1,e3((λ.src＝HostC,λ.dst＝ServerD) → drop)), and
and
are all paired switches sw1Is operated, and
and
respectively intersecting the source address domain and the destination address domain, and judging that a first SDN application (firewall) conflicts with a second SDN application (unsafe application) if the action domains are different, wherein the actions are influenced by the following steps: the source address included in the input OpenFlow message is HostCThe destination address is ServerDThe message of (2).
By applying the method for detecting the conflict among the plurality of Software Defined Network (SDN) applications, which is provided by the embodiment of the invention, each input OpenFlow message of each SDN application in the plurality of SDN applications to be detected is processed by utilizing the symbol execution tool, and whether the conflict exists between every two SDN applications is detected based on the processing result, so that whether the conflict exists among the SDN applications is detected in advance before the SDN applications are deployed, and the method has a good application prospect.
Those skilled in the art will appreciate that the modules or steps of the invention described above can be implemented in a general purpose computing device, centralized on a single computing device or distributed across a network of computing devices, and optionally implemented in program code that is executable by a computing device, such that the modules or steps are stored in a memory device and executed by a computing device, fabricated separately into integrated circuit modules, or fabricated as a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.
Although the embodiments of the present invention have been described above, the above description is only for the convenience of understanding the present invention, and is not intended to limit the present invention. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (9)
1. A method for detecting conflicts between a plurality of Software Defined Network (SDN) applications, comprising:
for each SDN application in a plurality of SDN applications to be tested, executing the following operations:
acquiring a source code and all input OpenFlow messages of the SDN application;
determining input OpenFlow messages to be processed by each event processor according to attribute information of each event processor contained in a source code of the SDN application, wherein the sum of the input OpenFlow messages to be processed by each event processor forms all the input OpenFlow messages;
for each incoming OpenFlow message, the following operations are performed:
processing the input OpenFlow message by using a symbol execution tool corresponding to the language type of the source code to obtain a plurality of executable paths corresponding to the input OpenFlow message, path constraint conditions corresponding to each executable path in the executable paths, and a first output OpenFlow message set corresponding to each executable path, wherein the first output OpenFlow message set is a set of output OpenFlow messages corresponding to each executable path;
respectively solving the path constraint conditions corresponding to each executable path by using a constraint solver, and processing each output OpenFlow message in a first output OpenFlow message set corresponding to each executable path based on a solving result to obtain a second output OpenFlow message set corresponding to each executable path, wherein the second output OpenFlow message set is a set of output OpenFlow messages obtained after processing each output OpenFlow message in the first output OpenFlow message set;
processing each output OpenFlow message in a second output OpenFlow message set corresponding to each executable path to obtain a third output OpenFlow message set corresponding to each executable path, wherein the third output OpenFlow message set is a set of output OpenFlow messages obtained after processing each output OpenFlow message in the second output OpenFlow message set;
processing each output OpenFlow message in the second output OpenFlow message set corresponding to each executable path to obtain a third output OpenFlow message set corresponding to each executable path, including:
for a second set of output OpenFlow messages corresponding to each executable path corresponding to each input OpenFlow message of each SDN application, performing the following operations:
classifying each output OpenFlow message in the second output OpenFlow message set according to the attribute information of each output OpenFlow message in the second output OpenFlow message set;
processing each output OpenFlow message in the second output OpenFlow message set according to the classification result to obtain a third output OpenFlow message set corresponding to an executable path to which the second output OpenFlow message set belongs;
and detecting whether conflicts exist between every two SDN applications by utilizing each output OpenFlow message in a third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of each SDN application.
2. The method of claim 1, wherein processing an input OpenFlow message with a symbolic execution tool corresponding to a language type of the source code to obtain a plurality of executable paths corresponding to the input OpenFlow message, a path constraint corresponding to each executable path of the plurality of executable paths, and a first output OpenFlow message set corresponding to each executable path comprises:
using a symbolic execution tool corresponding to a language type of source code of the SDN application, designating relevant variables contained in each input OpenFlow message of the SDN application as symbolic variables, wherein the relevant variables are variables required to be used in a process of detecting conflicts among a plurality of SDN applications;
and running each event processor contained in the source code of the SDN application by using the symbol execution tool to obtain a plurality of executable paths corresponding to each input OpenFlow message of the SDN application, a path constraint condition corresponding to each executable path in the executable paths and a first output OpenFlow message set corresponding to each executable path.
3. The method for detecting conflicts between software defined networking, SDN, applications of claim 2, further comprising:
and assigning specific values to independent variables contained in each input OpenFlow message of the SDN application, wherein the independent variables are variables which are not needed to be used in the process of detecting the conflict among the plurality of SDN applications.
4. Method for detecting conflicts between software defined network, SDN, applications according to claim 2 or 3, characterized in that it further comprises:
according to the specific meaning of each domain of a flow table contained in each input OpenFlow message of the SDN application in the software defined network SDN, limiting the value range of each symbol variable contained in each input OpenFlow message of the SDN application in a preset range.
5. The method according to claim 1, wherein a constraint solver is used to solve a path constraint condition corresponding to each executable path, and each output OpenFlow message in a first output OpenFlow message set corresponding to each executable path is processed based on a solution result to obtain a second output OpenFlow message set corresponding to each executable path, and the method comprises:
for each executable path corresponding to each input OpenFlow message of each SDN application, performing the following operations:
solving the path constraint condition corresponding to the executable path by using a constraint solver;
under the condition that the return result of the constraint solver is a solution, giving a specific value obtained by solving to each symbol variable contained in each output OpenFlow message in a first output OpenFlow message set corresponding to the executable path to obtain a second output OpenFlow message set corresponding to the executable path;
and under the condition that the result returned by the constraint solver is not a solution, removing the first output OpenFlow message set corresponding to the executable path to obtain a second output OpenFlow message set corresponding to the executable path, wherein the second output OpenFlow message set is an empty set.
6. The method for detecting conflicts between software defined networking, SDN, applications according to claim 1, wherein the outgoing OpenFlow message contains a flow table with or without a reset action in an action field.
7. The method according to claim 1, wherein the step of processing each output OpenFlow message in the second output OpenFlow message set according to the classification result to obtain a third output OpenFlow message set corresponding to an executable path to which the second output OpenFlow message set belongs includes:
when the action fields of the flow tables contained in the output OpenFlow messages in the second output OpenFlow message set do not contain reset actions, if the output OpenFlow messages in the second output OpenFlow message set are kept unchanged, the output OpenFlow messages contained in a third output OpenFlow message set corresponding to the executable path to which the second output OpenFlow message set belongs are kept consistent with the output OpenFlow messages contained in the second output OpenFlow message set;
when the action fields of the flow tables included in the output OpenFlow messages in the second output OpenFlow message set all contain reset actions, if the output OpenFlow messages in the second output OpenFlow message set are removed, the third output OpenFlow message set corresponding to the executable path to which the second output OpenFlow message set belongs is an empty set.
8. The method according to claim 7, wherein each output OpenFlow message in the second output OpenFlow message set is processed according to the classification result to obtain a third output OpenFlow message set corresponding to an executable path to which the second output OpenFlow message set belongs, and further comprising:
and under the condition that the action domain of the flow table contained in one part of the output OpenFlow messages in the second output OpenFlow message set contains a reset action and the action domain of the flow table contained in the other part of the output OpenFlow messages does not contain the reset action, processing each output OpenFlow message in the second output OpenFlow message set by using a preset synthesis rule to obtain a third output OpenFlow message set corresponding to the executable path to which the second output OpenFlow message set belongs.
9. The method of claim 1, wherein detecting whether a conflict exists between each of the plurality of SDN applications using respective output OpenFlow messages in a third set of output OpenFlow messages corresponding to each executable path corresponding to each input OpenFlow message for each SDN application comprises:
obtaining a first SDN application and a second SDN application from any two SDN applications in a plurality of SDN applications to be tested;
acquiring each output OpenFlow message in a third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of the first SDN application, and each output OpenFlow message in the third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of the second SDN application;
respectively obtaining a first output OpenFlow message and a second output OpenFlow message from a third output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of the first SDN application and from any output OpenFlow message set corresponding to each executable path corresponding to each input OpenFlow message of the second SDN application;
and judging whether the first SDN application and the second SDN application have conflict or not by utilizing a preset judgment rule according to the attribute information of the first output OpenFlow message and the second output OpenFlow message.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811504826.6A CN109725925B (en) | 2018-12-10 | 2018-12-10 | Method for detecting conflicts between multiple Software Defined Network (SDN) applications |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811504826.6A CN109725925B (en) | 2018-12-10 | 2018-12-10 | Method for detecting conflicts between multiple Software Defined Network (SDN) applications |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109725925A CN109725925A (en) | 2019-05-07 |
| CN109725925B true CN109725925B (en) | 2020-09-18 |
Family
ID=66294948
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811504826.6A Active CN109725925B (en) | 2018-12-10 | 2018-12-10 | Method for detecting conflicts between multiple Software Defined Network (SDN) applications |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109725925B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107809381A (en) * | 2017-10-19 | 2018-03-16 | 北京邮电大学 | One kind, which is realized, is based on route loop active auditing algorithm and implementation method in SDN |
| CN108156046A (en) * | 2016-12-06 | 2018-06-12 | 中国移动通信有限公司研究院 | Distributed route detecting method and device |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9973429B2 (en) * | 2013-04-05 | 2018-05-15 | Futurewei Technologies, Inc. | Software defined networking (SDN) controller orchestration and network virtualization for data center interconnection |
| CN104283738B (en) * | 2014-10-11 | 2018-07-17 | 新华三技术有限公司 | A kind of chain circuit detecting method and equipment |
-
2018
- 2018-12-10 CN CN201811504826.6A patent/CN109725925B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108156046A (en) * | 2016-12-06 | 2018-06-12 | 中国移动通信有限公司研究院 | Distributed route detecting method and device |
| CN107809381A (en) * | 2017-10-19 | 2018-03-16 | 北京邮电大学 | One kind, which is realized, is based on route loop active auditing algorithm and implementation method in SDN |
Non-Patent Citations (2)
| Title |
|---|
| 动态符号执行中路径搜索策略的研究与实现;王磊;《中国优秀硕士学位论文全文库 信息科技辑》;《中国学术期刊（光盘版）电子杂志社》;20180415;第9-45页 * |
| 软件定义网络OpenFlow流表优化技术研究;席孝强;《中国优秀硕士学位论文全文库 信息科技辑》;中国学术期刊（光盘版）电子杂志社;20180615;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109725925A (en) | 2019-05-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11902120B2 (en) | Synthetic data for determining health of a network security system | |
| CN109417496B (en) | Automatic service function verification in a virtual network environment | |
| US10587484B2 (en) | Anomaly detection and reporting in a network assurance appliance | |
| US11178009B2 (en) | Static network policy analysis for networks | |
| CN112470431B (en) | Synthesis of models of networks using automatic boolean learning | |
| US11038743B2 (en) | Event clustering for a network assurance platform | |
| US7505463B2 (en) | Rule set conflict resolution | |
| CN110710159B (en) | Methods, systems, devices, and media for network configuration and troubleshooting | |
| US20180351819A1 (en) | Semantic analysis to detect shadowing of rules in a model of network intents | |
| CN111684439B (en) | Network assurance of database version compatibility | |
| US10623271B2 (en) | Intra-priority class ordering of rules corresponding to a model of network intents | |
| CN110741602A (en) | Event generation in response to network intent form peering failure | |
| Kim et al. | Formal verification of SDN-based firewalls by using TLA+ | |
| Tu et al. | Linux network programming with p4 | |
| Chowdhary et al. | Sdn based network function parallelism in cloud | |
| Wang et al. | Rule anomalies detecting and resolving for software defined networks | |
| CN109725925B (en) | Method for detecting conflicts between multiple Software Defined Network (SDN) applications | |
| CN112019361A (en) | Migration method and device of access control list, storage medium and electronic equipment | |
| US20160006605A1 (en) | Network control device and network setting system | |
| Xiaochen et al. | A Fine-Grained Detection Mechanism for SDN Rule Collision | |
| US12086083B2 (en) | Multi-tenant aware data processing units | |
| US20210173938A1 (en) | Security risk reduction method and security risk reduction system | |
| Yao et al. | Model Checking of Software-Defined Networking for Multiple Applications | |
| Zhou | Guided synthesis of network behavior | |
| US7949007B1 (en) | Methods of clustering actions for manipulating packets of a communication protocol |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |