blob: c560fb14cff19fef06ebc32e04febaefe19c09e5 [file] [log] [blame]
Thomas Vachuska83e090e2014-10-22 14:25:35 -07001/*
Brian O'Connor5ab426f2016-04-09 01:19:45 -07002 * Copyright 2014-present Open Networking Laboratory
Thomas Vachuska83e090e2014-10-22 14:25:35 -07003 *
Thomas Vachuska4f1a60c2014-10-28 13:39:07 -07004 * Licensed under the Apache License, Version 2.0 (the "License");
5 * you may not use this file except in compliance with the License.
6 * You may obtain a copy of the License at
Thomas Vachuska83e090e2014-10-22 14:25:35 -07007 *
Thomas Vachuska4f1a60c2014-10-28 13:39:07 -07008 * http://www.apache.org/licenses/LICENSE-2.0
9 *
10 * Unless required by applicable law or agreed to in writing, software
11 * distributed under the License is distributed on an "AS IS" BASIS,
12 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13 * See the License for the specific language governing permissions and
14 * limitations under the License.
Thomas Vachuska83e090e2014-10-22 14:25:35 -070015 */
16
Brian O'Connorb876bf12014-10-02 14:59:37 -070017/**
toma1d16b62014-10-02 23:45:11 -070018 * Set of abstractions for conveying high-level intents for treatment of
19 * selected network traffic by allowing applications to express the
20 * <em>what</em> rather than the <em>how</em>. This makes such instructions
21 * largely independent of topology and device specifics, thus allowing them to
22 * survive topology mutations.
Thomas Vachuska4b420772014-10-30 16:46:17 -070023 * <p>
tom6db1f0a2014-10-07 09:12:29 -070024 * The controller core provides a suite of built-in intents and their compilers
25 * and installers. However, the intent framework is extensible in that it allows
26 * additional intents and their compilers or installers to be added
27 * dynamically at run-time. This allows others to enhance the initial arsenal of
28 * connectivity and policy-based intents available in base controller software.
Thomas Vachuska4b420772014-10-30 16:46:17 -070029 * </p>
30 * <p>
tom6db1f0a2014-10-07 09:12:29 -070031 * The following diagram depicts the state transition diagram for each top-level intent:<br>
32 * <img src="doc-files/intent-states.png" alt="ONOS intent states">
Thomas Vachuska4b420772014-10-30 16:46:17 -070033 * </p>
34 * <p>
tom6db1f0a2014-10-07 09:12:29 -070035 * The controller core accepts the intent specifications and translates them, via a
36 * process referred to as intent compilation, to installable intents, which are
37 * essentially actionable operations on the network environment.
38 * These actions are carried out by intent installation process, which results
39 * in some changes to the environment, e.g. tunnel links being provisioned,
40 * flow rules being installed on the data-plane, optical lambdas being reserved.
Thomas Vachuska4b420772014-10-30 16:46:17 -070041 * </p>
42 * <p>
tom6db1f0a2014-10-07 09:12:29 -070043 * After an intent is submitted by an application, it will be sent immediately
44 * (but asynchronously) into a compiling phase, then to installing phase and if
45 * all goes according to plan into installed state. Once an application decides
46 * it no longer wishes the intent to hold, it can withdraw it. This describes
47 * the nominal flow. However, it may happen that some issue is encountered.
48 * For example, an application may ask for an objective that is not currently
49 * achievable, e.g. connectivity across to unconnected network segments.
50 * If this is the case, the compiling phase may fail to produce a set of
51 * installable intents and instead result in a failed compile. If this occurs,
52 * only a change in the environment can trigger a transition back to the
53 * compiling state.
Thomas Vachuska4b420772014-10-30 16:46:17 -070054 * </p>
55 * <p>
tom6db1f0a2014-10-07 09:12:29 -070056 * Similarly, an issue may be encountered during the installation phase in
57 * which case the framework will attempt to recompile the intent to see if an
58 * alternate approach is available. If so, the intent will be sent back to
59 * installing phase. Otherwise, it will be parked in the failed state. Another
60 * scenario that’s very likely to be encountered is where the intent is
61 * successfully compiled and installed, but due to some topology event, such
62 * as a downed or downgraded link, loss of throughput may occur or connectivity
63 * may be lost altogether, thus impacting the viability of a previously
64 * satisfied intent. If this occurs, the framework will attempt to recompile
65 * the intent, and if an alternate approach is available, its installation
66 * will be attempted. Otherwise, the original top-level intent will be parked
67 * in the failed state.
Thomas Vachuska4b420772014-10-30 16:46:17 -070068 * </p>
69 * <p>
tom6db1f0a2014-10-07 09:12:29 -070070 * Please note that all *ing states, depicted in orange, are transitional and
71 * are expected to last only a brief amount of time. The rest of the states
72 * are parking states where the intent may spent some time; except for the
73 * submitted state of course. There, the intent may pause, but only briefly,
74 * while the system determines where to perform the compilation or while it
75 * performs global recomputation/optimization across all prior intents.
Thomas Vachuska4b420772014-10-30 16:46:17 -070076 * </p>
Thomas Vachuskaa1c4ccd2015-01-29 19:12:01 -080077 * <p>
Thomas Vachuska4a51e572015-02-07 21:36:23 -080078 * The figure below depicts the general interactions between different
79 * components of the intent subsystem.<br>
80 * <img src="doc-files/intent-design.png" alt="ONOS intent subsystem design">
Thomas Vachuskaa1c4ccd2015-01-29 19:12:01 -080081 * </p>
Brian O'Connorb876bf12014-10-02 14:59:37 -070082 */
Brian O'Connorabafb502014-12-02 22:26:20 -080083package org.onosproject.net.intent;