Improved topology Discovery performance for SDN controllers (through improved logic)

Recently do experiments, found that Ryu topology discovery performance is not high, so read the Ryu Topology Discovery source code, consulted related papers, improved Ryu topology discovery performance, rewrite the code, and re-did the experiment, found that improved topology discovery module capabilities have been enhanced, but there are limitations, Now first to summarize the work ahead, there is time to continue to improve.

I. LLDP topology Discovery principle

The link discovery protocol in the traditional network is LLDP (link Layer Discovery Protocol), LLDP allows nodes in the LAN to tell other nodes his own capabilities and neighbours. In a traditional Ethernet switch, the switch sends LLDP packets from each of its own ports, he will not be forwarded by other switches, the lifetime is only one hop, the LLDP load is encapsulated in the Ethernet frame, the structure is, where the dark gray is the LLDP load, Chassis ID TLV, Port ID TLV and time to live TLV three are mandatory fields, each representing the switch identifier (unique in the LAN), Port number, and TTL. When this data is sent out and parsed by neighbor nodes, it is possible to know the source destination switch of the link and the source destination interface.

Two. Ryu Topology Discovery principle

OpenFlow's official does not prescribe a standard topology discovery method, now OFDP (OpenFlow Discovery Protocol) is still using the Link Discovery Protocol LLDP in the traditional network, and then introduces Ryu how to use LLDP to discover the topology, Suppose there are now two OpenFlow switches connected to the controller, such as a brief description of the topology Discovery step (similar to S1 as the principal, S2):

1. The SDN controller constructs a PACKETOUT message to send the LLDP packets shown to the S1 three ports, where chassis ID TLV and Port ID TLV are respectively S1 and port numbers
2. The controller sends a stream table to the switch S1, and the Flow table rule is: Send the LLDP packet received from the controller port from his corresponding port
3. The controller sends a stream table to the switch S2, and the flow table rule is to send the LLDP data packets from the non-controller to the controller
4. The controller knows the destination switch and the destination interface by parsing the LLDP packet, getting the source switch of the link, the source interface, and the received Packetin message.

Three. Existing problems and room for improvement

Now the Ryu discovery topology is the entire data plane of all the switches on all the ports to send packetout packets, for the fattree and other networks, the number of ports is the number of switches k times, resulting in a lot of resource consumption, I use small server run simple topology link discovery function, Will often go down or find the topology is not complete, and if the message too much can cause broken pipe problem, so can the topology discovery mechanism to improve, so that the number of PACKETOUT messages and switches sent the same amount?

Four. Improved topology discovery mechanism of Ryu

In order to implement the logic improvements mentioned in the three, it is necessary to improve the port ID TLV in the LLDP payload, or there are other domain and port ID TLV one by one mappings available, here is a workaround, when the LLDP packet is forwarded from the switch port, Replace the source MAC address of this Ethernet packet with the MAC address of the port, and the controller has obtained all the information about the port of the switch in the previous configuration phase, so for the controller, the MAC address and the switch port number is one by one corresponding, the following detail describes the improvement scheme.

1. Update the number of LLDP packetout messages for the controller by one port, change one packetout message to a switch, LLDP the domain port ID TLV value in the packet payload to zero
2. The controller sends a rule to the flow table that all LLDP messages received from the port controller are flood to the other ports in addition to the controller, while the source MAC address of the Ethernet data frame is set to the MAC address of the corresponding port
3. Update the Packetin message processing mechanism of the controller, according to the source of the LLDP packet, can get the destination switch, the destination port, by parsing the LLDP packet, get the source Mac and the source switch, find the corresponding port number through the source MAC address
4. Because it is a modified code, do not forget to delete the original port-led related code

Add primary variables and classes to do an introduction

• Self.switches: is a dictionary that stores dpid to swithdata mappings
• Switchdata class: Contains the timestamp and the LLDP data that the switch contains
• Switchdatastate: Similar to the Portdatastate class, inherits from the dictionary, saves the mappings from the switch class to the Switchdata class, maintains a data structure similar to a doubly linked list

Modified the source switches.py file, the modified see github:https://github.com/cotyb/enhancement-ryu/tree/master/ryu%20topology% 20enhancement, after the experiment found that the topology discovery capability has been enhanced, but the performance of what still needs to continue to improve, there is time to continue to improve

Reference: Ef?cient topology Discovery in SDN

Improved topology Discovery performance for SDN controllers (through improved logic)