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.
...
The Device subsystem follows the architecture described in System Components, with a featuring:
- A
DeviceManagercapable of interfacing with multipleProvidersand listeners via aDeviceServiceinterface DeviceProviders,
...
- each with support of their own network protocol libraries or means to interface with the network
- A
DeviceStore, which tracks Device model objects and generatesDeviceEvents
. This section focuses on the aptly named OpenFlowDeviceProvider, used by ONOS to interact with OpenFlow networks. The OpticalConfigProvider, used to read in network configurations for optical networks, will be described as part of the [Packet Optical use case].
...
Note: "OF" is shorthand for "OpenFlow". For example, the actual name of OFSwitch above is OpenFlowSwitch.
Exceptions will be noted when they crop up.
Not shown above are how there are (currently) three switch maps for Switch objects in various states,
and the entry points for the other subsystems.
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. The red and pink blocks highlight the components that directly play a role in communicating with the infrastructure via TCP connections.
...
Switch objects are associated with several types of states that limit . Each state has a set of behaviors associated with it, e.g. the types of actions applicable to itcontrol messages that a Switch expects to receive or send. Two of the primary states tied to a switch Switch are its Channel State, and the ONOS instance's role.
The OFChannelHandler implements the channel state FSM in the ChannelState Enum. Each enum value represents the various points in the OpenFlow handshake. The following flowchart represents this FSM.
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.
The role of an ONOS instance describes its read and write permission regarding the a Switch object. In the multi-instance setting, one ONOS instance will be a Master with full control over the network switch, and the rest will be Equals only capable of reading state information from a network switch. The roles are enforced both at the OpenFlowSwitchDriver level by the RoleManager (not shown), and at a protocol-neutral level by the Cluster Subsystem.
...
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.