CN109450709B

CN109450709B - Asynchronous message configuration method, uploading method, controller and network equipment

Info

Publication number: CN109450709B
Application number: CN201811562607.3A
Authority: CN
Inventors: 宋小恒
Original assignee: New H3C Technologies Co Ltd
Current assignee: New H3C Information Technologies Co Ltd
Priority date: 2018-12-20
Filing date: 2018-12-20
Publication date: 2022-02-11
Anticipated expiration: 2038-12-20
Also published as: CN109450709A

Abstract

The application provides an asynchronous message configuration method, an uploading method, a controller and network equipment, wherein the controller issues asynchronous message configuration carrying a message type, an identifier of the controller and a sharing weight to the network equipment, and the network equipment performs sharing uploading according to the received asynchronous message configuration, so that the sharing uploading of the same type of asynchronous messages can be realized.

Description

Asynchronous message configuration method, uploading method, controller and network equipment

Technical Field

The present application relates to the field of network communication technologies, and in particular, to an asynchronous message configuration method, an asynchronous message uploading method, a controller, and a network device.

Background

SDN (Software Defined Network) is a novel Network architecture, and by separating a control plane and a forwarding plane of a Network, a controller manages the control plane of each Network device, so as to implement unified control on routing and transmission rule policies of the Network devices, and thereby enable flow control of the Network to be more flexible. In order to improve the processing capability and disaster tolerance capability of the controller in the SDN architecture, in some embodiments, a controller cluster including a plurality of controllers is used to control the SDN network device.

Disclosure of Invention

In a first aspect, the present application provides an asynchronous message configuration method, which is applied to a master controller in an SDN architecture controller cluster; the method comprises the following steps:

acquiring asynchronous message configuration of network equipment, wherein the asynchronous message configuration comprises a message type, an identifier of a controller included in at least one controller cluster and a sharing weight corresponding to the identifier of the controller;

and sending the asynchronous message configuration to network equipment so that the network equipment respectively sends asynchronous messages corresponding to the message types in the network equipment to corresponding controllers included in the asynchronous message configuration according to the sharing weight corresponding to the identifier of each controller according to the asynchronous message configuration.

Optionally, in the method, the step of obtaining the asynchronous message configuration of the network device includes:

different asynchronous message configurations corresponding to different network devices are obtained, wherein identifiers or sharing weights of controllers in different asynchronous messages are different.

Optionally, in the above method, further comprising:

detecting the working state of a slave controller in the controller cluster;

and when the slave controller is detected to have a fault, issuing new asynchronous message configuration aiming at the network equipment which sends asynchronous messages to the faulty slave controller, so that the network equipment which receives the new asynchronous message configuration sends asynchronous messages to the controller which works normally according to the new asynchronous message configuration.

Optionally, in the above method, the asynchronous message configuration further includes a message uploading mode corresponding to the message type, where the message uploading mode includes unicast uploading or broadcast uploading;

then, the step of sending the asynchronous message configuration to the network device includes:

sending asynchronous message configuration carrying the message uploading mode to network equipment, enabling the message type of the received asynchronous message configuration to be unicast uploading network equipment, and according to the asynchronous message configuration, respectively unicast uploading asynchronous messages corresponding to the message type in the network equipment to corresponding controllers included in the asynchronous message configuration according to the sharing weight corresponding to the identifier of each controller; or the message type of the received asynchronous message configuration is the network equipment which is transmitted by the broadcast, and the asynchronous message corresponding to the message type in the network equipment is broadcasted in the controller cluster according to the asynchronous message configuration.

In a second aspect, the present application provides an asynchronous message uploading method, which is applied to a network device adopted in an SDN architecture, and the method includes:

receiving asynchronous message configuration issued by a controller cluster, wherein the asynchronous message configuration comprises a message type, an identifier of a controller included in at least one controller cluster and a sharing weight corresponding to the identifier of the controller;

and according to the asynchronous message configuration, respectively uploading the asynchronous messages corresponding to the message types in the network equipment to corresponding controllers included in the asynchronous message configuration according to the sharing weight corresponding to the identifier of each controller.

the step of sending the asynchronous message corresponding to the message type in the network device to the corresponding controller in the controller cluster according to the sharing weight corresponding to the identifier of each controller includes:

for the asynchronous messages of which the message types correspond to unicast uploading, according to the asynchronous message configuration, respectively unicast and upload the asynchronous messages corresponding to the message types in the network equipment to corresponding controllers included in the asynchronous message configuration according to the sharing weight corresponding to the identifier of each controller; the method further comprises the following steps:

and for the asynchronous message of which the message type corresponds to the broadcast uploading, broadcasting the asynchronous message of the message type in the controller cluster.

Optionally, in the method, the step of sending the asynchronous message corresponding to the message type in the network device to the corresponding controller in the controller cluster according to the sharing weight corresponding to the identifier of each controller includes:

respectively calculating the ratio of the sharing weight corresponding to the identifier of each controller in the asynchronous message configuration to the sum of the sharing weights of the controllers in the controller cluster as the sharing proportion corresponding to the identifier of the controller;

and sharing the asynchronous message corresponding to the message type in the network equipment according to the sharing proportion corresponding to the identifier of each controller and sending the asynchronous message to the corresponding controller in the controller cluster.

Optionally, in the above method, the controller cluster includes a master controller and a slave controller, and the step of receiving the asynchronous message configuration sent by the controller cluster includes:

obtaining the asynchronous message configuration from the master controller;

the method further comprises the following steps:

and when receiving a configuration acquisition request sent by any slave controller, sending the asynchronous message configuration of the network equipment to the slave controller.

In a third aspect, the present application provides a controller comprising a machine-readable storage medium and a processor, the machine-readable storage medium storing machine-executable instructions that, when invoked or executed by the processor, cause the controller to implement the asynchronous message configuration method provided herein.

In a fourth aspect, the present application provides a network device comprising a machine-readable storage medium and a processor, the machine-readable storage medium storing machine-executable instructions that, when invoked or executed by the processor, cause the network device to implement a method as described above for a message provided herein.

Compared with the prior art, the method has the following beneficial effects:

in the asynchronous message configuration method, the forwarding method, the controller and the network device provided in this embodiment, the controller issues the asynchronous message configuration carrying the message type, the identifier of the controller and the sharing weight to the network device, and the network device performs sharing and forwarding according to the received asynchronous message configuration, so that sharing and forwarding of the same type of asynchronous message can be achieved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained from the drawings without inventive effort.

Fig. 1 is an interaction diagram of an SDN network provided in an embodiment of the present application;

fig. 2 is a schematic flowchart of an asynchronous message configuration method according to an embodiment of the present application;

fig. 3 is a schematic structural diagram of an asynchronous message setting notification provided in an embodiment of the present application;

fig. 4 is a flowchart illustrating an asynchronous message uploading method according to an embodiment of the present application;

fig. 5 is a second flowchart of an asynchronous message sending method according to an embodiment of the present application;

fig. 6 is a schematic diagram of a correspondence relationship between asynchronous message types and mask fields specified by the Openflow protocol;

fig. 7 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 8 is a functional block diagram of an asynchronous message uploading apparatus according to an embodiment of the present application;

fig. 9 is a second functional block diagram of an asynchronous message uploading apparatus according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a controller provided in an embodiment of the present application;

fig. 11 is a functional block diagram of an asynchronous message configuration apparatus according to an embodiment of the present application.

Icon: 100A, 100B, 100C, 100D-network devices; 110-asynchronous message uploading means; 111-configure the receiving module; 112-sharing the upload module; 113-broadcast upload module; 114-configure upload module; 120-a first machine-readable storage medium; 130-a first processor; 140 — first system bus; 20-a controller cluster; 200A, 200B, 200C-controller; 210-asynchronous message configuration means; 211-configuring an issuing module; 220-a second machine-readable storage medium; 230-a second processor; 240-second system bus; 300-virtual machine.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations.

Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

In the SDN architecture using the Openflow protocol, a network device needs to report various types of messages to a controller, and the messages are called Asynchronous messages (Asynchronous). The asynchronous message may include a Packet-in message for informing the controller of a Packet received by the network device, a Port-Status message for informing the controller of a Port state of the network device, a Flow-Removed message for informing the controller that a Flow table on the network device is deleted, and the like.

In some embodiments, a controller cluster of an SDN architecture generally includes one master controller and a plurality of slave controllers, each of which may respectively establish an Openflow connection with a respective managed network device to control the network device. Different controllers may independently control whether a network device sends a certain type of message to the controller, for example, a controller may inform the network device to send a certain type of asynchronous message to the controller through an asynchronous message setting (OFPT _ SET _ ASYNC) in the Openflow protocol. By the method, the network equipment can upload different types of asynchronous messages to different controllers, and the asynchronous messages based on the message types are shared and uploaded to a certain extent.

However, the different types of asynchronous messages are different in the uploading amount, for example, the uploading amount of a Packet-in message is usually much larger than that of other messages for network device status notification, and the Packet-in message only needs to be processed by one controller in the cluster, which causes the controller processing the asynchronous message to bear great processing pressure. In this case, multiple controllers may be required to cooperatively process the same type of asynchronous message. However, in the above embodiment, each controller can only independently control whether the network device uploads a certain type of message to itself, and the network device cannot separately upload multiple asynchronous messages of the same type to different controllers in a shared uploading manner.

In view of this, the present embodiment provides a scheme for a network device to share and upload an asynchronous message according to an asynchronous message configuration sent by a controller, and the scheme provided in the present embodiment is described in detail below.

Referring to fig. 1, fig. 1 is a network of an SDN architecture provided in this embodiment, and includes a controller cluster 20 composed of a plurality of controllers (e.g.,

controllers

200A, 200B, and 200C shown in fig. 1) and network devices (e.g.,

network devices

100A, 100B, 100C, and 100D shown in fig. 1) capable of communicating with each controller in the controller cluster 20. The network devices may be individually accessible to multiple virtual machines 300. The network devices need to send asynchronous messages generated by themselves to the controller cluster 20 for processing.

In the SDN architecture provided by this embodiment, an Openflow protocol is adopted, the network device shown in fig. 1 may be an Openflow switch, and each network device may establish Openlow connection with each controller respectively to perform interaction of control information. In the Controller cluster 20, a Master Controller (Master Controller) and at least one Slave Controller (Slave Controller) may be included.

Referring to fig. 2, fig. 2 is a flowchart of an asynchronous message configuration method applied to the master controller in the controller cluster 20 shown in fig. 1, and the method including various steps will be described in detail below.

Step S110, acquiring an asynchronous message configuration (asynchronous message configuration) of the network device, where the asynchronous message configuration includes a message type, an identifier of a controller included in at least one controller cluster, and a sharing weight corresponding to the identifier of the controller.

Step S120, sending asynchronous message configuration to the network device, so that the network device sends, according to the asynchronous message configuration, the asynchronous message corresponding to the message type in the network device to the corresponding controller included in the asynchronous message configuration according to the sharing weight corresponding to the identifier of each controller.

Optionally, in an implementation manner of this embodiment, an administrator may SET asynchronous message configurations for each network device on one main controller, and the main controller generates an asynchronous message setting notification (OFPT _ SET _ ASYNC) message according to the asynchronous message configurations and sends the message to the network devices.

In another implementation of this embodiment, the master controller may automatically generate an asynchronous message configuration according to the current network condition or the operation condition of the network device, and send the asynchronous message configuration to the network device.

In this embodiment, in order to inform the network device of the necessary information about sharing upload, the asynchronous message configuration may include a message type, an identifier of a controller included in at least one controller cluster, and a sharing weight corresponding to the identifier of each controller.

The message type is used for indicating the type of the asynchronous message which needs to be shared and uploaded by the network equipment; the identity of the controller is used to indicate the controller that needs to receive this type of asynchronous message. For example, the identification of the controller may be the ID of the controller in the controller cluster 20; the sharing weight is used to indicate a sharing proportion when the asynchronous message is shared to the controller.

Referring to fig. 3, fig. 3 shows an exemplary structure of an asynchronous message setup notification carrying asynchronous message configuration information, wherein an OFP _ ASYNC _ CONFIG _ PROP _ threads attribute is used to record various characteristics related to asynchronous message uploading.

As shown in fig. 3, in this embodiment, the message type in the asynchronous message configuration may be recorded in a message type, i.e., a type field, in the OFP _ ASYNC _ CONFIG _ PROP _ REASONS attribute, the identifier of the controller may be sequentially recorded in an identifier field, i.e., a controller _ id field, of the controller, and the sharing weight corresponding to the identifier of each controller may be recorded in a controller weight field, i.e., a controller _ weight field, where the identifier of the controller in the controller _ id field and the sharing weight in the controller _ weight field are in one-to-one correspondence in the sequence order.

Optionally, in an implementation manner of this embodiment, the master controller may issue the same asynchronous message configuration for different network devices.

In another implementation manner of this embodiment, in step S110, the main controller may obtain different asynchronous message configurations corresponding to different network devices, and in step S120, send the asynchronous message configurations corresponding to the network devices, respectively. Wherein the identification or sharing weight of the controller in different asynchronous messages is different

Based on the above design, in the scheme provided in this embodiment, the controller issues the asynchronous message configuration carrying the message type, the identifier of the controller, and the sharing weight to the network device, and the network device performs sharing and uploading according to the received asynchronous message configuration, so that sharing and uploading of the same type of asynchronous message can be achieved.

Optionally, in this embodiment, the master controller may detect an operating state of the slave controllers in the controller cluster 20, and when a failure of a slave controller is detected, issue a new asynchronous message configuration for the network device that sends an asynchronous message to the failed slave controller, so that the network device that receives the new asynchronous message configuration sends the asynchronous message to the controller that normally operates according to the new asynchronous message configuration. Thus, the master controller can adjust the asynchronous message uploading configuration of the corresponding network device in time when the states of other members of the controller cluster 20 change, so that the asynchronous message uploaded by the network device can be processed by the normally operating controller.

Optionally, in this embodiment, the master controller may generate a new configuration message by using different side policies in different specific scenarios, for example, the master controller may obtain load conditions of the slave controllers (for example, obtain the number of network devices that send asynchronous messages to the slave controllers), and generate a new asynchronous message configuration according to the load conditions of the slave controllers when issuing a new asynchronous message configuration to the network devices, so that the network devices send asynchronous messages to the controllers that have lighter loads and are working normally.

Alternatively, different controllers may be required to receive processing for different asynchronous messages, e.g., for Packet-in messages, only one controller may be required to be sent by a network device for processing; whereas for Port Status Port-Status messages, each controller in the controller cluster 20 may need to be notified by the network device.

Therefore, optionally, in this embodiment, the asynchronous message configuration issued by the master controller may further include a message uploading mode corresponding to the message type, and the message uploading mode may include unicast uploading or broadcast uploading.

The main controller sends asynchronous message configuration carrying a message uploading mode to the network equipment, so that the message type of the received asynchronous message configuration is unicast uploading network equipment, and according to the asynchronous message configuration, the asynchronous messages corresponding to the message types in the network equipment are respectively unicast uploaded to corresponding controllers included in the asynchronous message configuration according to the sharing weight corresponding to the identifier of each controller; or the message type configured by the received asynchronous message is the network equipment which is transmitted by the broadcast, and the asynchronous message corresponding to the message type in the network equipment is broadcasted in the controller cluster according to the asynchronous message configuration.

In one implementation of this embodiment, the network device may broadcast a message type corresponding to the asynchronous message broadcast for upload to each controller in the controller cluster 20.

In another implementation of this embodiment, the network device may also broadcast (or multicast) the message type corresponding to the asynchronous message delivered by the broadcast to a plurality of controllers corresponding to the identifiers of the controllers recorded in the asynchronous message configuration.

Referring to fig. 4, fig. 4 is a flowchart illustrating an asynchronous message uploading method applied to the network device shown in fig. 1, and the method including various steps will be described in detail below.

Step S210, obtaining an asynchronous message configuration from the controller cluster 20, where the asynchronous message configuration includes a message type, an identifier of at least one controller, and a sharing weight corresponding to the identifier of each controller.

Step S220, according to the asynchronous message configuration, the asynchronous message corresponding to the message type in the network device is respectively uploaded to the corresponding controller included in the asynchronous message configuration according to the sharing weight corresponding to each controller identifier.

In this embodiment, when the network device executes the sending of the asynchronous message, the asynchronous message of the same message type may be sent to the corresponding controller according to the sharing weight according to the configuration of the asynchronous message received in step S210.

For example, for a Packet-in message, the network device may buffer multiple Packet-in messages that need to be uploaded in the network device, and periodically upload the buffered Packet-in messages. In this embodiment, each time Packet-in message uploading is executed, the Packet-in messages in the cache may be sent to different controllers in the cluster according to the corresponding proportion for processing according to the sharing weight.

Alternatively, in step S220, the network device may respectively calculate a ratio of the sharing weight corresponding to the identifier of each controller in the asynchronous message configuration to the sum of the sharing weights of the controllers in the controller cluster 20 as the sharing proportion corresponding to the identifier of the controller. For example, if the sharing weight corresponding to the controller 200A is 2 and the sharing weight corresponding to the controller 200B is 1, the sharing ratio corresponding to the controller 200A is 2/3 and the sharing ratio corresponding to the controller 200B is 1/3. Then, the asynchronous message corresponding to the message type in the network device is shared and sent to the corresponding controller in the controller cluster 20 according to the sharing proportion corresponding to the identifier of each controller.

In this embodiment, if the asynchronous message configuration further includes a message uploading method, please refer to fig. 5, the asynchronous message uploading method may further include step S220 and step S230.

In step S220, for the asynchronous messages whose message types correspond to unicast uploading, the network device uploads the asynchronous messages of the message types to corresponding controllers in the controller cluster 20 according to the sharing weights indicated in the configuration of the asynchronous messages.

In step S230, the network device broadcasts an asynchronous message of the message type in the controller cluster 20, for which the message type corresponds to an asynchronous message of the broadcast upload.

Optionally, in this embodiment, the slave controller may send a configuration obtaining REQUEST message (OFPT _ GET _ ASYNC _ REQUEST) to the network device. When receiving a configuration acquisition request sent by any slave controller, the network device sends asynchronous message configuration of the network device to the slave controller through an asynchronous message acquisition response message (OFPT _ GET _ ASYNC _ REPLY).

Referring to fig. 3 again, in this embodiment, the asynchronous message acquisition response message (OFPT _ GET _ ASYNC _ REPLY) may have the same or similar structure as the asynchronous message setting notification (OFPT _ SET _ ASYNC), so that the slave controller may acquire complete information related to the network device and the asynchronous message upload through the asynchronous message acquisition response.

In this way, the slave controller can also acquire the asynchronous message configuration of each network device, so that when the master controller fails, the slave controller can continue to manage the uploading of the asynchronous messages of the network devices according to the acquired asynchronous message configuration. In addition, the slave controller can also judge whether the asynchronous message sent by the network equipment is normal according to the asynchronous message configuration of the network equipment.

In order to facilitate the skilled person to understand the solution provided by the present embodiment, the solution provided by the present embodiment is explained by an example.

Referring again to fig. 1, in the network of the SDN architecture shown in fig. 1, a controller cluster 20 includes

controllers

200A, 200B, and 200C, where the controller 200A is a master controller and the

controllers

200B and 200C are slave controllers.

The network devices (including the

network devices

100A, 100B, 100C, and 100D) are Openflow switches, the multiple user virtual machines 300 are respectively connected to the network devices, and each controller in the controller cluster 20 establishes Openflow connection with the

network devices

100A, 100B, 100C, and 100D, respectively.

The network devices may generate a large number of messages at intervals to be sent to the controller cluster 20, such as Packet-in messages. In order to reduce the impact of Packet-in messages on a single controller, it is required that Packet-in messages of network device 100A are reported to controller 200A and controller 200B, Packet-in messages of network device 100B are reported to controller 200B and controller 200C, and Packet-in messages of network device 100C and network device 100D are reported to controller 200A and controller 200C.

The administrator SETs an asynchronous message configuration for each network device on the controller 200A as a main controller, and the controller 200A issues an asynchronous message setting notification (OFPT _ SET _ ASYNC) message carrying the corresponding asynchronous message configuration to the

network devices

100A, 100B, 100C, and 100D, respectively.

Referring to fig. 3 again, the structure of the asynchronous message setting notification (OFPT _ SET _ ASYNC) message may be as shown in fig. 3, where an OFP _ ASYNC _ CONFIG _ PROP _ REASONS attribute structure is defined in the asynchronous message setting notification message and is used for recording related parameters of the asynchronous message configuration. The main fields related to the asynchronous message configuration in the OFP _ ASYNC _ CONFIG _ PROP _ details attribute structure include a message type (type), a mask (mask), a message uploading method (method), an identifier of a controller (controller _ id), and a sharing weight (controller _ weight) field, where:

the message type (type) is used to indicate for which type of asynchronous message the parameters in the OFP _ ASYNC _ CONFIG _ PROP _ REASONS attribute structure are configured. Referring to fig. 6, fig. 6 is a diagram illustrating a correspondence relationship between a value of a message type (type) field defined in the Openflow protocol and an asynchronous message type. For example, if the value of the type field IN the OFP _ ASYNC _ CONFIG _ PROP _ REASONS attribute structure is 0, the corresponding asynchronous message type is "ofpackjtjn _ SLAV", which indicates that the parameter recorded IN the OFP _ ASYNC _ CONFIG _ PROP _ REASONS attribute structure is used to specify how a PACKET-IN message is to be sent to the slave controller. If the value of the message type (type) field is 1, the corresponding asynchronous message type is an "OFPACPT _ PACKET _ IN _ MASTER" type, which indicates that the parameter recorded IN the OFP _ ASYNC _ CONFIG _ PROP _ REASONS attribute structure is used for specifying how a PACKET-IN message is sent to the main controller.

A mask field is used to indicate whether to upload an asynchronous message of the type indicated by the message type (type) field. The Openflow protocol provides that each type of asynchronous message shown in fig. 6 may correspond to one bit (i.e., one of bits 0 to 31) of a mask (mask) having a total length of 32 bits. For example, the "OFPACPT _ PACKET _ IN _ SLAV" type corresponds to the 0 th bit of the mask (mask), and the "OFPACPT _ PACKET _ IN _ MASTER" type corresponds to the 1 st bit of the mask (mask). When the position 1 corresponding to the message type (type) field in the mask (mask) indicates that the asynchronous message of the type indicated by the message type (type) field needs to be uploaded; at position 0 in the mask (mask) corresponding to the message type (type) field, the asynchronous message indicating the type indicated by the message type (type) field does not need to be uploaded. For example, when the message type (type) field is 0 and the mask (mask) is at position 0, position 1, an asynchronous message indicating the "OFPACPT _ PACKET _ IN _ SLAV" type needs to be uploaded; when the message type (type) field is 0 and the 0 th position is masked (mask) is 0, the asynchronous message indicating the "OFPACPT _ PACKET _ IN _ SLAV" type does not need to be uploaded.

The message upload mode (method) field is a field added in this embodiment and is used to indicate that the asynchronous message is uploaded by broadcast or unicast.

The identifier (controller _ ID) field of the controller is an added field in this embodiment, and is used to record the ID of one or more controllers in the controller cluster to indicate that an asynchronous message is sent to these controllers.

The sharing weight (controller _ weight) field is a field added in this embodiment, and a value in the sharing weight (controller _ weight) field corresponds to an identifier of each controller in the identifier (controller _ id) field of the controller one to one, and is used to indicate the sharing weight corresponding to each controller.

Specifically, in the above example, for the network device 100A, Packet-in messages need to be reported to the master controller 200A and the slave controller 200B, since it is specified in the Openflow protocol that one OFP _ ASYNC _ CONFIG _ PROP _ REASONS attribute structure can only record parameters of one type of asynchronous message, the asynchronous message setting notification message received by the network device 100A may include two attributes of the OFP _ ASYNC _ CONFIG _ PROP _ REASONS structure, or when the asynchronous message notification message is issued to the network device 100A, two asynchronous message setting messages are issued, one asynchronous message setting message is used to instruct the network device 100A to send an asynchronous message to the master controller, and the other asynchronous message setting message is used to instruct the network device 100A to send an asynchronous message to the slave controller.

One corresponding to the "OFPACPT _ PACKET _ IN _ MASTER" type and the other corresponding to the "OFPACPT _ PACKET _ IN _ SLAVE" type.

IN the attribute corresponding to "OFPACPT _ PACKET _ IN _ MASTER" type OFP _ ASYNC _ CONFIG _ PROP _ threads, the message type (type) field value is 1, and the mask field (mask) value is 0x2 (i.e., position 1) indicating that the network device 100A needs to send a PACKET-IN type asynchronous message to the MASTER controller. The value of the controller identification (controller _ ID) field is the ID of the controller 200A; the value of the message upload mode (method) field corresponds to unicast upload according to the sharing weight; the value of the sharing weight (controller _ weight) field is set to indicate that the sharing weight for uploading the asynchronous message to the main controller 200A is 2.

IN the attribute corresponding to "OFPACPT _ PACKET _ IN _ SLAVE" type OFP _ ASYNC _ CONFIG _ PROP _ threads, the message type (type) field value is 0, and the mask (mask) field value is 0x1 (i.e., 0 th position 1), which indicates that the network device 100A needs to send a PACKET-IN type asynchronous message to the SLAVE; the value of the controller identification (controller _ ID) field is the ID of the controller 200B; the value of the message upload mode (method) field corresponds to unicast upload according to the sharing weight; the value of the sharing weight (controller _ weight) field is 1 to indicate that the sharing weight for uploading the asynchronous message to the controller 200B is 1.

According to the asynchronous message configuration described above, the Packet-in message of network device 100A has a ratio of 2/3 for upstream controller 200A and a ratio of 1/3 for upstream controller 200B.

For network device 100B, Packet-in messages need to be posted to controller 200A and controller 200C. Therefore, the asynchronous message setting notification message received by the network device 100B also includes two attributes of the OFP _ ASYNC _ CONFIG _ PROP _ response structure.

The OFP _ ASYNC _ CONFIG _ PROP _ REASONS attribute corresponding to the "OFPACPT _ PACKET _ IN _ MASTER" type is similar to that received by network device 100A.

IN contrast, IN the attribute corresponding to "OFPACPT _ PACKET _ IN _ SLAVE" type OFP _ ASYNC _ CONFIG _ PROP _ threads, the value of the message type (type) field is 0, and the value of the mask (mask) field is 0x1, which indicates that the network device 100B needs to send a PACKET-IN type asynchronous message to the SLAVE controller; the value of the controller identification (controller _ ID) field is the ID of the controller 200C; the value of the message upload mode (method) field corresponds to unicast upload according to the sharing weight; the value of the sharing weight (controller _ weight) field is 1 to indicate that the sharing weight of the asynchronous message on the upper controller 200C is 1.

According to the asynchronous message configuration described above, the Packet-in message of network device 100B has a ratio of 2/3 for the upstream controller 200A and a ratio of 1/3 for the upstream controller 200C.

For the

network devices

100C and 100D, the Packet-in message needs to be reported to the controller 200B and the controller 200C, so that the asynchronous message setting notification received by the

network devices

100C and 100D includes an OFP _ ASYNC _ CONFIG _ PROP _ REASONS attribute. Wherein, the value of the message type (type) field is 0, and the value of the mask field is 0x1, which indicates that the

network devices

100C and 100D need to send Packet-in type asynchronous messages to the slave controllers; the value of the controller identification (controller _ ID) field is the ID of the

controllers

200B and 200C; the value of the message upload mode (method) field corresponds to unicast upload according to the sharing weight; the sharing weight (controller _ weight) field has a value of (1, 1) indicating that the sharing weight for uploading the asynchronous message to the controller 200B is 1 and the sharing weight for uploading the asynchronous message to the controller 200C is 1.

According to the asynchronous message configuration described above, the Packet-in messages of

network devices

100C and 100D have a ratio of 1/2 for the

upstream controller

200B and 1/2 for the upstream controller 200C.

After the above setting, controller 200A receives Packet-in messages of 2/3 on network device 100A and network device 100B, controller 200B receives Packet-in messages of 1/3 on network device 100A and network device 100B and Packet-in messages of 1/2 on network device 100C and network device 100D, and controller 200C receives Packet-in messages of 1/2 on network device 100C and network device 100D.

When a member in the controller cluster 20 changes, for example, the controller 200C goes offline, the controller 200A serving as the master controller timely responds to the offline event, and issues a new asynchronous message setting notification to the network device 100C and the network device 100D to notify that the network device 100C and the network device 100D adjust to send a Packet-in message of 1/2 to the controller 200A and send a Packet-in message of 1/2 to the controller 200B.

The

controller

200B or 200C as the slave controller may further send a configuration acquisition REQUEST message (OFPT _ GET _ ASYNC _ REQUEST) to each network device 100, and after receiving the configuration acquisition REQUEST, the network device 100 generates an asynchronous message acquisition response message (OFPT _ GET _ ASYNC _ REPLY) according to its own asynchronous message configuration and sends the asynchronous message acquisition response message (OFPT _ GET _ ASYNC _ REPLY) to the

controller

200B or 200C. The

controller

200B or 200C may detect whether the upload of each network device 100 is correct according to the asynchronous message configuration of each network device 100, and back up the asynchronous message configuration to cope with the burst failure of the controller 200A.

Referring to fig. 7, fig. 7 is a schematic diagram of a hardware structure of a network device 100 according to the present embodiment. The network device 100 may include a first processor 130 and a first machine-readable storage medium 120. The first processor 130 and the first machine-readable storage medium 120 may communicate via a first system bus 140. Also, the first machine-readable storage medium 120 stores machine-executable instructions, and the first processor 130 may perform the above-described asynchronous message uploading method by reading and executing the machine-executable instructions of the first machine-readable storage medium 120 corresponding to the asynchronous message uploading logic.

First machine-readable storage medium 120 referred to herein may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like. For example, the machine-readable storage medium may be: a RAM (random Access Memory), a volatile Memory, a non-volatile Memory, a flash Memory, a storage drive (e.g., a hard drive), a solid state drive, any type of storage disk (e.g., an optical disk, a dvd, etc.), or similar storage medium, or a combination thereof.

Referring to fig. 8, the present embodiment further provides an asynchronous message uploading device 110, where the asynchronous message uploading device 110 includes at least one functional module that can be stored in the first machine-readable storage medium 120 in a software form. Functionally partitioned, the asynchronous message uploading device 110 may include a configuration receiving module 111 and a sharing uploading module 112.

The configuration receiving module 111 is configured to receive an asynchronous message configuration issued by the controller cluster 20, where the asynchronous message configuration includes a message type, an identifier of a controller included in at least one controller cluster, and a sharing weight corresponding to the identifier of the controller.

In this embodiment, the configuration receiving module 111 may be configured to execute step S110 shown in fig. 2, and reference may be made to the description of step S110 for a detailed description of the configuration receiving module 111.

A sharing and sending module 112, configured to send asynchronous messages corresponding to the message types in the network device to corresponding controllers in the controller cluster 20 according to the sharing weights corresponding to the identifiers of the controllers, respectively, according to the configuration of the asynchronous messages.

In this embodiment, the shared uploading module 112 may be configured to perform step S120 shown in fig. 2, and reference may be made to the description of step S120 for a detailed description of the shared uploading module 112.

Optionally, in this embodiment, the asynchronous message configuration further includes a message uploading mode corresponding to the message type, where the message uploading mode includes unicast uploading or broadcast uploading.

The sharing upload module 112 is specifically configured to, when the message upload mode is unicast upload, upload the asynchronous messages corresponding to the message types in the network devices to corresponding controllers in the controller cluster 20 according to the sharing weights, respectively.

Referring to fig. 9, the asynchronous message uploading device 110 further includes a broadcast uploading module 113.

The broadcast upload module 113 is configured to broadcast an asynchronous message of a message type in the controller cluster 20, for the message type corresponding to the asynchronous message of the broadcast upload.

In this embodiment, the request receiving module may be configured to execute step S130 shown in fig. 4, and reference may be made to the description of step S130 for a detailed description of the request receiving module.

Optionally, in this embodiment, the sharing and sending-up module 112 respectively calculates a ratio of the sharing weight corresponding to the identifier of each controller in the asynchronous message configuration to the sum of the sharing weights of the controllers in the controller cluster 20 as a sharing proportion corresponding to the identifier of the controller, and sends the asynchronous message corresponding to the message type in the network device to the corresponding controller in the controller cluster 20 in a sharing manner according to the sharing proportion corresponding to the identifier of each controller.

Optionally, in this embodiment, the controller cluster 20 includes a master controller and a slave controller, and the configuration receiving module 111 is configured to obtain the asynchronous message configuration from the master controller.

Referring again to fig. 9, the asynchronous message uploading device 110 may further include a configuration uploading module 114.

The configuration upload module 114 is configured to send the asynchronous message configuration of the network device to any slave controller when receiving a configuration acquisition request sent by the slave controller.

Referring to fig. 10, fig. 10 is a schematic diagram of a hardware structure of a controller according to the present embodiment. The controller may include a second processor 230 and a second machine-readable storage medium 220. The second processor 230 and the second machine-readable storage medium 220 may communicate via a second system bus 240. Also, the second machine-readable storage medium 220 stores machine-executable instructions, and the second processor 230 may perform the above-described asynchronous message uploading method by reading and executing the machine-executable instructions corresponding to the asynchronous message uploading logic in the second machine-readable storage medium 220.

The second machine-readable storage medium 220 referred to herein may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and the like. For example, the machine-readable storage medium may be: a RAM (random Access Memory), a volatile Memory, a non-volatile Memory, a flash Memory, a storage drive (e.g., a hard drive), a solid state drive, any type of storage disk (e.g., an optical disk, a dvd, etc.), or similar storage medium, or a combination thereof.

Referring to fig. 11, the present embodiment further provides an asynchronous message configuration apparatus 210, where the asynchronous message configuration apparatus 210 includes at least one functional module that can be stored in a software form in a second machine-readable storage medium 220. Functionally divided, the asynchronous message configuration means 210 may comprise a configuration issuing module 211.

The configuration issuing module 211 is configured to send asynchronous message configuration to the network device, where the asynchronous message configuration includes a message type, an identifier of at least one controller, and a sharing weight corresponding to the identifier of each controller, so that the network device sends, according to the asynchronous message configuration, asynchronous messages corresponding to the message type in the network device to corresponding controllers in the controller cluster 20 according to the sharing weight corresponding to the identifier of each controller.

To sum up, in the asynchronous message configuration method, the forwarding method, the controller and the network device provided in this embodiment of the present application, the controller issues the asynchronous message configuration carrying the message type, the identifier of the controller and the sharing weight to the network device, and the network device performs sharing forwarding according to the received asynchronous message configuration, so that sharing forwarding of the same type of asynchronous message can be achieved.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The apparatus embodiments described above are merely illustrative, and for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition, functional modules in the embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

The above description is only for various embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope of the present application, and all such changes or substitutions are included in the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. An asynchronous message configuration method is characterized by being applied to a main controller in an SDN architecture controller cluster; the method comprises the following steps:

2. The method of claim 1, wherein the step of obtaining the asynchronous message configuration of the network device comprises:

3. The method of claim 1, further comprising:

detecting the working state of a slave controller in the controller cluster;

and when the slave controller is detected to have a fault, issuing new asynchronous message configuration aiming at the network equipment which sends asynchronous messages to the faulty slave controller, so that the network equipment which receives the new asynchronous message configuration sends asynchronous messages to a controller which normally works according to the new asynchronous message configuration.

4. The method of any of claims 1-3, wherein the asynchronous message configuration further comprises a message upload mode corresponding to the message type, the message upload mode comprising unicast upload or broadcast upload;

sending asynchronous message configuration carrying the message uploading mode to network equipment, enabling the message uploading mode of the received asynchronous message configuration to be unicast uploading network equipment, and according to the asynchronous message configuration, respectively unicast uploading asynchronous messages corresponding to the message types in the network equipment to corresponding controllers included in the asynchronous message configuration according to the sharing weight corresponding to the identifier of each controller; or enabling the message uploading mode of the received asynchronous message configuration to be the network equipment for broadcasting uploading, and broadcasting the asynchronous message corresponding to the message type in the network equipment in the controller cluster according to the asynchronous message configuration.

5. An asynchronous message uploading method applied to a network device adopted in an SDN architecture, the method comprising:

and according to the asynchronous message configuration, respectively uploading the asynchronous messages corresponding to the message types in the network equipment to corresponding controllers included in the asynchronous message configuration according to the sharing weight corresponding to each controller identifier.

6. The method of claim 5, wherein the asynchronous message configuration further comprises a message uploading mode corresponding to the message type, and wherein the message uploading mode comprises unicast uploading or broadcast uploading;

for the asynchronous messages of which the message types correspond to unicast uploading, according to the asynchronous message configuration, respectively unicast and upload the asynchronous messages corresponding to the message types in the network equipment to corresponding controllers included in the asynchronous message configuration according to the sharing weight corresponding to the identifier of each controller;

the method further comprises the following steps:

7. The method according to claim 5, wherein the step of respectively uploading the asynchronous messages corresponding to the message types in the network device to corresponding controllers in the controller cluster according to the sharing weights corresponding to the identifiers of each controller comprises:

8. The method according to any one of claims 5 to 7, wherein the controller cluster includes a master controller and a slave controller, and the step of receiving the asynchronous message configuration sent by the controller cluster includes:

obtaining the asynchronous message configuration from the master controller;

the method further comprises the following steps:

9. A controller comprising a machine-readable storage medium and a processor, the machine-readable storage medium having stored thereon machine-executable instructions that, when invoked or executed by the processor, cause the controller to implement the method of any of claims 1-4.

10. A network device comprising a machine-readable storage medium and a processor, the machine-readable storage medium having stored thereon machine-executable instructions that, when invoked or executed by the processor, cause the network device to implement the method of any of claims 5-8.