# Software Defined Wireless Mesh Network Flat Distribution Control Plane
## 6 The Controller Traffic Overhead  
Controller load and performance is a critical factor of SDN scalability. Since the topology discovery service in the SDN controller is running periodically, it is important to calculate and know the load this service exploits the controller. As was mentioned above, the FD-SDWMN architecture offers the appropriate environment for applying topology discovery based on LDDP. Due to the current topology discovery mechanism, the controller load depends on the number of Packet-Out messages that the controller should send addition to the number of Packet-In messages received. Discovering a local domain topology is not different from the state-of-the-art mechanism. In every discovery cycle, the amount of received LDDP Packet-In (\(\mathrm{PKT}_{\mathrm{IN}}\)) messages by a controller depends on the number of nodes a local domain has. Actually, it is twice the amount of active inter-router links within the domain, a packet per each link direction. On the other hand, the total amount of LLDP Packet-Out (\(\mathrm{PKT}_{\mathrm{OUT}}\)) messages sent by the controller every cycle is equal to the total number of switches. With N being the number of switches the domain has and L the number of inter-switch links, similarly to a single controller single-hop architecture, the number of messages in/out of the controller can be expressed as follows:  
For the current mechanism (OFDPv2):  
\[\mathrm{PKT}_{\mathrm{IN}}=2\mathrm{L} \tag{1}\]  
\[\mathrm{PKT}_{\mathrm{OUT}}=\mathrm{N} \tag{2}\]  
A significant reduction of the LLDP Packet-In and Packet-Out message numbers for the entire network topology discovery can be achieved in every controller of the FD-SDWMN architecture when discovering entire network topology using the aggregated topology discovery mechanism. The controller load can be calculated in two stages: firstly, when discovering links between local domain switches, depending on the number of domain members. Secondly, the load of aggregating the other neighbors' local domain's topology information as an event-driven message for each domain using connectivity agents of AMQP, depending on the performance of the AMQP system. Figure 6: LLDP packet format for quality of service (QoS) monitoring. With \(\rm{N_{Local}}\) being the number of local domain switches, \(\rm{L_{Local}}\) the number of inter-local domain links, \(\rm{M(AMQP)}\)  the number of messages exchanged by connectivity agents, the number of messages in/out of the controller can be expressed as follows:  
\[\rm{PKT_{IN}=2L_{Local}+M(AMQP)\left(L_{LC}<L\right)} \tag{3}\]  
\[\rm{PKT_{OUT}=N_{Local}+M(AMQP)\left(N_{LC}<N\right)} \tag{4}\]  
Together with the FD-SDWMN architecture, this adapts a suitable environment to apply current topology discovery in WMN. Moreover, it reduces the load of the controller. It reduces the number of the direct topology discovery message i.e., Packet-In and Packet-Out messages, and after AMQP starts, the connectivity agents send the topological information messages on-demand. Then the load calculation of direct discovery messages in the controller depends only on the number of the switches of the domain it controls instead of the entire network's switches, in addition to the load of messages exchanged by the connectivity agents between a particular controller and peering controllers that are distributed over WMN. Since the number of switches and their ports is the key parameter that impacts the controller load in OFDP [22], the aggregated mechanism can be compared with OFDPv2 to see how much it has improved the topology discovery load on the controller.