WO2017113929A1

WO2017113929A1 - Method and controller for controlling forwarding device cluster in software-defined networking

Info

Publication number: WO2017113929A1
Application number: PCT/CN2016/101780
Authority: WO
Inventors: 许欣; 李响
Original assignee: 中兴通讯股份有限公司
Priority date: 2015-12-29
Filing date: 2016-10-11
Publication date: 2017-07-06
Also published as: CN106936609A; CN106936609B

Abstract

A method and controller for controlling a forwarding device cluster in software-defined networking (SDN). The SDN controller performs a path selection by regarding the forwarding device cluster as a single, virtual forwarding device, wherein the forwarding device cluster comprises a plurality of independently-running member devices; and the SDN controller obtains a flow table of the member devices according to a path selection result, sending the flow table to the member devices so as to control traffic forwarding among the member devices and outbound traffic forwarding of the member devices. Software-defined networking is characterized by centralized control of network devices and the present application takes advantage of this characteristic to control traffic forwarding among member devices and outbound traffic forwarding of member devices via a flow table. Interoperability of different manufacturers can be achieved without requiring private protocols to be run among member devices; in addition, link maintenance of member devices and the controller requires no special processing and is simplified.

Description

Method and controller for controlling forwarding device cluster in software defined network

Technical field

The present invention relates to a software defined network, and more particularly to a method and a corresponding controller for controlling a forwarding device cluster in a software defined network.

Background technique

Software Defined Networking (SDN) is a new type of network innovation architecture. Its core idea is to separate the control and forwarding planes of the network and increase the flexibility and scalability of network management. The control layer in SDN is extracted by the control functions in the original network devices such as switches and routers, and is implemented by independent control software. The control functions in the original switches and routers are stripped from the infrastructure layer, and the control plane uniformly implements the forwarding management. OpenFlow is a protocol running between the controller and the forwarding device in the SDN network. The controller writes forwarding entries such as flow tables and group tables to the switch through the OpenFlow protocol to complete control of the entire network.

Similar to the traditional network, in the SDN network, in order to achieve load balancing and high reliability, it is also necessary to deploy multiple forwarding devices in a specific location of the network to form a cluster, which operates in active/standby mode or load sharing mode. To meet this requirement, you can deploy a device that uses the traditional cluster technology. The forwarding device cluster implements load balancing forwarding or active/standby switchover when the fault occurs. The SDN controller is presented as a single device.

However, in the case of a forwarding device cluster that uses the traditional clustering technology, the member switches of the cluster need to run a proprietary protocol. The mechanism by which multiple cluster device members presented as a whole maintain a single link with the SDN controller is also more complicated.

Summary of the invention

In view of this, the present invention provides the following technical solutions.

A method for controlling a cluster of forwarding devices in a software-defined network, comprising:

The software-defined network SDN controller treats the forwarding device cluster as a single virtual forwarding device for path decision, wherein the forwarding device cluster includes multiple independently running member devices;

And the SDN controller obtains the flow table of the member device according to the result of the path decision, and sends the flow table to the member device, and controls the outgoing traffic of the member device and the member device by using the flow table.

A controller in a software-defined network, comprising: a cluster control device, the cluster control device comprising:

The path decision module is configured to perform the path decision by using the forwarding device cluster as a single virtual forwarding device, where the forwarding device cluster includes multiple independent running member devices;

The flow table generating module is configured to obtain a flow table of the member device according to the result of the path decision, and control, by using the flow table, the outward flow of traffic between the member devices and the member device;

The flow table sending module is configured to send the flow table of the member device to the member device.

The above schemes fully utilize the characteristics of the network-defined network to perform centralized control on the network devices. The multiple forwarding devices that operate independently are used as a cluster to control the outbound traffic forwarding between the member devices of the cluster and the member devices. There is no need to run a proprietary protocol between the member devices, and the inter-communication between the member devices and the controller is not required.

DRAWINGS

1 is a flow chart of a control method according to Embodiment 1 of the present invention;

2 is a block diagram of an SDN controller according to an embodiment of the present invention;

3 is a schematic diagram of an example of a forwarding device cluster of the present invention.

detailed description

The embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be noted that, in the case of no conflict, the features in the embodiments and the embodiments in the present application may be arbitrarily combined with each other.

Embodiment 1

The embodiment of the present invention provides a method for controlling a forwarding device cluster in a software-defined network. According to the configuration of the administrator, the SDN controller controls the independently-operated forwarding device through the OpenFlow protocol (or other flow control protocol) to form a forwarding device cluster. Externally presented as a single virtual forwarding device.

The method for controlling the forwarding device cluster in the software definition network in this embodiment is as shown in FIG. 1 and includes:

Step 110: The SDN controller considers the forwarding device cluster as a single virtual forwarding device to perform path decision, where the forwarding device cluster includes multiple independent running member devices.

In this step, the path decision includes: determining that the virtual forwarding device forwards the traffic (that is, forwards the packet) as a virtual port of the egress port, and the virtual port can be classified into two types: an unbundled port and/or Or a bundled port, where each unbundled port corresponds to a physical port on a member device; each bundle port corresponds to multiple external physical ports on one or more member devices.

Step 120: The SDN controller obtains a flow table of the member device according to the result of the path decision, and sends the flow table to the member device, and controls the outgoing traffic of the member device and the member device by using the flow table. .

In this document, outgoing traffic forwarding of member devices refers to traffic forwarding outside the forwarding device cluster.

When the traffic forwarding is unicast traffic forwarding, the SDN controller controls the outgoing traffic forwarding between the member devices and the member device by using a flow table, including:

Controlling, by the flow meter, the first member device forwards the traffic directly from the device, and controls the second member device to forward the traffic from the device to the at least one first member device; wherein the first member device refers to A member device of the physical port corresponding to the virtual port, where the second member device refers to a member device that does not have a physical port corresponding to the virtual port.

In order to implement the control of the unicast traffic forwarding, the SDN controller obtains the flow table of the member device according to the result of the path decision, and may adopt the following manner: generating a unicast flow table of the virtual forwarding device according to the result of the path decision The unicast flow table includes the virtual port as an egress port; and the unicast flow table is modified for each member device to obtain a flow table of the member device; For the first member device, the modification includes: replacing the egress port with the physical port corresponding to the virtual port on the first member device; for each of the second member devices, the modifying includes: The physical port for the first bypass link is replaced by the second member device, and the first bypass link is the link of the second member device to the first member device.

When the unicast traffic is forwarded, the member device includes a physical port as an egress port, and the traffic is forwarded from the physical port; and the delivered flow table includes multiple physical ports as egress ports. At time, one physical port may be selected to forward traffic from the plurality of physical ports. The specific selection may be performed according to one or more of the following (two or more, any combination) strategies: a load balancing strategy; a priority policy; and a random selection strategy. In the port list delivered by the controller to the member device, you can also set the weight for each port for the member device to select when the port is selected.

When the traffic forwarding is broadcast or multicast traffic forwarding, the SDN controller controls the outbound traffic forwarding between the member devices and the member device by using a flow table, including:

For each first member device, the first member device is controlled to directly forward the traffic from the first member device by using a flow table, and for the traffic from outside the cluster of the forwarding device, the first member device is also controlled. The traffic is forwarded from the first member device to the other first member device that meets the following conditions: at least one of the virtual ports corresponding to the physical port is different from the virtual port corresponding to the physical port on the first member device;

For each second member device, the second member device is controlled by the flow table to forward traffic from the second member device to the first member device in the forwarding device cluster to switch traffic back to each of the virtual ports. Forward again;

The first member device refers to a member device that has a physical port corresponding to the virtual port, and the second member device refers to a member device that does not have a physical port corresponding to the virtual port.

In order to implement the above-mentioned broadcast or multicast traffic forwarding control, when the SDN controller obtains the flow table of the member device according to the result of the path decision, the following manner may be adopted:

Generating, according to a result of the path decision, a broadcast or multicast flow table of the virtual forwarding device, where the broadcast or multicast flow table includes the virtual port as an egress port;

And performing, by the first member device, a first modification and a second modification on the broadcast or multicast flow table, respectively, to obtain a first flow table and a second flow table of the first member device;

Performing a third modification to the broadcast or multicast flow table for each of the second member devices to obtain the first a flow table of two member devices;

The first modification includes: replacing the flag indicating that the packet is from the inside of the cluster as a new matching entry, and replacing the egress port with the physical port corresponding to the virtual port on the member device; the second modification includes Replacing the egress port with the physical port corresponding to the virtual port and the physical port set as the second bypass link on the member device, where the second bypass link is the first member device to the other first a link of the member device; the third modification includes: replacing the egress port with the physical port set as the third bypass link on the second member device, and adding a command or an action to indicate that the packet is from the packet a flag inside the cluster; the third bypass link is a link of the second member device to the first member device.

In particular, the third bypass link may include a link of the second member device to the first member device that satisfies the following condition 1 and condition 2, in addition to the link that receives the traffic, and selects in the following manner. The link of the first member device:

Condition 1, the virtual port corresponding to the physical port on the member device includes an unbundled port;

Condition 2: the virtual port corresponding to the physical port on the member device includes a first bundle port, and the first bundle port refers to a bundle port corresponding to multiple physical ports on one member device;

In a first mode, the first member device is selected from the first member devices in which the virtual port corresponding to the physical port is the second bundle port and the corresponding second bundle port is the same, and the second bundle port is selected. A bundle port corresponding to multiple physical ports on multiple member devices, the selection is performed according to one or more of the following strategies: a load balancing policy; a priority policy; and a random selection policy.

This embodiment is directed to the offline, fault, and new equipment that may occur in the forwarding device cluster. The corresponding flow table control method is also proposed, as follows:

For offline situations:

After the SDN controller determines that a member device in the forwarding device cluster is offline, the offline member device and its port are deleted from the member device surviving the forwarding device cluster; each of the forwarding device clusters survives If the member device's flow table has an outbound port connected to the offline member device, the member device's flow table is deleted from the outbound port of the offline member device, and the updated flow table is resent to the member device. The member device.

For port failures:

After the SDN controller determines that the status of a virtual port as the egress port becomes inactive (ie, fails), the physical port corresponding to the virtual port is deleted from the egress port of the corresponding flow table; For each of the first-class tables, the updated flow table is re-delivered to the corresponding member device; for each flow table that has no outgoing port after the deletion, the member device corresponding to the flow table is connected to the entity of the first member device. The port is added to the egress port of the flow table, and the updated flow table is re-delivered to the corresponding member device. After an unbundled port becomes inactive for one unbound port, it is determined that the unbundled port becomes inactive. For a bundled port, after the corresponding multiple physical ports become inactive, it is determined that the bundled port becomes inactive.

For communication failures between member devices:

After the SDN controller determines that a member device is connected to the physical port of the first member device or the link corresponding to the physical port is invalid, the physical port of the member device is updated as the physical port of the egress port. The updated flow table is resent to the member device for connecting to the physical port of the other first member device.

For the case of cluster splitting:

After the SDN controller determines that the forwarding device cluster is in a split state (ie, the clusters become two or more parts that are not connected to each other), record an interconnection port between the inactive virtual port and the member device. And the link between the member devices that are invalidated, and the linkage port on the member device is disabled; and the path determination is performed on the virtual forwarding device, and the flow table of the member device is obtained according to the result of the path decision. And sent to the member device.

For the case of joining a new member device:

After the SDN controller determines that a member device joins the forwarding device cluster, the flow table of the member device is obtained according to the result of the path decision, and is sent to the member device, and the member device has the virtual port. The corresponding physical port (for example, if the newly added member device has a physical port added to the existing bundle port), the flow table of the original member device is updated and delivered to the corresponding member device according to the new topology of the forwarding device cluster. .

The embodiment also provides a controller in a software-defined network, including a cluster control device. As shown in FIG. 2, the cluster control device includes:

The path decision module 10 is configured to perform the path decision by using the forwarding device cluster as a single virtual forwarding device, where the forwarding device cluster includes multiple independent running member devices;

The flow table generating module 20 is configured to obtain a flow table of the member device according to the result of the path decision, and control, by using the flow table, the outward flow forwarding between the member devices and the member device;

The flow table issuing module 30 is configured to send the flow table of the member device to the member device.

Optionally,

The path decision module 10 performs a path decision, including: determining a virtual port that is an outbound port that forwards the traffic to the virtual forwarding device, where the virtual port includes an unbundled port and/or a bundle port, where: each unbundled A port corresponds to a physical port on a member device. Each bundle port corresponds to multiple external physical ports on one or more member devices.

Optionally,

The flow table generating module 20 controls the outbound traffic forwarding between the member devices and the member device by using the flow table, including: when the traffic forwarding is unicast traffic forwarding, the first member device is controlled by the flow table. The traffic is directly forwarded from the device, and the second member device is configured to forward the traffic from the device to the at least one first member device. The first member device refers to the physical port corresponding to the virtual port. Member set The second member device refers to a member device that does not have a physical port corresponding to the virtual port.

Optionally,

The flow table generating module 20 obtains the flow table of the member device according to the result of the path decision, and includes: when the traffic is forwarded to the unicast traffic, the unicast flow table of the virtual forwarding device is generated according to the result of the path decision. The unicast flow table includes the virtual port as an egress port; and the unicast flow table is modified for each member device to obtain a flow table of the member device;

For each of the first member devices, the modification includes: replacing the egress port with a physical port corresponding to the virtual port on the first member device; The modification includes: replacing the egress port with the physical port set as the first bypass link on the second member device, where the first bypass link is the link of the second member device to the first member device.

Optionally,

The flow table generating module 20 controls the outbound traffic forwarding between the member devices and the member device by using the flow table, including: when the traffic forwarding is broadcast or multicast traffic forwarding, for each first member device And controlling, by the flow table, the first member device to directly forward the traffic from the first member device, and controlling, by the first member device, the traffic from the first member device for the traffic from the outside of the forwarding device cluster Forwarding to the other first member device that meets the following conditions: at least one of the virtual ports corresponding to the physical port is different from the virtual port corresponding to the physical port on the first member device; and, for each second member device, the flow table is Controlling, by the second member device, the traffic from the second member device to the first member device in the forwarding device cluster, to forward the traffic back to each of the virtual ports, and then forward the traffic; wherein, the first A member device refers to a member device having a physical port corresponding to the virtual port, and the second member device refers to having no pair with the virtual port. Members device entity port.

Optionally,

The flow table generating module 20 obtains the flow table of the member device according to the result of the path decision, including: when the traffic forwarding is broadcast or multicast traffic forwarding, generating a broadcast of the virtual forwarding device according to the result of the path decision a multicast flow table, the broadcast or multicast flow table including the virtual port as an egress port; and for each of the first member devices, performing a first modification and a second modification on the broadcast or multicast flow table Obtaining a first flow table and a second flow table of the first member device respectively;

The first modification includes: replacing the flag indicating that the packet is from the inside of the cluster as a new matching entry, and replacing the egress port with the physical port corresponding to the virtual port on the member device; the second modification includes Replacing the egress port with the physical port corresponding to the virtual port and the physical port set as the second bypass link on the member device, where the second bypass link is the first member device to the other first The link of the member device.

Optionally,

The flow table generating module 20 obtains the flow table of the member device according to the result of the path decision, and includes: when the traffic forwarding is broadcast or multicast traffic forwarding, generating the virtual forwarding device according to the result of the path decision. a broadcast or multicast flow table, the broadcast or multicast flow table including the virtual port as an egress port; for each of the second member devices, performing a third modification on the broadcast or multicast flow table to obtain a flow table of the second member device;

The third modification includes: replacing the egress port with the physical port for the third bypass link on the second member device, and adding a command or an action to mark the packet with a flag indicating that the packet is from the inside of the cluster; The third bypass link is a link of the second member device to the first member device.

Optionally,

The third bypass link includes a link of the second member device to the first member device that satisfies the following condition 1 and condition 2, in addition to the link that receives the traffic, and the first member selected in the following manner Device link:

In a first mode, the first member device is selected from the first member devices in which the virtual port corresponding to the physical port is the second bundle port and the corresponding second bundle port is the same, and the second bundle port is selected. a bundle port corresponding to multiple physical ports on multiple member devices;

The selection is performed according to one or more of the following strategies: a load balancing policy; a priority policy; and a random selection policy.

Optionally,

The cluster control device further includes one or more of the following modules:

The offline processing module is configured to: after determining that a member device in the forwarding device cluster is offline, deleting the offline member device and its port from the member device surviving the forwarding device cluster; and surviving the forwarding device cluster If the member device's flow table has an egress port connected to the offline member device, the egress port of the member device's flow table connected to the offline member device is deleted, and the updated flow table is re-updated. Issued to the member device;

The port failure processing module is configured to delete the physical port corresponding to the virtual port from the egress port of the corresponding flow table after determining that the status of the virtual port as the egress port becomes inactive; and For each flow table, the updated flow table is re-sent to the corresponding member device; for each flow table that has no outgoing port after the deletion, the member device corresponding to the flow table is connected to the first member device. The physical port is added to the egress port of the flow table, and the updated flow table is re-delivered to the corresponding member device.

The communication fault processing module is configured to: after determining that the physical port of the member device is connected to the first member device or the link corresponding to the physical port is invalid, the flow table of the member device is used as the out port The physical port is updated to be connected to the physical port of the other first member device, and the updated flow table is resent to the member device;

The cluster split processing module is configured to: after determining that the forwarding device cluster is in a split state, the record is in An interconnection port between the inactive virtual port and the member device, and a link between the failed member devices, and disabling the linkage port on the member device; and restarting the virtual forwarding device Performing a path decision, and obtaining a flow table of the member device according to the result of the path decision and delivering the flow table to the member device;

The member joins the processing module, and the SDN controller determines that a member device joins the forwarding device cluster, obtains a flow table of the member device according to the result of the path decision, and sends the flow table to the member device, and has the member device The flow table of the original member device is updated and sent to the corresponding member device according to the new topology of the forwarding device cluster.

The following is an example of several applications.

Example one

This example involves the formation and configuration of a cluster.

The SDN controller controls multiple independent forwarding devices through the OpenFlow protocol to form a forwarding device cluster, which is presented as an integrated logical device. As shown in Figure 3, in this example, the cluster consists of two OpenFlow forwarding devices, identified as DPID 1 and DPID 2. The two forwarding devices have ports numbered 1, 2, 3, 4, 5, and 6, respectively.

There are interconnected links between the member devices of the forwarding device cluster, that is, the link between port 3 of DPID 1 and port 3 of DPID 2, port 4 of DPID 1 and port 4 of DPID 2 in FIG. Not visible outside the cluster. The link between the member devices can be configured by the administrator. The SDN controller maintains the status of the internal link through link detection or path detection.

As shown in the figure, the virtual forwarding device presented by the forwarding device cluster exposes six ports (1, 2, 3, 4, 5, and 6 in Figure 1) and is divided into two categories:

Unbundled ports (1, 2, 3, 4): An unbundled port directly corresponds to a physical port on a member device that constitutes the cluster (that is, outside the cluster), such as

port

1, 2, and DPID2 on

DPID1. Port

1, 2. An unbundled port is interconnected with a neighbor device through an unbundled link. The port status directly corresponds to the state of the physical port.

Bundle port (5, 6): A bundle port corresponds to one or more members of the cluster to forward multiple physical ports on the device. For example, port 5 on DPID 1 and port 5 on DPID 2 are bundled to form port 5, DPID. Port 6 on 1 and port 6 on DPID 2 are bundled to form port 6. When any of the physical port states is active, the bundled port status is active. When all port states are inactive, the bundled port status is inactive. . The bundled port is connected to the neighbor through the bundled link. The corresponding port of the neighboring device must also be bundled. It can be statically configured or negotiated through the aggregation protocol.

Example two:

This example relates to the control of unicast traffic forwarding for a forwarding device cluster.

The SDN controller of this example delivers forwarding entries through the OpenFlow protocol to control and forward the device cluster. Off unicast traffic forwarding, including:

Step 1: The SDN controller regards the forwarding device cluster as a virtual forwarding device, and performs a path decision according to the network topology, and obtains a unicast flow table for controlling the virtual forwarding device to forward the unicast traffic.

Step 2: The SDN controller modifies the unicast flow table according to the physical port on the member device corresponding to the virtual port of the outbound port in the unicast flow table, and obtains the flow table of each member device and sends the flow table to each member device.

Specifically, for a member device, the following traffic forwarding control can be implemented through a flow table:

If the traffic is forwarded directly through the device, the device has a physical port corresponding to the virtual port (corresponding to the first member device in the above, the physical port on the device may correspond to the unbundled port, and may also correspond to If the physical port is one of the plurality of physical ports corresponding to the bundled port, the physical port is controlled by the flow table to control the member device to forward the traffic directly from the device. Go out.

If the traffic needs to be sent back through the other member devices of the cluster, that is, if the device does not have a physical port corresponding to the virtual port (corresponding to the second member device in the above), the member device is controlled to flow back through the flow table. Forward to other member devices.

For the unicast flow table of the virtual forwarding device, how to obtain the flow table of each member device is described in detail above, and details are not described herein again. After receiving the flow table, the member device can select one of the outbound port groups in the flow table as the actual forwarding port.

According to the above rules, further examples are given according to the cluster topology shown in FIG. 3:

Example 1: The virtual outgoing port is 1, 5.

Both the DPID 1 and the DPID 2 can forward the traffic directly, and the following ports are selected as the egress port in the flow table delivered to the DPID 1 and the DPID 2: the egress port of the flow table delivered to the DPID 1 is 1, 5, and the DPID 2 The outgoing port of the delivered flow table is 5.

Example 2: The virtual outgoing port is 1, 2.

The DPID 1 can directly forward the traffic. The port is determined by the method in the example 1. The outgoing port of the forwarding table sent to DPID 1 is 1, 2.

The DPID 2 needs to forward the traffic to the DPID 1 and the port corresponding to the bypass link of the member device with the available egress port as the egress port. The egress port of the flow table delivered to DPID 2 is 3 or 4.

Example three

This example relates to the control of forwarding device cluster broadcast or multicast traffic forwarding.

The SDN controller of this example delivers forwarding entries through the OpenFlow protocol to control traffic broadcast or multicast forwarding related to the forwarding device cluster, including:

Step 1: The SDN controller regards the forwarding device cluster as a virtual forwarding device, performs path decision according to the network topology, and obtains a broadcast or multicast flow table for controlling the virtual forwarding device to forward broadcast or multicast traffic; broadcast or multicast Packets need to be forwarded from multiple ports on the virtual forwarding device.

Step 2: The SDN controller modifies the broadcast or multicast flow table according to the physical port on the member device corresponding to the virtual port of the outbound port in the broadcast or multicast flow table, and obtains the flow table of each member device and delivers the flow table to each member device. Member equipment.

If the traffic is forwarded directly through the device (that is, the device is the first member device), the packets received from the cluster member devices are controlled by the flow table to forward the traffic directly from the device. The packets received by the device other than the cluster are forwarded through the flow table to control the member device to forward traffic from the device. The device also controls the member device to forward the device from the device to other first member devices. At least one of the virtual ports corresponding to the physical port on the first member device is different from the virtual port corresponding to the physical port on the device. That is, if another first member device has the same bundle port as the own device, it may not be forwarded to the other first member device. To identify whether the packet is received from the cluster member device or received from the device outside the cluster, you can add a command or action to the flow table of the second member device. The logo inside the cluster. At the same time, two flow tables are sent to the first member device, and the tag is added to the flow table as a match. If the match is successful, it means that the packet is received from the member device, and the match is successful. The flow table is matched.

If the traffic needs to be sent out by other member devices of the cluster (that is, the device is the second member device), the member device is controlled by the flow table to forward the traffic from the device to the first member device, so that the traffic is returned to each device. The virtual port is forwarded again. A member port of a bundled port is distributed among multiple forwarding devices, and multiple internal links are available between a pair of devices. The controller needs to select which ports to join the outbound port list to prevent multiple packets from being sent back. Port output. See the detailed description above for how to specifically select the link when detouring. In addition, for the traffic that needs to be bypassed, a command or an action is added to the forwarding table that is sent to the second member device, and the flag indicating that the packet is from the cluster is added to the forwarded packet, for example, by adding a VLAN tag or a tunnel identifier. Mark the flag for subsequent device identification and determine subsequent forwarding actions.

For the flow table of each member device obtained from the broadcast or multicast flow table of the virtual forwarding device, it has been described in detail above, and details are not described herein again.

Example: The virtual outgoing port is 1, 5;

A flow table is sent to the DPID 1 (also referred to as a forwarding entry). A flow table adds a matching item for identifying the packet received from the DPID 2 on the basis of the original matching item, and the egress port is 1, and the other port is 1. The outbound port of a flow table is 1, 5.

One forwarding entry is sent to and from the DPID 2, and the egress port is 5, 3. However, the packet sent from the DPID 1 is directly discarded, that is, the link that receives the packet is not used as the bypass link.

Example four

This example involves the SDN controller updating the surviving device when the cluster member device fails offline. A flow table that restores traffic to normal forwarding, including:

Step 1: The SDN controller detects that a member device in the forwarding device cluster is offline.

Step 2: The SDN controller maintains the state of the forwarding device cluster, and removes the offline device and related ports from the cluster;

Step 3: If the traffic received by other surviving member devices in the cluster is originally forwarded by the offline device, you need to select other available bypass paths. Therefore, the SDN controller updates the flow table of these devices, that is, the original outgoing port connected to the offline device should be deleted, and only the outgoing port to other retractable devices is reserved.

Example five

In this example, when the status of the external port on the member device of the cluster is changed to inactive, the SDN controller restores the normal forwarding of the traffic by updating the entries on the surviving device, including:

Step 1: The forwarding device reports, or the SDN controller detects that the status of a port on the cluster member is changed to inactive.

Step 2: The SDN controller deletes the port from the affected flow table, that is, updates the flow table:

If the member device of the port is removed from the egress port of the member device, the device does not have any member ports of the port. If the device needs to be bypassed by other devices, the device is added to the port of the device. Out port

For other member devices, the original forwarding path is forwarded through the port. The bypass path is modified, and the port is removed from the outbound port of the flow table, and the outgoing port of the other switchable device is reserved.

Example six

In this example, when the internal link of the cluster is interrupted, the SDN controller restores the normal forwarding of the traffic by updating the entries on the surviving device, including:

Step 1: The forwarding device reports or the controller detects that a port connected to other members on the cluster member is changed to inactive, or the controller detects that the internal path of the cluster is invalid.

Step 2: For the member devices that need to be forwarded through the port or link, modify the egress port in the flow table and switch back from other links.

Example seven

This example involves the internal link failure of the cluster and the change of the status of the bundled port member to the inactive superimposed fault scenario. The SDN controller disables the port on the device by performing the port linkage policy, triggers the path recalculation and resumes normal forwarding, including:

Step one, the SDN controller determines that the cluster is in a split state;

If the status of the bundled port member is changed to inactive, or the member of the bundled port is inactive, the forwarding device reports or the controller detects the inter-cluster port connectivity. The state changes to inactive, etc., and the SDN controller can determine whether the cluster is in a split state, that is, become multiple parts that are not connected to each other.

Step 2: The SDN controller disables the linkage port on the device according to the linkage policy; if the linkage port includes a port that should be closed after a port fails.

Step 3: The SDN controller recalculates the path according to the current cluster topology, and delivers the forwarding table, so that the traffic is forwarded through other member devices of the cluster and other member ports of the bundled port.

Example eight:

This example involves a method in which a member of the cluster is in a normal working state, a faulty member is restored, or a new member device is added, and the SDN controller joins the device to the cluster to enable traffic to be forwarded by the device, including:

Step 1: The cluster member device establishes a connection with the controller and completes initialization, and the SDN controller joins the device to the cluster to maintain the related state.

Step 2: The SDN controller generates a delivered entry for the newly added device, and updates the flow table of the other device according to the new cluster topology.

Step 3: The flow meter is sent, and the newly added device can be used normally.

The serial numbers of the embodiments of the present invention are merely for the description, and do not represent the advantages and disadvantages of the embodiments. Through the description of the above embodiments, those skilled in the art can clearly understand that the foregoing embodiment method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is better. Implementation. Based on such understanding, the technical solution of the embodiments of the present invention may be embodied in the form of a software product in essence or in the form of a software product stored in a storage medium (such as ROM/RAM, magnetic). The disc, the optical disc, includes a number of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to execute the controllers described in various embodiments of the present invention.

The modules such as the path decision module, the flow table generation module, and the flow table delivery module may include software loaded on a server or related device and/or combined or interacted with related hardware. For example, the path decision module may include a corresponding logic circuit. Or include the corresponding program in the server system. Each of the above modules may be each functional module in the same software system, or may belong to different software/operating systems.

The above are only the preferred embodiments of the present invention, and are not intended to limit the scope of the invention, and the equivalent structure or equivalent process transformations made by the description of the present invention and the drawings are directly or indirectly applied to other related technical fields. The same is included in the scope of patent protection of the present invention.

Practicality of work

The invention is applicable to the field of the software-defined network, and is used for inter-communication between the member devices without running a proprietary protocol, and the link maintenance of the member device and the controller does not need special processing, and is relatively simple.

Claims

A method for controlling a cluster of forwarding devices in a software-defined network, comprising:

The software-defined network SDN controller treats the forwarding device cluster as a single virtual forwarding device for path decision, wherein the forwarding device cluster includes multiple independently running member devices;

And the SDN controller obtains the flow table of the member device according to the result of the path decision, and sends the flow table to the member device, and controls the outgoing traffic of the member device and the member device by using the flow table.
The method of claim 1 wherein:

The path decision includes: determining a virtual port that is an outbound port that forwards the traffic to the virtual forwarding device, where the virtual port includes an unbundled port and/or a bundle port, where:

Each unbundled port corresponds to a physical port on a member device;

Each bundle port corresponds to multiple external physical ports on one or more member devices.
The method of claim 2 wherein:

When the traffic forwarding is unicast traffic forwarding, the SDN controller controls the outgoing traffic forwarding between the member devices and the member device by using a flow table, including:

Controlling, by the flow meter, the first member device forwards the traffic directly from the device, and controls the second member device to forward the traffic from the device to the at least one first member device; wherein the first member device refers to A member device of the physical port corresponding to the virtual port, where the second member device refers to a member device that does not have a physical port corresponding to the virtual port.
The method of claim 3 wherein:

When the traffic is forwarded to the unicast traffic, the SDN controller obtains the flow table of the member device according to the result of the path decision, including:

Generating, according to the result of the path decision, the unicast flow table of the virtual forwarding device, where the unicast flow table includes the virtual port as an egress port; and for each of the member devices, performing the unicast flow table Modify to get the flow table of the member device;

For each of the first member devices, the modification includes: replacing the egress port with a physical port corresponding to the virtual port on the first member device; The modification includes: replacing the egress port with the physical port set as the first bypass link on the second member device, where the first bypass link is the link of the second member device to the first member device.
The method of claim 3 wherein:

The SDN controller obtains the flow table of the member device according to the result of the path decision and sends the flow table to the member device according to the result of the path decision, and further includes:

When the delivered flow table includes a physical port as an egress port, the member device forwards traffic from the physical port;

When a plurality of physical ports that are outbound ports are included in the delivered flow table, the member device selects one of the multiple physical ports to forward traffic.
The method of claim 2 wherein:

When the traffic forwarding is broadcast or multicast traffic forwarding, the SDN controller controls the outbound traffic forwarding between the member devices and the member device by using a flow table, including:

For each first member device, the first member device is controlled to directly forward the traffic from the first member device by using a flow table, and for the traffic from outside the cluster of the forwarding device, the first member device is also controlled. The traffic is forwarded from the first member device to the other first member device that meets the following conditions: at least one of the virtual ports corresponding to the physical port is different from the virtual port corresponding to the physical port on the first member device;

For each second member device, the second member device is controlled by the flow table to forward traffic from the second member device to the first member device in the forwarding device cluster to switch traffic back to each of the virtual ports. Forward again;

The first member device refers to a member device that has a physical port corresponding to the virtual port, and the second member device refers to a member device that does not have a physical port corresponding to the virtual port.
The method of claim 6 wherein:

When the traffic forwarding is broadcast or multicast traffic forwarding, the SDN controller obtains a flow table of the member device according to the result of the path decision, including:

Generating, according to the result of the path decision, a broadcast or multicast flow table of the virtual forwarding device, where the broadcast or multicast flow table includes the virtual port as an egress port; for each of the first member devices, The first modification and the second modification are performed on the broadcast or multicast flow table, and the first flow table and the second flow table of the first member device are respectively obtained;

The first modification includes: replacing the flag indicating that the packet is from the inside of the cluster as a new matching entry, and replacing the egress port with the physical port corresponding to the virtual port on the member device; the second modification includes Replacing the egress port with the physical port corresponding to the virtual port and the physical port set as the second bypass link on the member device, where the second bypass link is the first member device to the other first The link of the member device.
The method of claim 6 or 7, wherein:

When the traffic forwarding is broadcast or multicast traffic forwarding, the SDN controller obtains a flow table of the member device according to the result of the path decision, including:

Generating, according to the result of the path decision, a broadcast or multicast flow table of the virtual forwarding device, where the broadcast or multicast flow table includes the virtual port as an egress port; for each of the second member devices, Performing a third modification to the broadcast or multicast flow table to obtain a flow table of the second member device;

The third modification includes: replacing the egress port with the physical port set as the third bypass link on the second member device, and adding a command or an action to mark the packet with a flag indicating that the packet is from the inside of the cluster; The third bypass link is a link of the second member device to the first member device.
The method of claim 8 wherein:

The third bypass link includes, in addition to the link receiving the traffic, the second member device meets the following The link of the first member device of condition one and condition two, and the link of the first member device selected in the following manner:

Condition 1, the virtual port corresponding to the physical port on the member device includes an unbundled port;

Condition 2: the virtual port corresponding to the physical port on the member device includes a first bundle port, and the first bundle port refers to a bundle port corresponding to multiple physical ports on one member device;

In a first mode, the first member device is selected from the first member devices in which the virtual port corresponding to the physical port is the second bundle port and the corresponding second bundle port is the same, and the second bundle port is selected. A bundle port that corresponds to multiple physical ports on multiple member devices.
A method as claimed in claim 5 or claim 9, wherein:

The selection is based on one or more of the following strategies:

Load balancing strategy;

Priority strategy

Randomly choose a strategy.
A method as claimed in any one of claims 3-7, wherein:

After the SDN controller sends the flow table to the member device, the SDN controller further includes:

After the SDN controller determines that a member device in the forwarding device cluster is offline, the offline member device and its port are deleted from the member device in which the forwarding device cluster survives;

If the member device of the forwarding device has an outgoing port connected to the offline member device, the member device's flow table is deleted from the outbound port of the offline member device. The updated flow table is delivered to the member device.
A method as claimed in any one of claims 3-7, wherein:

After the SDN controller sends the flow table to the member device, the SDN controller further includes:

After the SDN controller determines that the status of a virtual port as the egress port becomes inactive, the physical port corresponding to the virtual port is deleted from the egress port of the corresponding flow table;

After the flow table is deleted, the updated flow table is sent to the corresponding member device.

For each flow table that has no outgoing port after the deletion, the physical port connected to the first member device of the member device corresponding to the flow table is added as the egress port of the flow table, and the updated flow table is re-opened. Send to the corresponding member device.
A method as claimed in any one of claims 3-7, wherein:

After the SDN controller sends the flow table to the member device, the SDN controller further includes:

After the SDN controller determines that a member device is connected to the physical port of the first member device or the link corresponding to the physical port is invalid, the physical port of the member device is updated as the physical port of the egress port. The updated flow table is resent to the member device for connecting to the physical port of the other first member device.
A method as claimed in any one of claims 3-7, wherein:

After the SDN controller determines that the forwarding device cluster is in a split state, records an interconnection port between the inactive virtual port and the member device, and a link between the failed member devices, and disables a linkage port on the member device;

The SDN controller re-routes the virtual forwarding device, and obtains a flow table of the member device according to the result of the path decision, and sends the flow table to the member device.
A method as claimed in any one of claims 3-7, wherein:

After the SDN controller sends the flow table to the member device, the SDN controller further includes:

After the SDN controller determines that a member device joins the forwarding device cluster, the flow table of the member device is obtained according to the result of the path decision, and is sent to the member device, and the member device has the virtual port. The flow table of the original member device is updated and sent to the corresponding member device according to the new topology of the forwarding device cluster.
A controller in a software-defined network, comprising a cluster control device, the cluster control device comprising:

The path decision module is configured to perform the path decision by using the forwarding device cluster as a single virtual forwarding device, where the forwarding device cluster includes multiple independent running member devices;

The flow table generating module is configured to obtain a flow table of the member device according to the result of the path decision, and control, by using the flow table, the outward flow of traffic between the member devices and the member device;

The flow table sending module is configured to send the flow table of the member device to the member device.
The controller of claim 16 wherein:

The path decision module performs path decision, including: determining a virtual port that is an outbound port that forwards the traffic to the virtual forwarding device, where the virtual port includes an unbundled port and/or a bundle port, where: each unbundled port Corresponding to a physical port on a member device; each bundle port corresponds to multiple external physical ports on one or more member devices.
The controller of claim 17 wherein:

The flow table generating module controls, by the flow table, the traffic forwarding between the member devices and the member device, including: when the traffic forwarding is unicast traffic forwarding, the first member device controls the traffic through the flow table. Forwarding directly from the device to control the second member device to forward traffic from the device to the at least one first member device; wherein the first member device refers to a member that has a physical port corresponding to the virtual port The device, the second member device refers to a member device that does not have a physical port corresponding to the virtual port.
The controller of claim 18 wherein:

The flow table generating module obtains the flow table of the member device according to the result of the path decision, and includes: when the traffic forwarding is unicast traffic forwarding, generating a unicast flow table of the virtual forwarding device according to the result of the path decision, The unicast flow table includes the virtual port as an egress port; and the unicast flow table is modified for each member device to obtain a flow table of the member device;

The modification includes: replacing the egress port with the first component for each of the first member devices The physical port corresponding to the virtual port on the member device; the modification includes: replacing the egress port with the physical port set as the first bypass link on the second member device, The first bypass link is a link of the second member device to the first member device.
The controller of claim 17 wherein:

The flow table generating module controls the outbound traffic forwarding between the member devices and the member device by using the flow table, including: when the traffic forwarding is broadcast or multicast traffic forwarding, for each first member device, And controlling, by the flow table, the first member device to directly forward the traffic from the first member device, and controlling, by the first member device, the traffic from the first member device to the traffic from the outside of the forwarding device cluster The first member device that meets the following conditions is forwarded: at least one of the virtual ports corresponding to the physical port is different from the virtual port corresponding to the physical port on the first member device; and, for each second member device, is controlled by the flow table. The second member device forwards traffic from the second member device to the first member device in the forwarding device cluster to forward the traffic back to each of the virtual ports and forwards the traffic to the virtual port; wherein the first member The device refers to a member device that has a physical port corresponding to the virtual port, and the second member device does not have a corresponding device corresponding to the virtual port. Member entity device port.
The controller of claim 20 wherein:

The flow table generating module obtains the flow table of the member device according to the result of the path decision, and includes: when the traffic forwarding is broadcast or multicast traffic forwarding, generating a broadcast or group of the virtual forwarding device according to the result of the path decision a broadcast flow table, where the broadcast or multicast flow table includes the virtual port as an egress port; and for each of the first member devices, perform a first modification and a second modification on the broadcast or multicast flow table, Obtaining a first flow table and a second flow table of the first member device respectively;

The first modification includes: replacing the flag indicating that the packet is from the inside of the cluster as a new matching entry, and replacing the egress port with the physical port corresponding to the virtual port on the member device; the second modification includes Replacing the egress port with the physical port corresponding to the virtual port and the physical port set as the second bypass link on the member device, where the second bypass link is the first member device to the other first The link of the member device.
A controller according to claim 20 or 21 wherein:

The flow table generating module obtains the flow table of the member device according to the result of the path decision, and includes: when the traffic forwarding is broadcast or multicast traffic forwarding, generating a broadcast or group of the virtual forwarding device according to the result of the path decision a broadcast flow table, the broadcast or multicast flow table includes the virtual port as an egress port; for each of the second member devices, performing a third modification on the broadcast or multicast flow table to obtain the second a flow table of member devices;

The third modification includes: replacing the egress port with the physical port set as the third bypass link on the second member device, and adding a command or an action to mark the packet with a flag indicating that the packet is from the inside of the cluster; The third bypass link is a link of the second member device to the first member device.
The controller of claim 22 wherein:

The third bypass link includes a link of the second member device to the first member device that satisfies the following condition 1 and condition 2, in addition to the link that receives the traffic, and the first member selected in the following manner Device link:

Condition 1, the virtual port corresponding to the physical port on the member device includes an unbundled port;

Condition 2: the virtual port corresponding to the physical port on the member device includes a first bundle port, and the first bundle port refers to a bundle port corresponding to multiple physical ports on one member device;

In a first mode, the first member device is selected from the first member devices in which the virtual port corresponding to the physical port is the second bundle port and the corresponding second bundle port is the same, and the second bundle port is selected. a bundle port corresponding to multiple physical ports on multiple member devices;

The selection is performed according to one or more of the following strategies: a load balancing policy; a priority policy; and a random selection policy.
A controller as claimed in any one of claims 17 to 21, wherein:

The cluster control device further includes one or more of the following modules:

The offline processing module is configured to: after determining that a member device in the forwarding device cluster is offline, deleting the offline member device and its port from the member device surviving the forwarding device cluster; and surviving the forwarding device cluster If the member device's flow table has an egress port connected to the offline member device, the egress port of the member device's flow table connected to the offline member device is deleted, and the updated flow table is re-updated. Issued to the member device;

The port failure processing module is configured to delete the physical port corresponding to the virtual port from the egress port of the corresponding flow table after determining that the status of the virtual port as the egress port becomes inactive; and For each flow table, the updated flow table is re-sent to the corresponding member device; for each flow table that has no outgoing port after the deletion, the member device corresponding to the flow table is connected to the first member device. The physical port is added to the egress port of the flow table, and the updated flow table is re-delivered to the corresponding member device.

The communication fault processing module is configured to: after determining that the physical port of the member device is connected to the first member device or the link corresponding to the physical port is invalid, the flow table of the member device is used as the out port The physical port is updated to be connected to the physical port of the other first member device, and the updated flow table is resent to the member device;

The cluster split processing module is configured to: after determining that the forwarding device cluster is in a split state, record an interconnect port between the inactive virtual port and the member device, and a link between the failed member devices And disabling the linkage port on the member device; and performing a path decision on the virtual forwarding device, and obtaining a flow table of the member device according to the result of the path decision, and sending the flow table to the member device;

The member joins the processing module, and the SDN controller determines that a member device joins the forwarding device cluster, and obtains a flow table of the member device according to the result of the path decision, and sends the flow table to the member device, where the member device has When the physical port corresponding to the virtual port is used, the new topology of the forwarding device cluster is used. The flow table of the member device is updated and delivered to the corresponding member device.