KR20230136078A - Device and method for checking policy conflict on sdn - Google Patents

Abstract

An SDN policy conflict checking device and method are disclosed. The SDN policy conflict check method is a SDN policy conflict check method performed by an SDN (Software-Defined Networking) controller, comprising the steps of receiving a policy, generating a flow rule from the policy, and creating a flow rule from the policy. It includes determining whether there is a conflict between the flow rule and a plurality of flow rules included in the flow table.

Description

SDN policy conflict checking device and method {DEVICE AND METHOD FOR CHECKING POLICY CONFLICT ON SDN}

The present invention relates to software-defined networking (SDN), and more specifically, to an algorithm and implementation system for checking policy conflicts in the NB (North-Bound) of SDN.

In a 5G network, rules can be issued to the SDN controller from various VNFs, including security policies, QoS rules, and firewall policies issued based on SDN/NFV. Even if an error does not occur in each independent VNFs program, if various applications are executed on the SDN controller, conflicts may occur due to inconsistent rules in the SDN switches.

If a conflict occurs due to inconsistent rules in a 5G network using SDN/NFV as the core technology, verification is necessary because errors may occur throughout the network. SDN provides a programmable environment to dynamically configure or manage the network. And by separating the data plane and control plane, you can manage the data plane from the control plane. In SDN, the policy desired by the administrator is sent to the data plane through the control plane. At this time, the policy may not be visible or unwanted results may appear on the network due to internal regulations in the controller. Using the ONOS controller, administrators can issue policies through the NB (NorthBound) API (Application Programming Interface). The issued policies are preferentially filtered by the controller to prevent conflicts. However, policy conflicts may occur if the order of policies that are interrelated is reversed. These collisions cannot be controlled by the controller. Therefore, policies that cannot be controlled by the controller have a potential risk of conflict, so it is very important to resolve these conflicts before the policy is issued. In the present invention, the SDN controller, ONOS (Open Networking Operating System) controller, is used to show the above problems and solve the problem of correlation conflict occurring when a policy is issued.

Republic of Korea Patent Publication No. 2016-0121087 (published on October 19, 2016)

The technical problem to be achieved by the present invention is to provide a device and method that can check whether there is a policy conflict in SDN.

The SDN policy conflict check method according to an embodiment of the present invention is a SDN policy conflict check method performed by an SDN (Software-Defined Networking) controller, comprising the steps of receiving a policy and receiving a flow rule from the policy. It includes a step of generating, and a step of determining whether there is a conflict between the generated flow rule and a plurality of flow rules included in the flow table.

In the case of the SDN policy conflict checking device and method according to an embodiment of the present invention, it is possible to prevent network errors in advance by checking in advance whether there is a conflict between a newly received policy and an existing policy.

Additionally, administrators can make policies through SDN's NB (NorthBound) API (Application Programming Interface). The issued policies are preferentially filtered by the controller to prevent conflicts. However, policy conflicts may occur if the order of policies that are interrelated is reversed. These collisions cannot be controlled by the controller. Therefore, policies that cannot be controlled by the controller have a potential risk of conflict, so it is very important to resolve these conflicts before the policy is issued.

In the present invention, the SDN controller, ONOS (Open Networking Operating System) controller, was used to solve the above problems and, among other problems, the problem of correlation conflict occurring when a policy is issued.

In order to more fully understand the drawings cited in the detailed description of the present invention, a detailed description of each drawing is provided.
Figure 1 shows the SDN architecture.
Figure 2 shows the structure of the ONOS controller.
Figure 3 is a functional block diagram of a policy conflict check device according to an embodiment of the present invention.
FIG. 4 is a flowchart illustrating a policy conflict check method performed by the policy conflict check device shown in FIG. 3.

Specific structural or functional descriptions of the embodiments according to the concept of the present invention disclosed in this specification are merely illustrative for the purpose of explaining the embodiments according to the concept of the present invention. They may be implemented in various forms and are not limited to the embodiments described herein.

Since the embodiments according to the concept of the present invention can make various changes and have various forms, the embodiments will be illustrated in the drawings and described in detail in this specification. However, this is not intended to limit the embodiments according to the concept of the present invention to specific disclosed forms, and includes all changes, equivalents, or substitutes included in the spirit and technical scope of the present invention.

Terms such as first or second may be used to describe various components, but the components should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another component, for example, without departing from the scope of rights according to the concept of the present invention, a first component may be named a second component and similarly a second component The component may also be named a first component.

When a component is said to be “connected” or “connected” to another component, it is understood that it may be directly connected to or connected to that other component, but that other components may also exist in between. It should be. On the other hand, when it is mentioned that a component is “directly connected” or “directly connected” to another component, it should be understood that there are no other components in between. Other expressions that describe the relationship between components, such as "between" and "immediately between" or "neighboring" and "directly adjacent to" should be interpreted similarly.

The terms used in this specification are only used to describe specific embodiments and are not intended to limit the invention. Singular expressions include plural expressions unless the context clearly dictates otherwise. In this specification, terms such as “comprise” or “have” are intended to designate the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in this specification, but are not intended to indicate the presence of one or more other features. It should be understood that this does not exclude in advance the possibility of the existence or addition of elements, numbers, steps, operations, components, parts, or combinations thereof.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the technical field to which the present invention pertains. Terms as defined in commonly used dictionaries should be interpreted as having meanings consistent with the meanings they have in the context of the related technology, and unless clearly defined in this specification, should not be interpreted in an idealized or overly formal sense. No.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings attached to this specification. However, the scope of the patent application is not limited or limited by these examples. The same reference numerals in each drawing indicate the same members.

SDN (Software Defined Networking) is an approach that controls and manages the delivery of network traffic through an open API in a software-based controller. As shown in Figure 1, SDN, unlike existing network architecture, consists of an Infrastructure Layer (Data Plane) that transmits traffic between each node, a Control Layer (Control Plane) that specifies the path of traffic, and an Application Layer. It is done. The Control Plane communicates with the Application Layer using the NB (Northbound) Core API and with the Infrastructure Layer using the SB (Southbound) Core API. Because SDN has separate layers, it is designed to be easy to centralize control and management, and to be programmable through software. Therefore, it is one of the key controllable technologies that can quickly and easily adapt the network to suit user requirements. These SDN controllers include ONOS, Pox, Ryu, and Open Day Light. The present invention uses an ONOS Controller capable of configuring NB and SB API functions. However, the scope of the present invention is not limited thereto.

ONOS Controller is an open source-based SDN Controller that controls the OpenFlow protocol in the SDN control plane and manages switches, links, and software programs and modules. ONOS is a hierarchical structure in which the control plane is divided into Northbound and Southbound based on the Distributed Core as shown in Figure 2 in order to improve high availability, safety, reliability, and scalability. The Application Layer communicates using the NB (Northbound) Core API provided by Northbound, and policies can be made by programming the network through the interface. The Infrastructure Layer communicates with providers using the SB (Southbound) Core API provided by Southbound, and FlowRule, which is a reinterpretation of the policy issued by the Application Layer, is installed in the FlowTable of the switch (device). Because ONOS Controller instances have the same service and independent data storage, network status information can be quickly exchanged and accessed. Additionally, data stores maintain the same data between stores by performing synchronization, allowing data to be quickly recovered even if an error occurs in any instance.

A policy is an abstract policy made by the user at the application layer of SDN. Therefore, policies cannot be sent directly to the switch (device). Therefore, in an SDN controller (e.g., ONOS controller), the policy is transferred from the application part to the data plane and is rewritten as a flow rule by the controller's flow rule generator. It is interpreted.

The Internet Engineering Task Force (IETF) policy model specifies network policy with rules that specify actions to be taken when certain conditions are met, as shown below.

Network Policy

IF<condition(s)> Then <action(s)>

Figure 3 is a functional block diagram of a policy conflict check device according to an embodiment of the present invention.

Referring to FIG. 3, the policy conflict check device 100 is a computing device including at least a processor and/or memory, and may mean an SDN controller, for example, an Open Networking Operating System (ONOS) controller. . The policy conflict check device 100 may include at least one of a policy receiver 110, a flow rule generator 120, a conflict checker 130, and a storage unit 140.

The policy receiving unit 110 may receive a predetermined policy (police). The policy may be received from an administrator through a predetermined input/output interface, or may be received from at least one host via at least one switch. The received policy may be stored in the storage unit 140.

The flow rule generator 120 may generate a flow rule (FlowRule) corresponding to the received policy. A flow rule can mean that the abstract policy issued by the user in the application layer of the SDN controller is reinterpreted as a rule that is transmitted to the data plane by the flow rule generator. there is. Accordingly, the flow rule generator 120 may also be called a flow generator. The flow rule can be configured as shown in Equation 1.

[Equation 1]

FlowRule r = (P,I,A,C,D)

In other words, the tuple of the flow rule is P(Priority), I(Device ID), A(Action), C(Condition), and D(Duration) of FlowRule r. duration). In ONOS Controller, FlowRule is managed by Subsystem's FlowRuleService API. These management steps include Pending_Add, Added, Pending_Removed, Removed, and Failed. The Pending_Add stage is a state in which the subsystem has received a request from the application to install a FlowRule, but the FlowRule has not been added to the switch. In the Added stage, a FlowRule is added to the FlowTable of the switch (Device) by the Flow Rule Provider. In the Pending_Remove stage, a request to remove a FlowRule has been received from the application, but the FlowRule has not yet been removed from the switch. In the Removed stage, the Switch's FlowRule has been removed and the Subsystem has confirmed the removal and removed the FlowRule from the storage. The Failed stage indicates that the switch failed to install FlowRule.

The conflict check unit 130 can check (detect, determine) whether there is a conflict between the generated flow rule and at least one flow rule stored in the flow table. The specific operation of the collision check unit 130 will be described later.

The storage unit 140 may store an operating system (OS), program, source code, app (or application), algorithm, etc. necessary for the operation of the policy conflict check device 100. In addition, the storage unit 140 contains the policy received by the policy receiving unit 110, the flow rule created by the flow rule generating unit 120, the collision check result by the collision checking unit 130, the flow table, etc. It can be saved.

FIG. 4 is a flowchart illustrating a policy conflict check method performed by the policy conflict check device shown in FIG. 3.

Referring to Figures 3 and 4, the policy receiving unit 110 of the policy conflict check device 100 receives the policy (S110). The policy received by the policy receiving unit 110 may be stored in the storage unit 140.

Afterwards, the flow rule generator 120 of the policy conflict check device 100 may generate a flow rule corresponding to the received policy (S120). In this way, as a flow rule for a policy is created, it can be checked whether there is a conflict between at least one flow rule stored in the flow table and the created flow rule.

As the flow rule is created, the conflict check unit 130 of the policy conflict check device 100 may check whether the generated flow rule collides with the flow rule in the flow table (S130 to S60).

First, the collision check unit 130 compares the device IDs of the generated flow rule and the target flow rule (S130). Here, the target flow rule may mean any one flow rule stored in the flow table. At this time, if the device IDs of the two flow rules are not the same, step S130 is performed again after replacing the target flow rule. In other words, a comparison process with other flow rules included in the flow table is performed. This iterative process is performed repeatedly until comparison of all flow rules included in the flow table is completed, and if a flow rule with the same device ID does not exist, the created flow rule is inserted into the flow table. You can. In other words, the generated flow rule can be judged as a flow rule that does not conflict with the existing flow rule.

In step S130, if the device IDs of the two flow rules are the same, the conditions of the generated flow rule and the target flow rule are compared (S140). At this time, if the conditions of the two flow rules are not the same, step S130 is performed again after replacing the target flow rule. In other words, a comparison process with other flow rules included in the flow table is performed. This iterative process is performed repeatedly until comparison of all flow rules included in the flow table is completed, and if a flow rule with the same conditions does not exist, the generated flow rule can be inserted into the flow table. . In other words, the generated flow rule can be determined to be a flow rule that does not conflict with the existing flow rule.

In step S140, if the conditions of the two flow rules are the same, the priorities of the generated flow rule and the target flow rule are compared (S150). At this time, if the priorities of the two flow rules are not the same, step S130 is performed again after replacing the target flow rule. In other words, a comparison process with other flow rules included in the flow table is performed. This iterative process is performed repeatedly until comparison of all flow rules included in the flow table is completed, and if a flow rule with the same priority does not exist, the created flow rule can be inserted into the flow table. there is. In other words, the generated flow rule can be determined to be a flow rule that does not conflict with the existing flow rule.

In step S150, if the priorities of the two flow rules are the same, the liquid lines are compared (S160). At this time, if the actions of the two flow rules are the same, the two flow rules are determined to be equal rules. In this case, among the two flow rules, the flow rule with the longer duration is inserted into the flow table. That is, if the duration of the generated flow rule is greater than the duration of the target flow rule, the target flow rule can be deleted from the flow table and the generated flow rule can be inserted. Conversely, if the duration of the created flow rule is less than the duration of the target flow rule, the target flow rule is maintained without being deleted, and the created flow rule is not inserted into the flow table. Since the flow rules are the same, the duration time is compared and only one flow rule is maintained in the flow table.

In step S160, if the actions of the two flow rules are different from each other, it is determined that a correlation conflict occurs, in which the two flow rules conflict with each other. In this case, flow rules with a large duration can be maintained in the flow table. Specifically, if the duration of the generated flow rule is greater than the duration of the target flow rule, the target flow rule can be deleted from the flow table and the generated flow rule can be inserted. Conversely, if the duration of the created flow rule is less than the duration of the target flow rule, the target flow rule is maintained without being deleted, and the created flow rule is not inserted into the flow table. Since the flow rules conflict with each other, the duration time is compared and only one flow rule is maintained in the flow table.

The device described above may be implemented as a hardware component, a software component, and/or a set of hardware components and software components. For example, devices and components described in the embodiments include, for example, a processor, a controller, an Arithmetic Logic Unit (ALU), a Digital Signal Processor, a microcomputer, a Field Programmable Array (FPA), It may be implemented using one or more general-purpose or special-purpose computers, such as a Programmable Logic Unit (PLU), microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. Additionally, a processing device may access, store, manipulate, process, and generate data in response to the execution of software. For ease of understanding, a single processing device may be described as being used; however, those skilled in the art will understand that a processing device may include multiple processing elements and/or multiple types of processing elements. It can be seen that it may include. For example, a processing device may include a plurality of processors or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are also possible.

Software may include a computer program, code, instructions, or a combination of one or more of these, and may configure a processing unit to operate as desired, or may be processed independently or collectively. You can command the device. Software and/or data may be used on any type of machine, component, physical device, virtual equipment, computer storage medium or device to be interpreted by or to provide instructions or data to a processing device. , or may be permanently or temporarily embodied in a transmitted signal wave. Software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., singly or in combination. Program instructions recorded on the medium may be specially designed and configured for the embodiment or may be known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. -Includes specially configured hardware devices to store and execute program instructions, such as magneto-optical media, ROM, RAM, flash memory, etc. Examples of program instructions include machine language code, such as that produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

The present invention has been described with reference to the embodiments shown in the drawings, but these are merely illustrative, and those skilled in the art will understand that various modifications and other equivalent embodiments are possible therefrom. For example, the described techniques are performed in a different order than the described method, and/or components of the described system, structure, device, circuit, etc. are combined or combined in a different form than the described method, or other components are used. Alternatively, appropriate results may be achieved even if substituted or substituted by an equivalent. Therefore, the true scope of technical protection of the present invention should be determined by the technical spirit of the attached registration claims.

100: Policy conflict check device
110: Policy receiver
120: Flow rule generation unit
130: collision check unit
140: storage unit

Claims (12)

In the SDN policy conflict check method performed by the SDN (Software-Defined Networking) controller,
receiving a policy;
Creating a flow rule from the policy; and
Including determining whether there is a conflict between the generated flow rule and a plurality of flow rules included in the flow table,
How to check policy conflict. According to paragraph 1,
The step of determining whether there is a conflict is,
Comprising the step of comparing the device ID of the generated flow rule with the device ID of the target flow rule among the plurality of flow rules,
How to check policy conflict. According to paragraph 2,
When the device ID of the generated flow rule and the device ID of the target flow rule are the same, comparing the condition of the generated flow rule with the condition of the target flow rule,
How to check policy conflict. According to paragraph 3,
When the conditions of the generated flow rule and the conditions of the target flow rule are the same, comparing the priority of the generated flow rule and the priority of the target flow rule,
How to check policy conflict. According to paragraph 4,
When the priority of the generated flow rule is the same as the priority of the target flow rule, comparing the action of the generated flow rule and the action of the target flow rule,
How to check policy conflict. According to clause 5,
If the action of the generated flow rule and the action of the target flow rule are the same and the duration of the generated flow rule is greater than the duration of the target flow rule, the target flow rule is deleted from the flow table and the generated Further comprising inserting the flow rule into the flow table,
How to check policy conflict. According to clause 5,
If the action of the generated flow rule and the action of the target flow rule are the same and the duration of the generated flow rule is less than the duration of the target flow rule, the target flow rule is maintained in the flow table and the generated Further comprising the step of not inserting the flow rule into the flow table,
How to check policy conflict. According to clause 5,
If the action of the generated flow rule and the action of the target flow rule are not the same and the duration of the generated flow rule is greater than the duration of the target flow rule, the target flow rule is deleted from the flow table and the Further comprising inserting the generated flow rule into the flow table,
How to check policy conflict. According to clause 5,
If the action of the generated flow rule and the action of the target flow rule are not the same and the duration of the generated flow rule is less than the duration of the target flow rule, the target flow rule is maintained in the flow table and the Further comprising the step of not inserting the generated flow rule into the flow table,
How to check policy conflict. According to paragraph 2,
In the step of comparing the device IDs, if the device ID of the generated flow rule and the device ID of the target flow rule are not the same, the step of changing the target flow rule and comparing the device IDs is performed again.
How to check policy conflict. According to paragraph 3,
In the step of comparing the conditions, if the conditions of the generated flow rule and the conditions of the target flow rule are not the same, changing the target flow rule and performing the step of comparing the device ID again.
How to check policy conflict. According to paragraph 4,
In the step of comparing the priorities, if the priorities of the generated flow rule and the target flow rule are different, only the flow rule with a higher priority among the generated flow rule and the target flow rule is used in the flow. kept on the table,
How to check policy conflict.

Images