KR20160090485A - Method and apparatus for operating distributed controllers of software defined network - Google Patents

Abstract

The present invention relates to a method where two or more servers distribute a software defined network (SDN) to control the SDN. The method comprises: a step where a first server in which a first controller instance is installed transmits a flow table change item to a second server in which a second controller instance is installed; and a step where the first server transmits the flow table change item to a corresponding switch when the first server receives a reception confirmation message for the flow table change item from the second server. According to the present invention, a storage location change item and a network update can be synchronized between a plurality of servers (instances) realizing distributed controllers of an SDN.

Description

[0001] METHOD AND APPARATUS FOR OPERATING DISTRIBUTED CONTROLLERS OF SOFTWARE DEFINED NETWORK [0002]

The present invention relates to a method and apparatus for controlling a software defined network. More particularly, the present invention relates to a method and apparatus for operating a distributed controller in a software defined network.

The emergence of Software Defined Networking (SDN) is changing the network structure in recent years. Software-defined network technology separates the complexity of the control plane from the data plane, processing the complex functions of the control plane with software, and the data plane is the control plane So that only a simple function of the instruction is performed. With these changes, software can develop new network functions without complex hardware constraints, while at the same time making various attempts that were not possible with previous network architectures.

For example, in an environment such as a cloud network, the function of each network switch or router can be dynamically set to reduce energy consumption. In an enterprise network environment, a desired access control method can be implemented for each switch or router. This can reduce the number of equipment used in existing networks and equipment management costs. You can freely test newly developed functions.

Communication between the controller responsible for the control plane (i.e., the control device) and the switch responsible for the data plane is accomplished through the international standard OpenFlow protocol. A switch supporting an open flow protocol performs a simple operation such as transferring a packet to another switch, transferring the packet to a control device, or discarding the packet according to a predetermined rule, when a packet is delivered.

In a software defined network, a message sent by a switch to a control device, or a message sent by the application of the control device to each other is called an event of the control device.

An example of an event delivered to the controller is as follows. If there is a new flow in the flow table without a processing rule, a packet in event (packet in) occurs, and when the network switch is turned off, a connection down event occurs. When the topology of a software defined network changes, a topology change event occurs. When the network switch is turned on due to the turn-on or failure of the network switch, a connection up event occurs. The application of the control device is software that performs the appropriate operation for such an event.

It is an object of the present invention to provide a method and apparatus for operating a distributed controller in an SDN environment.

Further, the present invention provides a method and apparatus for synchronizing repository changes and network updates among a plurality of servers (instances) implementing SDN's distributed controller so that consistency of the network and the controller can be maintained even if one or more instances fail, And to provide the above-mentioned objects.

A method for distributing and controlling a software defined network by two or more servers according to an embodiment of the present invention includes the steps of distributing a flow table change to a second server that has installed a second controller instance Transmitting; When the first server receives the acknowledgment message for the flow table change from the second server, transmitting the flow table change to the corresponding switch.

Meanwhile, a method in which two or more servers according to an embodiment of the present invention distribute and control a software defined network is characterized in that a second server installing a second controller instance receives a flow table change request from a first server installing a first controller instance ; The second server storing the flow table changes and sending an acknowledgment message for the flow table changes to the first server; And when the second server receives the checkpoint time point information from the first server, deleting the flow table change of the first server received before the time of the checkpoint.

Further, a method for distributing and controlling a software defined network by two or more servers according to an embodiment of the present invention includes: a step in which a first server installing a first controller instance stores flow table changes in a shared repository; Storing a flow table change in the shared repository, the second server having installed the second controller instance; And transmitting the flow table change of the first server stored in the shared storage to the second server when the second server recognizes the failure of the first server. do.

A system including two or more servers that distribute and control a software defined network according to an embodiment of the present invention includes a first server having a first controller instance installed therein; And a second server in which a second controller instance is installed, the first server sending a flow table change to the second server, receiving an acknowledgment message for the flow table change from the second server And transmits the flow table change to the corresponding switch.

A system including two or more servers that distribute and control a software defined network according to an embodiment of the present invention includes: a first server in which a first controller instance is installed; And a second server in which a second controller instance is installed, the second server stores a flow table change received from the first server, and transmits to the first server an acknowledgment message for the flow table change Upon receipt of the checkpoint point-in-time information from the first server, deletes the flow-table change item of the first server received before the checkpoint point, recognizes the fault of the first server, 1 < / RTI > of the server to the corresponding switch.

Further, a computer program stored in a medium for executing a process of distributing and controlling a software defined network in two or more servers according to an embodiment of the present invention may be configured such that, in a first server in which a first controller instance is installed, 2 controller instance to the second server that installed it; And transmitting the flow table change message to the corresponding switch when receiving the acknowledgment message for the converted flow table change message from the second server in the first server.

A computer program stored in a medium for executing a process of distributing and controlling a software defined network in two or more servers according to an embodiment of the present invention includes a first controller instance installed in a second server in which a second controller instance is installed Receiving a flow table change from a first server; Storing the flow table change in the second server and transmitting an acknowledgment message for the flow table change to the first server; And a function of deleting a flow table change item of the first server received before the checkpoint time when the second server receives the checkpoint time point information from the first server.

According to the present invention, it is possible to synchronize storage changes and network updates among a plurality of servers (instances) implementing a distributed controller of the SDN. Further, according to the present invention, even if any one of the instances fails, the consistency of the network and the controller can be maintained, and the software defined network can be stably controlled.

1 is a diagram for explaining the configuration of a software defined network;
2 is a diagram for explaining an operation method of a distributed controller of a software defined network;
3 is a diagram for explaining a problem that may occur when a controller server (instance) fails;
4 is a flowchart for explaining a specific method of operating a distributed controller according to an embodiment of the present invention
5 is a view for explaining an example of operating a distributed controller according to another embodiment of the present invention

It is to be understood that the present invention is not limited to the description of the embodiments described below, and that various modifications may be made without departing from the technical scope of the present invention. In the following description, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail.

In the drawings, the same components are denoted by the same reference numerals. And in the accompanying drawings, some of the elements may be exaggerated, omitted or schematically illustrated. It is intended to clearly illustrate the gist of the present invention by omitting unnecessary explanations not related to the gist of the present invention. Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a diagram for explaining a configuration of a software defined network.

As shown in FIG. 1, a software defined network may include an SDN control device 100, an open flow switch 200, and a terminal 300. An open flow switch 200 and a terminal 300, and a link may refer to a connection between two nodes.

The control device 100 commands the switch 200, and the switch 200 can perform processing such as transmitting, modifying, or discarding a packet to a destination according to the command. The terminal 300 may generate a packet for transmission to another terminal through a software defined network and transmit the packet to the switch 200 through a port of the network interface.

When the open flow switch 200 receives a packet from the terminal 300 or another switch 200, it can switch packets based on the flow table. At this time, if there is no flow entry for packet switching in the flow table, the network switch 200 can transmit a flow rule request message to the control device 100. [ In the present specification, the open flow switch 200 should be understood as a concept including a switch supporting only an open flow protocol, a virtual switch supporting an open flow protocol, and a general L2 switch supporting an open flow protocol.

Meanwhile, the SDN of FIG. 1 can be configured as a plurality of servers according to the implementation, and is called a distributed controller. If the network is controlled by a single controller server, it is highly likely that if the server fails, the network operation is stopped, so the controller is installed on more than one server to distribute the risk to the server.

In a distributed controller environment, controllers are installed on two or more servers, and controller servers can cooperate to control the network. In a distributed controller environment, each controller installed on the server is called a controller instance.

2 is a diagram for explaining a method of operating a distributed controller of a software defined network. The SDN according to an embodiment of the present invention may include one or more controller servers 210 and 220 and switches 230 to 260, respectively, which implement controller instances as shown in FIG.

2, each of the controller instances 210 and 220 in the distributed controller environment may have a repository, which includes information about the status of the controller application and the operation of the application, Command, state of the switch, and the like.

The repository may be contained within the controller software, or it may be implemented using other software products, such as a distributed database or file system.

In the SDN of FIG. 2, the first controller instance 210 controls switches 230 and 240, and the second controller instance 220 controls switches 250 and 260. In this case, when a flow rule change occurs on the controlling switch, the controller instance sends the flow rule changes to the switch and then writes them to the storage, or writes the flow rule changes to the storage and sends them to the switch Lt; / RTI >

In such a distributed controller environment, if one of the controllers fails, another controller can recover the operation of the failed controller to ensure the stability of the entire network operation. Distributed controllers also have the purpose of distributing the risk of failures that can occur in the controller instance.

For example, if the first controller instance 210 in the SDN configuration of FIG. 2 applies a flow rule change to the switch 230, and the server 210 fails, then the second controller instance 220 should be able to inherit the job of 210 will be. In other words, if a failure occurs in 210, 220 can succeed in the operation of 230 that the application of the failed server has processed, so that the software defined network can be operated stably.

That is, in a distributed controller environment, even if one controller server fails, it is necessary to design the other controller server to recover from the failure that occurs. However, at present, there is a very shortage of the recovery technology of the distributed controller, which is a stumbling block to stable SDN operation.

FIG. 3 is a diagram for explaining a problem that may occur when a controller server (instance) in the related art fails.

FIG. 3A illustrates a case where the first controller instance transmits a change to the switch, and then writes the change to the storage, and transmits the change to the second controller instance.

In this case, if a failure occurs in the first controller server immediately after the change is transmitted to the switch, a problem arises that the switch is updated but the second controller instance, which needs to control the switch, can not recognize the update contents. That is, the update of the switch and the stored contents of the controller become inconsistent.

FIG. 3B illustrates a case where the first controller instance transmits the change to the second controller instance while recording the change in the storage, and then operates in such a manner that the change is transmitted to the switch.

In this case, if a failure occurs in the first controller server immediately after the change is transmitted to the second controller, the switch is not updated, but the contents of the update are recorded in the storage of the first controller instance, The state of the switch is recognized. That is, in the case of A and B, the update of the switch and the contents stored in the controller may be inconsistent.

According to the conventional method, there arises a problem that the consistency between the network and the controller can not be guaranteed in the event of a failure. The open flow protocol does not support fully synchronizing the update of the switch with the transmission of the controller instance. Therefore, such a phenomenon may occur frequently, and the application is inconsistent or bug-prone when a failure occurs.

In most conventional commercial products, if a failure occurs, the failure is recovered by deleting and initializing all flow rules and controller instance storage on the switch. Because the state of the store just before the failure and the state of the current switch can not be fully identified and synchronized, if the controller server fails, the switch and the storage of the distributed controller are fully initialized.

However, as mentioned above, the failure recovery method through the initialization inevitably takes a lot of time and resources to restore the network to a normal state. Furthermore, even when developing an application for a controller, it is very inefficient because it is necessary to consider a case where a failure occurs in the controller instance.

Accordingly, the present invention proposes a method of synchronizing update contents of a switch and storage contents of a controller instance in an SDN distributed controller environment. This is to enable the distributed controller to stably control the software defined network by ensuring consistency between the switch and the controller even if one controller instance fails.

More specifically, according to the present invention, any controller instance (primary controller) of the distributed controller can change the flow of a rule change, such as link up / down, to a storage change or any switch, (Second controller), and when receiving an acknowledgment message from another controller instance, the switch is updated.

Further, according to the present invention, when a failure occurs in the first controller, the contents of the first controller can be restored based on the changes received by the second controller, and the switch can be updated.

A method of operating the distributed controller according to the present invention will be described in detail below with reference to FIG. 4 attached hereto.

4 is a flowchart for explaining an example of operating a distributed controller according to an embodiment of the present invention. In the example of FIG. 4, the SDN distribution controller includes a first controller and a second controller, and the switch is under the control of the first controller in a normal situation.

Meanwhile, FIG. 4 shows one switch under the control of the first controller, but this is for convenience of description, and the present invention is not limited thereto. That is, in the software defined network according to the embodiment of the present invention, each controller instance can control a plurality of switches, and the switch shown in Fig. 4 means any switch under the control of the first controller in a normal situation .

If a change occurs in the switch controlled by the first controller in step 410 of FIG. 4, the first controller may convert the flow rule change to have a power-equality in step 412 and transmit it to the second controller.

The reason for converting the flow rule changes to have power equality is that if the first controller fails and the second controller repairs the failure, the first controller determines whether flow rule changes have been applied to the switch Regardless of whether the second controller also applies flow-rule changes to the switch.

According to the open flow protocol, the flow mode command can be classified as shown in Table 1 below.

Command value Explanation OFPFC_ADD 0 Add new flow rules OFPFC_MODIFY One Modify all matched flow rules OFPFC_MODIFY_STRICT 2 Match only match with priority (priority) OFPFC_DELETE 3 Delete all matched flow rules OFPFC_DELETE_STRICT 4 Only remove matching matches and priorities

In Table 1, except for the OFPFC_MODIFY and OFPFC_MODIFY_STRICT commands, all flow rule commands have a power equality. This is because no change occurs in the flow table when the flow rule already existing in the flow table is added again or when a non-existing flow rule is deleted.

Therefore, according to the present invention, the first controller can convert OFPFC_MODIFY or OFPFC_MODIFY_STRICT of all the rules into a change using OFPFC_ADD and OFPFC_DELETE so as to have a power equality, and transmit the change to the second controller.

More specifically, the process of modifying a specific flow rule to another flow rule has the same effect as the process of adding another flow rule after deleting the flow rule. As described above, since the flow rule deletion and addition commands have the exponentiation, if the flow rule deletion and additionally indicate the change, the change is guaranteed to be equal to the power.

The second controller that received the change in step 414 may record it and may transmit an acknowledgment message in step 416. More specifically, the second controller can apply the storage changes to the storage and write the switch changes to memory, disk, and the like.

In step 418, the first controller can acknowledge the acknowledgment message and then apply the change to the switch. That is, according to the present invention, the first controller reflects the changed contents after the second controller records the changed contents, and it is impossible to guarantee that the changed contents are not lost if the opposite order is set.

In steps 420 to 425, a checkpoint time point is generated to reduce the amount of changes to be restored when a failure occurs. According to the present invention, each of the controller instances can minimize the recovery object by assuming that the changes recorded before the checkpoint time have already been reflected in the network, and release the record or delete the record.

More specifically, in step 420, the first controller sends a barrier request message (Barrier, OFPT_BARRIER_REQUEST message) to one or more switches it controls, and in step 422 the switch can send a barrier response message (OFPT_BARRIER_REPLY message) to the first controller have.

When the barrier request is transmitted and the response is received due to the nature of the protocol, the commands before the barrier are reflected in the switch, and therefore, the present invention sets the transmission time point of the barrier to the checkpoint time point.

Accordingly, in step 423, the first controller provides the second controller with information on the time of transmitting the barrier request message as checkpoint information, and in step 425, the second controller deletes the record 1 received prior to the checkpoint time. According to another embodiment of the present invention, in step 425, the second controller records in its own storage that the storage of the received record 1 does not need to be maintained before the checkpoint time, or the storage of the record 1 It can be recognized that there is no need to maintain.

According to the present invention, such checkpoint information can be transmitted when it satisfies any condition such as a predetermined period or the amount of change occurring after the most recent checkpoint exceeds a predetermined range.

Steps 430 to 438 are the same as the steps 410 to 418 when another change 2 occurs.

More specifically, if a second change occurs in the switch controlled by the first controller in step 430, the first controller may convert the flow rule change to have a power-equality and transmit the change to the second controller in step 432.

The second controller records it in step 434, and if the first controller confirms the acknowledgment message in step 436, it can apply change 2 to the switch in step 438.

On the other hand, if a third change occurs in the switch controlled by the first controller in step 440, the first controller likewise can convert the third change to have a power equality in step 442 and transmit it to the second controller. In step 444, the second controller records it, and in step 445, it can transmit an acknowledgment message to the first controller.

At this time, it is possible to consider a case where a failure occurs in the first controller in step 446. If change 3 is not yet applied to the switch, if the first controller fails, the contents of the first and second controllers are different from the update status of the switch. However, according to the present invention, because the second controller has a record of the changes having a power equality, the second controller can easily recover the fault by applying the change to the switch.

For example, if a second controller is selected as the controller to proceed with the recovery operation, the second controller can apply the change received from the failed first controller to the switch. That is, if a fault occurs in the first controller in step 446, the fault is recovered in such a manner that the second controller reflects the records 2 and 3 after the check point time to the switch.

At step 450, the second controller may apply change 2 to the switch according to record 2. This is already applied to the switch by the first controller, but since the change 2 stored in the second controller has a power equality, the correct result is assured even once again.

Thereafter, in step 455, the second controller may apply change 3 to the switch according to record 3. This is an issue that the first controller has not been completed due to a failure before being applied to the switch, so that the second controller can maintain consistency between the network and the controller.

According to another embodiment of the present invention, only the changes satisfying predetermined conditions can be set to be transmitted / received between the controller instances. This is because each controller instance sending all changes to another controller instance can degrade the performance of the entire network.

For example, the network operator can set the condition of the recovery target flow rule in consideration of the priority of the flow rule to be restored in the event of a failure, and set only the change satisfying the condition to be transmitted to another controller.

According to the above embodiment, when a fault occurs in an arbitrary controller instance, the flow rule of a predetermined condition is surely restored, but the restoration of other flow rules is not guaranteed, so that the function of the distributed controller can be provided.

5 is a view for explaining an example of operating a distributed controller according to another embodiment of the present invention.

According to another embodiment of the present invention, as shown in FIG. 5, a shared storage 500 may be operated between the first controller 210 and the second controller 220. Since each time a switch is changed, sending changes to another controller instance and acknowledging it can be a burden on the overall network performance, it is running shared storage 500.

According to the above-described embodiment, there is no need to synchronize the controller instances each time, so that the cost of recording changes in controller instances in different controller instances to a memory or disk is reduced, and the performance of the entire network is improved.

In the example of FIG. 5, any controller instance may store the switch changes in the shared storage 500 (network disk or database server) and then apply the changes to the switch. Furthermore, storage changes can be cumulatively stored in a shared repository according to a predetermined cycle.

If any controller instance fails in the future, the recovery controller reads the changes recorded by the fault controller from the shared storage and proceeds to the recovery process as shown in FIG. 4.

In the example of FIG. 5, if 210 wishes to apply a flow rule change to 230 or / and 240, 210 may convert the change to have a power of equality and store it in 500. Further, 210 may store accumulated repository changes in 500 at preset intervals.

If a failure occurs at 210, then 220 can proceed to recovery by applying flow rule changes to 230 and / or 240 by referring to the changes recorded at 500 through 210.

The embodiments of the present invention disclosed in the present specification and drawings are intended to be illustrative only and not intended to limit the scope of the present invention. It is to be understood by those skilled in the art that other modifications based on the technical idea of the present invention are possible in addition to the embodiments disclosed herein.

100: SDN control device
200: Open flow switch
300: terminal

Claims (11)

A method for distributed control of a software defined network by two or more servers,
The first server installing the first controller instance sends a flow table change to the second server that installed the second controller instance;
And when the first server receives the acknowledgment message for the flow table change from the second server, transmitting the flow table change to the corresponding switch. The method according to claim 1,
The first server transmitting a barrier request message (OFPT_BARRIER_REQUEST message) to the switch according to a predetermined period or condition; And
When the first server receives a barrier response message (OFPT_BARRIER_REPLY message) from the switch, transmitting information on a transmission time point of the barrier request message to the second server with checkpoint time point information Control method. 2. The method of claim 1, wherein the step of transmitting the flow table change comprises:
The first server converting the flow table changes to have a power equality; And
And transmitting the flow table change information converted by the first server to the second server. 4. The method of claim 3,
Wherein the first server is a step of converting only a flow table change satisfying a preset condition so as to have a power equality. A method for distributed control of a software defined network by two or more servers,
Receiving a flow table change from a first server that installed the first controller instance, the second server having installed the second controller instance;
The second server storing the flow table changes and sending an acknowledgment message for the flow table changes to the first server;
And when the second server receives the checkpoint time point information from the first server, deleting the flow table change point of the first server received prior to the check point time point. 6. The method of claim 5,
And when the second server recognizes the failure of the first server, transmitting a flow table change of the first server stored in the second server to the second server by the second server . A method for distributed control of a software defined network by two or more servers,
The first server having installed the first controller instance stores the flow table changes in a shared repository;
Storing a flow table change in the shared repository, the second server having installed the second controller instance; And
And transmitting the flow table change of the first server stored in the shared storage to the second server when the second server recognizes the failure of the first server. Control method. 1. A system comprising two or more servers that distributively control a software defined network,
A first server in which a first controller instance is installed; And
A second server in which a second controller instance is installed,
Wherein the first server transmits the flow table change to the second server and upon receiving the acknowledgment message for the flow table change from the second server, Characterized by a control system. 1. A system comprising two or more servers that distributively control a software defined network,
A first server in which a first controller instance is installed; And
A second server in which a second controller instance is installed,
Wherein the second server stores the flow table change information received from the first server and transmits an acknowledgment message for the flow table change to the first server, Upon receipt, the flow table change information of the first server received before the checkpoint time is deleted, and if the failure of the first server is recognized, the flow table change of the stored first server is transmitted to the corresponding switch Characterized by a control system. A computer program stored in a medium for executing a process of distributing and controlling a software defined network in two or more servers,
Transmitting, at a first server that installed the first controller instance, a flow table change to a second server that installed the second controller instance; And
Wherein the first server executes a function of transmitting the flow table change message to a corresponding switch upon receiving an acknowledgment message for the converted flow table change message from the second server. A computer program stored in a medium for executing a process of distributing and controlling a software defined network in two or more servers,
Receiving, at a second server where a second controller instance is installed, a flow table change from a first server that installed the first controller instance;
Storing the flow table change in the second server and transmitting an acknowledgment message for the flow table change to the first server; And
And when the second server receives the checkpoint time point information from the first server, executes a function of deleting a flow table change of the first server received before the time of the check point.

Images