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 Subsystem
The following figure summarizes the key components of the OpenFlow southbound , is comprised of the OpenFlowDeviceProvider and the OpenFlow driver components. While not a subsystem in the ONOS Service 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 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.
Note: "OF" is shorthand for "OpenFlow". For example, the actual name of OFSwitch above is OpenFlowSwitch.
Exceptions will be noted when they crop up.
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.
The OpenFlow Controller
The OpenFlow functions are orchestrated through the OpenFlowController (OFController in the above figure). This component stores mapping of switch DPID to OpenFlowSwitch objects, and generates OpenFlow events that listeners (providers) may subscribe to. Providers may subscribe as one or more of the following listeners:
OpenFlowSwitchListener- A listener for switch events, e.g. switches connecting and disconnecting. Examples:OpenFlowDeviceProvider,OpenFlowLinkProvider.OpenFlowEventListener- A listener for OpenFlow messages. Example: theOpenFlowRuleProvider.PacketListener- A listener for incoming traffic packets (PacketIns). Examples:OpenFlowPacketProvider,OpenFlowLinkProvider,OpenFlowHostProvider.
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).
The OpenFlow Switch Object
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.
A Switch object has two types of interfaces:
OpenFlowSwitch, facing north, towards Providers, andOpenFlowSwitchDriver, facing south towards the channel andController
In general, the 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.