This section describes the Intent Framework and the subsystems associated with it.
The Intent Framework is a subsystem that allows applications to specify their network control desires in form of policy rather than mechanism. We refer to these policy-based directives as intents. The ONOS core accepts the intent specifications and translates them, via intent compilation, into 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, such as tunnel links being provisioned, flow rules being installed on a switch, or optical lambdas (wavelengths) being reserved.
Although the ONOS core provides a suite of built-in intents and their compilers and installers, the intent framework is designed to be extensible. It allows additional intents and their compilers or installers to be added to ONOS dynamically at run-time. This allows others to enhance the initial arsenal of connectivity and policy-based intents available in ONOS by default.
Intent is an immutable model object that describes an application's request to the ONOS core to alter the network's behavior. At the lowest levels, Intents may be described in terms of:
TrafficSelectorcarries criteria as a set of objects that implement the
TrafficTreatmentcarries instructions as a set of objects that implement the
In addition, Intents are always identified by both the
ApplicationId of the application that submitted it, and a unique
IntentId, generated at creation.
The following diagram depicts the state transition diagram for the compilation process of each top-level intent:
The 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 spend some time. The exception is the Submitted state, where the intent may pause briefly while:
After an intent is submitted by an application, it will be sent immediately (but asynchronously) into a compiling phase, then to the installing phase, and finally, to the installed state. An intent may also be withdrawn if an application decides that it no longer wishes for the intent to hold.
The rest of the states account for various issues that may arise:
The failure mode for the above cases is the failed state.
The Intent framework relies on the Java Future for handling the asynchronous intent compilation process.
Intents are ultimately compiled down into a set of
FlowRule model objects. The process may include:
Intentdown into installable intent(s), by an
FlowRules, by an
Intent has an
IntentCompiler associated with it. Similarly, installable
Intents will have a corresponding
IntentInstaller. For example, a PointToPointIntent must first be compiled into a
PathIntent by a
PointToPointIntentCompiler, before being converted into a
BatchOperation by the
IntentManager coordinates the compilation and installation of
FlowRules by managing the invocation of available
FlowRuleBatchOperations are handed off to the
FlowRuleService to be written down as protocol-specific messages. In the case of OpenFlow, the OpenFlowRuleProvider is responsible for generating
OFFlowMod messages from
FlowRules, and sending it to the appropriate network switch. It relies on the OpenFlow subsystem for its message factories and
OpenFlowSwitch references for this task.
Previous : Clustering
Next : GUI Architecture