See: Description
| Interface | Description |
|---|---|
| Constraint |
Representation of a connectivity constraint capable of evaluating a link
and determining the cost of traversing that link in the context of this
constraint.
|
| IntentBatchDelegate |
Facade for receiving notifications from the intent batch service.
|
| IntentBatchListener |
Listener for
intent events. |
| IntentBatchService |
Service for tracking and delegating batches of intent operations.
|
| IntentCompiler<T extends Intent> |
Abstraction of a compiler which is capable of taking an intent
and translating it to other, potentially installable, intents.
|
| IntentExtensionService |
Service for extending the capability of intent framework by
adding additional compilers or/and installers.
|
| IntentInstaller<T extends Intent> |
Abstraction of entity capable of installing intents to the environment.
|
| IntentListener |
Listener for
intent events. |
| IntentService |
Service for application submitting or withdrawing their intents.
|
| IntentStore |
Manages inventory of end-station intents; not intended for direct use.
|
| IntentStoreDelegate |
Intent store delegate abstraction.
|
| Class | Description |
|---|---|
| BatchWrite | |
| BatchWrite.Operation | |
| ConnectivityIntent |
Abstraction of connectivity intent for traffic matching some criteria.
|
| HostToHostIntent |
Abstraction of end-station to end-station bidirectional connectivity.
|
| Intent |
Abstraction of an application level intent.
|
| IntentBatchLeaderEvent |
A class to represent an intent related event.
|
| IntentEvent |
A class to represent an intent related event.
|
| IntentId |
Intent identifier suitable as an external key.
|
| IntentOperation |
Abstraction of an intent-related operation, e.g.
|
| IntentOperations |
Batch of intent submit/withdraw/replace operations.
|
| IntentOperations.Builder |
Builder for batches of intent operations.
|
| LinkCollectionIntent |
Abstraction of a connectivity intent that is implemented by a set of path
segments.
|
| MultiPointToSinglePointIntent |
Abstraction of multiple source to single destination connectivity intent.
|
| OpticalConnectivityIntent |
An optical layer intent for connectivity from one transponder port to another
transponder port.
|
| OpticalPathIntent | |
| PathIntent |
Abstraction of explicitly path specified connectivity intent.
|
| PointToPointIntent |
Abstraction of point-to-point connectivity.
|
| SinglePointToMultiPointIntent |
Abstraction of single source, multiple destination connectivity intent.
|
| Enum | Description |
|---|---|
| BatchWrite.OpType | |
| IntentBatchLeaderEvent.Type | |
| IntentEvent.Type | |
| IntentOperation.Type |
Operation type.
|
| IntentState |
Representation of the phases an intent may attain during its lifecycle.
|
| Exception | Description |
|---|---|
| IntentException |
Represents an intent related error.
|
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:
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.
Copyright © 2015. All rights reserved.