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 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.
...