# SDN-OpenFlow Topology Discovery: An Overview of Performance Issues
## 3 Recent SDN Topology Discovery Performance Studies
### Link Discovery Improvement Algorithms
#### 3.1.1 Periodic

Table 4: Comparison between different proposed approaches to enhance OFDP. egress port. S2 will receive the LLDP packet and encapsulate the LLDP packet with a Packet_In message and send it to the SDN-Controller. The SDN-Controller will parse the incoming Packet_In packet and learn about the new link. Finally, the results show that OFDPv2 uses 63-80% fewer LLDP Packet_Out messages than the same process in standard OFDP. Furthermore, in measuring the CPU overhead between OFDP and OFDPv2, the results show that OFDPv2 reduced the CPU utilization of the SDN-Controller by up to 45% compared to the standard OFDP. Additionally, in [42], the authors presented a lightweight, efficient, and secure approach to discover the links between SDN-Switches in SDN called Secure and Lightweight Link Discovery Protocol (SLDP). In general, the proposal uses a new packet format for link discovery by using minimal features of the frame and removing unnecessary features from the standard LLDP frame. Moreover, for each iteration of the link discovery process, the SDN-Controller will generate an SLDP packet and send it with a random source MAC address to SDN-Switches. Then the SDN-Controller installs a flow entry in each SDN-Switch flow table to generate the packet with that random source and agree to these values when a message is returned to the SDN-Controller. In brief, the SDN-Controller will initially send an SLDP packet to each SDN-Switch port in the network, and the subsequent discovery iterations will only receive ports that are eligible for SLDP packets. As result, only legitimate SLDP packets will be sent to the SDN-Controller to build the topology and this will reduce the number of packets used in the discovery process and prevent unqualified ports from receiving SLDP packets. In evaluation metrics, the authors used the Mininet emulator and compared it to the OFDP in various network topologies with different numbers of SDN-Switches, hosts, and links. Moreover, they used the number of packets sent by the SDN-Controller, CPU of the SDN-Controller, and validation time. For all of these metrics, SLDP outperforms the standard OFDP. Moreover, [43], the authors proposed another approach called Efficient and Secure Link discovery scheme (ESLD) by also limiting the transmission of LLDP packets to SDN-Switch ports connected to SDN-Switches. This approach is illustrated in Figure 9.  
The basic idea of the ESLD is to classify SDN-Switch ports into two classes, either 'Switch' or 'Host'. 'Switch' ports are those ports connected to SDN-Switches and 'host' ports connected to users. Moreover, ESLD uses some well-known OpenFlow messages such as 'Feature-Replay', 'State-Reply', and 'Port-Status' messages to label these ports in both types ('Host' or 'Switch'). Therefore, the efficiency of ESLD is directly dependent on the number of SDN-Switch ports in SDN. For evaluation, the authors used a host scale in different scenarios with different topologies and compared ESLD to the de facto OFDP  
Figure 9: ESLD methodology. and OFDPv2. Moreover, a number of LLDP packets handled by the SDN-Controller, CPU utilization for SDN-Controller, and SDN-Switches were used as performance metrics. In a different study, the authors suggested two new applications of the OFDP to improve the link discovery process: the Enhanced Topology Discovery Service (ETDP-SDN) and the ETDP-Hybrid [45]. In ETDP-SDN, the Discovery Service is centralized inside the SDN-Controller, and the SDN-Controller identifies each iteration of the root SDN-Switch and then sends an ETDP discovery packet to the root SDN-Switch. SDN-Switch will in turn flood this packet to all of its ports except for the port where ETDP is received. Next, the SDN-Controller installs a flow rule to force SDN-Switch to send a Packet_In to the SDN-Controller and another flow rule to flood the ETDP frame. Next, after the SDN-Controller receives the Packet_In message, it will send an additional FLOW_Mod to remove the flood rule, which was previously installed to prevent loops.