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 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.
The OpenFlow Controller
The OpenFlow functions are orchestrated through the OpenFlowController (OFController in the above figure). This component stores mapping of switch DPID to references to OpenFlowSwitch objects, and generates OpenFlow events that listeners (providers) may subscribe to. Providers may subscribe as one or more of the following listeners:
...
The OpenFlowController is also responsible for establishing, associating, and managing the communication channels for each of the Switch objects that it learns about. Connections are established by the Controller, and the state of each connected switch is kept track of by the OpenFlowSwitchAgent. Specifically, Controller associates a TCP OpenFlow channel implementation of the OpenFlow handshake (the OFChannelHandler, currently in Netty) with to an incoming OpenFlow connection by creating a Switch object with a reference to the TCP connection (labeled "Channel" above).
OpenFlow Switch Objects
The OpenFlow Switch object is the OpenFlow subsystem's representation of a network device, complete with a set of ports, unique identifier, device information, and a channel reference to the actual device connected on the other side. It is a composite of multiple interfaces, implemented as a series of OFSwitchImpl* classes. Each such implementation represents a type of OpenFlow-capable switch; for example, OFSwitchImplOVS10 is a representation of an OpenVSwitch supporting OpenFlow 1.0. A single instance of a Switch object represents a single OpenFlow connection from the network.
...
In general, the first interface allows providers (and indirectly, the rest of ONOS) to interact with the Switch object, and second interface deals with aspects the details of the protocol that require (or should have) little or no intervention from the rest of the system. These include initialization parts of the OpenFlow handshake unique to various types of switch, and certain forms of sanity checking of incoming/outgoing messages.
...
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.
Driver-specific handshakes The state transitions 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.
...
Roles are discussed further in Clustering.
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.