Page History

...

ONOS maintains both protocol-agnostic and protocol-specific network element and state representations. 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 DeviceManager and 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 by the intermediate transcription into a DeviceDescription.

The term 'Model Object' refers more to the core's representations, which Here we focus on herethe model objects.

Model Object Types

The interface definitions and implementations of these objects can be found across several packages under [org.onlab.onos.net.*]. While not formal, implicit object classifications fall out of the organization of these packages.

...

• Device - A network infrastructure element, e.g. a switch, router, access-point, or middle-box. Devices have a set of interfaces/ports and a DeviceId. Devices are interior vertices of the network graph.
• Port - A network interface on a Device. A Port and DeviceId pair forms a ConnectPoint, which represents an endpoint of a graph edge. 
  
• Host - A network end-station, which has an IP address, MAC address, VLAN ID, and a ConnectPoint. Hosts are exterior (leaf) vertices of the network graph.
• Link - A directed link between two infrastructure Devices (ConnectPoints). Links are interior edges of the network graph.
• EdgeLink - A specialized Link connecting a Host to a Device. EdgeLinks are exterior edges of the network graph.
• Path - A list of one or more adjacent Links, including EdgeLinks. EdgeLinks, if present in the path, can only be exterior links (beginning and end of the list).
• Topology - A Snapshot of a traversable graph representing the network. Path computations against this graph may be done using an arbitrary graph traversal algorithm, e.g. BFS, Dijkstra, or Bellman-Ford.

Network Logic

Network logic, such At the application level, directives for the network are expressed as high-level flow rules given as Criteria (Match) and Treatment (Action) pairs.

• FlowRule - A high-level flow rule given as a Match and Action pair. An action can be a composite action if needed. This abstraction is distinct from OpenFlow's notions of flow rules, e,g, separate the number of tables and OF match-action pairs.
• Intent - A high-level intent to affect network configuration or connectivity for a subset of network traffic. It allows applications to specify what they want to happen, rather than having to specify how they want things to happen.

Constructs for manipulating network logic, as well as their construction, are discussed further in [The Intent Framework].

Network Packets

Packets, such as from network traffic, and those to be injected into the network, have analogues to the OpenFlow PacketIn and PacketOut. 

• OutboundPacket - Protocol agnostic representation of a synthetic packet to be emitted on the network (packet-out). This includes information about where to emit this packet.
• InboundPacket - We may need to consider whether this abstraction should be purposefully omitted from the API to avoid scalability and security related issues. Regardless, reactive packet processing should still be available to providers to use as needed, e.g. host tracking, link detection.

...