This section describes how ONOS internally represents the infrastructure under its control.
ONOS maintains protocol-agnostic and protocol-specific network element and state representations that can be translated from one to the other. The former are constructs of the core tier, referred to as Model Objects, and the latter are constructs of the appropriate provider. For example,
DeviceStore (and consequently the
DeviceListeners) sees a network device as a
Device, whereas the
OpenFlowDeviceProvider will see the device as an
OpenFlowSwitch. Recall that these two representations are bridged across the provider and core layers by the intermediate transcription into a
DeviceDescription. Model Objects are what ONOS exposes to its applications.
Additionally, wherever possible, rich data types are used instead of Java primitives for disambiguation and clarity. For example, IP Addresses are described by the
IPAddress class, as opposed to an
int, and MAC addresses, with
MACAddress, rather than a
long.These rich data types provide methods to convert the object into analogous primitives where needed.
The rest of this section focuses on the Model Objects.
The interface definitions and implementations of these objects can be found across several packages under [org.onosproject.net.*]. While not formal, implicit object classifications fall out of the organization of these packages.Note that the following list is not comprehensive.
Many of the model objects have graph analogues, as ONOS represents networks as directed graphs.
DeviceId. Devices are interior vertices of the network graph.
DeviceIdpair forms a
ConnectPoint, which represents an endpoint of a graph edge.
ConnectPoint. Hosts are exterior (leaf) vertices of the network graph.
ConnectPoints). Links are interior edges of the network graph.
At the application level, directives for the network are expressed as high-level flow rules given as Criteria (Match) and Treatment (Action) pairs. An ONOS instance will have a role for any given device that either allows or denies it from applying changes to the device.
Constructs for manipulating network logic, as well as their construction, are discussed further in Intent Framework. Roles are explained in Cluster Coordination.
Packets, such as from network traffic, and those to be injected into the network, have analogues to the OpenFlow PacketIn and PacketOut.
Some entities rely on the existence of other entities, as in the case of Ports, which cannot exist without a Device. Similarly, Links, and by extension, Topologies, cannot exist without Ports serving as endpoints to the Link. We therefore consider Devices to be a first-class entity in ONOS's network representations.
Previous : System Components
Next : The Device Subsystem