CN109756421B - Congestion control system and method based on OpenFlow technology - Google Patents
Congestion control system and method based on OpenFlow technology Download PDFInfo
- Publication number
- CN109756421B CN109756421B CN201910062999.5A CN201910062999A CN109756421B CN 109756421 B CN109756421 B CN 109756421B CN 201910062999 A CN201910062999 A CN 201910062999A CN 109756421 B CN109756421 B CN 109756421B
- Authority
- CN
- China
- Prior art keywords
- network
- switch
- link
- controller
- bandwidth
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Abstract
The invention discloses a congestion control system and a method based on OpenFlow technology, wherein the system comprises: the system comprises a network topology sensing module, a network bandwidth monitoring module, a network delay detection module, a flow scheduling module, a network visualization display module and a network configuration management module; the method mainly comprises the steps of collecting network topology and calculating the shortest path of the whole network according to a Dijkstra algorithm; monitoring link bandwidth data in real time through requests and replies of OFPPortStatsRequest in OpenFlow messages; detecting the link delay in real time through a newly added timestamp tag of an LLDP data packet and a newly added timestamp tag of an echo message; displaying a visual interface, and changing a routing rule in real time through an REST API; and if the congestion is judged to occur, the traffic is dispatched to the light load link through the traffic dispatching module to avoid the congestion of a certain link, otherwise, the traffic is forwarded according to the original link. The congestion control system and the method can quickly recover network service, relieve network congestion and improve the utilization rate of link bandwidth.
Description
Technical Field
The invention relates to the field of congestion control of a data communication network, in particular to a congestion control system and method based on an OpenFlow technology.
Background
Traditional traffic engineering relies on a TCP/IP protocol stack, network traffic is increased explosively nowadays, traditional methods are low in efficiency for congestion sensing and congestion traffic scheduling, some methods even need to modify the protocol stack on an end system, and with the change of computer networks, the performance of the methods cannot meet the requirements of people.
In recent years, a software defined network becomes a research hotspot in the field of network communication, the design of the software defined network subverts the traditional architecture of a computer network, OpenFlow is used as a core protocol to enable efficient and intelligent flow scheduling to be possible, a controller in the software defined network architecture is provided with a global view, the controller not only grasps the whole network topology structure, but also has the capability of collecting network information in real time, and thus the controller has the routing decision capability. At the present stage, many researches based on the OpenFlow technology only use bandwidth as a congestion occurrence sign, and a congestion control method based on flow scheduling cost is provided. However, the above scheme only considers the network bandwidth and does not consider the link delay, and the above method cannot achieve the expected effect when there is an intolerable link in the network. The invention provides a method for detecting link delay based on an OpenFlow technology, provides a bandwidth monitoring method based on an OpenFlow protocol, and provides a congestion control system and a congestion control method in combination with topology sensing and flow scheduling.
Disclosure of Invention
The invention aims to overcome the defects and shortcomings in the prior art, and provides a congestion control system and method based on an OpenFlow technology, which can monitor bandwidth and detect time delay in real time, can dynamically select routing rules, and is beneficial to efficiently scheduling flow.
In order to realize the purpose, the invention adopts the following technical scheme:
an OpenFlow technology-based congestion control system, comprising:
the network topology sensing module is used for sensing the topology of the whole network switch and the host;
the network bandwidth monitoring module is used for collecting the bandwidth use condition of the whole network link in real time;
the network delay detection module is used for collecting delay data of the whole network link in real time;
and the flow scheduling module is used for dynamically executing a multi-parameter flow scheduling scheme in real time according to the data acquired by the network topology sensing module, the network bandwidth monitoring module and the network delay detection module, and changing a routing rule on line according to the requirement of a network administrator.
As a preferred technical solution, the system further includes two auxiliary modules:
the network visualization display module is used for arranging the network topology obtained by sensing and the network parameters obtained by collecting and then displaying the network topology and the collected network parameters by a graphical interface;
and the network configuration management module is used for designing a set of method for dynamically changing the routing rule based on REST API, configuring a monitoring period and a detection period through an easy-to-operate graphical interface user, and performing custom management on the network visualization display module.
As a preferred technical solution, a method for controlling a congestion control system based on the OpenFlow technology includes the steps of:
(1) acquiring the topology of the whole network and calculating the shortest path of the whole network based on the hop count: calling a network topology sensing module to sense the switch by using an LLDP protocol, and sensing a host by using an ARP protocol to obtain a full-network topology; after the topology of the whole network is obtained, the flow scheduling module calculates the shortest path of the whole network based on the hop count according to the Dijkstra algorithm, because the cost values of all links are equal, the optimal path is equivalent to the shortest path, and the shortest path only depends on the hop count;
(2) monitoring the bandwidth in real time and calculating the optimal path of the whole network based on the bandwidth: by utilizing an OFPPortStatsRequest message in an OpenFlow protocol, a controller acquires a bandwidth value of a whole network link, and periodically calls a network bandwidth monitoring module to acquire real-time bandwidth data; taking the bandwidth data as a cost value of each link, and calculating a bandwidth-based full-network optimal path by a flow scheduling module according to a Dijkstra algorithm;
(3) detecting time delay in real time and calculating the optimal path of the whole network based on the time delay: adding a timestamp variable into an OpenFlow protocol, calculating the link delay of the whole network, periodically calling a network delay detection module, and mastering real-time delay data; taking the time delay data as a cost value of each link, and calculating the time delay-based optimal path of the whole network by the flow scheduling module according to a Dijkstra algorithm;
(4) calculating a global optimal path: taking time delay and bandwidth with different weight ratios as cost values of each link, and calculating a global optimal path by a flow scheduling module according to a Dijkstra algorithm;
(5) selecting a routing rule: aiming at the time delay and bandwidth data conditions of each link in the network, a network administrator selects a proper routing rule according to a self-defined REST API, and a flow scheduling module sequentially issues flow table items for the switches on the selected path, so that the network congestion is relieved to the maximum extent.
As a preferred technical solution, in step (1), the invoking network topology sensing module senses the switch using the LLDP protocol, and senses the host using the ARP protocol to obtain the full network topology, specifically including the following steps:
feeling the switch: when a network is initialized, the controller instructs the switch to send an LLDP data Packet to another switch by issuing a Packet _ out message in an OpenFlow protocol to the switch, the other switch receives the LLDP data Packet, encapsulates the LLDP data Packet into a Packet _ in message, transmits the LLDP data Packet into the controller, and obtains information of the whole network switch through analysis;
feeling the host: when a host sends an ARP Packet to a network, an access switch where the ARP Packet first arrives does not know how to forward, the ARP Packet is encapsulated in a Packet _ in message and is uploaded to a controller, and the controller knows that the host is connected with the access switch.
As a preferred technical solution, in step (1), when topology is perceived, obtaining configuration information of each link includes link capacity;
and after the full-network topology is obtained, the switch is used as a vertex, the link is used as an edge, and the vertex and the link are stored in a graph structure to be used as input parameters of the Dijkstra algorithm.
As a preferred technical solution, in the step (2), by using an OFPPortStatsRequest message in the OpenFlow protocol, the controller grasps a bandwidth value of a link in the whole network, periodically calls the network bandwidth monitoring module, and grasps real-time bandwidth data, which specifically includes the following steps:
(2-1) initializing configuration: after the network topology sensing module acquires the whole network information, the network management module determines the monitoring period;
(2-2) the controller sends an OFPPortStatsRequest request to the full-network switch;
(2-3) after each switch receives the OFPPortStatsRequest request, inquiring the statistical data of all ports of the switch, and then replying to a set including the statistical data of all ports, wherein the number of elements is the number of ports, each element in the set is a structural body called ofp _ port _ stats, and the structural body contains four important data: sending byte number, receiving byte number, survival time and survival nanosecond time, wherein the four important data are statistical data of the port since initialization; the controller receives the ofp _ port _ stats structure body and stores four important data for calculation;
(2-4) at certain intervals, the controller sends an OFPPortStatsRequest request to the whole network switch to obtain new port statistical data;
(2-5) calculating port bandwidth data, and calculating the bandwidth value of the port according to the following formula;
wherein the interval period is:
period＝(durationsec_new+durationnsec_new×10-9)-(durationsec_old+durationnsec_old×10-9)
as a preferred technical solution, in the step (3), adding a timestamp variable in the OpenFlow protocol, calculating a link delay of the whole network, periodically calling a network delay detection module, and grasping real-time delay data specifically includes the following steps:
(3-1) obtaining [ controller-switch s 1-switch s 2-controller ] according to the timestamp variable newly added in the LLDP data packet encapsulated in the OpenFlow message]The time delay of the three links is set as T1；
(3-2) according to the principle of the step (3-1) [ controller-switch s 1-switch s 2-controller]Obtaining the reverse time delay of three links, setting as T2Defining RTT as the round trip delay, it is obvious that:
T1+T2＝RTTcontroller-s 1+RTTs1-s2+RTTs 2-controller
(3-3) according to the OpenFlow v1.3 protocol standard, obtaining the round-trip delay from the controller to the switch by adding a timestamp variable newly added by the echo message, wherein the specific process is as follows: setting a timestamp parameter in a message echo _ request sent by a controller, writing the current time into a timestamp field when the controller sends the echo _ request message to a switch, replying the echo _ reply message to the controller when the switch receives the message, and immediately inquiring the current time after the controller receives the message, so that the method comprises the following steps:
RTTcontroller-switchReceiving-transmitting time stamp
Thus obtaining RTTController-s 1、RTTController-s 2；
(3-4) deriving from the above steps, the link delay between switch s1 and switch s 2:
as a preferred technical solution, in the step (4), calculating the global optimal path specifically includes the following steps:
(4-1) assuming that there are n links in the network, let the network link set L: { L:1,l2,…ln{ used bandwidth set of links B: { B1,b2,…bnR, link residual bandwidth set R: { R: }1,r2,…rn{ S, set of link capacities S: }1,s2,…sn{ D } link delay set D: { D1,d2,…dnThe number of the five set elements is equal, the set L and the set S can be obtained by a network topology sensing module, the set B can be obtained by a network bandwidth monitoring module, the set D can be obtained by a network time delay detection module, and each element in the set R is obtained by the following calculation formula:
ri＝si-bi(i＝1,2,...n)
(4-2) set of cost values C of each link: { C1,c2,…cnAnd each element in the set C can be calculated by the following formula:
ci＝αdi-βri
wherein alpha and beta are weight coefficients, the numerical values depend on a specific network model and can be configured by a network administrator in real time;
and (4-3) introducing the set C as an input parameter into a Dijkstra algorithm, and calculating a global optimal path.
As a preferred technical solution, in step (5), four legal requests are defined in the custom REST API: firstly, switching a routing rule into hop count; secondly, switching the routing rule into bandwidth; thirdly, switching the routing rule into time delay; fourthly, switching the routing rule into the weight sum of the bandwidth and the time delay;
any of the above requests is submitted to a server running a controller program, which can change the routing rule, and the network administrator can freely set the routing rule as the case may be.
Compared with the prior art, the invention has the following advantages and effects:
(1) the method for dynamically monitoring the link bandwidth provided by the invention has high accuracy and sensitivity, and is suitable for collecting bandwidth data in a software defined network environment.
(2) According to the method for detecting the link time delay, the time delay data of each link in the network is obtained by adding the timestamp variable, and through practice, the method is high in measurement accuracy, can be used as a bottom data collection module, and brings possibility for enriching network functions.
(3) In the flow scheduling method provided by the invention, time delay and bandwidth data are displayed through a visual interface, and routing rules are changed in real time through a user-defined REST API; and if the congestion is judged to occur, the traffic is dispatched to the light load link through the traffic dispatching module to avoid the congestion of a certain link, otherwise, the traffic is forwarded according to the original link. Therefore, the network service can be quickly recovered, the network congestion is relieved, and the utilization rate of the link bandwidth is improved.
(4) The invention fully utilizes the flexible and programmable characteristic of the controller to develop abundant REST API for network administrators to manage and configure the network, thereby greatly improving the efficiency of the network administrators and reducing the cost of network management.
(5) The invention can monitor the network condition in real time through the data measuring module, optimizes the operation complexity of the manager and reduces the harm caused by low-efficiency scheduling, and the congestion control scheme can determine the routing rule according to various network parameters in the network, not only can determine the static routing rule of a single parameter when the network is initialized, but also can dynamically configure the multi-parameter routing rule by a network manager in the network operation process, thereby realizing high-efficiency scheduling of flow, greatly relieving network congestion and finally optimizing the agile scheduling and flexible control capability of the network.
Drawings
In order to more clearly and intuitively explain the technical solution of the present embodiment, the related drawings will be described below.
Fig. 1 is a schematic diagram of a congestion control system according to the present embodiment;
fig. 2 is a flowchart of the bandwidth monitoring function of the present embodiment;
fig. 3 is a schematic diagram of the delay detection principle of the present embodiment, where the sum of the three link delays of the solid arrows is T1The sum of the three link delays, called the forward delay, and the dashed arrow, is T2Called reverse latency, the link latency from the controller to switch s1 is RTTController-s 1The link delay from the controller to switch s2 is RTTController-s 2；
Fig. 4 is a model diagram of a network topology according to this embodiment, and includes a Controller (Controller), five OpenFlow switches (s1, s2, s3, s4, s5), and three hosts (h1, h2, h3), where h1 and h2 serve as clients and h3 serves as a server.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention will be described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention.
Examples
The congestion control system and method based on the OpenFlow technology provided by the embodiment have a dynamic bandwidth monitoring effect; by adding a timestamp label, an accurate time delay detection method is determined; the high-efficiency scheduling of the flow is realized by collecting the bandwidth and delay data of the link in real time and dynamically updating the routing rule, thereby greatly relieving the network congestion.
As shown in fig. 1, the congestion control system based on the OpenFlow technology in this embodiment mainly includes a network topology sensing module, a network bandwidth monitoring module, a network delay detection module, and a traffic scheduling module, where data obtained by the first three measurement modules may be fed back to the traffic scheduling module in real time, and the traffic scheduling module executes a multi-parameter traffic scheduling algorithm, so as to implement an optimal path forwarding function and achieve efficient traffic scheduling. Meanwhile, the system of the embodiment further comprises two auxiliary modules: the network visual display module is used for arranging the network topology obtained by sensing and the network parameters obtained by collecting and then displaying the network topology and the network parameters by a graphical interface; the network configuration management module is used for designing a set of method for dynamically changing routing rules based on REST API (REST: presentation layer state conversion; API: application program interface), configuring monitoring periods and detection periods through an easy-to-operate graphical interface user, and performing custom management on the network visualization display module.
In this embodiment, the network topology sensing module is configured to obtain a full-network topology structure, and when initializing, the controller grasps a networking condition of the full-network switch through an LLDP Protocol (Link Layer Discovery Protocol), and then discovers a full-network host according to an ARP Protocol (Address Resolution Protocol). And according to the obtained topology structure of the whole network, the flow scheduling module executes Dijkstra algorithm to calculate the shortest path of the whole network based on the hop number, the cost values of all links are equal at the moment, the optimal path is equivalent to the shortest path, and the shortest path depends on the hop number.
The network bandwidth monitoring module is used for periodically collecting bandwidth data of a whole network link, and finding that the OFPPortStatsRequest request is very suitable for measurement requirements by consulting OpenFlow protocol documents. When the controller sends this request to the switch, the switch returns data such as the number of bytes sent (tx _ bytes), the number of bytes received (rx _ bytes), the time to live (duration _ sec), the time to live (duration _ nsec), etc., of each port since initialization to the controller. Since the port bandwidth refers to the data transmission capability of the port, the total data in a certain interval time is the sum of the transmitted data and the received data. Because the data sent and received by the port is transmitted through the link which is connected with the port only, the bandwidth of the port is equal to that of the corresponding link. And taking the link bandwidth data as a cost value of each link, and calculating the bandwidth-based full-network optimal path by the flow scheduling module according to a Dijkstra algorithm.
Fig. 2 shows a specific process for calculating link bandwidth data, which includes the following steps:
And step 2, the controller sends an OFPPortStatsRequest request to the switch of the whole network, and the OFPPortStatsRequest request is transmitted through a secure channel because the secure channel (secure channel) exists between the controller and the switch.
Step 3, after receiving the OFPPortStatsRequest request, each switch queries the statistical data of all its ports, and then replies to the controller with a set including the statistical data of all the ports, where the number of elements is the number of ports, and each element in the set is a structural body called ofp _ port _ stats, and the structural body contains four important data: the number of transmitted bytes (tx _ bytes), the number of received bytes (rx _ bytes), the lifetime (duration _ sec), and the lifetime nanosecond (duration _ nsec), which are statistics of the port since initialization. The controller receives the ofp _ port _ stats structure and stores the four data for calculation.
And 4, after a period of period, the controller sends an OFPPortStatsRequest request to the whole network switch, which is similar to the step 2.
Step 6, calculating port bandwidth data, and obtaining the bandwidth value of the port according to the following formula:
wherein the interval period is:
period＝(durationsec_new+durationnsec_new×10-9)-(durationsec_old+durationnsec_old×10-9)
and (3) obtaining the bandwidth data of the whole network link according to the steps, finishing one bandwidth monitoring period, and returning to the step (2) for recycling according to the period interval set in the step (1).
As shown in fig. 3, which is a detection principle of the network delay detection module, the link delay required by this embodiment refers to the delay from the switch s1 to the switch s2, and needs to be calculated in two steps.
The first step, a timestamp variable newly added in an LLDP data packet is utilized, the LLDP data packet is used for link discovery, the link discovery is expanded, a function of time delay detection is added, and the cost can be ignored. Firstly, the controller adds the current time as a timestamp to an LLDP packet, that is, the sending time, then the controller sends an OpenFlow message encapsulating the LLDP packet to s1, s1 receives the message and sends the LLDP packet out, according to a flow table mechanism, s1 does not know how to operate (Action) after receiving the LLDP packet, then encapsulates the LLDP packet to the controller, the controller analyzes a timestamp variable from the LLDP packet, the current time is the receiving time, the time delay of three links can be obtained by subtracting the sending time from the receiving time, and the time delay is set as T1This process is represented by the solid arrow in fig. 3. Similarly, the reverse time delay of the three links can be obtained only by changing the direction, and is set as T2This process is represented by the dashed arrow in fig. 3. The RTT (Round-Trip Time) is defined as the Round Trip delay, and then:
T1+T2＝RTTcontroller-s 1+RTTs1-s2+RTTs 2-controller
The controller-to-switch latency needs to be known next.
And secondly, by inquiring the OpenFlow v1.3 protocol standard, the echo message can realize the measurement requirement, the echo message is a symmetric message, the controller and the switch can be actively sent to the other side, the message is simple, one side sends the echo _ request message, the other side replies the echo _ reply message, and the echo message is mainly used for detecting the activity of the equipment at the opposite side.
Thus, in the present embodiment, a time stamp parameter is set in the echo _ request message. When the controller sends an echo _ request message to the switch, the current time is written into a timestamp field, the switch receives the echo _ reply message and sends the echo _ reply message to the controller, and the controller immediately inquires the current time after receiving the echo _ reply message. Thus, there are:
RTTcontroller-switchReceiving-transmitting time stamp
Thus obtaining RTTController-s 1、RTTController-s 2(ii) a In FIG. 3, RTTController-switchThe device is formed by combining an implementation arrow and a dotted arrow in a dotted line frame.
And then the link delay between switch s1 and switch s2 is obtained:
and obtaining the time delay data of the whole network link according to the two steps, and completing the time delay detection of one section of link.
Fig. 4 is a model diagram of a network topology, and under the congestion control mechanism of this embodiment, the bandwidth data and the delay data have small measurement error, high accuracy, and sensitive response, and the following illustrates how the congestion control is implemented by traffic scheduling in this embodiment.
Firstly, there is no traffic in the network, the hop count of each link is 1, the bandwidth is 0, the time delays are approximately equal (a very small default value), h1 sends a data packet to h3, the traffic scheduling module will get through the forwarding path of s1-s2-s5 for this traffic (the controller sends corresponding flow table entries for these switches in turn), and meanwhile, the path for h3 to send a data packet to h1 will also be determined by the traffic scheduling module, that is, it is a reverse forwarding path: s5-s2-s 1. When h2 sends a packet to h3, the traffic scheduling module detects that the forwarding path of s1-s2-s5 bears a large amount of traffic, and then opens the forwarding path of s1-s3-s4-s5 for the flow from h2 to h3, and determines a reverse forwarding path: s5-s4-s3-s 1. Therefore, the function of bandwidth distribution can be realized, and the network congestion condition is greatly relieved.
Further, if the link delay of the link s1-s2 in the current network is increased suddenly due to an emergency, the delay detection module can quickly collect data and provide the data to the traffic scheduling module, and then the traffic scheduling module performs the optimal path forwarding function based on the delay, so that the traffic passing through the link is rerouted to another path. Specifically, the forwarding path from h1 to h3 is deleted first: s1-s2-s5 (the controller issues instructions to these switches to delete the corresponding flow table entry), and then opens the forwarding path of s1-s3-s4-s5 (the controller issues the corresponding flow table entry for these switches in turn). Thus, even if a link suddenly experiences intolerable delay, the congestion control system can detect this and mitigate it through traffic scheduling in a short time.
In this embodiment, the two parameters of the link bandwidth and the link delay are combined to calculate the global optimal path, so that the traffic scheduling is more scientific and reasonable, and the steps are as follows:
ri＝si-bi(i＝1,2,…n)
ci＝αdi-βri
wherein alpha and beta are weight coefficients, the values depend on a specific network model, and can be configured by a network administrator in real time.
And 3, transmitting the set C as an input parameter into a Dijkstra algorithm, and calculating a global optimal path.
In this embodiment, according to the time delay and bandwidth data conditions of each link in the network displayed by the network visualization display module, if congestion is determined to occur, a network administrator selects an appropriate routing rule according to a custom REST API, and schedules the traffic onto a light-load link through the traffic scheduling module to avoid congestion of a certain link, otherwise, forwards the traffic according to the original link.
In the custom REST API, four legitimate requests are defined: firstly, switching a routing rule into hop count; secondly, switching the routing rule into residual bandwidth; thirdly, switching the routing rule into time delay; and fourthly, switching the routing rule into the weight sum of the bandwidth and the time delay. Any of the above requests may be submitted to a server running the controller program to cause a change in the routing rules. The network administrator can freely set routing rules according to the situation, so that the flow scheduling module sequentially issues flow table items for the switches on the selected path, and the network congestion is relieved to the maximum extent.
The above-mentioned embodiments only express several embodiments of the present invention, and the description thereof is more specific and detailed, but not construed as limiting the scope of the present invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present patent shall be subject to the claims.
Claims (8)
1. An OpenFlow technology-based congestion control system, comprising:
the network topology sensing module is used for sensing the topology of the whole network switch and the host; the method comprises the following steps that a network topology perception module perceives a switch by using an LLDP protocol, and perceives a host by using an ARP protocol to obtain a full-network topology, and the specific process is as follows: feeling the switch: when a network is initialized, the controller instructs the switch to send an LLDP data Packet to another switch by issuing a Packet _ out message in an OpenFlow protocol to the switch, the other switch receives the LLDP data Packet, encapsulates the LLDP data Packet into a Packet _ in message, transmits the LLDP data Packet into the controller, and obtains information of the whole network switch through analysis; feeling the host: when a host sends an ARP (address resolution protocol) data Packet to a network, an access switch where the ARP data Packet arrives first does not know how to forward the ARP data Packet, the ARP data Packet is encapsulated into a Packet _ in message and is uploaded to a controller, and then the controller knows that the host is connected with the access switch;
the network bandwidth monitoring module is used for collecting the bandwidth use condition of the whole network link in real time; based on the OpenFlow environment, by using an OFPPortStatsRequest message in an OpenFlow protocol, a controller grasps a bandwidth value of a whole network link, periodically calls a network bandwidth monitoring module, and grasps real-time bandwidth data;
the network delay detection module is used for collecting delay data of the whole network link in real time; adding a timestamp variable in an OpenFlow protocol based on an OpenFlow environment, calculating the link delay of the whole network, periodically calling a network delay detection module, and mastering real-time delay data;
the flow scheduling module is used for dynamically executing a multi-parameter flow scheduling scheme in real time according to the data acquired by the network topology sensing module, the network bandwidth monitoring module and the network delay detection module, and can change a routing rule on line according to the requirement of a network administrator;
the method comprises the following specific steps: the traffic scheduling module calculates the shortest path of the whole network based on the hop count; the flow scheduling module calculates a bandwidth-based full-network optimal path; the traffic scheduling module calculates the optimal path of the whole network based on time delay; taking time delay and bandwidth with different weight ratios as cost values of each link, and calculating a global optimal path by a traffic scheduling module; aiming at the time delay and bandwidth data conditions of each link in the network, a network administrator selects a proper routing rule according to a user-defined requirement, and a flow scheduling module sequentially issues flow table items for the switches on the selected path;
the system also includes two auxiliary modules:
the network visualization display module is used for arranging the network topology obtained by sensing and the network parameters obtained by collecting and then displaying the network topology and the collected network parameters by a graphical interface;
and the network configuration management module is used for designing a set of method for dynamically changing the routing rule based on REST API, configuring a monitoring period and a detection period through an easy-to-operate graphical interface user, and performing custom management on the network visualization display module.
2. An OpenFlow technology-based congestion control method implemented by the OpenFlow technology-based congestion control system according to claim 1, comprising:
(1) acquiring the topology of the whole network and calculating the shortest path of the whole network based on the hop count: calling a network topology sensing module to sense the switch by using an LLDP protocol, and sensing a host by using an ARP protocol to obtain a full-network topology; after the topology of the whole network is obtained, the flow scheduling module calculates the shortest path of the whole network based on the hop count according to the Dijkstra algorithm, because the cost values of all links are equal, the optimal path is equivalent to the shortest path, and the shortest path only depends on the hop count;
(2) monitoring the bandwidth in real time and calculating the optimal path of the whole network based on the bandwidth: by utilizing an OFPPortStatsRequest message in an OpenFlow protocol, a controller acquires a bandwidth value of a whole network link, and periodically calls a network bandwidth monitoring module to acquire real-time bandwidth data; taking the bandwidth data as a cost value of each link, and calculating a bandwidth-based full-network optimal path by a flow scheduling module according to a Dijkstra algorithm;
(3) detecting time delay in real time and calculating the optimal path of the whole network based on the time delay: adding a timestamp variable into an OpenFlow protocol, calculating the link delay of the whole network, periodically calling a network delay detection module, and mastering real-time delay data; taking the time delay data as a cost value of each link, and calculating the time delay-based optimal path of the whole network by the flow scheduling module according to a Dijkstra algorithm;
(4) calculating a global optimal path: taking time delay and bandwidth with different weight ratios as cost values of each link, and calculating a global optimal path by a flow scheduling module according to a Dijkstra algorithm;
(5) selecting a routing rule: aiming at the time delay and bandwidth data conditions of each link in the network, a network administrator selects a proper routing rule according to a self-defined REST API, and a flow scheduling module sequentially issues flow table items for the switches on the selected path, so that the network congestion is relieved to the maximum extent.
3. The OpenFlow technology-based congestion control method according to claim 2, wherein in step (1), the invoking network topology awareness module uses an LLDP protocol to perceive the switch, and uses an ARP protocol to perceive the host, so as to obtain the full network topology, and the specific process is as follows:
feeling the switch: when a network is initialized, the controller instructs the switch to send an LLDP data Packet to another switch by issuing a Packet _ out message in an OpenFlow protocol to the switch, the other switch receives the LLDP data Packet, encapsulates the LLDP data Packet into a Packet _ in message, transmits the LLDP data Packet into the controller, and obtains information of the whole network switch through analysis;
feeling the host: when a host sends an ARP Packet to a network, an access switch where the ARP Packet first arrives does not know how to forward, the ARP Packet is encapsulated in a Packet _ in message and is uploaded to a controller, and the controller knows that the host is connected with the access switch.
4. The OpenFlow technology-based congestion control method according to claim 2, wherein in the step (1), when topology is perceived, the configuration information of each link is obtained to include link capacity;
and after the full-network topology is obtained, the switch is used as a vertex, the link is used as an edge, and the vertex and the link are stored in a graph structure to be used as input parameters of the Dijkstra algorithm.
5. The OpenFlow technology-based congestion control method according to claim 2, wherein in step (2), the controller grasps a bandwidth value of a link in the whole network and periodically calls the network bandwidth monitoring module to grasp real-time bandwidth data by using an OFPPortStatsRequest message in an OpenFlow protocol, and specifically includes the following steps:
(2-1) initializing configuration: after the network topology sensing module acquires the whole network information, the network management module determines the monitoring period;
(2-2) the controller sends an OFPPortStatsRequest request to the full-network switch;
(2-3) after each switch receives the OFPPortStatsRequest request, inquiring the statistical data of all ports of the switch, and then replying to a set including the statistical data of all ports, wherein the number of elements is the number of ports, each element in the set is a structural body called ofp _ port _ stats, and the structural body contains four important data: sending byte number tx _ bytes, receiving byte number rx _ bytes, survival time duration _ sec, and survival nanosecond time duration _ nsec, wherein the four important data are statistical data of the port since initialization; the controller receives the ofp _ port _ stats structure body and stores four important data for calculation;
(2-4) at a certain interval, namely, at an interval period, the controller sends an OFPPortStatsRequest request to the whole-network switch to obtain new port statistical data;
(2-5) calculating port bandwidth data, and calculating the bandwidth value of the port according to the following formula;
wherein the interval period is:
6. the OpenFlow technology-based congestion control method according to claim 2, wherein in step (3), the adding a timestamp variable in an OpenFlow protocol, calculating a link delay of a whole network, periodically calling a network delay detection module, and grasping real-time delay data specifically includes the following steps:
(3-1) obtaining [ controller-switch s 1-switch s 2-controller ] according to the timestamp variable newly added in the LLDP data packet encapsulated in the OpenFlow message]The time delay of the three links is set as T1；
(3-2) according to the principle of the step (3-1) [ controller-switch s 1-switch s 2-controller]Obtaining the reverse time delay of three links, setting as T2Defining RTT as the round trip delay, it is obvious that:
T1+T2＝RTTcontroller-s 1+RTTs1-s2+RTTs 2-controller
(3-3) according to the OpenFlow v1.3 protocol standard, obtaining the round-trip delay from the controller to the switch by adding a timestamp variable newly added by the echo message, wherein the specific process is as follows: setting a timestamp parameter in a message echo _ request sent by a controller, writing the current time into a timestamp field when the controller sends the echo _ request message to a switch, replying the echo _ reply message to the controller when the switch receives the message, and immediately inquiring the current time after the controller receives the message, so that the method comprises the following steps:
RTTcontroller-switchReceiving-transmitting time stamp
Thus obtaining RTTController-s 1、RTTController-s 2；
(3-4) deriving from the above steps, the link delay between switch s1 and switch s 2:
7. the OpenFlow technology-based congestion control method according to claim 2, wherein the step (4) of calculating the global optimal path specifically includes the following steps:
(4-1) assuming that there are n links in the network, let the network link set L: { L:1,l2,…ln{ used bandwidth set of links B: { B1,b2,…bnR, link residual bandwidth set R: { R: }1,r2,…rn{ S, set of link capacities S: }1,s2,…sn{ D } link delay set D: { D1,d2,…dnThe number of the five set elements is equal, the set L and the set S can be obtained by a network topology sensing module, the set B can be obtained by a network bandwidth monitoring module, the set D can be obtained by a network time delay detection module, and each element in the set R is obtained by the following calculation formula:
ri＝si-bi (i＝1,2,...n)
(4-2) set of cost values C of each link: { C1,c2,…cnAnd each element in the set C can be calculated by the following formula:
ci＝αdi-βri
wherein alpha and beta are weight coefficients, the numerical values depend on a specific network model and can be configured by a network administrator in real time;
and (4-3) introducing the set C as an input parameter into a Dijkstra algorithm, and calculating a global optimal path.
8. The OpenFlow technology-based congestion control method according to claim 2, wherein in the step (5), four legal requests are defined in the custom REST API: firstly, switching a routing rule into hop count; secondly, switching the routing rule into bandwidth; thirdly, switching the routing rule into time delay; fourthly, switching the routing rule into the weight sum of the bandwidth and the time delay;
any of the above requests is submitted to a server running a controller program, which can change the routing rule, and the network administrator can freely set the routing rule as the case may be.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910062999.5A CN109756421B (en) | 2019-01-23 | 2019-01-23 | Congestion control system and method based on OpenFlow technology |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910062999.5A CN109756421B (en) | 2019-01-23 | 2019-01-23 | Congestion control system and method based on OpenFlow technology |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109756421A CN109756421A (en) | 2019-05-14 |
| CN109756421B true CN109756421B (en) | 2021-07-16 |
Family
ID=66406066
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910062999.5A Active CN109756421B (en) | 2019-01-23 | 2019-01-23 | Congestion control system and method based on OpenFlow technology |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109756421B (en) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110191065B (en) * | 2019-06-08 | 2022-04-08 | 西安电子科技大学 | High-performance load balancing system and method based on software defined network |
| CN112995036B (en) * | 2019-12-13 | 2023-08-01 | 中盈优创资讯科技有限公司 | Network traffic scheduling method and device |
| CN111835653B (en) * | 2020-07-20 | 2023-10-20 | 浙江亿邦通信科技有限公司 | Control method and system for network traffic load balancing |
| CN116866249A (en) * | 2020-09-08 | 2023-10-10 | 超聚变数字技术有限公司 | Communication system, data processing method and related equipment |
| CN112350949B (en) * | 2020-10-23 | 2022-05-31 | 重庆邮电大学 | Rerouting congestion control method and system based on flow scheduling in software defined network |
| CN112702253A (en) * | 2020-12-11 | 2021-04-23 | 邦彦技术股份有限公司 | MPLS tunnel creating method, system and storage medium based on network link quality |
| US11818046B2 (en) * | 2021-01-26 | 2023-11-14 | Samsung Electronics Co., Ltd. | Coordinated congestion control in network-attached devices |
| CN113472661B (en) * | 2021-06-17 | 2023-07-25 | 中盈优创资讯科技有限公司 | Automatic optimization method and device for network routing cost value |
| CN114650257B (en) * | 2022-03-18 | 2023-07-04 | 南京邮电大学 | SDN network congestion control system and method based on RTT |
| CN114884824B (en) * | 2022-06-09 | 2023-06-16 | 中国联合网络通信集团有限公司 | Method, equipment and system for inquiring delay budget path |
| CN115865759A (en) * | 2023-02-27 | 2023-03-28 | 科来网络技术股份有限公司 | Network equipment time delay obtaining method and system based on flow mirror protocol |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108600102A (en) * | 2018-03-29 | 2018-09-28 | 北京交通大学 | A kind of flexible data Transmission system in the contract network based on wisdom |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107517155A (en) * | 2016-06-15 | 2017-12-26 | 中兴通讯股份有限公司 | A kind of software defined network, node, path calculation method and device |
| CN107135159B (en) * | 2017-03-31 | 2019-11-22 | 武汉绿色网络信息服务有限责任公司 | The method and system that optimal path determines in a kind of SDN network |
| CN107070714B (en) * | 2017-04-10 | 2019-06-21 | 中国人民解放军国防科学技术大学 | A kind of SDN network abnormality monitoring method |
| CN107483337A (en) * | 2017-07-31 | 2017-12-15 | 郑州云海信息技术有限公司 | Determine the method and its network equipment in path |
| CN108881031B (en) * | 2018-06-11 | 2020-09-18 | 云南师范大学 | Self-adaptive reliable data transmission method based on SDN network |
-
2019
- 2019-01-23 CN CN201910062999.5A patent/CN109756421B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108600102A (en) * | 2018-03-29 | 2018-09-28 | 北京交通大学 | A kind of flexible data Transmission system in the contract network based on wisdom |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109756421A (en) | 2019-05-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109756421B (en) | Congestion control system and method based on OpenFlow technology | |
| CN108600102B (en) | Flexible data transmission system based on intelligent cooperative network | |
| Zhang et al. | Load balancing in data center networks: A survey | |
| Su et al. | CeMon: A cost-effective flow monitoring system in software defined networks | |
| Hafeez et al. | Detection and mitigation of congestion in SDN enabled data center networks: A survey | |
| Zats et al. | DeTail: Reducing the flow completion time tail in datacenter networks | |
| US8730806B2 (en) | Congestion control and resource allocation in split architecture networks | |
| US8115617B2 (en) | Alarm reordering to handle alarm storms in large networks | |
| Tahaei et al. | A multi-objective software defined network traffic measurement | |
| US9059922B2 (en) | Network traffic distribution | |
| US10645006B2 (en) | Information system, control apparatus, communication method, and program | |
| CN111526089B (en) | Data fusion transmission and scheduling device based on variable-length granularity | |
| Hu et al. | Adjusting switching granularity of load balancing for heterogeneous datacenter traffic | |
| Wang et al. | A survey of elephant flow detection in SDN | |
| CN102025621A (en) | Routing selection method of cognitive network based on mapping mechanism | |
| CN105262682B (en) | A kind of software defined network system and its traffic grooming method for electric power data communication | |
| Mliki et al. | A comprehensive survey on carrier ethernet congestion management mechanism | |
| Irteza et al. | Efficient load balancing over asymmetric datacenter topologies | |
| Huang et al. | An enhanced scheduling framework for elephant flows in SDN-based data center networks | |
| Hussain et al. | A dynamic multipath scheduling protocol (DMSP) for full performance isolation of links in software defined networking (SDN) | |
| Wang et al. | SDN controller network load balancing approach for cloud computing data center | |
| Farahmand et al. | A closed-loop rate-based contention control for optical burst switched networks | |
| Lin et al. | Proactive multipath routing with a predictive mechanism in software‐defined networks | |
| EP3713164A1 (en) | Data scheduling method and tor switch | |
| Gao et al. | HPLB: High precision load balancing based on in-band network telemetry in data center networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |