Network Discovery

Overview

Given certain types of devices, links, and hosts, the network topology may be discovered by ONOS with little administrator intervention. An example is a device that is configured to connect automatically to a specified controller using a protocol such as OpenFlow. When it establishes a connection with the latter, it will 'see' the device and add it to its view of the network. Depending on the protocol used to establish this connection, further information, such as device capability and number of ports, may also be conveyed to the controller through a series of messages in a handshake.

In order to discover links and hosts, ONOS relies on the ability to collect information from, and to configure, network devices. This section focuses on the discovery of those elements, given that ONOS already has control over the devices. The details of how ONOS discovers and interacts with devices are discussed in the Device Subsystem.

Link Discovery

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.

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

LLDP probes are dropped after one network hop. This is true for both SDN controlled and legacy networks, and may prevent connections between two controlled network islands with a legacy network in between from being discovered. ONOS, like Floodlight, uses BDDP probes to discover paths between islands. While legacy devices do not drop LLDPs, 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.

Multiple ONOS clusters

Multiple independent control planes control neighboring sections of network in a multi-domain setting. These scenarios differ from the network islands in the previous section, which are controlled by one logical control plane. In this case, a controller might receive probes that have originated outside of its domain. These probes mark network edge links. 

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 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.