# SDN-OpenFlow Topology Discovery: An Overview of Performance Issues
## 3 Recent SDN Topology Discovery Performance Studies
### Link Discovery Improvement Algorithms
#### 3.1.2 Event  
This domain is named by event, because the changes come along each discovery takes place on every event, such as updating, adding, and deleting links. The authors in [38; 76; 87] used this type as we will discuss.  
In different techniques related to improving OpenFlow topology discovery called Secure and Efficient OpenFlow Topology Discovery Protocol (sOFTDP) [38]. The authors in [38] have transferred the control logic for topology discovery and its security from SDN-Controller to SDN-Switch in order to reduce arithmetic operations from SDN-Controller. SDN-Switches are now responsible for monitoring the status of their ports, and they have used Bidirectional Forwarding Detection (BFD) protocol [88] as a mechanism for detecting port vitality. Each SDN-Switch will establish BFD sessions with their neighbors using three-way handshaking. The SDN-Switches then will use the established BFD session to exchange control and echo messages to monitor link vitality. When a link failure occurs, the affected SDN-Switches will detect this failure by BFD and immediately send a notification called BFD-Status message to the SDN-Controller which also immediately removes this link from its links table. For a link addition, asynchronous notifications using the OFPT_Port_Status message will be sent to the SDN-Controller which in turn will discover this link by following the same procedure that is used in OFDP but only for this link. Moreover, port-status messages (OFPT_Port_Status) are sent from the SDN-Switch to the SDN-Controller when a change in port status occurs or when a new port is added, removed, or modified in the SDN-Switch data path.  
The experiments were performed using learning time and CPU utilization performance metrics to evaluate sOFTDP. In link addition, the average learning time for 50 experiments was 5.68 ms while in link removal the learning time was 3.25 ms. Also, they evaluated sOFTDP against standard OFDP and OFDPv2 in terms of CPU utilization of the SDN-Controller throughout 200 s with one topological change in second. The results show that sOFTDP induced the least overhead versus standard OFDP and OFDPv2.  
In the same procedural, the approach called ForCES based optimal network topology discovery [76] was proposed. In ForCES, the authors improved OFDP performance by offloading the SDN-Controller from sending or receiving LLDP advertisements. The LLDP protocol will work as it is and without any modifications. The SDN-Switches transmit LLDP advertisements and build their topology tables without the intervention of the SDN-Controller. Then the SDN-Controller pulls the topology information from the SDN-Switches continuously. This technique has been used in [87] in a small-scale testbed. As a result, this proposal can be beneficial by reducing the learning time, and the affected SDN-Switches will inform the SDN-Controller of this change immediately when a change to the topology occurs. However, this solution has been suggested for SDN networks that use ForCES protocol as a southbound interface but can be used with the logic for OpenFlow networks. Finally, the average time for the SDN-Controller to learn about topology changes is 10 ms which is less than 90% of the learning time in standard OFDP (i.e., 100 ms).