LinkDiscoveryModule
| ModuleTypeID (hex) | 0x0005 |
|---|---|
| ModuleTypeID (decimal) | 5 |
| Distribution support | single instance |
| Dependencies | SwitchRegistryModule |
The LinkDiscoveryModule detects and knows all links between switches in the SDN-network and each links properties. These links are directed, meaning there will be two directed links for each bidirectional connection between switches. It also detects broken links.
The configuration file for this module must define the following variable:
Config variable: ZSDN_LINK_DISCOVERY_MODULE_UPDATE_CYCLE
Type: Integer
Description: Frequency of link discovery messages sent to the network (milliseconds). A higher value increases link establish/failure detection rate but may impact performance.
Queries all links between switches known to the LinkDiscoveryModule. The Reply contains 0 or more SwitchToSwitchLinks.
| Request-MessageType | [[REQUEST.LINK_DISCOVERY_MODULE.GET_ALL_SWITCH_LINKS |
| Request-Payload | [[Request-Container |
| Reply-MessageType | [[REPLY.LINK_DISCOVERY_MODULE.GET_ALL_SWITCH_LINKS |
| Reply-Payload | [[Reply-Container |
Queries all SwitchToSwitchLinks coming from the switch given in the request. In other words, this will return all outgoing links of the given switch. If no switch with the given switch_dpid exists, the reply will have the switchExists field set to false, and 0 links are returned. If a switch with the given switch_dpid exists, switchExists will be set to true, and 0 to n links are returned.
| Request-MessageType | [[REQUEST.LINK_DISCOVERY_MODULE.GET_LINKS_FROM_SWITCH |
| Request-Payload | [[Request-Container |
| Reply-MessageType | [[REPLY.LINK_DISCOVERY_MODULE.GET_LINKS_FROM_SWITCH |
| Reply-Payload | [[Reply-Container |
Queries all SwitchToSwitchLinks ending at the switch given in the request. In other words, this will return all incoming links of the given switch. If no switch with the given switch_dpid exists, the reply will have the switchExists field set to false, and 0 links are returned. If a switch with the given switch_dpid exists, switchExists will be set to true, and 0 to n links are returned.
| Request-MessageType | [[REQUEST.LINK_DISCOVERY_MODULE.GET_LINKS_TO_SWITCH |
| Request-Payload | [[Request-Container |
| Reply-MessageType | [[REPLY.LINK_DISCOVERY_MODULE.GET_LINKS_TO_SWITCH |
| Reply-Payload | [[Reply-Container |
Queries all SwitchToSwitchLinks ending at AND coming from the switch given in the Request. In other words, this will return all incoming AND outgoing links of the given switch. If no switch with the given switch_dpid exists, the reply will have the switchExists field set to false, and 0 links are returned. If a switch with the given switch_dpid exists, switchExists will be set to true, and 0 to n incoming and 0 to n outgoing links are returned.
| Request-MessageType | [[REQUEST.LINK_DISCOVERY_MODULE.GET_ALL_LINKS_OF_SWITCH |
| Request-Payload | [[Request-Container |
| Reply-MessageType | [[REPLY.LINK_DISCOVERY_MODULE.GET_ALL_LINKS_OF_SWITCH |
| Reply-Payload | [[Reply-Container |
Queries the LinkDiscoveryModule if there are links between two Switches (Switch_A -> Switch_B and/or Switch_B -> Switch_A). If one or both of the switches do not exist, both_switches_exist will be set to false, and 0 links are returned. If both switches exist, 0 to n links from switch a to switch b as well as 0 to n links from switch b to switch a will be returned. Since switches could be connected witch each other by multiple links, the result may contain more than one link in each direction.
| Request-MessageType | [[REQUEST.LINK_DISCOVERY_MODULE.GET_LINKS_BETWEEN_TWO_SWITCHES |
| Request-Payload | [[Request-Container |
| Reply-MessageType | [[REPLY.LINK_DISCOVERY_MODULE.GET_LINKS_BETWEEN_TWO_SWITCHES |
| Reply-Payload | [[Reply-Container |
When a switchLink is added or removed, an event of this type is published.
| From-MessageType | [[FROM.LINK_DISCOVERY_MODULE.SWITCH_LINK_EVENT.*(ADDED/REMOVED) |
| From-Payload | [[From-Container |
For a detailed list of all supported topics, see the LinkDiscoveryModule.topics file.
Regularly (Once a second default, but configurable) send out custom-packets (Currently uses custom packets with the custom ethertype 0x511, LLDP implementation pending) to all switches, all ports. obtain all switches from SwitchRegistryModule, and subscribe for changesEvents of switches.
The packet contains custom payload (prefer protobuffer over custom binary format. containing unique ID, senderAttachmentPoint, timestamp (can optionally use to measure latency) create LinkDiscoveryModuleInternal.proto, importing CommonTopology.proto,
this has a message, e.g.
message LinkDiscoveryMessage {
required uint64 uniqueId = 1;
required common.topology.AttachmentPoint senderAttachmentPoint = 2;
required uint64 sendTimestamp = 3;
}Switches will send it back to controller. From the info of the payload and the PacketIn message, a link can be figured out. Sends Linkchangeevents accordingly if new results differ from old results. Doesn't immediately assume a link to be down but declares it down after x unsuccessful tries. Further versions may also subscribe to openflow-port-status events sent by switches, which could be used to react very fast to a link down. For now, we wanted a stable, probably slow reacting but reliable solution.
MessageType: FROM.SWITCH_ADAPTER.OPENFLOW.PACKET_IN.CUSTOM(0x511F)
Comment: Receiving 0x511F-packets send by this module to the switches.
MessageType: FROM.SWITCH_REGISTRY_MODULE.SWITCH_EVENT.*(ADDED/REMOVED/CHANGED
Comment: Update local Switch cache.
MessageType: TO.SWITCH_ADAPTER.SWITCH_INSTANCE(switchID).OPENFLOW.PACKET_OUT
Comment: Flooding LLDP-packets into the network to discover links between switches.