CN103677760B - A kind of event concurrency controller based on Openflow and event concurrency disposal route thereof - Google Patents

Abstract

The invention discloses an Openflow-based event parallel controller and an event parallel processing method thereof. The method separates the sending and receiving of Openflow messages from the processing of Openflow events, and uses extra computing threads to accelerate the processing of Openflow events. After the application is started, the controller will establish a link with the switch, and evenly distribute the link to multiple I/O threads, and the sending and receiving of messages on each link will be handled by a unique I/O thread. After the application receives the Openflow message, it triggers the corresponding Openflow event, and generates the processing tasks of the flow object and the state object according to the type of the event, which are handed over to different threads for processing. During stream event processing, subtasks can be dynamically generated and executed in parallel by multiple threads. For shared state, use a unique state thread for processing. Compared with the existing Openflow event parallel processing method, the method of the present invention has better performance scalability and simpler data access mode.

Description

An Openflow-based event parallel controller and its event parallel processing method

technical field

The invention relates to an Openflow controller, which refers to a software-defined Openflow controller in the network field and a parallel processing method for internal events of the Openflow controller, in particular to a parallel processing method inside the Openflow flow event processing process.

Background technique

In 2008, OpenFlow technology was first proposed. The idea is to separate the two functional modules of data forwarding and routing control in traditional network equipment, and use a centralized controller to manage and configure various network equipment through standardized interfaces. OpenFlow technology has attracted widespread attention in the industry and has become a very popular technology in recent years. Since the Openflow technology brings flexible programmability to the network, it has been widely used in various networks such as campus networks, wide area networks, mobile networks, and data center networks.

In the "OpenFlowSwitchSpecification" published on December 31, 2009, the OpenNetworking Foundation organization, Section 4.1 of this document introduces the types of OpenFlow messages. Openflow messages include controller-to-switch (translation: the message transmitted by the controller to the switch), Asynchronous (translation: asynchronous message) and Symmetric (translation: symmetric message). The asynchronous messages include Packet-in (translation: flow arrival message), Flow-Removed (translation: flow removal message), Port-status (translation: port status message) and Error (translation: error message).

On March 29, 2013, "SDN technology based on OpenFlow" was published in the Journal of Software, published by Zuo Qingyun et al. It is disclosed in the paper that an OpenFlow network is mainly composed of two parts: an OpenFlow switch and a controller. The OpenFlow switch forwards data packets according to the flow table, which represents the data forwarding plane; the controller realizes the management and control function through the whole network view, and its control logic represents the control plane. The processing unit of each OpenFlow switch is composed of flow tables, and each flow table is composed of many flow entries, and the flow entries represent forwarding rules. The data packet entering the switch obtains the corresponding operation by querying the flow table. The controller maintains the basic information of the entire network by maintaining a network view (networkview), such as topology, network elements, and provided services. The application program running on the controller manages and controls the entire network by calling the global data in the network view and then operating the OpenFlow switch.

The characteristics of the Openflow technology make the processing efficiency of the Openflow controller the key to the normal operation of the network. The processing efficiency of the original single-threaded controller is far from meeting the processing requirements of large-scale Openflow networks. Therefore, the prior art utilizes multithreading to process Openflow events in parallel within the controller to improve the processing efficiency of the controller.

However, the existing Openflow event parallel processing method has scalability problems in processing performance when using the many-core environment to control a large-scale Openflow network with complex behavior: (1) The flow event processing process does not support parallel operations, It cannot satisfy the calculation process with high time complexity; (2) It is difficult to effectively improve the processing efficiency of stream events by adding threads; (3) During the Openflow event processing process, there is coupling in access to shared data, which affects performance scalability.

Aiming at the above problems, the present invention proposes a new event parallel controller and its event parallel processing method for Openflow events, especially Openflow flow events, within the Openflow controller.

Contents of the invention

One of the purposes of the present invention is to provide a parallel event controller based on Openflow. The controller utilizes a many-core environment, and in a large-scale Openflow network scenario, uses I/O threads to send and receive Openflow messages in parallel. The thread accelerates the processing of Openflow events, increases the internal parallel support of the flow event processing process, enhances the computing power of the Openflow controller, and improves performance scalability.

The second object of the present invention is to propose a parallel event processing method based on Openflow, which uses a plurality of threads to send and receive Openflow messages in parallel; after receiving the Openflow message, trigger the corresponding Openflow event; The corresponding processing method generates a processing task for the stream event, which is executed in parallel by the stream-thread; for other types of events and their corresponding processing methods, generates a processing task for the shared state, which is executed in parallel by the state-thread; Within the processing process, subtasks can be dynamically generated, and through task stealing, multiple threads can process the same stream event in parallel.

The present invention is an event parallel controller based on Openflow, which includes a flow processing module (1), a state processing module (2) and an Openflow message distribution control module (3);

The Openflow message distribution control module (3) first adopts the asynchronous non-blocking IO model to receive the Openflow message sent by the Openflow switch (4) from the receiving buffer of the link; the Openflow message includes Packet-in message, Flow-Removed message, Port-status message and Error message.

Openflow message distribution control module (3) The second aspect will be the flow processing task ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ Sent to the main thread local task queue Q _z of the stream processing module (1);

The stream processing task ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ The acquisition is: (A) first trigger the Packet-in event according to the Packet-in message; then generate the flow object FLOW Base_flow of the Base_flow structure according to the Packet-in event; _{Base_flow} = {F ₁ , F ₂ ,...,F _f }; The start method in the structure generates the stream processing task corresponding to the Packet-in event (B) First trigger the Flow-Removed event according to the Flow-Removed message; then generate the flow object FLOW Base_flow with the Base_flow structure in Table 1 according to the Flow-Removed event; _{Base_flow} = {F ₁ , F ₂ ,...,F _f }; The start method in the structure generates the flow processing task corresponding to the Flow-Removed event ${\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}.$

Openflow message distribution control module (3) The third aspect will be the state processing task ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{\mathrm{port}-\mathrm{status}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}},{\mathrm{SA}}_{\mathrm{error}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}\}$ Sent to the access task queue of the state processing module (2) $P_{\mathrm{state}}^{\mathrm{STAT}{\mathrm{E.}}_{\mathrm{Base}\_\mathrm{state}}}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\}$ middle;

The state processing task ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{\mathrm{port}-\mathrm{status}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}},{\mathrm{SA}}_{\mathrm{error}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}\}$ The acquisition is: (A) first trigger the Port-status event according to the Port-status message; then generate the processing task of the state object STATE _{Base_state} = {S ₁ , S ₂ ,...,S _s } of the Base_state structure according to the Port-status event, That is, the Port-status status processing task is recorded as (B) First trigger the Error event based on the Error message; then generate the processing task for the state object STATE _{Base_state} = {S ₁ , S ₂ ,..., S _s } of the Base_state structure in Table 2 according to the Error event, that is, the Error state processing task recorded as ${\mathrm{SA}}_{\mathrm{error}}^{\mathrm{STAT}{\mathrm{E.}}_{\mathrm{Base}\_\mathrm{state}}}.$

The fourth aspect of the Openflow message distribution control module (3) receives the controller-to-switch message output by the flow processing module (1);

Openflow message distribution control module (3) The fifth aspect adopts the asynchronous non-blocking IO model from the message-thread TH ₃ = the link in {C ₁ , C ₂ ,...,C _c } output the controller-to-switch message to the Openflow switch (4) in the send buffer of

The first aspect of the stream processing module (1) is used to receive the stream processing tasks output by the Openflow message distribution control module (3) ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\};$

The second aspect of the stream processing module (1) will ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ Save to the main thread local task queue Q _z ;

The third aspect of the stream processing module (1) will ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ Send to the computing thread local task queue by polling middle;

The fourth aspect of stream processing module (1) execution ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ The specific task in; and dynamically generate the processing task of the convection object FLOW _{Base_flow} = {F ₁ , F ₂ ,..., F _f }, which is recorded as the flow object subtask will be described add to $Q^{T{h}_1}=\{Q_1,Q_2,...,Q_a\}$ middle;

Stream processing module (1) fifth aspect execution ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ Specific tasks in ; and dynamically generate processing tasks for state objects STATE _{Base_state} = {S ₁ , S ₂ ,..., S _s }, recorded as state object subtasks according to the The value of the global attribute is judged; if global is true, it means that the state is a global shared state, and the described Give the state processing module (2), and wait for the task completion message STA _2-1 of the state processing module (2); otherwise, if global is not true, it means that the state is a local shared state, and the stream processing module (1) the generation of The thread executes directly;

The sixth aspect of the stream processing module (1) implements task load balancing of computing threads by way of task stealing.

The seventh aspect of the stream processing module (1) outputs the controller-to-switch message to the Openflow message distribution module (3). The calculation thread synchronously writes the controller-to-switch message that needs to be output to the link in the message-thread TH ₃ ={C ₁ ,C ₂ ,…,C _c } in the send buffer.

The status processing module (2) first receives the status processing tasks sent by the Openflow message module (3) ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{\mathrm{port}-\mathrm{status}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}},{\mathrm{SA}}_{\mathrm{error}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}\},$ and will ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{\mathrm{port}-\mathrm{status}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}},{\mathrm{SA}}_{\mathrm{error}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}\}$ Save to the access task queue of the state object STATE _{Base_state} = {S ₁ ,S ₂ ,…,S _s } middle;

The second aspect of the state processing module (2) receives the state processing tasks sent by the stream processing module (1) and will Save to the access task queue of the state object STATE _{Base_state} = {S ₁ ,S ₂ ,…,S _s } middle;

State processing module (2) third aspect state - thread TH ₂ = B 1 in {B ₁ ,B ₂ ,...,B _{b }} from _Extract the access task queue belonging to B1 from $P_{\mathrm{state}}^{B_1}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\};$ Then B ₁ executes by polling $P_{\mathrm{state}}^{B_1}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\}$ tasks in ; when execution completes After that, the task completion message sent to stream processing module 1

State - Thread TH ₂ = B ₂ in {B ₁ ,B ₂ ,...,B _b } starts from _Extract the access task queue belonging to B2 from Then B ₂ executes by polling tasks in ; when execution completes After that, the task completion message sent to the stream processing module (1)

State - Thread TH ₂ = B _b in {B ₁ ,B ₂ ,...,B _b } starts from Extract the access task queue belonging to B _b from Then B _b executes by polling tasks in ; when execution completes After that, the task completion message sent to stream processing module 1

For the task completion message set sent by the fourth aspect of the state processing module (2) to the stream processing module (1), it is denoted as ${\mathrm{STA}}_{2-1}=\{{\mathrm{STA}}_{2-1}^{B_1},{\mathrm{STA}}_{2-1}^{B_2},...,{\mathrm{STA}}_{2-1}^{B_b}\}.$

The present invention is aimed at the advantage of the event parallel processing method of Openflow controller:

1. The present invention separates event processing from message sending and receiving inside the Openflow controller, and parallelizes Openflow events by using computing threads, adding parallel support inside the flow event processing process, which can effectively enhance the computing power of the Openflow controller, Improve scalability of controller processing performance.

② The present invention uses the state-thread to uniquely process the shared state, and can access the shared data in a non-mutually exclusive manner, which simplifies the access to the shared data in the event processing process and improves the access efficiency to a certain extent.

Description of drawings

Fig. 1 is a structural block diagram of the Openflow-based event parallel controller of the present invention.

Fig. 2 is a schematic diagram of the parallel processing process inside the Openflow controller of the present invention.

Figure 3 is a comparison of speedup ratios based on the switch program.

Figure 4 is a comparison chart of the speedup ratio based on the QPAS algorithm.

detailed description

The present invention will be further described in detail below in conjunction with the accompanying drawings.

Referring to shown in Fig. 1, a kind of event parallel controller based on Openflow of the present invention, this controller includes stream processing module 1, state processing module 2 and Openflow message distribution control module 3; The device is referred to as POCA. The POCA of the present invention cooperates with the existing Openflow controller and is embedded in the Openflow network architecture.

In the present invention, POCA is for the Packet-in (translation: flow arrival message), Flow-Removed (translation: flow removal message), Port-status (translation: port status message) and Error (translation: port status message) in the Openflow message. error message) for associated processing.

In the present invention, the event corresponding to Packet-in (translation: flow arrival message) is called Packet-in event; the event corresponding to Flow-Removed (translation: flow removal message) is called Flow-Removed event; Port-status ( The event corresponding to the port status message) is called the Port-status event; the event corresponding to the Error (translation: error message) is called the Error event.

In the present invention, in the flow object FLOW _{Base_flow} ={F ₁ , F ₂ ,...,F _f } of the Base_flow structure, F ₁ represents the first type of flow object, F ₂ represents the second type of flow object, and F _f Indicates the last type of flow object, and f is the identification number of the flow object. For the convenience of description, F _f is also referred to as any type of flow object hereinafter.

In the present invention, in the state object STATE _{Base_state} ={S ₁ , S ₂ ,..., S _s } of the Base_state structure, S ₁ represents the state object of the first type, S ₂ represents the state object of the second type, and S _s Indicates the last type of state object, and s represents the identification number of the state object. For the convenience of description, S _s is also referred to as any type of state object below. Any state object will correspond to a unique access task queue, then the access task queue corresponding to the first type of state object S ₁ is recorded as P ₁ (referred to as the first access task queue P ₁ ), and the second type of The access task queue corresponding to state object S ₂ is denoted as P ₂ (referred to as the second access task queue P ₂ ), and the access task queue corresponding to the last type of state object S _s is denoted as P _s (referred to as the last access task queue task queue P _s ). The access task queue adopts the collection expression form as

In the present invention, the thread in stream processing module 1 is recorded as stream-thread TH ₁ ={A ₁ , A ₂ ,...,A _z ,...,A _a } where A ₁ represents the first thread in stream processing module 1 Thread, A ₂ indicates the second thread in stream processing module 1, A _z indicates the zth thread in stream processing module 1, A _a indicates the last thread in stream processing module 1, and a indicates the thread in stream processing module 1 The thread identification number of , for the convenience of description, A _a is also referred to as any thread in the following. When one thread A _z in stream-thread TH ₁ ={A ₁ ,A ₂ ,...,A _z ,...,A _a } is used as the main thread, the rest of the threads are computing threads TH ₁ ={A ₁ ,A ₂ ,...,A _a }. Any thread will correspond to a unique local task queue, then the local task queue corresponding to the first thread A ₁ is recorded as Q ₁ (abbreviated as the first local task queue Q ₁ ), and the local task queue corresponding to the second thread A ₂ The task queue is denoted as Q ₂ (abbreviated as the second local task queue Q ₂ ), and the local task queue corresponding to the zth thread A _z is denoted as Q _z (abbreviated as the zth local task queue Q _z , also known as the main thread local task queue Q _z ), and the local task queue corresponding to the last thread A _a is denoted as Q _a (referred to as the last local task queue Q _a ). The local task queue set corresponding to computing thread TH ₁ ={A ₁ ,A ₂ ,…,A _a } is denoted as $Q^{T{h}_1}=\{Q_1,Q_2,...,Q_a\}.$

In the present invention, the threads in the state processing module 2 are recorded as state-thread TH ₂ = {B ₁ , B ₂ ,..., B _b } where B ₁ represents the first thread in the state processing module 2, and B ₂ represents The second thread in the state processing module 2, B _b represents the last thread in the state processing module 2, b represents the thread identification number in the state processing module 2, for the convenience of description, B _b is also referred to as any thread below . For the state object STATE _{Base_state} = {S ₁ , S ₂ ,..., S _s } in the state processing module 2 is evenly distributed on the state-thread TH ₂ = {B ₁ , B ₂ ,..., B _b }, then Any state-thread B _b will process multiple access task queues, and the access task queues processed by the state-thread B _b are recorded as $P_{\mathrm{state}}^{B_b}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\},$ and $P_{\mathrm{state}}^{B_b}\∈P_{\mathrm{state}}^{\mathrm{STAT}{\mathrm{E.}}_{\mathrm{Base}\_\mathrm{state}}};$ Any access task queue P _s will correspond to only one thread B _b .

In the present invention, the threads in the Openflow message distribution control module 3 are recorded as message-thread TH ₃ = {C ₁ , C ₂ ,..., C _c } where C ₁ represents the first thread in the Openflow message distribution control module 3 , C ₂ represents the second thread in the Openflow message distribution control module 3, C _c represents the last thread in the Openflow message distribution control module 3, and c represents the thread identification number in the Openflow message distribution control module 3, for convenience of description, Hereinafter, C _c is also referred to as any thread.

The link between Openflow message distribution control module 3 and multiple Openflow switches 4 is denoted as SV represents the Openflow controller, SW represents the set of Openflow switches, SW={D ₁ , D ₂ ,...,D _d } where D ₁ represents the first Openflow switch, D ₂ represents the second Openflow switch, and D _d represents the last An Openflow switch, and d represents an identification number of the Openflow switch. For convenience of description, D _d is also referred to as any Openflow switch hereinafter. The first link is recorded as The second link is denoted as The last link is marked as (also known as any link ), ${\mathrm{CON}}_{\mathrm{SW}}^{\mathrm{SV}}=\{{\mathrm{CON}}_{{\mathrm{D.}}_1}^{\mathrm{SV}},{\mathrm{CON}}_{{\mathrm{D.}}_2}^{\mathrm{SV}},...,{\mathrm{CON}}_{{\mathrm{D.}}_d}^{\mathrm{SV}}\}.$ For the link between the Openflow message distribution control module 3 and the Openflow switch 4 is evenly distributed on the message-thread TH ₃ ={C ₁ ,C ₂ ,…,C _c }, and any link There will be only one thread C _c corresponding to it.

(1) Openflow message distribution control module 3

Referring to Fig. 1, the Openflow message distribution control module 3 first adopts the asynchronous non-blocking IO model to receive the Openflow message sent by the Openflow switch 4 from the receiving buffer of the link;

The Openflow message includes a Packet-in message, a Flow-Removed message, a Port-status message and an Error message.

The second aspect of the Openflow message distribution control module 3 will be the flow processing task ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ Sent to the main thread local task queue _Qz of stream processing module 1;

In the present invention, the stream processing task ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ The acquisition is: (A) first trigger the Packet-in event according to the Packet-in message; then generate the flow object FLOW Base_flow with the Base_flow structure in Table 1 according to the Packet-in event _{Base_flow} ={F ₁ ,F ₂ ,…,F _f } ;Finally, generate the flow processing task corresponding to the Packet-in event according to the start method in the Base_flow structure (B) First trigger the Flow-Removed event according to the Flow-Removed message; then generate the flow object FLOW Base_flow with the Base_flow structure in Table 1 according to the Flow-Removed event; _{Base_flow} = {F ₁ , F ₂ ,...,F _f }; The start method in the structure generates the flow processing task corresponding to the Flow-Removed event

In the present invention, in the flow object FLOW _{Base_flow} ={F ₁ , F ₂ ,...,F _f } of the Base_flow structure, F ₁ represents the first type of flow object, F ₂ represents the second type of flow object, and F _f Indicates the last type of flow object, and f is the identification number of the flow object. For the convenience of description, F _f is also referred to as any type of flow object hereinafter.

Table 1Base_flow class

Openflow message distribution control module 3 The third aspect will state processing tasks ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{\mathrm{port}-\mathrm{status}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}},{\mathrm{SA}}_{\mathrm{error}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}\}$ Sent to the access task queue of status processing module 2 $P_{\mathrm{state}}^{\mathrm{STAT}{\mathrm{E.}}_{\mathrm{Base}\_\mathrm{state}}}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\}$ middle;

In the present invention, the state processing task ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{\mathrm{port}-\mathrm{status}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}},{\mathrm{SA}}_{\mathrm{error}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}\}$ The acquisition is: (A) First trigger the Port-status event according to the Port-status message; then generate the state object STATE _{Base_state} ＝{S ₁ ,S ₂ ,…,S _s for the Base_state structure in Table 2 according to the Port-status event }’s processing task, that is, the Port-status status processing task is recorded as (B) First trigger the Error event based on the Error message; then generate the processing task for the state object STATE _{Base_state} = {S ₁ , S ₂ ,..., S _s } of the Base_state structure in Table 2 according to the Error event, that is, the Error state processing task recorded as

Table 2Base_state class

The fourth aspect of the Openflow message distribution control module 3 receives the controller-to-switch message output by the stream processing module 1;

The fifth aspect of the Openflow message distribution control module 3 adopts the asynchronous non-blocking IO model from the link in the message-thread TH ₃ ={C ₁ ,C ₂ ,...,C _c } output the controller-to-switch message to the Openflow switch 4 in the sending buffer of

(2) Stream processing module 1

Referring to Fig. 1, the first aspect of the stream processing module 1 is used to receive the stream processing tasks output by the Openflow message distribution control module 3 ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\};$

The second aspect will ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ Save to the main thread local task queue Q _z ;

The third party will ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ Send to the computing thread local task queue of stream processing module 1 by polling middle;

The fourth aspect of implementation ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ The specific task in; and dynamically generate the processing task of the convection object FLOW _{Base_flow} = {F ₁ , F ₂ ,..., F _f }, which is recorded as the flow object subtask will be described add to $Q^{T{h}_1}=\{Q_1,Q_2,...,Q_a\}$ middle;

Implementation of the fifth aspect ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ Specific tasks in ; and dynamically generate processing tasks for state objects STATE _{Base_state} = {S ₁ , S ₂ ,..., S _s }, recorded as state object subtasks according to the The value of the global attribute (as shown in the fourth row of Table 2) is judged; if the global is true, it means that the state is a global shared state, and the described Give the state processing module 2, and wait for the task of the state processing module 2 to complete the message STA _2-1 ; otherwise, if global is not true, then it means that the state is a local shared state, then the stream processing module 1 produces the described The thread executes directly;

In the sixth aspect, the computing threads in the stream processing module 1 perform load balancing by way of task stealing.

Relevant public information about the "task stealing method":

Article name: Schedulingmultithreadedcomputationsbyworkstealing

Author: Robert D. Blumofe Univ. of Texas at Austin, Austin;

Charles E. Leiserson MIT Lab for Computer Science, Cambridge, MA;

Publication information: Journal of the ACM (JACM) JACM Homepage archive

Volume 46 Issue 5, Sept. 1999, Pages 720-748, ACM New York, NY, USA.

In the present invention, when the stream processing module 1 receives the task completion message output by the status processing module 2 After that, first judge whether there is a computing thread waiting for the message, and if so, make the waiting message ${\mathrm{STA}}_{2-1}=\{{\mathrm{STA}}_{2-1}^{B_1},{\mathrm{STA}}_{2-1}^{B_2},...,{\mathrm{STA}}_{2-1}^{B_b}\}$ execution of the computation thread continues; otherwise, ignore the message.

In the seventh aspect, the flow processing module 1 outputs the controller-to-switch message to the Openflow message distribution module 3 . In the present invention, the calculation thread synchronously writes the controller-to-switch message to be output to the link in the message-thread TH ₃ ={C ₁ ,C ₂ ,...,C _c } in the send buffer.

(3) Status processing module 2

Referring to Fig. 1, the state processing module 2 firstly receives the state processing task sent by the Openflow message module 3 ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{\mathrm{port}-\mathrm{status}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}},{\mathrm{SA}}_{\mathrm{error}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}\},$ and will ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{\mathrm{port}-\mathrm{status}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}},{\mathrm{SA}}_{\mathrm{error}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}\}$ Save to the access task queue of the state object STATE _{Base_state} = {S ₁ ,S ₂ ,…,S _s } middle;

The second aspect of the status processing module 2 is to receive the status processing tasks sent by the stream processing module 1 and will Save to the access task queue of the state object STATE _{Base_state} = {S ₁ ,S ₂ ,…,S _s } middle;

State processing module 2 third aspect state - thread TH ₂ = B 1 in {B ₁ , B ₂ ,..., B _{b }} from _Extract the access task queue belonging to B1 from $P_{\mathrm{state}}^{B_1}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\};$ Then B ₁ executes by polling $P_{\mathrm{state}}^{B_1}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\}$ tasks in ; when execution completes After that, the task completion message sent to stream processing module 1

State - Thread TH ₂ = B ₂ in {B ₁ ,B ₂ ,...,B _b } starts from _Extract the access task queue belonging to B2 from Then B ₂ executes by polling tasks in ; when execution completes After that, the task completion message sent to stream processing module 1

State - Thread TH ₂ = B _b in {B ₁ ,B ₂ ,...,B _b } starts from Extract the access task queue belonging to B _b from Then B _b executes by polling tasks in ; when execution completes After that, the task completion message sent to stream processing module 1

For the task completion message set sent by the state processing module 2 to the stream processing module 1 in the fourth aspect, it is denoted as ${\mathrm{STA}}_{2-1}=\{{\mathrm{STA}}_{2-1}^{B_1},{\mathrm{STA}}_{2-1}^{B_2},...,{\mathrm{STA}}_{2-1}^{B_b}\}.$

Referring to shown in Fig. 2, adopt the event parallel controller based on Openflow that the present invention designs to carry out the parallel processing of Openflow event, it comprises following parallel processing steps:

Step 1: Send and receive Openflow messages in parallel, and trigger corresponding Openflow events

There is a unique link per switch within the Openflow-based event-parallel controller of the present invention.

During the connection establishment process, the first thread C ₁ in the message-thread TH ₃ ={C ₁ ,C ₂ ,…,C _c } is responsible for sending messages to the Openflow switch SW={D ₁ ,D ₂ ,…,D _d } The link request is monitored. When a link request is received, the link is established ${\mathrm{CON}}_{\mathrm{SW}}^{\mathrm{SV}}=\{{\mathrm{CON}}_{{\mathrm{D.}}_1}^{\mathrm{SV}},{\mathrm{CON}}_{{\mathrm{D.}}_2}^{\mathrm{SV}},...,{\mathrm{CON}}_{{\mathrm{D.}}_d}^{\mathrm{SV}}\},$ and will link ${\mathrm{CON}}_{\mathrm{SW}}^{\mathrm{SV}}$ Distribute evenly to message _- thread TH3. any link Processed by only one thread C _c .

In the process of receiving Openflow messages, the message-thread TH ₃ ={C ₁ ,C ₂ ,...,C _c } adopts the asynchronous non-blocking IO model to receive the Openflow switch SW={D ₁ ,D ₂ ,... ,D _d } The Openflow message sent. Trigger the Packet-in event based on the Packet-in message; trigger the Flow-Removed event based on the Flow-Removed message; trigger the Port-status event based on the Port-status message; trigger the Error event based on the Error message.

During the Openflow message sending process, the message-thread TH ₃ ={C ₁ ,C ₂ ,…,C _c } adopts the asynchronous non-blocking IO model from the message-thread TH ₃ ={C ₁ ,C ₂ ,…,C _c } link to belong output the controller-to-switch message to the Openflow switch SW={D ₁ , D ₂ , . . . , D _d } in the sending buffer of . link to The operation of the send buffer needs to be synchronized.

In the present invention, the parallel sending and receiving of Openflow messages utilizes multiple message-threads to send and receive Openflow messages in parallel, each Openflow switch link is processed by a unique message-thread, and there is no mutual exclusion between message-threads. Therefore, the efficiency of Openflow messaging can be maximized. In addition, using the asynchronous non-blocking IO model can reduce the interference between the message sending and receiving process and the message processing process, thereby further improving the efficiency of message sending and receiving.

Step 2: Parallel processing of Openflow events

For the Packet-in event and Flow-Removed event, first generate the flow object FLOW _{Base_flow} ＝{F ₁ ,F ₂ ,…,F _f } as shown in the Base_flow structure in Table 1, and then generate the flow processing task according to the start method in the Base_flow structure ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\},$ Finally the task ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ Sent to the main thread local task queue Q _z in stream processing module 1;

For stream processing tasks ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ In stream processing module 1, the main thread A _z will ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ Send to the computing thread local task queue of stream processing module 1 by polling middle; calculation thread TH ₁ ={A ₁ ,A ₂ ,...,A _a } execute ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Remved}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ Concrete tasks in ; and dynamically generate flow object subtasks will be described add to $Q^{T{h}_1}=\{Q_1,Q_2,...,Q_a\}$ middle;

Calculation thread TH ₁ ={A ₁ ,A ₂ ,...,A _a } executes ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{\mathrm{Packets}-\mathrm{in}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}},{\mathrm{FA}}_{\mathrm{flow}-\mathrm{Removed}}^{{\mathrm{FLOW}}_{\mathrm{Base}\_\mathrm{flow}}}\}$ Specific tasks in ; and dynamically generate state object subtasks according to the The value of the global attribute (as shown in the fourth row of Table 2) is judged; if the global is true, it means that the state is a global shared state, and the described Give the state processing module 2, and wait for the task of the state processing module 2 to complete the message STA _2-1 ; otherwise, if global is not true, then it means that the state is a local shared state, then the stream processing module 1 produces the described The threads in the stream processing module 1 are directly executed; the computing threads in the stream processing module 1 perform load balancing by means of task stealing.

For the Port-status event and the Error event, first generate a processing task for the state object STATE _{Base_state} ={S ₁ , S ₂ ,..., S _s } of the Base_state structure in Table 2 ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{\mathrm{port}-\mathrm{status}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}},{\mathrm{SA}}_{\mathrm{error}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}\},$ then the task ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{\mathrm{port}-\mathrm{status}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}},{\mathrm{SA}}_{\mathrm{error}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}\}$ Sent to the access task queue of status processing module 2 $P_{\mathrm{state}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}=\{P_1{,P}_2,...,P_{\mathrm{the\; s}}\}$ middle.

For the task ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{\mathrm{port}-\mathrm{status}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}},{\mathrm{SA}}_{\mathrm{error}}^{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}\}$ and tasks ${\mathrm{TASK}}_{{\mathrm{STATE}}_{\mathrm{Base}\_\mathrm{state}}}^{\mathrm{sub}},$ In state processing module 2, B 1 in state-thread TH ₂ ={B ₁ ,B ₂ ,...,B _{b }} starts from _Extract the access task queue belonging to B1 from $P_{\mathrm{state}}^{B_1}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\};$ Then B ₁ executes by polling $P_{\mathrm{state}}^{B_1}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\};$ tasks in ; when execution completes After that, the task completion message sent to stream processing module 1 State - Thread TH ₂ = B ₂ in {B ₁ ,B ₂ ,...,B _b } starts from _Extract the access task queue belonging to B2 from Then B ₂ executes by polling tasks in ; when execution completes After that, the task completion message sent to stream processing module 1 State - Thread TH ₂ = B _b in {B ₁ ,B ₂ ,...,B _b } starts from Extract the access task queue belonging to B _b from $P_{\mathrm{state}}^{B_b}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\};$ Then B _b executes by polling $P_{\mathrm{state}}^{B_b}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\}$ tasks in ; when execution completes After that, the task completion message sent to stream processing module 1

In the present invention, after receiving the Openflow message, the corresponding Openflow event is triggered, and the processing tasks of the convection object and the state object are generated according to the type of the event, and are handed over to different threads for parallel processing. In the process of stream event processing, subtasks can be dynamically generated, and processed by multiple computing threads in parallel by using task stealing to improve the efficiency of stream event processing. Each shared state in the controller is processed by a unique state thread, which not only simplifies the access to the shared state, but also improves the processing efficiency of the computing thread for streaming events to a certain extent. Utilizing the event parallel processing method in the present invention can make the Openflow controller have better performance scalability.

Verification example

POCA, an event parallel processing system based on Openflow messages, when executing a switch program with a small amount of calculation, compared with other Openflow controllers, with the increase in the number of threads, when the number of threads is greater than 8, POCA has a higher speedup ratio . The reason is that each IO thread processes the switch link to which it belongs, and there is no interference with each other, thus improving the processing performance. Please refer to the comparison chart of the speedup ratio based on the switch program shown in Figure 3.

See Figure 4 for the comparison of speedup ratios based on the QPAS algorithm. When dealing with the computationally intensive QPAS algorithm, POCA has a higher speedup ratio than NOX as the number of threads increases. The reason is: POCA uses computing threads to perform parallel acceleration within the event processing process, which improves the processing efficiency of each event, thereby improving the overall processing efficiency.

The invention discloses an Openflow-based event parallel controller and an event parallel processing method thereof. The method separates the sending and receiving of Openflow messages from the processing of Openflow events, and uses extra computing threads to accelerate the processing of Openflow events. After the application is started, the controller will establish a link with the switch, and evenly distribute the link to multiple I/O threads, and the sending and receiving of messages on each link will be handled by a unique I/O thread. After the application receives the Openflow message, it triggers the corresponding Openflow event, and generates the processing tasks of the flow object and the state object according to the type of the event, which are handed over to different threads for processing. During stream event processing, subtasks can be dynamically generated and executed in parallel by multiple threads. For shared state, use a unique state thread for processing. Compared with the existing Openflow event parallel processing method, the method of the present invention has better performance scalability and simpler data access mode.

Claims (4)

1. A parallel event controller based on Openflow, characterized in that: the controller includes a flow processing module (1), a state processing module (2) and an Openflow message distribution control module (3); The Openflow message distribution control module (3) firstly adopts the asynchronous non-blocking IO model to receive the Openflow message sent by the Openflow switch (4) from the receiving buffer of the link; the Openflow message includes Packet-in message, Flow-Removed Message, Port-status message and Error message; The Packet-in message refers to the flow arrival message; The Flow-Removed message refers to the flow removal message; The Port-status message refers to a port status message; Error message refers to an error message; Openflow message distribution control module (3) The second aspect is to process the task of flow ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e-flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\}$ Sent to the main thread local task queue Q _z of the stream processing module (1); Indicates the stream processing task corresponding to the Packet-in event; Indicates the flow processing task corresponding to the Flow-Removed event; The stream processing task ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\}$ The acquisition is: (A) first trigger the Packet-in event according to the Packet-in message; then generate the flow object FLOW Base_flow of the Base_flow structure according to the Packet-in event; _{Base_flow} = {F ₁ , F ₂ ,...,F _f }; The start method in the structure generates the stream processing task corresponding to the Packet-in event (B) First trigger the Flow-Removed event according to the Flow-Removed message; then generate the flow object FLOW _{Base_flow} ＝{F ₁ , F ₂ ,...,F _f } according to the Base_flow structure in Table 1 according to the Flow-Removed event; The start method in the structure generates the flow processing task corresponding to the Flow-Removed event The flow object of the Base_flow structure FLOW _{Base_flow} ={F ₁ ,F ₂ ,...,F _f } where F ₁ represents the first type of flow object, F ₂ represents the second type of flow object, and F _f represents the last type The stream object of , f is the identification number of the stream object; Table 1Base_flow class Openflow message distribution control module (3) The third aspect will be the state processing task ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{Port-\mathrm{the\; s}tatu\mathrm{the\; s}}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}},{\mathrm{SA}}_{\mathrm{E.}rror}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}}\}$ Sent to the access task queue of the status processing module (2) $P_{\mathrm{the\; s}tate}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\}$ middle; Indicates the Port-status status processing task; Indicates the Error state processing task; The state processing task ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{Port-\mathrm{the\; s}tatu\stackrel{\‾}{\mathrm{the\; s}}}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}},{\mathrm{SA}}_{\mathrm{E.}rror}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}}\}$ The acquisition is: (A) first trigger the Port-status event according to the Port-status message; then generate the processing task of the state object STATE _{Base_state} ={S ₁ , S ₂ ,..., S _s } of the Base_state structure according to the Port-status event, That is, the Port-status status processing task is recorded as (B) First trigger the Error event according to the Error message; then generate the processing task for the state object STATE _{Base_state} ={S ₁ , S ₂ ,..., S _s } of the Base_state structure as in Table 2 according to the Error event, that is, the Error state processing task recorded as The state object of the Base_state structure STATE _{Base_state} = {S ₁ , S ₂ ,..., S _s } where S ₁ represents the first type of state object, S ₂ represents the second type of state object, and S _s represents the last type The state object of , s represents the identification number of the state object; Table 2Base_state class The fourth aspect of the Openflow message distribution control module (3) receives the controller-to-switch message output by the stream processing module (1); Openflow message distribution control module (3) The fifth aspect adopts the asynchronous non-blocking IO model from the message-thread TH ₃ ={C ₁ ,C ₂ ,...,C _c } to which the link belongs Output the controller-to-switch message to the Openflow switch (4) in the sending buffer; Message-Thread TH ₃ = {C ₁ , C ₂ ,..., C _c } C ₁ represents the first thread in the Openflow message distribution control module (3), and C ₂ represents the first thread in the Openflow message distribution control module (3) Second thread, _C represents the last thread in the Openflow message distribution control module (3), and c represents the thread identification number in the Openflow message distribution control module (3); The first aspect of the stream processing module (1) is used to receive the stream processing tasks output by the Openflow message distribution control module (3) ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\};$ The second aspect of the stream processing module (1) will ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\}$ Save to the main thread local task queue Q _z ; The third aspect of the stream processing module (1) will be ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\}$ Send to the computing thread local task queue by polling middle; The local task queue set corresponding to computing thread TH ₁ ={A ₁ ,A ₂ ,…,A _a } is denoted as Stream-Thread TH ₁ = {A ₁ ,A ₂ ,...,A _z ,...,A _a } where A ₁ represents the first thread in the stream processing module (1), and A ₂ represents the thread in the stream processing module (1). A _z represents the zth thread in the stream processing module (1), A _a represents the last thread in the stream processing module (1), and a represents the thread identification number in the stream processing module (1) ; The local task queue corresponding to the first thread A ₁ is marked as Q ₁ , the local task queue corresponding to the second thread A ₂ is marked as Q ₂ , the local task queue corresponding to the zth thread A _z is marked as Q _z , and finally The local task queue corresponding to a thread A _a is denoted as Q _a ; The fourth aspect of stream processing module (1) execution ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\}$ The specific task in; and dynamically generate the processing task of the convection object FLOW _{Base_flow} = {F ₁ , F ₂ ,..., F _f }, which is recorded as the flow object subtask will be described add to $Q^{{\mathrm{TH}}_1}=\{Q_1,Q_2,...,Q_a\}$ middle; The fifth aspect of stream processing module (1) execution ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\}$ Specific tasks in ; and dynamically generate processing tasks for state objects STATE _{Base_state} = {S ₁ , S ₂ ,..., S _s }, recorded as state object subtasks according to the The value of the global attribute is judged; if global is true, it means that the state is a global shared state, and the described Give the state processing module (2), and wait for the task of the state processing module (2) to complete the message STA _2-1 ; otherwise, if global is not true, it means that the state is a local shared state, then in the stream processing module (1) the generation of The thread executes directly; The state object of the Base_state structure STATE _{Base_state} = {S ₁ , S ₂ ,..., S _s } where S ₁ represents the first type of state object, S ₂ represents the second type of state object, and S _s represents the last type The state object of , s represents the identification number of the state object; The sixth aspect of the stream processing module (1) performs task load balancing of computing threads by means of task stealing; The seventh aspect of the stream processing module (1) outputs the controller-to-switch message to the Openflow message distribution module (3); the calculation thread writes the controller-to-switch message to be output synchronously into the message-thread TH ₃ ={C ₁ ,C ₂ ,…,C _c } belong to the link in the send buffer; In TH ₃ ={C ₁ , C ₂ ,...,C _c }, C ₁ represents the first thread in the Openflow message distribution control module (3), and C ₂ represents the second thread in the Openflow message distribution control module (3). Thread, C _c represents the last thread in the Openflow message distribution control module (3), and c represents the thread identification number in the Openflow message distribution control module (3); The state processing module (2) first receives the state processing task sent by the Openflow message module (3) ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{Port-\mathrm{the\; s}tatu\mathrm{the\; s}}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}},{\mathrm{SA}}_{\mathrm{E.}rror}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}}\},$ and will ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{Port-\mathrm{the\; s}tatu\mathrm{the\; s}}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}},{\mathrm{SA}}_{\mathrm{E.}rror}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}}\}$ Save to the access task queue of the state object STATE _{Base_state} = {S ₁ ,S ₂ ,…,S _s } middle; access task queue The access task queue corresponding to the first type of state object S ₁ is marked as P ₁ , the access task queue corresponding to the second type of state object S ₂ is marked as P ₂ , and the last type of state object S _s corresponds to The access task queue is denoted as P _s ; The second aspect of the status processing module (2) receives the status processing task sent by the stream processing module (1) and will Save to the access task queue of the state object STATE _{Base_state} = {S ₁ ,S ₂ ,…,S _s } middle; State processing module (2) third aspect state - thread TH ₂ = B 1 in {B ₁ , B ₂ ,..., B _{b }} from _Extract the access task queue belonging to B1 from $P_{\mathrm{the\; s}tate}^{B_1}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\},$ and $P_{\mathrm{the\; s}tate}^{B_1}\∈P_{\mathrm{the\; s}tate}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}};$ Then B ₁ executes by polling tasks in ; when execution completes After that, the task completion message sent to the stream processing module (1) State-Thread TH ₂ = {B ₁ , B ₂ ,..., B _b } where B ₁ represents the first thread in the state processing module (2), and B ₂ represents the second thread in the state processing module (2) , _B represents the last thread in the state processing module (2), and b represents the thread identification number in the state processing module (2); State - Thread TH ₂ = B ₂ in {B ₁ ,B ₂ ,...,B _b } starts from _Extract the access task queue belonging to B2 from $P_{\mathrm{the\; s}tate}^{B_2}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\},$ and $P_{\mathrm{the\; s}tate}^{B_2}\∈P_{\mathrm{the\; s}tate}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}};$ Then B ₂ executes by polling tasks in ; when execution completes After that, the task completion message sent to the stream processing module (1) State - Thread TH ₂ = B _b in {B ₁ ,B ₂ ,...,B _b } starts from Extract the access task queue belonging to B _b from $P_{\mathrm{the\; s}tate}^{B_b}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\},$ and $P_{\mathrm{the\; s}tate}^{B_b}\∈P_{\mathrm{the\; s}tate}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}};$ Then B _b executes by polling tasks in ; when execution completes After that, the task completion message sent to the stream processing module (1) For the task completion message set sent by the state processing module (2) to the stream processing module (1) in the fourth aspect, it is denoted as ${\mathrm{STA}}_{2-1}=\{{\mathrm{STA}}_{2-1}^{B_1},{\mathrm{STA}}_{2-1}^{B_2},...,{\mathrm{STA}}_{2-1}^{B_b}\}.$ 2. The event parallel controller based on Openflow according to claim 1, characterized in that: the controller is used in conjunction with the existing Openflow controller and is embedded in the Openflow network architecture. 3. according to the event parallel processing method that the event parallel controller based on Openflow according to claim 1 carries out, it is characterized in that having the following steps: Step 1: Send and receive Openflow messages in parallel, and trigger corresponding Openflow events There is a unique link for each switch in the Openflow-based event parallel controller; During the connection establishment process, the first thread C ₁ in the message-thread TH ₃ ={C ₁ ,C ₂ ,…,C _c } is responsible for sending messages to the Openflow switch SW={D ₁ ,D ₂ ,…,D _d } The link request is monitored; when the link request is received, the link is established ${\mathrm{CON}}_{SW}^{SV}=\{{\mathrm{CON}}_{{\mathrm{D.}}_1}^{SV},{\mathrm{CON}}_{{\mathrm{D.}}_2}^{SV},...,{\mathrm{CON}}_{{\mathrm{D.}}_d}^{SV}\},$ and will link Distribute evenly to messages - thread TH ₃ ; any link Processed by the only thread C _c ; In the process of receiving Openflow messages, the message-thread TH ₃ ={C ₁ ,C ₂ ,...,C _c } adopts the asynchronous non-blocking IO model to receive the Openflow switch SW={D ₁ ,D ₂ ,... , D _d } the Openflow message sent; trigger the Packet-in event according to the Packet-in message; trigger the Flow-Removed event according to the Flow-Removed message; trigger the Port-status event according to the Port-status message; trigger the Error event according to the Error message; During the Openflow message sending process, the message-thread TH ₃ ={C ₁ ,C ₂ ,…,C _c } adopts the asynchronous non-blocking IO model from the message-thread TH ₃ ={C ₁ ,C ₂ ,…,C _c } link to belong Output the controller-to-switch message to the Openflow switch SW={D ₁ , D ₂ ,...,D _d } in the sending buffer; The operation of the sending buffer needs to be synchronized; Step 2: Parallel processing of Openflow events For the Packet-in event and Flow-Removed event, first generate the flow object FLOW _{Base_flow} ＝{F ₁ ,F ₂ ,…,F _f } as shown in the Base_flow structure in Table 1, and then generate the flow processing task according to the start method in the Base_flow structure ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\},$ Finally the task ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\}$ Sent to the main thread local task queue Q _z in the stream processing module (1); For stream processing tasks ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\},$ In the stream processing module (1), the main thread A _z will ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\}$ Send to the calculation thread local task queue of the stream processing module (1) by polling middle; calculation thread TH ₁ ={A ₁ ,A ₂ ,...,A _a } execute ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\}$ Concrete tasks in ; and dynamically generate flow object subtasks will be described add to $Q^{{\mathrm{TH}}_1}=\{Q_1,Q_2,...,Q_a\}$ middle; Calculation thread TH ₁ ={A ₁ ,A ₂ ,...,A _a } executes ${\mathrm{TASK}}_{3-1}=\{{\mathrm{FA}}_{Packet-i\mathrm{no}}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}},{\mathrm{FA}}_{flow-\mathrm{Re}moved}^{{\mathrm{FLOW}}_{Ba\mathrm{the\; s}e\_flow}}\}$ Specific tasks in ; and dynamically generate state object subtasks according to the The value of the global attribute is judged; if global is true, it means that the state is a global shared state, and the described Give the state processing module (2), and wait for the task of the state processing module (2) to complete the message STA _2-1 ; otherwise, if global is not true, it means that the state is a local shared state, then in the stream processing module (1) the generation of The threads in the stream processing module (1) perform load balancing through task stealing; For the Port-status event and the Error event, first generate a processing task for the state object STATE _{Base_state} ={S ₁ , S ₂ ,..., S _s } of the Base_state structure in Table 2 ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{Port-\mathrm{the\; s}tatu\mathrm{the\; s}}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}},{\mathrm{SA}}_{\mathrm{E.}rror}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}}\},$ then the task ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{Port-\mathrm{the\; s}tatu\mathrm{the\; s}}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}},{\mathrm{SA}}_{\mathrm{E.}rror}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}}\}$ Sent to the access task queue of the status processing module (2) $P_{\mathrm{the\; s}tate}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\}$ middle; For the task ${\mathrm{TASK}}_{3-2}=\{{\mathrm{SA}}_{Port-\mathrm{the\; s}tatu\mathrm{the\; s}}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}},{\mathrm{SA}}_{\mathrm{E.}rror}^{{\mathrm{STATE}}_{Ba\mathrm{the\; s}e\_\mathrm{the\; s}tate}}\}$ and tasks In the state processing module (2), B 1 in the state-thread TH ₂ ={B ₁ ,B ₂ ,...,B _{b }} starts from _Extract the access task queue belonging to B1 from $P_{\mathrm{the\; s}tate}^{B_1}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\};$ Then B ₁ executes by polling $P_{\mathrm{the\; s}tate}^{B_1}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\}$ tasks in ; when execution completes After that, the task completion message sent to the stream processing module (1) State - Thread TH ₂ = B ₂ in {B ₁ ,B ₂ ,...,B _b } starts from _Extract the access task queue belonging to B2 from Then B ₂ executes by polling tasks in ; when execution completes After that, the task completion message sent to the stream processing module (1) State - Thread TH ₂ = B _b in {B ₁ ,B ₂ ,...,B _b } starts from Extract the access task queue belonging to B _b from $P_{\mathrm{the\; s}tate}^{B_b}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\};$ Then B _b executes by polling $P_{\mathrm{the\; s}tate}^{B_b}=\{P_1,P_2,...,P_{\mathrm{the\; s}}\}$ tasks in ; when execution completes After that, the task completion message sent to the stream processing module (1) 4. According to the event parallel processing method performed by the Openflow-based event parallel controller according to claim 1, it is characterized in that: with the increase of the number of threads, there is a higher speed-up ratio.