JP2015138987A - Communication system and service restoration method in communication system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a communication system and service restoration method in the communication system for canceling a failure state at an early stage to make it possible to resume packet transfer, in the case of having detected occurrence of a Byzantine type failure.SOLUTION: A communication system comprises: a first controller 10 for controlling a plurality of packet transfer devices on the basis of a flow control function and virtual network setting information; a second controller 20 which includes a flow control function having an actual operation result and virtual network setting information having an actual operation result and becomes a destination of changeover in the case that a failure occurs in the first controller 10; and a load distribution device 30 disposed between each controller and the plurality of packet transfer devices. The load distribution device 30 includes a role changeover instruction function 31 for making the second controller 20 execute control of the plurality of packet transfer devices in the case that a Byzantine type failure occurs in the first controller 10.

Description

  The present invention relates to a communication system including a control device that controls a plurality of packet transfer apparatuses and a service restoration method in the communication system.

  In the SDN (Software-Defined Networking) field such as OpenFlow, packet transfer in a network (NW) is controlled by a single controller. In such fields, techniques for increasing the availability of controllers have been proposed. For example, Patent Document 1 describes a technique for equalizing the loads of a plurality of controllers arranged in an OpenFlow network.

  In the open flow (OpenFlow), the data plane and the control plane are separated, and an OFC (OpenFlow Controller) centrally manages the network. In order to further increase the availability in such a configuration, it is necessary to provide means for quickly recovering work when a failure occurs in the OFC. However, at the present time, there are few proposals for technologies related to recovery from failures that occur in computer systems, especially from Byzantine-type failures.

  In general, failures that occur in a computer system can be classified into two types: “silent failure” and “byzantine failure”.

  Silent failure refers to a case where a response cannot be returned to a request from another node. On the other hand, a Byzantine-type failure refers to a case where the output with respect to the input has become incorrect or the output with respect to the input has become unreliable.

  A silent failure in OFC is considered to be a state in which a response cannot be returned to a request from an OFS (OpenFlow Switch), a management client, or the like. A silent failure in the OFC occurs when a fatal failure occurs or when an excessive load is applied. The means for recovering from this silent failure has already been devised and put into practical use. For example, the OFC is made redundant by cluster software (cluster SW), and when a silent failure occurs, the process is continued by failing over to a standby node.

  On the other hand, a Byzantine failure in OFC is considered to be a state in which an unintended flow is set in the OFS due to some factor, and an unintended packet transfer process is performed.

  Before moving on to details of Byzantine failure countermeasures, the background technologies are: (I) normal operation processing in a single OFC configuration, (II) restart processing in a single OFC configuration, and (III) failover processing in a cluster OFC configuration. Will be described.

(I) Normal operation processing in a single OFC configuration

  A single OFC configuration, that is, a system configuration when the OFC is not redundant will be described. FIG. 9 is a block diagram illustrating an example of a single OFC configuration in the OpenFlow system. The OFC 100 manages a plurality of OFSs 101 to 103. The OFSs 101 to 103 hold unique flow tables 113 to 115, respectively. Each flow table stores a finite number of flow entries. The packet entry rule is described in the flow entry. The OFC 100 holds a configuration 110, a topology 111, and a flow table 112.

  The OFC 100 holds as many flow tables as the number of subordinate OFSs. Further, the contents of the flow table 112 held by the OFC 100 and the flow tables 113 to 115 held by the OFSs 101 to 103 are always synchronized. Further, the flow table 112 of the OFC 100 is volatilized in processing such as restarting the OFC.

  The configuration 110 is information (configuration information) indicating a configuration, and describes settings of a virtual network. The OpenFlow network administrator can change the settings of the virtual network by appropriately operating the OFC. That is, the config is information that is changed during the operation of the OFC. Also, the config can usually be saved. Therefore, the config does not volatilize in processing such as restarting the OFC.

  The topology 111 is information indicating the topology (topology information) and is information created by the OFC using the topology detection function. The topology 111 is updated when the network configuration is changed, such as switch addition or redundancy. Further, the topology 111 is volatilized in processing such as restart of the OFC.

  Here, the basic operation of the OFC 100 will be described. FIG. 10 is a block diagram illustrating an example of the configuration of the OFC 100.

  The OFC 100 includes a communication unit 201, an OF (OpenFlow) protocol processing unit 202, a topology detection unit 203, a configuration management unit 205, and a path management unit 207.

  The OF protocol processing unit 202 uses the communication unit 201 to perform communication according to the OpenFlow protocol with a plurality of OFS.

  The topology detection unit 203 uses the OF protocol processing unit 202 to create information indicating the topology of the network (topology 204 shown in FIG. 10). The topology detection unit 203 transmits an LLDP (Link Layer Discovery Protocol) packet to all of the subordinate OFSs. The OFS sends the received LLDP packet from all ports. When a cable is connected to the OFS port and the cable is connected to another OFS, the connection destination OFS notifies the OFC 100 of the PACKET_IN message of the LLDP packet. The OFC 100 receives this PACKET_IN message and obtains connection information between OFS ports. The OFC 100 can acquire the topology of the network by collecting all the connection information. The topology detection unit 203 can detect a change in topology due to addition of OFS or insertion / removal of cables by periodically sending out LLDP. Each time, the topology detection unit 203 updates the topology.

  The configuration management unit 205 updates the information indicating the configuration (the configuration 206 illustrated in FIG. 10) in accordance with the virtual network setting change operation by the user.

  The route management unit 207 includes a route calculation unit 209, a route setting unit 210, and an audit unit 211.

  When performing flow control by open flow, it is necessary to first set a flow for appropriately transferring at least broadcast or multicast packets in OFS. This flow (hereinafter referred to as BC / MC (BroadCast / MultiCast) flow) is updated in accordance with changes in topology and configuration. The route calculation means 209 calculates a BC / MC flow when the system is started or when the topology or configuration is updated, and sets the BC / MC flow in the flow table (flow table 208 shown in FIG. 10).

  When a flow entry is added to the flow table, the route setting unit 210 notifies the OFS of the addition of the flow entry.

  When a packet arrives at the OFS, if there is a flow entry in which information (header information) such as a destination address and a source address written in the header of the packet matches the matching condition, the OFS is described in the flow entry. Process the packet as it was done. This process is called hard transfer. In the flow entry, as the packet transfer rule, processing conditions such as the above-described conformance conditions and sending the packet from a certain port are described.

  On the other hand, when a packet arrives at the OFS and there is no flow entry that matches the header information of the packet, the OFS inquires the OFC 100 about the processing method of the packet. The route management unit 207 that has received the inquiry message from the OFS inputs the topology, configuration, and header information of the packet to the route calculation unit 209, and derives a flow entry that defines the processing method of the packet. After the route management unit 207 adds this flow entry to the flow table 208, the route setting unit 210 adds the flow entry to the OFS flow table. The OFS performs processing such as transfer and discard according to the added flow entry. This process is called soft transfer. Soft transfer has poorer performance than hard transfer because it includes flow entry derivation processing.

  In addition, the OFS flow table has a function of deleting a flow entry that has not been hit for a certain period of time. In this function, OFS identifies and deletes flow entries that do not hit the default time. Thereafter, the OFS notifies the OFC 100 that the flow entry has been deleted. Receiving the notification, the route management unit 207 deletes the flow entry from the flow table.

  In this way, the OFC flow table and the OFS flow table are updated while maintaining synchronization. However, when the connection between the OFC and OFS is lost, the table synchronization is lost. Therefore, when the OFC and OFS are connected again, the process of synchronizing the table is executed again by the auditing means 211. This process is called an audit process. The audit means 211 mainly uses the flow table held on the OFC side and corrects the difference generated in the slave OFS side flow table.

  As described above, in order for the OpenFlow system to perform flow control, the OFC needs to hold the configuration, topology, and flow table, and the OFS needs to hold the flow table synchronized with the OFC.

(II) Restart processing in single OFC configuration

  A process when the OFC is restarted in the single OFC configuration (I) will be described. FIG. 11 is an explanatory diagram showing a service stop time due to an OFC restart when a silent failure occurs in a single OFC configuration, that is, a time from when the OFC restarts until packet transfer is restarted.

  When the OS of the OFC is restarted, communication between the OFC and OFS is disconnected. The OFS that has detected the disconnection continues to retry the connection to the OFC. When the OFC is activated, the configuration, topology, and flow table held by the OFC are all empty. Therefore, in the OFC, first, it is necessary to reload the saved configuration (configuration reload processing 300) and create the topology (topology information creation processing 301). When these processes are completed, the OFC can derive a BC / MC flow entry (BC / MC flow entry derivation process 302). The OFC receives a connection request from the OFS after this processing is completed. Since a difference occurs between the OFC and OFS flow tables while the communication between the OFC and OFS is disconnected, the OFC performs an audit (audit process 303). By this audit process, the flow entry set before the restart is deleted, and only the BC / MC flow is registered.

  As described above, when the OFC is restarted in the single OFC configuration, the flow control by the open flow becomes possible after the processing 300 to 303 is completed. After the service is resumed, software transfer is performed.

(III) Failover processing in cluster OFC configuration

  In OFC, the cluster method has already been put into practical use in order to cope with a silent failure. Here, a cluster OFC configuration, that is, a system configuration in which an OFC is clustered (redundant) will be described. FIG. 12 is a block diagram illustrating an example of a cluster OFC configuration in the OpenFlow system. With reference to FIG. 12, the failover process in the cluster OFC configuration will be described.

  Two OFC nodes, OFC (ACT) 400 and OFC (SBY) 401, constitute a cluster system by cluster middleware. Note that “ACT (ACTIVE)” represents the active system. “SBY (STANDBY)” represents a standby system. A unique address is assigned to each of OFC (ACT) 400 and OFC (SBY) 401. A unique virtual address is assigned to the cluster system.

  First, the cluster middleware associates a virtual address with the address of the OFC (ACT) 400. The OFSs 403 to 405 are connected to the OFC (ACT) 400 as a result by connecting to the virtual address. Thus, flow control by open flow is performed by the OFC (ACT) 400 and OFS 403 to 405. The OFC (ACT) 400 holds a configuration 410, a topology 411, and a flow table 412. These pieces of information are updated in the same manner as the above “(I) Normal operation processing in the single OFC configuration”. The OFC (SBY) 401 also holds a configuration 413, a topology 414, and a flow table 415. These pieces of information held in the OFC (SBY) 401 are always synchronized with the corresponding information held in the OFC (ACT) 400 by the mirror disk function and the memory synchronization function provided in the cluster middleware.

  The OFC (ACT) 400 and the OFC (SBY) 401 are connected by a LAN cable and periodically communicate (heartbeat communication) to confirm that the opposite node is operating normally.

  When a silent failure occurs, the OFC (ACT) 400 cannot continue heartbeat communication, and communication is disconnected due to a timeout or the like. The cluster middleware that detected the disconnection of the hard beat communication disconnects the communication established between the virtual address and the OFS. When the OFS detects disconnection, it repeatedly retries to establish communication with the virtual address in order to connect to the OFC again.

  On the other hand, the cluster middleware stops the service on the OFC (ACT) 400 side, starts the service on the OFC (SBY) 401 side, and associates the virtual address with the address of the OFC (SBY) 401. As a result, the OFS can establish communication with the OFC (SBY) 401. The configuration 413, the topology 414, and the flow table 415 of the OFC (SBY) 401 are the latest information because they are synchronized with those of the OFC (ACT) 400 side. Accordingly, the OFC (SBY) 401 does not require processing such as configuration reload, topology detection, and BC / MC flow entry derivation, which are necessary in the case (I). In other words, OFC (SBY) 401 requires only an audit process for eliminating the difference that occurred while the communication between OFS and OFC was disconnected, and packet transfer is possible after the audit process is completed. It should be noted that the hardware transfer is performed when the service is resumed.

  FIG. 13 is an explanatory diagram showing a service stop time in a failover process when a silent failure occurs in the cluster OFC configuration, that is, a time from when node switching is started until packet transfer is restarted. As shown in FIG. 13, in the cluster OFC configuration, the service can be restarted only by the node switching process 500 and the audit process 501 by the cluster middleware.

Reissue WO2013 / 114490

  Considering the basic operation of OFC described in (I) to (III) above, a Byzantine failure in OFC will be considered.

  Byzantine failure in OFC, for example, is a situation where flow control falls into an untrustworthy state where the system administrator may forward the packet as intended or may forward the packet unintentionally. is there. That is, an unintended flow entry has been derived and registered in the flow table. Such a state can occur in the following cases.

(A) An invalid configuration has been set. For example, when there is a mistake in the configuration setting work, or when a logical network that intentionally includes a security hole is set by an insider.

(B) The OFC function (for example, the route derivation function or the topology detection function) is illegal. For example, there is a potential bug in the OFC, or the OFC function has been tampered with by an unauthorized user.

  In the configuration described in (I) to (III), it is difficult to recover from a Byzantine failure. In the case of (A), the OFC is restarted once, the corrected configuration is read again, and the service is restarted, so that the illegal flow set in the OFS can be wiped out and the failure state can be eliminated. However, at least the service stop time shown in FIG. 11 occurs. In the case of (B), the service can be resumed by performing a necessary process such as newly preparing an OFC from which bugs and tampering have been removed and loading a configuration. However, a service stop time that is a total of at least the time for removing bugs and tampering and the time shown in FIG. 11 occurs. In either case, a service stop time of the order shown in FIG. 11 occurs.

  Therefore, an object of the present invention is to provide a communication system and a service restoration method in the communication system that can resolve a failure state at an early stage and resume packet transfer when the occurrence of a Byzantine failure is detected.

  The communication system according to the present invention includes a first control device that controls a plurality of packet transfer devices based on a flow control function and virtual network setting information, a flow control function that has an operation record, and a virtual that has an operation record. Load setting disposed between a plurality of packet transfer devices and each control device, and a second control device that is a switching destination when a failure occurs in the first control device. The load distribution device has a role change instruction function that causes the second control device to execute control of a plurality of packet transfer devices when a Byzantine failure occurs in the first control device. And

  The service restoration method according to the present invention has a first control device that controls a plurality of packet transfer devices based on a flow control function and virtual network setting information, a flow control function that has an operation record, and an operation record. Load that is set between a plurality of packet transfer devices and each control device, and a second control device that is a switching destination when a failure occurs in the first control device. In a communication system including a distribution device, the load distribution device causes a second control device to execute control of a plurality of packet transfer devices when a Byzantine failure occurs in the first control device. To do.

  According to the present invention, when the occurrence of a Byzantine-type failure is detected in the communication system, the failure state can be resolved early and packet transfer can be resumed.

It is a block diagram which shows the structure of 1st Embodiment of the communication system by this invention. It is explanatory drawing which shows an example of an address conversion table. It is a block diagram which shows the structure of OFC in 1st Embodiment. It is a flowchart which shows the switching operation of OFC in a load balancer. It is explanatory drawing which shows an example of the address conversion table updated in step S5. It is explanatory drawing which shows the service stop time accompanying recovery when a Byzantine type | mold failure generate | occur | produces in the communication system of 1st Embodiment. It is explanatory drawing which shows the structure of 2nd Embodiment of the communication system by this invention. It is a block diagram which shows the minimum structure of the communication system by this invention. It is a block diagram which shows an example of the single OFC structure in an open flow system. It is a block diagram which shows an example of a structure of OFC. It is explanatory drawing which shows the service stop time by the OFC restart when a silent failure occurs in the single OFC configuration. It is a block diagram which shows an example of the cluster OFC structure in an open flow system. It is explanatory drawing which shows the service stop time in the failover process when a silent failure occurs in a cluster OFC configuration.

Embodiment 1. FIG.
A first embodiment of the present invention will be described below with reference to the drawings.

  In the present embodiment, a multi-controller function implemented by the OpenFlow protocol Ver1.2 is used to perform open flow control in the active system, and always derive topology information and BC / MC flow entries in the standby system. Will be described as an example.

  In the present embodiment, an OFC (hereinafter referred to as a second OFC) that is a switching destination when a Byzantine failure occurs, in addition to a clustered OFC (hereinafter referred to as a first OFC). Deploy. Also, a load balancer (LB) is arranged between the OFS and the first OFC / second OFC so that the OFS connection destination OFC can be switched by the operation of the load balancer.

  As the second OFC, an OFC that does not have bugs or tampering with the route derivation or topology detection function, that is, an OFC having a reliable OFC function is prepared. For example, the second OFC is prepared based on the following concept.

When a bug is found in the OFC node that constitutes the first OFC, an OFC with a modified bug is prepared and used as the second OFC. Or, there is already a sufficient operation record and the quality is stable, or an old version of the OFC is used as the second OFC.
-Use an OFC that has been applied with a security policy that is stricter than the first OFC and that has been provided with countermeasures against unauthorized operations such as function tampering as the second OFC. For example, the second OFC is set so that only a more limited user can access it, and the second OFC is placed in a more protected network.

  In addition, reliable configuration information is loaded in the second OFC. For example, a reliable configuration is defined based on the following concept.

・ Configurations with sufficient operation results ・ Configurations set so that they cannot be updated ・ Simple configurations that can easily tamper with

  As described above, in this embodiment, the second OFC is managed so as to always have the most reliable OFC function and the most reliable configuration information. The first OFC and the second OFC are asymmetric.

  The topology information is not information that can be managed by OFC, but is information that is generated by transmitting an LLDP packet to the OFS and obtaining a response. In the present embodiment, the communication system is configured so that the topology information can always be obtained with the first OFC and the second OFC. Thereby, in the second OFC, a BC / MC flow entry can be always derived from the reliable OFC function and configuration information and the latest topology information. As a result, the communication system can shorten the service stop time at the time of switching.

  FIG. 1 is a block diagram showing a configuration of a first embodiment of a communication system according to the present invention. 1 are the same as the elements shown in FIG. 12, and detailed description thereof is omitted.

  As shown in FIG. 1, the communication system includes a first OFC 600, a second OFC 603, and a load balancer 604. In FIG. 1, three OFSs (OFSs 608 to 610) are connected to the load balancer 604, but any number of OFSs may be connected to the load balancer 604.

  The first OFC 600 is an OFC node configured redundantly by cluster middleware. The first OFC 600 includes an OFC (ACT) 601 and an OFC (SBY) 602. Note that the first OFC 600 may be configured redundantly with two or more OFCs.

  The configuration 611, topology 612, and flow table 613 held by the OFC (ACT) 601 are synchronized with the configuration 614, topology 615, and flow table 616 held by the OFC (SBY) 602, respectively.

  In the present embodiment, in addition to the first OFC 600 dealing with a silent failure, the second OFC 603 handles a Byzantine failure. As described above, the second OFC 603 has a reliable OFC function and configuration information. The second OFC is not limited to one, and a plurality of second OFCs may be arranged.

  When the OFSs 608 to 610 connect to the OFC, each OFS connects in a manner that allows communication with a plurality of OFCs. Each OFS communicates with a plurality of OFCs using, for example, a multi-controller function defined in the OpenFlow protocol Ver1.2 standard.

  In the multi-controller function, each OFC is assigned a role. The OFC given the role of “Master” has the authority to receive a message from the OFS and respond to the message and update the flow entry of the OFS. On the other hand, the OFC given the role of “Slave” can receive a message from the OFS, but does not return a response to the message. That is, the slave OFC cannot update the OFS flow table.

  The load balancer 604 has a role change instruction function 605 described later. The role change instruction function 605 is realized by a CPU of a computer that operates according to a program, for example. For example, the program is stored in a storage device (not shown) of the load balancer 604. The CPU of the load balancer 604 reads the program and operates as the role change instruction function 605 according to the program.

  The load balancer 604 gives virtual addresses to the master OFC and the slave OFC, respectively. Further, the load balancer 604 manages the association with the actual address of the OFC (hereinafter referred to as a real address) using the address conversion table 606. The NW address translation function 607 of the load balancer 604 refers to the address translation table 606 and rewrites the transmission destination / destination information in the packet header. FIG. 2 is an explanatory diagram illustrating an example of an address conversion table.

  In the initial state, the address conversion table 606 is as shown in FIG. The OFS can access the first OFC 600 as a result by accessing the virtual address 1 of the load balancer 604. Further, by accessing the virtual address 2 of the load balancer 604, it is possible to access the second OFC 603 as a result.

  Each OFS has two address information of a master and a slave as address information of the OFC to be connected. Each OFS sets the virtual address 1 of the load balancer 604 as the master OFC address, and sets the virtual address 2 as the slave OFC. By doing so, communication by the open flow protocol is established between the first OFC 600 and OFS, and flow control becomes possible. On the other hand, the second OFC 603 can receive the OpenFlow message issued from the OFS.

  The OFCs (OFC (ACT) 601, OFC (SBY) 602, second OFC 603 of the first OFC 600) in the present embodiment have a “role management function” and an “extended OF protocol processing unit”.

  FIG. 3 is a block diagram showing the configuration of the OFC in the first embodiment. The function of the OFC will be described with reference to FIG. 3 are the same as the elements shown in FIG. 10, and detailed descriptions thereof are omitted.

  The OFC 700 shown in FIG. 3 has an extended OF protocol processing means 701 and a role management function 702 in addition to the components included in the OFC 100 shown in FIG.

  The role management function 702 is a function that manages whether the OFC (OFC 700) performs an operation as a master or a slave.

  When the OFC 700 is set to operate as a master, the role management function 702 instructs the extended OF protocol processing unit 701 to accept all OpenFlow messages, perform necessary processing, and return a response. .

  On the other hand, when the OFC 700 is set to operate as a slave, the role management function 702 instructs the extended OF protocol processing unit 701 to discard other than the LLDP PACKET_IN message in the received OpenFlow message. By doing so, the slave side, that is, the OFC 700 to which the role of “slave” is given, can receive only messages necessary for topology detection. When the slave receives the LLDP PACKET_IN message, when the topology is updated, a BC / MC flow entry is derived and set in the flow table.

  The extended OF protocol processing unit 701 and the role management function 702 are realized by a CPU of a computer that operates according to a program, for example. The program is stored in a storage device (not shown) of the OFC 700, for example. The CPU of the OFC 700 reads the program and operates as the extended OF protocol processing unit 701 and the role management function 702 according to the program. Further, the extended OF protocol processing means 701 and the role management function 702 may be realized by separate hardware.

  Next, the operation of this embodiment will be described.

  First, an operation in which the load balancer 604 switches the controller from the first OFC to the second OFC when a Byzantine failure occurs will be described.

  There can be various means for detecting the occurrence of a Byzantine-type failure. For example, the occurrence of a Byzantine-type failure can be detected in the following cases.

・ When the CPU usage rate of OFC (ACT) increases abnormally. In this case, there is a possibility that a large number of unintended flow settings have been performed for some reason.
-The number of flow entries set in the OFS flow table has increased abnormally. In this case, there is a possibility that many unintended flows are set.

  When a Byzantine failure occurs, the load balancer 604 switches the OFC as follows. FIG. 4 is a flowchart showing the OFC switching operation in the load balancer 604.

  First, the system administrator uses the role change instruction function 605 of the load balancer 604 to instruct the load balancer 604 to change the role of each controller. That is, the role change instruction function 605 inputs a role change instruction of each controller from the system administrator via an operation unit (not shown) or the like (step S1).

  Note that the load balancer 604 may detect the occurrence of a Byzantine-type failure and start the processing after step S2. For example, when the load balancer 604 can monitor the CPU usage rate of the OFC, it can be determined that a Byzantine failure has occurred when the CPU usage rate exceeds a predetermined threshold. Further, for example, when the load balancer 604 can acquire the number of OFS flow entries, it can be determined that a Byzantine failure has occurred when the number of the flow entries exceeds a predetermined threshold.

  The load balancer 604 disconnects the communication established between the load balancer 604 and OFS (step S2). At this time, the load balancer 604 stops accepting the connection request from the OFS, and does not respond to the connection request from the OFS until step S6 is completed.

  The role change instruction function 605 notifies the role management function of the first OFC 600 to operate as a slave (step S3). Thereafter, the first OFC 600 receives only the LLDP PACKET_IN message.

  The role change instruction function 605 notifies the role management function of the second OFC 603 to operate as a master (step S4). Thereafter, the second OFC 603 receives all OpenFlow messages.

  The role change instruction function 605 updates the address conversion table 606 and sets the physical address of the second OFC 603 as the real address of the master. Also, the virtual address of the first OFC 600 is set as the real address of the slave (step S5). FIG. 5 is an explanatory diagram showing an example of the address conversion table 606 updated in step S5.

  The load balancer 604 resumes accepting a connection request from the OFS (step S6).

  A connection is established between the OFS and the second OFC 603, and communication using the OpenFlow protocol is established (step S7). A connection is also established between the OFS and the first OFC 600, and the first OFC 600 receives only the LLDP PACKET_IN message.

  The second OFC 603 executes an audit process (step S8). As a result, the flow table 619 of the second OFC 603 is synchronized with the flow tables 620 to 622 of the OFS. That is, only the BC / MC flow is set in the OFS, and the unintended flow set before the OFC switching is wiped out.

  Through the processing in steps S1 to S8, the communication system shown in FIG. 1 can resume the flow control with the reliable OFC and configuration information. Note that software transfer is performed immediately after service restart.

  As described above, in this embodiment, when a Byzantine failure occurs in the master OFC, the slave OFC having the most reliable OFC function and the most reliable configuration information is operated as the master. As a result, it is possible to recover from a Byzantine-type failure caused by two causes: the configuration information shown in (A) above, and the OFC function shown in (B) above.

  In this embodiment, the slave OFC receives a message required for topology detection and derives a BC / MC flow entry. Thereby, when the role of the OFC is switched from “slave” to “master”, BC / MC flow entry derivation processing or the like is not required in the OFC, and the service stop time can be shortened. With regard to the service stop time associated with the recovery from the Byzantine failure, if there is no particular countermeasure, at least the service stop time as shown in FIG. 11 occurs. According to this embodiment, the service stop time as shown in FIG. Become. FIG. 6 is an explanatory diagram illustrating a service stop time associated with recovery when a Byzantine failure occurs in the communication system according to the first embodiment.

  Further, the present invention can be applied as a disaster recovery measure by disposing the second OFC in a place away from the first OFC, for example, in a rack, a different floor, and a different DC from the first OFC.

Embodiment 2. FIG.
Hereinafter, a second embodiment of the present invention will be described with reference to the drawings.

  In this embodiment, a communication system including an OFC that controls an OFS that does not use the multi-controller function is taken as an example. OFS that does not use the multi-controller function can only send messages to a single controller. That is, the topology information can be detected only by the first OFC. FIG. 7 is an explanatory diagram showing the configuration of the second embodiment of the communication system according to the present invention.

  The configuration of the communication system shown in FIG. 7 is the same as that of the first embodiment.

  However, the load balancer 1107 does not have a role change instruction function. The OFC (ACT) 1101, OFC (SBY) 1102, and second OFC 1103 of the first OFC 1100 have topology change event transmission / reception functions 1104, 1105, and 1106, respectively, instead of the role management function and the extended OF protocol processing means. Have.

  The load balancer 1107 manages a single virtual address using the NW address translation function 1108. That is, the load balancer 1107 manages the association between the single virtual address and the real address of the OFC in the address conversion table 1109. In the example illustrated in FIG. 7, “LB virtual IP address” is set as the single virtual address. In addition, “virtual address of the first OFC” is set as the actual address of the OFC. The OFSs 1108 to 1110 connect to the single virtual address of the load balancer 1107.

  The load balancer 1107 relays the packet to the first OFC 1100 or the second OFC 1103 according to the address conversion table 1109.

  The OFC connected to the OFS 1110 to 1112 performs open flow control. Further, when the received OpenFlow message is an LLDP PACKET_IN message, each OFC notifies the opposite OFC node of the message using the topology change event transmission / reception function. Accordingly, it is possible to generate topology information even in an OFC node that has not directly received the OpenFlow message, and as a result, it is possible to always derive a BC / MC flow entry.

  In this way, node switching can be executed by setting the address of the switching destination OFC in the real address of the address conversion table held by the load balancer. That is, according to the present embodiment, if there is no bug or falsification in the OFC OF protocol processing means or the like and there is no possibility that an error is included in the message transmitted to the opposite node, a simple configuration as shown in FIG. Thus, the same effect as that of the first embodiment can be obtained.

  Note that the topology change event transmission / reception function (topology change event transmission / reception functions 1104, 1105, and 1106) of each OFC is realized by a CPU of a computer that operates according to a program, for example. The program is stored in, for example, a storage device (not shown) of each OFC. Each OFC CPU reads the program and operates as a topology change event transmission / reception function (topology change event transmission / reception function 1104, 1105, 1106) according to the program.

  As mentioned above, although the communication system applied to OpenFlow in each embodiment was taken as an example, the present invention is applicable to other than OpenFlow. For example, the OFC in each embodiment may be a control device other than the controller in the open flow. Further, for example, the OFS in each embodiment may be a packet transfer apparatus other than the switch in the open flow. That is, the present invention can be applied to any communication system in which the control device centrally manages each packet transfer device on the communication network.

  Next, the outline of the present invention will be described. FIG. 8 is a block diagram showing a minimum configuration of a communication system according to the present invention. The communication system according to the present invention controls a plurality of packet transfer apparatuses based on a flow control function (for example, an OFC function in an open flow) and virtual network setting information (for example, configuration information in an open flow). It has a control device 10 (corresponding to the first OFC 600 shown in FIG. 1), a flow control function with an operation record, and virtual network setting information with an operation record, and a failure occurs in the first control device 10 In this case, the second control device 20 (corresponding to the second OFC 603 shown in FIG. 1), which is the switching destination, and the load distribution device 30 (see FIG. 1) arranged between the plurality of packet transfer devices and each control device. Load balancer 604), and when the Byzantine failure occurs in the first control device 10, the load balancer 30 includes a plurality of load balancers 604. The control of the packet transfer device having a second control unit 20 function change instruction function to be executed in 31 (equivalent to the role change instruction function 605 in the load balancer 604 shown in FIG. 1).

  According to such a configuration, when a Byzantine fault occurs in the first control device, the second control device having the most reliable flow control function and the most reliable network setting information is operated. be able to. Thereby, for example, in OpenFlow, it is possible to recover from a Byzantine-type failure that originates from two causes: configuration information corruption and OFC function corruption. Therefore, in the communication system, when the occurrence of a Byzantine failure is detected, the failure state can be resolved early and packet transfer can be resumed.

  Further, the role change instruction function 31 of the load distribution device 30 determines that a Byzantine failure has occurred in the first control device when the CPU usage rate of the first control device 10 exceeds a predetermined threshold. May be. According to such a configuration, a Byzantine-type failure can be detected more reliably, and the failure state can be resolved earlier and packet transfer can be resumed.

  Further, during normal operation, the first control device 10 operates as a master that receives all messages transmitted from a plurality of packet transfer devices, and the second control device 20 detects topology from the plurality of packet transfer devices. The role changing instruction function 31 of the load balancer 30 operates as a slave when the Byzantine failure occurs in the first controller 10. The second controller 20 may be operated as a master. According to such a configuration, the second control device can transmit information necessary for appropriately transmitting broadcast or multicast packets necessary for starting flow control as a master (for example, BC / MC flow in open flow). ) Can be calculated and held during slave operation.

  Further, each control device, based on a role change instruction from the load balancer 30, manages a role management function for managing whether to operate the device as a master or a slave (in the role management function 702 shown in FIG. 3). Equivalent). According to such a configuration, the load balancer can change the role of each control device only by outputting a role change instruction.

  Further, when the role management function of the second control device 20 receives a message necessary for topology detection (for example, an LLDP PACKET_IN message in an open flow) during slave operation, the role management function operates as a master based on the message. A flow necessary for starting (for example, a BC / MC flow in an open flow) may be created. According to such a configuration, when the second control device 20 starts the flow control as the master, it is not necessary to create a flow necessary for starting the operation as the master. It can be shortened.

  When each control device determines that the message received from the packet transfer device is a message necessary for topology detection, the topology change event transmission / reception function (topology shown in FIG. 7) notifies the other control device of the message. It may have a change event transmission / reception function 1104 to 1106). According to such a configuration, the failure state can be resolved early and the packet transfer can be restarted when the occurrence of a Byzantine-type failure is detected with a simpler configuration.

  Further, the first control device 10 may be configured in a cluster by a plurality of control devices (for example, OFC (ACT) 601 and OFC (SBY) 602 shown in FIG. 1). According to such a configuration, the communication system can cope with not only a Byzantine type failure but also a silent type failure.

DESCRIPTION OF SYMBOLS 10 1st control apparatus 20 2nd control apparatus 30 Load distribution apparatus 31,605 Role change instruction | indication function 100,700 OFC
101-103, 403-405, 608-610, 1110-1112 OFS
110, 206, 410, 413, 611, 614, 617 Config 111, 204, 411, 414, 612, 615, 618 Topology 112, 113-115, 208, 412, 415, 417-419, 613, 616, 619, 620 to 622 flow table 201 communication means 202 OF protocol processing means 203 topology detection means 205 configuration management means 207 route management means 209 route calculation means 210 route setting means 211 auditing means 400, 601, 1101 OFC (ACT)
401, 602, 1102 OFC (SBY)
600, 1100 First OFC
603, 1103 Second OFC
604, 1107 Load balancer 607, 1108 NW address conversion function 606, 1109 Address conversion table 701 Extended OF protocol processing means 702 Role management function 1104 to 1106 Topology change event transmission / reception function

Claims (8)

A first control device that controls a plurality of packet transfer devices based on a flow control function and virtual network setting information;
A second control device having a flow control function having an operation record and setting information of a virtual network having an operation record, which is a switching destination when a failure occurs in the first control device;
A load balancer disposed between the plurality of packet transfer devices and each control device;
The load distribution device has a role change instruction function that causes the second control device to execute control of the plurality of packet transfer devices when a Byzantine failure occurs in the first control device. Communication system. The role change instruction function of the load balancer determines that a Byzantine failure has occurred in the first control device when the CPU usage rate of the first control device exceeds a predetermined threshold. Communication system. During normal operation, the first control device operates as a master that receives all messages transmitted from a plurality of packet transfer devices, and the second control device is necessary for topology detection from the plurality of packet transfer devices. Operates as a slave that receives only messages,
The role change instruction function of the load distribution device causes the first control device to operate as a slave and the second control device to operate as a master when a Byzantine failure occurs in the first control device. Or the communication system of Claim 2. The communication system according to claim 3, wherein each control device has a role management function for managing whether to operate the device as a master or a slave based on a role change instruction from the load distribution device. The role management function of the second control device, when receiving a message necessary for topology detection during the slave operation, creates a flow necessary for starting the operation as a master based on the message. The communication system described. The communication system according to claim 1, wherein each control device notifies the other control device of the message when it is determined that the message received from the packet transfer device is a message necessary for topology detection. The communication system according to any one of claims 1 to 6, wherein the first control device is configured in a cluster by a plurality of control devices. The first control device that controls a plurality of packet transfer devices based on the flow control function and the virtual network setting information, the flow control function with an operation record, and the setting information of a virtual network with an operation record And a second control device that becomes a switching destination when a failure occurs in the first control device, and a load distribution device disposed between the plurality of packet transfer devices and each control device. In a communication system,
The service restoration method, wherein the load balancer causes the second control device to execute control of the plurality of packet transfer devices when a Byzantine failure occurs in the first control device.

Images