Distributed Traffic Matrix Measurement in Software-Defined Networks

The creation and development of new protocols in computer networks is not an easy task. Accessibility to the source code of the devices and permission of the network administrators are necessary in order to carry out tests of new protocols. Besides, network administrators do not allow experimenting on their networks because they are afraid of possible tests that can deteriorate their service. Software-Defined Networks (SDN) appear to be the solution to these problems. SDN separates the control and forwarding planes of a network switch or router, allows a centralized management of the devices, and thus easies complex tasks that involve all the nodes of a network, such as load balancing or traffic engineering. One of the classical problems in networking is how to obtain the traffic matrix (TM) of the network. The TM represents the demand from the network users, and is a key parameter for any activity related to network planning, dimensioning, and operation. In legacy IP networks TMs are not easy to obtain. The estimation of the TM involves gathering simultaneously traffic measurements and routing information, and correlating them in a meaningful way. The main contribution of this thesis is the development of a distributed architecture that takes advantage of the SDN architecture for obtaining the TM in a distributed manner. In our approach every switch is responsible of calculating a fraction of the traffic matrix: the flows that ingress the network through this specific node. In this manner, the overhead due to packet flooding and CPU usage at the SDN controller is avoided. We extended OpenFlow protocol with new messages, and modified the firmware of the devices and the code of the controller in order to handle them. We implemented and evaluated the approach in a testbed with low-end devices (low-cost Linux-powered routers with OpenFlow capabilities), obtaining good results. The traffic matrix can be measured without delays even with a large amount of traffic. We analysed the new OpenFlow messages and noticed that some improvement can be done for avoiding even more unnecessary CPU usage at the controller