Data packet processing method, system and device

Abstract

The invention provides a data packet processing method, system and device. The method is applied to a controller, and comprises the following steps: receiving a target data packet sent by a switch; the target data packet is a data packet which is not matched with the flow table rule; determining a destination address according to the target data packet, sending the target data packet to a target device based on the destination address, generating a target flow table rule corresponding to the target data packet, and sending the target flow table rule to a path switch to enable the path switch to store the target flow table rule; the path switch is a switch on a transmission path through which the data packet with the same type as the target data packet needs to be forwarded. According to the invention, the forwarding flow of the data packet can be temporarily migrated to the controller for execution when the data packet does not have the matched flow table rule, and when the data packet of the same type is subsequently transmitted, the path switch completes the storage of the target flow table rule and can directly forward the data packet, so that the problem of packet loss caused by the installation delay of the flow table rule is solved, and the data processing efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software-defined networks, and particularly to a data packet processing method, system and device. Background Art

[0002] The core concept of Software-Defined Networking (SDN) is to separate the control logic of the network from the data packet forwarding logic, that is, to divide it into a control plane and a data plane. The control plane is mainly responsible for managing various network functions, while the data plane only retains basic data matching and forwarding functions to ensure fast processing of data packets. Specifically, a controller is deployed in the control plane and a switch is deployed in the data plane. The controller is responsible for centralized decision-making of network logic, such as formulating flow table rules corresponding to various data flows to indicate the processing of data flows, and then sending the flow table rules to the switches in the data plane. Each switch is provided with a flow table for storing the flow table rules sent by the controller. The switch installs the flow table rules into the flow table. When the switch obtains a data packet to be processed, it will match the flow table rules corresponding to the data packet in the flow table and perform operations such as forwarding, modifying or discarding the data packet according to the matched flow table rules. For example, a data packet from device A is forwarded to port 1 through transmission path 1, and a data packet from device B is directly discarded, etc. By separating the control plane from the data plane, SDN realizes centralized management and flexible configuration of the network. However, its asynchronous characteristic leads to a prominent problem of flow table rule installation delay. Especially in scenarios with high real-time requirements (such as industrial control, vehicle networking, etc.), the delay may cause data packet loss, network congestion and even service interruption.

[0003] In related technologies, the installation of flow table rules is mainly achieved through the following two modes: The first is active installation, where the controller pre-sends flow table rules for various types of data packets to the switch, but this method is difficult to cope with the changes of dynamic data flows. The second is reactive installation, that is, when the switch cannot match the flow table rules corresponding to the data packet to be processed, it needs to temporarily request flow table rules from the controller. The controller re-formulates flow table rules for the data packet, and then sends the newly formulated flow table rules to all switches on the path through which the data packet is transmitted. After all switches on the transmission path re-install the new flow table rules, they will sequentially perform the forwarding of the data packet. The processes of the controller generating new flow table rules, sending the flow table rules to all switches on the transmission path, and all switches installing the flow table rules will all cause time delays.

[0004] However, there are respective problems with the existing two flow table rule installation methods. Among them, the proactive installation has no processing ability for dynamic data streams; the problem with reactive installation is mainly the delay in installing flow table rules, which is particularly significant in "mouse flows" (short-term, high-frequency small flows), and it will reduce the throughput of the Transmission Control Protocol (TCP) or cause packet loss in the User Datagram Protocol (UDP), and even trigger problems such as network black holes, loops, and network congestion. Summary of the Invention

[0005] Embodiments of the present invention provide a data packet processing method, system, and device to solve the packet loss problem caused by the delay in installing flow table rules in the prior art, improve data transmission efficiency, and avoid triggering network black holes and loops.

[0006] In a first aspect, an embodiment of the present invention provides a data packet processing method applied to a controller, including:

[0007] Receiving a target data packet sent by a switch; the target data packet is a data packet that does not match a flow table rule;

[0008] According to the target data packet, determining a destination address, based on the destination address, sending the target data packet to a target device, and generating a target flow table rule corresponding to the target data packet, and sending the target flow table rule to a path switch to instruct the path switch to store the target flow table rule;

[0009] Wherein, the path switch is a switch on the transmission path through which data packets of the same type as the target data packet need to be forwarded.

[0010] In a second aspect, an embodiment of the present invention provides a data packet processing method applied to a switch, including:

[0011] Obtaining a data packet to be forwarded;

[0012] When there is no flow table rule in the pre-determined flow table rules that matches the data packet to be forwarded, sending the data packet to be forwarded as a target data packet to a controller, so that the controller determines a destination address according to the target data packet, based on the destination address, sends the target data packet to a target device, and generates a target flow table rule corresponding to the target data packet, and sends the target flow table rule to a path switch to instruct the path switch to store the target flow table rule;

[0013] Wherein, the path switch is a switch on the transmission path through which data packets of the same type as the target data packet need to be forwarded.

[0014] In a third aspect, an embodiment of the present invention provides a data packet processing system, including: a controller and a plurality of switches. A virtual switch is deployed inside the controller, and communication is carried out between the virtual switch and each of the plurality of switches.

[0015] The switch is used to obtain a data packet to be forwarded; when there is no flow table rule in the pre-determined flow table rules that matches the data packet to be forwarded, the data packet to be forwarded is sent to the virtual switch as a target data packet.

[0016] The virtual switch receives the target data packet, determines the destination address according to the target data packet, and based on the destination address, sends the target data packet to the target device, and sends the target data packet or the header information of the target data packet to the controller.

[0017] The controller receives the target data packet or the header information of the target data packet, generates a target flow table rule corresponding to the target data packet, and sends the target flow table rule to the path switch to instruct the path switch to store the target flow table rule.

[0018] Wherein, the path switch is a switch on the transmission path through which data packets of the same type as the target data packet need to be forwarded.

[0019] In a fourth aspect, an embodiment of the present invention provides a data packet processing device, including:

[0020] A data receiving module, configured to receive a target data packet sent by a switch; the target data packet is a data packet that does not match a flow table rule.

[0021] A data processing module, configured to determine a destination address according to the target data packet, and based on the destination address, send the target data packet to the target device, generate a target flow table rule corresponding to the target data packet, and send the target flow table rule to the path switch to instruct the path switch to store the target flow table rule.

[0022] Wherein, the path switch is a switch on the transmission path through which data packets of the same type as the target data packet need to be forwarded.

[0023] In a fifth aspect, an embodiment of the present invention provides a data packet processing device, including:

[0024] A data acquisition module, configured to acquire a data packet to be forwarded.

[0025] A data sending module, configured to send the packet to be forwarded to a controller as a target packet when there is no flow table rule in a pre-determined flow table rule that matches the packet to be forwarded, so that the controller determines a destination address according to the target packet, and based on the destination address, sends the target packet to a target device, generates a target flow table rule corresponding to the target packet, and sends the target flow table rule to a path switch to instruct the path switch to store the target flow table rule; wherein, the path switch is a switch on a transmission path through which packets of the same type as the target packet need to be forwarded.

[0026] In a sixth aspect, an embodiment of the present invention provides an electronic device, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the method in any possible implementation manner of the first aspect or the second aspect above is implemented.

[0027] In a seventh aspect, an embodiment of the present invention provides a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, the method in any possible implementation manner of the first aspect or the second aspect above is implemented.

[0028] In an eighth aspect, an embodiment of the present invention provides a computer program product, including a computer program, and when the computer program is executed by a processor, the method in any possible implementation manner of the first aspect or the second aspect above is implemented.

[0029] In the embodiment of the present invention, a target packet sent by a switch is received; the target packet is a packet that does not match a flow table rule; a destination address is determined according to the target packet, the target packet is sent to a target device based on the destination address, a target flow table rule corresponding to the target packet is generated, and the target flow table rule is sent to a path switch to instruct the path switch to store the target flow table rule; the path switch is a switch on a transmission path through which packets of the same type as the target packet need to be forwarded. In the embodiment of the present invention, when there is no flow table rule in the switch that matches the target packet, the packet forwarding traffic can be temporarily migrated to the controller for execution. The controller generates a target flow table rule and sends it to the path switch for storage. When the flow table rule has not been completely stored, the controller directly executes the operation of forwarding the packet, and the target packet does not need to wait for the switch to install the flow table rule before forwarding, reducing packet loss caused by the delay in installing the flow table rule. Moreover, since the controller also sends the target flow table rule to the path switch during the process of forwarding the packet to instruct the switch to directly process packets of the same type according to the stored target flow table rule when receiving them again, while reducing packet loss, the data transmission efficiency is improved, thereby avoiding the occurrence of network black holes, loops, and congestion problems. Brief Description of the Drawings

[0030] Figure 1 FIG. is an application scenario diagram of a traditional SDN architecture for processing data packets provided by an embodiment of the present invention;

[0031] Figure 2 FIG. is a flowchart of the implementation of a data packet processing method provided by an embodiment of the present invention;

[0032] Figure 3 FIG. is an application scenario diagram of a data packet processing method provided by an embodiment of the present invention;

[0033] Figure 4 FIG. is an application scenario diagram of a data packet processing method provided by another embodiment of the present invention;

[0034] Figure 5 FIG. is a flowchart of the implementation of a data packet processing method provided by another embodiment of the present invention;

[0035] Figure 6 FIG. is a flowchart of the implementation of a data packet processing method provided by another embodiment of the present invention;

[0036] Figure 7 FIG. is a schematic structural diagram of a data packet processing system provided by an embodiment of the present invention;

[0037] Figure 8 FIG. is a topological structure diagram of an SDN network provided by an embodiment of the present invention;

[0038] Figure 9 FIG. is a diagram of the feedback rate of the controller Packet-Out message provided by an embodiment of the present invention;

[0039] Figure 10 FIG. is a schematic structural diagram of a data packet processing device provided by an embodiment of the present invention;

[0040] Figure 11 FIG. is a schematic structural diagram of a data packet processing device provided by another embodiment of the present invention;

[0041] Figure 12 FIG. is a schematic diagram of an electronic device provided by an embodiment of the present invention. Detailed Description of the Embodiments

[0042] The embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings.

[0043] The architecture of Software Defined Network (SDN) is mainly divided into three layers: the application plane, the control plane, and the data plane, as well as the interfaces connecting these layers. The core idea is to separate the network control logic from the data forwarding devices (switches) and achieve global network management through a centralized controller. Among them, the application plane runs various network application programs, interacts with the control plane through the northbound interface to implement the formulation and execution of network policies; the core of the control plane is the controller, whose main functions are to maintain the global network view (such as the status of each forwarding device, link information, etc.), generate flow table rules and send them to the forwarding devices in the data plane, and handle network events (such as link failures, traffic congestion, etc.) to regulate the load balancing between switches in the data plane; the core components of the data plane are forwarding devices such as switches and routers that support the OpenFlow communication protocol. The forwarding devices communicate with the controller through the southbound interface, and their main function is to forward data packets according to the flow table rules sent by the control plane. There is a flow table space in the switch for storing flow table rules of various data packets. Among them, the OpenFlow protocol defines the communication standard between the controller and the switch and supports the sending and management of flow tables. In the architecture of Software Defined Network (SDN), one controller can be responsible for managing hundreds of switches, and the specific number of switches depends on the performance of the controller. The control plane of the entire SDN architecture can have one controller or can connect multiple controllers through the east-west interface to achieve distributed control of all switches. The specific number of controllers required can be determined according to the scale of the actual network scenario.

[0044] All switches in the data plane of the SDN architecture are divided into: ingress switches, egress switches, and other intermediate switches. The ingress switch is used to connect the external network and the internal network. It is the first switch for the data flow to enter the internal network. As the only access point for the data flow to enter the internal network from the external network, the ingress switch receives the data flow input by external network devices (such as servers, personal computers, and other Internet of Things devices), performs initial processing on the data flow according to the flow table rules sent by the controller, and transmits the data flow to the egress switch through multiple intermediate switches. The egress switch is the last switch for the data flow to leave the internal network and reach the target terminal device. It is also the necessary node for the data flow to reach the target terminal device, makes the final forwarding decision, and forwards the data flow to the target device (such as servers, personal computers, and other terminal devices).

[0045] Although the SDN architecture has significant advantages in network manageability and flexibility and can meet complex requirements, it also has certain defects in some aspects. The centralized control logic of SDN will cause a large number of redundant requests to be generated by switches, and delays are likely to occur during the process of the controller creating flow table rules and the switches installing flow table rules. Packets accumulate in the switches, resulting in congestion, which leads to low data traffic transmission efficiency. This problem is particularly prominent in larger-scale networks. Research shows that the performance bottleneck of the data plane mainly focuses on the flow table link. Among them, the flow table establishment delay has a key impact on the data flow transmission efficiency. The controller usually installs flow table rules on switches in two ways: proactive flow table installation and reactive flow table installation. The method of the traditional SDN architecture for processing data flows will be described below in combination with specific application scenarios.

[0046] Figure 1 It is an application scenario diagram of the traditional SDN architecture for processing data packets provided by an embodiment of the present invention. This application scenario is illustrated by taking the data transmission in a data center network as an example.

[0047] As Figure 1 shown, this application scenario includes: a controller (Controller), an ingress switch (Ingress Switch), an egress switch (Egress Switch), and multiple intermediate switches (Intermediate Switch) located on the intermediate transmission path, server A and server B located in one data center, and server A1 and server B1 located in another data center.

[0048] Proactive flow table installation: The controller has pre-formulated flow table rules for data packets from server A to server A1 and flow table rules for data packets from server B to server B1, and has pre-distributed all flow table rules to all switches. The switches store the flow table rules in their respective flow table spaces. When server A wants to send data to server A1, the data packet enters from the ingress switch. The ingress switch matches the corresponding flow table rule for the data packet and forwards the data packet through the intermediate switches according to the flow table rule and finally sends it to the egress switch. The egress switch finally forwards the data packet to server A1.

[0049] Reactive Flow Table Installation: Taking the numbered steps (0-1-2-3) marked in the figure as an example, when Server A wants to send data to Server B1, the data packet is sent to the ingress switch. Since there is no pre-stored matching flow table rule in the switch, the ingress switch encapsulates the data packet into a Packet-In message and sends it to the controller. The controller parses the header information in the data packet and generates a new flow table rule based on the source address, destination address, source port number, and destination port number in the header information, and sends it to all switches on the transmission path (including the ingress switch, intermediate switches, and egress switch) through a Flow Mod message to instruct all switches on the transmission path to store the new flow table rule. After all switches on the path have stored the new flow table rule, the data packet can pass through the egress switch and be sent to Server B1 smoothly.

[0050] Since there is a time interval between the controller generating new flow table rules, distributing the flow table rules to the switch, and the process of each switch installing the flow table rules to finally establish a complete transmission path, the operation of transmitting data packets will not be carried out immediately. During this random time interval, only a part of the transmission path may be established, which may trigger a Table Miss event on some switches (that is, when no flow table rule can be matched, Table Miss is triggered, and by default, the data packet is forwarded to the controller through a Packet-In message to request the controller to issue a Flow Mod message again). For example, forwarding a data packet requires passing through a transmission path: ingress switch - intermediate switch 1 - intermediate switch 2 - intermediate switch 3... intermediate switch n - egress switch. However, due to the time asynchronous characteristics of installing flow table rules on different switches, the main reasons for this time asynchronous characteristic are: different switches receive Flow Mod messages at different times, have different current traffic loads, and different performances of each switch. Eventually, the switches on the transmission path cannot store flow table rules simultaneously, and only part of the transmission path is established (for example, only the ingress switch - intermediate switch 1 - intermediate switch 2 complete the installation of flow table rules), and the path after intermediate switch 3 is not fully established. When the data packet passes through the ingress switch - intermediate switch 1 - intermediate switch 2 to intermediate switch 3, since intermediate switch 3 has not installed the flow table rule yet, it causes the Table Miss event to be triggered again. Since there are a large number of intermediate switches in the entire transmission path, the incidence of similar Table Miss events will be very high, resulting in a large number of switches repeatedly sending redundant requests to the controller, and the controller will also send redundant Flow Mod messages to all switches on the transmission path. Since each Table Miss event will trigger communication between the controller and all switches (such as the exchange of Flow Mod messages and FlowMod messages), it increases the load on the control channel between the controller and the switch and the data transmission delay. Frequent Table Miss will cause delays in establishing flow rules, reduce TCP throughput, or cause data packet loss (especially significant for short-term, high-frequency small traffic), and even lead to serious consequences such as network black holes (data packets are discarded), loops, and instant congestion.

[0051] Regarding the defects of the existing technology, the main sources of delay are analyzed as follows: 1. Control channel bottleneck: communication delay and bandwidth limitation between the controller and the switch; 2. Asynchrony of flow table update: when a data packet arrives at the switch, the flow rule may not have been installed yet, triggering additional communication (such as Packet-In message) and temporary congestion; 3. "Barrel effect": when the controller performance, switch processing capacity, and the control channel bandwidth between the controller and the switch are unbalanced, the overall performance is limited by the weakest link.

[0052] After analyzing the root cause of the delay, it is possible to start from the root cause to solve the problems of the existing technology. Through the above analysis, it can be found that there are potential bottlenecks in the centralized management of SDN. Such bottlenecks may occur in the controller, the control channel between the controller and the switch, and the switch itself. If any of the problems in these aspects, such as the controller being overloaded (unable to generate and issue flow table rules in time), the control channel being overloaded resulting in data transmission congestion, or the switch flow table overflowing, cannot be solved, the overall performance of SDN will be reduced, and the delay problem cannot be fundamentally solved. Therefore, the key to solving the above problems is to find a balance among the controller performance, the control channel bandwidth, and the switch's own performance through what method to achieve load balancing among the controller, the switch, and the control channel.

[0053] Based on the above analysis of the root cause problems, the present invention proposes a technical concept of closed-loop migrating data flows. This technical concept is mainly improved in two aspects. The first aspect is the improvement of the method: Firstly, using the SDN function, the workload of the control plane and the data plane is dynamically adjusted based on a software method. When the controller resources are rich, migrating the workload of the data plane (data flows) to the control plane for processing can alleviate problems such as packet loss, reduced TCP throughput, and network congestion caused by the delay in installing flow table rules; when the controller is overloaded, migrating the workload of the control plane (data flows) to the data plane for processing can save the use of the control channel and alleviate the load of the control channel; avoiding the imbalance among the data plane, the control plane, and the control channel, and making the SDN network more flexible, data processing efficient, and stable through the closed-loop migration of data flows between the control plane and the data plane. The second aspect is the improvement of the hardware architecture: improving the SDN architecture, by deploying a virtual switch in the controller, and having the virtual switch process the data flows migrated from the data plane, greatly improving the data processing efficiency, enhancing the robustness of the SDN network, and enabling the SDN network to be applied to a wider range of scenarios.

[0054] Next, the specific technical solutions adopted to implement the technical concept of the present invention will be described in detail in conjunction with specific drawings.

[0055] Figure 2 It is the implementation flowchart of the packet processing method provided by the embodiment of the present invention. The method of this embodiment is described by taking the execution on the controller side as an example.

[0056] As Figure 2 shown, the method provided by this embodiment includes the following steps:

[0057] S201, receiving a target packet sent by the switch; the target packet is a packet that does not match the flow table rule.

[0058] In this step, the data packet includes header information and data. The header information usually includes information such as source address, destination address, port number, ingress port, VLAN tag, and protocol type. Among them, the port number includes the source port number and the destination port number. The source port number refers to the port used by the application program that sends the data packet. When an application program (such as a browser, a mail client, etc.) on the source device needs to send data, the operating system will allocate a unique source port number for this application program; the destination port number refers to the port used by the application program on the destination device to receive the data packet.

[0059] In a possible implementation, when the switch obtains a data packet, it first extracts the header information of the data packet, and then queries the local flow table space to try to match the matching fields such as the ingress port, protocol type, source address, destination address, and port number of the data packet. If the match is successful, it directly executes the actions in the flow table rule (such as forwarding, modifying, and discarding, etc.); if the match fails, it triggers a Packet-In message, encapsulates the target data packet for which the flow table rule match fails, and sends it to the controller. After receiving the Packet-In message, the controller extracts the target data packet from it.

[0060] S202, determine the destination address according to the target data packet, based on the destination address, send the target data packet to the target device, and generate a target flow table rule corresponding to the target data packet, and send the target flow table rule to the path switch to instruct the path switch to store the target flow table rule; wherein, the path switch is a switch on the transmission path that the data packet of the same type as the target data packet needs to pass through.

[0061] In this step, after receiving the target data packet, the controller parses the target data packet to obtain the header information, extracts the destination address from the header information, and directly sends the target data packet to the target device corresponding to the destination address; and, while directly forwarding the target data packet to the target device, the controller also generates a target flow table rule for the target data packet according to the header information, and determines the transmission path of the target data packet and the data packet of the same type as the target data packet according to the source address and destination address in the header information, and finds the switch on the transmission path (i.e., the path switch), and then sends a FlowMod message to the path switch to instruct the path switch to store the target flow table rule, so that when the switch receives the data packet of the same type as the target data packet again, it can directly match the corresponding flow table rule without waiting for the flow table rule to be installed.

[0062] It should be noted that data streams will be generated during continuous communication. A data stream consists of multiple data packets, and each data packet carries part of the data of the data stream. These data packets have the same type, and having the same type means that multiple data packets in a data stream have the same five-tuple (source address, destination address, source port, destination port, and protocol type).

[0063] Exemplarily, the application scenario architecture of this embodiment is as Figure 3 shown. The controller is connected to all switches. After the ingress switch receives a data packet (corresponding to step 1. Flow), if no flow table rule is matched, it will send a Packet-In message to the controller (corresponding to step 2. PacketIn), and then the controller directly locates the egress switch and sends a Packet-Out message to the egress switch (corresponding to step 3. PacketOut); meanwhile, the controller generates a new flow table rule and encapsulates it into a Flow Mod message and sends it to the path switch (corresponding to step 4. Flow Mod).

[0064] This embodiment redefines the process of installing flow table rules. When there is no flow table rule in the switch that matches the target data packet, the data packet forwarding traffic can be temporarily migrated to the controller for execution. The controller generates the target flow table rule and sends it to the path switch for storage. When the flow table rule has not been completely stored, the controller directly executes the operation of forwarding the data packet, and the target data packet does not need to wait for the switch to install the flow table rule before forwarding, reducing the problem of data packet loss caused by the delay in installing the flow table rule. Moreover, since the controller also sends the target flow table rule to the path switch during the process of forwarding the data packet, it ensures that all switches on the transmission path install the flow table rule before receiving subsequent data packets of the same type, so as to instruct the switch to directly process other data packets of the same data stream according to the already stored target flow table rule when receiving them again. While reducing packet loss, it improves the data processing efficiency, thereby avoiding the occurrence of network black holes, loops, and congestion problems.

[0065] In a possible implementation manner, the target data packet includes header information and data to be forwarded;

[0066] Determining the destination address according to the target data packet, and based on the destination address, sending the target data packet to the target device includes:

[0067] Parsing the header information to obtain the destination address of the target device;

[0068] Determine the target port of the egress switch according to the destination address and the pre-stored correspondence between the egress switch port and the destination address; the egress switch is a switch directly connected to the target device, and the target port is the connection port between the egress switch and the target device;

[0069] Encapsulate the packet header information and the data to be forwarded into a Packet-Out message and send it to the target port of the egress switch, so as to instruct the egress switch to send the data to be forwarded to the target device through the target port.

[0070] It should be noted that the egress switch includes multiple ports, which are respectively connected to different terminal devices. After receiving a data packet, the egress switch determines from which port to forward the data according to the destination address of the data packet, and ensures that the data is sent to the corresponding terminal device through this port. For example, the egress switch includes port 1 and port 2. All data to be sent to server C1 needs to be sent through port 1, and all data to be sent to server C2 needs to be sent through port 2.

[0071] In a possible implementation, all switches have a forwarding table for recording the correspondence between the destination addresses of each terminal device and the switch ports to guide data forwarding. When the egress switch receives a target data packet, it queries the forwarding table according to the destination address in the packet header information to determine the target port, and forwards the data packet to the target device from this target port.

[0072] In another possible implementation, the controller maintains a global network topology correspondence table, which stores the egress switch, the terminal device, and the connection information between the two, including the correspondence between the destination addresses of each terminal device and the switch ports.

[0073] In this embodiment, after receiving the target data packet, the controller extracts the destination address in the packet header information, then queries the target port of the egress switch corresponding to the destination address through the database, encapsulates the packet header information and the data to be forwarded into a Packet-Out message and sends it to the target port of the egress switch. After receiving the Packet-Out message, the egress switch directly sends the data to be forwarded to the target device through the target port according to the indication of the Packet-Out message.

[0074] In this embodiment, since the controller can communicate directly with all switches, the corresponding relationship table of the controller stores all switch ports, terminal devices, and the connection information between them (including the connection information between the ingress switch and the source device, between switches, and between the egress switch and the destination device), providing flow visibility for the entire network topology. Therefore, when the controller receives a Packet-In message, it can directly forward the target data packet to the target port of the egress switch, providing temporary flow forwarding for the target data packet before the target flow table rule is fully installed, avoiding packet congestion or loss due to waiting for the flow table rule to be installed.

[0075] In the above embodiments, by migrating the data packets that the switch cannot immediately forward to the controller for execution (realizing the flow migration from the data plane to the control plane), the problem of flow table rule installation transmission delay is solved, reducing packet loss and improving data transmission efficiency to a certain extent.

[0076] The following describes the process of flow migration from the control plane to the data plane.

[0077] In a possible implementation manner, the sending of the target flow table rule to the path switch to instruct the path switch to store the target flow table rule includes:

[0078] Sending the target flow table rule to all path switches on the transmission path to instruct all path switches on the transmission path to store the target flow table rule;

[0079] Alternatively, sending the target flow table rule to the target path switch to instruct the target path switch to store the target flow table rule and to forward the target flow table rule to other switches on the transmission path;

[0080] Wherein, the target path switch is one or more path switches among all path switches on the transmission path.

[0081] In this embodiment, there are two modes when the controller issues flow table rules. The first mode is the parallel flow table installation mode: encapsulating the target flow table rule in a Flow Mod message and sending it to all switches on the transmission path (including the ingress switch, multiple intermediate switches, and the egress switch), instructing all switches to install the target flow table rule.

[0082] In a possible implementation, when the controller sends a Flow Mod message to a switch on the transmission path, it can be sent sequentially from downstream to upstream along the transmission path, so that the flow table rules are also installed in the order from downstream to upstream (the transmission path order from downstream to upstream is: ingress switch - middle switch - egress switch). This method can prevent subsequent data packets from arriving at the OpenFlow switch in advance before the flow table installation is completed as much as possible, thereby reducing unnecessary Packet-In messages. Further, according to protocol characteristics (such as the TCP protocol), target flow table rules are installed for the return path at the same time to prevent Table Miss events.

[0083] The second mode is: encapsulate the target flow table rules and the entire transmission path information into a Flow Mod message and send it to the target path switch in all switches. While installing the target flow table rules, the target path switch forwards the FlowMod message to other switches on the transmission path, avoiding the controller from sending Flow Mod messages to all switches, thereby reducing the occupancy of the control channel between the controller and the switches and reducing the control channel load. While solving the control channel bottleneck, it realizes the flow migration of the workload from the controller to the data plane.

[0084] In a possible implementation, the target switch can be any one or more switches on the transmission path. For example, if the transmission path order from downstream to upstream is: ingress switch - middle switch 1 - middle switch 2 - middle switch 3 - egress switch, then the target path switch can be middle switch 1. The controller sends a Flow Mod message encapsulating the entire transmission path information to middle switch 1. After receiving the Flow Mod message, middle switch 1 stores the target flow table rules in the flow table space and forwards the Flow Mod message to the ingress switch, middle switch 2 - middle switch 3, and egress switch. In a possible implementation, the target switch can also be a switch with a traffic load less than a preset threshold among all switches on the transmission path. The controller sends a Flow Mod message encapsulating the entire transmission path information to the switch with a traffic load less than the preset threshold, and this target switch replaces the controller to send a Flow Mod message encapsulating the entire transmission path information to other path switches on the transmission path. While reducing the control channel load, it makes the load between the switches in the data plane more balanced.

[0085] It should be noted that the traffic load of the switch can be represented by any one or more of the three parameters: CPU occupancy rate, flow table space occupancy rate, and memory occupancy rate. The preset threshold can be determined according to the entire network system. For example, the preset threshold can be set to 30%.

[0086] Exemplarily, as Figure 4 shown, after the Controller receives the Packet-In message sent by the ingress switch (corresponding to step 1. PacketIn), it generates a target flow table rule, then encapsulates the target flow table rule and the entire transmission path information into a Flow Mod message, and then sends the Flow Mod message to the target path switch (corresponding to step 2. Flow Mod); while storing the target flow table rule, the target path switch sends the Flow Mod message to other path switches bidirectionally along the transmission path (corresponding to step 3. Flow Mod).

[0087] Since in the above embodiment, migrating the processing flow of target data packets that do not match the flow table rules to the controller for execution will additionally increase the resource consumption of the controller. Therefore, in this embodiment, by migrating the workload of the controller (the task of sending Flow Mod messages) to the switch on the data plane for execution, the control channel load is reduced, and the resource consumption pressure on the controller is also alleviated.

[0088] In a possible implementation manner, receiving the target data packet sent by the switch includes:

[0089] Detecting the maximum traffic load of the controller and the traffic load at the current moment;

[0090] When the traffic load at the current moment is less than the target threshold, determining the maximum migration traffic that the controller can receive at the current moment according to the maximum traffic load and the traffic load at the current moment;

[0091] Receiving the target data packet sent by the switch according to the maximum migration traffic.

[0092] In this embodiment, in order to truly achieve efficient flow migration among the controller, the switch, and the control channel in various situations, it is necessary to determine the relationship between the traffic load brought by the switch migrating data packets to the controller and the processing efficiency of the controller. The upper limit of the controller's processing efficiency depends on the maximum traffic load that the controller can withstand. If the traffic load of the controller at the current moment is small, then within the maximum traffic load range of the controller, more data packets that the switch does not match the flow table rules can be migrated to the controller for direct processing by the controller, thereby maximizing the data processing efficiency and reducing packet loss.

[0093] It should be noted that the value of the target threshold can be determined according to the actual performance of the controller. For example, if the target threshold is set to 1000 packets per second, and the standard data frame size in Ethernet is usually 1470 bytes. Therefore, if UDP packets are sent, the target threshold is: 1470 bytes * 1000 packets per second = 1470000 bytes per second ≈ 1.5M / second.

[0094] In a possible implementation, the method for calculating the specific resource overhead of the controller (i.e., the traffic load brought by the switch to the controller) and whether this overhead is within the acceptable and manageable range of the controller includes: modeling for software-defined networks: expressed as SDN = (C, S), where C and S represent the control plane and the data plane respectively. The control plane consists of M controllers, expressed as C = {c1, c2,..., cM}; the data plane consists of N switches, expressed as S = {s1, s2,..., sN}.

[0095] In the SDN network model of this embodiment, C represents the controller instance, S(i) represents the i-th switch, N represents the number of switches, D(i) represents the transmission delay between the controller and the i-th switch, T tablie_miss (i) represents the time consumed for reporting Packet-In when the i-th switch receives an unmatched packet, T Packet_In_out (i) represents the Packet-Out feedback time after the controller processes the Packet-In reported by the i-th switch, T packet_mod (i) represents the time for the controller to issue a flow table entry, T Flow_install (i) represents the time for the i-th switch to install a flow table entry, T Flow_query (i) represents the time for the i-th switch to query a flow table entry, T i,j represents the transmission delay between the i-th switch and the j-th switch, B(i) represents the bandwidth of the i-th switch, B(i, t) represents the data flow rate of the i-th switch at time t, and CB(t) represents the traffic load of the controller at time t.

[0096] Therefore, the transmission time PS(i) for installing traditional flow table rules can be calculated by the first formula: PS(i) = T tablie_miss (i) + T packet_mod (i) + T Flow_install (i) + 2 * D(i), i ∈ {1,..., N}; the time OS1(i) required for the switch of this embodiment to successfully migrate packets to the controller can be calculated by the second formula: OS1(i) = T tablie_miss (i) + T Packet_In_out(i) + 2 * D(i), where i ∈ {1, …, N}; thus, the delay difference ΔT1(i) between the traditional method and the method of this embodiment can be calculated by the third formula: ΔT1(i) = PS(i) - OS1(i) = T packet_mod (i) + T Flow_install (i) - T Packet_In_out (i); Determine the traffic load of the controller at the current moment t (denoted as CB1(t)) according to the second formula and the third formula. CB1(t) is calculated by the fourth formula: CB1(t) = N * ΔT1(i) * B(i, t), where i ∈ {1, …, N},

[0097] In this embodiment, after determining the traffic load of the controller at the current moment through the fourth formula, it is also necessary to determine the upper limit of the traffic load processed by the controller (i.e., the maximum traffic load).

[0098] It should be noted that the detection method of the maximum traffic load of the controller can be detected through experiments. After determining the maximum traffic load of the controller and the traffic load at the current moment, it is possible to calculate how many switches can migrate the data packets without matching flow table rules to the controller for processing at the current moment (i.e., the maximum migration traffic).

[0099] In a possible implementation manner, the method for determining the maximum migration traffic that the controller can receive at the current moment according to the maximum traffic load and the traffic load at the current moment t can be: Assume that the traffic load at the current moment t is equal to the maximum traffic load, and solve the values of the switch quantity N and the switch bandwidth B(i). Then, the maximum migration traffic at the current moment t is: the number N of switches with a bandwidth of B(i) for data stream migration per second.

[0100] In a possible implementation manner, receiving the target data packets sent by the switch according to the maximum migration traffic includes: The controller receives the target data packets sent by N switches with a bandwidth of B(i).

[0101] In this embodiment, by migrating the workload of the data plane to the controller, the problem of flow table rule installation delay is solved; further, by migrating the workload of the controller to the target path switch of the data plane, the bandwidth resource occupation of the control channel and the resource consumption of the controller are alleviated, and the closed-loop flow migration between the data plane and the control plane is realized; furthermore, by determining the upper limit of the processing capacity of the controller and the traffic load at the current moment to obtain the maximum migration traffic, within the upper limit of the processing capacity of the controller, as many data packets of switches without matching flow table rules as possible are migrated to the controller, and the efficient flow migration is truly realized while always maintaining the load balance among the controller, the switch, and the control channel, improving the data processing ability, reducing packet loss, and making the SDN network more stable and efficient.

[0102] It should be noted that the method provided by the embodiments of the present invention can also be applied to scenarios where other rules are installed in a switch to solve the latency problem. For example, when setting firewall rules at the switch level, traffic can be migrated to the controller for execution before the passive firewall rules take effect.

[0103] Figure 5 FIG. 6 is a flowchart of the implementation of the data packet processing method provided by another embodiment of the present invention. In this embodiment, taking the execution on one side of the switch as an example, the data method of the data packet is described.

[0104] As Figure 5 shown, the method provided by this embodiment includes the following steps:

[0105] S501, obtain the data packet to be forwarded;

[0106] S502, when there is no flow table rule in the pre-determined flow table rules that matches the data packet to be forwarded, send the data packet to be forwarded as a target data packet to the controller, so that the controller determines the destination address according to the target data packet, and based on the destination address, sends the target data packet to the target device, generates a target flow table rule corresponding to the target data packet, and sends the target flow table rule to the path switch to instruct the path switch to store the target flow table rule; wherein, the path switch is a switch on the transmission path that the data packet of the same type as the target data packet needs to pass through.

[0107] In a possible implementation manner, the switch includes a target path switch; the target path switch is one or more path switches among all path switches on the transmission path; the method further includes:

[0108] Receive the target flow table rule sent by the controller;

[0109] Store the target flow table rule in the flow table space and send the target flow table rule to other path switches on the transmission path.

[0110] In a possible implementation manner, the obtaining the data packet to be forwarded; when there is no flow table rule in the pre-determined flow table rules that matches the data packet to be forwarded, sending the data packet to be forwarded as a target data packet to the controller includes:

[0111] Obtain the data flow to be forwarded; the same data flow includes multiple data packets to be forwarded of the same type;

[0112] Send the first n data packets in the same data flow as the target data packet to the controller.

[0113] In this embodiment, by migrating the packet forwarding operation to the controller when there is no matching flow table rule for the data packet, it is ensured that the data packet can be normally transmitted before all switches install the flow table rules, thereby reducing packet loss and latency. Utilizing the feature that the controller and all switches can communicate with each other, the target data packet is directly sent to the target device, avoiding various consequences caused by latency without sacrificing any flow visibility. Further, when the switch obtains a data flow, since the data flow contains multiple data packets with the same five-tuple information (i.e., the same type), only the first n data packets without matching rules need to be sent to the controller as the target data packets. While the controller directly forwards the target data packets, it generates the target flow table rules and sends them to the path switches for installation. Then the switch can directly forward the other data packets of the data flow according to the target flow table rules, reducing the workload of the controller while improving the data processing efficiency.

[0114] It should be noted that the detailed implementation process of the data packet processing method in this embodiment can refer to the description in the above-mentioned embodiment executed on the controller side, and will not be repeated here.

[0115] Figure 6 FIG. is a flowchart of the implementation of the data packet processing method provided by another embodiment of the present invention. This embodiment is described by taking the interaction execution between the controller and the switch as an example.

[0116] As Figure 6 shown, the method provided in this embodiment includes the following steps:

[0117] S601, the switch obtains the data packet to be forwarded;

[0118] S602, the switch matches the flow table rule for the data packet to be forwarded. When there is no matching flow table rule, the data packet to be forwarded is encapsulated into a Packet-In message as the target data packet;

[0119] S603, send the Packet-In message to the controller;

[0120] S604, the controller extracts the header information in the target data packet according to the Packet-In message, determines the target port of the egress switch according to the header information; and generates the target flow table rule according to the header information;

[0121] S6051, the controller sends a Packet-Out message to the egress switch, and the target data packet is encapsulated in the Packet-Out message;

[0122] S6052, send a Flow Mod message to the target path switch, and the target flow table rule is encapsulated in the Flow Mod message;

[0123] S606, The egress switch receives a Packet-Out message;

[0124] S607, The egress switch sends the target data packet to the target device through the target port according to the Packet-Out message.

[0125] S608, The target path switch stores the target flow table rule according to the Flow Mod message and sends the Flow Mod message to other path switches on the transmission path to instruct other path switches to store the target flow table rule.

[0126] It should be noted that the detailed implementation process of each step in this embodiment refers to the description in the above relevant method embodiments, and will not be repeated here.

[0127] In this embodiment, when the switch receives a data stream that does not match the flow table rule, the first data packet in the data stream is sent to the controller. The controller generates a new target flow table rule according to the header information of the target data packet, and sends a Flow Mod message to the target path switch. While instructing the switches on the transmission path to store the target flow table rule, the target data packet is directly sent to the egress switch. When processing the same type of data packets in the same data stream subsequently, the switch can directly forward according to the installed target flow table rule. By this method, a small part of the data stream is migrated to the controller, ensuring that the flow rule is installed before the same type of data packets reach the switch subsequently, avoiding additional bandwidth consumption and latency (packet loss).

[0128] Figure 7 It is a schematic structural diagram of a data packet processing system provided by an embodiment of the present invention.

[0129] As Figure 7 shown, the data packet processing system of this embodiment system includes: a controller 71 and multiple switches 72. A virtual switch 73 is deployed inside the controller 71, and communication is carried out between the virtual switch and each of the multiple switches;

[0130] The switch is used to obtain the data packet to be forwarded; when there is no flow table rule in the pre-determined flow table rules that matches the data packet to be forwarded, the data packet to be forwarded is sent to the virtual switch as the target data packet;

[0131] The virtual switch receives the target data packet, determines the destination address according to the target data packet, and based on the destination address, sends the target data packet to the target device, and sends the target data packet or the header information of the target data packet to the controller;

[0132] The controller receives the target data packet or the header information of the target data packet, generates a target flow table rule corresponding to the target data packet, and sends the target flow table rule to the path switch to instruct the path switch to store the target flow table rule;

[0133] Wherein, the path switch is a switch on the transmission path through which data packets of the same type as the target data packet need to be forwarded.

[0134] It should be noted that in the above method embodiments, the data flow migration from the switch to the controller and the closed-loop flow migration from the controller to the switch are realized, and problems such as packet loss and congestion caused by the flow table rule installation delay problem are solved. However, this method will also bring a certain resource consumption pressure to the control. Therefore, on the basis of the above method, this embodiment further proposes a new data packet processing system to improve the performance of the controller and make the SDN network architecture more stable and efficient.

[0135] It can be understood that physical switches have higher performance and efficiency when processing a large amount of data because they are directly connected to physical network interfaces and can provide faster transmission speeds and lower latency. Since virtual switches can also provide performance close to that of physical switches in some cases, in this embodiment, the controller is further improved to generate a virtual switch in the controller as a temporary efficient transfer.

[0136] In a possible implementation manner, the virtual switch communicates with all switches using the VXLAN tunnel between the controller and all switches.

[0137] In a possible implementation manner, such as Figure 8As shown, according to the characteristics of the global view of the software-defined network, we can set the data forwarding rules of the virtual switch in the controller in advance based on the global network topology. All its operations and management are the same as those of other switches. Since the Controller can communicate directly with all switches, the Controller can formulate flow table rules for all data packets in the SDN network in advance and store them in the Virtual Switch. That is, the Controller sends a Flow Mod message to the virtual switch to instruct the virtual switch to store the flow table rules (corresponding to step 0. Flow Mod). When the Ingress Switch receives a target data packet that does not match the flow table rules (corresponding to step 1. Flow), it encapsulates the target data packet in a Packet-In message and reports it to the Controller (corresponding to step 2. PacletIn). The target data packet is forwarded to the virtual switch in the Controller. The virtual switch directly locates the target port of the Egress Switch according to the header information in the target data packet and sends a Packet-Out message to the Egress Switch (corresponding to step 3. PacketOut). The data is sent to the target device through the target port of the Egress Switch (that is, the data packet forwarding path is: Ingress Switch - virtual switch in the Controller - Egress Switch); at the same time, the virtual switch encapsulates the header information of the target data packet in a Packet-In message and sends it to the Controller (corresponding to step 3. PacketIn). The Controller generates a target flow table rule according to the header information, encapsulates the target flow table rule in a Flow Mod message, and sends the Flow Mod message to the switches on the transmission path (corresponding to step 4. Flow Mod). (The path passed by this flow table rule storage process is: Ingress Switch - virtual switch in the Controller - Controller - path switch).

[0138] In this embodiment, while the Controller installs the flow table rules for the switches on the transmission path, the virtual switch in the Controller will directly forward the data to the target device through the Egress Switch at the same time. Therefore, when the Ingress Switch subsequently receives other data packets of the same data stream, it can directly process them according to the installed target flow table rules.

[0139] In a possible implementation, when the virtual switch sends a Packet-In message to the Controller, it can transmit only the header information or transmit both the data and the header information. It can be determined according to the actual situation whether the data packet transmits only the header or also transmits the data to be forwarded together.

[0140] In a possible implementation, when the controller sends a Flow Mod message to the path switch, the Flow Mod message can be sent to all switches on the transmission path, or the Flow Mod message can be sent to the target path switch, and the target path switch is responsible for sending the Flow Mod message to other switches on the transmission path on behalf of the controller, so that all path switches on the transmission path cooperate to install the target flow table rules.

[0141] In this embodiment, after the SDN network architecture is improved, the virtual switch forwards data packets. The time OS2(i) required for the virtual switch to successfully migrate the data packets to the controller can be calculated by the fifth formula: OS2(i) = T tablie_miss (i) + T Flow_query (i) + 2 * D(i), i ∈ {1, …, N}; Therefore, the delay difference ΔT2(i) between the traditional data transmission method and the system provided in this embodiment can be calculated by the sixth formula: ΔT2(i) = PS(i) - OS2(i) = T packet_mod (i) + T Flow_install (i) - T Flow_query (i); According to the fifth formula and the sixth formula, it can be determined that when a virtual switch is deployed inside the controller, the traffic load of the controller at time t can be calculated by the seventh formula: CB2(t) = N * ΔT2(i) * B(i, t), i ∈ {1, …, N},

[0142] In a possible embodiment, after determining the traffic load of the controller at the current time t, it is necessary to experimentally monitor the maximum traffic load after the virtual switch is deployed in the controller, determine the maximum migration traffic based on the maximum traffic load and the traffic load at the current time t, and migrate the data streams of more switches (i.e., data packets that do not match the flow table rules) to the virtual switch in the controller for processing according to the maximum migration traffic, so as to maximize the data processing efficiency.

[0143] It should be noted that the method for determining the maximum migration traffic at the current time after the improvement of the controller in this embodiment can refer to the description in the above relevant method embodiments, and will not be elaborated here.

[0144] In this embodiment, by improving the controller in the SDN network architecture, a virtual switch is deployed in the controller. When the switch migrates the data stream to the controller, the virtual switch performs the forwarding operation of the data stream. At the same time, the virtual switch only sends the packet header information to the controller through the Packet-In message, which greatly improves the data forwarding efficiency and reduces the resource consumption of the controller.

[0145] It should be noted that the steps not elaborated in this embodiment may be referred to the descriptions in the above-mentioned method embodiments, and will not be repeated here.

[0146] In the embodiment of the present invention, first, through the improvement of the software method in the first aspect: migrating the data stream of the switch to the controller for processing, to solve the problems of data packet loss and low data transmission efficiency caused by the delay in installing flow table rules. Then, by calculating the traffic load and the maximum traffic load of the controller at the current moment to determine the maximum migration flow, and migrating the data streams of more switches to the controller for processing according to the maximum migration flow, the data streams are migrated in a balanced manner between the traffic load brought by the switch and the processing efficiency of the controller, improving the data processing efficiency and the stability of the SDN network. Further, through the improvement of the controller structure, the performance of the controller is improved, further improving the data stream migration efficiency while reducing the consumption of the controller's computing resources.

[0147] Next, the maximum migration flow that the controller can receive implemented by the improvements of the present invention embodiment in terms of method and system will be determined in combination with specific implementation manners.

[0148] In a possible implementation manner, as the number of switches migrating data streams to the controller continuously increases, the system memory resources occupied by the controller when processing requests reported by each switch also increase synchronously. Through the fourth formula and the seventh formula, the traffic load of the controller at time t can be calculated. Further, it is also necessary to detect the upper limit of the traffic load processed by the controller (i.e., the maximum traffic load).

[0149] Exemplarily, by setting the switch to encapsulate the data packet into a Packet-In message and send it to the controller, and the controller feeds back a Packet-Out message to the switch according to the Packet-In message, the detected Packet-Out message feedback rate of the controller is as Figure 9 shown, the ordinate is the Packet-In message sending rate (Packet-In Rate), the abscissa is the Packet-Out message sending rate (Packet-Out Rate), and through Figure 9It can be seen that when the sending rate of Packet-In messages does not exceed 5000 packets per second, the controller can effectively handle Packet-In messages, and the sending rate of its Packet-Out matches the receiving rate of Packet-In. However, once the sending rate of Packet-In increases to more than 5000 packets per second, for example, reaching 5500 packets per second, the tested controller cannot fully process the received Packet-In messages, and the sending rate of its Packet-Out also decreases, being lower than the receiving rate of Packet In. This indicates that the test has reached the congestion point of the maximum Packet-Out sending rate of the tested controller. Then calculate the delay (i.e., T Packet_In_out (i) value) of the controller processing Packet-In and feedbacking Packet-Out after the switch sends Packet-In at different sending rates. The obtained results are shown in Table 1.

[0150] Table 1: Delay of the controller feedbacking Packet-Out after processing the Packet-In reported by the switch

[0151] Packet In transmission rate Minimum delay (milliseconds) Maximum delay (milliseconds) Average delay (milliseconds) 1000 0.4195 1.8617 0.7724 2000 0.4209 7.9453 0.6982 3000 0.4895 9.7617 0.8114 4000 0.5347 10.2604 0.9688 5000 1.9285 30.6348 8.2683 6000 8.9438 187.2449 110.8513

[0152] It can be seen from Table 1 that when the sending rate of Packet-In does not exceed 4000 packets per second, the delay of the controller feedbacking Packet-Out messages remains stable, and the maximum delay is about 10 milliseconds. However, when the sending rate of Packet-In exceeds 4000 packets per second, the delay of feedbacking Packet-Out messages begins to increase rapidly. When the sending rate of Packet-In exceeds 5000 packets per second, the delay of feedbacking Packet-Out messages can no longer meet the requirements of the actual network for data processing rate. Therefore, it is determined that the upper limit of the controller's processing capacity is 4000 packets per second.

[0153] It should be noted that the standard data frame size in Ethernet is usually 1470 bytes, and 4000 packets per second is the maximum traffic load of the controller. Therefore, in the current experimental environment, if UDP data packets are sent, the upper limit (maximum traffic load) of the controller's traffic transmission performance is: 1470 bytes * 4000 packets per second = 5880000 bytes per second ≈ 5.6M / s.

[0154] It should be noted that the maximum traffic load of the controller and the traffic load at the current moment are calculated through the above method (after the method is improved, the traffic load of the controller at time t is CB1(t), and the traffic load of the controller at time t after the controller structure is improved is CB2(t)). Further, the parameters required to calculate CB1(t) and CB2(t) (including T tablie_miss (i), Tpacket_mod (i), T Flow_install (i) and T Flow_query (i)). Exemplarily, the time T consumed when the switch reports Packet-In upon receiving an unmatched data packet tablie_miss (i) is calculated as follows: issue a Table Miss flow entry, and after this flow table takes effect, send a data packet. Record the time of sending the data packet as t1. The time when the switch reports a Packet-In message is t2, and the test result is T tablie_miss (i) = t2 - t1. Repeat the test 100 times, and randomly select 10 test results to calculate T tablie_miss (i) The average value is approximately 0.3585 milliseconds.

[0155] Exemplarily, the process of testing the delay of the controller issuing a flow table and the corresponding maximum issuing rate is as follows: The switch triggers Packet-In messages at a certain rate, instructs the controller to issue Flow Mod messages, and records the test results. Then change the rate of Packet-In reporting and conduct the test again. When the sending rates of the obtained Packet-In messages are different, record the minimum delay, maximum delay, and average ya delay of the controller issuing Flow Mod messages. The test results are shown in Table 2.

[0156] Table 2: Delay of the controller issuing Flow Mod after processing Packet-In reported by the switch

[0157] PacketIn transmission rate Minimum delay Maximum delay Average delay 500 0.9579 13.8496 1.1571 1000 1.20588 15.6572 1.8422 2000 2.3338 149.3366 96.2286 3000 6.6729 894.4834 561.2267

[0158] As can be seen from Table 1, when the sending rate of Packet-In messages is relatively low, such as below 2000 packets / second, the controller can handle Flow Mod messages well. At this time, the Flow Mod issuing rate can match the rate of Packet-In, and the ya delay of the controller issuing the flow table is relatively low. When the sending rate of Packet-In messages increases to more than 2000 packets / second, the delay of the controller issuing Flow Mod messages doubles, indicating that the maximum bearing capacity of the controller to process Flow Mod messages is 2000 packets / second. When exceeding 2000 packets / second, packet loss may occur. Therefore, the time T packet_mod (i) can take a value of = 1.8422 milliseconds.

[0159] Exemplarily, the time efficiency of switch flow table query is a key evaluation criterion. Calculate T Flow_query(i)'s method is to add a flow table to the switch, with the action of forwarding to a certain port. Send a data packet, record this time as t3, and the time when the data packet is forwarded out from the corresponding port as t4. Then the time for the switch to query a flow table is t4 - t3. Measure it 10 times repeatedly, and then change the number of installed flow table entries and repeat the test. The average query time is obtained as 0.33412 ms. Therefore, T Flow_query (i) takes the value of 0.33412.

[0160] Exemplarily, the method for detecting the time when the switch installs a flow table rule and makes it effective (i.e., T Flow_install (i)) is as follows: Continuously send data packets to an input port of the switch. At this time, no data packets are forwarded out. Add a flow table rule that can match the data packets, record the time t5 when this flow table is issued. After the flow table becomes effective, data packets will be forwarded out from the output port. Record the time t6 when the first data packet is forwarded out. Then the time for the switch to install a flow table rule and make it effective is t6 - t5. Repeat the test by issuing multiple different flow tables with different throughputs. A total of 10 tests are conducted, and 500 flow tables are issued each time. Finally, the minimum value of T Flow_install (i) is 0.30804 milliseconds, the median value is 1.57336 milliseconds, the average value is 2.89751 milliseconds, and the maximum value is 13.72160 milliseconds.

[0161] Through the above detection method, after obtaining the values of various parameters (T tablie_miss (i), T packet_mod (i), and T Flow_install (i), etc.), substitute the average value of the above parameters into the fourth formula, and let CB1(t) = 5.6 M / s (megabytes per second). The maximum migration flow rate after the improvement of the software method based on the first aspect of the present invention can be calculated as: CB1(t) = N * ΔT1(i) * B(i) = N * ΔT1(i) * 100 M = 5.6 M / s (megabytes per second). When the switch bandwidth is 100 M, the number of switches N is approximately 18. Therefore, when the traffic load of the controller is less than the target threshold, the data flow can be migrated to the controller. The maximum migration flow rate is: the number of switches with an allowable migration bandwidth of 100 M is less than or equal to 18 per second, that is, the switch can migrate the data flow to the controller at a transmission rate of 100 Mbps, and the maximum number of switches allowed to migrate the data flow at this rate is 18.

[0162] Further, after the controller deploys the virtual switch, the maximum traffic load is detected through experiments to be approximately 300M / s. Substituting the average value of the above parameters into the seventh formula and setting CB2(t) equal to 300, the maximum migration traffic after improving the controller structure according to the second aspect of the present invention can be obtained: CB2(t) = N * ΔT2(i) * B(i) = N * ΔT(i) * 100M = 300M / s. When the switch bandwidth is 100M, the number of switches is approximately 806. At this time, the maximum migration traffic allowed by the controller is: the number of switches with a bandwidth of 100M is 806 per second, that is, the switch can migrate data streams to the controller at a rate of 100Mbps, and the maximum number of switches allowed to migrate data streams at this rate is 806.

[0163] It should be noted that the above data is obtained under experimental conditions. In specific implementation, different parameter values will result in different finally determined maximum migration traffic allowed for the switch to the controller. Moreover, the number of switches corresponding to the allowed migrated data streams for switches with different bandwidths will also be different.

[0164] In this embodiment, by improving the method, migrating the data stream of the switch to the controller for processing solves problems such as packet loss caused by the delay in installing flow table rules. Further, by determining the maximum traffic load of the controller and the traffic load at the current moment, the maximum migration traffic that the controller can receive is determined, realizing the load balance between the controller, the switch, and the control channel on the basis of solving the delay problem and improving data processing efficiency. Further, through the improvement of the controller structure, the characteristic that the controller is connected to all switches is utilized, and the virtual switch data forwarding rules are set in advance to play the role of directly forwarding data. The virtual switch also plays the role of buffering and caching, greatly increasing the elasticity of the controller, making the controller, the switch, and the control channel always in a dynamically balanced state, fundamentally solving problems such as low data processing rate and network congestion, and making the SDN network greatly improve the data transmission efficiency while being more stable and flexible.

[0165] It should be understood that the magnitudes of the sequence numbers of the steps in the above embodiments do not mean the order of execution. The execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

[0166] The following is the device embodiment of the present invention. For details not described in detail therein, reference can be made to the corresponding method embodiment above.

[0167] Figure 10 is a schematic structural diagram of a packet processing device provided by an embodiment of the present invention, as Figure 10As shown in the figure, the device provided in this embodiment includes: a data receiving module 1001, configured to receive a target data packet sent by a switch; the target data packet is a data packet that does not match a flow table rule; a data processing module 1002, configured to determine a destination address according to the target data packet, and based on the destination address, send the target data packet to a target device, and generate a target flow table rule corresponding to the target data packet, and send the target flow table rule to a path switch to instruct the path switch to store the target flow table rule; wherein, the path switch is a switch on the transmission path through which data packets of the same type as the target data packet need to be forwarded.

[0168] In a possible implementation manner, the data receiving module 1001 is specifically configured to: detect the maximum traffic load of the controller and the traffic load at the current moment; when the traffic load at the current moment is less than a target threshold, determine the maximum migration traffic that the controller can receive at the current moment according to the maximum traffic load and the traffic load at the current moment; and receive the target data packet sent by the switch according to the maximum migration traffic.

[0169] In a possible implementation manner, the target data packet includes header information and data to be forwarded; the data processing module 1002 is specifically configured to: parse the header information to obtain the destination address of the target device; determine the target port of the egress switch according to the destination address and the corresponding relationship between the egress switch port and the destination address stored in advance; the egress switch is a switch directly connected to the target device, and the target port is the connection port between the egress switch and the target device; encapsulate the header information and the data to be forwarded into a Packet-Out message and send it to the target port of the egress switch to instruct the egress switch to send the data to be forwarded to the target device through the target port.

[0170] In a possible implementation manner, the data processing module 1002 is specifically configured to: send the target flow table rule to all path switches on the transmission path to instruct all path switches on the transmission path to store the target flow table rule; or, send the target flow table rule to a target path switch to instruct the target path switch to store the target flow table rule, and instruct the target path switch to forward the target flow table rule to other switches on the transmission path; wherein, the target path switch is one or more path switches among all path switches on the transmission path.

[0171] Figure 11 is a schematic structural diagram of a data packet processing device provided in another embodiment of the present invention, as Figure 11As shown in the figure, the device provided in this embodiment includes: a data acquisition module 1101, configured to acquire a data packet to be forwarded; a data sending module 1102, configured to, when there is no flow table rule in the pre-determined flow table rules that matches the data packet to be forwarded, send the data packet to be forwarded as a target data packet to a controller, so that the controller determines a destination address according to the target data packet, and based on the destination address, sends the target data packet to a target device, generates a target flow table rule corresponding to the target data packet, and sends the target flow table rule to a path switch to instruct the path switch to store the target flow table rule; where the path switch is a switch on a transmission path through which data packets of the same type as the target data packet are forwarded.

[0172] In a possible implementation manner, the switch includes a target path switch; the target path switch is one or more path switches among all path switches on the transmission path; the data sending module 1102 is further configured to: receive the target flow table rule sent by the controller; store the target flow table rule in a flow table space, and forward the target flow table rule to other path switches on the transmission path.

[0173] In a possible implementation manner, the data acquisition module 1101 is specifically configured to: acquire a data flow to be forwarded; the same data flow includes multiple data packets to be forwarded of the same type; when there is no flow table rule in the pre-determined flow table rules that matches the data flow to be forwarded, send the first n data packets in the same data flow as target data packets to the controller.

[0174] Figure 12 is a schematic diagram of an electronic device provided in an embodiment of the present invention. As Figure 12 shown, the electronic device 12 in this embodiment includes: a processor 120 and a memory 121. The memory 121 stores a computer program 122. When the processor 120 executes the computer program 122, the steps in the above method embodiments are implemented. Alternatively, when the processor 120 executes the computer program 122, the functions of each module / unit in the above device embodiments are implemented.

[0175] Exemplarily, the computer program 122 can be divided into one or more modules / units, and the one or more modules / units are stored in the memory 121 and executed by the processor 120 to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of completing specific functions, and the instruction segments are used to describe the execution process of the computer program 122 in the electronic device 12.

[0176] The electronic device 12 may include, but is not limited to, a processor 120 and a memory 121. Those skilled in the art can understand,Figure 12 This is only an example of the electronic device 12, and does not constitute a limitation on the electronic device 12. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, the electronic device 12 may also include input / output devices, network access devices, buses, etc.

[0177] The processor 120 may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0178] The memory 121 may be an internal storage unit of the electronic device 12, such as the hard disk or memory of the electronic device 12. The memory 121 may also be an external storage device of the electronic device 12, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc., equipped on the electronic device 12. Further, the memory 121 may also include both the internal storage unit and the external storage device of the electronic device 12. The memory 121 is used to store the computer program 122 and other programs and data required by the electronic device 12. The memory 121 may also be used to temporarily store data that has been output or is to be output.

[0179] For the convenience and simplicity of description, only the above division of each functional module / unit is used as an example. In actual applications, the above functions may be assigned to different functional modules / units according to needs. The above modules / units may be implemented in the form of hardware, or in the form of software, or in the form of a combination of hardware and software.

[0180] The embodiment of the present invention also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the methods in the above method embodiments are implemented.

[0181] The embodiment of the present invention also provides a computer program product, including a computer program. When the computer program is executed by a processor, the methods in the above method embodiments are implemented.

[0182] Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file or some intermediate form, etc. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disc, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium, etc.

[0183] In the above embodiments, the descriptions of each embodiment have their own focuses. For the parts not detailed or recorded in a certain embodiment, reference can be made to the relevant descriptions of other embodiments. Without special instructions and logical conflicts, the terms and / or descriptions between different embodiments are consistent and can be mutually referred to, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0184] The above-described embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of each embodiment of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A data packet processing method, applied to a controller, characterized in that: include: Receive the target data packet sent by the switch; The target data packet is a data packet that does not match the flow table rule; Determine a destination address according to the target data packet, send the target data packet to a target device based on the destination address, generate a target flow table rule corresponding to the target data packet, and send the target flow table rule to a path switch to instruct the path switch to store the target flow table rule; The path switch is a switch on a transmission path through which a data packet of the same type as the target data packet needs to be forwarded.

2. The method according to claim 1, characterized in that: The receiving switch sends a target data packet, including: Detecting the maximum flow load of the controller and the flow load at the current moment; When the traffic load at the current moment is less than the target threshold, determining the maximum migration traffic that the controller can receive at the current moment according to the maximum traffic load and the traffic load at the current moment; According to the maximum migration flow, a target data packet sent by the switch is received.

3. The method according to claim 1, characterized in that: The target data packet includes packet header information and data to be forwarded; The step of determining a destination address according to the target data packet and sending the target data packet to a target device based on the destination address includes: Parsing the packet header information to obtain the destination address of the target device; Determine the target port of the egress switch according to the destination address and the pre-stored correspondence between the egress switch port and the destination address; the egress switch is a switch directly connected to the target device, and the target port is a connection port between the egress switch and the target device; The packet header information and the data to be forwarded are encapsulated into a Packet-Out message and sent to the target port of the egress switch, so as to instruct the egress switch to send the data to be forwarded to the target device through the target port.

4. The method according to any one of claims 1 to 3, characterized in that: The step of sending the target flow table rule to a path switch to instruct the path switch to store the target flow table rule includes: Sending the target flow table rule to all path switches on the transmission path to instruct all path switches on the transmission path to store the target flow table rule; Alternatively, the target flow table rule is sent to a target path switch to instruct the target path switch to store the target flow table rule, and to instruct the target path switch to forward the target flow table rule to other switches on the transmission path; The target path switch is one or more path switches among all path switches on the transmission path.

5. A data packet processing method, applied to a switch, characterized in that: include: Get the data packet to be forwarded; When there is no flow table rule matching the data packet to be forwarded in the predetermined flow table rules, the data packet to be forwarded is sent to the controller as a target data packet, so that the controller determines a destination address according to the target data packet, sends the target data packet to a target device based on the destination address, generates a target flow table rule corresponding to the target data packet, and sends the target flow table rule to the path switch to instruct the path switch to store the target flow table rule; The path switch is a switch on a transmission path through which a data packet of the same type as the target data packet needs to be forwarded.

6. The method according to claim 5, characterized in that The switch includes a target path switch; the target path switch is one or more path switches among all path switches on the transmission path; The method further comprises: Receiving the target flow table rule sent by the controller; The target flow table rule is stored in the flow table space, and the target flow table rule is forwarded to other path switches on the transmission path.

7. The method according to claim 5, characterized in that The step of obtaining a data packet to be forwarded; and when there is no flow table rule matching the data packet to be forwarded in the predetermined flow table rules, sending the data packet to be forwarded as a target data packet to the controller includes: Obtain a data stream to be forwarded; the same data stream includes multiple data packets of the same type to be forwarded; When there is no flow table rule matched by the data flow to be forwarded in the predetermined flow table rules, the first n data packets in the same data flow are sent to the controller as target data packets.

8. A data packet processing system, characterized in that: include: A controller and a plurality of switches, wherein a virtual switch is deployed in the controller, and the virtual switch communicates with each of the plurality of switches; The switch is used to obtain a data packet to be forwarded; when there is no flow table rule matching the data packet to be forwarded in the predetermined flow table rules, the data packet to be forwarded is sent to the virtual switch as a target data packet; The virtual switch receives the target data packet, determines a destination address according to the target data packet, sends the target data packet to a target device based on the destination address, and sends the target data packet or header information of the target data packet to the controller; The controller receives the target data packet or the packet header information of the target data packet, generates a target flow table rule corresponding to the target data packet, and sends the target flow table rule to the path switch to instruct the path switch to store the target flow table rule; The path switch is a switch on a transmission path through which a data packet of the same type as the target data packet needs to be forwarded.

9. A data packet processing device, characterized in that: include: A data receiving module, used for receiving a target data packet sent by the switch; The target data packet is a data packet that does not match the flow table rule; A data processing module, configured to determine a destination address according to the target data packet, send the target data packet to a target device based on the destination address, generate a target flow table rule corresponding to the target data packet, and send the target flow table rule to a path switch to instruct the path switch to store the target flow table rule; The path switch is a switch on a transmission path through which a data packet of the same type as the target data packet needs to be forwarded.

10. A data packet processing device, characterized in that: include: A data acquisition module, used to acquire data packets to be forwarded; A data sending module is used to send the data packet to be forwarded as a target data packet to the controller when there is no flow table rule matching the data packet to be forwarded in the predetermined flow table rules, so that the controller determines the destination address according to the target data packet, sends the target data packet to the target device based on the destination address, generates a target flow table rule corresponding to the target data packet, and sends the target flow table rule to the path switch to instruct the path switch to store the target flow table rule; wherein the path switch is a switch on the transmission path that needs to be passed through for forwarding data packets of the same type as the target data packet.

Images