|
| 1 | +== Network Intent Composition (NIC) User Guide |
| 2 | + |
| 3 | +=== Overview |
| 4 | +Network Intent Composition (NIC) is an interface that allows clients to |
| 5 | +express a desired state in an implementation-neutral form that will be |
| 6 | +enforced via modification of available resources under the control of |
| 7 | +the OpenDaylight system. |
| 8 | + |
| 9 | +This description is purposely abstract as an intent interface might |
| 10 | +encompass network services, virtual devices, storage, etc. |
| 11 | + |
| 12 | +The intent interface is meant to be a controller-agnostic interface |
| 13 | +so that "intents" are portable across implementations, such as OpenDaylight |
| 14 | +and ONOS. Thus an intent specification should not contain implementation |
| 15 | +or technology specifics. |
| 16 | + |
| 17 | +The intent specification will be implemented by decomposing the intent |
| 18 | +and augmenting it with implementation specifics that are driven by |
| 19 | +local implementation rules, policies, and/or settings. |
| 20 | + |
| 21 | +=== Network Intent Composition (NIC) Architecture |
| 22 | +The core of the NIC architecture is the intent model, which specifies |
| 23 | +the details of the desired state. It is the responsibility of the NIC |
| 24 | +implementation transforms this desired state to the resources under |
| 25 | +the control of OpenDaylight. The component that transforms the |
| 26 | +intent to the implementation is typically referred to as a renderer. |
| 27 | + |
| 28 | +For the Lithium release, multiple, simultaneous renderers will not be supported. |
| 29 | +Instead either the VTN or GBP renderer feature can be installed, but |
| 30 | +not both. |
| 31 | + |
| 32 | +For the Litium release, the only actions supported are "ALLOW" and |
| 33 | +"BLOCK". The "ALLOW" action indicates that traffic can flow between |
| 34 | +the source and destination end points, while "BLOCK" prevents that |
| 35 | +flow; although it is possible that an given implementation may augment |
| 36 | +the available actions with additional actions. |
| 37 | + |
| 38 | +Besides transforming a desired state to an actual state it is the |
| 39 | +responsibility of a renderer to update the operational state tree for |
| 40 | +the NIC data model in OpenDaylight to reflect the intent which the |
| 41 | +renderer implemented. |
| 42 | + |
| 43 | +=== Configuring Network Intent Composition (NIC) |
| 44 | +For the Litium release there is no default implementation of a renderer, |
| 45 | +thus without an additional module installed the NIC will not function. |
| 46 | + |
| 47 | +=== Administering or Managing Network Intent Composition (NIC) |
| 48 | +There is no additional administration of management capabilities |
| 49 | +related to the Network Intent Composition features. |
| 50 | + |
| 51 | +=== Interactions |
| 52 | +A user can interact with the Network Intent Composition (NIC) either |
| 53 | +through the RESTful interface using standard RESTCONF operations and |
| 54 | +syntax or via the Karaf console CLI. |
| 55 | + |
| 56 | +==== REST |
| 57 | + |
| 58 | +===== Configuration |
| 59 | +The Network Intent Composition (NIC) feature supports the following REST |
| 60 | +operations against the configuration data store. |
| 61 | + |
| 62 | +* POST - creates a new instance of an intent in the configuration store, |
| 63 | +which will trigger the realization of that intent. An ID _must_ be specified |
| 64 | +as part of this request as an attribute of the intent. |
| 65 | + |
| 66 | +* PUT - creates or updates an instance of an intent in the configuration store, |
| 67 | +which will trigger the realization of that intent. |
| 68 | + |
| 69 | +* GET - fetches a list of all configured intents or a specific configured |
| 70 | +intent. |
| 71 | + |
| 72 | +* DETELE - removes a configured intent from the configuration store, which |
| 73 | +triggers the removal of the intent from the network. |
| 74 | + |
| 75 | +===== Operational |
| 76 | +The Network Intent Composition (NIC) feature supports the following REST |
| 77 | +operations against the operational data store. |
| 78 | + |
| 79 | +* GET - fetches a list of all operational intents or a specific operational |
| 80 | +intent. |
| 81 | + |
| 82 | +==== Karaf Console CLI |
| 83 | +Using the Karaf console CLI intents can be manipulated. The following Karaf |
| 84 | +console CLI commands are available. |
| 85 | + |
| 86 | +* intent:add <intent-data> - creates a new intent |
| 87 | + |
| 88 | +* intent:update <id> <intent-data> - updates an existing intent |
| 89 | + |
| 90 | +* intent:list - lists all intents in the system |
| 91 | + |
| 92 | +* intent:show <id> - display the details of a specific intent |
| 93 | + |
| 94 | +* intent:delete <id> - removes an intent from the system |
0 commit comments