Demo Case
- The Centralized Network Control of Software-defined Networking (SDN)
- A Bandwidth Reservation Policy Applied for Network Flows on a LAN
Scenario
Centralized network control is one feature of software-defined networking (SDN) technology. In traditional networks, the network control ability is distributed among all network switches. Swithes communicate with each other to achieve the functionality of networking. In other words, a traditional network adopts distributed network control. In SDN networks, the network control ability is centralized in a network controller. The controller is connected with all switches through the control plane network. Because it has the global view of all switches’ configuration, status, and statistics, it is able to use the whole network information for analyzing network situations and making decisions of network control. It then can simultaneously control all switches to execute its decisions.
In this example case, we deploy a network with 25 SDN switches. The 25 switches are connected to a controller through the control plane network. The controller controls the switches by OpenFlow protocol. Regarding the control ability, the controller is run up with the capabilities of MAC address learning and spanning tree protocol. On the data plane network, we arrange the upper-left host to be the network message sender while the bottom-right host to be the receiver. During the simulation, the SDN switches and the control communicate frequently by using OpenFlow protocol messages. The controller, which has the whole network view, performs centralized network control to set up a communication path between the sender and the receiver.
Applicable Version : ( ) Free Trial Version ( ) Book Card Version (v) Purchase Version
Download
1. Click here to download the configuration files of this demo case.
Scenario
The network bandwidth provided by a wired/wireless network link is limited. When a network flow passes through the network link, it consumes some or all of the limited network bandwidth. Usually, the network administrators do not manage the bandwidth usage of each flow because manually changing network devices’ setting on demand is error-prone and the response time to demands is usually too long to satisfy needs on time. In the case that several flows pass through the same link, consume all the limited bandwidth and each flow still needs more bandwidth, the bandwidth bottleneck occurs at the entrance of the congested link.
In the following demo video, eight traffic-source nodes from Internet generate eight traffic flows to those eight traffic-destination nodes, located at a local area network (LAN), separately (i.e., node 11 to node 1, node 12 to node 2, node 13 to node 3, and so on). Because the total link bandwidth from Internet is 80 Mbps (10 Mbps * 8 links) and the wired link bandwidth of the LAN is 1000 Mbps, no bandwidth bottleneck occurs at the entrance into the LAN. However, the wireless link bandwidth of the LAN is only 25 Mbps and is less than 80 Mbps. This causes the bandwidth bottleneck at the entrance into the wireless link. Because of the bandwidth bottleneck, the network packets sent from the eight traffic-source nodes are randomly dropped at the entrance into the wireless link (i.e., the access point device). As a consequence, the obtained receiving throughput of each traffic-destination node is unstable. The unstable receiving throughput may result in poor user experience on some real-time network applications, such as on-line video, video conference, etc.
To avoid the situation of unstable receiving throughput, one solution is to manage the bandwidth usage of each network flow. On an OpenFlow switch device, two ways can be used to control the bandwidth usage of each network flow. One is to use meter table and the other is to use the per-port output queues.
In the following demo video, we display an example case that has almost the same network topology as the one mentioned above. The only difference is that we replace the legacy switch in the LAN by an OpenFlow switch, to which an SDN controller is connected. To provide a QoS service to the traffic-destination nodes, we classify them into three groups: the guaranteed group, the fairly-shared group, and the contended group. The total quantum of bandwidth of the wireless link (i.e., 25 Mbps) is assigned to these three groups: 10 Mbps for the guaranteed group, 12 Mbps for the fairly-shared group, and 3 Mbps for the contended group.
For those nodes belonging to the guaranteed group, we want to reserve fixed quantum of bandwidth to each one. In this example case, 6 Mbps is reserved for Node 1 and 4 Mbps is reserved for Node 2. For those nodes belonging to the fairly-shared group, we want them to fairly share the assigned quantum of bandwidth. In this case, Node 3, Node 4, Node 5, and Node 6 belong to this group and each of them should obtain 3 Mbps (12/4). For those nodes belonging to the contended group, no bandwidth reservation is applied for everyone. In other words, all of them have to contend the allocated bandwidth of this group.
An SDN controller software (Ryu) is run up during the simulation with its restful north-bound interface being opened. We execute a script file to insert flow rules to the OpenFlow switch through the restful interface. We use one flow table and seven per-port output queues to realize the QoS service/scenario described above. From the simulation result, we can see that all those nodes applied with bandwidth reservation obtain the expected and stable receiving throughput (in KB/sec), and those nodes belonging to the contended group still obtain unstable throughput.
As mentioned at the beginning, manually changing network devices’ setting on demand is error-prone and the response time to demands is usually too long to satisfy needs on time. These problems can be solved by developing an intelligent SDN controller APP. A network administrator just has to classify users and assign their allowed quantum of bandwidth usage on the APP in advance. This APP is able to automatically detect the target network flows and automatically configure the OpenFlow switch to guarantee the bandwidth usage for each target flow.
Although we do not deploy such SDN controller APP in our example case, EstiNet Technologies Inc. do have this kind of product in its Enterprise SDN solution. For more information, please click the following link to visit the related product web pages.
