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.
...
| Table of Contents | ||
|---|---|---|
|
Overview
In order to manage the infrastructure, ONOS must keep track of information about the infrastructure (topology, installed flows, etc) in a form available to its applications. Importantly, the applications must be shielded from protocol-specifics, even if network state information is collected in protocol-specific ways.
As a solution, ONOS maintains ONOS maintains both 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 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 across the provider and core layers by the intermediate transcription into a DeviceDescription. Model Objects are what ONOS exposes to its applications.
Additionally, wherever Wherever possible, rich data types are also 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 byte[] or 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 ObjectsHere, we focus on the 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.Note that the following list is not comprehensive.
...
Constructs for manipulating network logic, as well as their construction, are discussed further in The Intent Framework. Roles are explained in ClusteringCluster Coordination.
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. 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 Protocol agnostic representation of a packet sent to the controller by a device. This enables reactive packet processing by making PacketIns available to providers and applications to use as needed, e.g. host tracking, link detection.
...
Previous : System Components
Next : The Device Subsystem
...