Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
Recall that ONOS represents various network components and properties as protocol-agnostic model objects at the core tier, and as protocol-specific objects at the provider tier. The following are the major representations translated across the two tiers:
| DeviceManager | OpenFlowDeviceProvider |
|---|---|
Device | OpenFlowSwitch |
DeviceId/ElementId | Dpid |
Port | OFPortDesc |
MastershipRole | RoleState |
The OpenFlow Subsystem
The OpenFlow southbound is comprised of the OpenFlowDeviceProvider and the OpenFlow driver components. While not a subsystem in the ONOS subsystem sense, we will refer to these components collectively as the OpenFlow subsystem. The OpenFlow subsystem implements the controller-side behavior of the OpenFlow protocol using the Java protocol bindings generated with Loxi. As such, the currently supported protocol versions are 1.0 and 1.3, the former with Nicira vendor extensions to add role negotiation functionalities.
...
The blue and green blocks correspond to the Provider Component and Provider in the figure under Subsystem Structure. The red and pink blocks and those with with red outlines represent the constituents of the red block labeled 'Protocols' in the same figure(Subsystem Structure). The red and pink blocks highlight the components that directly play a role in communicating with the infrastructure via TCP connections.
...
The state transitions for this FSM are driven by the reception of various OpenFlow messages during the handshake, which are defined in the OpenFlow specifications. Driver-specific aspects of the handshake, such as the exchange of barrier messages by some 1.3 switches, are implemented per OFSwitchImpl* class for the specific type of switch.
...
Roles are discussed further in Cluster Coordination.
Network Discovery
As the subsystem charged with the management of a key model object, the Device subsystem is integral to network discovery, which includes link, topology, and host discovery.
Link Discovery
The Link Subsystem interfaces with the Device subsystem with 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.
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.
...
Previous : Representing Networks
Next : Clustering
...