JP6930452B2 - Transfer devices, transfer systems, transfer methods, and programs - Google Patents

Description

The present invention relates to a technique for improving fault tolerance by a backup system mounting method related to a management function of a plurality of physical devices (transfer devices) constituting a network. The present invention relates to a technique for reducing the influence on the existing network design at the time of replacement with one physical device by bundling a plurality of physical device groups (switch clusters) constituting the network and controlling them as a logical node. Further, the present invention obtains total route information and total route calculation load that affect the outside when replacing one physical device by bundling a plurality of physical device groups (switch clusters) constituting the network and controlling them as logical nodes. Regarding technology to reduce.

In addition to the conventional method in which each transfer device autonomously communicates with other transfer devices to determine the transfer destination, the transfer device centrally manages a plurality of transfer devices with a single controller. There is a method to decide by the instruction of. In particular, in the case of centralized management type OpenFlow technology, the transfer destination of each transfer device is determined by the flow entry with match fields such as MAC (Media Access Control) address and IP (Internet Protocol) address as conditions. All entries are created by instructions from a controller that bundles and controls multiple transfer devices.

According to the OpenFlow technology, by setting the conditions for each transfer device in detail, it is possible to specify a route that is not affected by the restrictions of the routing protocol used in the conventional IP network. By adopting OpenFlow technology, it is expected that network resources will be used efficiently, functions will be added by applications placed in the network, and network design of wide area networks will be simplified.

“Distributed Operation”, ONOS-Wiki, [online], [Search on August 8, 2017], Internet <URL: https://wiki.onosproject.org/display/ONOS/Distributed+Operation> “OpenDaylight Controller: MD-SAL: Architecture: Clustering”, [online], [Search on August 8, 2017], Internet <URL: https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL: Architecture: Clustering>

There is an address aggregation method using a routing function such as OSPF (Open Shortest Path First) or BGP (Border Gateway Protocol) as a conventional method of bundling a plurality of devices and displaying them as one logical node from the outside. However, such an address aggregation method is limited in that it becomes difficult to properly distribute a VPN (Virtual Private Network) route.

On the other hand, if a protocol typified by OpenFlow technology that can construct a route is used, the control units of a plurality of devices are controlled by a single controller, so that a complete logical node can be created. Logical nodes using OpenFlow technology can flexibly respond to VPN routes by expanding the control function of the controller. However, in the logical node using OpenFlow technology, each transfer device (switch) depends on the controller. If the management network connecting the controller and each transfer device is disconnected, it becomes difficult for each transfer device to properly transfer packets. In addition, the transfer device alone cannot handle newly added or deleted routes.

Therefore, instead of the conventional routing protocol such as address aggregation, a centralized control type configuration using OpenFlow technology is the basis, and the connection between the controller and the transfer device, which is considered to be a problem of the centralized control type, is provided with redundancy. It can be said that it is important.
In the open source software and the like described in Non-Patent Documents 1 and 2, the controllers are deployed on a plurality of servers to cooperate and synchronize with each other, and even if one server fails, the other server can take over. A distributed processing function is adopted.

However, many transfer devices have only one management port for connecting to the controller. Therefore, in order to connect a plurality of transfer devices together to the controller, it is common to sandwich a management switch. Therefore, even if the number of controllers is increased to a plurality of controllers, if a failure occurs in the management switch, all the transfer devices are disconnected from the controllers, and the failure spreads throughout the network. In other words, there is a problem that the management switch becomes a single point of failure.

There are two possible methods for avoiding the problem that the entire network is stopped due to a failure of the management network, especially a failure at a single point of failure of the management switch.

The first method is to realize the route for transmitting the route construction information to the transfer device not via the management port but via the data communication port. In a network configured by combining transfer devices, as long as communication between devices is maintained by a data communication path, it is possible to realize a direct route construction similar to that of a centralized control type using the same route.
The second method is a method of extending the exchange communication of route information between the route construction functions depending on the management network, which has been realized by the management switch, so that the exchange communication of the route information can be performed via the data communication port. Similar to the first method, in a network configured by combining transfer devices, route information can be exchanged in the same way as the centralized control type using the same route as long as communication between the devices is maintained by the data plane. It becomes.

The first and second methods can be realized by controlling the data communication port on the same OS as the management port. However, the driver that enables port control for data communication does not operate on the same OS as the management port.

Therefore, an object of the present invention is to enable continuous operation even if a failure occurs in the management network in a cluster controlled by a protocol capable of constructing a route.

The invention according to claim 1 is a transfer device that controls packet transfer according to a protocol capable of route construction, wherein a virtual switch having a management port and route construction information received via a data plane are transmitted to the virtual switch. A bridge unit that allows the virtual switch to receive the route construction information by transmitting it to the management port, and a transfer unit that transfers packets according to the route constructed by the management unit to the virtual switch based on the route construction information. The transfer device is characterized by the above.

As a result, communication of route construction information can be realized even via a data communication port, and continuous operation can be performed even if a failure occurs in the management network.

In the invention according to claim 2, the bridge unit is the transfer device according to claim 1, wherein the path constructed by the management unit on the virtual switch is synchronized with the transfer unit.

As a result, communication of management information can be realized even via a data communication port.

In the invention according to claim 3, the bridge unit is transmitted from the management unit to the transfer unit, and the transfer unit is used for the management plane with respect to management information transmitted to another transfer device via the data plane. When deleting the header of, a dummy header is added in advance, and the transfer unit sends the management information from another transfer device via the data plane to the management unit, and the transfer unit manages the management plane. The transfer device according to claim 1 or 2 , wherein the header assigned by the transfer unit is deleted when the header is added.

As a result, communication of management information can be realized even via a data communication port.

In the invention according to claim 4 , the management unit is the transfer device according to claim 1, wherein the management unit is deployed in the transfer device.

This simplifies the cluster configuration and reduces the failure rate.
In the invention according to claim 5, the management unit is the transfer device according to claim 1, wherein the management unit is provided outside.

The invention according to claim 6 is a forwarding system that controls packet forwarding according to a protocol that can build a route, and includes a management device including a management unit that builds a route based on route construction information, and a virtual management port. a switch by transmitting the said path building information received via the data plane from the management unit of the management apparatus management port of the virtual switch, a bridge portion for receiving the route construction information to the virtual switch, wherein based on the route construction information, and the transfer system, characterized in that it comprises a and a transfer apparatus and a transfer unit for transferring the packet according to the route constructed in the virtual switch by the management unit.

As a result, communication of route construction information can be realized even via a data communication port, and continuous operation can be performed even if a failure occurs in the management network.

In the invention according to claim 7, the bridge unit is the transfer system according to claim 6, wherein the path constructed by the management unit on the virtual switch is synchronized with the transfer unit.

By doing so, the cluster controlled by the protocol that can be routed can continue to operate even if the management network fails.
In the invention according to claim 8, the bridge unit is transmitted from the management unit to the transfer unit, and the transfer unit is used for the management plane with respect to management information transmitted to another transfer device via the data plane. When deleting the header of, a dummy header is added in advance, and the transfer unit sends the management information from another transfer device via the data plane to the management unit, and the transfer unit manages the management plane. When adding a header for, delete the header given by the transfer unit.
The transfer system according to claim 6 or 7, characterized in that.
As a result, communication of management information can be realized even via a data communication port.

The invention according to claim 9, a rolling Okukata method of packet conforming to route construction possible protocol, the bridge portion of the transfer device, the virtual path construction information received via the data plane of the transfer device A step of transmitting the information to the management port of the switch, a step of receiving the route construction information by the virtual switch, a step of the management unit constructing a route to the virtual switch based on the route construction information, and a step of the bridge unit. the step of synchronizing the path built virtual switch to the transfer portion of the transfer device, and the rolling Okukata method characterized in that it comprises a.

As a result, communication of route construction information can be realized even via a data communication port, and continuous operation can be performed even if a failure occurs in the management network.

Procedure In the invention described in claim 10, the computer having a transfer unit for transferring control of the packet according to the route, the bridge portion, and transmits the route construction information received via the data plane to the management port of the virtual switch, To execute a procedure in which the virtual switch receives the route construction information, and a procedure in which the bridge unit synchronizes a route constructed in the virtual switch with the transfer unit based on the route construction information by the management unit. It was a program of.

As a result, communication of route construction information can be realized even via a data communication port, and continuous operation can be performed even if a failure occurs in the management network.

In the invention according to claim 16, if it is determined that the computer is disconnected from the transfer means for transferring packets, the receiving means for receiving a transfer control instruction conforming to a protocol that can construct a route from an external controller, and the external controller. , A transfer control program for functioning as a control means for controlling the transfer means provided by the user.

By doing so, the transfer control program based on the protocol that can construct a route can continue to operate even if a failure occurs in the management network.

According to the present invention, in a cluster controlled by a protocol capable of constructing a route, it is possible to continuously operate even if a failure occurs in the management network.

It is a figure which shows the cluster at the time of a normal time in 1st Embodiment. It is a block diagram of a switch. It is a figure which shows the influence when a failure occurs in a management switch. It is a figure which shows the flow after the failure occurrence. It is a figure which shows the cluster at the time of a normal time in 2nd Embodiment. It is a figure which shows the influence when a failure occurs in a management switch. It is a figure which shows the flow after the failure occurrence. It is a figure which shows the cluster in 3rd Embodiment. It is a figure which collated the hierarchical structure of the transfer apparatus in 4th Embodiment with the cluster of the comparative example. It is a figure which shows the information transferred between transfer devices. It is a hierarchical diagram of a transfer device. It is a figure which shows the information transferred between the transfer devices of 4th Embodiment. It is a figure which shows the cluster of the comparative example corresponding to the transfer apparatus of 4th Embodiment. It is a figure which shows the information transferred between the transfer devices of the 1st modification of 4th Embodiment. It is a figure which shows the cluster of the comparative example corresponding to the transfer apparatus of the 1st modification of 4th Embodiment. It is a figure which shows the information transferred between the transfer devices of the 1st modification of 4th Embodiment. It is a figure which shows the packet flowing through the cluster of the comparative example. It is a figure which shows the packet flowing through the cluster of 4th Embodiment. It is a figure which shows the hierarchical structure of the modification about the bridge part. It is a figure which shows the detail of the modification about the bridge part. It is a figure which shows the hierarchical structure of a bridge part. It is a figure which shows the detail about a bridge part. It is a figure which shows the structure of the cluster of the comparative example. It is a figure which shows the influence when a failure occurs in a management switch.

Hereinafter, a comparative example and a mode for carrying out the present invention will be described in detail with reference to each figure.
<< Comparative example >>
FIG. 23 shows an example of the configuration of a comparative example in the network using the OpenFlow technology targeted by the present invention.
The cluster 1C of the comparative example is a set of switches 4a to 4e, a management switch 3, and OpenFlow controllers 2a and 2b. Hereinafter, when the switches 4a to 4e are not particularly distinguished, they are simply referred to as switches 4. When the OpenFlow controllers 2a and 2b are not particularly distinguished, they are simply described as OpenFlow controller 2.

Switches 4a to 4e are transfer devices that are connected to the data plane 6 and transfer packets. The data plane 6 is a plane in which each switch 4a to 4e is connected to flow a packet. The switches 4a to 4e are connected to the OpenFlow controllers 2a and 2b located at the upper level via the management port and the control plane 5.

All switches 4a to 4e hold management ports. Normally, each switch 4 has only one management port. Therefore, when the switch 4 having only one management port is used, the control plane 5 connected to the management port is aggregated on the management switch 3 and connected to the OpenFlow controllers 2a and 2b. The management switch 3 is a switch that relays the OpenFlow controllers 2a and 2b and the switches 4a to 4e. The control plane 5 transmits transfer instructions of the OpenFlow controllers 2a and 2b to the switches 4a to 4e.

The switches 4a to 4e are connected in a Fabric configuration that plays the role of a spine (trunk) and a leaf (branch). That is, the switches 4a, 4d, 4e play the role of Leaf (branch), and are connected to the switches 4b, 4c via the data plane 6. The switches 4b and 4c play the role of a spine, and are connected to the switches 4a, 4d, and 4e via the data plane 6. Further, the switches 4a and 4e are connected to the outside.

The OpenFlow controllers 2a and 2b are connected to each other via the management network 7. The OpenFlow controllers 2a and 2b control the packet transfer of the switches 4a to 4e by the OpenFlow protocol. The management network 7 refers to a connection between the OpenFlow controllers 2a and 2b and the management switch 3. The management network 7 allows the OpenFlow controllers 2a and 2b to cooperate with each other.

The switches 4a to 4e may have other connection configurations. The cluster 1C of the comparative example has a redundant configuration with two OpenFlow controllers 2a and 2b, but the number of servers of the external OpenFlow controller 2 is not limited to two and may be any number.
The number of network devices in the cluster 1C of the comparative example is an example, and may be larger or smaller than this number. The network device in the cluster 1C may be connected to the outside by a Leaf switch, and may be connected to the outside by a Leaf switch other than the switches 4a and 4e.

FIG. 24 is a diagram showing the effect when a failure occurs in the management switch 3 in the comparative example.
In the cluster 1C of the comparative example, all the switches 4a to 4e, which are transfer devices, are disconnected from the OpenFlow controllers 2a and 2b due to the failure of the management switch 3. This makes it difficult for the cluster 1C to properly transfer packets transmitted from the outside. Furthermore, it becomes impossible to deal with double failures such as failures of the data plane 6.

<< Outline of Embodiment >>
Therefore, in order to avoid the problem that the entire network is stopped due to the failure of the management network, particularly the failure at the single point of failure of the management switch, an embodiment in which the controller of the backup system is embedded in each transfer device is proposed.

In the first and second embodiments, centralized management is performed with a controller deployed to a server outside the transfer device as a parent during normal operation. In the event of a failure, switch to the standby system and maintain proper transfer by coordinating between the controllers. Furthermore, even if a double failure occurs in the data plane, it is possible to respecify a new route by coordinating between the standby controllers.

<< First Embodiment >>
In the first embodiment, the routing protocol function is started by the backup system controller when a failure of the management network 7 occurs, and the autonomous decentralized operation is performed at the time of switching. After a failure occurs, each device operates autonomously and decentrally in the same way as a conventional IP network, so continuous operation is possible. Currently, some OpenFlow controllers released by OSS (Open-source software) have a routing protocol function that considers connection with an external network using conventional IP technology, and the implementation hurdle is low. .. However, since one controller takes charge of control before the failure, what was visible as one logical node from the external network has a side effect of being visible from the outside as a node for each physical device due to autonomous decentralized operation.

FIG. 1 is a diagram showing a configuration of a cluster 1 in a normal state in the first embodiment.
The cluster 1 is a set of switches 4a to 4e, a management switch 3, and OpenFlow controllers 2a and 2b.

The switches 4a to 4e are transfer devices connected to the data plane 6 to transfer packets. The data plane 6 is a plane in which each switch 4a to 4e is connected to flow a packet. Each of the switches 4a to 4e includes standby controllers 41a to 41e, respectively. In the drawings, the standby controllers 41a to 41e are simply described as "controllers". In the normal state, the switches 4a to 4e are connected to the OpenFlow controllers 2a and 2b located at the upper level via the management port 45 (see FIG. 2) and the control plane 5.

The control plane 5 connected to the management port 45 (see FIG. 2) held by all the switches 4a to 4e is aggregated on the management switch 3 and connected to the OpenFlow controllers 2a and 2b. The management switch 3 is a switch that relays the OpenFlow controllers 2a and 2b and the switches 4a to 4e. The control plane 5 transmits transfer instructions of the OpenFlow controllers 2a and 2b to the switches 4a to 4e. Here, the routing software 21 is operating on the OpenFlow controller 2b. The routing software 21 is an application program for causing the OpenFlow controller 2b to perform routing. The routing software 21 is not running on the OpenFlow controller 2a.

The switches 4a to 4e are connected in a Fabric configuration that plays the role of a spine (trunk) and a leaf (branch). That is, the switches 4a, 4d, 4e play the role of Leaf (branch), and are connected to the switches 4b, 4c via the data plane 6. The switches 4b and 4c play the role of a spine, and are connected to the switches 4a, 4d, and 4e via the data plane 6. Further, the switches 4a and 4e are connected to the outside.

The OpenFlow controllers 2a and 2b are connected to each other via the management network 7 and the management switch 3. The OpenFlow controllers 2a and 2b control the packet transfer of the switches 4a to 4e by the OpenFlow protocol. The management network 7 refers to a connection between the OpenFlow controllers 2a and 2b and the management switch 3. The management network 7 allows the OpenFlow controllers 2a and 2b to cooperate with each other.

Similar to the cluster 1C of the comparative example, the network configuration, the number of controllers, and the number of network devices of the cluster 1 of the first embodiment are not limited to the configurations shown in FIG. Further, in the first embodiment, the spare system controllers 41a to 41e are embedded in all the switches 4a to 4e. However, as long as each switch 4 can be controlled, the standby controller 41 may be embedded in any switch 4. The network device in the cluster 1 may be connected to the outside by a Leaf switch, and may be connected to the outside by a Leaf switch other than the switches 4a and 4e.

In the normal state of FIG. 1, the switches 4a to 4e are centrally controlled from the OpenFlow controllers 2a and 2b installed outside as in the comparative example.

FIG. 2 is a configuration diagram of the switch 4.
The switch 4 is a transfer device that controls packet transfer according to the OpenFlow protocol. The switch 4 includes a transfer unit 44, a management port 45, and a standby controller 41.
The transfer unit 44 is connected to the data plane 6 and transfers the packet.
The management port 45 is connected to the control plane 5 and receives a transfer control instruction from the external OpenFlow controller 2 to the transfer unit 44.
The standby controller 41 is not normally operating, and relays the transfer control instruction received from the management port 45 to the transfer unit 44. If the standby controller 41 determines that the external OpenFlow controller 2 is disconnected, it determines that a failure has occurred and switches the control of the transfer unit 44 to itself. The operations of the standby controller 41 and the transfer unit 44 will be described in detail with reference to FIG. 4 described later.
As shown by the broken line, the switch 4 may be configured to directly transmit the transfer control instruction received from the management port 45 to the transfer unit 44.

FIG. 3 is a diagram showing the effect when a failure occurs in the management switch 3.
Due to the failure of the management switch 3, the connections between all the switches 4a to 4e and the OpenFlow controllers 2a and 2b installed externally are lost. In FIG. 3, the failure of the management switch 3 is shown by a broken line. Further, the control plane 5 and the management network 7 shown by the broken line indicate that these connections have been lost. At that time, the spare system controllers 41a to 41e embedded in the switches 4a to 4e give instructions to the switches 4a to 4e, so that the cluster 1 can operate.

In the first embodiment, each of the standby controllers 41a to 41e embedded in the switches 4a to 4e communicates with the outside of the cluster 1 by a routing protocol to exchange route information autonomously and decentrally. In FIG. 3, the routing software 42a to 42e are operating on the standby controllers 41a to 41e, respectively. The routing software 42a to 42e are application programs for causing the switches 4a to 4e, which are their own devices, to perform routing.
The standby controller 41 embedded in the switch 4 autonomously operates the routing protocol when a failure is determined between the OpenFlow controllers 2a and 2b installed outside before the failure and its own transfer unit 44. As a result, the switches 4a to 4e of the first embodiment can appropriately transfer packets even after a failure occurs. In this method, the operation is the same as that of the conventional IP network, and the reliability can be ensured.

The flow after the occurrence of the failure in the first embodiment is shown in FIG. Initially, cluster 1 is visible from the outside as a single logical node.

When a failure occurs in the management network 7 (step S10), it is determined that both the transfer unit 44 of the switch 4 and the standby controller 41 are disconnected from the OpenFlow controllers 2a and 2b (steps S11 and S12). The transfer unit 44 of the switch 4 is connected to the standby controller 41 in the device (step S13). The standby system controller 41 switches the control of the transfer unit 44 to its own standby system controller 41 (step S14).

The standby controller 41 starts the routing function (step S15) and instructs the writing of the entry for acquiring the routing packet (step S16). The transfer unit 44 of the switch 4 writes an entry for the port to be routerized (step S17). As a result, the routing operation can be performed at the required port of the switch 4 managed by the standby controller 41.

The forwarding unit 44 of the switch 4 acquires the routing packet (step S18). The standby system controller 41 recognizes the relationship with the surrounding devices and instructs the transfer unit 44 to write an entry (step S19). The transfer unit 44 writes a packet transfer destination entry (step S20). After the operations of steps S18 to S20 have converged, the standby system becomes a stable operation (step S21). That is, when the backup system controller 41 determines that the external OpenFlow controller 2 is disconnected, the backup system controller 41 autonomously controls the transfer unit 44 in cooperation with the spare system controller 41 of the other switch 4.

The cluster 1 of the first embodiment is seen as a single logical node from the outside before the failure occurs. After a failure occurs and the cluster 1 starts communicating with the outside by the routing protocol, each switch 4 becomes visible to each physical node from the outside.
When the switch 4 detects the recovery of the management network failure, the control may be switched to the external OpenFlow controllers 2a and 2b to return to the normal state.
Further, when a failure occurs only in a certain switch 4 and communication with the external OpenFlow controllers 2a and 2b becomes impossible, the routing function may be started only in the failed switch 4. Further, the external OpenFlow controllers 2a and 2b may detect that a failure has occurred and instruct all other switches 4 in the cluster 1 to start the routing function.

<< Second Embodiment >>
In the second embodiment, a controller provided with a distributed processing platform is embedded in each transfer device as a backup system. As introduced in the conventional technology, some OpenFlow controllers have a function to deploy to multiple servers and operate in cooperation with each other in order to improve redundancy and expandability.

In the comparative example, the controllers are linked on the management network. However, in the second embodiment, the controller on the transfer device cooperates by using the data plane at the time of failure so as to withstand the failure of the management network. Even if a failure occurs in the management network, the conventional centralized control is possible, and it is also possible to deal with newly added / deleted routes. Since the implementation is based on the premise that the linkage between controllers is always performed via the management network, it is necessary to link in the data plane and be aware of the influence on the actual data transfer in the data plane.

FIG. 5 is a diagram showing a configuration of cluster 1A in a normal state in the second embodiment.
Cluster 1A is a set of switches 4a to 4e, a management switch 3, and OpenFlow controllers 2a and 2b.

The switches 4a to 4e are connected to the data plane 6 to transfer packets. The data plane 6 is a plane in which each switch 4a to 4e is connected to flow a packet. Each of the switches 4a to 4e includes standby controllers 41a to 41e, respectively. In the normal state, the switches 4a to 4e are connected to the OpenFlow controllers 2a and 2b located at the upper level via the management port 45 (see FIG. 2) and the control plane 5.

The routing software 21 is running on the OpenFlow controller 2b. The routing software 21 is an application program for causing the switch 4 which is its own device to perform routing. The control plane 5 connected to the management port 45 (see FIG. 2) held by all the switches 4a to 4e is aggregated on the management switch 3 and connected to the OpenFlow controllers 2a and 2b. The management switch 3 is a switch that relays the OpenFlow controllers 2a and 2b and the switches 4a to 4e. The control plane 5 transmits transfer instructions of the OpenFlow controllers 2a and 2b to the switches 4a to 4e.

The switches 4a to 4e are connected in a Fabric configuration that plays the role of a spine (trunk) and a leaf (branch). That is, the switches 4a, 4d, 4e play the role of Leaf (branch), and are connected to the switches 4b, 4c via the data plane 6. The switches 4b and 4c play the role of a spine, and are connected to the switches 4a, 4d, and 4e via the data plane 6. Further, the switches 4a and 4e are connected to the outside.

The OpenFlow controllers 2a and 2b and the standby controllers 41a to 41e are connected to each other via the management network 7 and the management switch 3. The OpenFlow controllers 2a and 2b control the packet transfer of the switches 4a to 4e by the OpenFlow protocol. The management network 7 allows the OpenFlow controllers 2a and 2b and the standby controllers 41a to 41e to cooperate with each other.

In the cluster 1A of the second embodiment, the network configuration, the number of controllers, and the number of network devices are not limited to the configuration shown in FIG. 5, as in the cluster 1C of the comparative example. Further, in the second embodiment, the spare system controllers 41a to 41e are embedded in all the switches 4a to 4e. However, the cluster 1A may be configured to embed the standby controller 41 in any switch 4 as long as it can control each switch 4. The network device in the cluster 1A may be connected to the outside by a Leaf switch, and may be connected to the outside by a Leaf switch other than the switches 4a and 4e.

In the normal time of FIG. 5, the switches 4a to 4e are centrally controlled from the OpenFlow controller 2b installed outside as in the comparative example.

FIG. 6 is a diagram showing the effect when a failure occurs in the management switch 3.
Due to the failure of the management switch 3, the connections between all the switches 4a to 4e and the OpenFlow controllers 2a and 2b installed externally are lost. In FIG. 6, the control plane 5 is shown by a broken line to indicate that the connection is lost. As a result, the connection between the standby controllers 41a to 41e and the OpenFlow controllers 2a and 2b is also lost. FIG. 6 shows that the connection was lost due to the management network 7 shown by the broken line.
At this time, the standby controllers 41a to 41e embedded inside the switches 4a to 4e autonomously detect the failure, switch the control of the transfer unit 44 to themselves, and give an instruction to each of the switches 4a to 4e. Cluster 1A becomes operational.

Further, the standby controllers 41a to 41e newly configure a management network 7 on the data plane 6 and cooperate with each other. Further, the switch 4a is made to execute the routing software 42a, and the switch 4e is made to execute the routing software 42e. As a result, packets received from the outside can be routed appropriately and quickly.

In the second embodiment, the controllers are initially linked on the management network 7 side in FIG. 5, and the management network 7 is configured on the data plane 6 in the event of a failure, and the controllers are linked.

In the second embodiment, the controllers, which originally have a base for distributed processing, are arranged outside and inside the transfer device, and when a failure occurs in the management network, the controllers communicate with each other through the data plane. Instructions are given to each switch.

In the second embodiment, even if the management network cannot communicate, the management network is configured on the data plane, so that the remaining packets can be appropriately transferred. Further, since each device is controlled by a group of controllers on a plurality of devices that are uniformly managed, it is possible to always manage as one logical node even when viewed from the outside.

FIG. 7 is a diagram showing a flow after a failure occurs.
Cluster 1A is visible from the outside as a single logical node both before and after the failure.
When a failure occurs in the management network 7 (step S30), it is determined that both the transfer unit 44 of the switch 4 and the standby controller 41 are disconnected from the external OpenFlow controllers 2a and 2b (steps S31 and S32). The transfer unit 44 of the switch 4 is connected to the standby controller 41 in the device (step S33). The standby system controller 41 switches the control of the transfer unit 44 to its own standby system controller 41 (step S34).

The spare system controller 41 sets the transfer unit 44 of each spare system controller 41 and each switch 4 so that the communication path for connection with the other spare system controller 41 can be performed on the data plane 6 (step S35). When the connection of all the spare system controllers 41 is completed (step S36), the standby system stabilizes the operation (step S37).

That is, when the spare system controller 41 determines that the external OpenFlow controller 2 is disconnected, the backup system controller 41 cooperates with the spare system controller 41 of the other switch 4 to perform distributed processing of the transfer control by the external OpenFlow controller 2.
The spare system controller 41 cooperates with the spare system controller 41 of the other switch 4 via the data plane 6, and receives the transfer destination route information from the spare system controller 41 of the other switch 4 via the data plane 6.

In the second embodiment, both before and after the failure receive instructions from a group of controllers that are centrally managed. Therefore, cluster 1A is consistently recognized as a single logical node from the outside.
In the normal state of FIG. 5, for example, when a failure occurs in the OpenFlow controllers 2a and 2b and the connection between the switch 4 and the OpenFlow controllers 2a and 2b is disconnected, the standby controllers 41a to 41e are placed on the control plane 5. The management network 7 may be configured so that the switches 4 cooperate with each other via the management switch 3.
Further, as in the first embodiment, when the switch 4 detects the recovery of the management network failure, the switch 4 may switch the control to the external OpenFlow controllers 2a and 2b to return to the normal state.
Further, when a failure occurs only in a certain switch 4 and communication with the external OpenFlow controllers 2a and 2b becomes impossible, the routing function may be started only in the failed switch 4. Further, the external OpenFlow controllers 2a and 2b may detect that a failure has occurred, and instruct all the other switches 4 of the cluster 1A to switch to the standby controller 41.

<< Third Embodiment >>
As a third embodiment, the configuration of FIG. 8 is shown.
Cluster 1B is a set of switches 4a to 4e. Each of the switches 4a to 4c and 4e includes controllers 43a to 43c and 43e, respectively. However, the switch 4d does not have an OpenFlow controller. Hereinafter, when the controllers 43a to 43c and 43e are not particularly distinguished, they are simply referred to as the controller 43.

In the normal state, the switches 4a to 4c and 4e are controlled by the controllers 43a to 43c and 43e in the own device. Each of the controllers 43a to 43c, 43e constitutes a management network 7 on the data plane 6. Further, the routing software 42a and 42e are operating on the switches 4a and 4e, respectively.
The switch 4d shows an example in which a transfer table is set from another controller 43 via the management network 7.

In the first and second embodiments, the operation is switched to the standby system operation after the failure of the management network 7. On the other hand, in the cluster 1B of the third embodiment, the control plane 5 is not connected to the upper controller 8 as shown by the broken line, and the controllers 43a to 43c, 43e cooperate on the data plane 6 from the beginning. A possible management network 7 is configured.

In the third embodiment, the centralized control infrastructure is distributed and deployed from the beginning, and control is performed by the management network 7 configured on the data plane 6. In the third embodiment, it is possible to avoid a single point of failure from the beginning, and it is always recognized as a single logical node by the external network. Further, since the control plane 5 is not required, the cluster 1B can be easily and inexpensively configured.

<< Fourth Embodiment >>
A cluster is a collection of multiple switches (transfer devices) and controllers (servers). Each switch connects the data plane ASIC control driver and the SDN controller via the management port on the management plane ASIC held by each switch. These communications are via a management switch connected between the management port of each switch and the SDN controller. This management switch is a single point of failure.

In this fourth embodiment, the communication of the route construction information via the management port in the conventional centralized control type is realized via the data communication port. This eliminates the need for a management switch, which is a single point of failure. Therefore, in the fourth embodiment, the route construction information is communicated via the control interface of the data communication port. Hereinafter, the fourth embodiment will be described with reference to FIGS. 9 to 22.

FIG. 9 is a diagram in which the hierarchical structure of the transfer device 40 in the fourth embodiment is collated with the cluster of the comparative example. In FIG. 9, the hierarchical structure of the transfer device 40 of the fourth embodiment is shown on the left side, and the cluster of the comparative example is shown on the right side. The transfer device 40 corresponds to the switch 4 of the first to third embodiments.

The uppermost routing layer of the transfer device 40 is routing software 42 for functioning as a routing control unit. The second cluster control layer of the transfer device 40 is an SDN (Software Defined Network) controller 430 that operates as a cluster control unit. The SDN controller 430 includes a clustering interface 431 and a device control interface 432. The SDN controller 430 provides transfer destination route information to the data plane ASIC405.

The routing software 42 of the uppermost routing layer communicates with the routing layer of another device by using the intercluster control interface routing protocol. The routing software 42 of the present embodiment corresponds to the routing software 42 of the comparative example.
The SDN controller 430 of the second cluster control layer performs route information exchange communication with the cluster control layer of another device using the intra-cluster control interface routing protocol. The route information exchanged here is management information transmitted and received by the SDN controller 430. The SDN controller 430 further transmits the route construction information to the transfer function unit, and constructs a packet transfer destination table in the transfer function unit.
The SDN controller 430 of the embodiment corresponds to the controller 43 of the comparative example. The transfer function unit corresponds to the data plane ASIC405 described later.

The transfer device 40 is further composed of an ASIC interface (Application Specific Integrated Circuit InterFace) control layer, a switch OS layer, and an interface layer. These correspond to the control plane 5 connected to the controller 43 of the comparative example and the switches 4a and 4b connected to the control plane 5 at the management port 45.

The ASIC interface control layer includes an OS standard driver 403 and an ASIC control driver 404 for the data plane. The OS standard driver 403 controls the ASIC 401 for the management plane of the interface layer described later. The data plane ASIC control driver 404 controls the data plane ASIC 405 described later.
The switch OS layer includes the switch OS 402. The switch OS 402 is basic software that manages hardware resources on the transfer device 40. The interface layer includes ASIC405 for the data plane and ASIC401 for the management plane. The management plane ASIC401 is an interface for transmitting and receiving management communication packets. The data plane ASIC405 is an interface that embodies the route constructed by the routing software 42. The data plane ASIC 405 and the data plane ASIC control driver 404 function as a forwarding unit that forwards packets by the constructed route.

The SDN controller 430 of this embodiment communicates with the OS standard driver 403 via the management plane ASIC401 and the switch OS402. The OS standard driver 403 controls the ASIC405 for the data plane based on the instruction from the SDN controller 430 of the own device or another device. As a result, the transfer device 40 of the present embodiment can realize the same processing as the cluster of the comparative example.

FIG. 10 is a diagram showing a method of constructing a route of another device in the cluster 1D from a route construction function connecting to a certain device in the cluster 1D via a data communication port.
The cluster 1D includes transfer devices 40a to 40d. The transfer device 40a includes routing software 42a and an SDN controller 430a. The transfer device 40b includes an SDN controller 430b.

Cluster 1D is configured with a Leaf-Spine 2x2 Clos topology. The transfer device 40a is connected to the transfer devices 40c and 40d by a data plane. The transfer device 40b is connected to the transfer devices 40c and 40d by a data plane. The SDN controller 430a internally controls communication via the management port, and also controls communication with the transfer devices 40c and 40d via the data plane. The SDN controller 430b internally controls communication via the management port.

The SDN controllers 430a and 430b internally communicate the route construction information via the management port. The SDN controller 430a communicates the route construction information with the transfer devices 40c and 40d via the data plane. In FIG. 10, the communication of this route construction information is indicated by an arrow with hatching.

Further, the SDN controllers 430a and 430b perform route information exchange communication using the intercluster control interface routing protocol via the data plane. Therefore, logically, communication is performed between the cluster control layers. In FIG. 10, this communication is indicated by a white arrow. According to the method of FIG. 10, it is possible to avoid the configuration of the logical node depending on the management port.
The device configuration topology is not limited to this. The number of devices constituting the cluster may be larger or smaller than this. In addition, any number of route construction functions may be provided in the cluster.

The following FIGS. 11, 12, and 14 show configuration examples for realizing the configuration of FIG. 10. The transfer device 40 shown in FIG. 11 internally deploys the routing software 42 and the SDN controller 430. The transfer device 40a shown in FIGS. 12 and 14 internally deploys the routing software 42a and the SDN controller 430a. Not limited to this, the transfer devices 40 and 40a may be configured by deploying routing software or an SDN controller externally and connecting the interfaces to each other, if necessary. It is assumed that the communication of the route construction information and the exchange communication of the route information of FIGS. 11, 12, and 14 are all communicated via the port of the data plane ASIC405.

FIG. 11 is a configuration diagram of the transfer device 40.
In the cluster of the comparative example, the route construction device communicated with each switch via the management switch. On the other hand, in the transfer device 40 of the fourth embodiment, an SDN controller 430 that functions as a route construction unit and an ASIC405 for a data plane that functions as a switch are deployed, and both are connected so as to be communicable. There is. The SDN controller 430 is configured to include a device control interface 432. The routing software 42 is directly deployed in the transfer device 40.
Since only one routing software 42 is required in the cluster, only the SDN controller 430 may be deployed in the transfer device 40.

The transfer device 40 is further equipped with a virtual ASIC 407 (virtual switch) and a bridge unit 410 including a bridge 408 and a bridge control unit 409. In FIG. 11, the virtual ASIC 407 is described as “vASIC”, the bridge 408 is described as “Bridge”, and the bridge control unit 409 is described as “Bridge-ctl”.
A virtual interface 406 is deployed on the bridge 408. In FIG. 11, the virtual interface 406 is described as “vIF”. The bridge unit 410 causes the virtual ASIC 407 to receive the route construction information by transmitting the route construction information received via the data plane to the management port (not shown) of the virtual ASIC 407.

The transfer device 40 is provided with an ASIC control driver 404 for a data plane, a switch OS 402, an ASIC 401 for a management plane (not shown), and a management port 45, which are the same as those in FIG. The management port 45 is a port included in the management plane ASIC401 (not shown), and functions as an interface with the management network. In FIG. 11, the management port 45 is described as Mgmt IF (ManaGeMenT Interface).

The virtual ASIC 407 is a virtualization of the management plane ASIC 401. In the transfer device 40, the upper SDN controller 430 constructs a route in the virtual ASIC 407. The bridge control unit 409 synchronizes the route constructed in the virtual ASIC 407 with the data plane ASIC 405.

The virtual interface 406 is an interface for virtually realizing communication related to management with another transfer device 40. The bridge 408 communicates management information such as route construction information transmitted / received by the virtual interface 406 via the data plane. The bridge 408 is connected to the interface of the data plane ASIC405 to integrate and separate communications.

The SDN controller 430 communicates the route construction information with the virtual ASIC 407. This communication is illustrated by a solid arrow.
The bridge control unit 409 controls the bridge 408 to integrate and separate management communication and data communication. This communication is indicated by the solid arrow in FIG. The bridge control unit 409 synchronizes the route information constructed in the virtual ASIC 407 with the data plane ASIC control driver 404 by the bridge 408. This communication is indicated by the dashed arrow in FIG. The data plane ASIC control driver 404 causes the data plane ASIC 405 to construct route information.
The switch OS 402 mediates information between the data plane ASIC control driver 404 and the data plane ASIC 405. Since the management port 45 that functions as an interface with the management network is not operating here, the description thereof will be omitted.

FIG. 12 is a diagram showing information transferred between the transfer devices 40a and 40b of the fourth embodiment.
The transfer device 40a of FIG. 12 has an SDN controller 430a that functions as a route construction unit. The SDN controller 430a directly controls the route of another transfer device 40b in the cluster from the transfer device 40a having a transfer control function.

The bridge unit 410 bridges from the virtual interface 406 configured on the bridge 408 to the data communication port of the data plane ASIC405. As a result, the data transmitted to the virtual interface 406 flows to the data plane connecting the devices while designating the destination port. The virtual interface 406 can be directly recognized on the OS.
The data to be sent to the data plane includes route construction information (FIG. 12) for the virtual ASIC 407 on the other transfer device 40. The data to be sent to the data plane further includes information for exchanging route information with the clustering interface 431 of the SDN controller 430 on the other transfer device 40 (FIG. 14).
The SDN controller 430a constructs a route in the virtual ASIC 407. The bridge control unit 409 synchronizes the route constructed in the virtual ASIC 407 with the data plane ASIC 405.

The routing software 42a and the SDN controller 430a are directly deployed in the transfer device 40a. However, only one routing software or SDN controller is required in the cluster. Therefore, when the routing software or the SDN controller is deployed outside, the routing software 42a or the SDN controller 430a may not be deployed in the transfer device 40a. When the routing software is deployed to the outside, the routing software 42a may not be deployed in the transfer device 40a, and only the SDN controller 430a may be deployed.

The route construction function is not provided inside the transfer device 40b. The transfer device 40b is controlled by the SDN controller 430a of the transfer device 40a, and a route is constructed in the virtual ASIC 407. After that, the bridge control unit 409 synchronizes the route constructed in the virtual ASIC 407 with the data plane ASIC 405.

That is, the SDN controller 430a transmits a packet of route construction information via its own virtual interface 406 and the data plane ASIC405. This packet arrives at the transfer device 40b via the data plane. The bridge control unit 409 of the transfer device 40b relays the route construction information to the virtual ASIC 407 of its own machine via the virtual interface 406. As a result, a route is constructed in the virtual ASIC 407 of the transfer device 40b. The bridge control unit 409 passes the constructed route information to the data plane ASIC control driver 404 by the bridge 408. As a result, the data plane ASIC405 can construct a route.

When the virtual ASIC 407 of the transfer device 40b responds to the route construction information of the SDN controller 430a, the route of the response packet is reversed.

The transfer devices 40a and 40b include a virtual ASIC 407, a bridge 408 including a virtual interface 406, a bridge control unit 409, an ASIC control driver 404 for a data plane, a switch OS 402, and a management port 45.

FIG. 13 is a diagram showing a cluster 1E including the transfer devices 40a and 40b of the fourth embodiment.
Cluster 1E includes transfer devices 40a-40c. Transfer devices 40b and 40c are connected to the transfer device 40a via a data plane.
The transfer device 40a includes a controller 43a and routing software 42a. Routing is performed by the controller 43a controlling the transfer devices 40a to 40c.

FIG. 14 is a diagram showing information transferred between the transfer devices of the first modification of the fourth embodiment.
FIG. 14 shows a configuration diagram in which route information is exchanged and communicated between devices having an SDN controller 430 that realizes a transfer control function, and the transfer control function is made redundant in the configuration of FIG. 14 in a cluster.

The basic operation of the transfer device 40a is the same as that of FIG. 12, and the packet of the route information exchange communication flows from the virtual interface 406 to the data communication port of the data plane ASIC405.

The routing software 42a and the SDN controller 430a are directly deployed in the transfer device 40a. However, only one routing software or SDN controller is required in the cluster. Therefore, when the routing software or the SDN controller is deployed outside, the routing software 42a or the SDN controller 430a may not be deployed in the transfer device 40a. When the routing software is deployed to the outside, the routing software 42a may not be deployed in the transfer device 40a, and only the SDN controller 430a may be deployed. Further, the transfer device 40b is not equipped with routing software or an SDN controller.

The SDN controllers 430a and 430b include a clustering interface 431 and a device control interface 432. The clustering interface 431 converts the functions and realizes communication between the SDN controllers 430a and 430b.

In the transfer device 40a, the SDN controller 430a communicates the route construction information with the virtual ASIC 407 of its own device via the device control interface 432. The SDN controller 430a further performs route information exchange communication using the intra-cluster control interface routing protocol with the SDN controller 430b of the transfer device 40b via the virtual interface 406 and the data plane.

In the transfer device 40b, the bridge unit 410 transmits the management information transmitted / received to / from the transfer device 40a via the data plane to the SDN controller 430b. Then, the SDN controller 430b receives the packet transmitted by the SDN controller 430a by the clustering interface 431. As a result, the SDN controller 430b can know what kind of route the own machine should construct.

When the transfer unit adds a header for the management plane to the management information transmitted from the transfer unit to the SDN controller 430b, the bridge unit 410 deletes the added header. As a result, it is possible to avoid a situation in which a header for the management plane is duplicated in the packet of management information.

When the transfer unit deletes the header for the management plane, the bridge unit 410 adds a dummy header to the management information transmitted from the SDN controller 430b to the transfer unit in advance. As a result, it is possible to avoid a situation in which the header for the management plane is deleted from the packet of management information.

FIG. 15 is a diagram showing a cluster 1F including transfer devices 40a and 40b of the first modification of the fourth embodiment. Cluster 1F is composed only of route information exchange communication between internal route construction functions.
The configuration required for the realization of FIG. 15 is the same as the case where the cluster 1E is configured only with the configuration of FIG. 14, and is therefore included in the proposal of FIG.
Cluster 1F includes transfer devices 40a to 40c. Transfer devices 40b and 40c are connected to the transfer device 40a via a data plane.
The transfer device 40a includes a controller 43a and routing software 42a. The transfer device 40b includes a controller 43b. The controller 43a controls the transfer devices 40a and 40c, and also controls the transfer device 40b by exchanging route information with the controller 43b.

<< Second modification of the fourth embodiment >>
In the conventional centralized control method, the management port on the management plane side can be directly controlled on the OS. However, there is no way to directly control the data communication port on the data plane side on the OS. All packets coming in from the data communication port are forwarded on the management plane side with a header to which input port information for realizing centralized control is added like the OpenFlow protocol.

The content of the present proposal is for controlling an external transfer device directly from a controller that exists on the management plane side of the transfer device and operates on the OS. The content of the first proposal is to realize a function of passing communication originally connected on the management plane to the data plane side (hereinafter referred to as a bridge function), and to control an external device by using this bridge function.

FIG. 16 is a diagram showing information transferred between the transfer devices 40a to 40d of the first modification of the fourth embodiment.
This cluster 1G includes transfer devices 40a to 40d. The transfer device 40a includes routing software 42a and an SDN controller 430a. The transfer devices 40b to 40d include SDN controllers 430b to 430d, respectively.

In the cluster 1G, the transfer device 40a is connected to the transfer devices 40c and 40d by a data plane. The transfer device 40b is connected to the transfer devices 40c and 40d by a data plane. The SDN controller 430a internally controls communication via the management port. In FIG. 16, this communication is indicated by a hatched arrow.
The SDN controller 430a controls communication with the SDN controllers 430b to 430d of another device via the data plane. In FIG. 16, this communication is indicated by a white arrow.
The SDN controllers 430b to 430d internally control communication via the management port. In FIG. 16, this communication is indicated by a hatched arrow.

The SDN controllers 430a and 430b internally exchange and communicate route information using the intercluster control interface routing protocol via the management port and externally via the data plane. Therefore, logically, communication is performed with each other at the cluster control layer.

FIG. 17 is a diagram showing packets flowing through the cluster 1H of the comparative example.

Cluster 1H of the comparative example includes cluster control devices 8a and 8b and transfer devices 40a to 40c. Each of the transfer devices 40a to 40c includes a management port 45. The transfer device 40a further includes a data plane port 46. Unlike the transfer devices 40 of the fourth embodiment, the transfer devices 40a to 40c of the comparative example do not include the virtual ASIC 407, the bridge 408 including the virtual interface 406, and the bridge control unit 409.

The cluster control devices 8a and 8b are configured to include the functions of the routing software 42 and the functions of the SDN controller. The cluster control devices 8a and 8b send and receive packets for intra-cluster control via the management plane. The cluster control device 8a further transmits and receives a packet having an OpenFlow header via the data plane port 46 and the management port 45 of the transfer device 40a. As a result, the cluster control device 8a can receive the packet from the routing software 42 via the data plane even if it cannot be received from the management plane.

The cluster control device 8a transmits a packet having an OpenFlow header to the transfer devices 40a to 40c via the management plane. The transfer devices 40a to 40c can construct a data plane route by receiving this packet via the management port 45.

FIG. 18 is a diagram showing packets flowing through the cluster 1J of the fourth embodiment.
The cluster 1J includes transfer devices 40a to 40c. The transfer device 40a includes the routing software 42a and the SDN controller 430a, and further includes a data plane port 46 on the data plane side. The transfer device 40a further includes an entrance / exit port 461 for passing packets from the data plane side to the management plane side.
The transfer device 40b includes an SDN controller 430b, has a data plane port 46 on the data plane side, and has an entrance / exit port 461 for passing packets from the data plane side to the management plane side. The entrance / exit port 461 corresponds to the bridge 408 and the virtual interface 406 shown in FIG. 11 and the like.
The transfer device 40c includes a data plane port 46 on the data plane side, and an entrance / exit port 461 for passing packets from the data plane side to the management plane side.

The SDN controller 430a receives a packet to which an OpenFlow header is added from the data plane port 46, and performs control communication related to its own device via the data plane port 46. The SDN controller 430a transmits a packet with an OpenFlow header via the entrance / exit port 461 for the control of the transfer device 40c. This packet is received by the transfer device 40c via the entrance / exit port 461 and is used to control the data plane port 46.
The SDN controller 430a transmits a packet to which an OpenFlow header is not added via the entrance / exit port 461 for control with another SDN controller 430b. This packet is received by the transfer device 40b via the entry / exit port 461 and is received by the SDN controller 430b. The SDN controller 430b further transmits control communication with the SDN controller 430a via the data plane port 46. By doing so, even in the cluster 1J which does not have a management plane, route information exchange communication between SDN controllers can be performed.

We propose two ways to deploy the bridge function in the device.
FIG. 19 is a diagram showing a hierarchical structure of a modified example of the bridge portion.
In this modification, the bridge unit 90A bridges only the communication connected from the OS on the management plane side to the data plane in order to control the external device.
The RIB (Routing Information Base) construction unit 92 constructs a route from the routing information obtained through BGP to the arrival of the packet.

The FIB (Forwarding Information Base) construction unit 91 constructs a packet transfer destination table in the transfer unit 9 by transmitting the route construction information 93. The transfer unit 9 transfers the data packet according to the transfer destination table constructed by the route construction information of the FIB construction unit 91. The bridge unit 90A bridges the route construction information communication 94a and the route information exchange communication 94b in which the FIB construction unit 91 controls an external device.
The route construction information transmission 93 is a communication for writing flow information to the transfer unit 9 of the own device. The route construction information communication 94a is a communication for writing flow information to the transfer unit 9 of another device. The route information exchange communication 94b is a communication for synchronizing information with the FIB construction unit 91 on another device or in another calculation processing unit. The communication 94a of the route construction information and the exchange communication 94b of the route information are collectively referred to as an external device control communication 40. The transmission 93 of the route construction information is called the own device control communication.
FIG. 20 is a diagram showing details of a modification of the bridge portion.
The SDN controller 430 corresponds to the FIB construction unit 91 shown in FIG. The transfer unit 9 corresponds to the data plane ASIC control driver 404 and the data plane ASIC 405. Further, the bridge unit 90A includes a bridge 408 that functions as a virtual switch and a bridge control unit 409 that functions as an OpenFlow controller. Here, the SDN controller 430 corresponding to the FIB construction unit 91 communicates the route construction information with its own transfer unit 9 without going through the bridge unit 90A.

FIG. 21 is a diagram showing a hierarchical structure of the bridge portion.
Here, in addition to the communication for controlling the external device, the transmission 93 of the route construction information for controlling the own device is also received once by the bridge unit 90, and the transmission of the route construction information 93 to the transfer unit 93 of the own device again. Is a method of sending out. Other than that, the configuration and operation are the same as those shown in FIG.

FIG. 22 is a diagram showing details regarding the bridge portion.
In the configuration of FIG. 22, a virtual ASIC 407 is additionally deployed with respect to the configuration of FIG. 20. With this virtual ASIC 407, it is possible to receive the route construction information to the own device and reflect the constructed route in the ASIC 405 for the data plane. This virtual ASIC 407 has the same number of ports as the data plane ASIC 405. By mapping the port of the data plane ASIC405 and the port of the virtual ASIC407, a route can be constructed in the virtual ASIC407.

After that, the bridge control unit 409, which functions as an OpenFlow controller, synchronizes the route constructed in the virtual ASIC 407 with the data plane ASIC 405, and the route construction is completed. For communication that directly accesses the OS and the port of the data plane ASIC405 for controlling the external device, the bridge control unit 409 confirms the destination and outputs it to the port on the bridge 408 that is not connected to the virtual ASIC407. This enables communication.

<< Points of invention >>
In the technology of collectively controlling a plurality of transfer devices by centralized management by a controller, the reliability of the entire system is improved by arranging a spare system controller in each transfer device in case of a failure. This standby controller can operate autonomously and decentrally in the event of a management network failure.
It is considered that the first to third embodiments are different from each other in terms of the influence on the external network at the time of failure, the way in which the load of the internal calculation processing is applied, and the like. Then, the internal configuration of the transfer device is described in detail by the fourth embodiment. In this fourth embodiment, virtual hardware (virtual ASIC407) is included so that the hardware not managed by the OS holding the control portion can be managed in a pseudo manner, and the virtual hardware and the physical hardware are synchronized. taking it.
If the interface for controlling the data communication port is open to the public, it can be realized by a switch cluster assembled with a group of transfer devices specialized for general-purpose functions. In addition, the function is not developed for a specific route construction function (corresponding to the SDN controller), and other route construction functions that enable route control by a standard protocol can be flexibly applied.

<< Effect of the above embodiment >>
With OpenFlow technology that can instruct flexible routes that are not affected by existing protocols, in order to deal with the problem of the management plane that becomes a single point of failure, a spare system controller is provided to improve fault tolerance and reliability. bottom. This can expand the applicability of OpenFlow technology.
Furthermore, we proposed a hybrid configuration in which OpenFlow technology for centralized management is distributed. This hybrid network can be flexibly configured according to the scale of the network, and high reliability can be expected.

It is a transfer device that holds a general-purpose transfer function that has not been exclusively developed by a major vendor. It has the same switching capacity as the conventional dedicated development device, and it is possible to configure a switch cluster that has a transfer control function as a logical node. Therefore, it is expected that the application applications of the transfer device having a general-purpose transfer function will be expanded, and the device options of the network operator, which has been conventionally constructed by using the specially developed device, will be expanded.

<< Modification example >>
The present invention is not limited to the above-described embodiment, and can be modified without departing from the spirit of the present invention. For example, there are the following (a) to (e).

(A) The network configuration, the number of controllers, and the number of network devices of the cluster of the above embodiment are not limited to the illustrated configurations.
(B) In the first and second embodiments, the spare system controllers 41a to 41e are embedded in all the switches 4a to 4e. However, any configuration may be used as long as each switch 4 can be controlled.
(C) In the third embodiment, the transfer device that omits the controller 43 is not limited to the switch 4d, and may be any of the switches 4a to 4e.
(D) Not limited to OpenFlow, a protocol capable of constructing a route may be targeted as well.
(E) The information processing device (computer) that realizes the functions of the routing software and the functions of the SDN controller by executing the control program may be configured inside or outside the transfer device (switch).

1,1A-1C cluster 2a, 2b OpenFlow controller (external controller)
21 Routing software 3 Management switch 4 Switch (Transporter)
40 Transporter 400 Doorway port 401 ASIC for management plane
402 Switch OS
403 OS standard driver 404 Data plane ASIC control driver 405 Data plane ASIC
406 Virtual Interface 407 Virtual ASIC
408 Bridge 409 Bridge control unit 410 Bridge unit 41 Spare system controller (controller)
42a-42e Routing software (routing control unit)
43a, 43e controller 430 SDN controller (cluster control unit, management unit)
44 Transfer unit 45 Management port (port)
5 Control plane 6 Data plane 7 Management network 8 Upper controller

Claims (10)

A transfer device that controls packet transfer according to a protocol that can be routed.
A virtual switch with a management port and
A bridge unit that allows the virtual switch to receive the route construction information by transmitting the route construction information received via the data plane to the management port of the virtual switch.
A transfer unit that transfers packets according to a route constructed in the virtual switch by the management unit based on the route construction information.
A transfer device comprising. The bridge unit synchronizes the route constructed by the management unit on the virtual switch with the transfer unit.
The transfer device according to claim 1. The bridge unit is dummy in advance when the transfer unit deletes the header for the management plane with respect to the management information transmitted from the management unit to the transfer unit and transmitted to another transfer device via the data plane. With the header of
When the transfer unit assigns a header for the management plane to the management information transmitted from another transfer device via the data plane and transmitted from the transfer unit to the management unit, it is assigned by the transfer unit . Delete the header,
The transfer device according to claim 1 or 2. The management unit is deployed in the transfer device.
The transfer device according to claim 1. The management department is deployed outside.
The transfer device according to claim 1. A forwarding system that controls packet forwarding according to a protocol that can be routed.
A management device equipped with a management unit that constructs a route based on route construction information,
A virtual switch with a management port and
A bridge unit that causes the virtual switch to receive the route construction information by transmitting the route construction information received from the management unit of the management device via the data plane to the management port of the virtual switch.
A transfer unit that transfers packets according to a route constructed in the virtual switch by the management unit based on the route construction information.
With a transfer device
A transfer system characterized by having. The bridge unit synchronizes the route constructed by the management unit on the virtual switch with the transfer unit.
The transfer system according to claim 6. The bridge unit is dummy in advance when the transfer unit deletes the header for the management plane with respect to the management information transmitted from the management unit to the transfer unit and transmitted to another transfer device via the data plane. With the header of
When the transfer unit assigns a header for the management plane to the management information transmitted from another transfer device via the data plane and transmitted from the transfer unit to the management unit, it is assigned by the transfer unit. Delete the header,
The transfer system according to claim 6 or 7. It is a forwarding method that controls the forwarding of packets according to a protocol that can be routed.
Bridge portion of the transfer device, the step of transmitting the route construction information received via the data plane to the management port of the virtual switch of the transfer device,
The step in which the virtual switch receives the route construction information,
A step in which the management unit constructs a route in the virtual switch based on the route construction information.
A step in which the bridge unit synchronizes the path constructed in the virtual switch with the transfer unit of the transfer device.
Rolling Okukata method characterized in that it comprises a. A computer with a transfer unit for transferring control of the packet according to the route,
The procedure for the bridge to transmit the route construction information received via the data plane to the management port of the virtual switch.
A procedure in which the virtual switch receives the route construction information,
A procedure in which the bridge unit synchronizes a route constructed in the virtual switch by the management unit with the transfer unit based on the route construction information.
A program to execute.

Images