Page History

...

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.

...

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:

...

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 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 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, 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 (the OFChannelHandler, currently in Netty) to an incoming 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 the details of the protocol that require (or should have) little or no intervention from the rest of the system. These include parts of the OpenFlow handshake unique to various types of switch, and certain forms of sanity checking of incoming/outgoing messages.

Switch States

Switch objects are associated with several types of states. Each state has a set of behaviors associated with it, e.g. the types of control messages that a Switch expects to receive or send. Two of the primary states tied to a Switch are its Channel State, and the ONOS instance's role. 

...

Roles are discussed further in Cluster Coordination.

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.

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.

...