This section describes the function and structure of the Device subsystem, including a detailed look at the OpenFlow facilities.
Overview
The Device subsystem is responsible for discovering and tracking the devices that comprise the network, and for enabling operators and applications to control them. Most of ONOS's core subsystems rely on the the Device and Port model objects created and managed by this subsystem, and/or its provider for interacting with the network.
The Device subsystem follows the architecture described in System Components, with a DeviceManager
capable of interfacing with multiple DeviceProviders
, each with support of their own network protocol libraries or means to interface with the network. 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].
Model Objects and Provider Representations
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. 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.