Set of abstractions for conveying high-level intents for treatment of selected network traffic by allowing applications to express the what rather than the how. This makes such instructions largely independent of topology and device specifics, thus allowing them to survive topology mutations.

The controller core provides a suite of built-in intents and their compilers and installers. However, the intent framework is extensible in that it allows additional intents and their compilers or installers to be added dynamically at run-time. This allows others to enhance the initial arsenal of connectivity and policy-based intents available in base controller software.

The following diagram depicts the state transition diagram for each top-level intent:
ONOS intent states

The controller core accepts the intent specifications and translates them, via a process referred to as intent compilation, to installable intents, which are essentially actionable operations on the network environment. These actions are carried out by intent installation process, which results in some changes to the environment, e.g. tunnel links being provisioned, flow rules being installed on the data-plane, optical lambdas being reserved.

After an intent is submitted by an application, it will be sent immediately (but asynchronously) into a compiling phase, then to installing phase and if all goes according to plan into installed state. Once an application decides it no longer wishes the intent to hold, it can withdraw it. This describes the nominal flow. However, it may happen that some issue is encountered. For example, an application may ask for an objective that is not currently achievable, e.g. connectivity across to unconnected network segments. If this is the case, the compiling phase may fail to produce a set of installable intents and instead result in a failed compile. If this occurs, only a change in the environment can trigger a transition back to the compiling state.

Similarly, an issue may be encountered during the installation phase in which case the framework will attempt to recompile the intent to see if an alternate approach is available. If so, the intent will be sent back to installing phase. Otherwise, it will be parked in the failed state. Another scenario that’s very likely to be encountered is where the intent is successfully compiled and installed, but due to some topology event, such as a downed or downgraded link, loss of throughput may occur or connectivity may be lost altogether, thus impacting the viability of a previously satisfied intent. If this occurs, the framework will attempt to recompile the intent, and if an alternate approach is available, its installation will be attempted. Otherwise, the original top-level intent will be parked in the failed state.

Please note that all *ing states, depicted in orange, are transitional and are expected to last only a brief amount of time. The rest of the states are parking states where the intent may spent some time; except for the submitted state of course. There, the intent may pause, but only briefly, while the system determines where to perform the compilation or while it performs global recomputation/optimization across all prior intents.

The figure below depicts the general interactions between different components of the intent subsystem.
ONOS intent subsystem design