Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Links are discovered on a hop-by-hop basis using probe frames sent out of all controlled devices on all ports. The device ID of the sending device is added to the probe, to identify one end of a link. The other end is found once a neighboring device receives the probe, sending it back to the controller. For example, given devices A and B which are controlled by the same controller and connected together by a direct link, the link from A to B is found via the following steps:

  1. The controller constructs a probe containing A's device ID.
  2. The controller sends down a PacketOut directive with the probe as the payload.
  3. A receives the directive and sends the probe out on all of its ports.
  4. B receives A's probe, and sends it back to the controller.
  5. The controller receives the probe that it had sent from A, from B. It has found one network hop.

The same step of events allow the controller to find the reverse link direction, from B to A. Links are found one direction at a time, as links cannot be assumed to be bidirectional.

The Link Subsystem interfaces with the Device subsystem via a LLDPLinkProvider that subscribes to the DeviceService for DeviceEvents (i.e. by implementing a DeviceListener), and polling for information about OpenFlow-capable Devices. The LLDPLinkProvider allocates a LinkDiscovery object per discovered Device.

LinkDiscovery implements the actual mechanism for link discovery via LLDP and BDDP messages. Every proberate milliseconds (default 3000ms), a LinkDiscovery instance sends out probe messages containing LLDPs and BDDPs, as PacketOuts via the Device that it is paired with. A probe message intercepted at an adjacent switch is passed, as PacketIns, to their corresponding LinkDiscovery instance, which corresponds the sender and receiver of the probe message as the source and destination endpoints of a directed link.

Legacy networks

SDN islands and legacy networks

SDN islands are subsections of networks that are SDN controlled. Each island my have one or more hops through a legacy network in between it and another island.

LLDP probes are dropped after one network hop . This is true for on both SDN controlled and legacy networks, and . This may prevent connections between two controlled network islands with a legacy network in between from being discovered, causing a controller to believe that it is managing two disjoint networks. ONOS, like Floodlight, uses BDDP probes to discover paths between islands. While legacy devices do not drop LLDPsBDDPs, they also do not mark them in any way, i.e., they behave as transparent relays. Therefore, connections across legacy networks will appear as single hops regardless of how many legacy devices may be along that path.


Control domains

Multiple independent control planes control neighboring sections of network in a multi-domain setting. These scenarios Domains differ from the network islands, in that the previous section, which latter are controlled by one logical control plane. In this casethe former, a controller might receive probes that have originated outside of its domainit (or its cluster, in the case of clustered control planes like ONOS) had not created. These probes mark the location of network edge links that demarcatewhere a control plane's influence ends and another's begin. 

A problematic case involves probes from outside devices whose ID(s) are found within the domain (ID aliasing). Other than under special circumstances (e.g. the probe arrives before the domain's own device is discovered, or the recipient of the probe is the one being aliased), ID aliasing is difficult to detect, and leads to wrongly reported links.

ONOS employs per-logical instance -control-plane fingerprints to identify its own cluster. Since ONOS 1.4, the ability to add fingerprint information to probe messages has been added to the LLDPLinkProvider, to aid in the identification of foreign devices and ID aliasing.

Host Discovery

The Device Subsystem discovers network end-hosts via ARP and DHCP messages detected as PacketIns, and describes their locations in the network in terms of Device-Port pairs referred to as ConnectPoints. The HostLocationProvider implements this function by implementing a DeviceListener in a similar vein as the LLDPLinkProvider.