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 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 . The 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 following figure summarizes the organization of this southbound.
...
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 channel implementation of the OpenFlow handshake (the OFChannelHandler, currently in Netty) with 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 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.
...
OpenFlowSwitch, facing north, towards Providers, andOpenFlowSwitchDriver, facing south towards the channel andController
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 of the protocol that require (or should have) little or no intervention from the rest of the system. These include initialization of the OpenFlow handshake and certain forms of sanity checking of incoming/outgoing messages.
Switch States
Switch objects are associated with several types of states that limit the types of actions applicable to it. Two of the primary states tied to a switch are its Channel State, and the ONOS instance's role.
Channel state
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.
Role
The role of an ONOS instance describes its read and write permission regarding the 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.
Roles are discussed further in Clustering.