[submodule "docs/submodules/aaa"]
path = docs/submodules/aaa
url = ../aaa
- branch = master
+ branch = .
[submodule "docs/submodules/netconf"]
path = docs/submodules/netconf
url = ../netconf
- branch = master
+ branch = .
[submodule "docs/submodules/odlparent"]
path = docs/submodules/odlparent
url = ../odlparent
- branch = master
+ branch = .
[submodule "source/submodules/spectrometer"]
path = docs/submodules/spectrometer
url = ../spectrometer
branch = master
+[submodule "docs/submodules/netvirt"]
+ path = docs/submodules/netvirt
+ url = ../netvirt
+ branch = .
+[submodule "docs/submodules/genius"]
+ path = docs/submodules/genius
+ url = ../genius
+ branch = .
It is the responsibility of the caller to create a new transaction
and submit the same modification again in order to update data tree.
- **Warning**
+ .. warning::
``OptimisticLockFailedException`` usually exposes **multiple
writers** to the same data subtree, which may conflict on same
Install the Forwarding Objective:
-`http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward <http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward>`__
----
+``http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward``
Install the Filter Objective
-`http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter <http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter>`__
----
+``http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter``
Install the Next Objective:
-`http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next <http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next>`__
----
+``http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next``
Flow mod driver API
~~~~~~~~~~~~~~~~~~~
---------------------------
Go to
-`http://${controller-ip}:8181/apidoc/explorer/index.html <http://${controller-ip}:8181/apidoc/explorer/index.html>`__,
+http://${controller-ip}:8181/apidoc/explorer/index.html,
and look under DIDM section to see all the available REST calls and
tables
Session Establishment
~~~~~~~~~~~~~~~~~~~~~
-The `OpenFlow Protocol
-Library <#_openflow_protocol_library_developer_guide>`__ provides
+The :ref:`OpenFlow Protocol
+Library <openflow-protocol-library>` provides
interface **SwitchConnectionHandler** which contains method
*onSwitchConnected* (step 1). This event is raised in the OpenFlow
Protocol Library when an OpenFlow device connects to OpenDaylight and
- sal CodeGeneratorImpl (target/generated-sources/sal)
-- documentation generator (target/site/models):
- `openflow-provider.html <https://jenkins.opendaylight.org/openflowplugin/job/openflowplugin-merge/ws/openflowplugin/target/site/models/openflow-provider.html>`__,
- `openflow-provider-impl.html <https://jenkins.opendaylight.org/openflowplugin/job/openflowplugin-merge/ws/openflowplugin/target/site/models/openflow-provider-impl.html>`__
-
Altering generated files
~~~~~~~~~~~~~~~~~~~~~~~~
FRS uses service with implemented barrier waiting logic between
dependent objects
-SalFlatBatchService for FRS
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Service: SalFlatBatchService
+----------------------------
+
+Basics
+~~~~~~
SalFlatBatchService was created along forwardingrules-sync application
-as the service that should application used by default. This service
-uses only one input with bag of flow/group/meter objects and their
-common add/update/remove action. So you practically send only one input
-(of specific bags) to this service.
+as the service that should application used by default. This service uses
+only one input with bag of flow/group/meter objects and their common
+add/update/remove action. So you practically send only one input (of specific
+bags) to this service.
+
+- interface: *org.opendaylight.yang.gen.v1.urn.opendaylight.flat.batch.service.rev160321.SalFlatBatchService*
+
+- implementation: *org.opendaylight.openflowplugin.impl.services.SalFlatBatchServiceImpl*
+
+- method: *processFlatBatch(input)*
+
+- input: *org.opendaylight.yang.gen.v1.urn.opendaylight.flat.batch.service.rev160321.ProcessFlatBatchInput*
+
+Usage benefits
+^^^^^^^^^^^^^^
+
+- possibility to use only one input bag with particular failure analysis preserved
+
+- automatic barrier decision (chain+wait)
+
+- less RPC routing in cluster environment (since one call encapsulates all others)
+
+ProcessFlatBatchInput
+~~~~~~~~~~~~~~~~~~~~~
+
+Input for SalFlatBatchService (ProcessFlatBatchInput object) consists of:
+
+- node - NodeRef
+
+- batch steps - List<Batch> - defined action + bag of objects + order for failures analysis
+
+ - BatchChoice - yang-modeled action choice (e.g. FlatBatchAddFlowCase) containing batch bag of objects (e.g. flows to be added)
+
+ - BatchOrder - (integer) order of batch step (should be incremented by single action)
+
+- exitOnFirstError - boolean flag
Workflow
-^^^^^^^^
+~~~~~~~~
+#. prepare **list of steps** based on input
-- prepare plan of actions
+#. **mark barriers** in steps where needed
- - mark actions where the barrier is needed before continue
+#. prepare particular **F/G/M-batch** service calls from **Flat-batch** steps
-- run appropriate service calls
+ - F/G/M-batch services encapsulate bulk of single service calls
+
+ - they actually chain barrier after processing all single calls if actual step is marked as barrier-needed
+
+#. **chain** futures and **start** executing
+
+ - start all actions that can be run simultaneously (chain all on one starting point)
+
+ - in case there is a step marked as barrier-needed
+
+ - wait for all fired jobs up to one with barrier
+
+ - merge rpc results (status, errors, batch failures) into single one
+
+ - the latest job with barrier is new starting point for chaining
+
+Services encapsulation
+^^^^^^^^^^^^^^^^^^^^^^
+
+- SalFlatBatchService
+
+ - SalFlowBatchService
+
+ - SalFlowService
+
+ - SalGroupBatchService
+
+ - SalGroupService
+
+ - SalMeterBatchService
+
+ - SalMeterService
+
+Barrier decision
+^^^^^^^^^^^^^^^^
+
+- decide on actual step and all previous steps since the latest barrier
+
+- if condition in table below is satisfied the latest step before actual is marked as barrier-needed
+
++---------------------------+------------------------------------------------------------------+
+| actual step | previous steps contain |
++===========================+==================================================================+
+| FLOW_ADD *or* FLOW_UPDATE | GROUP_ADD *or* METER_ADD |
++---------------------------+------------------------------------------------------------------+
+| GROUP_ADD | GROUP_ADD *or* GROUP_UPDATE |
++---------------------------+------------------------------------------------------------------+
+| GROUP_REMOVE | FLOW_UPDATE *or* FLOW_REMOVE *or* GROUP_UPDATE *or* GROUP_REMOVE |
++---------------------------+------------------------------------------------------------------+
+| METER_REMOVE | FLOW_UPDATE *or* FLOW_REMOVE |
++---------------------------+------------------------------------------------------------------+
+
+Error handling
+^^^^^^^^^^^^^^
- - start all actions that can be run simultaneously
+There is flag in ProcessFlatBatchInput to stop process on the first error.
- - if there is barrier-needed mark, wait for all fired jobs and only
- then continue with the next action
+- *true* - if partial step is not successful stop whole processing
-error handling:
+- *false* (default) - try to process all steps regardless partial results
-- there is flag to stop process on the first error (default set to
- false)
+If error occurs in any of partial steps upper FlatBatchService call will return as unsuccessful in both cases.
+However every partial error is attached to general flat batch result along with BatchFailure (contains BatchOrder
+and BatchItemIdChoice to identify failed step).
Cluster singleton approach in plugin
------------------------------------
Yang models and API
-------------------
-+--------------------------------------------------------+-------------------+
-| Model | DOC |
-+========================================================+===================+
++--------------------------------------------------------+
+| Model |
++========================================================+
| ***Openflow basic types*** |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-table-types.yang <https://git.opendaylig | `YangDOC <https:/ |
-| ht.org/gerrit/gitweb?p=openflowplugin.git;f=model/mode | /jenkins.opendayl |
-| l-flow-base/src/main/yang/opendaylight-table-types.yan | ight.org/releng/v |
-| g;a=blob;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-base/t |
-| | arget/site/models |
-| | /opendaylight-tab |
-| | le-types.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-action-types.yang <https://git.opendayli | `YangDOC <https:/ |
-| ght.org/gerrit/gitweb?p=openflowplugin.git;f=model/mod | /jenkins.opendayl |
-| el-flow-base/src/main/yang/opendaylight-action-types.y | ight.org/releng/v |
-| ang;a=blob;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-base/t |
-| | arget/site/models |
-| | /opendaylight-act |
-| | ion-types.html>`_ |
-| | _ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-flow-types.yan <https://git.opendaylight | `YangDOC <https:/ |
-| .org/gerrit/gitweb?p=openflowplugin.git;f=model/model- | /jenkins.opendayl |
-| flow-base/src/main/yang/opendaylight-flow-types.yang;a | ight.org/releng/v |
-| =blob;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-base/t |
-| | arget/site/models |
-| | /opendaylight-flo |
-| | w-types.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-meter-types.yang <https://git.opendaylig | `YangDOC <https:/ |
-| ht.org/gerrit/gitweb?p=openflowplugin.git;f=model/mode | /jenkins.opendayl |
-| l-flow-base/src/main/yang/opendaylight-meter-types.yan | ight.org/releng/v |
-| g;a=blob;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-base/t |
-| | arget/site/models |
-| | /opendaylight-met |
-| | er-types.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-group-types.yang <https://git.opendaylig | `YangDOC <https:/ |
-| ht.org/gerrit/gitweb?p=openflowplugin.git;f=model/mode | /jenkins.opendayl |
-| l-flow-base/src/main/yang/opendaylight-group-types.yan | ight.org/releng/v |
-| g;a=blob;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-base/t |
-| | arget/site/models |
-| | /opendaylight-gro |
-| | up-types.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-match-types.yang <https://git.opendaylig | `YangDOC <https:/ |
-| ht.org/gerrit/gitweb?p=openflowplugin.git;f=model/mode | /jenkins.opendayl |
-| l-flow-base/src/main/yang/opendaylight-match-types.yan | ight.org/releng/v |
-| g;a=blob;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-base/t |
-| | arget/site/models |
-| | /opendaylight-mat |
-| | ch-types.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-port-types.yang <https://git.opendayligh | `YangDOC <https:/ |
-| t.org/gerrit/gitweb?p=openflowplugin.git;f=model/model | /jenkins.opendayl |
-| -flow-base/src/main/yang/opendaylight-port-types.yang; | ight.org/releng/v |
-| a=blob;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-base/t |
-| | arget/site/models |
-| | /opendaylight-por |
-| | t-types.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-queue-types.yang <https://git.opendaylig | `YangDOC <https:/ |
-| ht.org/gerrit/gitweb?p=openflowplugin.git;f=model/mode | /jenkins.opendayl |
-| l-flow-base/src/main/yang/opendaylight-queue-types.yan | ight.org/releng/v |
-| g;a=blob;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-base/t |
-| | arget/site/models |
-| | /opendaylight-que |
-| | ue-types.html>`__ |
-+--------------------------------------------------------+-------------------+
++--------------------------------------------------------+
+| `opendaylight-table-types.yang <https://git.opendaylig |
+| ht.org/gerrit/gitweb?p=openflowplugin.git;f=model/mode |
+| l-flow-base/src/main/yang/opendaylight-table-types.yan |
+| g;a=blob;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
+| `opendaylight-action-types.yang <https://git.opendayli |
+| ght.org/gerrit/gitweb?p=openflowplugin.git;f=model/mod |
+| el-flow-base/src/main/yang/opendaylight-action-types.y |
+| ang;a=blob;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
+| `opendaylight-flow-types.yang <https://git.opendayligh |
+| t.org/gerrit/gitweb?p=openflowplugin.git;f=model/model |
+| -flow-base/src/main/yang/opendaylight-flow-types.yang; |
+| a=blob;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
+| `opendaylight-meter-types.yang <https://git.opendaylig |
+| ht.org/gerrit/gitweb?p=openflowplugin.git;f=model/mode |
+| l-flow-base/src/main/yang/opendaylight-meter-types.yan |
+| g;a=blob;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
+| `opendaylight-group-types.yang <https://git.opendaylig |
+| ht.org/gerrit/gitweb?p=openflowplugin.git;f=model/mode |
+| l-flow-base/src/main/yang/opendaylight-group-types.yan |
+| g;a=blob;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
+| `opendaylight-match-types.yang <https://git.opendaylig |
+| ht.org/gerrit/gitweb?p=openflowplugin.git;f=model/mode |
+| l-flow-base/src/main/yang/opendaylight-match-types.yan |
+| g;a=blob;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
+| `opendaylight-port-types.yang <https://git.opendayligh |
+| t.org/gerrit/gitweb?p=openflowplugin.git;f=model/model |
+| -flow-base/src/main/yang/opendaylight-port-types.yang; |
+| a=blob;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
+| `opendaylight-queue-types.yang <https://git.opendaylig |
+| ht.org/gerrit/gitweb?p=openflowplugin.git;f=model/mode |
+| l-flow-base/src/main/yang/opendaylight-queue-types.yan |
+| g;a=blob;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
| ***Openflow services*** |
-+--------------------------------------------------------+-------------------+
-| `sal-table.yang <https://git.opendaylight.org/gerrit/g | `YangDOC <https:/ |
-| itweb?p=openflowplugin.git;f=model/model-flow-service/ | /jenkins.opendayl |
-| src/main/yang/sal-table.yang;a=blob;hb=refs/heads/stab | ight.org/releng/v |
-| le/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/sal-table.htm |
-| | l>`__ |
-+--------------------------------------------------------+-------------------+
-| `sal-group.yang <https://git.opendaylight.org/gerrit/g | `YangDOC <https:/ |
-| itweb?p=openflowplugin.git;f=model/model-flow-service/ | /jenkins.opendayl |
-| src/main/yang/sal-group.yang;a=blob;hb=refs/heads/stab | ight.org/releng/v |
-| le/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/sal-group.htm |
-| | l>`__ |
-+--------------------------------------------------------+-------------------+
-| `sal-queue.yang <https://git.opendaylight.org/gerrit/g | `YangDOC <https:/ |
-| itweb?p=openflowplugin.git;f=model/model-flow-service/ | /jenkins.opendayl |
-| src/main/yang/sal-queue.yang;a=blob;hb=refs/heads/stab | ight.org/releng/v |
-| le/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/sal-queue.htm |
-| | l>`__ |
-+--------------------------------------------------------+-------------------+
-| `flow-errors.yang <https://git.opendaylight.org/gerrit | `YangDOC <https:/ |
-| /gitweb?p=openflowplugin.git;f=model/model-flow-servic | /jenkins.opendayl |
-| e/src/main/yang/flow-errors.yang;a=blob;hb=refs/heads/ | ight.org/releng/v |
-| stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/flow-errors.h |
-| | tml>`__ |
-+--------------------------------------------------------+-------------------+
-| `flow-capable-transaction.yang <https://git.opendaylig | `YangDOC <https:/ |
-| ht.org/gerrit/gitweb?p=openflowplugin.git;f=model/mode | /jenkins.opendayl |
-| l-flow-service/src/main/yang/flow-capable-transaction. | ight.org/releng/v |
-| yang;a=blob;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/flow-capable- |
-| | transaction.html> |
-| | `__ |
-+--------------------------------------------------------+-------------------+
-| `sal-flow.yang <https://git.opendaylight.org/gerrit/gi | `YangDOC <https:/ |
-| tweb?p=openflowplugin.git;f=model/model-flow-service/s | /jenkins.opendayl |
-| rc/main/yang/sal-flow.yang;a=blob;hb=refs/heads/stable | ight.org/releng/v |
-| /boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/sal-flow.html |
-| | >`__ |
-+--------------------------------------------------------+-------------------+
-| `sal-meter.yang <https://git.opendaylight.org/gerrit/g | `YangDOC <https:/ |
-| itweb?p=openflowplugin.git;f=model/model-flow-service/ | /jenkins.opendayl |
-| src/main/yang/sal-meter.yang;a=blob;hb=refs/heads/stab | ight.org/releng/v |
-| le/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/sal-meter.htm |
-| | l>`__ |
-+--------------------------------------------------------+-------------------+
-| `flow-topology-discovery.yang <https://git.opendayligh | `YangDOC <https:/ |
-| t.org/gerrit/gitweb?p=openflowplugin.git;f=model/model | /jenkins.opendayl |
-| -flow-service/src/main/yang/flow-topology-discovery.ya | ight.org/releng/v |
-| ng;a=blob;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/flow-topology |
-| | -discovery.html>` |
-| | __ |
-+--------------------------------------------------------+-------------------+
-| `node-errors.yang <https://git.opendaylight.org/gerrit | `YangDOC <https:/ |
-| /gitweb?p=openflowplugin.git;f=model/model-flow-servic | /jenkins.opendayl |
-| e/src/main/yang/node-errors.yang;a=blob;hb=refs/heads/ | ight.org/releng/v |
-| stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/node-errors.h |
-| | tml>`__ |
-+--------------------------------------------------------+-------------------+
-| `node-config.yang <https://git.opendaylight.org/gerrit | `YangDOC <https:/ |
-| /gitweb?p=openflowplugin.git;f=model/model-flow-servic | /jenkins.opendayl |
-| e/src/main/yang/node-config.yang;a=blob;hb=refs/heads/ | ight.org/releng/v |
-| stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/node-config.h |
-| | tml>`__ |
-+--------------------------------------------------------+-------------------+
-| `sal-echo.yang <https://git.opendaylight.org/gerrit/gi | `YangDOC <https:/ |
-| tweb?p=openflowplugin.git;f=model/model-flow-service/s | /jenkins.opendayl |
-| rc/main/yang/sal-echo.yang;a=blob;hb=refs/heads/stable | ight.org/releng/v |
-| /boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/sal-echo.html |
-| | >`__ |
-+--------------------------------------------------------+-------------------+
-| `sal-port.yang <https://git.opendaylight.org/gerrit/gi | `YangDOC <https:/ |
-| tweb?p=openflowplugin.git;f=model/model-flow-service/s | /jenkins.opendayl |
-| rc/main/yang/sal-port.yang;a=blob;hb=refs/heads/stable | ight.org/releng/v |
-| /boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/sal-port.html |
-| | >`__ |
-+--------------------------------------------------------+-------------------+
-| `packet-processing.yang <https://git.opendaylight.org/ | `YangDOC <https:/ |
-| gerrit/gitweb?p=openflowplugin.git;f=model/model-flow- | /jenkins.opendayl |
-| service/src/main/yang/packet-processing.yang;a=blob;hb | ight.org/releng/v |
-| =refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/packet-proces |
-| | sing.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `flow-node-inventory.yang <https://git.opendaylight.or | `YangDOC <https:/ |
-| g/gerrit/gitweb?p=openflowplugin.git;f=model/model-flo | /jenkins.opendayl |
-| w-service/src/main/yang/flow-node-inventory.yang;a=blo | ight.org/releng/v |
-| b;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-servic |
-| | e/target/site/mod |
-| | els/flow-node-inv |
-| | entory.html>`__ |
-+--------------------------------------------------------+-------------------+
++--------------------------------------------------------+
+| `sal-table.yang <https://git.opendaylight.org/gerrit/g |
+| itweb?p=openflowplugin.git;f=model/model-flow-service/ |
+| src/main/yang/sal-table.yang;a=blob;hb=refs/heads/stab |
+| le/boron>`__ |
++--------------------------------------------------------+
+| `sal-group.yang <https://git.opendaylight.org/gerrit/g |
+| itweb?p=openflowplugin.git;f=model/model-flow-service/ |
+| src/main/yang/sal-group.yang;a=blob;hb=refs/heads/stab |
+| le/boron>`__ |
++--------------------------------------------------------+
+| `sal-queue.yang <https://git.opendaylight.org/gerrit/g |
+| itweb?p=openflowplugin.git;f=model/model-flow-service/ |
+| src/main/yang/sal-queue.yang;a=blob;hb=refs/heads/stab |
+| le/boron>`__ |
++--------------------------------------------------------+
+| `flow-errors.yang <https://git.opendaylight.org/gerrit |
+| /gitweb?p=openflowplugin.git;f=model/model-flow-servic |
+| e/src/main/yang/flow-errors.yang;a=blob;hb=refs/heads/ |
+| stable/boron>`__ |
++--------------------------------------------------------+
+| `flow-capable-transaction.yang <https://git.opendaylig |
+| ht.org/gerrit/gitweb?p=openflowplugin.git;f=model/mode |
+| l-flow-service/src/main/yang/flow-capable-transaction. |
+| yang;a=blob;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
+| `sal-flow.yang <https://git.opendaylight.org/gerrit/gi |
+| tweb?p=openflowplugin.git;f=model/model-flow-service/s |
+| rc/main/yang/sal-flow.yang;a=blob;hb=refs/heads/stable |
+| /boron>`__ |
++--------------------------------------------------------+
+| `sal-meter.yang <https://git.opendaylight.org/gerrit/g |
+| itweb?p=openflowplugin.git;f=model/model-flow-service/ |
+| src/main/yang/sal-meter.yang;a=blob;hb=refs/heads/stab |
+| le/boron>`__ |
++--------------------------------------------------------+
+| `flow-topology-discovery.yang <https://git.opendayligh |
+| t.org/gerrit/gitweb?p=openflowplugin.git;f=model/model |
+| -flow-service/src/main/yang/flow-topology-discovery.ya |
+| ng;a=blob;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
+| `node-errors.yang <https://git.opendaylight.org/gerrit |
+| /gitweb?p=openflowplugin.git;f=model/model-flow-servic |
+| e/src/main/yang/node-errors.yang;a=blob;hb=refs/heads/ |
+| stable/boron>`__ |
++--------------------------------------------------------+
+| `node-config.yang <https://git.opendaylight.org/gerrit |
+| /gitweb?p=openflowplugin.git;f=model/model-flow-servic |
+| e/src/main/yang/node-config.yang;a=blob;hb=refs/heads/ |
+| stable/boron>`__ |
++--------------------------------------------------------+
+| `sal-echo.yang <https://git.opendaylight.org/gerrit/gi |
+| tweb?p=openflowplugin.git;f=model/model-flow-service/s |
+| rc/main/yang/sal-echo.yang;a=blob;hb=refs/heads/stable |
+| /boron>`__ |
++--------------------------------------------------------+
+| `sal-port.yang <https://git.opendaylight.org/gerrit/gi |
+| tweb?p=openflowplugin.git;f=model/model-flow-service/s |
+| rc/main/yang/sal-port.yang;a=blob;hb=refs/heads/stable |
+| /boron>`__ |
++--------------------------------------------------------+
+| `packet-processing.yang <https://git.opendaylight.org/ |
+| gerrit/gitweb?p=openflowplugin.git;f=model/model-flow- |
+| service/src/main/yang/packet-processing.yang;a=blob;hb |
+| =refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
+| `flow-node-inventory.yang <https://git.opendaylight.or |
+| g/gerrit/gitweb?p=openflowplugin.git;f=model/model-flo |
+| w-service/src/main/yang/flow-node-inventory.yang;a=blo |
+| b;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
| ***Openflow statistics*** |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-queue-statistics.yang <https://git.opend | `YangDOC <https:/ |
-| aylight.org/gerrit/gitweb?p=openflowplugin.git;f=model | /jenkins.opendayl |
-| /model-flow-statistics/src/main/yang/opendaylight-queu | ight.org/releng/v |
-| e-statistics.yang;a=blob;hb=refs/heads/stable/boron>`_ | iew/openflowplugi |
-| _ | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-statis |
-| | tics/target/site/ |
-| | models/opendaylig |
-| | ht-queue-statisti |
-| | cs.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-flow-table-statistics.yang <https://git. | `YangDOC <https:/ |
-| opendaylight.org/gerrit/gitweb?p=openflowplugin.git;f= | /jenkins.opendayl |
-| model/model-flow-statistics/src/main/yang/opendaylight | ight.org/releng/v |
-| -flow-table-statistics.yang;a=blob;hb=refs/heads/stabl | iew/openflowplugi |
-| e/boron>`__ | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-statis |
-| | tics/target/site/ |
-| | models/opendaylig |
-| | ht-flow-table-sta |
-| | tistics.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-port-statistics.yang <https://git.openda | `YangDOC <https:/ |
-| ylight.org/gerrit/gitweb?p=openflowplugin.git;f=model/ | /jenkins.opendayl |
-| model-flow-statistics/src/main/yang/opendaylight-port- | ight.org/releng/v |
-| statistics.yang;a=blob;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-statis |
-| | tics/target/site/ |
-| | models/opendaylig |
-| | ht-port-statistic |
-| | s.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-statistics-types.yang <https://git.opend | `YangDOC <https:/ |
-| aylight.org/gerrit/gitweb?p=openflowplugin.git;f=model | /jenkins.opendayl |
-| /model-flow-statistics/src/main/yang/opendaylight-stat | ight.org/releng/v |
-| istics-types.yang;a=blob;hb=refs/heads/stable/boron>`_ | iew/openflowplugi |
-| _ | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-statis |
-| | tics/target/site/ |
-| | models/opendaylig |
-| | ht-statistics-typ |
-| | es.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-group-statistics.yang <https://git.opend | `YangDOC <https:/ |
-| aylight.org/gerrit/gitweb?p=openflowplugin.git;f=model | /jenkins.opendayl |
-| /model-flow-statistics/src/main/yang/opendaylight-grou | ight.org/releng/v |
-| p-statistics.yang;a=blob;hb=refs/heads/stable/boron>`_ | iew/openflowplugi |
-| _ | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-statis |
-| | tics/target/site/ |
-| | models/opendaylig |
-| | ht-group-statisti |
-| | cs.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-flow-statistics.yang <https://git.openda | `YangDOC <https:/ |
-| ylight.org/gerrit/gitweb?p=openflowplugin.git;f=model/ | /jenkins.opendayl |
-| model-flow-statistics/src/main/yang/opendaylight-flow- | ight.org/releng/v |
-| statistics.yang;a=blob;hb=refs/heads/stable/boron>`__ | iew/openflowplugi |
-| | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-statis |
-| | tics/target/site/ |
-| | models/opendaylig |
-| | ht-flow-statistic |
-| | s.html>`__ |
-+--------------------------------------------------------+-------------------+
-| `opendaylight-meter-statistics.yang <https://git.opend | `YangDOC <https:/ |
-| aylight.org/gerrit/gitweb?p=openflowplugin.git;f=model | /jenkins.opendayl |
-| /model-flow-statistics/src/main/yang/opendaylight-mete | ight.org/releng/v |
-| r-statistics.yang;a=blob;hb=refs/heads/stable/boron>`_ | iew/openflowplugi |
-| _ | n/job/openflowplu |
-| | gin-merge-boron/l |
-| | astSuccessfulBuil |
-| | d/artifact/model/ |
-| | model-flow-statis |
-| | tics/target/site/ |
-| | models/opendaylig |
-| | ht-meter-statisti |
-| | cs.html>`__ |
-+--------------------------------------------------------+-------------------+
++--------------------------------------------------------+
+| `opendaylight-queue-statistics.yang <https://git.opend |
+| aylight.org/gerrit/gitweb?p=openflowplugin.git;f=model |
+| /model-flow-statistics/src/main/yang/opendaylight-queu |
+| e-statistics.yang;a=blob;hb=refs/heads/stable/boron>`_ |
++--------------------------------------------------------+
+| `opendaylight-flow-table-statistics.yang <https://git. |
+| opendaylight.org/gerrit/gitweb?p=openflowplugin.git;f= |
+| model/model-flow-statistics/src/main/yang/opendaylight |
+| -flow-table-statistics.yang;a=blob;hb=refs/heads/stabl |
+| e/boron>`__ |
++--------------------------------------------------------+
+| `opendaylight-port-statistics.yang <https://git.openda |
+| ylight.org/gerrit/gitweb?p=openflowplugin.git;f=model/ |
+| model-flow-statistics/src/main/yang/opendaylight-port- |
+| statistics.yang;a=blob;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
+| `opendaylight-statistics-types.yang <https://git.opend |
+| aylight.org/gerrit/gitweb?p=openflowplugin.git;f=model |
+| /model-flow-statistics/src/main/yang/opendaylight-stat |
+| istics-types.yang;a=blob;hb=refs/heads/stable/boron>`_ |
++--------------------------------------------------------+
+| `opendaylight-group-statistics.yang <https://git.opend |
+| aylight.org/gerrit/gitweb?p=openflowplugin.git;f=model |
+| /model-flow-statistics/src/main/yang/opendaylight-grou |
+| p-statistics.yang;a=blob;hb=refs/heads/stable/boron>`_ |
++--------------------------------------------------------+
+| `opendaylight-flow-statistics.yang <https://git.openda |
+| ylight.org/gerrit/gitweb?p=openflowplugin.git;f=model/ |
+| model-flow-statistics/src/main/yang/opendaylight-flow- |
+| statistics.yang;a=blob;hb=refs/heads/stable/boron>`__ |
++--------------------------------------------------------+
+| `opendaylight-meter-statistics.yang <https://git.opend |
+| aylight.org/gerrit/gitweb?p=openflowplugin.git;f=model |
+| /model-flow-statistics/src/main/yang/opendaylight-mete |
+| r-statistics.yang;a=blob;hb=refs/heads/stable/boron>`_ |
++--------------------------------------------------------+
Karaf feature tree
------------------
Introduction
~~~~~~~~~~~~
-We need to translate OpenFlow messages coming up from the `OpenFlow
-Protocol Library <#_openflow_protocol_library_developer_guide>`__ into
+We need to translate OpenFlow messages coming up from the :ref:`OpenFlow
+Protocol Library <openflow-protocol-library>` into
MD-SAL Notification objects and then publish them to the MD-SAL.
Mechanics
+.. _openflow-protocol-library:
+
OpenFlow Protocol Library Developer Guide
=========================================
TLS Support
-----------
- **Note**
+.. note::
see OpenFlow Plugin Developper Guide
OpenDaylight controller uses the library project to interact with an OVS
instance.
- **Note**
+.. note::
Read the OVSDB User Guide before you begin development.
1. Start ODL, from the unzipped directory
-::
+ ::
- bin/karaf
+ bin/karaf
-1. Once karaf has started, and you see the OpenDaylight ascii art in the
+2. Once karaf has started, and you see the OpenDaylight ascii art in the
console, the last step is to start the OVSDB plugin framework with
the following command in the karaf console:
-::
+ ::
- feature:install odl-ovsdb-openstack
+ feature:install odl-ovsdb-openstack
Sample output from the Karaf console
''''''''''''''''''''''''''''''''''''
1. Start the controller.
-::
-
- vagrant up devstack-control
- vagrant ssh devstack-control
- cd devstack
- ./stack.sh
+ ::
-1. Run the following:
+ vagrant up devstack-control
+ vagrant ssh devstack-control
+ cd devstack
+ ./stack.sh
-::
+2. Run the following:
- vagrant up devstack-compute-1
- vagrant ssh devstack-compute-1
- cd devstack
- ./stack.sh
+ ::
-1. To start testing, create a new VM.
+ vagrant up devstack-compute-1
+ vagrant ssh devstack-compute-1
+ cd devstack
+ ./stack.sh
-::
+3. To start testing, create a new VM.
- nova boot --flavor m1.tiny --image $(nova image-list | grep 'cirros-0.3.1-x86_64-uec\s' | awk '{print $2}') --nic net-id=$(neutron net-list | grep private | awk '{print $2}') test
+ ::
-To create three, use the following:
+ nova boot --flavor m1.tiny --image $(nova image-list | grep 'cirros-0.3.1-x86_64-uec\s' | awk '{print $2}') --nic net-id=$(neutron net-list | grep private | awk '{print $2}') test
+
+ To create three, use the following:
-::
+ ::
- nova boot --flavor m1.tiny --image $(nova image-list | grep 'cirros-0.3.1-x86_64-uec\s' | awk '{print $2}') --nic net-id=$(neutron net-list | grep private | awk '{print $2}') --num-instances 3 test
+ nova boot --flavor m1.tiny --image $(nova image-list | grep 'cirros-0.3.1-x86_64-uec\s' | awk '{print $2}') --nic net-id=$(neutron net-list | grep private | awk '{print $2}') --num-instances 3 test
**To get a mininet installation for testing:.**
3. Add the Security Group and Rules.
- **Note**
+ .. note::
- This is no different than what users normally do in regular
- openstack deployments.
+ This is no different than what users normally do in regular
+ OpenStack deployments.
-::
+ ::
- neutron security-group-create group1 --description "Group 1"
- neutron security-group-list
- neutron security-group-rule-create --direction ingress --protocol tcp group1
+ neutron security-group-create group1 --description "Group 1"
+ neutron security-group-list
+ neutron security-group-rule-create --direction ingress --protocol tcp group1
-1. Start the tenant, specifying the security-group.
+4. Start the tenant, specifying the security-group.
-::
+ ::
- nova boot --flavor m1.tiny \
- --image $(nova image-list | grep 'cirros-0.3.1-x86_64-uec\s' | awk '{print $2}') \
- --nic net-id=$(neutron net-list | grep 'vxlan2' | awk '{print $2}') vxlan2 \
- --security-groups group1
+ nova boot --flavor m1.tiny \
+ --image $(nova image-list | grep 'cirros-0.3.1-x86_64-uec\s' | awk '{print $2}') \
+ --nic net-id=$(neutron net-list | grep 'vxlan2' | awk '{print $2}') vxlan2 \
+ --security-groups group1
Examples: Rules supported
'''''''''''''''''''''''''
neutron security-group-rule-create --direction egress --protocol tcp --port-range-min 443 --remote-ip-prefix 172.16.240.128/25 group7
**Reference
-gist**:https://gist.github.com/anonymous/1543a410d57f491352c8[Gist]
+gist**: `Gist <https://gist.github.com/anonymous/1543a410d57f491352c8>`__
Security group rules supported in ODL
'''''''''''''''''''''''''''''''''''''
-The following rules formata are supported in the current implementation.
+The following rules formats are supported in the current implementation.
The direction (ingress/egress) is always expected. Rules are implemented
such that tcp-syn packets that do not satisfy the rules are dropped.
2. `Install
Vagrant <http://docs.vagrantup.com/v2/installation/index.html>`__.
-1. Enable the L3 Forwarding feature:
+3. Enable the L3 Forwarding feature:
-::
+ ::
- echo 'ovsdb.l3.fwd.enabled=yes' >> ./opendaylight/configuration/config.ini
- echo 'ovsdb.l3gateway.mac=${GATEWAY_MAC}' >> ./configuration/config.ini
+ echo 'ovsdb.l3.fwd.enabled=yes' >> ./opendaylight/configuration/config.ini
+ echo 'ovsdb.l3gateway.mac=${GATEWAY_MAC}' >> ./configuration/config.ini
-1. Run the following commands to get the odl neutron drivers:
+4. Run the following commands to get the odl neutron drivers:
-::
+ ::
- git clone https://github.com/dave-tucker/odl-neutron-drivers.git
- cd odl-neutron-drivers
- vagrant up devstack-control devstack-compute-1
+ git clone https://github.com/dave-tucker/odl-neutron-drivers.git
+ cd odl-neutron-drivers
+ vagrant up devstack-control devstack-compute-1
-1. Use ssh to go to the control node, and clone odl-neutron-drivers
+5. Use ssh to go to the control node, and clone odl-neutron-drivers
again:
-::
+ ::
- vagrant ssh devstack-control
- git clone https://github.com/dave-tucker/odl-neutron-drivers.git
- cd odl-neutron-drivers
- sudo python setup.py install
- *leave this shell open*
+ vagrant ssh devstack-control
+ git clone https://github.com/dave-tucker/odl-neutron-drivers.git
+ cd odl-neutron-drivers
+ sudo python setup.py install
+ *leave this shell open*
-1. Start odl, as mentioned in `running Karaf feature
+6. Start odl, as mentioned in `running Karaf feature
section <#ovsdbStartingOdl>`__.
-2. To see processing of neutron event related to L3, do this from
+7. To see processing of neutron event related to L3, do this from
prompt:
-::
+ ::
- log:set debug org.opendaylight.ovsdb.openstack.netvirt.impl.NeutronL3Adapter
+ log:set debug org.opendaylight.ovsdb.openstack.netvirt.impl.NeutronL3Adapter
-1. From shell, do one of the following: open on ssh into control node or
+8. From shell, do one of the following: open on ssh into control node or
vagrant ssh devstack-control.
-::
+ ::
- cd ~/devstack && ./stack.sh
+ cd ~/devstack && ./stack.sh
-1. From a new shell in the host system, run the following:
+9. From a new shell in the host system, run the following:
-::
+ ::
- cd odl-neutron-drivers
- vagrant ssh devstack-compute-1
- cd ~/devstack && ./stack.sh
+ cd odl-neutron-drivers
+ vagrant ssh devstack-compute-1
+ cd ~/devstack && ./stack.sh
OpenStack workflow
''''''''''''''''''
1. Set up authentication. From shell on stack control or vagrant ssh
devstack-control:
-::
+ ::
- source openrc admin admin
+ source openrc admin admin
-::
+ rm -f id_rsa_demo* ; ssh-keygen -t rsa -b 2048 -N -f id_rsa_demo
+ nova keypair-add --pub-key id_rsa_demo.pub demo_key
+ # nova keypair-list
- rm -f id_rsa_demo* ; ssh-keygen -t rsa -b 2048 -N -f id_rsa_demo
- nova keypair-add --pub-key id_rsa_demo.pub demo_key
- # nova keypair-list
+2. Create two networks and two subnets.
-1. Create two networks and two subnets.
+ ::
-::
+ neutron net-create net1 --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
+ --provider:network_type gre --provider:segmentation_id 555
- neutron net-create net1 --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
- --provider:network_type gre --provider:segmentation_id 555
+ neutron subnet-create --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
+ net1 10.0.0.0/16 --name subnet1 --dns-nameserver 8.8.8.8
-::
-
- neutron subnet-create --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
- net1 10.0.0.0/16 --name subnet1 --dns-nameserver 8.8.8.8
+ neutron net-create net2 --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
+ --provider:network_type gre --provider:segmentation_id 556
-::
+ neutron subnet-create --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
+ net2 20.0.0.0/16 --name subnet2 --dns-nameserver 8.8.8.8
- neutron net-create net2 --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
- --provider:network_type gre --provider:segmentation_id 556
-
-::
+3. Create a router, and add an interface to each of the two subnets.
- neutron subnet-create --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
- net2 20.0.0.0/16 --name subnet2 --dns-nameserver 8.8.8.8
+ ::
-1. Create a router, and add an interface to each of the two subnets.
-
-::
-
- neutron router-create demorouter --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}')
- neutron router-interface-add demorouter subnet1
- neutron router-interface-add demorouter subnet2
+ neutron router-create demorouter --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}')
+ neutron router-interface-add demorouter subnet1
+ neutron router-interface-add demorouter subnet2
# neutron router-port-list demorouter
-1. Create two tenant instances.
+4. Create two tenant instances.
-::
-
- nova boot --poll --flavor m1.nano --image $(nova image-list | grep 'cirros-0.3.2-x86_64-uec\s' | awk '{print $2}') \
- --nic net-id=$(neutron net-list | grep -w net1 | awk '{print $2}'),v4-fixed-ip=10.0.0.10 \
- --availability-zone nova:devstack-control \
- --key-name demo_key host10
+ ::
-::
+ nova boot --poll --flavor m1.nano --image $(nova image-list | grep 'cirros-0.3.2-x86_64-uec\s' | awk '{print $2}') \
+ --nic net-id=$(neutron net-list | grep -w net1 | awk '{print $2}'),v4-fixed-ip=10.0.0.10 \
+ --availability-zone nova:devstack-control \
+ --key-name demo_key host10
- nova boot --poll --flavor m1.nano --image $(nova image-list | grep 'cirros-0.3.2-x86_64-uec\s' | awk '{print $2}') \
- --nic net-id=$(neutron net-list | grep -w net2 | awk '{print $2}'),v4-fixed-ip=20.0.0.20 \
- --availability-zone nova:devstack-compute-1 \
- --key-name demo_key host20
+ nova boot --poll --flavor m1.nano --image $(nova image-list | grep 'cirros-0.3.2-x86_64-uec\s' | awk '{print $2}') \
+ --nic net-id=$(neutron net-list | grep -w net2 | awk '{print $2}'),v4-fixed-ip=20.0.0.20 \
+ --availability-zone nova:devstack-compute-1 \
+ --key-name demo_key host20
Limitations
'''''''''''
3. Create a Loadbalancer pool *X*.
-::
+ ::
- neutron lb-pool-create --name http-pool --lb-method ROUND_ROBIN --protocol HTTP --subnet-id XYZ
+ neutron lb-pool-create --name http-pool --lb-method ROUND_ROBIN --protocol HTTP --subnet-id XYZ
-1. Create a Loadbalancer pool member *Y* and associate with pool *X*.
+4. Create a Loadbalancer pool member *Y* and associate with pool *X*.
-::
+ ::
- neutron lb-member-create --address 10.0.0.10 --protocol-port 80 http-pool
- neutron lb-member-create --address 10.0.0.11 --protocol-port 80 http-pool
- neutron lb-member-create --address 10.0.0.12 --protocol-port 80 http-pool
- neutron lb-member-create --address 10.0.0.13 --protocol-port 80 http-pool
+ neutron lb-member-create --address 10.0.0.10 --protocol-port 80 http-pool
+ neutron lb-member-create --address 10.0.0.11 --protocol-port 80 http-pool
+ neutron lb-member-create --address 10.0.0.12 --protocol-port 80 http-pool
+ neutron lb-member-create --address 10.0.0.13 --protocol-port 80 http-pool
-1. Create a Loadbalancer instance *Z*, and associate pool *X* and VIP
+5. Create a Loadbalancer instance *Z*, and associate pool *X* and VIP
*B* with it.
-::
+ ::
- neutron lb-vip-create --name http-vip --protocol-port 80 --protocol HTTP --subnet-id XYZ http-pool
+ neutron lb-vip-create --name http-vip --protocol-port 80 --protocol HTTP --subnet-id XYZ http-pool
Implementation
''''''''''''''
- Proactive forward rules:
-::
+ ::
- sudo ovs-ofctl -O OpenFlow13 add-flow s1 "table=10,reg0=0,ip,nw_dst=10.0.0.5,actions=load:0x1->NXM_NX_REG0[[]],multipath(symmetric_l4, 1024, modulo_n, 4, 0, NXM_NX_REG1[0..12]),resubmit(,10)"
- sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=0,actions=mod_dl_dst:00:00:00:00:00:10,mod_nw_dst:10.0.0.10,goto_table:20
- sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=1,actions=mod_dl_dst:00:00:00:00:00:11,mod_nw_dst:10.0.0.11,goto_table:20
- sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=2,actions=mod_dl_dst:00:00:00:00:00:12,mod_nw_dst:10.0.0.12,goto_table:20
- sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=3,actions=mod_dl_dst:00:00:00:00:00:13,mod_nw_dst:10.0.0.13,goto_table:20
+ sudo ovs-ofctl -O OpenFlow13 add-flow s1 "table=10,reg0=0,ip,nw_dst=10.0.0.5,actions=load:0x1->NXM_NX_REG0[[]],multipath(symmetric_l4, 1024, modulo_n, 4, 0, NXM_NX_REG1[0..12]),resubmit(,10)"
+ sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=0,actions=mod_dl_dst:00:00:00:00:00:10,mod_nw_dst:10.0.0.10,goto_table:20
+ sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=1,actions=mod_dl_dst:00:00:00:00:00:11,mod_nw_dst:10.0.0.11,goto_table:20
+ sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=2,actions=mod_dl_dst:00:00:00:00:00:12,mod_nw_dst:10.0.0.12,goto_table:20
+ sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=3,actions=mod_dl_dst:00:00:00:00:00:13,mod_nw_dst:10.0.0.13,goto_table:20
- Proactive reverse rules:
-::
+ ::
- sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,ip,tcp,tp_src=80,actions=mod_dl_src:00:00:00:00:00:05,mod_nw_src:10.0.0.5,goto_table:20
+ sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,ip,tcp,tp_src=80,actions=mod_dl_src:00:00:00:00:00:05,mod_nw_src:10.0.0.5,goto_table:20
OVSDB project code
''''''''''''''''''
``operationResults = transactionBuilder.execute().get();``
- **Note**
+ .. note::
Although the "select" operation is supported in the OVSDB
library, the library implementation is a little different from
- `OpenStack Neutron ML2
Plugin <https://wiki.openstack.org/wiki/Neutron/ML2>`__
-|Openstack Integration|
+.. figure:: images/openstack_integration.png
+
+ OpenStack Integration
OVSDB Service Function Chaining Developer Guide
-----------------------------------------------
odl-ovsdb-openstack feature as well as the openflowplugin, neutron and
sfc features are installed.
-feature:install odl-ovsdb-sfc-ui ---
+``feature:install odl-ovsdb-sfc-ui``
Verify the required features are installed:
-opendaylight-user@root>feature:list -i \| grep ovsdb
-
-odl-ovsdb-southbound-api \| 1.2.1-SNAPSHOT \| x \|
-odl-ovsdb-southbound-1.2.1-SNAPSHOT \| OpenDaylight
- southbound :: api
-
-odl-ovsdb-southbound-impl \| 1.2.1-SNAPSHOT \| x \|
-odl-ovsdb-southbound-1.2.1-SNAPSHOT \| OpenDaylight :: southbound
- impl
-
-odl-ovsdb-southbound-impl-rest \| 1.2.1-SNAPSHOT \| x \|
-odl-ovsdb-southbound-1.2.1-SNAPSHOT \| OpenDaylight :: southbound ::
-impl
- REST
-
-odl-ovsdb-southbound-impl-ui \| 1.2.1-SNAPSHOT \| x \|
-odl-ovsdb-southbound-1.2.1-SNAPSHOT \| OpenDaylight :: southbound ::
-impl
- UI
-
-odl-ovsdb-library \| 1.2.1-SNAPSHOT \| x \|
-odl-ovsdb-library-1.2.1-SNAPSHOT \| OpenDaylight
- library
-
-odl-ovsdb-openstack \| 1.2.1-SNAPSHOT \| x \| ovsdb-1.2.1-SNAPSHOT \|
-OpenDaylight :: OVSDB
- OpenStack Network Virtual
-
-odl-ovsdb-sfc-api \| 1.2.1-SNAPSHOT \| x \| odl-ovsdb-sfc-1.2.1-SNAPSHOT
-\| OpenDaylight :: ovsdb-sfc
- api
-
-odl-ovsdb-sfc \| 1.2.1-SNAPSHOT \| x \| odl-ovsdb-sfc-1.2.1-SNAPSHOT \|
-OpenDaylight
- ovsdb-sfc
-
-odl-ovsdb-sfc-rest \| 1.2.1-SNAPSHOT \| x \|
-odl-ovsdb-sfc-1.2.1-SNAPSHOT \| OpenDaylight :: ovsdb-sfc
- REST
-
-odl-ovsdb-sfc-ui \| 1.2.1-SNAPSHOT \| x \| odl-ovsdb-sfc-1.2.1-SNAPSHOT
-\| OpenDaylight :: ovsdb-sfc
- UI
-
-opendaylight-user@root>feature:list -i \| grep sfc odl-sfc-model \|
-0.2.0-SNAPSHOT \| x \| odl-sfc-0.2.0-SNAPSHOT \| OpenDaylight :: sfc ::
-Model odl-sfc-provider \| 0.2.0-SNAPSHOT \| x \| odl-sfc-0.2.0-SNAPSHOT
-\| OpenDaylight :: sfc :: Provider odl-sfc-provider-rest \|
-0.2.0-SNAPSHOT \| x \| odl-sfc-0.2.0-SNAPSHOT \| OpenDaylight :: sfc ::
-Provider odl-sfc-ovs \| 0.2.0-SNAPSHOT \| x \| odl-sfc-0.2.0-SNAPSHOT \|
-OpenDaylight :: OpenvSwitch odl-sfcofl2 \| 0.2.0-SNAPSHOT \| x \|
-odl-sfc-0.2.0-SNAPSHOT \| OpenDaylight :: sfcofl2 odl-ovsdb-sfc-test \|
-1.2.1-SNAPSHOT \| x \| odl-ovsdb-sfc-test1.2.1-SNAPSHOT \| OpenDaylight
-:: ovsdb-sfc-test odl-ovsdb-sfc-api \| 1.2.1-SNAPSHOT \| x \|
-odl-ovsdb-sfc-1.2.1-SNAPSHOT \| OpenDaylight :: ovsdb-sfc :: api
-odl-ovsdb-sfc \| 1.2.1-SNAPSHOT \| x \| odl-ovsdb-sfc-1.2.1-SNAPSHOT \|
-OpenDaylight :: ovsdb-sfc odl-ovsdb-sfc-rest \| 1.2.1-SNAPSHOT \| x \|
-odl-ovsdb-sfc-1.2.1-SNAPSHOT \| OpenDaylight :: ovsdb-sfc :: REST
-odl-ovsdb-sfc-ui \| 1.2.1-SNAPSHOT \| x \| odl-ovsdb-sfc-1.2.1-SNAPSHOT
-\| OpenDaylight :: ovsdb-sfc :: UI
-
-opendaylight-user@root>feature:list -i \| grep neutron
-odl-neutron-service \| 0.6.0-SNAPSHOT \| x \| odl-neutron-0.6.0-SNAPSHOT
-\| OpenDaylight :: Neutron :: API odl-neutron-northbound-api \|
-0.6.0-SNAPSHOT \| x \| odl-neutron-0.6.0-SNAPSHOT \| OpenDaylight ::
-Neutron :: Northbound odl-neutron-spi \| 0.6.0-SNAPSHOT \| x \|
-odl-neutron-0.6.0-SNAPSHOT \| OpenDaylight :: Neutron :: API
-odl-neutron-transcriber \| 0.6.0-SNAPSHOT \| x \|
-odl-neutron-0.6.0-SNAPSHOT \| OpenDaylight :: Neutron :: Implementation
----
+::
+
+ opendaylight-user@root>feature:list -i | grep ovsdb
+ odl-ovsdb-southbound-api | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight southbound :: api
+ odl-ovsdb-southbound-impl | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound impl
+ odl-ovsdb-southbound-impl-rest | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: impl REST
+ odl-ovsdb-southbound-impl-ui | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: impl UI
+ odl-ovsdb-library | 1.2.1-SNAPSHOT | x | odl-ovsdb-library-1.2.1-SNAPSHOT | OpenDaylight library
+ odl-ovsdb-openstack | 1.2.1-SNAPSHOT | x | ovsdb-1.2.1-SNAPSHOT | OpenDaylight :: OVSDB OpenStack Network Virtual
+ odl-ovsdb-sfc-api | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc api
+ odl-ovsdb-sfc | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight ovsdb-sfc
+ odl-ovsdb-sfc-rest | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc REST
+ odl-ovsdb-sfc-ui | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc UI
+
+ opendaylight-user@root>feature:list -i | grep sfc
+ odl-sfc-model | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: sfc :: Model
+ odl-sfc-provider | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: sfc :: Provider
+ odl-sfc-provider-rest | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: sfc :: Provider
+ odl-sfc-ovs | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: OpenvSwitch
+ odl-sfcofl2 | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: sfcofl2
+ odl-ovsdb-sfc-test | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-test1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc-test
+ odl-ovsdb-sfc-api | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc :: api
+ odl-ovsdb-sfc | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc
+ odl-ovsdb-sfc-rest | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc :: REST
+ odl-ovsdb-sfc-ui | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc :: UI
+
+ opendaylight-user@root>feature:list -i | grep neutron
+ odl-neutron-service | 0.6.0-SNAPSHOT | x | odl-neutron-0.6.0-SNAPSHOT | OpenDaylight :: Neutron :: API
+ odl-neutron-northbound-api | 0.6.0-SNAPSHOT | x | odl-neutron-0.6.0-SNAPSHOT | OpenDaylight :: Neutron :: Northbound
+ odl-neutron-spi | 0.6.0-SNAPSHOT | x | odl-neutron-0.6.0-SNAPSHOT | OpenDaylight :: Neutron :: API
+ odl-neutron-transcriber | 0.6.0-SNAPSHOT | x | odl-neutron-0.6.0-SNAPSHOT | OpenDaylight :: Neutron :: Implementation
OVSDB NetVirt Service Function Chaining Example
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://localhost:8181/restconf/config/ietf-access-control-list:access-lists
-{ "access-lists": { "acl": [ { "acl-name": "http-acl",
-"access-list-entries": { "ace": [ { "rule-name": "http-rule", "matches":
-{ "source-port-range": { "lower-port": 0, "upper-port": 0 }, "protocol":
-6, "destination-port-range": { "lower-port": 80, "upper-port": 80 } },
-"actions": { "netvirt-sfc-acl:sfc-name": "http-sfc" } } ] } } ] } } ---
+::
+
+ {
+ "access-lists": {
+ "acl": [
+ {
+ "acl-name": "http-acl",
+ "access-list-entries": {
+ "ace": [
+ {
+ "rule-name": "http-rule",
+ "matches": {
+ "source-port-range": {
+ "lower-port": 0,
+ "upper-port": 0
+ },
+ "protocol": 6,
+ "destination-port-range": {
+ "lower-port": 80,
+ "upper-port": 80
+ }
+ },
+ "actions": {
+ "netvirt-sfc-acl:sfc-name": "http-sfc"
+ }
+ }
+ ]
+ }
+ }
+ ]
+ }
+ }
When the chain is rendered using the Rendered Service Path RPC,
NetvirtSfc will add the classification flows. The classification flows
identifying the NSH NSI. In this case the chain is identified with an
NSP of 4 and the NSI is 255 to indicate the beginning of the chain.
-sudo ovs-ofctl --protocol=OpenFlow13 dump-flows br-int OFPST\_FLOW reply
-(OF1.3) (xid=0x2): cookie=0x0, duration=17.157s, table=0, n\_packets=0,
-n\_bytes=0, priority=6 actions=goto\_table:1 cookie=0x14,
-duration=10.692s, table=0, n\_packets=0, n\_bytes=0,
-priority=400,udp,in\_port=4,tp\_dst=6633 actions=LOCAL cookie=0x0,
-duration=17.134s, table=0, n\_packets=0, n\_bytes=0, dl\_type=0x88cc
-actions=CONTROLLER:65535 cookie=0x14, duration=10.717s, table=0,
-n\_packets=0, n\_bytes=0, priority=350,nsp=4 actions=goto\_table:152
-cookie=0x14, duration=10.688s, table=0, n\_packets=0, n\_bytes=0,
-priority=400,udp,nw\_dst=10.2.1.1,tp\_dst=6633 actions=output:4
-cookie=0x0, duration=17.157s, table=1, n\_packets=0, n\_bytes=0,
-priority=0 actions=goto\_table:11 cookie=0x1110070000040254,
-duration=10.608s, table=1, n\_packets=0, n\_bytes=0,
-priority=40000,reg0=0x1,nsp=4,nsi=254,in\_port=1 actions=goto\_table:21
-cookie=0x0, duration=17.157s, table=11, n\_packets=0, n\_bytes=0,
-priority=0 actions=goto\_table:21 cookie=0x1110060000040254,
-duration=10.625s, table=11, n\_packets=0, n\_bytes=0,
-nsp=4,nsi=254,in\_port=4
-actions=load:0x1→NXM\_NX\_REG0[],move:NXM\_NX\_NSH\_C2[]→NXM\_NX\_TUN\_ID[0..31],resubmit(1,1)
-cookie=0x1110010000040255, duration=10.615s, table=11, n\_packets=0,
-n\_bytes=0, tcp,reg0=0x1,tp\_dst=80
-actions=move:NXM\_NX\_TUN\_ID[0..31]→NXM\_NX\_NSH\_C2[],set\_nshc1:0xc0a83246,set\_nsp:0x4,set\_nsi:255,load:0xa020101→NXM\_NX\_TUN\_IPV4\_DST[],load:0x4→NXM\_NX\_TUN\_ID[0..31],resubmit(,0)
-cookie=0x0, duration=17.157s, table=21, n\_packets=0, n\_bytes=0,
-priority=0 actions=goto\_table:31 cookie=0x1110040000000000,
-duration=10.765s, table=21, n\_packets=0, n\_bytes=0,
-priority=1024,arp,in\_port=LOCAL,arp\_tpa=10.2.1.1,arp\_op=1
-actions=move:NXM\_OF\_ETH\_SRC[]→NXM\_OF\_ETH\_DST[],set\_field:f6:00:00:0f:00:01→eth\_src,load:0x2→NXM\_OF\_ARP\_OP[],move:NXM\_NX\_ARP\_SHA[]→NXM\_NX\_ARP\_THA[],move:NXM\_OF\_ARP\_SPA[]→NXM\_OF\_ARP\_TPA[],load:0xf600000f0001→NXM\_NX\_ARP\_SHA[],load:0xa020101→NXM\_OF\_ARP\_SPA[],IN\_PORT
-cookie=0x0, duration=17.157s, table=31, n\_packets=0, n\_bytes=0,
-priority=0 actions=goto\_table:41 cookie=0x0, duration=17.157s,
-table=41, n\_packets=0, n\_bytes=0, priority=0 actions=goto\_table:51
-cookie=0x0, duration=17.157s, table=51, n\_packets=0, n\_bytes=0,
-priority=0 actions=goto\_table:61 cookie=0x0, duration=17.142s,
-table=61, n\_packets=0, n\_bytes=0, priority=0 actions=goto\_table:71
-cookie=0x0, duration=17.140s, table=71, n\_packets=0, n\_bytes=0,
-priority=0 actions=goto\_table:81 cookie=0x0, duration=17.116s,
-table=81, n\_packets=0, n\_bytes=0, priority=0 actions=goto\_table:91
-cookie=0x0, duration=17.116s, table=91, n\_packets=0, n\_bytes=0,
-priority=0 actions=goto\_table:101 cookie=0x0, duration=17.107s,
-table=101, n\_packets=0, n\_bytes=0, priority=0 actions=goto\_table:111
-cookie=0x0, duration=17.083s, table=111, n\_packets=0, n\_bytes=0,
-priority=0 actions=drop cookie=0x14, duration=11.042s, table=150,
-n\_packets=0, n\_bytes=0, priority=5 actions=goto\_table:151
-cookie=0x14, duration=11.027s, table=151, n\_packets=0, n\_bytes=0,
-priority=5 actions=goto\_table:152 cookie=0x14, duration=11.010s,
-table=152, n\_packets=0, n\_bytes=0, priority=5 actions=goto\_table:158
-cookie=0x14, duration=10.668s, table=152, n\_packets=0, n\_bytes=0,
-priority=650,nsp=4,nsi=255
-actions=load:0xa020101→NXM\_NX\_TUN\_IPV4\_DST[],goto\_table:158
-cookie=0x14, duration=10.995s, table=158, n\_packets=0, n\_bytes=0,
-priority=5 actions=drop cookie=0xba5eba11ba5eba11, duration=10.645s,
-table=158, n\_packets=0, n\_bytes=0,
-priority=751,nsp=4,nsi=255,in\_port=4
-actions=move:NXM\_NX\_NSH\_C1[]→NXM\_NX\_NSH\_C1[],move:NXM\_NX\_NSH\_C2[]→NXM\_NX\_NSH\_C2[],move:NXM\_NX\_TUN\_ID[0..31]→NXM\_NX\_TUN\_ID[0..31],IN\_PORT
-cookie=0xba5eba11ba5eba11, duration=10.590s, table=158, n\_packets=0,
-n\_bytes=0, priority=751,nsp=4,nsi=254,in\_port=4
-actions=move:NXM\_NX\_NSI[]→NXM\_NX\_NSI[],move:NXM\_NX\_NSP[]→NXM\_NX\_NSP[],move:NXM\_NX\_NSH\_C1[]→NXM\_NX\_TUN\_IPV4\_DST[],move:NXM\_NX\_NSH\_C2[]→NXM\_NX\_TUN\_ID[0..31],IN\_PORT
-cookie=0xba5eba11ba5eba11, duration=10.640s, table=158, n\_packets=0,
-n\_bytes=0, priority=750,nsp=4,nsi=255
-actions=move:NXM\_NX\_NSH\_C1[]→NXM\_NX\_NSH\_C1[],move:NXM\_NX\_NSH\_C2[]→NXM\_NX\_NSH\_C2[],move:NXM\_NX\_TUN\_ID[0..31]→NXM\_NX\_TUN\_ID[0..31],output:4
-cookie=0xba5eba11ba5eba11, duration=10.571s, table=158, n\_packets=0,
-n\_bytes=0, priority=761,nsp=4,nsi=254,nshc1=3232248390,in\_port=4
-actions=move:NXM\_NX\_NSI[]→NXM\_NX\_NSI[],move:NXM\_NX\_NSP[]→NXM\_NX\_NSP[],move:NXM\_NX\_NSH\_C1[]→NXM\_NX\_TUN\_IPV4\_DST[],move:NXM\_NX\_NSH\_C2[]→NXM\_NX\_TUN\_ID[0..31],set\_nshc1:0,resubmit(,11)
----
+::
+
+ sudo ovs-ofctl --protocol=OpenFlow13 dump-flows br-int
+ OFPST_FLOW reply (OF1.3) (xid=0x2):
+ cookie=0x0, duration=17.157s, table=0, n_packets=0, n_bytes=0, priority=6 actions=goto_table:1
+ cookie=0x14, duration=10.692s, table=0, n_packets=0, n_bytes=0, priority=400,udp,in_port=4,tp_dst=6633 actions=LOCAL
+ cookie=0x0, duration=17.134s, table=0, n_packets=0, n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535
+ cookie=0x14, duration=10.717s, table=0, n_packets=0, n_bytes=0, priority=350,nsp=4 actions=goto_table:152
+ cookie=0x14, duration=10.688s, table=0, n_packets=0, n_bytes=0, priority=400,udp,nw_dst=10.2.1.1,tp_dst=6633 actions=output:4
+ cookie=0x0, duration=17.157s, table=1, n_packets=0, n_bytes=0, priority=0 actions=goto_table:11
+ cookie=0x1110070000040254, duration=10.608s, table=1, n_packets=0, n_bytes=0, priority=40000,reg0=0x1,nsp=4,nsi=254,in_port=1 actions=goto_table:21
+ cookie=0x0, duration=17.157s, table=11, n_packets=0, n_bytes=0, priority=0 actions=goto_table:21
+ cookie=0x1110060000040254, duration=10.625s, table=11, n_packets=0, n_bytes=0, nsp=4,nsi=254,in_port=4 actions=load:0x1->NXM_NX_REG0[],move:NXM_NX_NSH_C2[]->NXM_NX_TUN_ID[0..31],resubmit(1,1)
+ cookie=0x1110010000040255, duration=10.615s, table=11, n_packets=0, n_bytes=0, tcp,reg0=0x1,tp_dst=80 actions=move:NXM_NX_TUN_ID[0..31]->NXM_NX_NSH_C2[],set_nshc1:0xc0a83246,set_nsp:0x4,set_nsi:255,load:0xa020101->NXM_NX_TUN_IPV4_DST[],load:0x4->NXM_NX_TUN_ID[0..31],resubmit(,0)
+ cookie=0x0, duration=17.157s, table=21, n_packets=0, n_bytes=0, priority=0 actions=goto_table:31
+ cookie=0x1110040000000000, duration=10.765s, table=21, n_packets=0, n_bytes=0, priority=1024,arp,in_port=LOCAL,arp_tpa=10.2.1.1,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:f6:00:00:0f:00:01->eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xf600000f0001->NXM_NX_ARP_SHA[],load:0xa020101->NXM_OF_ARP_SPA[],IN_PORT
+ cookie=0x0, duration=17.157s, table=31, n_packets=0, n_bytes=0, priority=0 actions=goto_table:41
+ cookie=0x0, duration=17.157s, table=41, n_packets=0, n_bytes=0, priority=0 actions=goto_table:51
+ cookie=0x0, duration=17.157s, table=51, n_packets=0, n_bytes=0, priority=0 actions=goto_table:61
+ cookie=0x0, duration=17.142s, table=61, n_packets=0, n_bytes=0, priority=0 actions=goto_table:71
+ cookie=0x0, duration=17.140s, table=71, n_packets=0, n_bytes=0, priority=0 actions=goto_table:81
+ cookie=0x0, duration=17.116s, table=81, n_packets=0, n_bytes=0, priority=0 actions=goto_table:91
+ cookie=0x0, duration=17.116s, table=91, n_packets=0, n_bytes=0, priority=0 actions=goto_table:101
+ cookie=0x0, duration=17.107s, table=101, n_packets=0, n_bytes=0, priority=0 actions=goto_table:111
+ cookie=0x0, duration=17.083s, table=111, n_packets=0, n_bytes=0, priority=0 actions=drop
+ cookie=0x14, duration=11.042s, table=150, n_packets=0, n_bytes=0, priority=5 actions=goto_table:151
+ cookie=0x14, duration=11.027s, table=151, n_packets=0, n_bytes=0, priority=5 actions=goto_table:152
+ cookie=0x14, duration=11.010s, table=152, n_packets=0, n_bytes=0, priority=5 actions=goto_table:158
+ cookie=0x14, duration=10.668s, table=152, n_packets=0, n_bytes=0, priority=650,nsp=4,nsi=255 actions=load:0xa020101->NXM_NX_TUN_IPV4_DST[],goto_table:158
+ cookie=0x14, duration=10.995s, table=158, n_packets=0, n_bytes=0, priority=5 actions=drop
+ cookie=0xba5eba11ba5eba11, duration=10.645s, table=158, n_packets=0, n_bytes=0, priority=751,nsp=4,nsi=255,in_port=4 actions=move:NXM_NX_NSH_C1[]->NXM_NX_NSH_C1[],move:NXM_NX_NSH_C2[]->NXM_NX_NSH_C2[],move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],IN_PORT
+ cookie=0xba5eba11ba5eba11, duration=10.590s, table=158, n_packets=0, n_bytes=0, priority=751,nsp=4,nsi=254,in_port=4 actions=move:NXM_NX_NSI[]->NXM_NX_NSI[],move:NXM_NX_NSP[]->NXM_NX_NSP[],move:NXM_NX_NSH_C1[]->NXM_NX_TUN_IPV4_DST[],move:NXM_NX_NSH_C2[]->NXM_NX_TUN_ID[0..31],IN_PORT
+ cookie=0xba5eba11ba5eba11, duration=10.640s, table=158, n_packets=0, n_bytes=0, priority=750,nsp=4,nsi=255 actions=move:NXM_NX_NSH_C1[]->NXM_NX_NSH_C1[],move:NXM_NX_NSH_C2[]->NXM_NX_NSH_C2[],move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],output:4
+ cookie=0xba5eba11ba5eba11, duration=10.571s, table=158, n_packets=0, n_bytes=0, priority=761,nsp=4,nsi=254,nshc1=3232248390,in_port=4 actions=move:NXM_NX_NSI[]->NXM_NX_NSI[],move:NXM_NX_NSP[]->NXM_NX_NSP[],move:NXM_NX_NSH_C1[]->NXM_NX_TUN_IPV4_DST[],move:NXM_NX_NSH_C2[]->NXM_NX_TUN_ID[0..31],set_nshc1:0,resubmit(,11)
+
Configuration
~~~~~~~~~~~~~
http://localhost:8181/restconf/config/netvirt-providers-config:netvirt-providers-config
-{ "netvirt-providers-config": { "table-offset": 1 } } ---
+``{ "netvirt-providers-config": { "table-offset": 1 } }``
Next configure SFC to start at table 150 and configure the table
handoff. The configuration starts SFC at table 150 and sets the handoff
http://localhost:8181/restconf/config/sfc-of-renderer:sfc-of-renderer-config
-{ "sfc-of-renderer-config": { "sfc-of-app-egress-table-offset": 11,
-"sfc-of-table-offset": 150 } } ---
+``{ "sfc-of-renderer-config": { "sfc-of-app-egress-table-offset": 11, "sfc-of-table-offset": 150 } }``
OVSDB Hardware VTEP Developer Guide
-----------------------------------
Service Function Chaining
=========================
-OpenDaylight Service Function Chaining (SFC) Overiew
-----------------------------------------------------
+OpenDaylight Service Function Chaining (SFC) Overview
+-----------------------------------------------------
OpenDaylight Service Function Chaining (SFC) provides the ability to
define an ordered list of a network services (e.g. firewalls, load
- SCF - Service Classifier Function
-- SF - Service Function
+- SF - Service Function
- SFC - Service Function Chain
Classifier manages everything from starting the packet listener to
creation (and removal) of appropriate ip(6)tables rules and marking
received packets accordingly. Its functionality is **available only on
-Linux** as it leverdges **NetfilterQueue**, which provides access to
+Linux** as it leverages **NetfilterQueue**, which provides access to
packets matched by an **iptables** rule. Classifier requires **root
privileges** to be able to operate.
Rules are created using appropriate iptables command. If the Access
Control Entry (ACE) rule is MAC address related both iptables and
-ip6tabeles rules re issued. If ACE rule is IPv4 address related, only
+IPv6 tables rules are issued. If ACE rule is IPv4 address related, only
iptables rules are issued, same for IPv6.
.. note::
See: sfc-model/src/main/yang/service-function-classifier.yang
-SFC-OVS Plugin
+SFC-OVS Plug-in
--------------
Overview
Classifier, etc.) to OVS objects (like Bridge,
TerminationPoint=Port/Interface). The mapping takes care of automatic
instantiation (setup) of corresponding object whenever its counterpart
-is created. For example, when a new SFF is created, the SFC-OVS plugin
+is created. For example, when a new SFF is created, the SFC-OVS plug-in
will create a new OVS bridge and when a new OVS Bridge is created, the
-SFC-OVS plugin will create a new SFF.
+SFC-OVS plug-in will create a new SFF.
SFC-OVS Architecture
~~~~~~~~~~~~~~~~~~~~
- OVS to SFF mapping API (methods to convert OVS Bridge and OVS
TerminationPoints to SFF object)
-SFC Southbound REST Plugin
+SFC Southbound REST Plug-in
--------------------------
Overview
~~~~~~~~
-The Southbound REST Plugin is used to send configuration from DataStore
+The Southbound REST Plug-in is used to send configuration from datastore
down to network devices supporting a REST API (i.e. they have a
configured REST URI). It supports POST/PUT/DELETE operations, which are
triggered accordingly by changes in the SFC data stores.
- Service Function Schedule Type (SFST)
-- Service Function Forwader (SFF)
+- Service Function Forwarder (SFF)
- Rendered Service Path (RSP)
-Southbound REST Plugin Architecture
+Southbound REST Plug-in Architecture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. **listeners** - used to listen on changes in the SFC data stores
JSON-encoded data down to these devices
.. figure:: ./images/sfc/sb-rest-architecture.png
- :alt: Southbound REST Plugin Architecture diagram
+ :alt: Southbound REST Plug-in Architecture diagram
- Southbound REST Plugin Architecture diagram
+ Southbound REST Plug-in Architecture diagram
Key APIs and Interfaces
~~~~~~~~~~~~~~~~~~~~~~~
-The plugin provides Southbound REST API designated to listening REST
+The plug-in provides Southbound REST API designated to listening REST
devices. It supports POST/PUT/DELETE operations. The operation (with
corresponding JSON-encoded data) is sent to unique REST URL belonging to
-certain datatype.
+certain data type.
- Access Control List (ACL):
``http://<host>:<port>/config/ietf-acl:access-lists/access-list/``
- **``int serviceIndex``**: the initial service index for this rendered
service path
-- **``List<String>``**: a list of service funtion names which scheduled
+- **``List<String>``**: a list of service function names which scheduled
by the Service Function Scheduling Algorithm.
API Reference Documentation
Please refer the API docs generated in the mdsal-apidocs.
+
+Logical Service Function Forwarder
+----------------------------------
+
+Overview
+~~~~~~~~
+
+Rationale
+^^^^^^^^^
+
+When the current SFC is deployed in a cloud environment, it is assumed that each
+switch connected to a Service Function is configured as a Service Function Forwarder and
+each Service Function is connected to its Service Function Forwarder depending on the
+Compute Node where the Virtual Machine is located. This solution allows the basic cloud
+use cases to be fulfilled, as for example, the ones required in OPNFV Brahmaputra, however,
+some advanced use cases, like the transparent migration of VMs can not be implemented.
+The Logical Service Function Forwarder enables the following advanced use cases:
+
+1. Service Function mobility without service disruption
+2. Service Functions load balancing and failover
+
+As shown in the picture below, the Logical Service Function Forwarder concept extends the current
+SFC northbound API to provide an abstraction of the underlying Data Center infrastructure.
+The Data Center underlaying network can be abstracted by a single SFF. This single SFF uses
+the logical port UUID as data plane locator to connect SFs globally and in a location-transparent manner.
+SFC makes use of Genius project to track the location of the SF's logical ports.
+
+.. figure:: ./images/sfc/single-logical-sff-concept.png
+ :alt: Single Logical SFF concept
+
+The SFC internally distributes the necessary flow state over the relevant switches based on the
+internal Data Center topology and the deployment of SFs.
+
+Changes in data model
+~~~~~~~~~~~~~~~~~~~~~
+The Logical Service Function Forwarder concept extends the current SFC northbound API to provide
+an abstraction of the underlying Data Center infrastructure.
+
+The Logical SFF simplifies the configuration of the current SFC data model by reducing the number
+of parameters to be be configured in every SFF, since the controller will discover those parameters
+by interacting with the services offered by the Genius project.
+
+The following picture shows the Logical SFF data model. The model gets simplified as most of the
+configuration parameters of the current SFC data model are discovered in runtime. The complete
+YANG model can be found here `logical SFF model
+<https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-function-forwarder-logical.yang>`__.
+
+.. figure:: ./images/sfc/logical-sff-datamodel.png
+ :alt: Logical SFF data model
+
+Interaction with Genius
+~~~~~~~~~~~~~~~~~~~~~~~
+As shown in the following picture, SFC will interact with Genius project's services to provide the
+Logical SFF functionality.
+
+.. figure:: ./images/sfc/sfc-genius-interaction.png
+ :alt: SFC and Genius
+
+The following are the main Genius' services used by SFC:
+
+1. Interaction with Interface Tunnel Manager (ITM)
+
+2. Interaction with the Interface Manager
+
+3. Interaction with Resource Manager
+
+
+
Rendering to the inventory-rendering model
- **Important**
+.. important::
When implementing your version of the topology-rendering model in
the Topology Processing Framework, the source file of the model
Step2 - Module and Feature Creation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- **Important**
+.. important::
This and following steps are based on the `model specific
approach <#_model_specific_approach>`__ in the Topology Processing
Inventory Rendering). In the case of the provider class, we put the
abbreviation at the end.
- **Important**
+.. important::
- In the next sections, we use the terms TopologyRequestListener,
TopologyRequestHandler, etc. without a prepended or appended
the rendering operator just wraps each received UnderlayItem to
OverlayItem and sends them to write.
- **Important**
+.. important::
For purposes of topology rendering from inventory to
network-topology, there are misused fields in UnderlayItem as
-UNI Manager Plug-In Developer Guide
-===================================
+User Network Interface Manager Plug-in (Unimgr) Developer Guide
+===============================================================
-The UNI Manager plug in exposes capabilities of OpenDaylight to
-configure networked equipment to operate according to Metro Ethernet
-Forum (MEF) requirements for User Network Interface (UNI) and to support
-the creation of an Ethernet Virtual Connection (EVC) according to MEF
-requirements.
-
-UNI Manager adheres to a minimum set of functionality defined by MEF 7.2
-and 10.2 specifications.
+User Network Interface Manager Plug-in (Unimgr) is an experimental/proof of
+concept (PoC) project formed to initiate the development of data models and
+APIs facilitating the use by software applications and/or service orchestrators
+of OpenDaylight to configure and provision connectivity services, in particular
+Carrier Ethernet services as defined by Metro Ethernet Forum (MEF), in physical
+or virtual network elements.
Functionality
-------------
-The UNI manager plugin enables the creation of Ethernet Virtual
-Connections (EVC) as defined by the Metro Ethernet Forum (MEF). An EVC
-provides a simulated Ethernet connection among LANs existing at
-different geographical locations. This version of the plugin is limited
-to connecting two LANS.
-
-As defined by MEF, each location to be connected must have a User
-Network Interface, (UNI) which is a device that connects the user LAN to
-the EVC providers network.
-
-UNI and EVC are implemented via Open vSwitch, leveraging the OVSDB
-project: creating a UNI will end up creating an OVSDB node with an
-*ovsbr0* bridge, interface and port. While creating a UNI, based on the
-MEF requirement, one can specify a desired QoS; this leverages the QoS
-and Queue tables from the OVS database. (see documentation bellow for
-full details). Same goes with the EVC, to which one can apply a given
-QoS to control the speed of the connection. Creating an EVC will add two
-additional ports to the *ovsbr0* bridge:
-
-- *eht0*: the interface connected to a client laptop
-
-- *gre1*, interface used to for gre tunnelling between two clients
- (VXLAN).
-
-Finally, within this release, UniMgr is more a Proof Of Concept than a
-framework to be used in production. Previous demonstrations were made
-using Raspberry Pis, having a low NIC bandwith, thus the speed as
-defined in the API is actually mapped as follow:
-
-- ``speed-10M`` ⇒ 1 Mb
-
-- ``speed-100M`` ⇒ 2 Mb
-
-- ``speed-1G`` ⇒ 3 Mb
-
-- ``speed-10G`` ⇒ 4 Mb
-
-UNI Manager REST APIs
----------------------
-
-This API enables the creation and management of both UNI’s and EVCs. In
-order to create an EVC using this interface you would first create two
-UNI’s via the following REST API (see documentation below for full
-details)
-
-::
-
- PUT http://<host-ip>:8181/restconf/config/network-topology:network-topology/topology/unimgr:uni/node/<uni-id>
-
-You would then create an EVC, indicating that it is a connection between
-the two UNI’s that were just created, via the following REST API (see
-documentation below for full details)
-
-::
-
- PUT http://<host-ip>:8181/restconf/config/network-topology:network-topology/topology/unimgr:evc/link/<evc-id>
-
-You can then change attributes of the UNI’s or EVCs, and delete these
-entities using this API (see documentation below for full details).
-
-This plugin uses the OpenDaylight OVSDB plugin to provision and the
-manage devices which implement the OVSDB REST interface, as needed to
-realize the UNI and EVC life-cycles
-
-.. note::
-
- Both the configuration and operational databases can be operated
- upon by the unimgr REST API. The only difference between the two is
- in the REST Path. The configuration datastore represents the desired
- state, the operational datastore represents the actual state.
-
-For operating on the config database
-
-::
-
- http://<host-ip>:8181/restconf/config/<PATH>
-
-For operating on the operational database
-
-::
-
- http://<host-ip>:8181/restconf/operational/<PATH>
-
-The documentation below shows examples of both
+Unimgr provides support for both service orchestration, via the Legato API, and
+network resource provisioning, via the Presto API. These APIs, and the
+interfaces they provide, are defined by YANG models developed within MEF in
+collaboration with ONF and IETF. An application/user can interact with Unimgr
+at ether layer. For the Boron release, the YANG models are as follows:
-CREATE UNI
-~~~~~~~~~~
+Legato YANG models
+------------------
-::
-
- PUT http://<host-ip>:8181/restconf/config/network-topology:network-topology/topology/unimgr:uni/node/<uni-id>
-
-.. note::
-
- uni-id is determined by and supplied by the caller both in the path
- and the body of the rest message
-
-Request Body
-
-::
-
- {
- "network-topology:node": [
- {
- "node-id": "uni-id",
- "speed": {
- "speed-1G": 1
- },
- "uni:mac-layer": "IEEE 802.3-2005",
- "uni:physical-medium": "100BASE-T",
- "uni:mode": "syncEnabled"
- "uni:type": "UNITYPE",
- "uni:mtu-size": 1600,
- "uni:mac-address": "68:5b:35:bb:f8:3e",
- "uni:ip-address": "192.168.2.11",
- }
- ]
- }
-
-Response on success: 200
-
-Input Options
-
-::
-
- "speed"
- "speed-10M"
- "speed-100M"
- "speed-1G"
- "speed-10G"
- "uni:mac-layer"
- "IEEE 802.3-2005"
- uni:physical-medium
- "10BASE-T"
- "100BASE-T"
- "1000BASE-T"
- "10GBASE-T"
- "uni:mode"
- "syncEnabled"
- "syncDisabled"
- "uni:type"
- "UNITYPE"
- "uni:mtu-size"
- 1600 reccomended
-
-On OVS, the QoS, the Queue were updated, and a bridge was added:
-
-::
+https://git.opendaylight.org/gerrit/gitweb?p=unimgr.git;a=tree;f=legato-api/src/main/yang;hb=refs/heads/stable/boron
- mininet@mininet-vm:~$ sudo ovs-vsctl list QoS
- _uuid : 341c6e9d-ecb4-44ff-a21c-db644b466f4c
- external_ids : {opendaylight-qos-id="qos://18db2a79-5655-4a94-afac-94015245e3f6"}
- other_config : {dscp="0", max-rate="3000000"}
- queues : {}
- type : linux-htb
+Presto YANG models
+------------------
- mininet@mininet-vm:~$ sudo ovs-vsctl list Queue
- _uuid : 8a0e1fc1-5d5f-4e7a-9c4d-ec412a5ec7de
- dscp : 0
- external_ids : {opendaylight-queue-id="queue://740a3809-5bef-4ad4-98d6-2ba81132bd06"}
- other_config : {dscp="0", max-rate="3000000"}
+https://git.opendaylight.org/gerrit/gitweb?p=unimgr.git;a=tree;f=presto-api/src/main/yang;hb=refs/heads/stable/boron
- mininet@mininet-vm:~$ sudo ovs-vsctl show
- 0b8ed0aa-67ac-4405-af13-70249a7e8a96
- Manager "tcp:192.168.1.200:6640"
- is_connected: true
- Bridge "ovsbr0"
- Port "ovsbr0"
- Interface "ovsbr0"
- type: internal
- ovs_version: "2.4.0"
-
-RETRIEVE UNI
-~~~~~~~~~~~~
-
-GET
-`http://<host-ip>:8181/restconf/operational/network-topology:network-topology/topology/unimgr:uni/node/<uni-id> <http://<host-ip>:8181/restconf/operational/network-topology:network-topology/topology/unimgr:uni/node/<uni-id>>`__
-
-Response : 200
+Legato API Tree
+---------------
+module: mef-services
::
-
- {
- "node": [
- {
- "node-id": "uni-id",
- "cl-unimgr-mef:speed": {
- "speed-1G": [null]
- },
- "cl-unimgr-mef:mac-layer": "IEEE 802.3-2005",
- "cl-unimgr-mef:physical-medium": "1000BASE-T",
- "cl-unimgr-mef:mode": "syncEnabled",
- "cl-unimgr-mef:type": "UNITYPE",
- "cl-unimgr-mef:mtu-size": "1600",
- "cl-unimgr-mef:mac-address": "00:22:22:22:22:22",
- "cl-unimgr-mef:ip-address": "10.36.0.22"
- }
- ]
- }
-
-Output Options
-
+ +--rw mef-services
+ +--rw mef-service* [svc-id]
+ +--rw evc
+ | +--rw unis
+ | | +--rw uni* [uni-id]
+ | | +--rw evc-uni-ce-vlans
+ | | | +--rw evc-uni-ce-vlan* [vid]
+ | | | +--rw vid -> /mef-interfaces:mef-interfaces/unis/uni[mef-interfaces:uni-id = current()/../../../uni-id]/ce-vlans/ce-vlan/vid
+ | | +--rw ingress-bwp-flows-per-cos!
+ | | | +--rw coupling-enabled? boolean
+ | | | +--rw bwp-flow-per-cos* [cos-name]
+ | | | +--rw cos-name -> /mef-global:mef-global/profiles/cos-names/cos-name/name
+ | | | +--rw bw-profile -> /mef-interfaces:mef-interfaces/unis/uni[mef-interfaces:uni-id = current()/../../../uni-id]/ingress-envelopes/envelope/env-id
+ | | +--rw egress-bwp-flows-per-eec!
+ | | | +--rw coupling-enabled? boolean
+ | | | +--rw bwp-flow-per-eec* [eec-name]
+ | | | +--rw eec-name -> /mef-global:mef-global/profiles/eec-names/eec-name/name
+ | | | +--rw bw-profile -> /mef-interfaces:mef-interfaces/unis/uni[mef-interfaces:uni-id = current()/../../../uni-id]/egress-envelopes/envelope/env-id
+ | | +--rw status
+ | | | +--ro oper-state-enabled? boolean
+ | | | +--ro available-status? mef-types:svc-endpoint-availability-type
+ | | +--rw uni-id -> /mef-interfaces:mef-interfaces/unis/uni/uni-id
+ | | +--rw role mef-types:evc-uni-role-type
+ | | +--rw admin-state-enabled? boolean
+ | | +--rw color-id? mef-types:cos-color-identifier-type
+ | | +--rw data-svc-frm-cos? -> /mef-global:mef-global/profiles/cos/cos-profile/id
+ | | +--rw l2cp-svc-frm-cos? -> /mef-global:mef-global/profiles/l2cp-cos/l2cp-profile/id
+ | | +--rw soam-svc-frm-cos? -> /mef-global:mef-global/profiles/cos/cos-profile/id
+ | | +--rw data-svc-frm-eec? -> /mef-global:mef-global/profiles/eec/eec-profile/id
+ | | +--rw l2cp-svc-frm-eec? -> /mef-global:mef-global/profiles/l2cp-eec/l2cp-profile/id
+ | | +--rw soam-svc-frm-eec? -> /mef-global:mef-global/profiles/eec/eec-profile/id
+ | | +--rw ingress-bw-profile-per-evc? -> /mef-interfaces:mef-interfaces/unis/uni[mef-interfaces:uni-id = current()/../uni-id]/ingress-envelopes/envelope/env-id
+ | | +--rw egress-bw-profile-per-evc? -> /mef-interfaces:mef-interfaces/unis/uni[mef-interfaces:uni-id = current()/../uni-id]/egress-envelopes/envelope/env-id
+ | | +--rw src-mac-addr-limit-enabled? boolean
+ | | +--rw src-mac-addr-limit? uint32
+ | | +--rw src-mac-addr-limit-interval? yang:timeticks
+ | | +--rw test-meg-enabled? boolean
+ | | +--rw test-meg? mef-types:identifier45
+ | | +--rw subscriber-meg-mip-enabled? boolean
+ | | +--rw subscriber-meg-mip? mef-types:identifier45
+ | +--rw status
+ | | +--ro oper-state-enabled? boolean
+ | | +--ro available-status? mef-types:virt-cx-availability-type
+ | +--rw sls-inclusions-by-cos
+ | | +--rw sls-inclusion-by-cos* [cos-name]
+ | | +--rw cos-name -> /mef-global:mef-global/profiles/cos-names/cos-name/name
+ | +--rw sls-uni-inclusions!
+ | | +--rw sls-uni-inclusion-set* [pm-type pm-id uni-id1 uni-id2]
+ | | +--rw pm-type -> /mef-global:mef-global/slss/sls[mef-global:sls-id = current()/../../../evc-performance-sls]/perf-objs/perf-obj/pm-type
+ | | +--rw pm-id -> /mef-global:mef-global/slss/sls[mef-global:sls-id = current()/../../../evc-performance-sls]/perf-objs/perf-obj[mef-global:pm-type = current()/../pm-type]/pm-id
+ | | +--rw uni-id1 -> ../../../unis/uni/uni-id
+ | | +--rw uni-id2 -> ../../../unis/uni/uni-id
+ | +--rw sls-uni-exclusions!
+ | | +--rw sls-uni-exclusion-set* [pm-type pm-id uni-id1 uni-id2]
+ | | +--rw pm-type -> /mef-global:mef-global/slss/sls[mef-global:sls-id = current()/../../../evc-performance-sls]/perf-objs/perf-obj/pm-type
+ | | +--rw pm-id -> /mef-global:mef-global/slss/sls[mef-global:sls-id = current()/../../../evc-performance-sls]/perf-objs/perf-obj[mef-global:pm-type = current()/../pm-type]/pm-id
+ | | +--rw uni-id1 -> ../../../unis/uni/uni-id
+ | | +--rw uni-id2 -> ../../../unis/uni/uni-id
+ | +--rw evc-id mef-types:evc-id-type
+ | +--ro evc-status? mef-types:evc-status-type
+ | +--rw evc-type mef-types:evc-type
+ | +--rw admin-state-enabled? boolean
+ | +--rw elastic-enabled? boolean
+ | +--rw elastic-service? mef-types:identifier45
+ | +--rw max-uni-count? uint32
+ | +--rw preserve-ce-vlan-id? boolean
+ | +--rw cos-preserve-ce-vlan-id? boolean
+ | +--rw evc-performance-sls? -> /mef-global:mef-global/slss/sls/sls-id
+ | +--rw unicast-svc-frm-delivery? mef-types:data-svc-frame-delivery-type
+ | +--rw multicast-svc-frm-delivery? mef-types:data-svc-frame-delivery-type
+ | +--rw broadcast-svc-frm-delivery? mef-types:data-svc-frame-delivery-type
+ | +--rw evc-meg-id? mef-types:identifier45
+ | +--rw max-svc-frame-size? mef-types:max-svc-frame-size-type
+ +--rw svc-id mef-types:retail-svc-id-type
+ +--rw sp-id? -> /mef-global:mef-global/svc-providers/svc-provider/sp-id
+ +--rw svc-type? mef-types:mef-service-type
+ +--rw user-label? mef-types:identifier45
+ +--rw svc-entity? mef-types:service-entity-type
+
+module: mef-global
::
-
- "cl-unimgr-mef:speed"
- "speed-10M"
- "speed-100M"
- "speed-1G"
- "speed-10G"
- "cl-unimgr-mef::mac-layer"
- "IEEE 802.3-2005"
- "cl-unimgr-mef:physical-medium"
- "10BASE-T"
- "100BASE-T"
- "1000BASE-T"
- "10GBASE-T"
- "cl-unimgr-mef::mode"
- "syncEnabled"
- "syncDisabled"
- "cl-unimgr-mef::type"
- "UNITYPE"
-
-UPDATE UNI
-~~~~~~~~~~
-
+ +--rw mef-global
+ +--rw svc-providers!
+ | +--rw svc-provider* [sp-id]
+ | +--rw sp-id mef-types:svc-provider-type
+ +--rw cens!
+ | +--rw cen* [cen-id]
+ | +--rw cen-id mef-types:cen-type
+ | +--rw sp-id? -> /mef-global/svc-providers/svc-provider/sp-id
+ +--rw slss!
+ | +--rw sls* [sls-id]
+ | +--rw perf-objs
+ | | +--rw pm-time-interval uint64
+ | | +--rw pm-time-interval-increment uint64
+ | | +--rw unavail-flr-threshold-pp mef-types:simple-percent
+ | | +--rw consecutive-small-time-intervals uint64
+ | | +--rw perf-obj* [pm-type pm-id]
+ | | +--rw pm-type mef-types:performance-metric-type
+ | | +--rw pm-id mef-types:identifier45
+ | | +--rw cos-name -> /mef-global/profiles/cos-names/cos-name/name
+ | | +--rw fd-pp mef-types:simple-percent
+ | | +--rw fd-range-pp mef-types:simple-percent
+ | | +--rw fd-perf-obj uint64
+ | | +--rw fd-range-perf-obj uint64
+ | | +--rw fd-mean-perf-obj uint64
+ | | +--rw ifdv-pp mef-types:simple-percent
+ | | +--rw ifdv-pair-interval mef-types:simple-percent
+ | | +--rw ifdv-perf-obj uint64
+ | | +--rw flr-perf-obj uint64
+ | | +--rw avail-pp mef-types:simple-percent
+ | | +--rw hli-perf-obj uint64
+ | | +--rw chli-consecutive-small-time-intervals uint64
+ | | +--rw chli-perf-obj uint64
+ | | +--rw min-uni-pairs-avail uint64
+ | | +--rw gp-avail-pp mef-types:simple-percent
+ | +--rw sls-id mef-types:cen-type
+ | +--rw sp-id? -> /mef-global/svc-providers/svc-provider/sp-id
+ +--rw subscribers!
+ | +--rw subscriber* [sub-id]
+ | +--rw sub-id mef-types:subscriber-type
+ | +--rw sp-id? -> /mef-global/svc-providers/svc-provider/sp-id
+ | +--rw cen-id? -> /mef-global/cens/cen/cen-id
+ +--rw profiles!
+ +--rw cos-names
+ | +--rw cos-name* [name]
+ | +--rw name mef-types:identifier45
+ +--rw eec-names
+ | +--rw eec-name* [name]
+ | +--rw name mef-types:identifier45
+ +--rw ingress-bwp-flows
+ | +--rw bwp-flow* [bw-profile]
+ | +--rw bw-profile mef-types:identifier45
+ | +--rw user-label? mef-types:identifier45
+ | +--rw cir? mef-types:bwp-cir-type
+ | +--rw cir-max? mef-types:bwp-cir-type
+ | +--rw cbs? mef-types:bwp-cbs-type
+ | +--rw eir? mef-types:bwp-eir-type
+ | +--rw eir-max? mef-types:bwp-eir-type
+ | +--rw ebs? mef-types:bwp-ebs-type
+ | +--rw coupling-enabled? boolean
+ | +--rw color-mode? mef-types:bwp-color-mode-type
+ | +--rw coupling-flag? mef-types:bwp-coupling-flag-type
+ +--rw egress-bwp-flows
+ | +--rw bwp-flow* [bw-profile]
+ | +--rw bw-profile mef-types:identifier45
+ | +--rw user-label? mef-types:identifier45
+ | +--rw cir? mef-types:bwp-cir-type
+ | +--rw cir-max? mef-types:bwp-cir-type
+ | +--rw cbs? mef-types:bwp-cbs-type
+ | +--rw eir? mef-types:bwp-eir-type
+ | +--rw eir-max? mef-types:bwp-eir-type
+ | +--rw ebs? mef-types:bwp-ebs-type
+ | +--rw coupling-enabled? boolean
+ | +--rw color-mode? mef-types:bwp-color-mode-type
+ | +--rw coupling-flag? mef-types:bwp-coupling-flag-type
+ +--rw l2cp-cos
+ | +--rw l2cp-profile* [id]
+ | +--rw l2cps
+ | | +--rw l2cp* [dest-mac-addr peering-proto-name]
+ | | +--rw dest-mac-addr yang:mac-address
+ | | +--rw peering-proto-name mef-types:identifier45
+ | | +--rw protocol? mef-types:l2cp-peering-protocol-type
+ | | +--rw protocol-id? yang:hex-string
+ | | +--rw cos-name? -> /mef-global/profiles/cos-names/cos-name/name
+ | | +--rw handling? mef-types:l2cp-handling-type
+ | | +--rw subtype* yang:hex-string
+ | +--rw id mef-types:identifier45
+ | +--rw user-label? mef-types:identifier45
+ +--rw l2cp-eec
+ | +--rw l2cp-profile* [id]
+ | +--rw l2cps
+ | | +--rw l2cp* [dest-mac-addr peering-proto-name]
+ | | +--rw dest-mac-addr yang:mac-address
+ | | +--rw peering-proto-name mef-types:identifier45
+ | | +--rw protocol? mef-types:l2cp-peering-protocol-type
+ | | +--rw protocol-id? yang:hex-string
+ | | +--rw eec-name? -> /mef-global/profiles/eec-names/eec-name/name
+ | | +--rw handling? mef-types:l2cp-handling-type
+ | | +--rw subtype* yang:hex-string
+ | +--rw id mef-types:identifier45
+ | +--rw user-label? mef-types:identifier45
+ +--rw l2cp-peering
+ | +--rw l2cp-profile* [id]
+ | +--rw l2cps
+ | | +--rw l2cp* [dest-mac-addr peering-proto-name]
+ | | +--rw dest-mac-addr yang:mac-address
+ | | +--rw peering-proto-name mef-types:identifier45
+ | | +--rw protocol? mef-types:l2cp-peering-protocol-type
+ | | +--rw protocol-id? yang:hex-string
+ | | +--rw subtype* yang:hex-string
+ | +--rw id mef-types:identifier45
+ | +--rw user-label? mef-types:identifier45
+ +--rw elmi
+ | +--rw elmi-profile* [id]
+ | +--rw id mef-types:identifier45
+ | +--rw user-label? mef-types:identifier45
+ | +--rw polling-counter? mef-types:elmi-polling-counter-type
+ | +--rw status-error-threshold? mef-types:elmi-status-error-threshold-type
+ | +--rw polling-timer? mef-types:elmi-polling-timer-type
+ | +--rw polling-verification-timer? mef-types:elmi-polling-verification-timer-type
+ +--rw eec
+ | +--rw eec-profile* [id]
+ | +--rw id mef-types:identifier45
+ | +--rw (eec-id)?
+ | +--:(pcp)
+ | | +--rw eec-pcp!
+ | | +--rw default-pcp-eec-name? -> /mef-global/profiles/eec-names/eec-name/name
+ | | +--rw default-pcp-color? mef-types:cos-color-type
+ | | +--rw pcp* [pcp-value]
+ | | +--rw pcp-value mef-types:ieee8021p-priority-type
+ | | +--rw discard-value? boolean
+ | | +--rw eec-name? -> /mef-global/profiles/eec-names/eec-name/name
+ | | +--rw color? mef-types:cos-color-type
+ | +--:(dscp)
+ | +--rw eec-dscp!
+ | +--rw default-ipv4-eec-name? -> /mef-global/profiles/eec-names/eec-name/name
+ | +--rw default-ipv4-color? mef-types:cos-color-type
+ | +--rw default-ipv6-eec-name? -> /mef-global/profiles/eec-names/eec-name/name
+ | +--rw default-ipv6-color? mef-types:cos-color-type
+ | +--rw ipv4-dscp* [dscp-value]
+ | | +--rw dscp-value inet:dscp
+ | | +--rw discard-value? boolean
+ | | +--rw eec-name? -> /mef-global/profiles/eec-names/eec-name/name
+ | | +--rw color? mef-types:cos-color-type
+ | +--rw ipv6-dscp* [dscp-value]
+ | +--rw dscp-value inet:dscp
+ | +--rw discard-value? boolean
+ | +--rw eec-name? -> /mef-global/profiles/eec-names/eec-name/name
+ | +--rw color? mef-types:cos-color-type
+ +--rw cos
+ +--rw cos-profile* [id]
+ +--rw id mef-types:identifier45
+ +--rw (cos-id)?
+ +--:(evc)
+ | +--rw cos-evc!
+ | +--rw default-evc-cos-name? -> /mef-global/profiles/cos-names/cos-name/name
+ | +--rw default-evc-color? mef-types:cos-color-type
+ +--:(pcp)
+ | +--rw cos-pcp!
+ | +--rw default-pcp-cos-name? -> /mef-global/profiles/cos-names/cos-name/name
+ | +--rw default-pcp-color? mef-types:cos-color-type
+ | +--rw pcp* [pcp-value]
+ | +--rw pcp-value mef-types:ieee8021p-priority-type
+ | +--rw discard-value? boolean
+ | +--rw cos-name? -> /mef-global/profiles/cos-names/cos-name/name
+ | +--rw color? mef-types:cos-color-type
+ +--:(dscp)
+ +--rw cos-dscp!
+ +--rw default-ipv4-cos-name? -> /mef-global/profiles/cos-names/cos-name/name
+ +--rw default-ipv4-color? mef-types:cos-color-type
+ +--rw default-ipv6-cos-name? -> /mef-global/profiles/cos-names/cos-name/name
+ +--rw default-ipv6-color? mef-types:cos-color-type
+ +--rw ipv4-dscp* [dscp-value]
+ | +--rw dscp-value inet:dscp
+ | +--rw discard-value? boolean
+ | +--rw cos-name? -> /mef-global/profiles/cos-names/cos-name/name
+ | +--rw color? mef-types:cos-color-type
+ +--rw ipv6-dscp* [dscp-value]
+ +--rw dscp-value inet:dscp
+ +--rw discard-value? boolean
+ +--rw cos-name? -> /mef-global/profiles/cos-names/cos-name/name
+ +--rw color? mef-types:cos-color-type
+
+Presto API Tree
+---------------
+
+module: onf-core-network-module
::
-
- PUT http://<host-ip>:8181/restconf/config/network-topology:network-topology/topology/unimgr:uni/node/<uni-id>
-
-.. note::
-
- uni-id is determined by and supplied by the caller both in the path
- and the body of the rest message
-
-Request Body
-
+ +--rw forwarding-constructs
+ +--rw forwarding-construct* [uuid]
+ +--rw uuid string
+ +--rw layerProtocolName? onf-cnt:LayerProtocolName
+ +--rw lowerLevelFc* -> /forwarding-constructs/forwarding-construct/uuid
+ +--rw fcRoute* [uuid]
+ | +--rw uuid string
+ | +--rw fc* -> /forwarding-constructs/forwarding-construct/uuid
+ +--rw fcPort* [topology node tp]
+ | +--rw topology nt:topology-ref
+ | +--rw node nt:node-ref
+ | +--rw tp nt:tp-ref
+ | +--rw role? onf-cnt:PortRole
+ | +--rw fcPortDirection? onf-cnt:PortDirection
+ +--rw fcSpec
+ | +--rw uuid? string
+ | +--rw fcPortSpec* [uuid]
+ | | +--rw uuid string
+ | | +--rw ingressFcPortSet* [topology node tp]
+ | | | +--rw topology nt:topology-ref
+ | | | +--rw node nt:node-ref
+ | | | +--rw tp nt:tp-ref
+ | | +--rw egressFcPortSet* [topology node tp]
+ | | | +--rw topology nt:topology-ref
+ | | | +--rw node nt:node-ref
+ | | | +--rw tp nt:tp-ref
+ | | +--rw role? string
+ | +--rw nrp:nrp-ce-fcspec-attrs
+ | +--rw nrp:connectionType? nrp-types:NRP_ConnectionType
+ | +--rw nrp:unicastFrameDelivery? nrp-types:NRP_ServiceFrameDelivery
+ | +--rw nrp:multicastFrameDelivery? nrp-types:NRP_ServiceFrameDelivery
+ | +--rw nrp:broadcastFrameDelivery? nrp-types:NRP_ServiceFrameDelivery
+ | +--rw nrp:vcMaxServiceFrame? nrp-types:NRP_PositiveInteger
+ | +--rw nrp:vcId? nrp-types:NRP_PositiveInteger
+ +--rw forwardingDirection? onf-cnt:ForwardingDirection
+
+augment /nt:network-topology/nt:topology/nt:node/nt:termination-point:
::
-
- {
- "network-topology:node": [
- {
- "node-id": "uni-id",
- "speed": {
- "speed-1G": 1
- },
- "uni:mac-layer": "IEEE 802.3-2005",
- "uni:physical-medium": "100BASE-T",
- "uni:mode": "syncEnabled"
- "uni:type": "UNITYPE",
- "uni:mtu-size": 1600,
- "uni:mac-address": "68:5b:35:bb:f8:3e",
- "uni:ip-address": "192.168.2.11",
- }
- ]
- }
-
-Response on success: 200
-
-Input Options
-
-::
-
- "speed"
- "speed-10M"
- "speed-100M"
- "speed-1G"
- "speed-10G"
- "uni:mac-layer"
- "IEEE 802.3-2005"
- uni:physical-medium
- "10BASE-T"
- "100BASE-T"
- "1000BASE-T"
- "10GBASE-T"
- "uni:mode"
- "syncEnabled"
- "syncDisabled"
- "uni:type"
- "UNITYPE"
- "uni:mtu-size"
- 1600 reccomended
-
-DELETE UNI
-~~~~~~~~~~
-
-::
-
- DELETE http://<host-ip>:8181/restconf/config/network-topology:network-topology/topology/unimgr:uni/node/<uni-id>
-
-Response on success: 200
-
-CREATE EVC
-~~~~~~~~~~
-
-::
-
- PUT http://<host-ip>:8181/restconf/config/network-topology:network-topology/topology/unimgr:evc/link/<evc-id>
-
-.. note::
-
- evc-id is determined by and supplied by the caller both in the path
- and the body of the rest message
-
-Request Body
-
-::
-
- {
- "link": [
- {
- "link-id": "evc-1",
- "source": {
- "source-node": "/network-topology/topology/node/uni-1"
- },
- "destination": {
- "dest-node": "/network-topology/topology/node/uni-2"
- },
- "cl-unimgr-mef:uni-source": [
- {
- "order": "0",
- "ip-address": "192.168.2.11"
- }
- ],
- "cl-unimgr-mef:uni-dest": [
- {
- "order": "0",
- "ip-address": "192.168.2.10"
- }
- ],
- "cl-unimgr-mef:cos-id": "gold",
- "cl-unimgr-mef:ingress-bw": {
- "speed-10G": {}
- },
- "cl-unimgr-mef:egress-bw": {
- "speed-10G": {}
- }
- }
- ]
- }
-
-Response on success: 200
-
-Input Optionss
-
-::
-
- ["source"]["source-node"]
- Id of 1st UNI to assocate EVC with
- ["cl-unimgr-mef:uni-source"][0]["ip-address"]
- IP address of 1st UNI to associate EVC with
- ["destination"]["dest-node"]
- Id of 2nd UNI to assocate EVC with
- ["cl-unimgr-mef:uni-dest"][0]["ip-address"]
- IP address of 2nd UNI to associate EVC with
- "cl-unimgr-mef:cos-id"
- class of service id to associate with the EVC
- "cl-unimgr-mef:ingress-bw"
- "cl-unimgr-mef:egress-bw"
- "speed-10M"
- "speed-100M"
- "speed-1G"
- "speed-10G"
-
-On OVS, the QoS, the Queue were updated, and two ports were added:
-
-::
-
- mininet@mininet-vm:~$ sudo ovs-vsctl list QoS
- _uuid : 341c6e9d-ecb4-44ff-a21c-db644b466f4c
- external_ids : {opendaylight-qos-id="qos://18db2a79-5655-4a94-afac-94015245e3f6"}
- other_config : {dscp="0", max-rate="3000000"}
- queues : {}
- type : linux-htb
-
- mininet@mininet-vm:~$ sudo ovs-vsctl list Queue
- _uuid : 8a0e1fc1-5d5f-4e7a-9c4d-ec412a5ec7de
- dscp : 0
- external_ids : {opendaylight-queue-id="queue://740a3809-5bef-4ad4-98d6-2ba81132bd06"}
- other_config : {dscp="0", max-rate="3000000"}
-
- mininet@mininet-vm:~$ sudo ovs-vsctl show
- 0b8ed0aa-67ac-4405-af13-70249a7e8a96
- Manager "tcp:192.168.1.200:6640"
- is_connected: true
- Bridge "ovsbr0"
- Port "ovsbr0"
- Interface "ovsbr0"
- type: internal
- Port "eth1"
- Interface "eth1"
- Port "gre1"
- Interface "gre1"
- type: gre
- options: {remote_ip="192.168.1.233"}
- ovs_version: "2.4.0"
-
-RETRIEVE EVC
-~~~~~~~~~~~~
-
-::
-
- GET http://<host-ip>:8181/restconf/operational/network-topology:network-topology/topology/unimgr:evc/link/<evc-id>
-
-Response on success: 200
-
-::
-
- {
- "link": [
- {
- "link-id": "evc-5",
- "source": {
- "source-node": "/network-topology/topology/node/uni-9"
- },
- "destination": {
- "dest-node": "/network-topology/topology/node/uni-10"
- },
- "cl-unimgr-mef:uni-dest": [
- {
- "order": 0,
- "uni": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='unimgr:uni']/network-topology:node[network-topology:node-id='uni-10']",
- "ip-address": "10.0.0.22"
- }
- ],
- "cl-unimgr-mef:ingress-bw": {
- "speed-1G": [null]
- },
- "cl-unimgr-mef:cos-id": "new1",
- "cl-unimgr-mef:uni-source": [
- {
- "order": 0,
- "uni": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='unimgr:uni']/network-topology:node[network-topology:node-id='uni-9']",
- "ip-address": "10.0.0.21"
- }
- ],
- "cl-unimgr-mef:egress-bw": {
- "speed-1G": [null]
- }
- }
- ]
- }
-
-Output Options
-
-::
-
- ["source"]["source-node"]
- ["cl-unimgr-mef:uni-source"][0]["uni"]
- Id of 1st UNI assocated with EVC
- ["cl-unimgr-mef:uni-source"][0]["ip-address"]
- IP address of 1st UNI assocated with EVC
- ["destination"]["dest-node"]
- ["cl-unimgr-mef:uni-dest"][0]["uni"]
- Id of 2nd UNI assocated with EVC
- ["cl-unimgr-mef:uni-dest"][0]["ip-address"]
- IP address of 2nd UNI assocated with EVC
- "cl-unimgr-mef:cos-id"
- class of service id associated with the EVC
- "cl-unimgr-mef:ingress-bw"
- "cl-unimgr-mef:egress-bw"
- "speed-10M"
- "speed-100M"
- "speed-1G"
- "speed-10G"
-
-UPDATE EVC
-~~~~~~~~~~
-
-::
-
- PUT http://<host-ip>:8181/restconf/config/network-topology:network-topology/topology/unimgr:evc/link/<evc-id>
-
-.. note::
-
- evc-id is determined by and supplied by the caller both in the path
- and the body of the rest message
-
-Request Body
-
-::
-
- {
- "link": [
- {
- "link-id": "evc-1",
- "source": {
- "source-node": "/network-topology/topology/node/uni-1"
- },
- "destination": {
- "dest-node": "/network-topology/topology/node/uni-2"
- },
- "cl-unimgr-mef:uni-source": [
- {
- "order": "0",
- "ip-address": "192.168.2.11"
- }
- ],
- "cl-unimgr-mef:uni-dest": [
- {
- "order": "0",
- "ip-address": "192.168.2.10"
- }
- ],
- "cl-unimgr-mef:cos-id": "gold",
- "cl-unimgr-mef:ingress-bw": {
- "speed-10G": {}
- },
- "cl-unimgr-mef:egress-bw": {
- "speed-10G": {}
- }
- }
- ]
- }
-
-Response on success: 200
-
-Input Optionss
-
-::
-
- ["source"]["source-node"]
- Id of 1st UNI to assocate EVC with
- ["cl-unimgr-mef:uni-source"][0]["ip-address"]
- IP address of 1st UNI to associate EVC with
- ["destination"]["dest-node"]
- Id of 2nd UNI to assocate EVC with
- ["cl-unimgr-mef:uni-dest"][0]["ip-address"]
- IP address of 2nd UNI to associate EVC with
- "cl-unimgr-mef:cos-id"
- class of service id to associate with the EVC
- "cl-unimgr-mef:ingress-bw"
- "cl-unimgr-mef:egress-bw"
- "speed-10M"
- "speed-100M"
- "speed-1G"
- "speed-10G"
-
-DELETE EVC
-~~~~~~~~~~
-
-::
-
- DELETE http://host-ip:8181/restconf/config/network-topology:network-topology/topology/unimgr:evc/link/evc-id
-
-Response on success: 200
-
+ +--rw ltp-attrs
+ +--rw lpList* [uuid]
+ | +--rw uuid string
+ | +--rw layerProtocolName? onf-cnt:LayerProtocolName
+ | +--rw lpSpec
+ | | +--rw adapterSpec
+ | | | +--rw nrp:nrp-conn-adapt-spec-attrs
+ | | | | +--rw nrp:sourceMacAddressLimit
+ | | | | | +--rw nrp:enabled? boolean
+ | | | | | +--rw nrp:limit? NRP_NaturalNumber
+ | | | | | +--rw nrp:timeInterval? NRP_NaturalNumber
+ | | | | +--rw nrp:CeExternalInterface
+ | | | | | +--rw nrp:physicalLayer? nrp-types:NRP_PhysicalLayer
+ | | | | | +--rw nrp:syncMode* [linkId]
+ | | | | | | +--rw nrp:linkId string
+ | | | | | | +--rw nrp:syncModeEnabled? boolean
+ | | | | | +--rw nrp:numberOfLinks? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:resiliency? nrp-types:NRP_InterfaceResiliency
+ | | | | | +--rw nrp:portConvsIdToAggLinkMap
+ | | | | | | +--rw nrp:conversationId? NRP_NaturalNumber
+ | | | | | | +--rw nrp:linkId? NRP_NaturalNumber
+ | | | | | +--rw nrp:maxFrameSize? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:linkOamEnabled? boolean
+ | | | | | +--rw nrp:tokenShareEnabled? boolean
+ | | | | | +--rw nrp:serviceProviderUniId? string
+ | | | | +--rw nrp:coloridentifier
+ | | | | | +--rw (identifier)?
+ | | | | | +--:(sap-color-id)
+ | | | | | | +--rw nrp:serviceAccessPointColorId
+ | | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
+ | | | | | +--:(pcp-color-id)
+ | | | | | | +--rw nrp:pcpColorId
+ | | | | | | +--rw nrp:vlanTag? nrp-types:NRP_VlanTag
+ | | | | | | +--rw nrp:pcpValue* nrp-types:NRP_NaturalNumber
+ | | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
+ | | | | | +--:(dei-color-id)
+ | | | | | | +--rw nrp:deiColorId
+ | | | | | | +--rw nrp:vlanTag? nrp-types:NRP_VlanTag
+ | | | | | | +--rw nrp:deiValue* nrp-types:NRP_NaturalNumber
+ | | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
+ | | | | | +--:(desp-color-id)
+ | | | | | +--rw nrp:despColorId
+ | | | | | +--rw nrp:ipVersion? nrp-types:NRP_IpVersion
+ | | | | | +--rw nrp:dscpValue* nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
+ | | | | +--rw nrp:ingressBwpFlow
+ | | | | | +--rw nrp:bwpFlowIndex? nrp-types:NRP_PositiveInteger
+ | | | | | +--rw nrp:cir? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:cirMax? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:cbs? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:eir? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:eirMax? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:ebs? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:couplingFlag? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:colorMode? nrp-types:NRP_ColorMode
+ | | | | | +--rw nrp:rank? nrp-types:NRP_PositiveInteger
+ | | | | | +--rw nrp:tokenRequestOffset? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:egressBwpFlow
+ | | | | | +--rw nrp:bwpFlowIndex? nrp-types:NRP_PositiveInteger
+ | | | | | +--rw nrp:cir? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:cirMax? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:cbs? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:eir? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:eirMax? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:ebs? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:couplingFlag? nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:colorMode? nrp-types:NRP_ColorMode
+ | | | | | +--rw nrp:rank? nrp-types:NRP_PositiveInteger
+ | | | | | +--rw nrp:tokenRequestOffset? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:l2cpAddressSet? nrp-types:NRP_L2cpAddressSet
+ | | | | +--rw nrp:l2cpPeering* [linkId]
+ | | | | +--rw nrp:destinationMacAddress? string
+ | | | | +--rw nrp:protocolType? NRP_ProtocolFrameType
+ | | | | +--rw nrp:linkId string
+ | | | | +--rw nrp:protocolId? string
+ | | | +--rw nrp:nrp-ivc-endpoint-conn-adapt-spec-attrs
+ | | | | +--rw nrp:ivcEndPointId? string
+ | | | | +--rw nrp:testMegEnabled? boolean
+ | | | | +--rw nrp:ivcEndPointRole? nrp-types:NRP_EndPointRole
+ | | | | +--rw nrp:ivcEndPointMap* [vlanId]
+ | | | | | +--rw nrp:vlanId nrp-types:NRP_PositiveInteger
+ | | | | | +--rw (endpoint-map-form)?
+ | | | | | +--:(map-form-e)
+ | | | | | | +--rw nrp:enni-svid* [vid]
+ | | | | | | +--rw nrp:vid nrp-types:NRP_PositiveInteger
+ | | | | | +--:(map-form-t)
+ | | | | | | +--rw nrp:root-svid? nrp-types:NRP_PositiveInteger
+ | | | | | | +--rw nrp:leaf-svid? nrp-types:NRP_PositiveInteger
+ | | | | | +--:(map-form-v)
+ | | | | | | +--rw nrp:vuni-vid? nrp-types:NRP_PositiveInteger
+ | | | | | | +--rw nrp:enni-cevid* [vid]
+ | | | | | | +--rw nrp:vid nrp-types:NRP_PositiveInteger
+ | | | | | +--:(map-form-u)
+ | | | | | +--rw nrp:cvid* [vid]
+ | | | | | +--rw nrp:vid nrp-types:NRP_PositiveInteger
+ | | | | +--rw nrp:subscriberMegMipEnabled? boolean
+ | | | +--rw nrp:nrp-evc-endpoint-conn-adapt-spec-attrs
+ | | | +--rw nrp:sourceMacAddressLimit
+ | | | | +--rw nrp:enabled? boolean
+ | | | | +--rw nrp:limit? NRP_NaturalNumber
+ | | | | +--rw nrp:timeInterval? NRP_NaturalNumber
+ | | | +--rw nrp:CeExternalInterface
+ | | | | +--rw nrp:physicalLayer? nrp-types:NRP_PhysicalLayer
+ | | | | +--rw nrp:syncMode* [linkId]
+ | | | | | +--rw nrp:linkId string
+ | | | | | +--rw nrp:syncModeEnabled? boolean
+ | | | | +--rw nrp:numberOfLinks? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:resiliency? nrp-types:NRP_InterfaceResiliency
+ | | | | +--rw nrp:portConvsIdToAggLinkMap
+ | | | | | +--rw nrp:conversationId? NRP_NaturalNumber
+ | | | | | +--rw nrp:linkId? NRP_NaturalNumber
+ | | | | +--rw nrp:maxFrameSize? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:linkOamEnabled? boolean
+ | | | | +--rw nrp:tokenShareEnabled? boolean
+ | | | | +--rw nrp:serviceProviderUniId? string
+ | | | +--rw nrp:coloridentifier
+ | | | | +--rw (identifier)?
+ | | | | +--:(sap-color-id)
+ | | | | | +--rw nrp:serviceAccessPointColorId
+ | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
+ | | | | +--:(pcp-color-id)
+ | | | | | +--rw nrp:pcpColorId
+ | | | | | +--rw nrp:vlanTag? nrp-types:NRP_VlanTag
+ | | | | | +--rw nrp:pcpValue* nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
+ | | | | +--:(dei-color-id)
+ | | | | | +--rw nrp:deiColorId
+ | | | | | +--rw nrp:vlanTag? nrp-types:NRP_VlanTag
+ | | | | | +--rw nrp:deiValue* nrp-types:NRP_NaturalNumber
+ | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
+ | | | | +--:(desp-color-id)
+ | | | | +--rw nrp:despColorId
+ | | | | +--rw nrp:ipVersion? nrp-types:NRP_IpVersion
+ | | | | +--rw nrp:dscpValue* nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
+ | | | +--rw nrp:ingressBwpFlow
+ | | | | +--rw nrp:bwpFlowIndex? nrp-types:NRP_PositiveInteger
+ | | | | +--rw nrp:cir? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:cirMax? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:cbs? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:eir? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:eirMax? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:ebs? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:couplingFlag? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:colorMode? nrp-types:NRP_ColorMode
+ | | | | +--rw nrp:rank? nrp-types:NRP_PositiveInteger
+ | | | | +--rw nrp:tokenRequestOffset? nrp-types:NRP_NaturalNumber
+ | | | +--rw nrp:egressBwpFlow
+ | | | | +--rw nrp:bwpFlowIndex? nrp-types:NRP_PositiveInteger
+ | | | | +--rw nrp:cir? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:cirMax? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:cbs? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:eir? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:eirMax? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:ebs? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:couplingFlag? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:colorMode? nrp-types:NRP_ColorMode
+ | | | | +--rw nrp:rank? nrp-types:NRP_PositiveInteger
+ | | | | +--rw nrp:tokenRequestOffset? nrp-types:NRP_NaturalNumber
+ | | | +--rw nrp:l2cpAddressSet? nrp-types:NRP_L2cpAddressSet
+ | | | +--rw nrp:l2cpPeering* [linkId]
+ | | | | +--rw nrp:destinationMacAddress? string
+ | | | | +--rw nrp:protocolType? NRP_ProtocolFrameType
+ | | | | +--rw nrp:linkId string
+ | | | | +--rw nrp:protocolId? string
+ | | | +--rw nrp:evcEndPointId? nrp-types:NRP_PositiveInteger
+ | | | +--rw nrp:testMegEnabled? boolean
+ | | | +--rw nrp:evcEndPointRole? nrp-types:NRP_EvcEndPointRole
+ | | | +--rw nrp:evcEndPointMap* [vid]
+ | | | | +--rw nrp:vid nrp-types:NRP_PositiveInteger
+ | | | +--rw nrp:subscriberMegMipEbabled? boolean
+ | | +--rw terminationSpec
+ | | | +--rw nrp:nrp-termination-spec-attrs
+ | | | | +--rw nrp:physicalLayer? nrp-types:NRP_PhysicalLayer
+ | | | | +--rw nrp:syncMode* [linkId]
+ | | | | | +--rw nrp:linkId string
+ | | | | | +--rw nrp:syncModeEnabled? boolean
+ | | | | +--rw nrp:numberOfLinks? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:resiliency? nrp-types:NRP_InterfaceResiliency
+ | | | | +--rw nrp:portConvsIdToAggLinkMap
+ | | | | | +--rw nrp:conversationId? NRP_NaturalNumber
+ | | | | | +--rw nrp:linkId? NRP_NaturalNumber
+ | | | | +--rw nrp:maxFrameSize? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:linkOamEnabled? boolean
+ | | | | +--rw nrp:tokenShareEnabled? boolean
+ | | | | +--rw nrp:serviceProviderUniId? string
+ | | | +--rw nrp:nrp-uni-termination-attrs
+ | | | +--rw nrp:defaultCeVlanId? nrp-types:NRP_PositiveInteger
+ | | | +--rw nrp:uniMegEnabled? boolean
+ | | | +--rw nrp:elmiEnabled? boolean
+ | | | +--rw nrp:serviceprovideruniprofile? string
+ | | | +--rw nrp:operatoruniprofile? string
+ | | | +--rw nrp:ingressBwpUni
+ | | | | +--rw nrp:bwpFlowIndex? nrp-types:NRP_PositiveInteger
+ | | | | +--rw nrp:cir? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:cirMax? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:cbs? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:eir? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:eirMax? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:ebs? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:couplingFlag? nrp-types:NRP_NaturalNumber
+ | | | | +--rw nrp:colorMode? nrp-types:NRP_ColorMode
+ | | | | +--rw nrp:rank? nrp-types:NRP_PositiveInteger
+ | | | | +--rw nrp:tokenRequestOffset? nrp-types:NRP_NaturalNumber
+ | | | +--rw nrp:egressBwpUni
+ | | | +--rw nrp:bwpFlowIndex? nrp-types:NRP_PositiveInteger
+ | | | +--rw nrp:cir? nrp-types:NRP_NaturalNumber
+ | | | +--rw nrp:cirMax? nrp-types:NRP_NaturalNumber
+ | | | +--rw nrp:cbs? nrp-types:NRP_NaturalNumber
+ | | | +--rw nrp:eir? nrp-types:NRP_NaturalNumber
+ | | | +--rw nrp:eirMax? nrp-types:NRP_NaturalNumber
+ | | | +--rw nrp:ebs? nrp-types:NRP_NaturalNumber
+ | | | +--rw nrp:couplingFlag? nrp-types:NRP_NaturalNumber
+ | | | +--rw nrp:colorMode? nrp-types:NRP_ColorMode
+ | | | +--rw nrp:rank? nrp-types:NRP_PositiveInteger
+ | | | +--rw nrp:tokenRequestOffset? nrp-types:NRP_NaturalNumber
+ | | +--rw adapterPropertySpecList* [uuid]
+ | | | +--rw uuid string
+ | | +--rw providerViewSpec
+ | | +--rw serverSpecList* [uuid]
+ | | +--rw uuid string
+ | +--rw configuredClientCapacity? string
+ | +--rw lpDirection? onf-cnt:TerminationDirection
+ | +--rw terminationState? string
+ +--rw ltpSpec
+ +--rw ltpDirection? onf-cnt:TerminationDirection
It is implemented as two major components
-- `VTN Manager <#_vtn_manager>`__
+- :ref:`vtn-manager`
-- `VTN Coordinator <#_vtn_coordinator>`__
+- :ref:`vtn-coordinator`
+
+.. _vtn-manager:
VTN Manager
~~~~~~~~~~~
| | | rdinator:RestApi:L2_Netw |
| | | ork_Example_Using_VTN_Vi |
| | | rtualization>`__ |
-| | | for usage. |
+| | | for usage. |
+--------------------------+--------------------------+--------------------------+
Feature Overview
To Log in to DLUX, after installing the application:
- Open a browser and enter the login URL as
- `http://<OpenDaylight-IP>:8181/index.html <http://<OpenDaylight-IP>:8181/index.html>`__.
+ http://<OpenDaylight-IP>:8181/index.html
.. note::
YANG documentation for VTN Manager, please refer to:
https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/apidocs/index.html
+.. _vtn-coordinator:
+
VTN Coordinator
~~~~~~~~~~~~~~~
Javadocs are generated while creating mvn:site and they are located in
target/ directory in each module.
-
-.. |Openstack Integration| image:: ./images/openstack_integration.png
-.. |Screenshot8| image:: ./images/Screenshot8.png
- :width: 500px
people.
.. contents:: Contents
- :depth: 1
+ :depth: 2
:local:
Style Guide
^, for subsubsections
", for paragraphs
-
Troubleshooting
---------------
+Nested formatting doesn't work
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+As stated in the reStructuredText_ guide, inline markup for bold,
+italic, and fixed-width can't be nested. Further, it can't be mixed
+with hyperlinks, so you can't have bold text link somewhere.
+
+This is tracked in a `Docutils FAQ question
+<http://docutils.sourceforge.net/FAQ.html#is-nested-inline-markup-possible>`,
+but there is no clear current plan to fix this.
+
Make sure you've cloned submodules
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
rm -rf .tox
tox -edocs
+Builds on Read the Docs
+^^^^^^^^^^^^^^^^^^^^^^^
+
+It appears as though the Read the Docs builds don't automatically clear
+the file structure between builds and clones. The result is that you
+may have to clean up the state of old runs of the build script.
+
+As an example, this patch:
+https://git.opendaylight.org/gerrit/41679
+
+Finally fixed the fact that our builds for failing because they were
+taking too long by removing directories of generated javadoc that were
+present from previous runs.
+
AsciiDoc-based Documentation
============================
To something like::
- .. image:: images/dlux-default.png
+ .. figure:: images/dlux-default.png
A helpful regular expression for automating the replacements is
something like::
replace: $1.. figure:: images/dlux/$3\n$1 :width: $5\n\n$1 $2
+Project Documentation Requirements
+==================================
+
+Submitting Documentation Outlines (M3)
+--------------------------------------
+
+#. Determine the features your project will have and which ones will be
+ ''user-facing''.
+
+ * In general, a feature is user-facing if it creates functionality that a
+ user would direction interact with.
+ * For example, ``odl-openflowplugin-flow-services-ui`` is likely
+ user-facing since it installs user-facing OpenFlow features, while
+ ``odl-openflowplugin-flow-services`` is not because it provides only
+ developer-facing features.
+
+#. Determine pieces of documentation you need provide based on the features
+ your project will have and which ones will be user-facing.
+
+ * The kinds of required documentation can be found below in the
+ :ref:`requirements-for-projects` section.
+ * Note that you might need to create multiple different documents for the
+ same kind of documentation. For example, the controller project will
+ likely want to have a developer section for the config subsystem as well
+ as a for the MD-SAL.
+
+#. Clone the docs repo: ``git clone https://git.opendaylight.org/gerrit/docs``
+#. For each piece of documentation find the corresponding template in the docs repo.
+
+ * For user documentation: ``docs.git/manuals/readme/src/main/asciidoc/template_user_guide.adoc``
+ * For developer documentation: ``docs.git/manuals/readme/src/main/asciidoc/template_developer_guide.adoc``
+ * For installation documentation (if any): ``docs.git/manuals/readme/src/main/asciidoc/template_installation_guide.adoc``
+
+#. Copy the template into the appropriate directory for your project.
+
+ * For user documentation: ``docs.git/manuals/user-guide/src/main/asciidoc/${project-shortname}/${feature-name}-user.adoc``
+ * For developer documentation: ``docs.git/manuals/developer-guide/src/main/asciidoc/${project-shortname}/${feature-name}-dev.adoc``
+ * For installation documentation (if any): ``docs.git/manuals/install-guide/src/main/asciidoc/${project-shortname}/${feature-name}-install.adoc``
+
+#. Edit the template to fill in the outline of what you will provide using the
+ suggestions in the template.
+
+ * DO NOT leave any sections blank as blank sections will cause build errors.
+
+#. Link the template into the appropriate core adoc file
+
+ * For user documentation: ``docs.git/manuals/user-guide/src/main/asciidoc/bk-user-guide.adoc``
+ * For developer documentation: ``docs.git/manuals/developer-guide/src/main/asciidoc/bk-developers-guide.adoc``
+ * For installation documentation (if any): ``docs.git/manuals/install-guide/src/main/asciidoc/bk-install-guide.adoc``
+ * Add a line like:
+
+ .. code-block:: none
+
+ include::${project-shortname}/${feature-name}-user.adoc[]
+
+ * Make sure there is a blank line between your include statement and any others as this prevents sections from running into each other.
+
+#. Make sure the documentation project still builds.
+
+ * Run ``mvn clean install`` from the root of the cloned docs repo.
+
+ * After that, you should be able to find the PDF and HTML version of the
+ docs. Use ``find . -name *.pdf`` to find the PDF and the HTML is
+ always at ``target/docbkx/webhelp/${manual-name}/index.html``.
+
+ * The `AsciiDoc tips <https://wiki.opendaylight.org/view/CrossProject:Documentation_Group:Tools:AsciiDoc_Tips>`_
+ page provide common errors and solutions.
+ * If you still have problems e-mail the documentation group at
+ documentation@lists.opendaylight.org
+
+#. Commit and submit the patch
+
+ #. Commit using:
+
+ .. code-block:: bash
+
+ git add --all && git commit -sm "Documentation outline for ${project-shortname}"
+
+ #. Submit using:
+
+ .. code-block:: bash
+
+ git review
+
+ See the `Git-review Workflow <https://wiki.opendaylight.org/view/Git-review_Workflow>`_
+ page if you don't have git-review installed.
+
+#. Wait for the patch to be merged or to get feedback
+
+ * If you get feedback, make the requested changes and resubmit the patch.
+ * When you resubmit the patch, it's helpful if you also post a +0 reply to
+ the gerrit saying what patch set you just submitted and what you fixed in
+ the patch set.
+ * The documentation team will also be creating (or asking projects to
+ create) small groups of 2-4 projects that will peer review each other's
+ documentation. Patches which have seen a few cycles of peer review will be
+ prioritized for review and merge by the documentation team.
+
+Expected Output From Documentation Project
+------------------------------------------
+
+The expected output is (at least) 3 PDFs and equivalent web-based documentation:
+
+* User/Operator Guide
+* Developer Guide
+* Installation Guide
+
+These guides will consist of "front matter" produced by the documentation group
+and the per-project/per-feature documentation provided by the projects. Note
+that this is intended to be who is responsible for the documentation and should
+not be interpreted as preventing people not normally in the documentation group
+from helping with "front matter" nor preventing people from the documentation
+group from helping with per-project/per-feature documentation.
+
+Boron Project Documentation Requirements
+----------------------------------------
+
+.. _kinds-of-docs:
+
+Kinds of Documentation
+^^^^^^^^^^^^^^^^^^^^^^
+
+These are the expected kinds of documentation and target audiences for each kind.
+
+* **User/Operator:** for people looking to use the feature w/o writing code
+
+ * Should include an overview of the project/feature
+ * Should include description of availbe configuration options and what they do
+
+* **Developer:** for people looking to use the feature in code w/o modifying it
+
+ * Should include API documentation, e.g., enunciate for REST, Javadoc for
+ Java, ??? for RESTCONF/models
+
+* **Contributor:** for people looking to extend or modify the feature's source
+ code
+
+ .. note:
+
+ should be documented on the wiki not in asciidoc
+
+* **Installation:** for people looking for instructions to install the feature
+ after they have downloaded the ODL release
+
+ .. note:
+
+ audience is the same as User/Operator docs
+
+ * For most projects, this will be just a list of top-level features and
+ options
+
+ * As an example, l2switch-switch as the top-level feature with the -rest
+ and -ui options
+ * We'd also like them to note if the options should be checkboxes (i.e.,
+ they can each be turned on/off independently) or a drop down (i.e., at
+ most one can be selected)
+ * What other top-level features in the release are incompatible with each
+ feature
+ * This will likely be presented as a table in the documentation and the
+ data will likely also be consumed by automated installers/configurators/downloaders
+
+ * For some projects, there is extra installation instructions (for external
+ components) and/or configuration
+
+ * In that case, there will be a (sub)section in the documentation
+ describing this process.
+
+* **HowTo/Tutorial:** walk throughs and examples that are not general-purpose
+ documentation
+
+ * Generally, these should be done as a (sub)section of either user/operator
+ or developer documentation.
+ * If they are especially long or complex, they may belong on their own
+
+* **Release Notes:**
+
+ * Release notes are required as part of each project's release review. They
+ must also be translated into AsciiDoc for inclusion in the formal
+ documentation.
+
+.. _requirements-for-projects:
+
+Requirements for projects
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Projects MUST do the following
+
+* Provide `AsciiDoc-format <https://wiki.opendaylight.org/view/CrossProject:Documentation_Group:Tools:AsciiDoc_Tips>`_ documentation including
+
+ * Developer documentation for every feature
+
+ * Most projects will want to logically nest the documentation for
+ individual features under a single project-wide chapter or section
+ * This can be provided as a single .adoc file or multiple .adoc files if
+ the features fall into different groups
+ * This should start with ~300 word overview of the project and include
+ references to any automatically-generated API documentation as well as
+ more general developer information (see
+ :ref:`kinds-of-docs`).
+
+ * User/Operator documentation for every every user-facing feature (if any)
+
+ * ''Note: This should be per-feature, not per-project. User's shouldn't have to know which project a feature came from.''
+ * Intimately related features, e.g., l2switch-switch, l2switch-switch-rest, and l2switch-switch-ui, can be documented as one noting the differences
+ * This can be provided as a single .adoc file or multiple .adoc files if the features fall into different groups
+
+ * Installation documentation
+
+ * Most projects will simply provide a list of user-facing features and
+ options. See :ref:`kinds-of-docs` above.
+
+ * Release Notes (both on the wiki and AsciiDoc) as part of the release review.
+
+* This documentation will be contributed to the docs repo (or possibly imported from the project's own repo with tooling that is under development)
+
+ * Projects MAY be ENCOURGAGED to instead provide this from their own repository if the tooling is developed
+ * Projects choosing to meet the requirement this way MUST provide a patch to docs repo to import the project's documentation
+
+* Projects MUST cooperate with the documentation group on edits and enhancements to documentation
+
+ * Note that the documentation team will also be creating (or asking projects to create) small groups of 2-4 projects that will peer review each other's documentation. Patches which have seen a few cycles of peer review will be prioritized for review and merge by the documentation team.
+
+Timeline for Deliverables from Projects
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+* **M3:** Documentation Started
+
+ * Identified the kinds of documentation that will be provided and for what
+ features
+
+ * Release Notes are not required until release reviews at **RC2**
+
+ * Created the appropriate .adoc files in the docs repository (or their own
+ repository if the tooling is available)
+ * Have an outline for the expected documentation in those .adoc files
+ including the relevant (sub)sections and a sentence or two explaining what
+ will go there
+
+ * Obviusly, providing actual documentation in the (sub)sections is
+ encouraged and meets this requirement
+
+ * Milestone readout should include
+
+ #. the list of kinds of documentation
+ #. the list of corresponding .adoc files and their location, e.g., repo and
+ path
+ #. the list of commits creating those .adoc files
+ #. the current word counts of those .adoc files
+
+* **M4:** Documentation Continues
+
+ * The readout at M4 should include the word counts of all .adoc files with
+ links to commits
+ * The goal is to have draft documentation complete so that the documentation
+ group can comment on it.
+
+* **M5:** Documentation Complete
+
+ * All (sub)sections in all .adoc files have complete, readable, usable content.
+ * Ideally, there should have been some interaction with the documentation
+ group about any suggested edits and enhancements
+
+* **RC2:** Release notes
+ * Projects must provide release notes as .adoc pushed to integration (or
+ locally in the project's repository if the tooling is developed)
.. _AsciiDoc: http://www.methods.co.nz/asciidoc/
your gpg-agent to run a GUI window to ask for your passphrase and
give you an option to save your passphrase in the keychain.
- .. image:: images/pinentry-mac.png
+ .. figure:: images/pinentry-mac.png
:depth: 1
:local:
-Messaging4Transport
-===================
-Adds AMQP bindings to the MD-SAL, which makes all MD-SAL APIs available via
-that mechanism. AMQP bindings integration exposes the MD-SAL datatree, rpcs,
-and notifications via AMQP, when installed.
-
Network Intent Composition (NIC)
================================
Offers an interface with an abstraction layer for you to communicate
- odl-usc-channel-ui
- all
- * - VPN Service
- - Enables support for OpenStack VPNaaS
- - odl-vpnservice-core
- - all
-
* - VTN Manager
- Enables Virtual Tenant Network support
- odl-vtn-manager-rest
- odl-lispflowmapping-neutron
- self+all
- * - Messaging4Transport
- - Introduces an AMQP Northbound to MD-SAL
- - odl-messaging4transport
- - all
-
* - Network Intent Composition (NIC)
- Provides abstraction layer for communcating network intents (including
a distributed intent mapping service REST API) using either Hazelcast
centralize the coordination of encryption across a wide array of endpoint and
device types.
-VPN Service
-===========
-Implements the infrastructure services required to support L3 VPN service. It
-initially leverages open source routing applications as pluggable components.
-L3 services include:
-
-* The L3 VPN Manager
-* MP-BGP Routing Stack
-* MPLS Label Manager
-* NextHop Manager
-* FIB Service & Openstack Neutron Service
-
-The VPN Service offers:
-
-* An API for L3 VPN Services
-* Integration with open source routing suites, including Quagga & Ryu
-* OpenStack Integration with BGPVPN_Blueprint_ for end-to-end integration
-* OpenStack Neutron integration
-* VPN Service upstreamed as part of SDN-distributed routing and the VPN (SDNVPN)
- project of Open Platform for NFV project (OPNFV) (available in Brahmaputra
- release)
-* Network Overlay solution necessary for a Datacenter/Cloud environment
-
Virtual Tenant Network (VTN)
============================
Provides multi-tenant virtual network on an SDN controller, allowing you to
:maxdepth: 1
developer-guide/index
+ submodules/netvirt/docs/index
Content for OpenDaylight Contributors
release-process/index
submodules/spectrometer/docs/index
javadoc
+ submodules/genius/docs/index
.. Commenting the below out until we actually use it
.. Indices and tables
In case of ``"flat"``, the VLAN specific parameters are not filled out.
.. note:: In case of VXLAN network (i.e. ``network-type`` is ``"vxlan-network"``), no information is actually written
-into VPP Renderer datastore, as VXLAN is used for tenant-network (so no packets are going outside). Instead, VPP Renderer looks up GBP flood domains corresponding to existing VPP bridge domains trying to establish a VXLAN tunnel between them.
+ into VPP Renderer datastore, as VXLAN is used for tenant-network (so no packets are going outside). Instead, VPP Renderer looks up GBP flood domains corresponding to existing VPP bridge domains trying to establish a VXLAN tunnel between them.
For a ``port`` entity it is checked that ``vif-type`` contains ``"vhostuser"`` substring, and that ``device-owner`` contains a specific substring, namely ``"compute"``, ``"router"`` or ``"dhcp"``.
the dlux interface on http://$CONTROL_HOST:8181/dlux/index.html - the
default username and password is "admin/admin" (see screenshot below)
-.. image:: images/dlux-default.png
+.. figure:: images/dlux-default.png
Ensuring OpenStack network state is clean
-----------------------------------------
* If you reload DLUX, you should now see that all of your Open vSwitch nodes
are now connected to OpenDaylight
-.. image:: images/dlux-with-switches.png
+.. figure:: images/dlux-with-switches.png
* If something has gone wrong, check ``data/log/karaf.log`` under
the OpenDaylight distribution directory. If you do not see any interesting
:maxdepth: 1
autorelease
+ project-lifecycle
branch-cutting
simultaneous-release
--- /dev/null
+*****************
+Project lifecycle
+*****************
+
+This page documents the current rules to follow when adding and removing
+a particular project to Simultaneous Release (SR).
+
+List of states
+==============
+
+The state names are short negative phrases describing what is missing to
+progress to the following state.
+
+- **non-existent**
+ The project is not recognized by Technical Steering Committee (TSC) to be
+ part of OpenDaylight (ODL).
+- **non-participating**
+ The project is recognized byt TSC to be an ODL project, but the project has
+ not confirmed participation in SR for given release cycle.
+- **non-building**
+ The recognized project is willing to participate, but its current codebase is
+ not passing its own merge job, or the project artifacts are otherwise
+ unavailable in Nexus.
+- **failing-distribution-check**
+ Merge job passes, but project distribution-check job is either not defined
+ or failing.
+- **not-in-autorelease**
+ Project distribution-check passes, but the project is not added to
+ autorelease (git submodule, maven module)
+- **repo-not-in-integration**
+ Project is added do autorelease, but integration/distribution:features-index
+ is not listing all its feature repositories.
+- **feature-not-in-integration**
+ Feature repositories are referenced, but some user-facing features are absent
+ from integration/distribution:features-test
+- **feature-is-experimental**
+ All user-facing features are in features-test, but at least one corresponding
+ functiona CSIT jobs does not meet integration/test requirements.
+- **ready**
+
+.. note::
+
+ A project may change its state in both directions, this list is to make sure
+ a project is not left in an invalid state, for example present in
+ autorelease but without passing distribution-check job.
+
+.. todo::
+
+ - Add links to documents concerning project lifecycle from TSC point of view.
+ - Add links to M# templates, test requirements and other relevant info.
+ - Mention other jobs involved in verification (verify, validate-autorelease, ... releng-check-poms).
+ - Add back-references to this document (from integration/distribution, job definition templates, ...).
+ - Do we need a special rules applicable at Release Review?
+ - By adding features to integration, distribution-check job may start failing on issues
+ that were not visible before. Document a workaround or create a specialized verify-like job.
+ - Mention that some rules do not make sense for Integration/Distribution project, provide substitute rules.
After release candidate is built gpg sign artifacts using odlsign-bulk script in
**releng/builder/scripts**.
-.. code-block:: bash
+ .. code-block:: bash
- cd scripts/
- ./odlsign-bulk <staging-repo-id> # eg. autorelease-1367
+ cd scripts/
+ ./odlsign-bulk <staging-repo-id> # eg. autorelease-1367
Releasing OpenDaylight
======================
+- Block submit permissions for registered users and elevate RE's committer rights on gerrit.
+
+ .. figure:: images/gerrit-update-committer-rights.png
+
+- Export ${RELEASE} and ${BUILDNUM} with current release name and build number.
+
+ .. code-block:: bash
+
+ export RELEASE=Beryllium-SR4
+ export BRANCH=${RELEASE//-*}
+ export BUILDNUM=55
+
- Nexus: click release for staging repo **(Helpdesk)**
- Nexus: click release for gpgsign repo (created above in Preparations) **(Helpdesk)**
- Send email to Helpdesk with binary URL to update website **(Helpdesk)**
- Send email to TSC and Release mailing lists announcing release binaries location **(Release Engineering Team)**
-- Checkout autorelease and switch to release branch eg stable/carbon
- **(Release Engineering Team)**
+- Checkout autorelease and switch to release branch eg stable/carbon **(Release Engineering Team)**
+
+ .. code-block:: bash
+
+ git checkout -b stable/${BRANCH,,} origin/stable/${BRANCH,,}
+ git submodule update --init
+ git submodule foreach git checkout stable/${BRANCH,,} origin/stable/${BRANCH,,}
+
- Make sure your git repo is setup to push (use git-review)
.. code-block:: bash
- git review -s
+ git submodule foreach 'git review -s'
-- Download patches from Jenkins build page
+- Download patches (*.bundle files and taglist.log.gz) from log server.
.. code-block:: bash
- cd /tmp
- wget https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-boron/230/artifact/patches/*zip*/patches.zip
- unzip patches.zip
+ mkdir /tmp/patches && cd /tmp/patches
+ wget https://logs.opendaylight.org/releng/jenkins092/autorelease-release-${BRANCH,,}/${BUILDNUM}/archives/all-bundles.tar.gz
+ gunzip all-bundles.tar.gz
+ wget https://logs.opendaylight.org/releng/jenkins092/autorelease-release-${BRANCH,,}/${BUILDNUM}/archives/patches/taglist.log.gz
+ gunzip taglist.log.gz
-- Run the following commands for every project in the release
+- Run the following commands for every project in the release, to apply patches to each project directory.
.. code-block:: bash
- ../scripts/patch-odl-release.sh /tmp/patches Carbon
- git review -y -t Carbon
- git push gerrit release/carbon
+ ../scripts/patch-odl-release.sh /tmp/patches ${RELEASE}
+ git review -y -t ${RELEASE}
+ git push gerrit release/${RELEASE,,}
+
+- Merge all patches on gerrit in the order generated by merge-order.log
- Tag autorelease too
.. code-block:: bash
- git submodule foreach git checkout release/carbon
- git add [add each project individually to not pull in extra]
- git commit -sm "Release Carbon"
- git tag -asm "OpenDaylight Carbon release" release/carbon
- git review -y -t Carbon
- git push gerrit release/carbon
+ git checkout `cat /tmp/patches/taglist.log | grep autorelease | awk '{print $2}'`
+ git submodule foreach git checkout release/${RELEASE,,}
+ git commit -asSm "Release ${RELEASE}"
+ git tag -asm "OpenDaylight ${RELEASE} release" release/${RELEASE,,}
+ git push gerrit release/${RELEASE,,}
+
+- Re-enable submit permissions for registered users and disable elevated RE committer rights on gerrit.
- Generate release notes (???)
+
- Send email to release/tsc/dev notifying tagging and version bump complete **(Release Engineering Team)**
-Subproject commit 43caa2e08d468994a699f910ac4cd415ab8db00c
+Subproject commit 776ca501cf63459e2e62ab4a3375031dfa3ade82
--- /dev/null
+Subproject commit aca0ee3aa7632c6f98b027e8344ce6a6a01f9c2f
-Subproject commit bd6c15b1aaac20d1d9903168b8dca690e3ad039d
+Subproject commit 185680e2bf1ee2fad37c1c54d8fd0c0b59427919
-Subproject commit 03cd91edfcb91ebad953158eca8418806314b335
+Subproject commit e929de1fab104d1e8e960b9a4aa2eaf5f63bc32f
--- /dev/null
+Subproject commit 19492ed269c6e2954d9069980073bb1d05aa885b
-Subproject commit 2b5895ad62a478fea24eec83195d150e74981b38
+Subproject commit b9e27e08b90c1e20a75e256215e2f3280c111522
-Subproject commit ad9719929ee660307a58aafcaf9fe221f6d961c6
+Subproject commit 952d6d1b307e80c09b3b1df5d147babeaccc6f75
-Subproject commit 71a9169a009fc6602b6ff8861fc408034f9526bb
+Subproject commit d085b9f97bb7067f0429bb11218442ea650327be
BGP User Guide
==============
+This guide contains information on how to use OpenDaylight Border Gateway Protocol (BGP) plugin.
+The user should learn about BGP basic concepts, supported capabilities, configuration and usage.
+
+.. contents:: Contents
+ :depth: 1
+ :local:
+
+Overview
+--------
+This section provides high-level overview of the Border Gateway Protocol, OpenDaylight implementation and BGP usage in SDN era.
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+Border Gateway Protocol
+^^^^^^^^^^^^^^^^^^^^^^^
+The Border Gateway Protocol (BGP) is an inter-Autonomous System (AS) routing protocol.
+The primary role of the BGP is an exchange of routes among other BGP systems.
+The route is an unit of information which pairs destination (IP address prefix) with attributes to the path with the destination.
+One of the most interesting attributes is a list of ASes that the route traversed - essential when avoiding loop routing.
+Advertised routes are stored in the Routing Information Bases (RIBs). Routes are later used to forward packets, stored in Routing Table for this purpose.
+The main advantage of the BGP over other routing protocols is its scalability, thus it has become the standardized Internet routing protocol (Internet is a set of ASes).
+
+BGP in SDN
+^^^^^^^^^^
+However BGP evolved long time before SDN was born, it plays a significant role in many SDN use-cases.
+Also, continuous evolution of the protocol brings extensions that are very well suited for SDN.
+Nowadays, BGP can carry various types of routing information - L3VPN, L2VPN, IP multicast, linkstate, etc.
+Here is a brief list of software-based/legacy-network technologies where BGP-based SDN solution get into an action:
+
+* SDN WAN - WAN orchestration and optimization
+* SDN router - Turns switch into an Internet router
+* Virtual Route Reflector - High-performance server-based BGP Route Reflector
+* SDX - A Software Defined Internet Exchange controller
+* Large-Scale Data Centers - BGP Data Center Routing, MPLS/SR in DCs, DC interconnection
+* DDoS mitigation - Traffic Filtering distribution with BGP
+
+OpenDaylight BGP plugin
+^^^^^^^^^^^^^^^^^^^^^^^
+The OpenDaylight controller provides an implementation of BGP (RFC 4271) as a south-bound protocol plugin.
+The implementation renders all basic *BGP speaker capabilities*:
+
+* inter/intra-AS peering
+* routes advertising
+* routes originating
+* routes storage
+
+The plugin's **north-bound API** (``REST``/``Java``) provides to user:
+
+* fully dynamic runtime standardized BGP configuration
+* read-only access to all RIBs
+* read-write programmable RIBs
+* read-only reachability/linkstate topology view
+
+.. note:: The BGP plugin is NOT a virtual router - does not construct Routing Tables, nor forward traffic.
+
+List of supported capabilities
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+In addition to the base protocol implementation, the plugin provides many extensions to BGP, all based on IETF standards.
+
+* `RFC4271 <https://tools.ietf.org/html/rfc4271>`_ - A Border Gateway Protocol 4 (BGP-4)
+* `RFC4456 <https://tools.ietf.org/html/rfc4456>`_ - BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
+* `RFC1997 <https://tools.ietf.org/html/rfc1997>`_ - BGP Communities Attribute
+* `RFC4360 <https://tools.ietf.org/html/rfc4360>`_ - BGP Extended Communities Attribute
+* `RFC4486 <https://tools.ietf.org/html/rfc4486>`_ - Subcodes for BGP Cease Notification Message
+* `RFC5492 <https://tools.ietf.org/html/rfc5492>`_ - Capabilities Advertisement with BGP-4
+* `RFC5004 <https://tools.ietf.org/html/rfc5004>`_ - Avoid BGP Best Path Transitions from One External to Another
+* `RFC6286 <https://tools.ietf.org/html/rfc6286>`_ - Autonomous-System-Wide Unique BGP Identifier for BGP-4
+* `RFC6793 <https://tools.ietf.org/html/rfc6793>`_ - BGP Support for Four-Octet Autonomous System (AS) Number Space
+* `RFC7311 <https://tools.ietf.org/html/rfc7311>`_ - The Accumulated IGP Metric Attribute for BGP
+* `RFC5668 <https://tools.ietf.org/html/rfc5668>`_ - 4-Octet AS Specific BGP Extended Community
+* `draft-ietf-idr-link-bandwidth <https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-06>`_ - BGP Link Bandwidth Extended Community
+* `draft-ietf-idr-bgp-extended-messages <https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-13>`_ - Extended Message support for BGP
+* `RFC4760 <https://tools.ietf.org/html/rfc4760>`_ - Multiprotocol Extensions for BGP-4
+ * `RFC7752 <https://tools.ietf.org/html/rfc7752>`_ - North-Bound Distribution of Link-State and TE Information using BGP
+ * `draft-gredler-idr-bgp-ls-segment-routing-ext <https://tools.ietf.org/html/draft-gredler-idr-bgp-ls-segment-routing-ext-03>`_ - BGP Link-State extensions for Segment Routing
+ * `draft-ietf-idr-bgpls-segment-routing-epe <https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-05>`_ - Segment Routing Egress Peer Engineering BGP-LS Extensions
+ * `RFC5575 <https://tools.ietf.org/html/rfc5575>`_ - Dissemination of Flow Specification Rules
+ * `RFC7674 <http://tools.ietf.org/html/rfc7674>`_ - Clarification of the Flowspec Redirect Extended Community
+ * `draft-ietf-idr-flow-spec-v6 <https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-07>`_ - Dissemination of Flow Specification Rules for IPv6
+ * `draft-ietf-idr-flowspec-redirect-ip <https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-ip-00>`_ - BGP Flow-Spec Redirect to IP Action
+ * `RFC3107 <https://tools.ietf.org/html/rfc3107>`_ - Carrying Label Information in BGP-4
+ * `draft-ietf-idr-bgp-prefix-sid <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-03>`_ - Segment Routing Prefix SID extensions for BGP
+ * `RFC4364 <https://tools.ietf.org/html/rfc4364>`_ - BGP/MPLS IP Virtual Private Networks (VPNs)
+ * `RFC4659 <https://tools.ietf.org/html/rfc4659>`_ - BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
+ * `RFC7432 <https://tools.ietf.org/html/rfc7432>`_ - BGP MPLS-Based Ethernet VPN
+ * `draft-ietf-bess-evpn-overlay <https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-04>`_ - A Network Virtualization Overlay Solution using EVPN
+ * `draft-ietf-bess-evpn-vpws <https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-07>`_ - VPWS support in EVPN
+* `RFC7911 <https://tools.ietf.org/html/rfc7911>`_ - Advertisement of Multiple Paths in BGP
+* `RFC2918 <https://tools.ietf.org/html/rfc2918>`_ - Route Refresh Capability for BGP-4
+
+Running BGP
+-----------
+This section explains how to install BGP plugin.
+
+1. Install BGP feature - ``odl-bgpcep-bgp``.
+ Also, for sake of this sample, it is required to install RESTCONF.
+ In the Karaf console, type command:
+
+ .. code-block:: console
+
+ feature:install odl-restconf odl-bgpcep-bgp
+
+2. The BGP plugin contains a default configuration, which is applied after the feature starts up.
+ One instance of BGP plugin is created (named *example-bgp-rib*), and its presence can be verified via REST:
+
+ **URL:** ``/restconf/operational/bgp-rib:bgp-rib``
+
+ **Method:** ``GET``
+
+ **Response Body:**
+
+ .. code-block:: xml
+
+ <bgp-rib xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
+ <rib>
+ <id>example-bgp-rib</id>
+ <loc-rib>
+ ....
+ </loc-rib>
+ </rib>
+ </bgp-rib>
+
+Basic Configuration & Concepts
+------------------------------
+The following section shows how to configure BGP basics, how to verify functionality and presents essential components of the plugin.
+Next samples demonstrate the plugin's runtime configuration capability.
+It shows the way to configure the plugin via REST, using standardized OpenConfig BGP APIs.
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+BGP RIB API
+^^^^^^^^^^^
+This tree illustrates the BGP RIBs organization in datastore.
+
+.. code-block:: console
+
+ bgp-rib
+ +--ro rib* [id]
+ +--ro id rib-id
+ +--ro peer* [peer-id]
+ | +--ro peer-id peer-id
+ | +--ro peer-role peer-role
+ | +--ro simple-routing-policy? simple-routing-policy
+ | +--ro supported-tables* [afi safi]
+ | | +--ro afi identityref
+ | | +--ro safi identityref
+ | | +--ro send-receive? send-receive
+ | +--ro adj-rib-in
+ | | +--ro tables* [afi safi]
+ | | +--ro afi identityref
+ | | +--ro safi identityref
+ | | +--ro attributes
+ | | | +--ro uptodate? boolean
+ | | +--ro (routes)?
+ | +--ro effective-rib-in
+ | | +--ro tables* [afi safi]
+ | | +--ro afi identityref
+ | | +--ro safi identityref
+ | | +--ro attributes
+ | | | +--ro uptodate? boolean
+ | | +--ro (routes)?
+ | +--ro adj-rib-out
+ | +--ro tables* [afi safi]
+ | +--ro afi identityref
+ | +--ro safi identityref
+ | +--ro attributes
+ | | +--ro uptodate? boolean
+ | +--ro (routes)?
+ +--ro loc-rib
+ +--ro tables* [afi safi]
+ +--ro afi identityref
+ +--ro safi identityref
+ +--ro attributes
+ | +--ro uptodate? boolean
+ +--ro (routes)?
+
+Protocol Configuration
+^^^^^^^^^^^^^^^^^^^^^^
+As a first step, a new protocol instance needs to be configured.
+It is a very basic configuration conforming with RFC4271.
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 2,7,8
+
+ <protocol xmlns="http://openconfig.net/yang/network-instance">
+ <name>bgp-example</name>
+ <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
+ <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <global>
+ <config>
+ <router-id>192.0.2.2</router-id>
+ <as>65000</as>
+ </config>
+ </global>
+ </bgp>
+ </protocol>
+
+@line 2: The unique protocol instance identifier.
+
+@line 7: BGP Identifier of the speaker.
+
+@line 8: Local autonomous system number of the speaker. Note that, OpenDaylight BGP implementation supports four-octet AS numbers only.
+
+-----
+
+The new instance presence can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 3,4
+
+ <rib xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
+ <id>bgp-example</id>
+ <loc-rib>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet"></ipv4-routes>
+ <attributes>
+ <uptodate>true</uptodate>
+ </attributes>
+ </tables>
+ </loc-rib>
+ </rib>
-Configuring BGP
----------------
+@line 3: Loc-RIB - Per-protocol instance RIB, which contains the routes that have been selected by local BGP speaker's decision process.
-The OpenDaylight Karaf distribution comes pre-configured with a baseline
-BGP configuration. You can find it in the ``etc/opendaylight/karaf``
-directory and it consists of two files:
+@line 4: The BGP-4 supports carrying IPv4 prefixes, such routes are stored in *ipv4-address-family*/*unicast-subsequent-address-family* table.
-``31-bgp.xml``
- defines the basic parser and RIB support
+BGP Server
+^^^^^^^^^^
-``41-bgp-example.xml``
- contains a sample configuration which needs to be customized to your
- deployment)
+BGP uses TCP as its transport protocol, by default listens on port 179. OpenDaylight BGP plugin is configured to listen on port *1790*, due to
+privileged ports restriction for non-root users.
+One of the workarounds is to use port redirection. In case other port is desired to be used instead, we can reconfigure it.
-The next sections will describe how to configure BGP manually or using
-RESTCONF.
+Here is a sample of bgp port listening re-configuration:
-RIB
-~~~
+**URL:** ``/restconf/config/bgp-peer-acceptor-config:bgp-peer-acceptor-config/default``
-The configuration of the Routing Information Base (RIB) is specified
-using a block in the ``41-bgp-example.xml`` file.
+**Method:** ``PUT``
-.. code:: xml
+**Content-Type:** ``application/xml``
- <module>
- <type>prefix:rib-impl</type>
- <name>example-bgp-rib</name>
- <rib-id>example-bgp-rib</rib-id>
- <local-as>64496</local-as>
- <bgp-id>192.0.2.2</bgp-id>
- <cluster-id>192.0.2.3</cluster-id>
- ...
- </module>
+**Request Body:**
-- **type** - should always be set to ``prefix:rib-impl``
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 3,4
-- **name** and **rib-id** - BGP RIB Identifier, you can specify
- multiple BGP RIBs by having multiple the above ``module`` blocks.
- Each such RIB must have a unique rib-id and name.
+ <bgp-peer-acceptor-config xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
+ <config-name xmlns="urn:opendaylight:params:xml:ns:yang:bgp-peer-acceptor-config">default</config-name>
+ <binding-address xmlns="urn:opendaylight:params:xml:ns:yang:bgp-peer-acceptor-config">0.0.0.0</binding-address>
+ <binding-port xmlns="urn:opendaylight:params:xml:ns:yang:bgp-peer-acceptor-config">1791</binding-port>
+ </bgp-peer-acceptor-config>
-- **local-as** - the local AS number (where OpenDaylight is deployed),
- we use this in best path selection
+@line 3: Binding address: By default is 0.0.0.0, so it is not a mandatory field.
-- **bgp-id** - the local BGP identifier (the IP of the VM where
- OpenDaylight is deployed), we use this in best path selection.
+@line 4: Binding Port: Port were BGP Server will listen.
-- **cluster-id** - cluster identifier, optional, if not specified, BGP
- Identifier will be used
+BGP Peering
+^^^^^^^^^^^
+To exchange routing information between two BGP systems (peers), it is required to configure a peering on both BGP speakers first.
+This mean that each BGP speaker has a white list of neighbors, representing remote peers, with which the peering is allowed.
+The TCP connection is established between two peers and they exchange messages to open and confirm the connection parameters followed by routes exchange.
-Depending on your BGP router, you might need to switch from linkstate
-attribute type 99 to 29. Check with your router vendor. Change the field
-iana-linkstate-attribute-type to true if your router supports type 29.
-This snippet is located in ``31-bgp.xml`` file.
+Here is a sample basic neighbor configuration:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 3,4
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.1</neighbor-address>
+ <timers>
+ <config>
+ <hold-time>90</hold-time>
+ <connect-retry>10</connect-retry>
+ </config>
+ </timers>
+ <transport>
+ <config>
+ <remote-port>179</remote-port>
+ <passive-mode>false</passive-mode>
+ </config>
+ </transport>
+ <config>
+ <peer-type>INTERNAL</peer-type>
+ </config>
+ </neighbor>
+
+@line 2: IP address of the remote BGP peer. Also serves as an unique identifier of a neighbor in a list of neighbors.
+
+@line 5: Proposed number of seconds for value of the Hold Timer. Default value is **90**.
+
+@line 6: Time interval in seconds between attempts to establish session with the peer. Effective in active mode only. Default value is **30**.
+
+@line 11: Remote port number to which the local BGP is connecting. Effective in active mode only. Default value **179**.
+
+@line 12: Wait for peers to issue requests to open a BGP session, rather than initiating sessions from the local router. Default value is **false**.
+
+@line 16: Explicitly designate the peer as internal or external. Default value is **INTERNAL**.
+
+-----
+
+Once the remote peer is connected and it advertised routes to local BGP system, routes are stored in peer's RIBs.
+The RIBs can be checked via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/peer/bgp:%2F%2F192.0.2.1``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 8,13,35,40,62,66
+
+ <peer xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
+ <peer-id>bgp://192.0.2.1</peer-id>
+ <supported-tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ </supported-tables>
+ <peer-role>ibgp</peer-role>
+ <adj-rib-in>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <ipv4-route>
+ <path-id>0</path-id>
+ <prefix>10.0.0.10/32</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.10.1.1</global>
+ </ipv4-next-hop>
+ </attributes>
+ </ipv4-route>
+ </ipv4-routes>
+ <attributes>
+ <uptodate>true</uptodate>
+ </attributes>
+ </tables>
+ </adj-rib-in>
+ <effective-rib-in>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <ipv4-route>
+ <path-id>0</path-id>
+ <prefix>10.0.0.10/32</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.10.1.1</global>
+ </ipv4-next-hop>
+ </attributes>
+ </ipv4-route>
+ </ipv4-routes>
+ <attributes>
+ <uptodate>true</uptodate>
+ </attributes>
+ </tables>
+ </effective-rib-in>
+ <adj-rib-out>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet"></ipv4-routes>
+ <attributes></attributes>
+ </tables>
+ </adj-rib-out>
+ </peer>
+
+@line 8: **Adj-RIB-In** - Per-peer RIB, which contains unprocessed routes that has been advertised to local BGP speaker by the remote peer.
+
+@line 13: Here is the reported route with destination *10.0.0.10/32* in Adj-RIB-In.
+
+@line 35: **Effective-RIB-In** - Per-peer RIB, which contains processed routes as a result of applying inbound policy to Adj-RIB-In routes.
+
+@line 40: Here is the reported route with destination *10.0.0.10/32*, same as in Adj-RIB-In, as it was not touched by import policy.
+
+@line 62: **Adj-RIB-Out** - Per-peer RIB, which contains routes for advertisement to the peer by means of the local speaker's UPDATE message.
+
+@line 66: The peer's Adj-RIB-Out is empty as there are no routes to be advertise from local BGP speaker.
+
+-----
+
+Also the same route should appeared in Loc-RIB now:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 4,6,8,11,14
+
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <ipv4-route>
+ <path-id>0</path-id>
+ <prefix>10.0.0.10/32</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.10.1.1</global>
+ </ipv4-next-hop>
+ </attributes>
+ </ipv4-route>
+ </ipv4-routes>
-.. code:: xml
+@line 4: **Destination** - IPv4 Prefix Address.
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bgp:linkstate">prefix:bgp-linkstate</type>
- <name>bgp-linkstate</name>
- <iana-linkstate-attribute-type>true</iana-linkstate-attribute-type>
- </module>
+@line 6: **AS_PATH** - mandatory attribute, contains a list of the autonomous system numbers through that routing information has traversed.
-- **iana-linkstate-attribute-type** - IANA has issued an early
- allocation for the BGP linkstate path attribute (=29). To preserve he
- old value (=99) set this to to false; to use IANA assigned type set
- the value to true or remove it as it’s true by default.
+@line 8: **ORIGIN** - mandatory attribute, indicates an origin of the route - **ibgp**, **egp**, **incomplete**.
-BGP Peer
-~~~~~~~~
-
-The initial configuration is written so that it will be ignored to
-prevent the client from starting with default configuration. Therefore
-the first step is to uncomment the module containing bgp-peer.
-
-.. code:: xml
-
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">prefix:bgp-peer</type>
- <name>example-bgp-peer</name>
- <host>192.0.2.1</host>
- <holdtimer>180</holdtimer>
- <peer-role>ibgp</peer-role>
- <rib>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">prefix:rib-instance</type>
- <name>example-bgp-rib</name>
- </rib>
- ...
- </module>
-
-- **name** - BGP Peer name, in this configuration file you specify
- multiple BGP Peers by replicating the above ``module`` block. Each
- peers must have a unique name.
-
-- **host** - IP address or hostname of BGP speaker where OpenDaylight
- should connect to the peer
-
-- **holdtimer** - hold time in seconds
-
-- **peer-role** - If peer role is not present, default value "ibgp"
- will be used (other allowed values are "ebgp" and "rr-client"). This
- field is case-sensitive.
-
-- **rib** - BGP RIB identifier
-
-Configure Connection Attributes (Optional)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.. code:: xml
-
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:reconnectstrategy">prefix:timed-reconnect-strategy</type>
- <name>example-reconnect-strategy</name>
- <min-sleep>1000</min-sleep>
- <max-sleep>180000</max-sleep>
- <sleep-factor>2.00</sleep-factor>
- <connect-time>5000</connect-time>
- <executor>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-event-executor</type>
- <name>global-event-executor</name>
- </executor>
- </module>
-
-- **min-sleep** - minimum sleep time (miliseconds) in between reconnect
- tries
-
-- **max-sleep** - maximum sleep time (miliseconds) in between reconnect
- tries
-
-- **sleep-factor** - power factor of the sleep time between reconnect
- tries, i.e., the previous sleep time will be multiplied by this
- number to determine the next sleep time, but never exceed
- **max-sleep**
-
-- **connect-time** - how long BGP should wait (miliseconds) for the TCP
- connect attempt, overrides default connection timeout dictated by
- TCP.
-
-BGP Speaker Configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The previous entries described configuration of a BGP connections
-initiated by OpenDaylight. OpenDaylight can also accept incoming BGP
-connections.
-
-The configuration of BGP speaker is located in: ``41-bgp-example.xml``:
-
-.. code:: xml
-
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">prefix:bgp-peer-acceptor</type>
- <name>bgp-peer-server</name>
-
- <!--Default parameters-->
- <!--<binding-address>0.0.0.0</binding-address>-->
- <!--<binding-port>1790</binding-port>-->
-
- ...
- <!--Drops or accepts incoming BGP connection, every BGP Peer that should be accepted needs to be added to this registry-->
- <peer-registry>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">prefix:bgp-peer-registry</type>
- <name>global-bgp-peer-registry</name>
- </peer-registry>
- </module>
-
-- Changing binding address: Uncomment tag binding-address and change
- the address to e.g. *127.0.0.1*. The default binding address is
- *0.0.0.0*.
-
-- Changing binding port: Uncomment tag binding-port and change the port
- to e.g. *1790*. The default binding port is *179* as specified in
- `RFC 4271 <http://tools.ietf.org/html/rfc4271>`__.
-
-Incomming BGP Connections
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**The BGP speaker drops all BGP connections from unknown BGP peers.**
-The decision is made in component bgp-peer-registry that is injected
-into the speaker (The registry is configured in ``31-bgp.xml``).
-
-To add a BGP Peer configuration into the registry, it is necessary to
-configure regular BGP peer just like in example in
-``41-bgp-example.xml``. Notice that the BGP peer depends on the same
-bgp-peer-registry as bgp-speaker:
-
-.. code:: xml
-
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">prefix:bgp-peer</type>
- <name>example-bgp-peer</name>
- <host>192.0.2.1</host>
- ...
- <peer-registry>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">prefix:bgp-peer-registry</type>
- <name>global-bgp-peer-registry</name>
- </peer-registry>
- ...
- </module>
-
-The BGP peer registers itself into the registry, which allows incoming
-BGP connections handled by the bgp-speaker. (Config attribute
-peer-registry is optional for now to preserve backwards compatibility).
-With this configuration, the connection to 192.0.2.1 is initiated by
-OpenDaylight but will also be accepted from 192.0.2.1. In case both
-connections are being established, only one of them will be preserved
-and the other will be dropped. The connection initiated from device with
-lower BGP id will be dropped by the registry. Each BGP peer must be
-configured in its own ``module`` block. Note, that the name of the
-module needs to be unique, so if you are configuring more peers, when
-changing the **host**, also change the **name**.
-
-To configure a peer that only listens for incoming connections and
-instruct OpenDaylight not to initiate the connection, add the
-initiate-connection attribute to peer’s configuration and set it to
-false:
-
-.. code:: xml
-
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">prefix:bgp-peer</type>
- <name>example-bgp-peer</name>
- <host>192.0.2.1</host> // IP address or hostname of the speaker
- <holdtimer>180</holdtimer>
- <initiate-connection>false</initiate-connection> // Connection will not be initiated by ODL
- ...
- </module>
-
-- **initiate-connection** - if set to false OpenDaylight will not
- initiate connection to this peer. Default value is true.
-
-BGP Application Peer
-~~~~~~~~~~~~~~~~~~~~
-
-A BGP speaker needs to register all peers that can be connected to it
-(meaning if a BGP peer is not configured, the connection with
-OpenDaylight won’t be successful). As a first step, configure RIB. Then,
-instead of configuring regular peer, configure this application peer,
-with its own application RIB. Change the bgp-peer-id, which is your
-local BGP ID that will be used in BGP best path selection algorithm.
-
-.. code:: xml
-
- <module>
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-application-peer</type>
- <name>example-bgp-peer-app</name>
- <bgp-peer-id>10.25.1.9</bgp-peer-id>
- <target-rib>
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:rib-instance</type>
- <name>example-bgp-rib</name>
- </target-rib>
- <application-rib-id>example-app-rib</application-rib-id>
- ...
- </module>
-
-- **bgp-peer-id** - the local BGP identifier (the IP of the VM where
- OpenDaylight is deployed), we use this in best path selection
-
-- **target-rib** - RIB ID of existing RIB where the data should be
- transferred
-
-- **application-rib-id** - RIB ID of local application RIB (all the
- routes that you put to OpenDaylight will be displayed here)
-
-Configuration through RESTCONF
-------------------------------
+@line 11: **LOCAL_PREF** - indicates a degree of preference for external routes, higher value is preferred.
-Another method to configure BGP is dynamically through RESTCONF. Instead
-of restarting Karaf, install another feature, that provides you the
-access to *restconf/config/* URLs.
-
-::
-
- feature:install odl-netconf-connector-all
-
-To check what modules you have currently configured, check following
-link:
-http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/
-
-This URL is also used to POST new configuration. If you want to change
-any other configuration that is listed here, make sure you include the
-correct namespaces. RESTCONF will tell you if some namespace is wrong.
-
-To update an existing configuration use **PUT** and give the full path
-to the element you wish to update.
-
-It is vital that you respect the order of steps described in user guide.
-
-RIB
-~~~
-
-First, configure the RIB. This module is already present in the
-configuration, therefore we change only the parameters we need. In this
-case, it’s **bgp-rib-id** and **local-as**.
-
-**URL:**
-*http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-bgp-rib-impl-cfg:rib-impl/example-bgp-rib*
-
-**PUT:**
-
-.. code:: xml
-
- <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:rib-impl</type>
- <name>example-bgp-rib</name>
- <session-reconnect-strategy xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:protocol:framework">x:reconnect-strategy-factory</type>
- <name>example-reconnect-strategy-factory</name>
- </session-reconnect-strategy>
- <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">example-bgp-rib</rib-id>
- <extensions xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:spi">x:extensions</type>
- <name>global-rib-extensions</name>
- </extensions>
- <codec-tree-factory xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">x:binding-codec-tree-factory</type>
- <name>runtime-mapping-singleton</name>
- </codec-tree-factory>
- <tcp-reconnect-strategy xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:protocol:framework">x:reconnect-strategy-factory</type>
- <name>example-reconnect-strategy-factory</name>
- </tcp-reconnect-strategy>
- <data-provider xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">x:binding-async-data-broker</type>
- <name>pingpong-binding-data-broker</name>
- </data-provider>
- <local-as xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">64496</local-as>
- <bgp-dispatcher xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type>bgp-dispatcher</type>
- <name>global-bgp-dispatcher</name>
- </bgp-dispatcher>
- <dom-data-provider xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">x:dom-async-data-broker</type>
- <name>pingpong-broker</name>
- </dom-data-provider>
- <local-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type>bgp-table-type</type>
- <name>ipv4-unicast</name>
- </local-table>
- <local-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type>bgp-table-type</type>
- <name>ipv6-unicast</name>
- </local-table>
- <local-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type>bgp-table-type</type>
- <name>linkstate</name>
- </local-table>
- <local-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type>bgp-table-type</type>
- <name>ipv4-flowspec</name>
- </local-table>
- <local-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type>bgp-table-type</type>
- <name>ipv6-flowspec</name>
- </local-table>
- <local-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type>bgp-table-type</type>
- <name>labeled-unicast</name>
- </local-table>
- <bgp-rib-id xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">192.0.2.2</bgp-rib-id>
- <openconfig-provider xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp-openconfig-spi">x:bgp-openconfig-provider</type>
- <name>openconfig-bgp</name>
- </openconfig-provider>
- </module>
-
-Depending on your BGP router, you might need to switch from linkstate
-attribute type 99 to 29. Check with your router vendor. Change the field
-iana-linkstate-attribute-type to true if your router supports type 29.
-You can do that with the following RESTCONF operation:
-
-**URL:**
-*http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-bgp-linkstate-cfg:bgp-linkstate/bgp-linkstate*
-
-**PUT:**
-
-.. code:: xml
-
- <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:linkstate">x:bgp-linkstate</type>
- <name>bgp-linkstate</name>
- <iana-linkstate-attribute-type xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:linkstate">true</iana-linkstate-attribute-type>
- </module>
+@line 14: **NEXT_HOP** - mandatory attribute, defines IP address of the router that should be used as the next hop to the destination.
-BGP Peer
-~~~~~~~~
-
-We also need to add a new module to configuration (bgp-peer). In this
-case, the whole module needs to be configured. Please change values
-**host**, **holdtimer** and **peer-role** (if necessary).
-
-**URL:**
-*http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules*
-
-**POST:**
-
-.. code:: xml
-
- <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-peer</type>
- <name>example-bgp-peer</name>
- <host xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">192.0.2.1</host>
- <holdtimer xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">180</holdtimer>
- <peer-role xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">ibgp</peer-role>
- <rib xmlns"urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:rib-instance</type>
- <name>example-bgp-rib</name>
- </rib>
- <peer-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-peer-registry</type>
- <name>global-bgp-peer-registry</name>
- </peer-registry>
- <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type>
- <name>ipv4-unicast</name>
- </advertized-table>
- <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type>
- <name>ipv6-unicast</name>
- </advertized-table>
- <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type>
- <name>linkstate</name>
- </advertized-table>
- <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type>
- <name>ipv4-flowspec</name>
- </advertized-table>
- <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type>
- <name>ipv6-flowspec</name>
- </advertized-table>
- <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type>
- <name>labeled-unicast</name>
- </advertized-table>
- </module>
-
-This is all necessary information that you need to get ODL connect to
-your speaker.
-
-BGP Application Peer
-~~~~~~~~~~~~~~~~~~~~
-
-Change the value **bgp-peer-id** which is your local BGP ID that will be
-used in BGP Best Path Selection algorithm.
-
-**URL:**
-*http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules*
-
-**POST:**
-
-.. code:: xml
-
- <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-application-peer</type>
- <name>example-bgp-peer-app</name>
- <bgp-peer-id xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">10.25.1.9</bgp-peer-id> <!-- Your local BGP-ID that will be used in BGP Best Path Selection algorithm -->
- <target-rib xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:rib-instance</type>
- <name>example-bgp-rib</name>
- </target-rib>
- <application-rib-id xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">example-app-rib</application-rib-id>
- <data-broker xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
- <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">x:dom-async-data-broker</type>
- <name>pingpong-broker</name>
- </data-broker>
- </module>
-
-Tutorials
----------
-
-Viewing BGP Topology
-~~~~~~~~~~~~~~~~~~~~
-
-This section summarizes how data from BGP can be viewed through
-RESTCONF. Currently it is the only way to view the data.
-
-Network Topology View
-^^^^^^^^^^^^^^^^^^^^^
+-----
-The URL for network topology is:
-http://localhost:8181/restconf/operational/network-topology:network-topology/
-
-If BGP is configured properly, it should display output similar to:
-
-.. code:: xml
-
- <network-topology>
- <topology>
- <topology-id>pcep-topology</topology-id>
- <topology-types>
- <topology-pcep/>
- </topology-types>
- </topology>
- <topology>
- <server-provided>true</server-provided>
- <topology-id>example-ipv4-topology</topology-id>
- <topology-types/>
- </topology>
- <topology>
- <server-provided>true</server-provided>
- <topology-id>example-linkstate-topology</topology-id>
- <topology-types/>
- </topology>
- </network-topology>
+There are much more attributes that may be carried along with the destination:
-BGP topology information as learned from BGP peers are is in three
-topologies (if all three are configured):
+**BGP-4 Path Attributes**
-- **example-linkstate-topology** - displays links and nodes advertised
- through linkstate update messages
+* **MULTI_EXIT_DISC** (MED)
+ Optional attribute, to be used to discriminate among multiple exit/entry points on external links, lower number is preferred.
- - http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-linkstate-topology
+ .. code-block:: xml
-- **example-ipv4-topology** - display IPv4 addresses of nodes in the
- topology
+ <multi-exit-disc>
+ <med>0</med>
+ </multi-exit-disc>
- - http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-ipv4-topology
-- **example-ipv6-topology** - display IPv6 addresses of nodes in the
- topology
+* **ATOMIC_AGGREGATE**
+ Indicates whether AS_SET was excluded from AS_PATH due to routes aggregation.
- - http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-ipv6-topology
+ .. code-block:: xml
-Route Information Base (RIB) View
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ <atomic-aggregate/>
-Another view of BGP data is through **BGP RIBs**, located here:
-http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/
+* **AGGREGATOR**
+ Optional attribute, contains AS number and IP address of a BGP speaker which performed routes aggregation.
-There are multiple RIBs configured:
+ .. code-block:: xml
-- AdjRibsIn (per Peer) : Adjacency RIBs In, BGP routes as they come
- from BGP Peer
+ <aggregator>
+ <as-number>65000</as-number>
+ <network-address>192.0.2.2</network-address>
+ </aggregator>
-- EffectiveRib (per Peer) : BGP routes after applying Import policies
+* **Unrecognised**
+ Optional attribute, used to store optional attributes, unrecognized by a local BGP speaker.
-- LocRib (per RIB) : Local RIB, BGP routes from all peers
+ .. code-block:: xml
-- AdjRibsOut (per Peer) : BGP routes that will be advertizes, after
- applying Export policies
+ <unrecognized-attributes>
+ <partial>true</partial>
+ <transitive>true</transitive>
+ <type>101</type>
+ <value>0101010101010101</value>
+ </unrecognized-attributes>
-This is how the empty output looks like, when address families for IPv4
-Unicast, IPv6 Unicast, IPv4 Flowspec, IPv6 Flowspec, IPv4 Labeled
-Unicast and Linkstate were configured:
+**Route Reflector Attributes**
-.. code:: xml
+* **ORIGINATOR_ID**
+ Optional attribute, carries BGP Identifier of the originator of the route.
- <loc-rib xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv6-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- <attributes>
- <uptodate>false</uptodate>
- </attributes>
- <ipv6-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- </ipv6-routes>
- </tables>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- <attributes>
- <uptodate>false</uptodate>
- </attributes>
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- </ipv4-routes>
- </tables>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">x:flowspec-subsequent-address-family</safi>
- <attributes>
- <uptodate>false</uptodate>
- </attributes>
- <flowspec-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
- </flowspec-routes>
- </tables>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv6-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">x:flowspec-subsequent-address-family</safi>
- <attributes>
- <uptodate>false</uptodate>
- </attributes>
- <flowspec-ipv6-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
- </flowspec-ipv6-routes>
- </tables>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">x:labeled-unicast-subsequent-address-family</safi>
- <attributes>
- <uptodate>false</uptodate>
- </attributes>
- <labeled-unicast-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
- </labeled-unicast-routes>
- </tables>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-linkstate">x:linkstate-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-linkstate">x:linkstate-subsequent-address-family</safi>
- <attributes>
- <uptodate>false</uptodate>
- </attributes>
- <linkstate-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-linkstate">
- </linkstate-routes>
- </tables>
- </loc-rib>
+ .. code-block:: xml
-You can see details for each AFI by expanding the RESTCONF link:
+ <originator-id>
+ <originator>41.41.41.41</originator>
+ </originator-id>
-- **IPv4 Unicast** :
- http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes
+* **CLUSTER_LIST**
+ Optional attribute, contains a list of CLUSTER_ID values representing the path that the route has traversed.
-- **IPv6 Unicast** :
- http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/ipv6-routes
+ .. code-block:: xml
-- **IPv4 Labeled Unicast** :
- http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes
+ <cluster-id>
+ <cluster>40.40.40.40</cluster>
+ </cluster-id>
-- **IPv4 Flowspec** :
- http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes
+* **Communities**
+ Optional attribute, may be used for policy routing.
-- **IPv6 Flowspec** :
- http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes
+ .. code-block:: xml
-- **Linkstate** :
- http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-linkstate:linkstate-address-family/bgp-linkstate:linkstate-subsequent-address-family/linkstate-routes
+ <communities>
+ <as-number>65000</as-number>
+ <semantics>30740</semantics>
+ </communities>
-Populate RIB
-~~~~~~~~~~~~
+**Extended Communities**
-If an application peer is configured, you can populate its RIB by making
-POST calls to RESTCONF like the following.
+* **Route Target**
+ Identifies one or more routers that may receive a route.
-IPv4 Unicast
-^^^^^^^^^^^^
+ .. code-block:: xml
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <route-target-ipv4>
+ <global-administrator>192.0.2.2</global-administrator>
+ <local-administrator>123</local-administrator>
+ </route-target-ipv4>
+ </extended-communities>
+ <extended-communities>
+ <transitive>true</transitive>
+ <as-4-route-target-extended-community>
+ <as-4-specific-common>
+ <as-number>65000</as-number>
+ <local-administrator>123</local-administrator>
+ </as-4-specific-common>
+ </as-4-route-target-extended-community>
+ </extended-communities>
-**Add route:**
-**URL:**
-http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/
+* **Route Origin**
+ Identifies one or more routers that injected a route.
-- where example-app-rib is your application RIB id (that you specified
- in the configuration) and tables specifies AFI and SAFI of the data
- that you want to add.
+ .. code-block:: xml
-**Method:** POST
+ <extended-communities>
+ <transitive>true</transitive>
+ <route-origin-ipv4>
+ <global-administrator>192.0.2.2</global-administrator>
+ <local-administrator>123</local-administrator>
+ </route-origin-ipv4>
+ </extended-communities>
+ <extended-communities>
+ <transitive>true</transitive>
+ <as-4-route-origin-extended-community>
+ <as-4-specific-common>
+ <as-number>65000</as-number>
+ <local-administrator>123</local-administrator>
+ </as-4-origin-common>
+ </as-4-route-target-extended-community>
+ </extended-communities>
-**Content-Type:** application/xml
-.. code:: xml
+* **Link Bandwidth**
+ Carries the cost to reach external neighbor.
- <?xml version="1.0" encoding="UTF-8" standalone="no"?>
- <ipv4-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <prefix>1.1.1.1/32</prefix>
+ .. code-block:: xml
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <link-bandwidth-extended-community>
+ <bandwidth>BH9CQAA=</bandwidth>
+ </link-bandwidth-extended-community>
+ </extended-communities>
+
+* **AIGP**
+ Optional attribute, carries accumulated IGP metric.
+
+ .. code-block:: xml
+
+ <aigp>
+ <aigp-tlv>
+ <metric>120</metric>
+ </aigp-tlv>
+ </aigp>
+
+
+.. note:: When the remote peer disconnects, it disappear from operational state of local speaker instance and advertised routes are removed too.
+
+External peering configuration
+''''''''''''''''''''''''''''''
+An example above provided configuration for internal peering only.
+Following configuration sample is intended for external peering:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 5
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.3</neighbor-address>
+ <config>
+ <peer-type>EXTERNAL</peer-type>
+ <peer-as>64999</peer-as>
+ </config>
+ </neighbor>
+
+@line 5: AS number of the remote peer.
+
+Route reflector configuration
+'''''''''''''''''''''''''''''
+The local BGP speaker can be configured with a specific *cluster ID*.
+Following example adds the cluster ID to the existing speaker instance:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/global/config``
+
+**Method:** ``PUT``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 4
+
+ <config>
+ <router-id>192.0.2.2</router-id>
+ <as>65000</as>
+ <route-reflector-cluster-id>192.0.2.1</route-reflector-cluster-id>
+ </config>
+
+@line 4: Route-reflector cluster id to use when local router is configured as a route reflector.
+ The *router-id* is used as a default value.
+
+-----
+
+Following configuration sample is intended for route reflector client peering:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 8
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.4</neighbor-address>
+ <config>
+ <peer-type>INTERNAL</peer-type>
+ </config>
+ <route-reflector>
+ <config>
+ <route-reflector-client>true</route-reflector-client>
+ </config>
+ </route-reflector>
+ </neighbor>
+
+@line 8: Configure the neighbor as a route reflector client. Default value is *false*.
+
+MD5 authentication configuration
+''''''''''''''''''''''''''''''''
+The OpenDaylight BGP implementation is supporting TCP MD5 for authentication.
+Sample configuration below shows how to set authentication password for a peer:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 4
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.5</neighbor-address>
+ <config>
+ <auth-password>topsecret</auth-password>
+ </config>
+ </neighbor>
+
+@line 4: Configures an MD5 authentication password for use with neighboring devices.
+
+Simple Routing Policy configuration
+'''''''''''''''''''''''''''''''''''
+The OpenDaylight BGP implementation is supporting *Simple Routing Policy*.
+Sample configuration below shows how to set *Simple Routing Policy* for a peer:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 4
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.7</neighbor-address>
+ <config>
+ <simple-routing-policy>learn-none</simple-routing-policy>
+ </config>
+ </neighbor>
+
+@line 4: *Simple Routing Policy*:
+
+ * ``learn-none`` - routes advertised by the peer are not propagated to Effective-RIB-In and Loc-RIB
+ * ``announce-none`` - routes from local Loc-RIB are not advertised to the peer
+
+.. note:: Existing neighbor configuration can be reconfigured (change configuration parameters) anytime.
+ As a result, established connection is dropped, peer instance is recreated with a new configuration settings and connection re-established.
+
+.. note:: The BGP configuration is persisted on OpendDaylight shutdown and restored after the re-start.
+
+BGP Application Peer and programmable RIB
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The OpenDaylight BGP implementation also supports routes injection via *Application Peer*.
+Such peer has its own programmable RIB, which can be modified by user.
+This concept allows user to originate new routes and advertise them to all connected peers.
+
+Application Peer configuration
+''''''''''''''''''''''''''''''
+Following configuration sample show a way to configure the *Application Peer*:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 2,4
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>10.25.1.9</neighbor-address>
+ <config>
+ <peer-group>application-peers</peer-group>
+ </config>
+ </neighbor>
+
+@line 2: IP address is uniquely identifying *Application Peer* and its programmable RIB. Address is also used in local BGP speaker decision process.
+
+@line 4: Indicates that peer is associated with *application-peers* group. It serves to distinguish *Application Peer's* from regular neighbors.
+
+-----
+
+The *Application Peer* presence can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/peer/bgp:%2F%2F10.25.1.9``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 3,8
+
+ <peer xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
+ <peer-id>bgp://10.25.1.9</peer-id>
+ <peer-role>internal</peer-role>
+ <adj-rib-in>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet"></ipv4-routes>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ </tables>
+ </adj-rib-in>
+ <effective-rib-in>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet"></ipv4-routes>
+ <attributes></attributes>
+ </tables>
+ </effective-rib-in>
+ </peer>
+
+@line 3: Peer role for *Application Peer* is *internal*.
+
+@line 8: Adj-RIB-In is empty, as no routes were originated yet.
+
+.. note:: There is no Adj-RIB-Out for *Application Peer*.
+
+Programmable RIB
+''''''''''''''''
+Next example shows how to inject a route into the programmable RIB.
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <ipv4-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <path-id>0</path-id>
+ <prefix>10.0.0.11/32</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.11.1.1</global>
+ </ipv4-next-hop>
+ </attributes>
+ </ipv4-route>
+
+-----
+
+Now the injected route appears in *Application Peer's* RIBs and in local speaker's Loc-RIB:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/peer/bgp:%2F%2F10.25.1.9``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 9
+
+ <peer xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
+ <peer-id>bgp://10.25.1.9</peer-id>
+ <peer-role>internal</peer-role>
+ <adj-rib-in>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <ipv4-route>
+ <path-id>0</path-id>
+ <prefix>10.0.0.11/32</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.11.1.1</global>
+ </ipv4-next-hop>
+ </attributes>
+ </ipv4-route>
+ </ipv4-routes>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ </tables>
+ </adj-rib-in>
+ <effective-rib-in>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <ipv4-route>
+ <path-id>0</path-id>
+ <prefix>10.0.0.11/32</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.11.1.1</global>
+ </ipv4-next-hop>
+ </attributes>
+ </ipv4-route>
+ </ipv4-routes>
+ <attributes></attributes>
+ </tables>
+ </effective-rib-in>
+ </peer>
+
+@line 9: Injected route is present in *Application Peer's* Adj-RIB-In and Effective-RIB-In.
+
+-----
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 2
+
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <ipv4-route>
+ <path-id>0</path-id>
+ <prefix>10.0.0.10/32</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.11.1.1</global>
+ </ipv4-next-hop>
+ </attributes>
+ </ipv4-route>
+ <ipv4-route>
+ <path-id>0</path-id>
+ <prefix>10.0.0.10/32</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.10.1.1</global>
+ </ipv4-next-hop>
+ </attributes>
+ </ipv4-route>
+ </ipv4-routes>
+
+@line 2: The injected route is now present in Loc-RIB along with a route (destination *10.0.0.10/32*) advertised by remote peer.
+
+-----
+
+This route is also advertised to the remote peer (*192.0.2.1*), hence route appears in its Adj-RIB-Out:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/peer/bgp:%2F%2F192.0.2.1/adj-rib-out/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <ipv4-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <path-id>0</path-id>
+ <prefix>10.0.0.11/32</prefix>
<attributes>
- <ipv4-next-hop>
- <global>199.20.160.41</global>
- </ipv4-next-hop><as-path/>
- <multi-exit-disc>
- <med>0</med>
- </multi-exit-disc>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <originator-id>
- <originator>41.41.41.41</originator>
- </originator-id>
- <origin>
- <value>igp</value>
- </origin>
- <cluster-id>
- <cluster>40.40.40.40</cluster>
- </cluster-id>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.11.1.1</global>
+ </ipv4-next-hop>
</attributes>
- </ipv4-route>
+ </ipv4-route>
-The request results in **204 No content**. This is expected.
+-----
-**Delete route:**
+The injected route can be modified (i.e. different path attribute):
-**URL:**
-`http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/bgp-inet:ipv4-route/<route-id> <http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/bgp-inet:ipv4-route/<route-id>>`__
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/ipv4-route/10.0.0.11%2F32/0``
-**Method:** DELETE
+**Method:** ``PUT``
-IPv6 Unicast
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <ipv4-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <path-id>0</path-id>
+ <prefix>10.0.0.11/32</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>50</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.11.1.2</global>
+ </ipv4-next-hop>
+ </attributes>
+ </ipv4-route>
+
+-----
+
+The route can be removed from programmable RIB in a following way:
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/ipv4-route/10.0.0.11%2F32/0``
+
+**Method:** ``DELETE``
+
+-----
+
+Also it is possible to remove all routes from a particular table at once:
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/``
+
+**Method:** ``DELETE``
+
+-----
+
+Consequently, route disappears from programmable RIB, *Application Peer's* RIBs, Loc-RIB and peer's Adj-RIB-Out (UPDATE message with prefix withdrawal is send).
+
+.. note:: Routes stored in programmable RIB are persisted on OpendDaylight shutdown and restored after the re-start.
+
+BGP Protocol Configuration Loader
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+BGP Protocol Configuration Loader allows user to define static initial configuration for a BGP protocol instance.
+This service will detect the creation of new configuration files following the pattern "protocols-*.xml" under the path "etc/opendaylight/bgp".
+Once the file is processed, the defined configuration will be available from the configuration Data Store.
+
+.. note:: If the BGP instance is already present, no update or configuration will be applied.
+
+When installing BGP an example will be provided and a default configuration loaded.
+
+**PATH:** ``etc/opendaylight/bgp/protocols-config.xml``
+
+.. code-block:: xml
+
+ <protocols xmlns="http://openconfig.net/yang/network-instance">
+ <protocol>
+ <name>example-bgp-rib</name>
+ <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
+ <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <global>
+ <config>
+ <router-id>192.0.2.2</router-id>
+ <as>64496</as>
+ <!-- if cluster-id is not present, it's value is the same as bgp-id -->
+ <!-- <route-reflector-cluster-id>192.0.2.3</route-reflector-cluster-id> -->
+ <!-- <read-only-limit>120</read-only-limit>-->
+ </config>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
+ <!--Advertise N Paths
+ <receive>true</receive>
+ <send-max>2</send-max>-->
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-LABELLED-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-LABELLED-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV4-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV6-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L2VPN-EVPN</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>LINKSTATE</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV4-FLOW</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV6-FLOW</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV4-L3VPN-FLOW</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV6-L3VPN-FLOW</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </global>
+ <neighbors xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.1</neighbor-address>
+ <config>
+ <peer-type>INTERNAL</peer-type>
+ <peer-as>64496</peer-as>
+ </config>
+ <transport>
+ <config>
+ <remote-port>179</remote-port>
+ <passive-mode>true</passive-mode>
+ </config>
+ </transport>
+ <timers>
+ <config>
+ <hold-time>180</hold-time>
+ <connect-retry>10</connect-retry>
+ </config>
+ </timers>
+ <route-reflector>
+ <config>
+ <route-reflector-client>false</route-reflector-client>
+ </config>
+ </route-reflector>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
+ <!--Advertise N Paths
+ <receive>true</receive>
+ <send-max>0</send-max>-->
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-LABELLED-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-LABELLED-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV4-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV6-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L2VPN-EVPN</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>LINKSTATE</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV4-FLOW</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV6-FLOW</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV4-L3VPN-FLOW</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV6-L3VPN-FLOW</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </neighbor>
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.6</neighbor-address>
+ <config>
+ <peer-group>application-peers</peer-group>
+ </config>
+ </neighbor>
+ </neighbors>
+ </bgp>
+ </protocol>
+ </protocols>
+
+BGP pipeline
^^^^^^^^^^^^
+.. figure:: ./images/bgpcep/bgp-pipeline.png
+ :alt: BGP pipeline.
+
+ BGP pipeline - routes re-advertisement.
+
+.. figure:: ./images/bgpcep/bgp-app-pipeline.png
+ :alt: BGP Application Peer pipeline.
+
+ BGP applcaition peer pipeline - routes injection.
+
+References
+^^^^^^^^^^
+* `A Border Gateway Protocol 4 (BGP-4) <https://tools.ietf.org/html/rfc4271>`_
+* `BGP Route Reflection <https://tools.ietf.org/html/rfc4456>`_
+* `BGP Communities Attribute <https://tools.ietf.org/html/rfc1997>`_
+* `BGP Support for Four-Octet Autonomous System (AS) Number Space <https://tools.ietf.org/html/rfc6793>`_
+* `The Accumulated IGP Metric Attribute for BGP <https://tools.ietf.org/html/rfc7311>`_
+* `4-Octet AS Specific BGP Extended Community <https://tools.ietf.org/html/rfc5668>`_
+* `BGP Link Bandwidth Extended Community <https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-06>`_
+* `Use of BGP for Routing in Large-Scale Data Centers <https://tools.ietf.org/html/rfc7938>`_
+
+IP Unicast Family
+-----------------
+The BGP-4 allows to carry IPv4 specific information only.
+The basic BGP Multiprotocol extension brings *Unicast* Subsequent Address Family (SAFI) - intended to be used for IP unicast forwarding.
+The combination of IPv4 and IPv6 Address Family (AF) and Unicast SAFI is essential for Internet routing.
+The IPv4 Unicast routes are interchangeable with BGP-4 routes, as they can carry the same type of routing information.
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+Configuration
+^^^^^^^^^^^^^
+This section shows a way to enable IPv4 and IPv6 Unicast family in BGP speaker and peer configuration.
+
+BGP Speaker
+'''''''''''
+To enable IPv4 and IPv6 Unicast support in BGP plugin, first configure BGP speaker instance:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <protocol xmlns="http://openconfig.net/yang/network-instance">
+ <name>bgp-example</name>
+ <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
+ <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <global>
+ <config>
+ <router-id>192.0.2.2</router-id>
+ <as>65000</as>
+ </config>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-UNICAST</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </global>
+ </bgp>
+ </protocol>
+
+BGP Peer
+''''''''
+Here is an example for BGP peer configuration with enabled IPv4 and IPv6 Unicast family.
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.1</neighbor-address>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-UNICAST</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </neighbor>
+
+IP Unicast API
+^^^^^^^^^^^^^^
+Following trees illustrate the BGP IP Unicast routes structures.
+
+IPv4 Unicast Route
+''''''''''''''''''
+.. code-block:: console
+
+ :(ipv4-routes-case)
+ +--ro ipv4-routes
+ +--ro ipv4-route* [prefix path-id]
+ +--ro prefix inet:ipv4-prefix
+ +--ro path-id path-id
+ +--ro attributes
+ +--ro origin
+ | +--ro value bgp-t:bgp-origin
+ +--ro as-path
+ | +--ro segments*
+ | +--ro as-sequence* inet:as-number
+ | +--ro as-set* inet:as-number
+ +--ro (c-next-hop)?
+ | +--:(ipv4-next-hop-case)
+ | | +--ro ipv4-next-hop
+ | | +--ro global? inet:ipv4-address
+ | +--:(ipv6-next-hop-case)
+ | | +--ro ipv6-next-hop
+ | | +--ro global? inet:ipv6-address
+ | | +--ro link-local? inet:ipv6-address
+ | +--:(empty-next-hop-case)
+ | +--ro empty-next-hop? empty
+ +--ro multi-exit-disc
+ | +--ro med? uint32
+ +--ro local-pref
+ | +--ro pref? uint32
+ +--ro atomic-aggregate!
+ +--ro aggregator
+ | +--ro as-number? inet:as-number
+ | +--ro network-address? inet:ipv4-address
+ +--ro communities*
+ | +--ro as-number? inet:as-number
+ | +--ro semantics? uint16
+ +--ro extended-communities*
+ | +--ro transitive? boolean
+ | +--ro (extended-community)?
+ | +--:(as-specific-extended-community-case)
+ | | +--ro as-specific-extended-community
+ | | +--ro global-administrator? short-as-number
+ | | +--ro local-administrator? binary
+ | +--:(inet4-specific-extended-community-case)
+ | | +--ro inet4-specific-extended-community
+ | | +--ro global-administrator? inet:ipv4-address
+ | | +--ro local-administrator? binary
+ | +--:(opaque-extended-community-case)
+ | | +--ro opaque-extended-community
+ | | +--ro value? binary
+ | +--:(route-target-extended-community-case)
+ | | +--ro route-target-extended-community
+ | | +--ro global-administrator? short-as-number
+ | | +--ro local-administrator? binary
+ | +--:(route-origin-extended-community-case)
+ | | +--ro route-origin-extended-community
+ | | +--ro global-administrator? short-as-number
+ | | +--ro local-administrator? binary
+ | +--:(route-target-ipv4-case)
+ | | +--ro route-target-ipv4
+ | | +--ro global-administrator? inet:ipv4-address
+ | | +--ro local-administrator? uint16
+ | +--:(route-origin-ipv4-case)
+ | | +--ro route-origin-ipv4
+ | | +--ro global-administrator? inet:ipv4-address
+ | | +--ro local-administrator? uint16
+ | +--:(link-bandwidth-case)
+ | | +--ro link-bandwidth-extended-community
+ | | +--ro bandwidth netc:bandwidth
+ | +--:(as-4-generic-spec-extended-community-case)
+ | | +--ro as-4-generic-spec-extended-community
+ | | +--ro as-4-specific-common
+ | | +--ro as-number inet:as-number
+ | | +--ro local-administrator uint16
+ | +--:(as-4-route-target-extended-community-case)
+ | | +--ro as-4-route-target-extended-community
+ | | +--ro as-4-specific-common
+ | | +--ro as-number inet:as-number
+ | | +--ro local-administrator uint16
+ | +--:(as-4-route-origin-extended-community-case)
+ | | +--ro as-4-route-origin-extended-community
+ | | +--ro as-4-specific-common
+ | | +--ro as-number inet:as-number
+ | | +--ro local-administrator uint16
+ | +--:(encapsulation-case)
+ | +--ro encapsulation-extended-community
+ | +--ro tunnel-type encapsulation-tunnel-type
+ +--ro originator-id
+ | +--ro originator? inet:ipv4-address
+ +--ro cluster-id
+ | +--ro cluster* bgp-t:cluster-identifier
+ +--ro aigp
+ | +--ro aigp-tlv
+ | +--ro metric? netc:accumulated-igp-metric
+ +--ro unrecognized-attributes* [type]
+ +--ro partial boolean
+ +--ro transitive boolean
+ +--ro type uint8
+ +--ro value binary
+
+IPv6 Unicast Route
+''''''''''''''''''
+.. code-block:: console
+
+ :(ipv6-routes-case)
+ +--ro ipv6-routes
+ +--ro ipv6-route* [prefix path-id]
+ +--ro prefix inet:ipv6-prefix
+ +--ro path-id path-id
+ +--ro attributes
+ ...
+
+Usage
+^^^^^
+IPv4 Unicast
+''''''''''''
+The IPv4 Unicast table in an instance of the speaker's Loc-RIB can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <ipv4-route>
+ <path-id>0</path-id>
+ <prefix>193.0.2.1/32</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.0.0.1</global>
+ </ipv4-next-hop>
+ </attributes>
+ </ipv4-route>
+ </ipv4-routes>
-**Add route:**
+IPv6 Unicast
+''''''''''''
+The IPv6 Unicast table in an instance of the speaker's Loc-RIB can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv6-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <ipv6-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <ipv6-route>
+ <path-id>0</path-id>
+ <prefix>2a02:b80:0:1::/64</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>200</pref>
+ </local-pref>
+ <ipv6-next-hop>
+ <global>2a02:b80:0:2::1</global>
+ </ipv6-next-hop>
+ </attributes>
+ </ipv6-route>
+ </ipv6-routes>
+
+.. note:: IPv4/6 routes mapping to topology nodes is supported by BGP Topology Provider.
+
+Programming
+^^^^^^^^^^^
+IPv4 Unicast
+''''''''''''
+This examples show how to originate and remove IPv4 route via programmable RIB.
+Make sure the *Application Peer* is configured first.
-**URL:**
-http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes/
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes``
-**Method:** POST
+**Method:** ``POST``
-**Content-Type:** application/xml
+**Content-Type:** ``application/xml``
-.. code:: xml
+**Request Body:**
- <ipv6-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <prefix>2001:db8:30::3/128</prefix>
+.. code-block:: xml
+
+ <ipv4-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <path-id>0</path-id>
+ <prefix>10.0.0.11/32</prefix>
<attributes>
- <ipv6-next-hop>
- <global>2001:db8:1::6</global>
- </ipv6-next-hop>
- <as-path/>
- <origin>
- <value>egp</value>
- </origin>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.11.1.1</global>
+ </ipv4-next-hop>
</attributes>
- </ipv6-route>
+ </ipv4-route>
-The request results in **204 No content**. This is expected.
+-----
-**Delete route:**
+To remove the route added above, following request can be used:
-**URL:**
-`http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes/bgp-inet:ipv6-route/<route-id> <http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes/bgp-inet:ipv6-route/<route-id>>`__
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/ipv4-route/10.0.0.11%2F32/0``
-**Method:** DELETE
+**Method:** ``DELETE``
-IPv4 Labeled Unicast
-^^^^^^^^^^^^^^^^^^^^
+IPv6 Unicast
+''''''''''''
+This examples show how to originate and remove IPv6 route via programmable RIB:
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes``
-**Add route:**
+**Method:** ``POST``
-**URL:**
-http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes
+**Content-Type:** ``application/xml``
-**Method:** POST
+**Request Body:**
-**Content-Type:** application/xml
+.. code-block:: xml
-.. code:: xml
+ <ipv6-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <prefix>2001:db8:30::3/128</prefix>
+ <path-id>0</path-id>
+ <attributes>
+ <ipv6-next-hop>
+ <global>2001:db8:1::6</global>
+ </ipv6-next-hop>
+ <as-path/>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ </attributes>
+ </ipv6-route>
+
+-----
+
+To remove the route added above, following request can be used:
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes/ipv6-route/2001:db8:30::3%2F128/0``
+
+**Method:** ``DELETE``
+
+References
+^^^^^^^^^^
+* `Multiprotocol Extensions for BGP-4 <https://tools.ietf.org/html/rfc4760>`_
- <labeled-unicast-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
+IP Labeled Unicast Family
+-------------------------
+The BGP Labeled Unicast (BGP-LU) Multiprotocol extension is used to distribute a MPLS label that is mapped to a particular route.
+It can be used to advertise a MPLS transport path between IGP regions and Autonomous Systems.
+Also, BGP-LU can help to solve the Inter-domain traffic-engineering problem and can be deployed in large-scale data centers along with MPLS and Spring.
+In addition, IPv6 Labeled Unicast can be used to interconnect IPv6 islands over IPv4/MPLS networks using 6PE.
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+Configuration
+^^^^^^^^^^^^^
+This section shows a way to enable IPv4 and IPv6 Labeled Unicast family in BGP speaker and peer configuration.
+
+BGP Speaker
+'''''''''''
+To enable IPv4 and IPv6 Labeled Unicast support in BGP plugin, first configure BGP speaker instance:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <protocol xmlns="http://openconfig.net/yang/network-instance">
+ <name>bgp-example</name>
+ <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
+ <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <global>
+ <config>
+ <router-id>192.0.2.2</router-id>
+ <as>65000</as>
+ </config>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-LABELLED-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-LABELLED-UNICAST</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </global>
+ </bgp>
+ </protocol>
+
+BGP Peer
+''''''''
+Here is an example for BGP peer configuration with enabled IPv4 and IPv6 Labeled Unicast family.
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.1</neighbor-address>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-LABELLED-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-LABELLED-UNICAST</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </neighbor>
+
+IP Labeled Unicast API
+^^^^^^^^^^^^^^^^^^^^^^
+Following trees illustrate the BGP IP Labeled Unicast routes structures.
+
+IPv4 Labeled Unicast Route
+''''''''''''''''''''''''''
+.. code-block:: console
+
+ :(labeled-unicast-routes-case)
+ +--ro labeled-unicast-routes
+ +--ro labeled-unicast-route* [route-key path-id]
+ +--ro route-key string
+ +--ro label-stack*
+ | +--ro label-value? netc:mpls-label
+ +--ro prefix? inet:ip-prefix
+ +--ro path-id path-id
+ +--ro attributes
+ ...
+
+
+IPv6 Labeled Unicast Route
+''''''''''''''''''''''''''
+.. code-block:: console
+
+ :(labeled-unicast-ipv6-routes-case)
+ +--ro labeled-unicast-ipv6-routes
+ +--ro labeled-unicast-route* [route-key path-id]
+ +--ro route-key string
+ +--ro label-stack*
+ | +--ro label-value? netc:mpls-label
+ +--ro prefix? inet:ip-prefix
+ +--ro path-id path-id
+ +--ro attributes
+ ...
+
+Usage
+^^^^^
+The IPv4 Labeled Unicast table in an instance of the speaker's Loc-RIB can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <labeled-unicast-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
+ <labeled-unicast-route>
+ <path-id>0</path-id>
+ <route-key>MAA+gRQAAA==</route-key>
+ <attributes>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>200.10.0.101</global>
+ </ipv4-next-hop>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ </attributes>
+ <label-stack>
+ <label-value>1000</label-value>
+ </label-stack>
+ <prefix>20.0.0.0/24</prefix>
+ </labeled-unicast-route>
+ </labeled-unicast-routes>
+
+Programming
+^^^^^^^^^^^
+IPv4 Labeled
+''''''''''''
+This examples show how to originate and remove IPv4 labeled route via programmable RIB.
+Make sure the *Application Peer* is configured first.
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <labeled-unicast-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
<route-key>label1</route-key>
<prefix>1.1.1.1/32</prefix>
+ <path-id>0</path-id>
<label-stack>
- <label-value>123</label-value>
+ <label-value>800322</label-value>
</label-stack>
+ <attributes>
+ <ipv4-next-hop>
+ <global>199.20.160.41</global>
+ </ipv4-next-hop>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path/>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ </attributes>
+ </labeled-unicast-route>
+
+-----
+
+In addition, BGP-LU Spring extension allows to attach BGP Prefix SID attribute to the route, in order to signal the BGP-Prefix-SID, where the SR is applied to MPLS dataplane.
+
+.. code-block:: xml
+
+ <bgp-prefix-sid>
+ <bgp-prefix-sid-tlvs>
+ <label-index-tlv xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">322</label-index-tlv>
+ </bgp-prefix-sid-tlvs>
+ <bgp-prefix-sid-tlvs>
+ <srgb-value xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
+ <base>800000</base>
+ <range>4095</range>
+ </srgb-value>
+ </bgp-prefix-sid-tlvs>
+ </bgp-prefix-sid>
+
+-----
+
+To remove the route added above, following request can be used:
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes/bgp-labeled-unicast:labeled-unicast-route/label1/0``
+
+**Method:** ``DELETE``
+
+IPv6 Labeled
+''''''''''''
+This examples show how to originate and remove IPv6 labeled route via programmable RIB.
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-ipv6-routes``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <labeled-unicast-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
+ <route-key>label1</route-key>
+ <prefix>2001:db8:30::3/128</prefix>
+ <path-id>0</path-id>
<label-stack>
- <label-value>456</label-value>
+ <label-value>123</label-value>
</label-stack>
+ <attributes>
+ <ipv6-next-hop>
+ <global>2003:4:5:6::7</global>
+ </ipv6-next-hop>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path/>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ </attributes>
+ </labeled-unicast-route>
+
+-----
+
+To remove the route added above, following request can be used:
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-ipv6-routes/bgp-labeled-unicast:labeled-unicast-route/label1/0``
+
+**Method:** ``DELETE``
+
+References
+^^^^^^^^^^
+* `Carrying Label Information in BGP-4 <https://tools.ietf.org/html/rfc3107>`_
+* `Segment Routing Prefix SID extensions for BGP <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-03>`_
+* `Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) <https://tools.ietf.org/html/rfc4798>`_
+* `BGP-Prefix Segment in large-scale data centers <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-01>`_
+* `Egress Peer Engineering using BGP-LU <https://tools.ietf.org/html/draft-gredler-idr-bgplu-epe-06>`_
+
+IP L3VPN Family
+---------------
+The BGP/MPLS IP Virtual Private Networks (BGP L3VPN) Multiprotocol extension can be used to exchange particular VPN (customer) routes among the provider's routers attached to that VPN.
+Also, routes are distributed to specific VPN remote sites.
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+Configuration
+^^^^^^^^^^^^^
+This section shows a way to enable IPv4 and IPv6 L3VPN family in BGP speaker and peer configuration.
+
+BGP Speaker
+'''''''''''
+To enable IPv4 and IPv6 L3VPN support in BGP plugin, first configure BGP speaker instance:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <protocol xmlns="http://openconfig.net/yang/network-instance">
+ <name>bgp-example</name>
+ <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
+ <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <global>
+ <config>
+ <router-id>192.0.2.2</router-id>
+ <as>65000</as>
+ </config>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV4-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV6-UNICAST</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </global>
+ </bgp>
+ </protocol>
+
+BGP Peer
+''''''''
+Here is an example for BGP peer configuration with enabled IPv4 and IPv6 L3VPN family.
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.1</neighbor-address>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV4-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV6-UNICAST</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </neighbor>
+
+IP L3VPN API
+^^^^^^^^^^^^
+Following trees illustrate the BGP IP L3VPN routes structures.
+
+IPv4 L3VPN Route
+''''''''''''''''
+.. code-block:: console
+
+ :(vpn-ipv4-routes-case)
+ +--ro vpn-ipv4-routes
+ +--ro vpn-route* [route-key]
+ +--ro route-key string
+ +--ro label-stack*
+ | +--ro label-value? netc:mpls-label
+ +--ro prefix? inet:ip-prefix
+ +--ro path-id? path-id
+ +--ro route-distinguisher? bgp-t:route-distinguisher
+ +--ro attributes
+ ...
+
+IPv6 L3VPN Route
+''''''''''''''''
+.. code-block:: console
+
+ :(vpn-ipv6-routes-case)
+ +--ro vpn-ipv6-routes
+ +--ro vpn-route* [route-key]
+ +--ro route-key string
+ +--ro label-stack*
+ | +--ro label-value? netc:mpls-label
+ +--ro prefix? inet:ip-prefix
+ +--ro path-id? path-id
+ +--ro route-distinguisher? bgp-t:route-distinguisher
+ +--ro attributes
+ ...
+
+Usage
+^^^^^
+IPv4 L3VPN
+''''''''''
+The IPv4 L3VPN table in an instance of the speaker's Loc-RIB can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:mpls-labeled-vpn-subsequent-address-family/bgp-vpn-ipv4:vpn-ipv4-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <vpn-ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-vpn-ipv4">
+ <vpn-route>
+ <route-key>cAXdYQABrBAALABlCgIi</route-key>
+ <label-stack>
+ <label-value>24022</label-value>
+ </label-stack>
+ <attributes>
+ <extended-communities>
+ <transitive>true</transitive>
+ <route-target-extended-community>
+ <global-administrator>65000</global-administrator>
+ <local-administrator>AAAAZQ==</local-administrator>
+ </route-target-extended-community>
+ </extended-communities>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path></as-path>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>127.16.0.44</global>
+ </ipv4-next-hop>
+ </attributes>
+ <route-distinguisher>172.16.0.44:101</route-distinguisher>
+ <prefix>10.2.34.0/24</prefix>
+ </vpn-route>
+ </vpn-ipv4-routes>
+
+IPv6 L3VPN
+''''''''''
+The IPv6 L3VPN table in an instance of the speaker's Loc-RIB can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv6-address-family/bgp-types:mpls-labeled-vpn-subsequent-address-family/bgp-vpn-ipv6:vpn-ipv6-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <vpn-ipv6-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-vpn-ipv6">
+ <vpn-route>
+ <route-key>mAXdcQABrBAALABlKgILgAAAAAE=</route-key>
+ <label-stack>
+ <label-value>24023</label-value>
+ </label-stack>
+ <attributes>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <extended-communities>
+ <route-target-extended-community>
+ <global-administrator>65000</global-administrator>
+ <local-administrator>AAAAZQ==</local-administrator>
+ </route-target-extended-community>
+ <transitive>true</transitive>
+ </extended-communities>
+ <ipv6-next-hop>
+ <global>2a02:b80:0:2::1</global>
+ </ipv6-next-hop>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path></as-path>
+ </attributes>
+ <route-distinguisher>172.16.0.44:101</route-distinguisher>
+ <prefix>2a02:b80:0:1::/64</prefix>
+ </vpn-route>
+ </vpn-ipv6-routes>
+
+Programming
+^^^^^^^^^^^
+This examples show how to originate and remove IPv4 L3VPN route via programmable RIB.
+Make sure the *Application Peer* is configured first.
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:mpls-labeled-vpn-subsequent-address-family/bgp-vpn-ipv4:vpn-ipv4-routes``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <vpn-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-vpn-ipv4">
+ <route-key>vpn1</route-key>
<label-stack>
- <label-value>342</label-value>
+ <label-value>123</label-value>
</label-stack>
+ <route-distinguisher>429496729:1</route-distinguisher>
+ <prefix>2.2.2.2/32</prefix>
<attributes>
- <ipv4-next-hop>
- <global>199.20.160.41</global>
- </ipv4-next-hop>
- <origin>
- <value>igp</value>
- </origin>
- <as-path/>
- <local-pref>
- <pref>100</pref>
- </local-pref>
+ <ipv4-next-hop>
+ <global>199.20.166.41</global>
+ </ipv4-next-hop>
+ <as-path/>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <extended-communities>
+ <route-target-extended-community>
+ <global-administrator>65000</global-administrator>
+ <local-administrator>AAAAZQ==</local-administrator>
+ </route-target-extended-community>
+ <transitive>true</transitive>
+ </extended-communities>
</attributes>
- </labeled-unicast-route>
+ </vpn-route>
+
+-----
+
+To remove the route added above, following request can be used:
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:mpls-labeled-vpn-subsequent-address-family/bgp-vpn-ipv4:vpn-ipv4-routes/vpn-route/vpn1``
+
+**Method:** ``DELETE``
+
+References
+^^^^^^^^^^
+* `BGP/MPLS IP Virtual Private Networks (VPNs) <https://tools.ietf.org/html/rfc4364>`_
+* `BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN <https://tools.ietf.org/html/rfc4659>`_
+* `BGP/MPLS VPN Virtual PE <https://tools.ietf.org/html/draft-ietf-bess-virtual-pe-00>`_
+
+Link-State Family
+-----------------
+The BGP Link-State (BGP-LS) Multiprotocol extension allows to distribute Link-State and Traffic Engineering (TE) information.
+This information is typically distributed by IGP routing protocols with in the network, limiting LSDB or TED visibility to the IGP area.
+The BGP-LS-enabled routers are capable to collect such information from networks (multiple IGP areas, inter-AS) and share with external components (i.e. OpenDaylight BGP).
+The information is applicable in ALTO servers and PCEs, as both need to gather information about topologies.
+In addition, link-state information is extended to carry segment information (Spring).
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+Configuration
+^^^^^^^^^^^^^
+This section shows a way to enable IPv4 and IPv6 Labeled Unicast family in BGP speaker and peer configuration.
+
+BGP Speaker
+'''''''''''
+To enable BGP-LS support in BGP plugin, first configure BGP speaker instance:
-The request results in **204 No content**. This is expected.
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
-**Delete route:**
+**Method:** ``POST``
-**URL:**
-`http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes/bgp-labeled-unicast:labeled-unicast-route/<route-id> <http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes/bgp-labeled-unicast:labeled-unicast-route/<route-id>>`__
+**Content-Type:** ``application/xml``
-**Method:** DELETE
+**Request Body:**
-IPv4 Flowspec
+.. code-block:: xml
+
+ <protocol xmlns="http://openconfig.net/yang/network-instance">
+ <name>bgp-example</name>
+ <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
+ <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <global>
+ <config>
+ <router-id>192.0.2.2</router-id>
+ <as>65000</as>
+ </config>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name>LINKSTATE</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </global>
+ </bgp>
+ </protocol>
+
+BGP Peer
+''''''''
+Here is an example for BGP peer configuration with enabled BGP-LS family.
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.1</neighbor-address>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name>LINKSTATE</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </neighbor>
+
+Link-State Route API
+^^^^^^^^^^^^^^^^^^^^
+Following tree illustrate the BGP Link-State route structure.
+
+.. code-block:: console
+
+ :(linkstate-routes-case)
+ +--ro linkstate-routes
+ +--ro linkstate-route* [route-key]
+ +--ro route-key binary
+ +--ro protocol-id protocol-id
+ +--ro identifier identifier
+ +--ro (object-type)?
+ | +--:(node-case)
+ | | +--ro node-descriptors
+ | | +--ro as-number? inet:as-number
+ | | +--ro area-id? area-identifier
+ | | +--ro domain-id? domain-identifier
+ | | +--ro (c-router-identifier)?
+ | | +--:(isis-node-case)
+ | | | +--ro isis-node
+ | | | +--ro iso-system-id netc:iso-system-identifier
+ | | +--:(isis-pseudonode-case)
+ | | | +--ro isis-pseudonode
+ | | | +--ro is-is-router-identifier
+ | | | | +--ro iso-system-id netc:iso-system-identifier
+ | | | +--ro psn uint8
+ | | +--:(ospf-node-case)
+ | | | +--ro ospf-node
+ | | | +--ro ospf-router-id uint32
+ | | +--:(ospf-pseudonode-case)
+ | | +--ro ospf-pseudonode
+ | | +--ro ospf-router-id uint32
+ | | +--ro lan-interface ospf-interface-identifier
+ | +--:(link-case)
+ | | +--ro local-node-descriptors
+ | | | +--ro as-number? inet:as-number
+ | | | +--ro area-id? area-identifier
+ | | | +--ro domain-id? domain-identifier
+ | | | +--ro (c-router-identifier)?
+ | | | | +--:(isis-node-case)
+ | | | | | +--ro isis-node
+ | | | | | +--ro iso-system-id netc:iso-system-identifier
+ | | | | +--:(isis-pseudonode-case)
+ | | | | | +--ro isis-pseudonode
+ | | | | | +--ro is-is-router-identifier
+ | | | | | | +--ro iso-system-id netc:iso-system-identifier
+ | | | | | +--ro psn uint8
+ | | | | +--:(ospf-node-case)
+ | | | | | +--ro ospf-node
+ | | | | | +--ro ospf-router-id uint32
+ | | | | +--:(ospf-pseudonode-case)
+ | | | | +--ro ospf-pseudonode
+ | | | | +--ro ospf-router-id uint32
+ | | | | +--ro lan-interface ospf-interface-identifier
+ | | | +--ro bgp-router-id? inet:ipv4-address
+ | | | +--ro member-asn? inet:as-number
+ | | +--ro remote-node-descriptors
+ | | | +--ro as-number? inet:as-number
+ | | | +--ro area-id? area-identifier
+ | | | +--ro domain-id? domain-identifier
+ | | | +--ro (c-router-identifier)?
+ | | | | +--:(isis-node-case)
+ | | | | | +--ro isis-node
+ | | | | | +--ro iso-system-id netc:iso-system-identifier
+ | | | | +--:(isis-pseudonode-case)
+ | | | | | +--ro isis-pseudonode
+ | | | | | +--ro is-is-router-identifier
+ | | | | | | +--ro iso-system-id netc:iso-system-identifier
+ | | | | | +--ro psn uint8
+ | | | | +--:(ospf-node-case)
+ | | | | | +--ro ospf-node
+ | | | | | +--ro ospf-router-id uint32
+ | | | | +--:(ospf-pseudonode-case)
+ | | | | +--ro ospf-pseudonode
+ | | | | +--ro ospf-router-id uint32
+ | | | | +--ro lan-interface ospf-interface-identifier
+ | | | +--ro bgp-router-id? inet:ipv4-address
+ | | | +--ro member-asn? inet:as-number
+ | | +--ro link-descriptors
+ | | +--ro link-local-identifier? uint32
+ | | +--ro link-remote-identifier? uint32
+ | | +--ro ipv4-interface-address? ipv4-interface-identifier
+ | | +--ro ipv6-interface-address? ipv6-interface-identifier
+ | | +--ro ipv4-neighbor-address? ipv4-interface-identifier
+ | | +--ro ipv6-neighbor-address? ipv6-interface-identifier
+ | | +--ro multi-topology-id? topology-identifier
+ | +--:(prefix-case)
+ | | +--ro advertising-node-descriptors
+ | | | +--ro as-number? inet:as-number
+ | | | +--ro area-id? area-identifier
+ | | | +--ro domain-id? domain-identifier
+ | | | +--ro (c-router-identifier)?
+ | | | +--:(isis-node-case)
+ | | | | +--ro isis-node
+ | | | | +--ro iso-system-id netc:iso-system-identifier
+ | | | +--:(isis-pseudonode-case)
+ | | | | +--ro isis-pseudonode
+ | | | | +--ro is-is-router-identifier
+ | | | | | +--ro iso-system-id netc:iso-system-identifier
+ | | | | +--ro psn uint8
+ | | | +--:(ospf-node-case)
+ | | | | +--ro ospf-node
+ | | | | +--ro ospf-router-id uint32
+ | | | +--:(ospf-pseudonode-case)
+ | | | +--ro ospf-pseudonode
+ | | | +--ro ospf-router-id uint32
+ | | | +--ro lan-interface ospf-interface-identifier
+ | | +--ro prefix-descriptors
+ | | +--ro multi-topology-id? topology-identifier
+ | | +--ro ospf-route-type? ospf-route-type
+ | | +--ro ip-reachability-information? inet:ip-prefix
+ | +--:(te-lsp-case)
+ | +--ro (address-family)?
+ | | +--:(ipv4-case)
+ | | | +--ro ipv4-tunnel-sender-address inet:ipv4-address
+ | | | +--ro ipv4-tunnel-endpoint-address inet:ipv4-address
+ | | +--:(ipv6-case)
+ | | +--ro ipv6-tunnel-sender-address inet:ipv6-address
+ | | +--ro ipv6-tunnel-endpoint-address inet:ipv6-address
+ | +--ro tunnel-id? rsvp:tunnel-id
+ | +--ro lsp-id? rsvp:lsp-id
+ +--ro attributes
+ +--ro (link-state-attribute)?
+ +--:(node-attributes-case)
+ | +--ro node-attributes
+ | +--ro topology-identifier* topology-identifier
+ | +--ro node-flags? node-flag-bits
+ | +--ro isis-area-id* isis-area-identifier
+ | +--ro dynamic-hostname? string
+ | +--ro ipv4-router-id? ipv4-router-identifier
+ | +--ro ipv6-router-id? ipv6-router-identifier
+ | +--ro sr-capabilities
+ | | +--ro mpls-ipv4? boolean
+ | | +--ro mpls-ipv6? boolean
+ | | +--ro sr-ipv6? boolean
+ | | +--ro range-size? uint32
+ | | +--ro (sid-label-index)?
+ | | +--:(local-label-case)
+ | | | +--ro local-label? netc:mpls-label
+ | | +--:(ipv6-address-case)
+ | | | +--ro ipv6-address? inet:ipv6-address
+ | | +--:(sid-case)
+ | | +--ro sid? uint32
+ | +--ro sr-algorithm
+ | +--ro algorithms* algorithm
+ +--:(link-attributes-case)
+ | +--ro link-attributes
+ | +--ro local-ipv4-router-id? ipv4-router-identifier
+ | +--ro local-ipv6-router-id? ipv6-router-identifier
+ | +--ro remote-ipv4-router-id? ipv4-router-identifier
+ | +--ro remote-ipv6-router-id? ipv6-router-identifier
+ | +--ro mpls-protocol? mpls-protocol-mask
+ | +--ro te-metric? netc:te-metric
+ | +--ro metric? netc:metric
+ | +--ro shared-risk-link-groups* rsvp:srlg-id
+ | +--ro link-name? string
+ | +--ro max-link-bandwidth? netc:bandwidth
+ | +--ro max-reservable-bandwidth? netc:bandwidth
+ | +--ro unreserved-bandwidth* [priority]
+ | | +--ro priority uint8
+ | | +--ro bandwidth? netc:bandwidth
+ | +--ro link-protection? link-protection-type
+ | +--ro admin-group? administrative-group
+ | +--ro sr-adj-ids*
+ | | +--ro (flags)?
+ | | | +--:(ospf-adj-flags-case)
+ | | | | +--ro backup? boolean
+ | | | | +--ro set? boolean
+ | | | +--:(isis-adj-flags-case)
+ | | | +--ro backup? boolean
+ | | | +--ro set? boolean
+ | | | +--ro address-family? boolean
+ | | +--ro weight? weight
+ | | +--ro (sid-label-index)?
+ | | +--:(local-label-case)
+ | | | +--ro local-label? netc:mpls-label
+ | | +--:(ipv6-address-case)
+ | | | +--ro ipv6-address? inet:ipv6-address
+ | | +--:(sid-case)
+ | | +--ro sid? uint32
+ | +--ro sr-lan-adj-ids*
+ | | +--ro (flags)?
+ | | | +--:(ospf-adj-flags-case)
+ | | | | +--ro backup? boolean
+ | | | | +--ro set? boolean
+ | | | +--:(isis-adj-flags-case)
+ | | | +--ro backup? boolean
+ | | | +--ro set? boolean
+ | | | +--ro address-family? boolean
+ | | +--ro weight? weight
+ | | +--ro iso-system-id? netc:iso-system-identifier
+ | | +--ro neighbor-id? inet:ipv4-address
+ | | +--ro (sid-label-index)?
+ | | +--:(local-label-case)
+ | | | +--ro local-label? netc:mpls-label
+ | | +--:(ipv6-address-case)
+ | | | +--ro ipv6-address? inet:ipv6-address
+ | | +--:(sid-case)
+ | | +--ro sid? uint32
+ | +--ro peer-node-sid
+ | | +--ro weight? weight
+ | | +--ro (sid-label-index)?
+ | | +--:(local-label-case)
+ | | | +--ro local-label? netc:mpls-label
+ | | +--:(ipv6-address-case)
+ | | | +--ro ipv6-address? inet:ipv6-address
+ | | +--:(sid-case)
+ | | +--ro sid? uint32
+ | +--ro peer-adj-sid
+ | | +--ro weight? weight
+ | | +--ro (sid-label-index)?
+ | | +--:(local-label-case)
+ | | | +--ro local-label? netc:mpls-label
+ | | +--:(ipv6-address-case)
+ | | | +--ro ipv6-address? inet:ipv6-address
+ | | +--:(sid-case)
+ | | +--ro sid? uint32
+ | +--ro peer-set-sids*
+ | +--ro weight? weight
+ | +--ro (sid-label-index)?
+ | +--:(local-label-case)
+ | | +--ro local-label? netc:mpls-label
+ | +--:(ipv6-address-case)
+ | | +--ro ipv6-address? inet:ipv6-address
+ | +--:(sid-case)
+ | +--ro sid? uint32
+ +--:(prefix-attributes-case)
+ | +--ro prefix-attributes
+ | +--ro igp-bits
+ | | x--ro up-down? bits
+ | | +--ro is-is-up-down? boolean
+ | | +--ro ospf-no-unicast? boolean
+ | | +--ro ospf-local-address? boolean
+ | | +--ro ospf-propagate-nssa? boolean
+ | +--ro route-tags* route-tag
+ | +--ro extended-tags* extended-route-tag
+ | +--ro prefix-metric? netc:igp-metric
+ | +--ro ospf-forwarding-address? inet:ip-address
+ | +--ro sr-prefix
+ | | +--ro (flags)?
+ | | | +--:(isis-prefix-flags-case)
+ | | | | +--ro no-php? boolean
+ | | | | +--ro explicit-null? boolean
+ | | | | +--ro readvertisement? boolean
+ | | | | +--ro node-sid? boolean
+ | | | +--:(ospf-prefix-flags-case)
+ | | | +--ro no-php? boolean
+ | | | +--ro explicit-null? boolean
+ | | | +--ro mapping-server? boolean
+ | | +--ro algorithm? algorithm
+ | | +--ro (sid-label-index)?
+ | | +--:(local-label-case)
+ | | | +--ro local-label? netc:mpls-label
+ | | +--:(ipv6-address-case)
+ | | | +--ro ipv6-address? inet:ipv6-address
+ | | +--:(sid-case)
+ | | +--ro sid? uint32
+ | +--ro ipv6-sr-prefix
+ | | +--ro algorithm? algorithm
+ | +--ro sr-range
+ | | +--ro inter-area? boolean
+ | | +--ro range-size? uint16
+ | | +--ro sub-tlvs*
+ | | +--ro (range-sub-tlv)?
+ | | +--:(binding-sid-tlv-case)
+ | | | +--ro weight? weight
+ | | | +--ro (flags)?
+ | | | | +--:(isis-binding-flags-case)
+ | | | | | +--ro address-family? boolean
+ | | | | | +--ro mirror-context? boolean
+ | | | | | +--ro spread-tlv? boolean
+ | | | | | +--ro leaked-from-level-2? boolean
+ | | | | | +--ro attached-flag? boolean
+ | | | | +--:(ospf-binding-flags-case)
+ | | | | +--ro mirroring? boolean
+ | | | +--ro binding-sub-tlvs*
+ | | | +--ro (binding-sub-tlv)?
+ | | | +--:(prefix-sid-case)
+ | | | | +--ro (flags)?
+ | | | | | +--:(isis-prefix-flags-case)
+ | | | | | | +--ro no-php? boolean
+ | | | | | | +--ro explicit-null? boolean
+ | | | | | | +--ro readvertisement? boolean
+ | | | | | | +--ro node-sid? boolean
+ | | | | | +--:(ospf-prefix-flags-case)
+ | | | | | +--ro no-php? boolean
+ | | | | | +--ro explicit-null? boolean
+ | | | | | +--ro mapping-server? boolean
+ | | | | +--ro algorithm? algorithm
+ | | | | +--ro (sid-label-index)?
+ | | | | +--:(local-label-case)
+ | | | | | +--ro local-label? netc:mpls-label
+ | | | | +--:(ipv6-address-case)
+ | | | | | +--ro ipv6-address? inet:ipv6-address
+ | | | | +--:(sid-case)
+ | | | | +--ro sid? uint32
+ | | | +--:(ipv6-prefix-sid-case)
+ | | | | +--ro algorithm? algorithm
+ | | | +--:(sid-label-case)
+ | | | | +--ro (sid-label-index)?
+ | | | | +--:(local-label-case)
+ | | | | | +--ro local-label? netc:mpls-label
+ | | | | +--:(ipv6-address-case)
+ | | | | | +--ro ipv6-address? inet:ipv6-address
+ | | | | +--:(sid-case)
+ | | | | +--ro sid? uint32
+ | | | +--:(ero-metric-case)
+ | | | | +--ro ero-metric? netc:te-metric
+ | | | +--:(ipv4-ero-case)
+ | | | | +--ro loose? boolean
+ | | | | +--ro address inet:ipv4-address
+ | | | +--:(ipv6-ero-case)
+ | | | | +--ro loose? boolean
+ | | | | +--ro address inet:ipv6-address
+ | | | +--:(unnumbered-interface-id-ero-case)
+ | | | | +--ro loose? boolean
+ | | | | +--ro router-id? uint32
+ | | | | +--ro interface-id? uint32
+ | | | +--:(ipv4-ero-backup-case)
+ | | | | +--ro loose? boolean
+ | | | | +--ro address inet:ipv4-address
+ | | | +--:(ipv6-ero-backup-case)
+ | | | | +--ro loose? boolean
+ | | | | +--ro address inet:ipv6-address
+ | | | +--:(unnumbered-interface-id-backup-ero-case)
+ | | | +--ro loose? boolean
+ | | | +--ro router-id? uint32
+ | | | +--ro interface-id? uint32
+ | | +--:(prefix-sid-tlv-case)
+ | | | +--ro (flags)?
+ | | | | +--:(isis-prefix-flags-case)
+ | | | | | +--ro no-php? boolean
+ | | | | | +--ro explicit-null? boolean
+ | | | | | +--ro readvertisement? boolean
+ | | | | | +--ro node-sid? boolean
+ | | | | +--:(ospf-prefix-flags-case)
+ | | | | +--ro no-php? boolean
+ | | | | +--ro explicit-null? boolean
+ | | | | +--ro mapping-server? boolean
+ | | | +--ro algorithm? algorithm
+ | | | +--ro (sid-label-index)?
+ | | | +--:(local-label-case)
+ | | | | +--ro local-label? netc:mpls-label
+ | | | +--:(ipv6-address-case)
+ | | | | +--ro ipv6-address? inet:ipv6-address
+ | | | +--:(sid-case)
+ | | | +--ro sid? uint32
+ | | +--:(ipv6-prefix-sid-tlv-case)
+ | | | +--ro algorithm? algorithm
+ | | +--:(sid-label-tlv-case)
+ | | +--ro (sid-label-index)?
+ | | +--:(local-label-case)
+ | | | +--ro local-label? netc:mpls-label
+ | | +--:(ipv6-address-case)
+ | | | +--ro ipv6-address? inet:ipv6-address
+ | | +--:(sid-case)
+ | | +--ro sid? uint32
+ | +--ro sr-binding-sid-labels*
+ | +--ro weight? weight
+ | +--ro (flags)?
+ | | +--:(isis-binding-flags-case)
+ | | | +--ro address-family? boolean
+ | | | +--ro mirror-context? boolean
+ | | | +--ro spread-tlv? boolean
+ | | | +--ro leaked-from-level-2? boolean
+ | | | +--ro attached-flag? boolean
+ | | +--:(ospf-binding-flags-case)
+ | | +--ro mirroring? boolean
+ | +--ro binding-sub-tlvs*
+ | +--ro (binding-sub-tlv)?
+ | +--:(prefix-sid-case)
+ | | +--ro (flags)?
+ | | | +--:(isis-prefix-flags-case)
+ | | | | +--ro no-php? boolean
+ | | | | +--ro explicit-null? boolean
+ | | | | +--ro readvertisement? boolean
+ | | | | +--ro node-sid? boolean
+ | | | +--:(ospf-prefix-flags-case)
+ | | | +--ro no-php? boolean
+ | | | +--ro explicit-null? boolean
+ | | | +--ro mapping-server? boolean
+ | | +--ro algorithm? algorithm
+ | | +--ro (sid-label-index)?
+ | | +--:(local-label-case)
+ | | | +--ro local-label? netc:mpls-label
+ | | +--:(ipv6-address-case)
+ | | | +--ro ipv6-address? inet:ipv6-address
+ | | +--:(sid-case)
+ | | +--ro sid? uint32
+ | +--:(ipv6-prefix-sid-case)
+ | | +--ro algorithm? algorithm
+ | +--:(sid-label-case)
+ | | +--ro (sid-label-index)?
+ | | +--:(local-label-case)
+ | | | +--ro local-label? netc:mpls-label
+ | | +--:(ipv6-address-case)
+ | | | +--ro ipv6-address? inet:ipv6-address
+ | | +--:(sid-case)
+ | | +--ro sid? uint32
+ | +--:(ero-metric-case)
+ | | +--ro ero-metric? netc:te-metric
+ | +--:(ipv4-ero-case)
+ | | +--ro loose? boolean
+ | | +--ro address inet:ipv4-address
+ | +--:(ipv6-ero-case)
+ | | +--ro loose? boolean
+ | | +--ro address inet:ipv6-address
+ | +--:(unnumbered-interface-id-ero-case)
+ | | +--ro loose? boolean
+ | | +--ro router-id? uint32
+ | | +--ro interface-id? uint32
+ | +--:(ipv4-ero-backup-case)
+ | | +--ro loose? boolean
+ | | +--ro address inet:ipv4-address
+ | +--:(ipv6-ero-backup-case)
+ | | +--ro loose? boolean
+ | | +--ro address inet:ipv6-address
+ | +--:(unnumbered-interface-id-backup-ero-case)
+ | +--ro loose? boolean
+ | +--ro router-id? uint32
+ | +--ro interface-id? uint32
+ x--:(te-lsp-attributes-case)
+ +--ro te-lsp-attributes
+
+
+Usage
+^^^^^
+The Link-State table in a instance of the speaker's Loc-RIB can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-linkstate:linkstate-address-family/bgp-linkstate:linkstate-subsequent-address-family/linkstate-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <linkstate-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-linkstate">
+ ...
+ </linkstate-routes>
+
+.. note:: Link-State routes mapping to topology links/nodes/prefixes is supported by BGP Topology Provider.
+
+References
+^^^^^^^^^^
+* `North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP <https://tools.ietf.org/html/rfc7752>`_
+* `BGP Link-State extensions for Segment Routing <https://tools.ietf.org/html/draft-gredler-idr-bgp-ls-segment-routing-ext-03>`_
+* `Segment Routing BGP Egress Peer Engineering BGP-LS Extensions <https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-05>`_
+* `BGP Link-State Information Distribution Implementation Report <https://tools.ietf.org/html/draft-ietf-idr-ls-distribution-impl-04>`_
+
+Flow Specification Family
+-------------------------
+The BGP Flow Specification (BGP-FS) Multiprotocol extension can be used to distribute traffic flow specifications.
+For example, the BGP-FS can be used in a case of (distributed) denial-of-service (DDoS) attack mitigation procedures and traffic filtering (BGP/MPLS VPN service, DC).
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+Configuration
^^^^^^^^^^^^^
+This section shows a way to enable BGP-FS family in BGP speaker and peer configuration.
+
+BGP Speaker
+'''''''''''
+To enable BGP-FS support in BGP plugin, first configure BGP speaker instance:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <protocol xmlns="http://openconfig.net/yang/network-instance">
+ <name>bgp-example</name>
+ <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
+ <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <global>
+ <config>
+ <router-id>192.0.2.2</router-id>
+ <as>65000</as>
+ </config>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name>IPV4-FLOW</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV6-FLOW</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV4-L3VPN-FLOW</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV6-L3VPN-FLOW</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </global>
+ </bgp>
+ </protocol>
+
+BGP Peer
+''''''''
+Here is an example for BGP peer configuration with enabled BGP-FS family.
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.1</neighbor-address>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name>IPV4-FLOW</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV6-FLOW</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV4-L3VPN-FLOW</afi-safi-name>
+ </afi-safi>
+ <afi-safi>
+ <afi-safi-name>IPV6-L3VPN-FLOW</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </neighbor>
+
+Flow Specification API
+^^^^^^^^^^^^^^^^^^^^^^
+Following trees illustrate the BGP Flow Specification routes structure.
+
+IPv4 Flow Specification Route
+'''''''''''''''''''''''''''''
+.. code-block:: console
+
+ :(flowspec-routes-case)
+ +--ro flowspec-routes
+ +--ro flowspec-route* [route-key path-id]
+ +--ro route-key string
+ +--ro flowspec*
+ | +--ro (flowspec-type)?
+ | +--:(port-case)
+ | | +--ro ports*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint16
+ | +--:(destination-port-case)
+ | | +--ro destination-ports*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint16
+ | +--:(source-port-case)
+ | | +--ro source-ports*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint16
+ | +--:(icmp-type-case)
+ | | +--ro types*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint8
+ | +--:(icmp-code-case)
+ | | +--ro codes*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint8
+ | +--:(tcp-flags-case)
+ | | +--ro tcp-flags*
+ | | +--ro op? bitmask-operand
+ | | +--ro value? uint16
+ | +--:(packet-length-case)
+ | | +--ro packet-lengths*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint16
+ | +--:(dscp-case)
+ | | +--ro dscps*
+ | | +--ro op? numeric-operand
+ | | +--ro value? dscp
+ | +--:(fragment-case)
+ | | +--ro fragments*
+ | | +--ro op? bitmask-operand
+ | | +--ro value? fragment
+ | +--:(destination-prefix-case)
+ | | +--ro destination-prefix? inet:ipv4-prefix
+ | +--:(source-prefix-case)
+ | | +--ro source-prefix? inet:ipv4-prefix
+ | +--:(protocol-ip-case)
+ | +--ro protocol-ips*
+ | +--ro op? numeric-operand
+ | +--ro value? uint8
+ +--ro path-id path-id
+ +--ro attributes
+ +--ro extended-communities*
+ +--ro transitive? boolean
+ +--ro (extended-community)?
+ +--:(traffic-rate-extended-community-case)
+ | +--ro traffic-rate-extended-community
+ | +--ro informative-as? bgp-t:short-as-number
+ | +--ro local-administrator? netc:bandwidth
+ +--:(traffic-action-extended-community-case)
+ | +--ro traffic-action-extended-community
+ | +--ro sample? boolean
+ | +--ro terminal-action? boolean
+ +--:(redirect-extended-community-case)
+ | +--ro redirect-extended-community
+ | +--ro global-administrator? bgp-t:short-as-number
+ | +--ro local-administrator? binary
+ +--:(traffic-marking-extended-community-case)
+ | +--ro traffic-marking-extended-community
+ | +--ro global-administrator? dscp
+ +--:(redirect-ipv4-extended-community-case)
+ | +--ro redirect-ipv4
+ | +--ro global-administrator? inet:ipv4-address
+ | +--ro local-administrator? uint16
+ +--:(redirect-as4-extended-community-case)
+ | +--ro redirect-as4
+ | +--ro global-administrator? inet:as-number
+ | +--ro local-administrator? uint16
+ +--:(redirect-ip-nh-extended-community-case)
+ +--ro redirect-ip-nh-extended-community
+ +--ro next-hop-address? inet:ip-address
+ +--ro copy? boolean
+
+
+IPv6 Flow Specification Route
+'''''''''''''''''''''''''''''
+.. code-block:: console
+
+ :(flowspec-ipv6-routes-case)
+ +--ro flowspec-ipv6-routes
+ +--ro flowspec-route* [route-key path-id]
+ +--ro flowspec*
+ | +--ro (flowspec-type)?
+ | +--:(port-case)
+ | | +--ro ports*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint16
+ | +--:(destination-port-case)
+ | | +--ro destination-ports*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint16
+ | +--:(source-port-case)
+ | | +--ro source-ports*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint16
+ | +--:(icmp-type-case)
+ | | +--ro types*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint8
+ | +--:(icmp-code-case)
+ | | +--ro codes*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint8
+ | +--:(tcp-flags-case)
+ | | +--ro tcp-flags*
+ | | +--ro op? bitmask-operand
+ | | +--ro value? uint16
+ | +--:(packet-length-case)
+ | | +--ro packet-lengths*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint16
+ | +--:(dscp-case)
+ | | +--ro dscps*
+ | | +--ro op? numeric-operand
+ | | +--ro value? dscp
+ | +--:(fragment-case)
+ | | +--ro fragments*
+ | | +--ro op? bitmask-operand
+ | | +--ro value? fragment
+ | +--:(destination-ipv6-prefix-case)
+ | | +--ro destination-prefix? inet:ipv6-prefix
+ | +--:(source-ipv6-prefix-case)
+ | | +--ro source-prefix? inet:ipv6-prefix
+ | +--:(next-header-case)
+ | | +--ro next-headers*
+ | | +--ro op? numeric-operand
+ | | +--ro value? uint8
+ | +--:(flow-label-case)
+ | +--ro flow-label*
+ | +--ro op? numeric-operand
+ | +--ro value? uint32
+ +--ro path-id path-id
+ +--ro attributes
+ +--ro extended-communities*
+ +--ro transitive? boolean
+ +--ro (extended-community)?
+ +--:(traffic-rate-extended-community-case)
+ | +--ro traffic-rate-extended-community
+ | +--ro informative-as? bgp-t:short-as-number
+ | +--ro local-administrator? netc:bandwidth
+ +--:(traffic-action-extended-community-case)
+ | +--ro traffic-action-extended-community
+ | +--ro sample? boolean
+ | +--ro terminal-action? boolean
+ +--:(redirect-extended-community-case)
+ | +--ro redirect-extended-community
+ | +--ro global-administrator? bgp-t:short-as-number
+ | +--ro local-administrator? binary
+ +--:(traffic-marking-extended-community-case)
+ | +--ro traffic-marking-extended-community
+ | +--ro global-administrator? dscp
+ +--:(redirect-ipv6-extended-community-case)
+ | +--ro redirect-ipv6
+ | +--ro global-administrator? inet:ipv6-address
+ | +--ro local-administrator? uint16
+ +--:(redirect-as4-extended-community-case)
+ | +--ro redirect-as4
+ | +--ro global-administrator? inet:as-number
+ | +--ro local-administrator? uint16
+ +--:(redirect-ip-nh-extended-community-case)
+ +--ro redirect-ip-nh-extended-community
+ +--ro next-hop-address? inet:ip-address
+ +--ro copy? boolean
+
+Usage
+^^^^^
+The flowspec route represents rules and an action, defined as an extended community.
+
+IPv4 Flow Specification
+'''''''''''''''''''''''
+The IPv4 Flowspec table in an instance of the speaker's Loc-RIB can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <flowspec-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ <flowspec-route>
+ <path-id>0</path-id>
+ <route-key>all packets to 192.168.0.1/32 AND from 10.0.0.2/32 AND where IP protocol equals to 17 or equals to 6 AND where port equals to 80 or equals to 8080 AND where destination port is greater than 8080 and is less than 8088 or equals to 3128 AND where source port is greater than 1024 </route-key>
+ <attributes>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path></as-path>
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-extended-community>
+ <local-administrator>AgMWLg==</local-administrator>
+ <global-administrator>258</global-administrator>
+ </redirect-extended-community>
+ </extended-communities>
+ </attributes>
+ <flowspec>
+ <destination-prefix>192.168.0.1/32</destination-prefix>
+ </flowspec>
+ <flowspec>
+ <source-prefix>10.0.0.2/32</source-prefix>
+ </flowspec>
+ <flowspec>
+ <protocol-ips>
+ <op>equals</op>
+ <value>17</value>
+ </protocol-ips>
+ <protocol-ips>
+ <op>equals end-of-list</op>
+ <value>6</value>
+ </protocol-ips>
+ </flowspec>
+ <flowspec>
+ <ports>
+ <op>equals</op>
+ <value>80</value>
+ </ports>
+ <ports>
+ <op>equals end-of-list</op>
+ <value>8080</value>
+ </ports>
+ </flowspec>
+ <flowspec>
+ <destination-ports>
+ <op>greater-than</op>
+ <value>8080</value>
+ </destination-ports>
+ <destination-ports>
+ <op>less-than and-bit</op>
+ <value>8088</value>
+ </destination-ports>
+ <destination-ports>
+ <op>equals end-of-list</op>
+ <value>3128</value>
+ </destination-ports>
+ </flowspec>
+ <flowspec>
+ <source-ports>
+ <op>end-of-list greater-than</op>
+ <value>1024</value>
+ </source-ports>
+ </flowspec>
+ </flowspec-route>
+ </flowspec-routes>
+
+IPv6 Flows Specification
+''''''''''''''''''''''''
+The IPv6 Flowspec table in an instance of the speaker's Loc-RIB can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <flowspec-ipv6-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ <flowspec-route>
+ <path-id>0</path-id>
+ <route-key>all packets to 2001:db8:31::/64 AND from 2001:db8:30::/64 AND where next header equals to 17 AND where DSCP equals to 50 AND where flow label equals to 2013 </route-key>
+ <attributes>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path></as-path>
+ <extended-communities>
+ <transitive>true</transitive>
+ <traffic-rate-extended-community>
+ <informative-as>0</informative-as>
+ <local-administrator>AAAAAA==</local-administrator>
+ </traffic-rate-extended-community>
+ </extended-communities>
+ </attributes>
+ <flowspec>
+ <destination-prefix>2001:db8:31::/64</destination-prefix>
+ </flowspec>
+ <flowspec>
+ <source-prefix>2001:db8:30::/64</source-prefix>
+ </flowspec>
+ <flowspec>
+ <next-headers>
+ <op>equals end-of-list</op>
+ <value>17</value>
+ </next-headers>
+ </flowspec>
+ <flowspec>
+ <dscps>
+ <op>equals end-of-list</op>
+ <value>50</value>
+ </dscps>
+ </flowspec>
+ <flowspec>
+ <flow-label>
+ <op>equals end-of-list</op>
+ <value>2013</value>
+ </flow-label>
+ </flowspec>
+ </flowspec-route>
+ </flowspec-ipv6-routes>
+
+IPv4 L3VPN Flows Specification
+''''''''''''''''''''''''''''''
+The IPv4 L3VPN Flowspec table in an instance of the speaker's Loc-RIB can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-l3vpn-subsequent-address-family/bgp-flowspec:flowspec-l3vpn-ipv4-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <flowspec-l3vpn-ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ <flowspec-l3vpn-route>
+ <path-id>0</path-id>
+ <route-key>[l3vpn with route-distinguisher 172.16.0.44:101] all packets from 10.0.0.3/32</route-key>
+ <attributes>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>5.6.7.8</global>
+ </ipv4-next-hop>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path></as-path>
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-ip-nh-extended-community>
+ <copy>false</copy>
+ <next-hop-address>0.0.0.0</next-hop-address>
+ </redirect-ip-nh-extended-community>
+ </extended-communities>
+ </attributes>
+ <route-distinguisher>172.16.0.44:101</route-distinguisher>
+ <flowspec>
+ <source-prefix>10.0.0.3/32</source-prefix>
+ </flowspec>
+ </flowspec-l3vpn-route>
+ </flowspec-l3vpn-ipv4-routes>
+
+Programming
+^^^^^^^^^^^
+IPv4 Flow Specification
+'''''''''''''''''''''''
+This examples show how to originate and remove IPv4 fowspec route via programmable RIB.
+Make sure the *Application Peer* is configured first.
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <flowspec-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ <route-key>flow1</route-key>
+ <path-id>0</path-id>
+ <flowspec>
+ <destination-prefix>192.168.0.1/32</destination-prefix>
+ </flowspec>
+ <flowspec>
+ <source-prefix>10.0.0.1/32</source-prefix>
+ </flowspec>
+ <flowspec>
+ <protocol-ips>
+ <op>equals end-of-list</op>
+ <value>6</value>
+ </protocol-ips>
+ </flowspec>
+ <flowspec>
+ <ports>
+ <op>equals end-of-list</op>
+ <value>80</value>
+ </ports>
+ </flowspec>
+ <flowspec>
+ <destination-ports>
+ <op>greater-than</op>
+ <value>8080</value>
+ </destination-ports>
+ <destination-ports>
+ <op>and-bit less-than end-of-list</op>
+ <value>8088</value>
+ </destination-ports>
+ </flowspec>
+ <flowspec>
+ <source-ports>
+ <op>greater-than end-of-list</op>
+ <value>1024</value>
+ </source-ports>
+ </flowspec>
+ <flowspec>
+ <types>
+ <op>equals end-of-list</op>
+ <value>0</value>
+ </types>
+ </flowspec>
+ <flowspec>
+ <codes>
+ <op>equals end-of-list</op>
+ <value>0</value>
+ </codes>
+ </flowspec>
+ <flowspec>
+ <tcp-flags>
+ <op>match end-of-list</op>
+ <value>32</value>
+ </tcp-flags>
+ </flowspec>
+ <flowspec>
+ <packet-lengths>
+ <op>greater-than</op>
+ <value>400</value>
+ </packet-lengths>
+ <packet-lengths>
+ <op>and-bit less-than end-of-list</op>
+ <value>500</value>
+ </packet-lengths>
+ </flowspec>
+ <flowspec>
+ <dscps>
+ <op>equals end-of-list</op>
+ <value>20</value>
+ </dscps>
+ </flowspec>
+ <flowspec>
+ <fragments>
+ <op>match end-of-list</op>
+ <value>first</value>
+ </fragments>
+ </flowspec>
+ <attributes>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path/>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <extended-communities>
+ ....
+ </extended-communities>
+ </attributes>
+ </flowspec-route>
+
+-----
-**Add route:**
-
-**URL:**
-http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes
-
-**Method:** POST
-
-**Content-Type:** application/xml
-
-.. code:: xml
-
- <flowspec-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
- <route-key>flow1</route-key>
- <flowspec>
- <destination-prefix>192.168.0.1/32</destination-prefix>
- </flowspec>
- <flowspec>
- <source-prefix>10.0.0.1/32</source-prefix>
- </flowspec>
- <flowspec>
- <protocol-ips>
- <op>equals end-of-list</op>
- <value>6</value>
- </protocol-ips>
- </flowspec>
- <flowspec>
- <ports>
- <op>equals end-of-list</op>
- <value>80</value>
- </ports>
- </flowspec>
- <flowspec>
- <destination-ports>
- <op>greater-than</op>
- <value>8080</value>
- </destination-ports>
- <destination-ports>
- <op>and-bit less-than end-of-list</op>
- <value>8088</value>
- </destination-ports>
- </flowspec>
- <flowspec>
- <source-ports>
- <op>greater-than end-of-list</op>
- <value>1024</value>
- </source-ports>
- </flowspec>
- <flowspec>
- <types>
- <op>equals end-of-list</op>
- <value>0</value>
- </types>
- </flowspec>
- <flowspec>
- <codes>
- <op>equals end-of-list</op>
- <value>0</value>
- </codes>
- </flowspec>
- <flowspec>
- <tcp-flags>
- <op>match end-of-list</op>
- <value>32</value>
- </tcp-flags>
- </flowspec>
- <flowspec>
- <packet-lengths>
- <op>greater-than</op>
- <value>400</value>
- </packet-lengths>
- <packet-lengths>
- <op>and-bit less-than end-of-list</op>
- <value>500</value>
- </packet-lengths>
- </flowspec>
- <flowspec>
- <dscps>
- <op>equals end-of-list</op>
- <value>20</value>
- </dscps>
- </flowspec>
- <flowspec>
- <fragments>
- <op>match end-of-list</op>
- <value>first</value>
- </fragments>
- </flowspec>
- <attributes>
- <origin>
- <value>igp</value>
- </origin>
- <as-path/>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <extended-communities>
- ....
- </extended-communities>
- </attributes>
- </flowspec-route>
-
-**Flowspec Extended Communities (Actions):**
-
-.. code:: xml
+**Extended Communities**
+
+* **Traffic Rate**
+ .. code-block:: xml
+ :linenos:
+ :emphasize-lines: 5
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <traffic-rate-extended-community>
+ <informative-as>123</informative-as>
+ <local-administrator>AAAAAA==</local-administrator>
+ </traffic-rate-extended-community>
+ </extended-communities>
+
+ @line 5: A rate in bytes per second, *AAAAAA==* (0) means traffic discard.
+
+* **Traffic Action**
+ .. code-block:: xml
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <traffic-action-extended-community>
+ <sample>true</sample>
+ <terminal-action>false</terminal-action>
+ </traffic-action-extended-community>
+ </extended-communities>
+
+
+* **Redirect to VRF AS 2byte format**
+ .. code-block:: xml
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-extended-community>
+ <global-administrator>123</global-administrator>
+ <local-administrator>AAAAew==</local-administrator>
+ </redirect-extended-community>
+ </extended-communities>
+
+* **Redirect to VRF IPv4 format**
+ .. code-block:: xml
<extended-communities>
- <transitive>true</transitive>
- <traffic-rate-extended-community>
- <informative-as>123</informative-as>
- <local-administrator>AAAAAA==</local-administrator>
- </traffic-rate-extended-community>
+ <transitive>true</transitive>
+ <redirect-ipv4>
+ <global-administrator>192.168.0.1</global-administrator>
+ <local-administrator>12345</local-administrator>
+ </redirect-ipv4>
</extended-communities>
+* **Redirect to VRF AS 4byte format**
+ .. code-block:: xml
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-as4>
+ <global-administrator>64495</global-administrator>
+ <local-administrator>12345</local-administrator>
+ </redirect-as4>
+ </extended-communities>
+
+* **Redirect to IP**
+ .. code-block:: xml
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-ip-nh-extended-community>
+ <copy>false</false>
+ </redirect-ip-nh-extended-community>
+ </extended-communities>
+
+* **Traffic Marking**
+ .. code-block:: xml
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <traffic-marking-extended-community>
+ <global-administrator>20</global-administrator>
+ </traffic-marking-extended-community>
+ </extended-communities>
+
+-----
+
+To remove the route added above, following request can be used:
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes/bgp-flowspec:flowspec-route/flow1/0``
+
+**Method:** ``DELETE``
+
+IPv4 L3VPN Flow Specification
+'''''''''''''''''''''''''''''
+This examples show how to originate and remove IPv4 L3VPN fowspec route via programmable RIB.
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-l3vpn-subsequent-address-family/bgp-flowspec:flowspec-l3vpn-ipv4-routes``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <flowspec-l3vpn-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ <path-id>0</path-id>
+ <route-key>flow-l3vpn</route-key>
+ <route-distinguisher>172.16.0.44:101</route-distinguisher>
+ <flowspec>
+ <source-prefix>10.0.0.3/32</source-prefix>
+ </flowspec>
+ <attributes>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path></as-path>
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-ipv4>
+ <global-administrator>172.16.0.44</global-administrator>
+ <local-administrator>102</local-administrator>
+ </redirect-ipv4>
+ </extended-communities>
+ </attributes>
+ </flowspec-l3vpn-route>
+
+-----
+
+To remove the route added above, following request can be used:
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-l3vpn-subsequent-address-family/bgp-flowspec:flowspec-l3vpn-ipv4-routes/flowspec-l3vpn-route/flow-l3vpn/0``
+
+**Method:** ``DELETE``
+
+IPv6 Flow Specification
+'''''''''''''''''''''''
+This examples show how to originate and remove IPv6 fowspec route via programmable RIB.
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <flowspec-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ <route-key>flow-v6</route-key>
+ <path-id>0</path-id>
+ <flowspec>
+ <destination-prefix>2001:db8:30::3/128</destination-prefix>
+ </flowspec>
+ <flowspec>
+ <source-prefix>2001:db8:31::3/128</source-prefix>
+ </flowspec>
+ <flowspec>
+ <flow-label>
+ <op>equals end-of-list</op>
+ <value>1</value>
+ </flow-label>
+ </flowspec>
+ <attributes>
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-ipv6>
+ <global-administrator>2001:db8:1::6</global-administrator>
+ <local-administrator>12345</local-administrator>
+ </redirect-ipv6>
+ </extended-communities>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path/>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ </attributes>
+ </flowspec-route>
+
+-----
+
+To remove the route added above, following request can be used:
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes/bgp-flowspec:flowspec-route/flow-v6/0``
+
+**Method:** ``DELETE``
+
+References
+^^^^^^^^^^
+* `Dissemination of Flow Specification Rules <https://tools.ietf.org/html/rfc5575>`_
+* `Dissemination of Flow Specification Rules for IPv6 <https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-07>`_
+* `BGP Flow-Spec Extended Community for Traffic Redirect to IP Next Hop <https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-ip-00>`_
+* `Clarification of the Flowspec Redirect Extended Community <https://tools.ietf.org/html/rfc7674>`_
+* `Revised Validation Procedure for BGP Flow Specifications <https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-03>`_
+
+EVPN Family
+-----------
+The BGP MPLS-Based Ethernet VPN (BGP EVPN) Multiprotocol extension can be used to distribute Ethernet L2VPN service related routes in order to support a concept of MAC routing.
+A major use-case for BGP EVPN is data-center interconnection (DCI), where advantage of BGP EVPN are MAC/IP address advertising across MPLS network, Multihoming functionality including Fast Convergence, Split Horizon and Aliasing support, VM (MAC) Mobility, support Multicast and Broadcast traffic.
+In addition to MPLS, IP tunnelling encapsulation techniques like VXLAN, NVGRE, MPLSoGRE and others can be used for packet transportation.
+Also, Provider Backbone Bridging (PBB) can be combined with EVPN in order to reduce a number of MAC Advertisement routes.
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+Configuration
+^^^^^^^^^^^^^
+This section shows a way to enable EVPN family in BGP speaker and peer configuration.
+
+BGP Speaker
+'''''''''''
+To enable EVPN support in BGP plugin, first configure BGP speaker instance:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <protocol xmlns="http://openconfig.net/yang/network-instance">
+ <name>bgp-example</name>
+ <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
+ <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <global>
+ <config>
+ <router-id>192.0.2.2</router-id>
+ <as>65000</as>
+ </config>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L2VPN-EVPN</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </global>
+ </bgp>
+ </protocol>
+
+BGP Peer
+''''''''
+Here is an example for BGP peer configuration with enabled EVPN family.
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.1</neighbor-address>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L2VPN-EVPN</afi-safi-name>
+ </afi-safi>
+ </afi-safis>
+ </neighbor>
+
+EVPN Route API
+^^^^^^^^^^^^^^
+Following tree illustrate the BGP EVPN route structure.
+
+.. code-block:: console
+
+ :(evpn-routes-case)
+ +--ro evpn-routes
+ +--ro evpn-route* [route-key]
+ +--ro route-key string
+ +--ro (evpn-choice)
+ | +--:(ethernet-a-d-route-case)
+ | | +--ro ethernet-a-d-route
+ | | +--ro (esi)
+ | | | +--:(arbitrary-case)
+ | | | | +--ro arbitrary
+ | | | | +--ro arbitrary binary
+ | | | +--:(lacp-auto-generated-case)
+ | | | | +--ro lacp-auto-generated
+ | | | | +--ro ce-lacp-mac-address yang:mac-address
+ | | | | +--ro ce-lacp-port-key uint16
+ | | | +--:(lan-auto-generated-case)
+ | | | | +--ro lan-auto-generated
+ | | | | +--ro root-bridge-mac-address yang:mac-address
+ | | | | +--ro root-bridge-priority uint16
+ | | | +--:(mac-auto-generated-case)
+ | | | | +--ro mac-auto-generated
+ | | | | +--ro system-mac-address yang:mac-address
+ | | | | +--ro local-discriminator uint24
+ | | | +--:(router-id-generated-case)
+ | | | | +--ro router-id-generated
+ | | | | +--ro router-id inet:ipv4-address
+ | | | | +--ro local-discriminator uint32
+ | | | +--:(as-generated-case)
+ | | | +--ro as-generated
+ | | | +--ro as inet:as-number
+ | | | +--ro local-discriminator uint32
+ | | +--ro ethernet-tag-id
+ | | | +--ro vlan-id uint32
+ | | +--ro mpls-label netc:mpls-label
+ | +--:(mac-ip-adv-route-case)
+ | | +--ro mac-ip-adv-route
+ | | +--ro (esi)
+ | | | +--:(arbitrary-case)
+ | | | | +--ro arbitrary
+ | | | | +--ro arbitrary binary
+ | | | +--:(lacp-auto-generated-case)
+ | | | | +--ro lacp-auto-generated
+ | | | | +--ro ce-lacp-mac-address yang:mac-address
+ | | | | +--ro ce-lacp-port-key uint16
+ | | | +--:(lan-auto-generated-case)
+ | | | | +--ro lan-auto-generated
+ | | | | +--ro root-bridge-mac-address yang:mac-address
+ | | | | +--ro root-bridge-priority uint16
+ | | | +--:(mac-auto-generated-case)
+ | | | | +--ro mac-auto-generated
+ | | | | +--ro system-mac-address yang:mac-address
+ | | | | +--ro local-discriminator uint24
+ | | | +--:(router-id-generated-case)
+ | | | | +--ro router-id-generated
+ | | | | +--ro router-id inet:ipv4-address
+ | | | | +--ro local-discriminator uint32
+ | | | +--:(as-generated-case)
+ | | | +--ro as-generated
+ | | | +--ro as inet:as-number
+ | | | +--ro local-discriminator uint32
+ | | +--ro ethernet-tag-id
+ | | | +--ro vlan-id uint32
+ | | +--ro mac-address yang:mac-address
+ | | +--ro ip-address? inet:ip-address
+ | | +--ro mpls-label1 netc:mpls-label
+ | | +--ro mpls-label2? netc:mpls-label
+ | +--:(inc-multi-ethernet-tag-res-case)
+ | | +--ro inc-multi-ethernet-tag-res
+ | | +--ro ethernet-tag-id
+ | | | +--ro vlan-id uint32
+ | | +--ro orig-route-ip? inet:ip-address
+ | +--:(es-route-case)
+ | +--ro es-route
+ | +--ro (esi)
+ | | +--:(arbitrary-case)
+ | | | +--ro arbitrary
+ | | | +--ro arbitrary binary
+ | | +--:(lacp-auto-generated-case)
+ | | | +--ro lacp-auto-generated
+ | | | +--ro ce-lacp-mac-address yang:mac-address
+ | | | +--ro ce-lacp-port-key uint16
+ | | +--:(lan-auto-generated-case)
+ | | | +--ro lan-auto-generated
+ | | | +--ro root-bridge-mac-address yang:mac-address
+ | | | +--ro root-bridge-priority uint16
+ | | +--:(mac-auto-generated-case)
+ | | | +--ro mac-auto-generated
+ | | | +--ro system-mac-address yang:mac-address
+ | | | +--ro local-discriminator uint24
+ | | +--:(router-id-generated-case)
+ | | | +--ro router-id-generated
+ | | | +--ro router-id inet:ipv4-address
+ | | | +--ro local-discriminator uint32
+ | | +--:(as-generated-case)
+ | | +--ro as-generated
+ | | +--ro as inet:as-number
+ | | +--ro local-discriminator uint32
+ | +--ro orig-route-ip inet:ip-address
+ +--ro route-distinguisher bgp-t:route-distinguisher
+ +--ro attributes
+ +--ro extended-communities*
+ | +--ro transitive? boolean
+ | +--ro (extended-community)?
+ | +--:(encapsulation-case)
+ | | +--ro encapsulation-extended-community
+ | | +--ro tunnel-type encapsulation-tunnel-type
+ | +--:(esi-label-extended-community-case)
+ | | +--ro esi-label-extended-community
+ | | +--ro single-active-mode? boolean
+ | | +--ro esi-label netc:mpls-label
+ | +--:(es-import-route-extended-community-case)
+ | | +--ro es-import-route-extended-community
+ | | +--ro es-import yang:mac-address
+ | +--:(mac-mobility-extended-community-case)
+ | | +--ro mac-mobility-extended-community
+ | | +--ro static? boolean
+ | | +--ro seq-number uint32
+ | +--:(default-gateway-extended-community-case)
+ | | +--ro default-gateway-extended-community!
+ | +--:(layer-2-attributes-extended-community-case)
+ | +--ro layer-2-attributes-extended-community
+ | +--ro primary-pe? boolean
+ | +--ro backup-pe? boolean
+ | +--ro control-word? boolean
+ | +--ro l2-mtu uint16
+ +--ro pmsi-tunnel!
+ +--ro leaf-information-required boolean
+ +--ro mpls-label? netc:mpls-label
+ +--ro (tunnel-identifier)?
+ +--:(rsvp-te-p2mp-lsp)
+ | +--ro rsvp-te-p2mp-lps
+ | +--ro p2mp-id uint32
+ | +--ro tunnel-id uint16
+ | +--ro extended-tunnel-id inet:ip-address
+ +--:(mldp-p2mp-lsp)
+ | +--ro mldp-p2mp-lsp
+ | +--ro address-family identityref
+ | +--ro root-node-address inet:ip-address
+ | +--ro opaque-value*
+ | +--ro opaque-type uint8
+ | +--ro opaque-extended-type? uint16
+ | +--ro opaque yang:hex-string
+ +--:(pim-ssm-tree)
+ | +--ro pim-ssm-tree
+ | +--ro p-address inet:ip-address
+ | +--ro p-multicast-group inet:ip-address
+ +--:(pim-sm-tree)
+ | +--ro pim-sm-tree
+ | +--ro p-address inet:ip-address
+ | +--ro p-multicast-group inet:ip-address
+ +--:(bidir-pim-tree)
+ | +--ro bidir-pim-tree
+ | +--ro p-address inet:ip-address
+ | +--ro p-multicast-group inet:ip-address
+ +--:(ingress-replication)
+ | +--ro ingress-replication
+ | +--ro receiving-endpoint-address? inet:ip-address
+ +--:(mldp-mp2mp-lsp)
+ +--ro mldp-mp2mp-lsp
+ +--ro opaque-type uint8
+ +--ro opaque-extended-type? uint16
+ +--ro opaque
+ ...
+
+Usage
+^^^^^
+The L2VPN EVPN table in an instance of the speaker's Loc-RIB can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/odl-bgp-evpn:l2vpn-address-family/odl-bgp-evpn:evpn-subsequent-address-family/evpn-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <evpn-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-evpn">
+ <evpn-route>
+ <route-key>AxEAAcCoZAED6AAAAQAgwKhkAQ==</route-key>
+ <route-distinguisher>192.168.100.1:1000</route-distinguisher>
+ <inc-multi-ethernet-tag-res>
+ <ethernet-tag-id>
+ <vlan-id>256</vlan-id>
+ </ethernet-tag-id>
+ <orig-route-ip>192.168.100.1</orig-route-ip>
+ </inc-multi-ethernet-tag-res>
+ <attributes>
+ <ipv4-next-hop>
+ <global>172.23.29.104</global>
+ </ipv4-next-hop>
+ <as-path/>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <extended-communities>
+ <extended-communities>
+ <transitive>true</transitive>
+ <route-target-extended-community>
+ <global-administrator>65504</global-administrator>
+ <local-administrator>AAAD6A==</local-administrator>
+ </route-target-extended-community>
+ </extended-communities>
+ </extended-communities>
+ <pmsi-tunnel>
+ <leaf-information-required>true</leaf-information-required>
+ <mpls-label>20024</mpls-label>
+ <ingress-replication>
+ <receiving-endpoint-address>192.168.100.1</receiving-endpoint-address>
+ </ingress-replication>
+ </pmsi-tunnel>
+ </attributes>
+ </evpn-route>
+ </evpn-routes>
+
+Programming
+^^^^^^^^^^^
+This examples show how to originate and remove EVPN routes via programmable RIB.
+There are four different types of EVPN routes, and several extended communities.
+Routes can be used for variety of use-cases supported by BGP/MPLS EVPN, PBB EVPN and NVO EVPN.
+Make sure the *Application Peer* is configured first.
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/odl-bgp-evpn:l2vpn-address-family/odl-bgp-evpn:evpn-subsequent-address-family/odl-bgp-evpn:evpn-routes``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 3,4,14
+
+ <evpn-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-evpn">
+ <route-key>evpn</route-key>
+ <route-distinguisher>172.12.123.3:200</route-distinguisher>
+ ....
+ <attributes>
+ <ipv4-next-hop>
+ <global>199.20.166.41</global>
+ </ipv4-next-hop>
+ <as-path/>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <extended-communities>
+ ....
+ </extended-communities>
+ </attributes>
+ </evpn-route>
+
+@line 3: Route Distinguisher (RD) - set to RD of the MAC-VRF advertising the NLRI, recommended format *<IP>:<VLAN_ID>*
+
+@line 4: One of the EVPN route must be set here.
+
+@line 14: In some cases, specific extended community presence is required. The route may carry one or more Route Target attributes.
+
+-----
+
+**EVPN Routes:**
+
+* **Ethernet AD per ESI**
+ .. code-block:: xml
+
+ <ethernet-a-d-route>
+ <mpls-label>0</mpls-label>
+ <ethernet-tag-id>
+ <vlan-id>4294967295</vlan-id>
+ </ethernet-tag-id>
+ <arbitrary>
+ <arbitrary>AAAAAAAAAAAA</arbitrary>
+ </arbitrary>
+ </ethernet-a-d-route>
+
+* **Ethernet AD per EVI**
+ .. code-block:: xml
+
+ <ethernet-a-d-route>
+ <mpls-label>24001</mpls-label>
+ <ethernet-tag-id>
+ <vlan-id>2200</vlan-id>
+ </ethernet-tag-id>
+ <arbitrary>
+ <arbitrary>AAAAAAAAAAAA</arbitrary>
+ </arbitrary>
+ </ethernet-a-d-route>
+
+* **MAC/IP Advertisement**
+ .. code-block:: xml
+
+ <mac-ip-adv-route>
+ <arbitrary>
+ <arbitrary>AAAAAAAAAAAA</arbitrary>
+ </arbitrary>
+ <ethernet-tag-id>
+ <vlan-id>2100</vlan-id>
+ </ethernet-tag-id>
+ <mac-address>f2:0c:dd:80:9f:f7</mac-address>
+ <ip-address>10.0.1.12</ip-address>
+ <mpls-label1>299776</mpls-label1>
+ </mac-ip-adv-route>
+
+
+* **Inclusive Multicast Ethernet Tag**
+ .. code-block:: xml
+
+ <inc-multi-ethernet-tag-res>
+ <ethernet-tag-id>
+ <vlan-id>2100</vlan-id>
+ </ethernet-tag-id>
+ <orig-route-ip>43.43.43.43</orig-route-ip>
+ </inc-multi-ethernet-tag-res>
+
+* **Ethernet Segment**
+ .. code-block:: xml
+
+ <es-route>
+ <orig-route-ip>43.43.43.43</orig-route-ip>
+ <arbitrary>
+ <arbitrary>AAAAAAAAAAAA</arbitrary>
+ </arbitrary>
+ </es-route>
+
+**EVPN Ethernet Segment Identifier (ESI):**
+
+* **Type 0**
+ Indicates an arbitrary 9-octet ESI.
+
+ .. code-block:: xml
+
+ <arbitrary>
+ <arbitrary>AAAAAAAAAAAA</arbitrary>
+ </arbitrary>
+
+* **Type 1**
+ IEEE 802.1AX LACP is used.
+
+ .. code-block:: xml
+
+ <lacp-auto-generated>
+ <ce-lacp-mac-address>f2:0c:dd:80:9f:f7</ce-lacp-mac-address>
+ <ce-lacp-port-key>22</ce-lacp-port-key>
+ </lacp-auto-generated>
+
+* **Type 2**
+ Indirectly connected hosts via a bridged LAN.
+
+ .. code-block:: xml
+
+ <lan-auto-generated>
+ <root-bridge-mac-address>f2:0c:dd:80:9f:f7</root-bridge-mac-address>
+ <root-bridge-priority>20</root-bridge-priority>
+ </lan-auto-generated>
+
+* **Type 3**
+ MAC-based ESI.
+
+ .. code-block:: xml
+
+ <mac-auto-generated>
+ <system-mac-address>f2:0c:dd:80:9f:f7</system-mac-address>
+ <local-discriminator>2000</local-discriminator>
+ </mac-auto-generated>
+
+* **Type 4**
+ Router-ID ESI
+
+ .. code-block:: xml
+
+ <router-id-generated>
+ <router-id>43.43.43.43</router-id>
+ <local-discriminator>2000</local-discriminator>
+ </router-id-generated>
+
+* **Type 5**
+ AS-based ESI
+
+ .. code-block:: xml
+
+ <as-generated>
+ <as>16843009</as>
+ <local-discriminator>2000</local-discriminator>
+ </as-generated>
+
+**Extended Communities:**
+
+* **ESI Label Extended Community**
+ .. code-block:: xml
+
<extended-communities>
- <transitive>true</transitive>
- <traffic-action-extended-community>
- <sample>true</sample>
- <terminal-action>false</terminal-action>
- </traffic-action-extended-community>
+ <transitive>true</transitive>
+ <esi-label-extended-community>
+ <single-active-mode>false</single-active-mode>
+ <esi-label>24001</esi-label>
+ </esi-label-extended-community >
</extended-communities>
+* **ES-Import Route Target**
+ .. code-block:: xml
+
<extended-communities>
- <transitive>true</transitive>
- <redirect-extended-community>
- <global-administrator>123</global-administrator>
- <local-administrator>AAAAew==</local-administrator>
- </redirect-extended-community>
+ <transitive>true</transitive>
+ <es-import-route-extended-community>
+ <es-import>f2:0c:dd:80:9f:f7</es-import>
+ </es-import-route-extended-community>
</extended-communities>
+* **MAC Mobility Extended Community**
+ .. code-block:: xml
+
<extended-communities>
- <transitive>true</transitive>
- <redirect-ipv4>
- <global-administrator>192.168.0.1</global-administrator>
- <local-administrator>12345</local-administrator>
- </redirect-ipv4>
+ <transitive>true</transitive>
+ <mac-mobility-extended-community>
+ <static>true</static>
+ <seq-number>200</seq-number>
+ </mac-mobility-extended-community>
</extended-communities>
+* **Default Gateway Extended Community**
+ .. code-block:: xml
+
<extended-communities>
- <transitive>true</transitive>
- <redirect-as4>
- <global-administrator>64495</global-administrator>
- <local-administrator>12345</local-administrator>
- </redirect-as4>
+ <transitive>true</transitive>
+ <default-gateway-extended-community>
+ </default-gateway-extended-community>
</extended-communities>
+* **EVPN Layer 2 attributes extended community**
+ .. code-block:: xml
+
<extended-communities>
- <transitive>true</transitive>
- <redirect-ip-nh-extended-community>
- <copy>false</false>
- </redirect-ip-nh-extended-community>
+ <transitive>false</transitive>
+ <layer-2-attributes-extended-community>
+ <primary-pe>true</primary-pe>
+ <backup-pe>true</backup-pe>
+ <control-word >true</control-word>
+ <l2-mtu>200</l2-mtu>
+ </layer-2-attributes-extended-community>
</extended-communities>
+* **BGP Encapsulation extended community**
+ .. code-block:: xml
+ :linenos:
+ :emphasize-lines: 4
+
<extended-communities>
- <transitive>true</transitive>
- <traffic-marking-extended-community>
- <global-administrator>20</global-administrator>
- </traffic-marking-extended-community>
+ <transitive>false</transitive>
+ <encapsulation-extended-community>
+ <tunnel-type>vxlan</tunnel-type>
+ </encapsulation-extended-community>
</extended-communities>
-The request results in **204 No content**. This is expected.
+ @line 4: `full list of tunnel types <http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types>`_
+
+* **P-Multicast Service Interface Tunnel (PMSI) attribute**
+ .. code-block:: xml
+
+ <pmsi-tunnel>
+ <leaf-information-required>true</leaf-information-required>
+ <mpls-label>20024</mpls-label>
+ <ingress-replication>
+ <receiving-endpoint-address>172.12.123.3</receiving-endpoint-address>
+ </ingress-replication>
+ </pmsi-tunnel>
+
+-----
+
+To remove the route added above, following request can be used:
+
+**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/odl-bgp-evpn:l2vpn-address-family/odl-bgp-evpn:evpn-subsequent-address-family/odl-bgp-evpn:evpn-routes/evpn-route/evpn``
+
+**Method:** ``DELETE``
+
+-----
+
+.. table:: EVPN Routes Usage.
+
+ +--------------------------------------+-----------------------------------------------------+-------------------------------------------+
+ | EVN Route Type | Extended Communities | Usage |
+ +======================================+=====================================================+===========================================+
+ | **Ethernet Auto-discovery** | ESI Label, BGP EncapsulationEVPN Layer 2 attributes | Fast Convergence, Split Horizon, Aliasing |
+ +--------------------------------------+-----------------------------------------------------+-------------------------------------------+
+ | **MAC/IP Advertisement** | BGP Encapsulation, MAC Mobility, Default Gateway | MAC address reachability |
+ +--------------------------------------+-----------------------------------------------------+-------------------------------------------+
+ | **Inclusive Multicast Ethernet Tag** | PMSI Tunnel, BGP Encapsulation | Handling of Multi-destination traffic |
+ +--------------------------------------+-----------------------------------------------------+-------------------------------------------+
+ | **Ethernet Segment** | BGP Encapsulation, ES-Import Route Target | Designated Forwarder Election |
+ +--------------------------------------+-----------------------------------------------------+-------------------------------------------+
+
+References
+^^^^^^^^^^
+* `BGP MPLS-Based Ethernet VPN <https://tools.ietf.org/html/rfc7432>`_
+* `Provider Backbone Bridging Combined with Ethernet VPN <https://tools.ietf.org/html/rfc7623>`_
+* `VPWS support in EVPN <https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-07>`_
+* `A Network Virtualization Overlay Solution using EVPN <https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-04>`_
+* `Interconnect Solution for EVPN Overlay networks <https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-04>`_
+* `Usage and applicability of BGP MPLS based Ethernet VPN <https://tools.ietf.org/html/draft-ietf-bess-evpn-usage-03>`_
+
+Additional Path
+---------------
+The ADD-PATH capability allows to advertise multiple paths for the same address prefix.
+It can help with optimal routing and routing convergence in a network by providing potential alternate or backup paths.
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+Configuration
+^^^^^^^^^^^^^
+This section shows a way to enable ADD-PATH capability in BGP speaker and peer configuration.
+
+.. note:: The capability is applicable for IP Unicast, IP Labeled Unicast and Flow Specification address families.
+
+BGP Speaker
+'''''''''''
+To enable ADD-PATH capability in BGP plugin, first configure BGP speaker instance:
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 14
+
+ <protocol xmlns="http://openconfig.net/yang/network-instance">
+ <name>bgp-example</name>
+ <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
+ <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <global>
+ <config>
+ <router-id>192.0.2.2</router-id>
+ <as>65000</as>
+ </config>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
+ <receive>true</receive>
+ <send-max>2</send-max>
+ </afi-safi>
+ </afi-safis>
+ </global>
+ </bgp>
+ </protocol>
+
+@line 14: Defines path selection strategy: *send-max* > 1 -> Advertise N Paths or *send-max* = 0 -> Advertise All Paths
+
+BGP Peer
+''''''''
+Here is an example for BGP peer configuration with enabled ADD-PATH capability.
+
+**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
+ <neighbor-address>192.0.2.1</neighbor-address>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-LABELLED-UNICAST</afi-safi-name>
+ </afi-safi>
+ <afi-safis>
+ <afi-safi>
+ <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
+ <receive>true</receive>
+ <send-max>0</send-max>
+ </afi-safi>
+ </afi-safis>
+ </afi-safis>
+ </neighbor>
+
+.. note:: The path selection strategy is not configurable on per peer basis. The send-max presence indicates a willingness to send ADD-PATH NLRIs to the neighbor.
+
+Usage
+^^^^^
+The IPv4 Unicast table with enabled ADD-PATH capability in an instance of the speaker's Loc-RIB can be verified via REST:
+
+**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 3
+
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <ipv4-route>
+ <path-id>1</path-id>
+ <prefix>193.0.2.1/32</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.0.0.1</global>
+ </ipv4-next-hop>
+ </attributes>
+ </ipv4-route>
+ <ipv4-route>
+ <path-id>2</path-id>
+ <prefix>193.0.2.1/32</prefix>
+ <attributes>
+ <as-path></as-path>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <ipv4-next-hop>
+ <global>10.0.0.2</global>
+ </ipv4-next-hop>
+ </attributes>
+ </ipv4-route>
+ </ipv4-routes>
+
+@line 3: The routes with the same destination are distinguished by *path-id* attribute.
+
+References
+^^^^^^^^^^
+* `Advertisement of Multiple Paths in BGP <https://tools.ietf.org/html/rfc7911>`_
+* `Best Practices for Advertisement of Multiple Paths in IBGP <https://tools.ietf.org/html/draft-ietf-idr-add-paths-guidelines-08>`_
+
+Route Refresh
+-------------
+The Route Refresh Capability allows to dynamically request a re-advertisement of the Adj-RIB-Out from a BGP peer.
+This is useful when the inbound routing policy for a peer changes and all prefixes from a peer must be reexamined against a new policy.
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+Configuration
+^^^^^^^^^^^^^
+The capability is enabled by default, no additional configuration is required.
+
+Usage
+^^^^^
+To send a Route Refresh request from OpenDaylight BGP speaker instance to its neighbor, invoke RPC:
-**Delete route:**
+**URL:** ``/restconf/operations/bgp-peer-rpc:route-refresh-request``
-**URL:**
-`http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes/bgp-flowspec:flowspec-route/<route-id> <http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes/bgp-flowspec:flowspec-route/<route-id>>`__
+**Method:** ``POST``
-**Method:** DELETE
+**Content-Type:** ``application/xml``
-IPv6 Flowspec
+**Request Body:**
+
+.. code-block:: xml
+
+ <input xmlns="urn:opendaylight:params:xml:ns:yang:bgp-peer-rpc">
+ <afi xmlns:types="urn:opendaylight:params:xml:ns:yang:bgp-types">types:ipv4-address-family</afi>
+ <safi xmlns:types="urn:opendaylight:params:xml:ns:yang:bgp-types">types:unicast-subsequent-address-family</safi>
+ <peer-ref xmlns:rib="urn:opendaylight:params:xml:ns:yang:bgp-rib">/rib:bgp-rib/rib:rib[rib:id="bgp-example"]/rib:peer[rib:peer-id="bgp://10.25.1.9"]</peer-ref>
+ </input>
+
+References
+^^^^^^^^^^
+* `Route Refresh Capability for BGP-4 <https://tools.ietf.org/html/rfc2918>`_
+
+High Availability
+-----------------
+Running OpenDaylight BGP in clustered environment brings an advantage of the plugin's high availability (HA).
+This section illustrates a basic scenario for HA, also presents a configuration for clustered OpenDaylight BGP.
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+Configuration
^^^^^^^^^^^^^
+Following example shows a configuration for running BGP in clustered environment.
+
+#. As the first step, configure (replicated *deafult* shard and *topology* shard if needed) and run OpenDaylight in clustered environment, install BGP and RESTCONF.
+
+#. On one node (OpenDaylight instance), configure BGP speaker instance and neighbor. In addition, configure BGP topology exporter if required. The configuration is shared across all interconnected cluster nodes, however BGP become active only on one node. Other nodes with configured BGP serves as stand-by backups.
+
+#. Remote peer should be configured to accept/initiate connection from/to all OpenDaylight cluster nodes with configured BGP plugin.
+
+#. Connect remote peer, let it advertise some routes. Verify routes presence in Loc-RIB and/or BGP topology exporter instance on all nodes of the OpenDaylight cluster.
+
+.. warning::
+
+ Replicating RIBs across the cluster nodes is causing severe scalability issue and overall performance degradation. To avoid this problems, configure BGP RIB module as a separate shard without enabled replication. Change configuration on all nodes as following (`configuration/initial`):
+
+ * In ``modules.conf`` add a new module:
+ .. code-block:: console
+
+ {
+ name = "bgp_rib"
+ namespace = "urn:opendaylight:params:xml:ns:yang:bgp-rib"
+ shard-strategy = "module"
+ }
+
+ * In ``module-shards.conf`` define a new module shard:
+ .. code-block:: console
+
+ {
+ name = "bgp_rib"
+ shards = [
+ {
+ name="bgp_rib"
+ replicas = [
+ "member-1"
+ ]
+ }
+ ]
+ }
+
+ **Note:** Use correct member name in module shard configuration.
+
+Failover scenario
+^^^^^^^^^^^^^^^^^
+Following section presents a basic BGP speaker failover scenario on 3-node OpenDaylight cluster setup.
+
+.. figure:: ./images/bgpcep/BGP_HA.png
+ :alt: BGP HA setup.
+
+ Once the OpenDaylight BGP is configured, the speaker become active on one of the cluster nodes. Remote peer can establish connection with this BGP instance.
+ Routes advertised by remote peer are replicated, hence RIBs state on all nodes is the same.
+
+-----
+
+.. figure:: ./images/bgpcep/BGP_HA_failure.png
+ :alt: Node went down.
+
+ In a case a cluster node, where BGP instance is running, goes down (unexpected failure, restart), active BGP session is dropped.
+
+-----
+
+.. figure:: ./images/bgpcep/BGP_HA_recovery.png
+ :alt: BGP recovery.
+
+ Now, one of the stand-by BGP speaker instances become active. Remote peer establishes new connection and advertises routes again.
+
+Topology Provider
+-----------------
+This section provides an overview of the BGP topology provider service.
+It shows how to configure and use all available BGP topology providers.
+Providers are building topology view of BGP routes stored in local BGP speaker's Loc-RIB.
+Output topologies are rendered in a form of standardised IETF network topology model.
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+Inet Reachability Topology
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+Inet reachability topology exporter offers a mapping service from IPv4/6 routes to network topology nodes.
+
+Configuration
+'''''''''''''
+Following example shows how to create a new instance of IPv4 BGP topology exporter:
+
+**URL:** ``/restconf/config/network-topology:network-topology``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 2,4,6
+
+ <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
+ <topology-id>bgp-example-ipv4-topology</topology-id>
+ <topology-types>
+ <bgp-ipv4-reachability-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"></bgp-ipv4-reachability-topology>
+ </topology-types>
+ <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-config">bgp-example</rib-id>
+ </topology>
+
+@line 2: An identifier for a topology.
+
+@line 4: Used to identify type of the topology. In this case BGP IPv4 reachability topology.
+
+@line 6: A name of the local BGP speaker instance.
+
+-----
+
+The topology exporter instance can be removed in a following way:
+
+**URL:** ``/restconf/config/network-topology:network-topology/topology/bgp-example-ipv4-topology``
+
+**Method:** ``DELETE``
+
+-----
+
+Following example shows how to create a new instance of IPv6 BGP topology exporter:
+
+**URL:** ``/restconf/config/network-topology:network-topology``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
+ <topology-id>bgp-example-ipv6-topology</topology-id>
+ <topology-types>
+ <bgp-ipv6-reachability-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"></bgp-ipv6-reachability-topology>
+ </topology-types>
+ <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-config">bgp-example</rib-id>
+ </topology>
+
+Usage
+'''''
+Operational state of the topology can be verified via REST:
+
+**URL:** ``/restconf/operational/network-topology:network-topology/topology/bgp-example-ipv4-topology``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 8,11
+
+ <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
+ <topology-id>bgp-example-ipv4-topology</topology-id>
+ <server-provided>true</server-provided>
+ <topology-types>
+ <bgp-ipv4-reachability-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"></bgp-ipv4-reachability-topology>
+ </topology-types>
+ <node>
+ <node-id>10.10.1.1</node-id>
+ <igp-node-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology">
+ <prefix>
+ <prefix>10.0.0.10/32</prefix>
+ </prefix>
+ </igp-node-attributes>
+ </node>
+ </topology>
+
+@line 8: The identifier of a node in a topology. Its value is mapped from route's NEXT_HOP attribute.
+
+@line 11: The IP prefix attribute of the node. Its value is mapped from routes's destination IP prefix.
+
+BGP Linkstate Topology
+^^^^^^^^^^^^^^^^^^^^^^
+BGP linkstate topology exporter offers a mapping service from BGP-LS routes to network topology nodes and links.
+
+Configuration
+'''''''''''''
+Following example shows how to create a new instance of linkstate BGP topology exporter:
+
+**URL:** ``/restconf/config/network-topology:network-topology``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+
+ <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
+ <topology-id>bgp-example-linkstate-topology</topology-id>
+ <topology-types>
+ <bgp-linkstate-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"></bgp-linkstate-topology>
+ </topology-types>
+ <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-config">bgp-example</rib-id>
+ </topology>
+
+Usage
+'''''
+Operational state of the topology can be verified via REST.
+A sample output below represents a two node topology with two unidirectional links interconnecting those nodes.
+
+**URL:** ``/restconf/operational/network-topology:network-topology/topology/bgp-example-linkstate-topology``
+
+**Method:** ``GET``
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
+ <topology-id>bgp-example-linkstate-topology</topology-id>
+ <server-provided>true</server-provided>
+ <topology-types>
+ <bgp-linkstate-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"></bgp-linkstate-topology>
+ </topology-types>
+ <node>
+ <node-id>bgpls://IsisLevel2:1/type=node&as=65000&domain=673720360&router=0000.0000.0040</node-id>
+ <termination-point>
+ <tp-id>bgpls://IsisLevel2:1/type=tp&ipv4=203.20.160.40</tp-id>
+ <igp-termination-point-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology"/>
+ </termination-point>
+ <igp-node-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology">
+ <prefix>
+ <prefix>40.40.40.40/32</prefix>
+ <metric>10</metric>
+ </prefix>
+ <prefix>
+ <prefix>203.20.160.0/24</prefix>
+ <metric>10</metric>
+ </prefix>
+ <name>node1</name>
+ <router-id>40.40.40.40</router-id>
+ <isis-node-attributes xmlns="urn:TBD:params:xml:ns:yang:network:isis-topology">
+ <ted>
+ <te-router-id-ipv4>40.40.40.40</te-router-id-ipv4>
+ </ted>
+ <iso>
+ <iso-system-id>MDAwMDAwMDAwMDY0</iso-system-id>
+ </iso>
+ </isis-node-attributes>
+ </igp-node-attributes>
+ </node>
+ <node>
+ <node-id>bgpls://IsisLevel2:1/type=node&as=65000&domain=673720360&router=0000.0000.0039</node-id>
+ <termination-point>
+ <tp-id>bgpls://IsisLevel2:1/type=tp&ipv4=203.20.160.39</tp-id>
+ <igp-termination-point-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology"/>
+ </termination-point>
+ <igp-node-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology">
+ <prefix>
+ <prefix>39.39.39.39/32</prefix>
+ <metric>10</metric>
+ </prefix>
+ <prefix>
+ <prefix>203.20.160.0/24</prefix>
+ <metric>10</metric>
+ </prefix>
+ <name>node2</name>
+ <router-id>39.39.39.39</router-id>
+ <isis-node-attributes xmlns="urn:TBD:params:xml:ns:yang:network:isis-topology">
+ <ted>
+ <te-router-id-ipv4>39.39.39.39</te-router-id-ipv4>
+ </ted>
+ <iso>
+ <iso-system-id>MDAwMDAwMDAwMDg3</iso-system-id>
+ </iso>
+ </isis-node-attributes>
+ </igp-node-attributes>
+ </node>
+ <link>
+ <destination>
+ <dest-node>bgpls://IsisLevel2:1/type=node&as=65000&domain=673720360&router=0000.0000.0039</dest-node>
+ <dest-tp>bgpls://IsisLevel2:1/type=tp&ipv4=203.20.160.39</dest-tp>
+ </destination>
+ <link-id>bgpls://IsisLevel2:1/type=link&local-as=65000&local-domain=673720360&local-router=0000.0000.0040&remote-as=65000&remote-domain=673720360&remote-router=0000.0000.0039&ipv4-iface=203.20.160.40&ipv4-neigh=203.20.160.39</link-id>
+ <source>
+ <source-node>bgpls://IsisLevel2:1/type=node&as=65000&domain=673720360&router=0000.0000.0040</source-node>
+ <source-tp>bgpls://IsisLevel2:1/type=tp&ipv4=203.20.160.40</source-tp>
+ </source>
+ <igp-link-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology">
+ <metric>10</metric>
+ <isis-link-attributes xmlns="urn:TBD:params:xml:ns:yang:network:isis-topology">
+ <ted>
+ <color>0</color>
+ <max-link-bandwidth>1250000.0</max-link-bandwidth>
+ <max-resv-link-bandwidth>12500.0</max-resv-link-bandwidth>
+ <te-default-metric>0</te-default-metric>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>0</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>1</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>2</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>3</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>4</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>5</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>6</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>7</priority>
+ </unreserved-bandwidth>
+ </ted>
+ </isis-link-attributes>
+ </igp-link-attributes>
+ </link>
+ <link>
+ <destination>
+ <dest-node>bgpls://IsisLevel2:1/type=node&as=65000&domain=673720360&router=0000.0000.0040</dest-node>
+ <dest-tp>bgpls://IsisLevel2:1/type=tp&ipv4=203.20.160.40</dest-tp>
+ </destination>
+ <link-id>bgpls://IsisLevel2:1/type=link&local-as=65000&local-domain=673720360&local-router=0000.0000.0039&remote-as=65000&remote-domain=673720360&remote-router=0000.0000.0040&ipv4-iface=203.20.160.39&ipv4-neigh=203.20.160.40</link-id>
+ <source>
+ <source-node>bgpls://IsisLevel2:1/type=node&as=65000&domain=673720360&router=0000.0000.0039</source-node>
+ <source-tp>bgpls://IsisLevel2:1/type=tp&ipv4=203.20.160.39</source-tp>
+ </source>
+ <igp-link-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology">
+ <metric>10</metric>
+ <isis-link-attributes xmlns="urn:TBD:params:xml:ns:yang:network:isis-topology">
+ <ted>
+ <color>0</color>
+ <max-link-bandwidth>1250000.0</max-link-bandwidth>
+ <max-resv-link-bandwidth>12500.0</max-resv-link-bandwidth>
+ <te-default-metric>0</te-default-metric>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>0</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>1</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>2</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>3</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>4</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>5</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>6</priority>
+ </unreserved-bandwidth>
+ <unreserved-bandwidth>
+ <bandwidth>12500.0</bandwidth>
+ <priority>7</priority>
+ </unreserved-bandwidth>
+ </ted>
+ </isis-link-attributes>
+ </igp-link-attributes>
+ </link>
+ </topology>
+
+BGP Network Topology Configuration Loader
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+BGP Network Topology Configuration Loader allows user to define static initial configuration for a BGP protocol instance.
+This service will detect the creation of new configuration files following the pattern "network-topology-*.xml" under the path "etc/opendaylight/bgp".
+Once the file is processed, the defined configuration will be available from the configuration Data Store.
+
+.. note:: If the BGP topology instance is already present, no update or configuration will be applied.
+
+When installing BGP an example will be provided and a default configuration loaded.
+
+**PATH:** ``etc/opendaylight/bgp/network-topology-config.xml``
+
+.. code-block:: xml
+
+ <network-topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
+ <topology>
+ <topology-id>example-ipv4-topology</topology-id>
+ <topology-types>
+ <bgp-ipv4-reachability-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"/>
+ </topology-types>
+ <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-config">example-bgp-rib</rib-id>
+ </topology>
+ <topology>
+ <topology-id>example-ipv6-topology</topology-id>
+ <topology-types>
+ <bgp-ipv6-reachability-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"/>
+ </topology-types>
+ <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-config">example-bgp-rib</rib-id>
+ </topology>
+ <topology>
+ <topology-id>example-linkstate-topology</topology-id>
+ <topology-types>
+ <bgp-linkstate-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"/>
+ </topology-types>
+ <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-config">example-bgp-rib</rib-id>
+ </topology>
+ </network-topology>
+
+Test Tools
+----------
+BGP test tools serves to test basic BGP functionality, scalability and performance.
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+BGP Test Tool
+^^^^^^^^^^^^^
+The BGP Test Tool is a stand-alone Java application purposed to simulate remote BGP peers, that are capable to advertise sample routes.
+This application is not part of the OpenDaylight Karaf distribution, however it can be downloaded from OpenDaylight's Nexus (use latest release version):
+
+``https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/bgpcep/bgp-testtool``
+
+Usage
+'''''
+The application can be run from command line:
+
+.. code-block:: console
+
+ java -jar bgp-testtool-*-executable.jar
+
+
+with optional input parameters:
+
+.. code-block:: console
+
+ -i <BOOLEAN>, --active <BOOLEAN>
+ Active initialisation of the connection, by default false.
+
+ -ho <N>, --holdtimer <N>
+ In seconds, value of the desired holdtimer, by default 90.
+
+ -sc <N>, --speakersCount <N>
+ Number of simulated BGP speakers, when creating each speaker, uses incremented local-address for binding, by default 0.
+
+ -ra <IP_ADDRESS:PORT,...>, --remoteAddress <IP_ADDRESS:PORT,...>
+ A list of IP addresses of remote BGP peers, that the tool can accept or initiate connect to that address (based on the mode), by default 192.0.2.2:1790.
+
+ -la <IP_ADDRESS:PORT>, --localAddress <IP_ADDRESS:PORT>
+ IP address of BGP speakers which the tools simulates, by default 192.0.2.2:0.
+
+ -pr <N>, --prefixes <N>
+ Number of prefixes to be advertised by each simulated speaker
+
+ -mp <BOOLEAN>, --multiPathSupport <BOOLEAN>
+ Active ADD-PATH support, by default false.
+
+ -as <N>, --as <N>
+ Local AS Number, by default 64496.
+
+ -ec <EXTENDED_COMMUNITIES>, --extended_communities <EXTENDED_COMMUNITIES>
+ Extended communities to be send. Format: x,x,x where x is each extended community from bgp-types.yang, by default empty.
+
+ -ll <LOG_LEVEL>, --log_level <LOG_LEVEL>
+ Log level for console output, by default INFO.
+
+BGP Application Peer Benchmark
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+It is a simple OpenDaylight application which is capable to inject and remove specific amount of IPv4 routes.
+This application is part of the OpenDaylight Karaf distribution.
+
+Configuration
+'''''''''''''
+As a first step install BGP, RESTCONF and NETCONF connector plugin, then configure *Application Peer*.
+Install ``odl-bgpcep-bgp-benchmark`` feature and reconfigure BGP Application Peer Benchmark application as per following:
+
+**URL:** ``/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-bgp-benchmark-cfg:app-peer-benchmark/bgp-app-peer-benchmark``
+
+**Method:** ``PUT``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 12
+
+ <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:odl-bgp-benchmark-cfg">x:app-peer-benchmark</type>
+ <name>bgp-app-peer-benchmark</name>
+ <binding-data-broker xmlns="urn:opendaylight:params:xml:ns:yang:controller:odl-bgp-benchmark-cfg">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">x:binding-async-data-broker</type>
+ <name>pingpong-binding-data-broker</name>
+ </binding-data-broker>
+ <rpc-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:odl-bgp-benchmark-cfg">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">x:binding-rpc-registry</type>
+ <name>binding-rpc-broker</name>
+ </rpc-registry>
+ <app-rib-id xmlns="urn:opendaylight:params:xml:ns:yang:controller:odl-bgp-benchmark-cfg">10.25.1.9</app-rib-id>
+ </module>
+
+@line 12: The *Application Peer* identifier.
+
+.. warning:: This configuration will be moved to configuration datastore in Carbon release.
+
+Inject routes
+'''''''''''''
+Routes injection can be invoked via RPC:
+
+**URL:** ``/restconf/operations/odl-bgp-app-peer-benchmark:add-prefix``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 2,3,4,5
+
+ <input xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-app-peer-benchmark">
+ <prefix>1.1.1.1/32</prefix>
+ <count>100000</count>
+ <batchsize>2000</batchsize>
+ <nexthop>192.0.2.2</nexthop>
+ </input>
+
+@line 2: A initial IPv4 prefix carried in route. Value is incremented for following routes.
+
+@line 3: An amount of routes to be added to *Application Peer's* programmable RIB.
+
+@line 4: A size of the transaction batch.
+
+@line 5: A NEXT_HOP attribute value used in all injected routes.
+
+**Response Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 3,4,5
+
+ <output xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-app-peer-benchmark">
+ <result>
+ <duration>4301</duration>
+ <rate>25000</rate>
+ <count>100000</count>
+ </result>
+ </output>
+
+@line 3: Request duration in milliseconds.
+
+@line 4: Writes per second rate.
+
+@line 5: An amount of routes added to *Application Peer's* programmable RIB.
+
+Remove routes
+'''''''''''''
+Routes deletion can be invoked via RPC:
+
+**URL:** ``/restconf/operations/odl-bgp-app-peer-benchmark:delete-prefix``
+
+**Method:** ``POST``
+
+**Content-Type:** ``application/xml``
+
+**Request Body:**
+
+.. code-block:: xml
+ :linenos:
+ :emphasize-lines: 2,3,4
+
+ <input xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-app-peer-benchmark">
+ <prefix>1.1.1.1/32</prefix>
+ <count>100000</count>
+ <batchsize>2000</batchsize>
+ </input>
+
+@line 2: A initial IPv4 prefix carried in route to be removed. Value is incremented for following routes.
+
+@line 3: An amount of routes to be removed from *Application Peer's* programmable RIB.
+
+@line 4: A size of the transaction batch.
+
+**Response Body:**
+
+.. code-block:: xml
+
+ <output xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-app-peer-benchmark">
+ <result>
+ <duration>1837</duration>
+ <rate>54500</rate>
+ <count>100000</count>
+ </result>
+ </output>
+
+Troubleshooting
+---------------
+This section offers advices in a case OpenDaylight BGP plugin is not working as expected.
+
+.. contents:: Contents
+ :depth: 2
+ :local:
+
+BGP is not working...
+^^^^^^^^^^^^^^^^^^^^^
+* First of all, ensure that all required features are installed, local and remote BGP configuration is correct.
+
+* Check OpenDaylight Karaf logs:
+
+From Karaf console:
+
+.. code-block:: console
+
+ log:tail
+
+or open log file: ``data/log/karaf.log``
+
+Possibly, a reason/hint for a cause of the problem can be found there.
+
+* Try to minimise effect of other OpenDaylight features, when searching for a reason of the problem.
+
+* Try to set DEBUG severity level for BGP logger via Karaf console commands, in order to collect more information:
+
+.. code-block:: console
+
+ log:set DEBUG org.opendaylight.protocol.bgp
+
+.. code-block:: console
+
+ log:set DEBUG org.opendaylight.bgpcep.bgp
+
+Bug reporting
+^^^^^^^^^^^^^
+Before you report a bug, check `BGPCEP Bugzilla <https://bugs.opendaylight.org/buglist.cgi?list_id=65849&product=bgpcep&resolution=--->`_ to ensure same/similar bug is not already filed there.
+
+Write an e-mail to bgpcep-users@lists.opendaylight.org and provide following information:
+
+#. State OpenDaylight version
+
+#. Describe your use-case and provide as much details related to BGP as possible
-**Add route:**
-
-**URL:**
-http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes
-
-**Method:** POST
-
-**Content-Type:** application/xml
-
-.. code:: xml
-
- <flowspec-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
- <route-key>flow-v6</route-key>
- <flowspec>
- <destination-prefix>2001:db8:30::3/128</destination-prefix>
- </flowspec>
- <flowspec>
- <source-prefix>2001:db8:31::3/128</source-prefix>
- </flowspec>
- <flowspec>
- <flow-label>
- <op>equals end-of-list</op>
- <value>1</value>
- </flow-label>
- </flowspec>
- <attributes>
- <extended-communities>
- <redirect-ipv6>
- <global-administrator>2001:db8:1::6</global-administrator>
- <local-administrator>12345</local-administrator>
- </redirect-ipv6>
- </extended-communities>
- <origin>
- <value>igp</value>
- </origin>
- <as-path/>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- </attributes>
- </flowspec-route>
-
-The request results in **204 No content**. This is expected.
-
-**Delete route:**
-
-**URL:**
-`http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes/bgp-flowspec:flowspec-route/<route-id> <http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes/bgp-flowspec:flowspec-route/<route-id>>`__
-
-**Method:** DELETE
+#. Steps to reproduce
+#. Attach Karaf log files, optionally packet captures, REST input/output
\ No newline at end of file
Run REST GET command to verify the device details:
--------------------------------------------------
-`http://<CONTROLLER-IP:8181>/restconf/operational/opendaylight-inventory:nodes <http://<CONTROLLER-IP:8181>/restconf/operational/opendaylight-inventory:nodes>`__
+http://<CONTROLLER-IP:8181>/restconf/operational/opendaylight-inventory:nodes
Run REST adjust-flow command to adjust flows and push to the device
-------------------------------------------------------------------
output in the REST output container. Here is the REST API to adjust and
push flows to HP 3800 device:
-`http://<CONTROLLER-IP:8181>/restconf/operations/openflow-feature:adjust-flow <http://<CONTROLLER-IP:8181>/restconf/operations/openflow-feature:adjust-flow>`__
+http://<CONTROLLER-IP:8181>/restconf/operations/openflow-feature:adjust-flow
FlowObjectives API
------------------
Filter Objective
~~~~~~~~~~~~~~~~
-`http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter <http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter>`__
+http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter
Next Objective
~~~~~~~~~~~~~~
-`http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next <http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next>`__
+http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next
Forward Objective
~~~~~~~~~~~~~~~~~
-`http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward <http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward>`__
+http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward
- To an optical network: The port maybe *abstract*, yet the optical
wavelength is *concrete*.
- **Note**
+.. note::
*This is a very domain specific analogy, tied to something most
readers will understand. It in no way implies the **GBP** should be
resolution process.
.. figure:: ./images/groupbasedpolicy/GBPTerminology1.png
- :alt: GBP Access Model Terminology - Endpoints, EndpointGroups,
- Contract
+ :alt: GBP Access Model Terminology - Endpoints, EndpointGroups, Contract
GBP Access Model Terminology - Endpoints, EndpointGroups, Contract
GBP Access Model Terminology - Subject, Classifier, Action
.. figure:: ./images/groupbasedpolicy/GBPTerminology3.png
- :alt: GBP Forwarding Model Terminology - L3 Context, L2 Bridge
- Context, L2 Flood Context/Domain, Subnet
+ :alt: GBP Forwarding Model Terminology - L3 Context, L2 Bridge Context, L2 Flood Context/Domain, Subnet
GBP Forwarding Model Terminology - L3 Context, L2 Bridge Context, L2
Flood Context/Domain, Subnet
Architecture and Value Proposition
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-**GBP** offers an intent based interface, accessed via the `UX <#UX>`__,
+**GBP** offers an intent based interface, accessed via the :ref:`UX <gbp-ux>`,
via the `REST API <#REST>`__ or directly from a domain-specific-language
-such as `Neutron <#Neutron>`__ through a mapping interface.
+such as :ref:`Neutron <gbp-neutron>` through a mapping interface.
There are two models in **GBP**:
The *classifier* and *action* portions of the model can be thought of as
hooks, with their definition provided by each *renderer* about its
domain specific capabilities. In **GBP** for this release, there is one
-renderer, the *`OpenFlow Overlay renderer (OfOverlay). <#OfOverlay>`__*
+renderer, the :ref:`OpenFlow Overlay renderer (OfOverlay). <gbp-of-overlay>`
These hooks are filled with *definitions* of the types of *features* the
renderer can provide the *subject*, and are called
High-level implementation Architecture
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The overall architecture, including *`Neutron <#Neutron>`__* domain
-specific mapping, and the `OpenFlow Overlay renderer <#OfOverlay>`__
+The overall architecture, including :ref:`Neutron <gbp-neutron>` domain
+specific mapping, and the :ref:`OpenFlow Overlay renderer <gbp-of-overlay>`
looks as so:
.. figure:: ./images/groupbasedpolicy/GBP_High-levelBerylliumArchitecture.png
domain-specific-language is completely separate and independent of the
underlying renderer implementation.
-For instance, using the `Neutron Mapper <#Neutron>`__, which maps the
+For instance, using the :ref:`Neutron Mapper <gbp-neutron>`, which maps the
Neutron API to the **GBP** core model, any contract automatically
-generated from this mapping can be augmented via the `UX <#UX>`__ to use
-`Service Function Chaining <#SFC>`__, a capability not currently
+generated from this mapping can be augmented via the :ref:`UX <gbp-ux>` to use
+:ref:`Service Function Chaining <gbp-sfc>`, a capability not currently
available in OpenStack Neutron.
When another renderer is added, for instance, NetConf, the same policy
particular cookie. Actions are specific actions that need to be taken on
the traffic before it reaches its destination. Actions could include
tagging or encapsulating the traffic in some way, redirecting the
-traffic, or applying a `service function chain <#SFC>`__.
+traffic, or applying a :ref:`service function chain <gbp-sfc>`.
Rules, subjects, and actions have an *order* parameter, where a lower
order value means that a particular item will be applied first. All
purpose of matching. Otherwise, the label with the same name will
completely override the label from the parent.
+.. _gbp-ux:
+
Using the GBP UX interface
--------------------------
Below the select box are buttons which display Expressed or Delivered
policy of Governance section. In the bottom half of this section is
select box with list of renderers for select. There is currently only
-`OfOverlay <#OfOverlay>`__ renderer available.
+:ref:`OfOverlay <gbp-of-overlay>` renderer available.
Below the select box is Renderer configuration button, which switch the
app into the Policy expression view with Renderers section expanded for
By single-clicking on any contract or EPG, the data of actual selected
element will be shown in the right column below the menu. A Manage
button launches a display wizard window for managing configuration of
-items such as `Service Function Chaining <#SFC>`__.
+items such as :ref:`Service Function Chaining <gbp-sfc>`.
.. figure:: ./images/groupbasedpolicy/ui-3-governanceview-expressed.png
:alt: Expressed policy
Please see:
-- `Using the GBP OpenFlow Overlay (OfOverlay) renderer <#OfOverlay>`__
+- :ref:`gbp-of-overlay`
-- `Policy Resolution <#policyresolution>`__
+- `Policy Resolution`_
- `Forwarding Model <#forwarding>`__
It is recommended to use either:
-- `Neutron mapper <#Neutron>`__
+- `Neutron mapper <gbp-neutron>`
-- `the UX <#UX>`__
+- :ref:`the UX <gbp-ux>`
If the REST API must be used, and the above resources are not
sufficient:
- feature:install odl-dlux-yangui
- browse to:
- `http://<odl-controller>:8181/index.html <http://<odl-controller>:8181/index.html>`__
+ ``http://<odl-controller>:8181/index.html``
and select YangUI from the left menu.
to explore the various **GBP** REST options
+.. _gbp-neutron:
+
Using OpenStack with GBP
------------------------
REST calls from OpenStack Neutron are by the Neutron NorthBound project.
**GBP** provides the implementation of the `Neutron V2.0
-API <http://developer.openstack.org/api-ref-networking-v2.html>`__.
+API <http://developer.openstack.org/api-ref-networking-v2.html>`_.
Features
~~~~~~~~
**Neutron FloatingIP**
When associated with a Neutron Port, this leverages the
-`OfOverlay <#OfOverlay>`__ renderer’s NAT capabilities.
+:ref:`OfOverlay <gbp-of-overlay>` renderer’s NAT capabilities.
A dedicated *external* interface on each Nova compute host allows for
disitributed external access. Each Nova instance associated with a
Assuming the gateway provisioned in the Neutron Subnet command for the
external network is reachable, the combination of **GBP** Neutron Mapper
-and `OfOverlay renderer <#OfOverlay>`__ will automatically ARP for this
+and :ref:`OfOverlay renderer <gbp-of-overlay>` will automatically ARP for this
default gateway, requiring no user intervention.
**Troubleshooting within GBP**
No intervention passed initial OpenStack setup is required by the user.
More information about configuration can be found in our DevStack demo
-environment on the `**GBP**
-wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`__.
+environment on the `GBP
+wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`_.
Administering or Managing GBP Neutron
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For consistencies sake, all provisioning should be performed via the
Neutron API. (CLI or Horizon).
-The mapped policies can be augmented via the **GBP** `UX <#UX>`__, to:
+The mapped policies can be augmented via the **GBP** :ref:`UX <gbp-ux>`, to:
-- Enable `Service Function Chaining <#SFC>`__
+- Enable :ref:`Service Function Chaining <gbp-sfc>`
- Add endpoints from outside of Neutron i.e. VMs/containers not
provisioned in OpenStack
Tutorials
~~~~~~~~~
-A DevStack demo environment can be found on the `**GBP**
-wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`__.
+A DevStack demo environment can be found on the `GBP
+wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`_.
GBP Renderer manager
--------------------
Similarly, when a Location provider is deleted, information of its locations
is removed from the OPER data store.
+.. _gbp-of-overlay:
+
Using the GBP OpenFlow Overlay (OfOverlay) renderer
---------------------------------------------------
This renderer is designed to work with OpenVSwitch (OVS) 2.1+ (although
2.3 is strongly recommended) and OpenFlow 1.3.
-When used in conjunction with the `Neutron Mapper feature <#Neutron>`__
+When used in conjunction with the :ref:`Neutron Mapper feature <gbp-neutron>`
no extra OfOverlay specific setup is required.
When this feature is loaded "standalone", the user is required to
- and creating the VXLAN/VXLAN-GPE tunnel ports on the bridges.
+.. _gbp-offset:
+
The **GBP** OfOverlay renderer also supports a table offset option, to
offset the pipeline post-table 0. The value of table offset is stored in
the config datastore and it may be rewritten at runtime.
Policy resolution is completely domain independent, and the OfOverlay
leverages process policy information internally. See `Policy Resolution
-process <#policyresolution>`__.
+process <Policy Resolution>`_.
It listens to inputs to the *Tenants* configuration datastore, validates
tenant input, then writes this to the Tenants operational datastore.
The endpoint repository operates in **orchestrated** mode. This means
the user is responsible for the provisioning of endpoints via:
-- `UX/GUI <#UX>`__
+- :ref:`UX/GUI <gbp-ux>`
- REST API
- **Note**
+.. note::
- When using the `Neutron mapper <#Neutron>`__ feature, everything is
+ When using the :ref:`Neutron mapper <gbp-neutron>` feature, everything is
managed transparently via Neutron.
The Endpoint Manager is responsible for listening to Endpoint repository
**Ingress NAT Mapper**
-Table `*offset* <#offset>`__\ +1.
+Table :ref:`offset <gbp-offset>` +1.
ARP responder for external NAT address:
**Source Mapper**
-Table `*offset* <#offset>`__\ +2.
+Table :ref:`offset <gbp-offset>` +2.
Determines based on characteristics from the ingress port, which:
**Destination Mapper**
-Table `*offset* <#offset>`__\ +3.
+Table :ref:`offset <gbp-offset>` +3.
Determines based on characteristics of the endpoint:
**Policy Enforcer**
-Table `*offset* <#offset>`__\ +4.
+Table :ref:`offset <gbp-offset>` +4.
Once the Source and Destination EndpointGroups are assigned, policy is
enforced based on resolved rules.
-In the case of `Service Function Chaining <#SFC>`__, the encapsulation
+In the case of :ref:`Service Function Chaining <gbp-sfc>`, the encapsulation
and destination for traffic destined to a chain, is discovered and
enforced.
**Egress NAT Mapper**
-Table `*offset* <#offset>`__\ +5.
+Table :ref:`offset <gbp-offset>` +5.
Performs NAT function before Egressing OVS instance to the underlay
network.
**External Mapper**
-Table `*offset* <#offset>`__\ +6.
+Table :ref:`offset <gbp-offset>` +6.
Manages post-policy enforcement for endpoint specific destination
-effects. Specifically for `Service Function Chaining <#SFC>`__, which is
+effects. Specifically for :ref:`Service Function Chaining <gbp-sfc>`, which is
why we can support both symmetric and asymmetric chains and distributed
ingress/egress classification.
Configuring OpenFlow Overlay via REST
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- **Note**
+.. note::
- Please see the `UX <#UX>`__ section on how to configure **GBP** via
+ Please see the :ref:`UX <gbp-ux>` section on how to configure **GBP** via
the GUI.
**Endpoint**
}
}
- **Note**
+.. note::
The usage of "port-name" preceded by "ofoverlay". In OpenDaylight,
base datastore objects can be *augmented*. In **GBP**, the base
}
}
-**Tenants** see `Policy Resolution <#policyresolution>`__ and
+**Tenants** see `Policy Resolution`_ and
`Forwarding Model <#forwarding>`__ for details:
::
~~~~~~~~~
Comprehensive tutorials, along with a demonstration environment
-leveraging Vagrant can be found on the `**GBP**
+leveraging Vagrant can be found on the `GBP
wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`__
Using the GBP eBPF IO Visor Agent renderer
feature:install odl-groupbasedpolicy-iovisor odl-restconf
Installation details, usage, and other information for the IO Visor GBP
-module can be found here: `**IO Visor** github repo for IO
-Modules <https://github.com/iovisor/iomodules>`__
+module can be found here: `IO Visor github repo for IO
+Modules <https://github.com/iovisor/iomodules>`_
Using the GBP FaaS renderer
---------------------------
More information about FaaS can be found here:
https://wiki.opendaylight.org/view/FaaS:GBPIntegration
+.. _gbp-sfc:
+
Using Service Function Chaining (SFC) with GBP Neutron Mapper and OfOverlay
---------------------------------------------------------------------------
This takes the form of an *action* in **GBP**.
-Using the `**GBP** demo and development environment <#demo>`__ as an
+Using the `GBP demo and development environment <#demo>`__ as an
example:
.. figure:: ./images/groupbasedpolicy/sfc-1-topology.png
- DevStack based GBP+Neutron integration Vagrant environment
`Demo @ GBP
-wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Consumability/Demo>`__
+wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Consumability/Demo>`_
advanced SDN and NFV use cases.
LISP data plane Tunnel Routers are available at
-`LISPmob.org <http://LISPmob.org/>`__ in the open source community on
+`OpenOverlayRouter.org <http://www.openoverlayrouter.org/>`__ in the open source community on
the following platforms:
- Linux
- OpenWRT
For more details and support for LISP data plane software please visit
-`the LISPmob web site <http://LISPmob.org/>`__.
+`the OOR web site <http://www.openoverlayrouter.org/>`__.
LISP Flow Mapping Service
~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
This section provides instructions to set up a LISP network of three
-nodes (one "client" node and two "server" nodes) using LISPmob as data
+nodes (one "client" node and two "server" nodes) using OOR as data
plane LISP nodes and the LISP Flow Mapping project from OpenDaylight as
the LISP programmable mapping system for the LISP network.
running the ODL instance, and ``restconfPort`` to 8181, if you didn’t
modify the default controller settings.
-- **LISPmob version 0.5.x** The README.md lists the dependencies needed
+- **OOR version 1.0 or later** The README.md lists the dependencies needed
to build it from source.
- **A virtualization platform**
+==========================+==========================+==========================+
| **controller** | OpenDaylight | 192.168.16.11 |
+--------------------------+--------------------------+--------------------------+
-| **client** | LISPmob | 192.168.16.30 |
+| **client** | OOR | 192.168.16.30 |
+--------------------------+--------------------------+--------------------------+
-| **server1** | LISPmob | 192.168.16.31 |
+| **server1** | OOR | 192.168.16.31 |
+--------------------------+--------------------------+--------------------------+
-| **server2** | LISPmob | 192.168.16.32 |
+| **server2** | OOR | 192.168.16.32 |
+--------------------------+--------------------------+--------------------------+
-| **service-node** | LISPmob | 192.168.16.33 |
+| **service-node** | OOR | 192.168.16.33 |
+--------------------------+--------------------------+--------------------------+
Table: Nodes in the tutorial
+The figure below gives a sketch of network topology that will be used in the tutorial.
+
+.. figure:: ./images/tutorial_architecture_diagram.png
+ :alt: Network architecture of the tutorial
+
+In LISP terminology **client**, **server1** and **server2** are mobile nodes (MN in OOR),
+**controller** is a MS/MR and **service-node** is a RTR.
+
.. note::
- While the tutorial uses LISPmob as the data plane, it could be any
+ While the tutorial uses OOR as the data plane, it could be any
LISP-enabled hardware or software router (commercial/open source).
Instructions
Karaf console to see when the log output is winding down, and
continue with the tutorial after that.
-2. Install LISPmob on the **client**, **server1**, **server2**, and
+2. Install OOR on the **client**, **server1**, **server2**, and
**service-node** VMs following the installation instructions `from
- the LISPmob README
- file <https://github.com/LISPmob/lispmob#software-prerequisites>`__.
-
-3. Configure the LISPmob installations from the previous step. Starting
- from the ``lispd.conf.example`` file in the distribution, set the
- EID in each ``lispd.conf`` file from the IP address space selected
+ the OOR README
+ file <https://github.com/OpenOverlayRouter/oor#software-prerequisites>`__.
+
+3. Configure the OOR installations from the previous step. Take a look
+ at the ``oor.conf.example`` to get a general idea of the structure
+ of the conf file. First, check if the file ``/etc/oor.conf`` exists.
+ If the file doesn't exist, create the file ``/etc/oor.conf``. Set the
+ EID in ``/etc/oor.conf`` file from the IP address space selected
for your virtual/LISP network. In this tutorial the EID of the
**client** is set to 1.1.1.1/32, and that of **server1** and
**server2** to 2.2.2.2/32.
-4. Set the RLOC interface to ``eth1`` in each ``lispd.conf`` file. LISP
+4. Set the RLOC interface to ``eth1`` in each ``oor.conf`` file. LISP
will determine the RLOC (IP address of the corresponding VM) based
on this interface.
that it doesn’t interfere with the mappings on the controller, since
we’re going to program them manually.
-6. Modify the "key" parameter in each ``lispd.conf`` file to a
+6. Modify the "key" parameter in each ``oor.conf`` file to a
key/password of your choice (*password* in this tutorial).
.. note::
The ``resources/tutorial`` directory in the *stable/boron*
branch of the project git repository has the files used in the
tutorial `checked
- in <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial;hb=refs/heads/stable/boron>`__,
- so you can just copy the files to ``/root/lispd.conf`` on the
+ in <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial;hb=refs/heads/master>`__,
+ so you can just copy the files to ``/etc/oor.conf`` on the
respective VMs. You will also find the JSON files referenced
below in the same directory.
]
}
-9. Run the ``lispd`` LISPmob daemon on all VMs:
+9. Run the ``oor`` OOR daemon on all VMs:
::
- lispd -f /root/lispd.conf
+ oor -f /etc/oor.conf
-10. The **client** LISPmob node should now register its EID-to-RLOC
+ For more information on accessing OOR logs, take a look at
+ `OOR README <https://github.com/OpenOverlayRouter/oor#readme>`__
+10. The **client** OOR node should now register its EID-to-RLOC
mapping in OpenDaylight. To verify you can lookup the corresponding
EIDs via the REST API
After the mapping for 2.2.2.2/32 is updated with the above, the ICMP
traffic from **client** to **server1** will flow through the
- **service-node**. You can confirm this in the LISPmob logs, or by
+ **service-node**. You can confirm this in the OOR logs, or by
sniffing the traffic on either the **service-node** or **server1**.
Note that service chains are unidirectional, so unless another ELP
mapping is added for the return traffic, packets will go from
The ping from the **client** should now have stopped.
In this case the ACL is done on the destination RLOC. There is an
- effort underway in the LISPmob community to allow filtering on EIDs,
+ effort underway in the OOR community to allow filtering on EIDs,
which is the more logical place to apply ACLs.
17. To delete the rule and restore connectivity on the service chain,
data/RPC/notifications described by a YANG model that is implemented by
the device.**
- **Tip**
+.. tip::
NETCONF southbound can be activated by installing
``odl-netconf-connector-all`` Karaf feature.
**For such devices you only need to put the schema into folder
cache/schema inside your Karaf distribution.**
- **Important**
+.. important::
The file with YANG schema for ietf-inet-types has to be called
ietf-inet-types@2010-09-24.yang. It is the required naming format of
new NETCONF connectors both through the NETCONF server for MD-SAL (port
2830) or RESTCONF. This guide focuses on RESTCONF.
- **Tip**
+.. tip::
To enable NETCONF connector configuration through MD-SAL install
either the ``odl-netconf-topology`` or
To spawn NETCONF connectors that are cluster-aware you need to install
the ``odl-netconf-clustered-topology`` karaf feature.
- **Warning**
+.. warning::
The ``odl-netconf-topology`` and ``odl-netconf-clustered-topology``
features are considered **INCOMPATIBLE**. They both manage the same
Should return 200 response code with no body.
- **Tip**
+.. tip::
This call is transformed into a couple of NETCONF RPCs. Resulting
NETCONF RPCs that go directly to the device can be found in the
Notifications over NETCONF are not supported in the Boron release.
- **Tip**
+.. tip::
Install NETCONF northbound for MD-SAL by installing feature:
``odl-netconf-mdsal`` in karaf. Default binding port is **2830**.
These jars are part of OpenDaylight’s controller project and are built
from the NETCONF codebase in OpenDaylight.
- **Tip**
+.. tip::
Download testtool from OpenDaylight Nexus at:
https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.1.0-Boron/
- perf-client.jar - RESTCONF stress/performance measuring tool
- **Tip**
+.. tip::
Each executable tool provides help. Just invoke ``java -jar
<name-of-the-tool.jar> --help``
http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/17830-sim-device/yang-ext:mount/
- **Warning**
+.. warning::
Data will be mirrored in operational datastore only when using the
default simple datastore.
- Ongoing support and integration of the OpenFlow specification
-- The plugin should be implemented in an easily extensibile manner
+- The plugin should be implemented in an easily extensible manner
- Protocol verification activities will be performed on supported
OpenFlow specifications
^^^^^^^^
Coverage has been moved to a `GoogleDoc
-Spreadshee <https://docs.google.com/spreadsheet/ccc?key=0AtpUuSEP8OyMdHNTZjBoM0VjOE9BcGhHMzk3N19uamc&usp=sharing%23gid=2#gid=0>`__
+Spreadsheet <https://docs.google.com/spreadsheet/ccc?key=0AtpUuSEP8OyMdHNTZjBoM0VjOE9BcGhHMzk3N19uamc&usp=sharing%23gid=2#gid=0>`__
OF 1.3 Considerations
^^^^^^^^^^^^^^^^^^^^^
Tutorial / How-To
-----------------
+.. _ofp-running-new-plugin:
+
Running the controller with the new OpenFlow Plugin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Opendaylight Controller Plugin Options
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Run OpenDaylight controller with the new OpenFlow 1.0/1.3 plugin
-
-There are 2 ways. In integration project the plugin version is
-controlled by startup parameter. Or there is distribution build
-available directly in openflowplugin project.
-
-1. use **integration** project
-
- - download and unzip latest build from
- https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/0.2.2-SNAPSHOT/
-
- ::
-
- cd <extracted directory>/bin
- ./karaf
-
- - or clone and build **integration** project:
-
- ::
-
- git clone https://git.opendaylight.org/gerrit/p/integration.git
- cd integration/distributions/extra/karaf
- mvn clean install
- cd ./target/assembly/bin
-
- - and finally run
-
- ::
-
- ./karaf
-
-2. use **openflowplugin** project
-
- - download and unzip latest build from
- https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/openflowplugin/openflowplugin-karaf/0.1.0-SNAPSHOT/
-
- ::
-
- cd <extracted directory>/bin
- ./karaf
-
- - or clone and build **openflowplugin** project:
-
- ::
-
- git clone https://git.opendaylight.org/gerrit/p/openflowplugin.git
- cd openflowplugin
- mvn clean install
- cd ./distribution/karaf/target/assembly/bin/
-
- - or build whole distribution localy from folder distribution/karaf
-
- ::
-
- mvn clean install -DskipTests
-
- - and run
-
- ::
-
- ./karaf
-
**How to start**
There are all helium features (from features-openflowplugin) duplicated
http://<controller-ip>:8181/dlux/index.html
-**Run OpenDaylight controller with the old OpenFlow 1.0-only (old)
-plugin**
-
-There are 2 ways. In integration project the plugin version is
-controlled by startup parameter. Or there is distribution build
-available directly in controller project.
-
-1. use **integration/distributions/base** project
-
- - use the instructions from
- OpenDaylight\_OpenFlow\_Plugin::Running\_controller\_with\_the\_new\_OF\_plugin#To\_run\_the\_OpenDaylight\_controller\_with\_the\_new\_OpenFlow\_1.0/1.3\_(new)\_plugin[
- 1.0/1.3 plugin], but skip the plugin version parameter:
-
- ::
-
- ./run.sh
-
-2. use **controller/distribution/opendaylight** project
-
- - download and unzip latest build from
- https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/controller/distribution.opendaylight/
-
- ::
-
- cd opendaylight
-
- - or clone and build **controller** project:
-
- ::
-
- git clone https://git.opendaylight.org/gerrit/p/controller.git
- cd controller/opendaylight/distribution/opendaylight
- mvn clean install
- cd target/distribution.opendaylight-osgipackage/opendaylight
-
- - and finally run (there is no version specific option, because the
-
- 1.0/1.3 (new) plugin is not available here at all)
-
-**Give it a minute to come up :)**
-
OpenFlow 1.3 Enabled Software Switches / Environment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- You can setup the switch as per the instructions given on the
following URL
-```https://github.com/CPqD/ofsoftswitch13`` <https://github.com/CPqD/ofsoftswitch13>`__
+`https://github.com/CPqD/ofsoftswitch13 <https://github.com/CPqD/ofsoftswitch13>`__
- Fire following command to start the switch
sudo mn --topo single,3 --controller 'remote,ip=<your controller ip>,port=6653' --switch ovsk,protocols=OpenFlow13
+.. _ofp-e2e-inv:
+
End to End Inventory
~~~~~~~~~~~~~~~~~~~~
Learn End to End for Inventory
''''''''''''''''''''''''''''''
-`End to End
-Inventory <#odl-ofp-end-to-end-inventory_introduction-introduction>`__
+See :ref:`ofp-e2e-inv`
Check inventory
'''''''''''''''
-- Run mininet with support for OF 1.3 as described in `End to End
- Inventory <#odl-ofp-end-to-end-inventory_introduction-introduction>`__
+- Run mininet with support for OF 1.3 as described in :ref:`ofp-e2e-inv`
-- Make sure you see the openflow:1 node come up as described in `End to
- End
- Inventory <#odl-ofp-end-to-end-inventory_introduction-introduction>`__
+- Make sure you see the openflow:1 node come up as described in :ref:`ofp-e2e-inv`
Flow Strategy
'''''''''''''
- See your configured flow in POSTMAN with
- - URL `http://<controller <http://<controller>`__
- IP>:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/table/0/
+ - URL http://<controller IP>:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/table/0/
- GET
^^^^^^^^^^^^^
Examples for XML for various flow matches, instructions & actions can be
-found in following section `here <#odl-ofp-example-flows_overview>`__
+found in following section :ref:`here <ofp-example-flows>`.
End to End Topology
~~~~~~~~~~~~~~~~~~~
Basically, you will learn how to:
1. Run the Base/Virtualization/Service provider Edition with the new
- openflowplugin: `Running the controller with the new OpenFlow
- Plugin <#odl-ofp-running-controller-with-the-new-of-plugin_top>`__
+ openflowplugin: :ref:`Running the controller with the new OpenFlow
+ Plugin <ofp-running-new-plugin>`
-2. Start mininet to use OF 1.3: `OpenFlow 1.3 Enabled Software Switches
- / Environment <#odl-ofp-test-environment_top>`__
+2. Start mininet to use OF 1.3: :ref:`OpenFlow 1.3 Enabled Software Switches
+ / Environment <ofp-test-environment>`
3. Use RESTCONF to see the topology information.
- http://comments.gmane.org/gmane.linux.network.openvswitch.general/3251
For testing group feature please use for example
-`CPQD <#odl-ofp-end-to-end-inventory_introduction-introduction>`__
-virtual switch.
+CPQD virtual switch in the :ref:`ofp-e2e-inv` section.
Instructions
^^^^^^^^^^^^
Learn End to End for Inventory
''''''''''''''''''''''''''''''
-`End to End
-Inventory <#odl-ofp-end-to-end-inventory_introduction-introduction>`__
+:ref:`ofp-e2e-inv`
Check inventory
'''''''''''''''
-Run CPqD with support for OF 1.3 as described in `End to End
-Inventory <#odl-ofp-end-to-end-inventory_introduction-introduction>`__
+Run CPqD with support for OF 1.3 as described in :ref:`ofp-e2e-inv`
-Make sure you see the openflow:1 node come up as described in `End to
-End
-Inventory <#odl-ofp-end-to-end-inventory_introduction-introduction>`__
+Make sure you see the openflow:1 node come up as described in :ref:`ofp-e2e-inv`
Group Strategy
''''''''''''''
- See your configured group in POSTMAN with
- URL
- `http://<ip-address>:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/group/1 <http://<ip-address>:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/group/1>`__
+ http://<ip-address>:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/group/1
- GET
- See your operational group stats in POSTMAN with
- URL
- `http://<ip-address>:8080/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/group/1 <http://<ip-address>:8080/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/group/1>`__
+ http://<ip-address>:8080/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/group/1
- GET
Learn End to End for Inventory
''''''''''''''''''''''''''''''
-- `End to End
- Inventory <#odl-ofp-end-to-end-inventory_introduction-introduction>`__
+- :ref:`ofp-e2e-inv`
Check inventory
'''''''''''''''
-- Run mininet with support for OF 1.3 as described in `End to End
- Inventory <#odl-ofp-end-to-end-inventory_introduction-introduction>`__
+- Run mininet with support for OF 1.3 as described in :ref:`ofp-e2e-inv`
-- Make sure you see the openflow:1 node come up as described in `End to
- End
- Inventory <#odl-ofp-end-to-end-inventory_introduction-introduction>`__
+- Make sure you see the openflow:1 node come up as described in :ref:`ofp-e2e-inv`
Meter Strategy
''''''''''''''
be executed on the OSGI console testing various features in OpenFlow 1.3
spec.
-- `OSGI Console Test Provider Commands:
- Flows <#odl-ofp-test-provider-flows_test-provider>`__
+- :ref:`OSGI Console Test Provider Commands:
+ Flows <ofp-test-provider-flows>`
+
+- :ref:`OSGI Console Test Provider Commands:
+ Groups <ofp-test-provider-groups>`
-- `OSGI Console Test Provider Commands:
- Groups <#odl-ofp-test-provider-groups_test-provider>`__
+- :ref:`OSGI Console Test Provider Commands:
+ Meters <ofp-test-provider-meters>`
-- `OSGI Console Test Provider Commands:
- Meters <#odl-ofp-test-provider-meters_test-provider>`__
+- :ref:`OSGI Console Test Provider Commands: Topology
+ Events <ofp-test-provider-topology>`
-- `OSGI Console Test Provider Commands: Topology
- Events <#odl-ofp-test-provider-topoogy_test-provider>`__
+.. _ofp-test-provider-flows:
Flows : Test Provider
~~~~~~~~~~~~~~~~~~~~~
switch. The flow to be deleted should have same flowid and Nodeid as
used for flow add.
+.. _ofp-test-provider-groups:
+
Group : Test Provider
~~~~~~~~~~~~~~~~~~~~~
actiontype(a#). GroupId should be same as that used for adding the flow.
You can confirm that it was modified on the switch.
+.. _ofp-test-provider-meters:
+
Meters : Test Provider
~~~~~~~~~~~~~~~~~~~~~~
The CLI takes care of using the same meterId and nodeId as used for
meter add. You can confirm that it was modified on the switch.
+.. _ofp-test-provider-topology:
+
Topology : Notification
~~~~~~~~~~~~~~~~~~~~~~~
- `Models Documentation (OpenFlow Services
Section) <https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Model_Reference>`__
+.. _ofp-example-flows:
+
Example flows
-------------
The format of the XML that describes OpenFlow matches is determined by
the opendaylight-match-types yang model: .
-The RESTCONF documentation for the match-types yang model can be found
-at
-`opendaylight-match-types.html <https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/opendaylight/md-sal/model/model-flow-base/target/site/models/opendaylight-match-types.html>`__
-
IPv4 Dest Address
^^^^^^^^^^^^^^^^^
The format of the XML that describes OpenFlow actions is determined by
the opendaylight-action-types yang model: .
-The RESTCONF documentation for the match-types yang model can be found
-at
-`opendaylight-action-types.html <https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/opendaylight/md-sal/model/model-flow-base/target/site/models/opendaylight-action-types.html>`__
-
Apply Actions
^^^^^^^^^^^^^
Postman Operations
+
+
+PacketCable REST API Usage Examples
+-----------------------------------
+
+* CCAP "CONFIG" DATASTORE API STRUCTURE
+
+ * Add and view CCAPConfigDatastore(add triggers also the CCAP COPS connection)::
+
+ PUT http://localhost:8181/restconf/config/packetcable:ccaps/ccap/CMTS-1
+
+ {"ccap":[
+ {"ccapId":"CMTS-1",
+ "amId": {
+ "am-tag": 51930,
+ "am-type": 1
+ },
+ "connection": {
+ "ipAddress": "10.20.30.40",
+ "port":3918
+ },"subscriber-subnets": [
+ "2001:4978:030d:1000:0:0:0:0/52",
+ "44.137.0.0/16"
+ ],"upstream-scns": [
+ "SCNA",
+ "extrm_up"
+ ],"downstream-scns": [
+ "extrm_dn",
+ "ipvideo_dn",
+ "SCNC"
+ ]}
+ ]}
+
+ GET http://localhost:8181/restconf/config/packetcable:ccaps/ccap/CMTS-1
+
+
+* CCAP OPERATIONAL STATUS - GET CCAP (COPS) CONNECTION STATUS
+
+ * Shows the Operational Datastorecontents for the CCAP COPS connection.
+ * The status is updated when the COPS connection is initiated or after an RPC poll::
+
+ GET http://localhost:8181/restconf/operational/packetcable:ccaps/ccap/CMTS-1/
+ Response: 200 OK
+
+ {
+ "ccap": [
+ {
+ "ccapId": "CMTS-1",
+ "connection": {
+ "error": [
+ "E6-CTO: CCAP client is connected"
+ ],
+ "timestamp": "2016-03-23T14:15:54.129-05:00",
+ "connected": true
+ }
+ }
+ ]
+ }
+
+
+* CCAP OPERATIONAL STATUS - RPC CCAP POLL CONNECTION
+
+ * A CCAP RPC poll returns the COPS connectivity status info and also triggers an Operational Datastore status update with the same data::
+
+ POST http://localhost:8181/restconf/operations/packetcable:ccap-poll-connection
+ {
+ "input": {
+ "ccapId": "/packetcable:ccaps/packetcable:ccap[packetcable:ccapId='CMTS-1']"
+ }
+ }
+ Response: 200 OK
+ {
+ "output": {
+ "response": "CMTS-1: CCAP poll complete",
+ "timestamp": "2016-03-23T14:15:54.131-05:00",
+ "ccap": {
+ "ccapId": "CMTS-1",
+ "connection": {
+ "connection": {
+ "error": [
+ "CMTS-1: CCAP client is connected"
+ ],
+ "timestamp": "2016-03-23T14:15:54.129-05:00",
+ "connected": true
+ }
+ }
+ }
+ }
+ }
+
+* CCAP OPERATIONAL STATUS - RPC CCAP POLL CONNECTION (2) - CONNECTION DOWN::
+
+ POST http://localhost:8181/restconf/operations/packetcable:ccap-poll-connection
+ {
+ "input": {
+ "ccapId": "/packetcable:ccaps/packetcable:ccap[packetcable:ccapId='CMTS-1']"
+ }
+ }
+ Response: 200 OK
+ {
+ "output": {
+ "response": "CMTS-1: CCAP poll complete",
+ "timestamp": "2016-03-23T14:15:54.131-05:00",
+ "ccap": {
+ "ccapId": "CMTS-1",
+ "connection": {
+ "error": [
+ "CMTS-1: CCAP client is disconnected with error: null",
+ "CMTS-1: CCAP Cops socket is closed"],
+ "timestamp": "2016-03-23T14:15:54.129-05:00",
+ "connected": false
+ }
+ }
+ }
+ }
+
+
+* CCAP OPERATIONAL STATUS - RPC CCAP SET CONNECTION
+
+ * A CCAP RPC sets the CCAP COPS connection; possible values true or false meaning that the connection should be up or down.
+ * RPC responds with the same info as RPC POLL CONNECTION, and also updates the Operational Datastore::
+
+ POST http://localhost:8181/restconf/operations/packetcable:ccap-set-connection
+ {
+ "input": {
+ "ccapId": "/packetcable:ccaps/packetcable:ccap[packetcable:ccapId='CMTS-1']",
+ "connection": {
+ "connected": true
+ }
+ }
+ }
+ Response: 200 OK
+ {
+ "output": {
+
+ "response": "CMTS-1: CCAP set complete",
+ "timestamp": "2016-03-23T17:47:29.446-05:00",
+ "ccap": {
+ "ccapId": "CMTS-1",
+ "connection": {
+ "error": [
+ "CMTS-1: CCAP client is connected",
+ "CMTS-1: CCAP COPS socket is already open"],
+ "timestamp": "2016-03-23T17:47:29.436-05:00",
+ "connected": true
+ }
+ }
+ }
+ }
+
+* CCAP OPERATIONAL STATUS - RPC CCAP SET CONNECTION (2) - SHUTDOWN COPS CONNECTION::
+
+ POST http://localhost:8181/restconf/operations/packetcable:ccap-set-connection
+ {
+ "input": {
+ "ccapId": "/packetcable:ccaps/packetcable:ccap[packetcable:ccapId='E6-CTO']",
+ "connection": {
+ "connected": false
+ }
+ }
+ }
+ Response: 200 OK
+ {
+ "output": {
+ "response": "E6-CTO: CCAP set complete",
+ "timestamp": "2016-03-23T17:47:29.446-05:00",
+ "ccap": {
+ "ccapId": "E6-CTO",
+ "connection": {
+ "error": [
+ "E60CTO: CCAP client is disconnected with error: null"],
+ "timestamp": "2016-03-23T17:47:29.436-05:00",
+ "connected": false
+ }
+ }
+ }
+ }
+
+.. note::
+ A "null" in the error information means that the CCAP connection has been disconnected as a result of a RPC SET.
+
+* GATES "CONFIG" DATASTORE API STRUCTURE CHANGED
+
+ * A CCAP RPC poll returns the gate status info, and also triggers a Operational Datastorestatus update.
+ * At a minimum the appIdneeds to be included in the input, subscriberIdand gateIdare optional.
+ * A gate status response is only included if the RPC request is done for a specific gate (subscriberIdand gateIdincluded in input).
+ * Add and retrieve gates to/from the Config Datastore::
+
+ PUT http://localhost:8181/restconf/config/packetcable:qos/apps/app/cto-app/subscribers/subscriber/44.137.0.12/gates/gate/gate88/
+
+ {
+ "gate": [
+ {
+ "gateId": "gate88",
+ "gate0spec": {
+ "dscp-tos-overwrite": "0xa0",
+ "dscp-tos-mask": "0xff"
+ },
+ "traffic-profile": {
+ "service-class-name": "extrm_dn"
+ },
+ "classifiers": {
+ "classifier-container": [
+ {
+ "classifier-id": "1",
+ "classifier": {
+ "srcIp": "44.137.0.0",
+ "dstIp": "44.137.0.11",
+ "protocol": "0",
+ "srcPort": "1234",
+ "dstPort": "4321",
+ "tos-byte": "0xa0",
+ "tos-mask": "0xe0"
+ }
+ }
+ ]
+ }
+ }
+ ]
+ }
+
+ GET http://localhost:8181/restconf/config/packetcable:qos/apps/app/cto-app/subscribers/subscriber/44.137.0.12/gates/gate/gate88/
+
+
+* GATES SUPPORT MULTIPLE (UP TO FOUR) CLASSIFIERS
+
+ * Please note that there is a classifier container now that can have up to four classifiers::
+
+ PUT http://localhost:8181/restconf/config/packetcable:qos/apps/app/cto-app/subscribers/subscriber/44.137.0.12/gates/gate/gate88/
+ { "gate":{
+ "gateId": "gate44",
+ "gate-spec": {
+ "dscp-tos-overwrite": "0xa0",
+ "dscp-tos-mask": "0xff" },
+ "traffic-profile": {
+ "service-class-name": "extrm_dn"},
+ "classifiers":
+ { "classifier-container":[
+ { "classifier-id": "1",
+ "ipv6-classifier": {
+ "srcIp6": "2001:4978:030d:1100:0:0:0:0/64",
+ "dstIp6": "2001:4978:030d:1000:0:0:0:0/64",
+ "flow-label": "102",
+ "tc-low": "0xa0",
+ "tc-high": "0xc0",
+ "tc-mask": "0xe0",
+ "next-hdr": "256",
+ "srcPort-start": "4321",
+ "srcPort-end": "4322",
+ "dstPort-start": "1234",
+ "dstPort-end": "1235"
+ }},
+ { "classifier-id": "2",
+ "ext-classifier" : {
+ "srcIp": "44.137.0.12",
+ "srcIpMask": "255.255.255.255",
+ "dstIp": "10.10.10.0",
+ "dstIpMask": "255.255.255.0",
+ "tos-byte": "0xa0",
+ "tos-mask": "0xe0",
+ "protocol": "0",
+ "srcPort-start": "4321",
+ "srcPort-end": "4322",
+ "dstPort-start": "1234",
+ "dstPort-end": "1235"
+ }
+ }]
+ }
+ }
+ }
+
+
+* CCAP OPERATIONAL STATUS - GET GATE STATUS FROM OPERATIONAL DATASTORE
+
+ * Shows the Operational Datastore contents for the gate.
+ * The gate status is updated at the time when the gate is configured or during an RPC poll::
+
+ GET http://localhost:8181/restconf/operational/packetcable:qos/apps/app/cto-app/subscribers/subscriber/44.137.0.12/gates/gate/gate88
+
+ Response: 200
+ {
+ "gate":[{
+ "gateId":"gate88",
+ "cops-gate-usage-info": "0",
+ "cops-gate-state": "Committed(4)/Other(-1)",
+ "gatePath": "cto-app/44.137.0.12/gate88",
+ "cops-gate-time-info": "0",
+ "cops-gateId": "3e0800e9",
+ "timestamp": "2016-03-24T10:30:18.763-05:00",
+ "ccapId": "E6-CTO"
+ }]
+ }
+
+
+* CCAP OPERATIONAL STATUS - RPC GATE STATUS POLL
+
+ * A CCAP RPC poll returns the gate status info and also triggers an Operational Datastore status update.
+ * At a minimum, the appId needs to be included in the input; subscriberId and gateId are optional.
+ * A gate status response is only included if the RPC request is done for a specific gate (subscriberId and gateId included in input)::
+
+ POST http://localhost:8181/restconf/operations/packetcable:qos-poll-gates
+ {
+ "input": {
+ "appId": "/packetcable:apps/packetcable:apps[packetcable:appId='cto-app]",
+ "subscriberId": "44.137.0.11",
+ "gateId": "gate44"
+ }
+ }
+ Response: 200 OK
+ {
+ "output": {
+ "gate": {
+ "cops-gate-usage-info": "0",
+ "cops-gate-state": "Committed(4)/Other(-1)",
+ "gatePath": "ctoapp/44.137.0.12/gate88",
+ "cops-gate-time-info": "0",
+ "cops-gateId": "1ceb0001",
+ "error": [""],
+ "timestamp": "2016-03-24T13:22:59.900-05:00",
+ "ccapId": "E6-CTO"
+ },
+ "response": "cto-app/44.137.0.12/gate88: gate poll complete",
+ "timestamp": "2016-03-24T13:22:59.906-05:00"
+ }
+ }
+
+ * When multiple gates are polled (only appId or appId and subscriberId are provided), a generic response is returned and the Operational Datastore is updated in the background::
+
+ { "output": {
+ "gate": {},
+ "response": "cto-app/: gate subtree poll in progress",
+ "timestamp": "2016-03-24T13:25:30.471-05:00"
+ }
+ }
+
+
Service Function Chaining
=========================
-OpenDaylight Service Function Chaining (SFC) Overiew
-----------------------------------------------------
+OpenDaylight Service Function Chaining (SFC) Overview
+-----------------------------------------------------
OpenDaylight Service Function Chaining (SFC) provides the ability to
define an ordered list of a network services (e.g. firewalls, load
SFC User Interface (SFC-UI) is based on Dlux project. It provides an
easy way to create, read, update and delete configuration stored in
-Datastore. Moreover, it shows the status of all SFC features (e.g
+datastore. Moreover, it shows the status of all SFC features (e.g
installed, uninstalled) and Karaf log messages as well.
SFC-UI Architecture
1. Run ODL distribution (run karaf)
-2. In karaf console execute: ``feature:install odl-sfc-ui``
+2. In Karaf console execute: ``feature:install odl-sfc-ui``
3. Visit SFC-UI on: ``http://<odl_ip_address>:8181/sfc/index.html``
-SFC Southbound REST Plugin
+SFC Southbound REST Plug-in
--------------------------
Overview
~~~~~~~~
-The Southbound REST Plugin is used to send configuration from DataStore
+The Southbound REST Plug-in is used to send configuration from datastore
down to network devices supporting a REST API (i.e. they have a
configured REST URI). It supports POST/PUT/DELETE operations, which are
triggered accordingly by changes in the SFC data stores.
- Service Function Schedule Type (SFST)
-- Service Function Forwader (SFF)
+- Service Function Forwarder (SFF)
- Rendered Service Path (RSP)
-Southbound REST Plugin Architecture
+Southbound REST Plug-in Architecture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-From the user perspective, the REST plugin is another SFC Southbound
-plugin used to communicate with network devices.
+From the user perspective, the REST plug-in is another SFC Southbound
+plug-in used to communicate with network devices.
.. figure:: ./images/sfc/sb-rest-architecture-user.png
- :alt: Soutbound REST Plugin integration into ODL
+ :alt: Southbound REST Plug-in integration into ODL
- Soutbound REST Plugin integration into ODL
+ Southbound REST Plug-in integration into ODL
Configuring Southbound REST Plugin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Run ODL distribution (run karaf)
-2. In karaf console execute: ``feature:install odl-sfc-sb-rest``
+2. In Karaf console execute: ``feature:install odl-sfc-sb-rest``
3. Configure REST URIs for SF/SFF through SFC User Interface or RESTCONF
(required configuration steps can be found in the tutorial stated
Tutorial
~~~~~~~~
-Comprehensive tutorial on how to use the Southbound REST Plugin and how
+Comprehensive tutorial on how to use the Southbound REST Plug-in and how
to control network devices with it can be found on:
https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#SFC_101
Classifier, etc.) to OVS objects (like Bridge,
TerminationPoint=Port/Interface). The mapping takes care of automatic
instantiation (setup) of corresponding object whenever its counterpart
-is created. For example, when a new SFF is created, the SFC-OVS plugin
+is created. For example, when a new SFF is created, the SFC-OVS plug-in
will create a new OVS bridge and when a new OVS Bridge is created, the
-SFC-OVS plugin will create a new SFF.
+SFC-OVS plug-in will create a new SFF.
The feature is intended for SFC users willing to use Open vSwitch as
underlying network infrastructure for deploying RSPs (Rendered Service
SFC-OVS uses the OVSDB MD-SAL Southbound API for getting/writing
information from/to OVS devices. From the user perspective SFC-OVS acts
-as a layer between SFC DataStore and OVSDB.
+as a layer between SFC datastore and OVSDB.
.. figure:: ./images/sfc/sfc-ovs-architecture-user.png
:alt: SFC-OVS integration into ODL
1. Run ODL distribution (run karaf)
-2. In karaf console execute: ``feature:install odl-sfc-ovs``
+2. In Karaf console execute: ``feature:install odl-sfc-ovs``
3. Configure Open vSwitch to use ODL as a manager, using following
command: ``ovs-vsctl set-manager tcp:<odl_ip_address>:6640``
Overview
''''''''
-This tutorial shows the usual workflow when OVS configuration is
+This tutorial shows the usual work flow when OVS configuration is
transformed to corresponding SFC objects (in this case SFF).
-Prerequisities
+Prerequisites
''''''''''''''
- Open vSwitch installed (ovs-vsctl command available in shell)
This tutorial shows the usual workflow during creation of OVS Bridge
with use of SFC APIs.
-Prerequisities
+Prerequisites
''''''''''''''
- Open vSwitch installed (ovs-vsctl command available in shell)
2. SFF data plane locator must be configured
-3. Classifier interface must be mannually added to SFF bridge.
+3. Classifier interface must be manually added to SFF bridge.
Administering or Managing Classifier
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Rules are created using appropriate iptables command. If the Access
Control Entry (ACE) rule is MAC address related both iptables and
-ip6tabeles rules re issued. If ACE rule is IPv4 address related, only
+IPv6 tables rules re issued. If ACE rule is IPv4 address related, only
iptables rules are issued, same for IPv6.
.. note::
Administering or Managing Classifier
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Classfier runs alongside sfc\_agent, therefore the commad for starting
+Classifier runs alongside sfc\_agent, therefore the command for starting
it locally is:
::
assuming VLAN is used for the SFF-SF, and the other where the RSP
ingress tunnel is NSH GRE (UDP port 4789):
-+-------------+--------------------------------------+--------------------------+
-| Priority | Match | Action |
-+=============+======================================+==========================+
-| 256 | EtherType==0x8847 (MPLS unicast) | Goto Table 2 |
-+-------------+--------------------------------------+--------------------------+
-| 256 | EtherType==0x8100 (VLAN) | Goto Table 2 |
-+-------------+--------------------------------------+--------------------------+
-| 256 | EtherType==0x0800,udp,tp\_dst==4789 | Goto Table 2 |
-| | (IP v4) | |
-+-------------+--------------------------------------+--------------------------+
-| 5 | Match Any | Drop |
-+-------------+--------------------------------------+--------------------------+
++----------+-------------------------------------+--------------+
+| Priority | Match | Action |
++==========+=====================================+==============+
+| 256 | EtherType==0x8847 (MPLS unicast) | Goto Table 2 |
++----------+-------------------------------------+--------------+
+| 256 | EtherType==0x8100 (VLAN) | Goto Table 2 |
++----------+-------------------------------------+--------------+
+| 256 | EtherType==0x0800,udp,tp\_dst==4789 | Goto Table 2 |
+| | (IP v4) | |
++----------+-------------------------------------+--------------+
+| 5 | Match Any | Drop |
++----------+-------------------------------------+--------------+
Table: Table Transport Ingress
- The RSP Path 2 (symmetric downlink path) uses MPLS label 101 for
ingress and 100 for egress
-+--------------------------+--------------------------+--------------------------+
-| Priority | Match | Action |
-+==========================+==========================+==========================+
-| 256 | MPLS Label==100 | RSP Path=1, Pop MPLS, |
-| | | Goto Table 4 |
-+--------------------------+--------------------------+--------------------------+
-| 256 | MPLS Label==101 | RSP Path=2, Pop MPLS, |
-| | | Goto Table 4 |
-+--------------------------+--------------------------+--------------------------+
-| 256 | VLAN ID==1000, IP | RSP Path=1, Pop VLAN, |
-| | DSCP==1 | Goto Table 4 |
-+--------------------------+--------------------------+--------------------------+
-| 256 | VLAN ID==1000, IP | RSP Path=2, Pop VLAN, |
-| | DSCP==2 | Goto Table 4 |
-+--------------------------+--------------------------+--------------------------+
-| 5 | Match Any | Goto Table 3 |
-+--------------------------+--------------------------+--------------------------+
++----------+-------------------+-----------------------+
+| Priority | Match | Action |
++==========+===================+=======================+
+| 256 | MPLS Label==100 | RSP Path=1, Pop MPLS, |
+| | | Goto Table 4 |
++----------+-------------------+-----------------------+
+| 256 | MPLS Label==101 | RSP Path=2, Pop MPLS, |
+| | | Goto Table 4 |
++----------+-------------------+-----------------------+
+| 256 | VLAN ID==1000, IP | RSP Path=1, Pop VLAN, |
+| | DSCP==1 | Goto Table 4 |
++----------+-------------------+-----------------------+
+| 256 | VLAN ID==1000, IP | RSP Path=2, Pop VLAN, |
+| | DSCP==2 | Goto Table 4 |
++----------+-------------------+-----------------------+
+| 5 | Match Any | Goto Table 3 |
++----------+-------------------+-----------------------+
Table: Table Path Mapper
The Next Hop table uses the RSP Path Id and appropriate packet fields to
determine where to send the packet next. For NSH, only the NSP (Network
Services Path, RSP ID) and NSI (Network Services Index, next hop) fields
-from the NSH header are needed to determine the VXLAN tunnel destination
+from the NSH header are needed to determine the VxLAN tunnel destination
IP. For VLAN or MPLS, then the source MAC address is used to determine
the destination MAC address.
NSH paths. RSP Path 1 ingress packets come from external to SFC, for
which we don’t have the source MAC address (MacSrc).
-+------------+--------------------------------+--------------------------------+
-| Priority | Match | Action |
-+============+================================+================================+
-| 256 | RSP Path==1, MacSrc==SF1 | MacDst=SFF2, Goto Table 10 |
-+------------+--------------------------------+--------------------------------+
-| 256 | RSP Path==2, MacSrc==SF1 | Goto Table 10 |
-+------------+--------------------------------+--------------------------------+
-| 256 | RSP Path==2, MacSrc==SFF2 | MacDst=SF1, Goto Table 10 |
-+------------+--------------------------------+--------------------------------+
-| 246 | RSP Path==1 | MacDst=SF1, Goto Table 10 |
-+------------+--------------------------------+--------------------------------+
-| 256 | nsp=3,nsi=255 (SFF Ingress RSP | load:0xa000002→NXM\_NX\_TUN\_I |
-| | 3) | PV4\_DST[], |
-| | | Goto Table 10 |
-+------------+--------------------------------+--------------------------------+
-| 256 | nsp=3,nsi=254 (SFF Ingress | load:0xa00000a→NXM\_NX\_TUN\_I |
-| | from SF, RSP 3) | PV4\_DST[], |
-| | | Goto Table 10 |
-+------------+--------------------------------+--------------------------------+
-| 256 | nsp=4,nsi=254 (SFF1 Ingress | load:0xa00000a→NXM\_NX\_TUN\_I |
-| | from SFF2) | PV4\_DST[], |
-| | | Goto Table 10 |
-+------------+--------------------------------+--------------------------------+
-| 5 | Match Any | Drop |
-+------------+--------------------------------+--------------------------------+
++----------+--------------------------------+--------------------------------+
+| Priority | Match | Action |
++==========+================================+================================+
+| 256 | RSP Path==1, MacSrc==SF1 | MacDst=SFF2, Goto Table 10 |
++----------+--------------------------------+--------------------------------+
+| 256 | RSP Path==2, MacSrc==SF1 | Goto Table 10 |
++----------+--------------------------------+--------------------------------+
+| 256 | RSP Path==2, MacSrc==SFF2 | MacDst=SF1, Goto Table 10 |
++----------+--------------------------------+--------------------------------+
+| 246 | RSP Path==1 | MacDst=SF1, Goto Table 10 |
++----------+--------------------------------+--------------------------------+
+| 256 | nsp=3,nsi=255 (SFF Ingress RSP | load:0xa000002→NXM\_NX\_TUN\_I |
+| | 3) | PV4\_DST[], |
+| | | Goto Table 10 |
++----------+--------------------------------+--------------------------------+
+| 256 | nsp=3,nsi=254 (SFF Ingress | load:0xa00000a→NXM\_NX\_TUN\_I |
+| | from SF, RSP 3) | PV4\_DST[], |
+| | | Goto Table 10 |
++----------+--------------------------------+--------------------------------+
+| 256 | nsp=4,nsi=254 (SFF1 Ingress | load:0xa00000a→NXM\_NX\_TUN\_I |
+| | from SFF2) | PV4\_DST[], |
+| | | Goto Table 10 |
++----------+--------------------------------+--------------------------------+
+| 5 | Match Any | Drop |
++----------+--------------------------------+--------------------------------+
Table: Table Next Hop
Here are two examples on SFF1. RSP Paths 1 and 2 are symmetric MPLS
paths that use VLAN for the SFF-SF. RSP Paths 3 and 4 are symmetric NSH
paths. Since it is assumed that switches used for NSH will only have one
-VXLANport, the NSH packets are just sent back where they came from.
-
-+------------+--------------------------------+--------------------------------+
-| Priority | Match | Action |
-+============+================================+================================+
-| 256 | RSP Path==1, MacDst==SF1 | Push VLAN ID 1000, Port=SF1 |
-+------------+--------------------------------+--------------------------------+
-| 256 | RSP Path==1, MacDst==SFF2 | Push MPLS Label 101, Port=SFF2 |
-+------------+--------------------------------+--------------------------------+
-| 256 | RSP Path==2, MacDst==SF1 | Push VLAN ID 1000, Port=SF1 |
-+------------+--------------------------------+--------------------------------+
-| 246 | RSP Path==2 | Push MPLS Label 100, |
-| | | Port=Ingress |
-+------------+--------------------------------+--------------------------------+
-| 256 | nsp=3,nsi=255 (SFF Ingress RSP | IN\_PORT |
-| | 3) | |
-+------------+--------------------------------+--------------------------------+
-| 256 | nsp=3,nsi=254 (SFF Ingress | IN\_PORT |
-| | from SF, RSP 3) | |
-+------------+--------------------------------+--------------------------------+
-| 256 | nsp=4,nsi=254 (SFF1 Ingress | IN\_PORT |
-| | from SFF2) | |
-+------------+--------------------------------+--------------------------------+
-| 5 | Match Any | Drop |
-+------------+--------------------------------+--------------------------------+
+VXLAN port, the NSH packets are just sent back where they came from.
+
++----------+--------------------------------+--------------------------------+
+| Priority | Match | Action |
++==========+================================+================================+
+| 256 | RSP Path==1, MacDst==SF1 | Push VLAN ID 1000, Port=SF1 |
++----------+--------------------------------+--------------------------------+
+| 256 | RSP Path==1, MacDst==SFF2 | Push MPLS Label 101, Port=SFF2 |
++----------+--------------------------------+--------------------------------+
+| 256 | RSP Path==2, MacDst==SF1 | Push VLAN ID 1000, Port=SF1 |
++----------+--------------------------------+--------------------------------+
+| 246 | RSP Path==2 | Push MPLS Label 100, |
+| | | Port=Ingress |
++----------+--------------------------------+--------------------------------+
+| 256 | nsp=3,nsi=255 (SFF Ingress RSP | IN\_PORT |
+| | 3) | |
++----------+--------------------------------+--------------------------------+
+| 256 | nsp=3,nsi=254 (SFF Ingress | IN\_PORT |
+| | from SF, RSP 3) | |
++----------+--------------------------------+--------------------------------+
+| 256 | nsp=4,nsi=254 (SFF1 Ingress | IN\_PORT |
+| | from SFF2) | |
++----------+--------------------------------+--------------------------------+
+| 5 | Match Any | Drop |
++----------+--------------------------------+--------------------------------+
Table: Table Transport Egress
In all the following configuration sections, replace the ``${JSON}``
string with the appropriate JSON configuration. Also, change the
-``localhost`` desintation in the URL accordingly.
+``localhost`` destination in the URL accordingly.
SFC OF Renderer NSH Tutorial
''''''''''''''''''''''''''''
}
}
-The depolyed topology like this:
+The deployed topology like this:
::
First step is to create the required RSP as usually done.
-Once RSP name is avaiable it is used to send a POST RPC to the
+Once RSP name is available it is used to send a POST RPC to the
controller similar to below:
::
}
}
+Logical Service Function Forwarder
+----------------------------------
+
+Overview
+~~~~~~~~
+
+Rationale
+^^^^^^^^^
+
+When the current SFC is deployed in a cloud environment, it is assumed that each
+switch connected to a Service Function is configured as a Service Function Forwarder and
+each Service Function is connected to its Service Function Forwarder depending on the
+Compute Node where the Virtual Machine is located.
+
+.. figure:: ./images/sfc/sfc-in-cloud.png
+ :alt: Deploying SFC in Cloud Environments
+
+As shown in the picture above, this solution allows the basic cloud use cases to be fulfilled,
+as for example, the ones required in OPNFV Brahmaputra, however, some advanced use cases
+like the transparent migration of VMs can not be implemented. The Logical Service Function Forwarder
+enables the following advanced use cases:
+
+1. Service Function mobility without service disruption
+2. Service Functions load balancing and failover
+
+As shown in the picture below, the Logical Service Function Forwarder concept extends the current
+SFC northbound API to provide an abstraction of the underlying Data Center infrastructure.
+The Data Center underlaying network can be abstracted by a single SFF. This single SFF uses
+the logical port UUID as data plane locator to connect SFs globally and in a location-transparent manner.
+SFC makes use of `Genius <./genius-user-guide.html>`__ project to track the
+location of the SF's logical ports.
+
+.. figure:: ./images/sfc/single-logical-sff-concept.png
+ :alt: Single Logical SFF concept
+
+The SFC internally distributes the necessary flow state over the relevant switches based on the
+internal Data Center topology and the deployment of SFs.
+
+Changes in data model
+~~~~~~~~~~~~~~~~~~~~~
+The Logical Service Function Forwarder concept extends the current SFC northbound API to provide
+an abstraction of the underlying Data Center infrastructure.
+
+The Logical SFF simplifies the configuration of the current SFC data model by reducing the number
+of parameters to be be configured in every SFF, since the controller will discover those parameters
+by interacting with the services offered by the `Genius <./genius-user-guide.html>`__ project.
+
+The following picture shows the Logical SFF data model. The model gets simplified as most of the
+configuration parameters of the current SFC data model are discovered in runtime. The complete
+YANG model can be found here `logical SFF model
+<https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-function-forwarder-logical.yang>`__.
+
+.. figure:: ./images/sfc/logical-sff-datamodel.png
+ :alt: Logical SFF data model
+
+How to configure the Logical SFF
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The following are examples to configure the Logical SFF:
+
+::
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-node:service-nodes/
+
+**Service Nodes JSON.**
+
+::
+
+ {
+ "service-nodes": {
+ "service-node": [
+ {
+ "name": "classifier1",
+ "service-function": [
+ ],
+ "ip-mgmt-address": "192.168.1.10"
+ },
+ {
+ "name": "sf1",
+ "service-function": [
+ "dpi-1"
+ ],
+ "ip-mgmt-address": "192.168.1.30"
+ },
+ {
+ "name": "sf2",
+ "service-function": [
+ "firewall-1"
+ ],
+ "ip-mgmt-address": "192.168.1.40"
+ },
+ {
+ "name": "classifier2",
+ "service-function": [
+ ],
+ "ip-mgmt-address": "192.168.1.60"
+ }
+ ]
+ }
+ }
+
+::
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/restconf/config/service-function:service-functions/
+
+**Service Functions JSON.**
+
+::
+
+ {
+ "service-functions": {
+ "service-function": [
+ {
+ "name": "dpi-1",
+ "ip-mgmt-address": "192.168.1.30",
+ "rest-uri": "http://192.168.1.30:5000",
+ "type": "dpi",
+ "nsh-aware": "true",
+ "sf-data-plane-locator": [
+ {
+ "name": "dpi-1-dpl",
+ "interface-name": "e0fffc12-a46e-4575-bf36-8383c8edefed",
+ "service-function-forwarder": "sfflogical1"
+ }
+ ]
+ },
+ {
+ "name": "firewall-1",
+ "ip-mgmt-address": "192.168.1.40",
+ "rest-uri": "http://192.168.1.40:5000",
+ "type": "firewall",
+ "nsh-aware": "true",
+ "sf-data-plane-locator": [
+ {
+ "name": "firewall-1-dpl",
+ "interface-name": "952a5486-d1a5-40cd-a7c1-cc61e59a2b36",
+ "service-function-forwarder": "sfflogical1"
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+::
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
+
+**Service Function Forwarders JSON.**
+
+::
+
+ {
+ "service-function-forwarders": {
+ "service-function-forwarder": [
+ {
+ "name": "sfflogical1"
+ }
+ ]
+ }
+ }
+
+::
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-chain:service-function-chains/
+
+**Service Function Chains JSON.**
+
+::
+
+ {
+ "service-function-chains": {
+ "service-function-chain": [
+ {
+ "name": "SFC1",
+ "symmetric": "true",
+ "sfc-service-function": [
+ {
+ "name": "dpi-abstract1",
+ "type": "dpi"
+ },
+ {
+ "name": "firewall-abstract1",
+ "type": "firewall"
+ }
+ ]
+ },
+ {
+ "name": "SFC2",
+ "symmetric": "true",
+ "sfc-service-function": [
+ {
+ "name": "dpi-abstract1",
+ "type": "dpi"
+ }
+ ]
+ }
+ ]
+ }
+ }
- SNBI Forwarding Element (FE)
-.. figure:: ./images/snbi/snbi_arch.png
+.. figure:: images/snbi/snbi_arch.png
:alt: SNBI Architecture Diagram
SNBI Architecture Diagram
-UNI Manager Plug In Project
-===========================
+User Network Interface Manager Plug-in (Unimgr)
+===============================================
Overview
--------
-The version of the UNI Manager (UNIMgr) plug-in included in OpenDaylight
-Boron release is experimental, serving as a proof-of-concept (PoC)
-for using features of OpenDaylight to provision networked elements with
-attributes satisfying Metro Ethernet Forum (MEF) requirements for
-delivery of Carrier Ethernet service. This initial version of UNIMgr
-does not enable the full set of MEF-defined functionality for Carrier
-Ethernet service. UNI Manager adheres to a minimum set of functionality
-defined by MEF 7.2 and 10.2 specifications.
-
-UNIMgr receives a request from applications to create an Ethernet
-Private Line (EPL) private Ethernet connection between two endpoints on
-the network. The request must include the IP addresses of the endpoints
-and a class of service identifier.
-
-UNI Manager plug-in translates the request for EPL service into (a)
-configuring two instances of Open vSwitch (OVS), each instance running
-in one of the UNI endpoints, with two ports and a bridge between the
-ports, and (b) creating a GRE tunnel to provide a private connection
-between the endpoints. This initial version of UNIMgr uses only OVSDB on
-its southbound interface to send configuration commands.
-
-UNIMgr also accepts a bits per second datarate parameter, which is
-translated to an OVSDB command to limit the rate at which the OVS
-instances will forward data traffic.
-
-The YANG module used to create the UNIMgr plug-in models MEF-defined UNI
-and Ethernet Virtual Connection (EVC) attributes but does not include
-the full set of UNI and EVC attributes. And of the attributes modeled in
-the YANG module only a subset of them are implemented in the UNIMgr
-listener code translating the Operational data tree to OVSDB commands.
-The YANG module used to develop the PoC UNIMgr plug-in is
-cl-unimgr-mef.yang. A copy of this module is available in the
-odl-unimgr-api bundle of the UNIMgr project.
-
-Limitations of the PoC version of UNI Manager in OpenDaylight Boron
-include those listed below: \* Uses only OVSDB southbound interface of
-OpenDaylight \* Only uses UNI ID, IP Address, and speed UNI attributes
-\* Only uses a subset of EVC per UNI attributes \* Does not use MEF
-Class of Service or Bandwidth Profile attributes \* Configures only Open
-vSwitch network elements
-
-Opportunities for evolution of the UNI Manager plug in include using
-complete MEF Service Layer and MEF Resource Layer YANG models and
-supporting other OpenDaylight southbound protocols like NetConf and
-OpenFlow.
-
-UNI Manager Components
-----------------------
-
-UNI Manager is comprised of the following OpenDaylight Karaf features:
+The User Network Interface Manager (Unimgr) is an experimental/proof of concept
+(PoC) project formed to initiate the development of data models and APIs
+facilitating the use by software applications and/or service orchestrators of
+OpenDaylight to configure and provision connectivity services, in particular
+Carrier Ethernet services as defined by Metro Ethernet Forum (MEF), in physical
+or virtual network elements.
+
+MEF as defined the LSO Reference Architecture for the management and control of
+domains and entities that enable cooperative LSO capabilities across one or
+more service provider networks. The architecture also identifies the Management
+Interface Reference Points (LSO Reference Points), the logical points of
+interaction between specific functional management components. These LSO
+Reference Points are further defined by interface profiles and instantiated by
+APIs.
+
+The LSO High Level Management Reference Architecture is shown below. Note that
+this is a functional architecture that does not describe how the management
+components are implemented (e.g., single vs. multiple instances), but rather
+identifies management components that provide logical functionality as well as
+the points of interaction among them.
+
+Unimgr provides support for both the Legato as well as the Presto interfaces.
+These interface, and the APIs associated with them, are defined by YANG models
+developed within MEF in collaboration with ONF and IETF. For the Boron release,
+these are as follows:
+
+Legato YANG modules:
+https://git.opendaylight.org/gerrit/gitweb?p=unimgr.git;a=tree;f=legato-api/src/main/yang;hb=refs/heads/stable/boron
+
+Presto YANG modules:
+https://git.opendaylight.org/gerrit/gitweb?p=unimgr.git;a=tree;f=presto-api/src/main/yang;hb=refs/heads/stable/boron
+
+An application/user can interact with Unimgr at either the service
+orchestration layer (Legato) or the network resource provisioning layer
+(Presto).
+
+Unimgr Components
+-----------------
+
+Unimgr is comprised of the following OpenDaylight Karaf features:
+--------------------------------------+--------------------------------------+
| odl-unimgr-api | OpenDaylight :: UniMgr :: api |
| odl-unimgr-ui | OpenDaylight :: UniMgr :: UI |
+--------------------------------------+--------------------------------------+
-Installing UNI Manager Plug-in
-------------------------------
+Installing Unimgr
+-----------------
-After launching OpenDaylight install the feature for the UNI Manager
-plug-in. From the karaf command prompt execute the following command to
-install the UNI Manager plug-in:
+After launching OpenDaylight, install the feature for Unimgr. From the karaf
+command prompt execute the following command:
::
- $ feature:install odl-manager-ui
+ $ feature:install odl-unimgr-ui
-Explore and exercise the UNI Manager REST API
----------------------------------------------
+Explore and exercise the Unimgr REST API
+----------------------------------------
-To see the UNI Manager APIs, browse to this URL:
+To see the Unimgr API, browse to this URL:
http://localhost:8181/apidoc/explorer/index.html
Replace localhost with the IP address or hostname where OpenDaylight is
running if you are not running OpenDaylight locally on your machine.
-See also the UNI Manager Developer’s Guide for a full list and
-description of UNI Manager POSTMAN calls.
-
+See also the Unimgr Developer Guide for a full listing of the API.
To log in to DLUX, after installing the application:
1. Open a browser and enter the login URL
- `http://<your-karaf-ip>:8181/index.html <http://<your-karaf-ip>:8181/index.html>`__
+ http://<your-karaf-ip>:8181/index.htm
in your browser (Chrome is recommended).
2. Login to the application with your username and password credentials.
It is implemented as two major components
-- `VTN Manager <#_vtn_manager>`__
+- `VTN Manager`
-- `VTN Coordinator <#_vtn_coordinator>`__
+- `VTN Coordinator`
VTN Manager
~~~~~~~~~~~
''''''''''''''''''''''''''''
- stack.sh prints out Horizon is now available at
- `http://<CONTROL\_NODE\_IP\_ADDRESS>:8080/ <http://<CONTROL_NODE_IP_ADDRESS>:8080/>`__
+ http://<CONTROL\_NODE\_IP\_ADDRESS>:8080/
- Execute the command *sudo ovs-vsctl show* in the control node
terminal and verify if the bridge *br-int* is created.
^^^^^^^^^^^^^^^^^^^^^^^^
- Please visit the OpenDaylight DLUX GUI after stacking all the nodes,
- `http://<ODL\_IP\_ADDRESS>:8181/index.html <http://<ODL_IP_ADDRESS>:8181/index.html>`__.
+ http://<ODL\_IP\_ADDRESS>:8181/index.html.
The switches, topology and the ports that are currently read can be
validated.
http://<controller-ip>:8181/index.html
- **Tip**
+.. tip::
If the interconnected between the Open vSwitch is not seen, Please
bring up the interface for the dataplane manually using the below
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Login to
- `http://<CONTROL\_NODE\_IP>:8080/ <http://<CONTROL_NODE_IP>:8080/>`__
+ http://<CONTROL\_NODE\_IP>:8080/
to check the horizon GUI.
.. figure:: ./images/vtn/OpenStackGui.png
and enter the login URL. If you have installed DLUX as a stand-alone,
then the login URL is http://localhost:9000/DLUX/index.html. However if
you have deployed DLUX with Karaf, then the login URL is
-`http://\\<your <http://\<your>`__ IP\\>:8181/dlux/index.html. \* Login
+http://<your IP>:8181/dlux/index.html. \* Login
to the application with user ID and password credentials as admin.
NOTE:admin is the only user type available for DLUX in this release.
here does not work in other releases.
.. figure:: ./images/vtn/vlanmap_using_mininet.png
- :alt: Example that demonstrates vlanmap testing in Mininet
- Environment
+ :alt: Example that demonstrates vlanmap testing in Mininet Environment
Example that demonstrates vlanmap testing in Mininet Environment
This example explains how to test vlan-map in a multi host scenario.
.. figure:: ./images/vtn/vlanmap_using_mininet.png
- :alt: Example that demonstrates vlanmap testing in Mininet
- Environment
+ :alt: Example that demonstrates vlanmap testing in Mininet Environment
Example that demonstrates vlanmap testing in Mininet Environment
+++ /dev/null
-# Makefile for Sphinx documentation
-#
-
-# You can set these variables from the command line.
-SPHINXOPTS =
-SPHINXBUILD = sphinx-build
-PAPER =
-BUILDDIR = _build
-
-# User-friendly check for sphinx-build
-ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
- $(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don\'t have Sphinx installed, grab it from http://sphinx-doc.org/)
-endif
-
-# Internal variables.
-PAPEROPT_a4 = -D latex_paper_size=a4
-PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-# the i18n builder cannot share the environment and doctrees with the others
-I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-
-.PHONY: help
-help:
- @echo "Please use \`make <target>' where <target> is one of"
- @echo " html to make standalone HTML files"
- @echo " dirhtml to make HTML files named index.html in directories"
- @echo " singlehtml to make a single large HTML file"
- @echo " pickle to make pickle files"
- @echo " json to make JSON files"
- @echo " htmlhelp to make HTML files and a HTML help project"
- @echo " qthelp to make HTML files and a qthelp project"
- @echo " applehelp to make an Apple Help Book"
- @echo " devhelp to make HTML files and a Devhelp project"
- @echo " epub to make an epub"
- @echo " epub3 to make an epub3"
- @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
- @echo " latexpdf to make LaTeX files and run them through pdflatex"
- @echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
- @echo " text to make text files"
- @echo " man to make manual pages"
- @echo " texinfo to make Texinfo files"
- @echo " info to make Texinfo files and run them through makeinfo"
- @echo " gettext to make PO message catalogs"
- @echo " changes to make an overview of all changed/added/deprecated items"
- @echo " xml to make Docutils-native XML files"
- @echo " pseudoxml to make pseudoxml-XML files for display purposes"
- @echo " linkcheck to check all external links for integrity"
- @echo " doctest to run all doctests embedded in the documentation (if enabled)"
- @echo " coverage to run coverage check of the documentation (if enabled)"
-
-.PHONY: clean
-clean:
- rm -rf $(BUILDDIR)/*
-
-.PHONY: html
-html:
- $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
- @echo
- @echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
-
-.PHONY: dirhtml
-dirhtml:
- $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
- @echo
- @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
-
-.PHONY: singlehtml
-singlehtml:
- $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
- @echo
- @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
-
-.PHONY: pickle
-pickle:
- $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
- @echo
- @echo "Build finished; now you can process the pickle files."
-
-.PHONY: json
-json:
- $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
- @echo
- @echo "Build finished; now you can process the JSON files."
-
-.PHONY: htmlhelp
-htmlhelp:
- $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
- @echo
- @echo "Build finished; now you can run HTML Help Workshop with the" \
- ".hhp project file in $(BUILDDIR)/htmlhelp."
-
-.PHONY: qthelp
-qthelp:
- $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
- @echo
- @echo "Build finished; now you can run "qcollectiongenerator" with the" \
- ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
- @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/OpenDaylightDocumentation.qhcp"
- @echo "To view the help file:"
- @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/OpenDaylightDocumentation.qhc"
-
-.PHONY: applehelp
-applehelp:
- $(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp
- @echo
- @echo "Build finished. The help book is in $(BUILDDIR)/applehelp."
- @echo "N.B. You won't be able to view it unless you put it in" \
- "~/Library/Documentation/Help or install it in your application" \
- "bundle."
-
-.PHONY: devhelp
-devhelp:
- $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
- @echo
- @echo "Build finished."
- @echo "To view the help file:"
- @echo "# mkdir -p $$HOME/.local/share/devhelp/OpenDaylightDocumentation"
- @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/OpenDaylightDocumentation"
- @echo "# devhelp"
-
-.PHONY: epub
-epub:
- $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
- @echo
- @echo "Build finished. The epub file is in $(BUILDDIR)/epub."
-
-.PHONY: epub3
-epub3:
- $(SPHINXBUILD) -b epub3 $(ALLSPHINXOPTS) $(BUILDDIR)/epub3
- @echo
- @echo "Build finished. The epub3 file is in $(BUILDDIR)/epub3."
-
-.PHONY: latex
-latex:
- $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
- @echo
- @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
- @echo "Run \`make' in that directory to run these through (pdf)latex" \
- "(use \`make latexpdf' here to do that automatically)."
-
-.PHONY: latexpdf
-latexpdf:
- $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
- @echo "Running LaTeX files through pdflatex..."
- $(MAKE) -C $(BUILDDIR)/latex all-pdf
- @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
-
-.PHONY: latexpdfja
-latexpdfja:
- $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
- @echo "Running LaTeX files through platex and dvipdfmx..."
- $(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
- @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
-
-.PHONY: text
-text:
- $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
- @echo
- @echo "Build finished. The text files are in $(BUILDDIR)/text."
-
-.PHONY: man
-man:
- $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
- @echo
- @echo "Build finished. The manual pages are in $(BUILDDIR)/man."
-
-.PHONY: texinfo
-texinfo:
- $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
- @echo
- @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
- @echo "Run \`make' in that directory to run these through makeinfo" \
- "(use \`make info' here to do that automatically)."
-
-.PHONY: info
-info:
- $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
- @echo "Running Texinfo files through makeinfo..."
- make -C $(BUILDDIR)/texinfo info
- @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
-
-.PHONY: gettext
-gettext:
- $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
- @echo
- @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
-
-.PHONY: changes
-changes:
- $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
- @echo
- @echo "The overview file is in $(BUILDDIR)/changes."
-
-.PHONY: linkcheck
-linkcheck:
- $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
- @echo
- @echo "Link check complete; look for any errors in the above output " \
- "or in $(BUILDDIR)/linkcheck/output.txt."
-
-.PHONY: doctest
-doctest:
- $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
- @echo "Testing of doctests in the sources finished, look at the " \
- "results in $(BUILDDIR)/doctest/output.txt."
-
-.PHONY: coverage
-coverage:
- $(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
- @echo "Testing of coverage in the sources finished, look at the " \
- "results in $(BUILDDIR)/coverage/python.txt."
-
-.PHONY: xml
-xml:
- $(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
- @echo
- @echo "Build finished. The XML files are in $(BUILDDIR)/xml."
-
-.PHONY: pseudoxml
-pseudoxml:
- $(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
- @echo
- @echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
-
+++ /dev/null
-This folder is designed to receive compiled reST from the makeRST.sh
-script. It is a skeleton to receive the compiled reST and make it
-useful. It is not useful on its own.
+++ /dev/null
-#!/usr/bin/env python3
-# -*- coding: utf-8 -*-
-#
-# OpenDaylight Documentation documentation build configuration file, created by
-# sphinx-quickstart on Mon Mar 28 14:20:08 2016.
-#
-# This file is execfile()d with the current directory set to its
-# containing dir.
-#
-# Note that not all possible configuration values are present in this
-# autogenerated file.
-#
-# All configuration values have a default; values that are commented out
-# serve to show the default.
-
-import sys
-import os
-import sphinx_bootstrap_theme
-
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
-#sys.path.insert(0, os.path.abspath('.'))
-
-# -- General configuration ------------------------------------------------
-
-# If your documentation needs a minimal Sphinx version, state it here.
-#needs_sphinx = '1.0'
-
-# Add any Sphinx extension module names here, as strings. They can be
-# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
-# ones.
-extensions = []
-
-javasphinx_available = False
-try:
- import javasphinx
- javasphinx_available = True
- extensions.append('javasphinx')
-except ImportError, e:
- pass
-
-# Add any paths that contain templates here, relative to this directory.
-templates_path = ['_templates']
-
-# The suffix(es) of source filenames.
-# You can specify multiple suffix as a list of string:
-# source_suffix = ['.rst', '.md']
-source_suffix = '.rst'
-
-# The encoding of source files.
-#source_encoding = 'utf-8-sig'
-
-# The master toctree document.
-master_doc = 'index'
-
-# General information about the project.
-project = 'OpenDaylight Documentation'
-copyright = '2016, OpenDaylight Project'
-author = 'OpenDaylight Project'
-
-# The version info for the project you're documenting, acts as replacement for
-# |version| and |release|, also used in various other places throughout the
-# built documents.
-#
-# The short X.Y version.
-version = 'Boron'
-# The full version, including alpha/beta/rc tags.
-release = 'Boron'
-
-# The language for content autogenerated by Sphinx. Refer to documentation
-# for a list of supported languages.
-#
-# This is also used if you do content translation via gettext catalogs.
-# Usually you set "language" from the command line for these cases.
-language = None
-
-# There are two options for replacing |today|: either, you set today to some
-# non-false value, then it is used:
-#today = ''
-# Else, today_fmt is used as the format for a strftime call.
-#today_fmt = '%B %d, %Y'
-
-# List of patterns, relative to source directory, that match files and
-# directories to ignore when looking for source files.
-# This patterns also effect to html_static_path and html_extra_path
-exclude_patterns = []
-
-# The reST default role (used for this markup: `text`) to use for all
-# documents.
-#default_role = None
-
-# If true, '()' will be appended to :func: etc. cross-reference text.
-#add_function_parentheses = True
-
-# If true, the current module name will be prepended to all description
-# unit titles (such as .. function::).
-#add_module_names = True
-
-# If true, sectionauthor and moduleauthor directives will be shown in the
-# output. They are ignored by default.
-#show_authors = False
-
-# The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
-
-# A list of ignored prefixes for module index sorting.
-#modindex_common_prefix = []
-
-# If true, keep warnings as "system message" paragraphs in the built documents.
-#keep_warnings = False
-
-# If true, `todo` and `todoList` produce output, else they produce nothing.
-todo_include_todos = False
-
-
-# -- Options for HTML output ----------------------------------------------
-
-# The theme to use for HTML and HTML Help pages. See the documentation for
-# a list of builtin themes.
-html_theme = 'bootstrap'
-
-# Theme options are theme-specific and customize the look and feel of a theme
-# further. For a list of options available for each theme, see the
-# documentation.
-#html_theme_options = {}
-html_theme_options = {
- 'bootswatch_theme': "united",
-}
-
-# Add any paths that contain custom themes here, relative to this directory.
-#html_theme_path = []
-html_theme_path = sphinx_bootstrap_theme.get_html_theme_path()
-
-# The name for this set of Sphinx documents.
-# "<project> v<release> documentation" by default.
-#html_title = 'OpenDaylight Documentation v0.3.0'
-
-# A shorter title for the navigation bar. Default is the same as html_title.
-#html_short_title = None
-
-# The name of an image file (relative to this directory) to place at the top
-# of the sidebar.
-html_logo = '_static/odl_small.png'
-
-# The name of an image file (relative to this directory) to use as a favicon of
-# the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
-# pixels large.
-#html_favicon = None
-
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
-
-# Add any extra paths that contain custom files (such as robots.txt or
-# .htaccess) here, relative to this directory. These files are copied
-# directly to the root of the documentation.
-#html_extra_path = []
-
-# If not None, a 'Last updated on:' timestamp is inserted at every page
-# bottom, using the given strftime format.
-# The empty string is equivalent to '%b %d, %Y'.
-#html_last_updated_fmt = None
-
-# If true, SmartyPants will be used to convert quotes and dashes to
-# typographically correct entities.
-#html_use_smartypants = True
-
-# Custom sidebar templates, maps document names to template names.
-#html_sidebars = {}
-
-# Additional templates that should be rendered to pages, maps page names to
-# template names.
-#html_additional_pages = {}
-
-# If false, no module index is generated.
-#html_domain_indices = True
-
-# If false, no index is generated.
-#html_use_index = True
-
-# If true, the index is split into individual pages for each letter.
-#html_split_index = False
-
-# If true, links to the reST sources are added to the pages.
-#html_show_sourcelink = True
-
-# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
-#html_show_sphinx = True
-
-# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
-#html_show_copyright = True
-
-# If true, an OpenSearch description file will be output, and all pages will
-# contain a <link> tag referring to it. The value of this option must be the
-# base URL from which the finished HTML is served.
-#html_use_opensearch = ''
-
-# This is the file name suffix for HTML files (e.g. ".xhtml").
-#html_file_suffix = None
-
-# Language to be used for generating the HTML full-text search index.
-# Sphinx supports the following languages:
-# 'da', 'de', 'en', 'es', 'fi', 'fr', 'h', 'it', 'ja'
-# 'nl', 'no', 'pt', 'ro', 'r', 'sv', 'tr', 'zh'
-#html_search_language = 'en'
-
-# A dictionary with options for the search language support, empty by default.
-# 'ja' uses this config value.
-# 'zh' user can custom change `jieba` dictionary path.
-#html_search_options = {'type': 'default'}
-
-# The name of a javascript file (relative to the configuration directory) that
-# implements a search results scorer. If empty, the default will be used.
-#html_search_scorer = 'scorer.js'
-
-# Output file base name for HTML help builder.
-htmlhelp_basename = 'OpenDaylightDocumentationdoc'
-
-# -- Options for LaTeX output ---------------------------------------------
-
-latex_elements = {
-# The paper size ('letterpaper' or 'a4paper').
-#'papersize': 'letterpaper',
-
-# The font size ('10pt', '11pt' or '12pt').
-#'pointsize': '10pt',
-
-# Additional stuff for the LaTeX preamble.
-#'preamble': '',
-
-# Latex figure (float) alignment
-#'figure_align': 'htbp',
-}
-
-# Grouping the document tree into LaTeX files. List of tuples
-# (source start file, target name, title,
-# author, documentclass [howto, manual, or own class]).
-latex_documents = [
- (master_doc, 'OpenDaylightDocumentation.tex', 'OpenDaylight Documentation Documentation',
- 'OpenDaylight Project', 'manual'),
-]
-
-# The name of an image file (relative to this directory) to place at the top of
-# the title page.
-#latex_logo = None
-
-# For "manual" documents, if this is true, then toplevel headings are parts,
-# not chapters.
-#latex_use_parts = False
-
-# If true, show page references after internal links.
-#latex_show_pagerefs = False
-
-# If true, show URL addresses after external links.
-#latex_show_urls = False
-
-# Documents to append as an appendix to all manuals.
-#latex_appendices = []
-
-# If false, no module index is generated.
-#latex_domain_indices = True
-
-
-# -- Options for manual page output ---------------------------------------
-
-# One entry per manual page. List of tuples
-# (source start file, name, description, authors, manual section).
-man_pages = [
- (master_doc, 'opendaylightdocumentation', 'OpenDaylight Documentation Documentation',
- [author], 1)
-]
-
-# If true, show URL addresses after external links.
-#man_show_urls = False
-
-
-# -- Options for Texinfo output -------------------------------------------
-
-# Grouping the document tree into Texinfo files. List of tuples
-# (source start file, target name, title, author,
-# dir menu entry, description, category)
-texinfo_documents = [
- (master_doc, 'OpenDaylightDocumentation', 'OpenDaylight Documentation Documentation',
- author, 'OpenDaylightDocumentation', 'One line description of project.',
- 'Miscellaneous'),
-]
-
-# Documents to append as an appendix to all manuals.
-#texinfo_appendices = []
-
-# If false, no module index is generated.
-#texinfo_domain_indices = True
-
-# How to display URL addresses: 'footnote', 'no', or 'inline'.
-#texinfo_show_urls = 'footnote'
-
-# If true, do not generate a @detailmenu in the "Top" node's menu.
-#texinfo_no_detailmenu = False
-
-
-linkcheck_ignore = [
- # Ignore jenkins because it's often slow to respond.
- 'https://jenkins.opendaylight.org/releng',
- 'https://jenkins.opendaylight.org/sandbox',
- 'http://\$CONTROL_HOST:8181/dlux/index.html',
- # The '#' in the path makes sphinx think it's an anchor
- 'https://git.opendaylight.org/gerrit/#/admin/projects/releng/builder',
-]
-
-# Build integration stuff
-#import subprocess
-
-#subprocess.call(["./build-integration-robot-libdoc.sh"])
-
-# Disable javasphinx generation until we have a solution to long build
-# times. readthedocs timesout after 902 seconds.
-# if javasphinx_available:
-# subprocess.call(["./generate-javaapidoc.sh"])
+++ /dev/null
-.. OpenDaylight Documentation documentation master file, created by
- sphinx-quickstart on Mon Mar 28 14:20:08 2016.
- You can adapt this file completely to your liking, but it should at least
- contain the root `toctree` directive.
-
-Welcome to the OpenDaylight Handbook!
-=====================================
-
-This handbook provides details on various aspects of OpenDaylight from the user
-guides to the developer guides and tries to act as a single point of contact
-for all documentation related articles in OpenDaylight. If you would like to
-contribute to the Handbook please refer to the :ref:`documentation-guide`.
-
-Content for OpenDaylight Users
-------------------------------
-
-The following content is intended for people who would like to deploy, use, or
-just learn more about OpenDaylight.
-
-.. toctree::
- :maxdepth: 1
-
- getting-started-guide/index
- opendaylight-with-openstack/index
- user-guide-autogenerated/index
-
-.. Uncomment this when we have reST content targeting developers
-.. Content for OpenDaylight Developers
-.. -----------------------------------
-..
-.. The Following content is intended for developers building applications or code
-.. on top of OpenDaylight, but who do not plan to modify OpenDaylight code
-.. itself.
-
-
-Content for OpenDaylight Contributors
--------------------------------------
-
-The following content is intended for developers who either currently
-participate in the development of OpenDaylight or would like to start.
-
-.. toctree::
- :maxdepth: 1
-
- developer-guide-autogenerated/index
-
-
-.. Commenting the below out until we actually use it
-.. Indices and tables
-.. ==================
-..
-.. * :ref:`genindex`
-.. * :ref:`modindex`
-.. * :ref:`search`
+++ /dev/null
-@ECHO OFF\r
-\r
-REM Command file for Sphinx documentation\r
-\r
-if "%SPHINXBUILD%" == "" (\r
- set SPHINXBUILD=sphinx-build\r
-)\r
-set BUILDDIR=_build\r
-set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% .\r
-set I18NSPHINXOPTS=%SPHINXOPTS% .\r
-if NOT "%PAPER%" == "" (\r
- set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%\r
- set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS%\r
-)\r
-\r
-if "%1" == "" goto help\r
-\r
-if "%1" == "help" (\r
- :help\r
- echo.Please use `make ^<target^>` where ^<target^> is one of\r
- echo. html to make standalone HTML files\r
- echo. dirhtml to make HTML files named index.html in directories\r
- echo. singlehtml to make a single large HTML file\r
- echo. pickle to make pickle files\r
- echo. json to make JSON files\r
- echo. htmlhelp to make HTML files and a HTML help project\r
- echo. qthelp to make HTML files and a qthelp project\r
- echo. devhelp to make HTML files and a Devhelp project\r
- echo. epub to make an epub\r
- echo. epub3 to make an epub3\r
- echo. latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter\r
- echo. text to make text files\r
- echo. man to make manual pages\r
- echo. texinfo to make Texinfo files\r
- echo. gettext to make PO message catalogs\r
- echo. changes to make an overview over all changed/added/deprecated items\r
- echo. xml to make Docutils-native XML files\r
- echo. pseudoxml to make pseudoxml-XML files for display purposes\r
- echo. linkcheck to check all external links for integrity\r
- echo. doctest to run all doctests embedded in the documentation if enabled\r
- echo. coverage to run coverage check of the documentation if enabled\r
- goto end\r
-)\r
-\r
-if "%1" == "clean" (\r
- for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i\r
- del /q /s %BUILDDIR%\*\r
- goto end\r
-)\r
-\r
-\r
-REM Check if sphinx-build is available and fallback to Python version if any\r
-%SPHINXBUILD% 1>NUL 2>NUL\r
-if errorlevel 9009 goto sphinx_python\r
-goto sphinx_ok\r
-\r
-:sphinx_python\r
-\r
-set SPHINXBUILD=python -m sphinx.__init__\r
-%SPHINXBUILD% 2> nul\r
-if errorlevel 9009 (\r
- echo.\r
- echo.The 'sphinx-build' command was not found. Make sure you have Sphinx\r
- echo.installed, then set the SPHINXBUILD environment variable to point\r
- echo.to the full path of the 'sphinx-build' executable. Alternatively you\r
- echo.may add the Sphinx directory to PATH.\r
- echo.\r
- echo.If you don't have Sphinx installed, grab it from\r
- echo.http://sphinx-doc.org/\r
- exit /b 1\r
-)\r
-\r
-:sphinx_ok\r
-\r
-\r
-if "%1" == "html" (\r
- %SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished. The HTML pages are in %BUILDDIR%/html.\r
- goto end\r
-)\r
-\r
-if "%1" == "dirhtml" (\r
- %SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml.\r
- goto end\r
-)\r
-\r
-if "%1" == "singlehtml" (\r
- %SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml.\r
- goto end\r
-)\r
-\r
-if "%1" == "pickle" (\r
- %SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished; now you can process the pickle files.\r
- goto end\r
-)\r
-\r
-if "%1" == "json" (\r
- %SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished; now you can process the JSON files.\r
- goto end\r
-)\r
-\r
-if "%1" == "htmlhelp" (\r
- %SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished; now you can run HTML Help Workshop with the ^\r
-.hhp project file in %BUILDDIR%/htmlhelp.\r
- goto end\r
-)\r
-\r
-if "%1" == "qthelp" (\r
- %SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished; now you can run "qcollectiongenerator" with the ^\r
-.qhcp project file in %BUILDDIR%/qthelp, like this:\r
- echo.^> qcollectiongenerator %BUILDDIR%\qthelp\OpenDaylightDocumentation.qhcp\r
- echo.To view the help file:\r
- echo.^> assistant -collectionFile %BUILDDIR%\qthelp\OpenDaylightDocumentation.ghc\r
- goto end\r
-)\r
-\r
-if "%1" == "devhelp" (\r
- %SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished.\r
- goto end\r
-)\r
-\r
-if "%1" == "epub" (\r
- %SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished. The epub file is in %BUILDDIR%/epub.\r
- goto end\r
-)\r
-\r
-if "%1" == "epub3" (\r
- %SPHINXBUILD% -b epub3 %ALLSPHINXOPTS% %BUILDDIR%/epub3\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished. The epub3 file is in %BUILDDIR%/epub3.\r
- goto end\r
-)\r
-\r
-if "%1" == "latex" (\r
- %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished; the LaTeX files are in %BUILDDIR%/latex.\r
- goto end\r
-)\r
-\r
-if "%1" == "latexpdf" (\r
- %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex\r
- cd %BUILDDIR%/latex\r
- make all-pdf\r
- cd %~dp0\r
- echo.\r
- echo.Build finished; the PDF files are in %BUILDDIR%/latex.\r
- goto end\r
-)\r
-\r
-if "%1" == "latexpdfja" (\r
- %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex\r
- cd %BUILDDIR%/latex\r
- make all-pdf-ja\r
- cd %~dp0\r
- echo.\r
- echo.Build finished; the PDF files are in %BUILDDIR%/latex.\r
- goto end\r
-)\r
-\r
-if "%1" == "text" (\r
- %SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished. The text files are in %BUILDDIR%/text.\r
- goto end\r
-)\r
-\r
-if "%1" == "man" (\r
- %SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished. The manual pages are in %BUILDDIR%/man.\r
- goto end\r
-)\r
-\r
-if "%1" == "texinfo" (\r
- %SPHINXBUILD% -b texinfo %ALLSPHINXOPTS% %BUILDDIR%/texinfo\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished. The Texinfo files are in %BUILDDIR%/texinfo.\r
- goto end\r
-)\r
-\r
-if "%1" == "gettext" (\r
- %SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished. The message catalogs are in %BUILDDIR%/locale.\r
- goto end\r
-)\r
-\r
-if "%1" == "changes" (\r
- %SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.The overview file is in %BUILDDIR%/changes.\r
- goto end\r
-)\r
-\r
-if "%1" == "linkcheck" (\r
- %SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Link check complete; look for any errors in the above output ^\r
-or in %BUILDDIR%/linkcheck/output.txt.\r
- goto end\r
-)\r
-\r
-if "%1" == "doctest" (\r
- %SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Testing of doctests in the sources finished, look at the ^\r
-results in %BUILDDIR%/doctest/output.txt.\r
- goto end\r
-)\r
-\r
-if "%1" == "coverage" (\r
- %SPHINXBUILD% -b coverage %ALLSPHINXOPTS% %BUILDDIR%/coverage\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Testing of coverage in the sources finished, look at the ^\r
-results in %BUILDDIR%/coverage/python.txt.\r
- goto end\r
-)\r
-\r
-if "%1" == "xml" (\r
- %SPHINXBUILD% -b xml %ALLSPHINXOPTS% %BUILDDIR%/xml\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished. The XML files are in %BUILDDIR%/xml.\r
- goto end\r
-)\r
-\r
-if "%1" == "pseudoxml" (\r
- %SPHINXBUILD% -b pseudoxml %ALLSPHINXOPTS% %BUILDDIR%/pseudoxml\r
- if errorlevel 1 exit /b 1\r
- echo.\r
- echo.Build finished. The pseudo-XML files are in %BUILDDIR%/pseudoxml.\r
- goto end\r
-)\r
-\r
-:end\r
+++ /dev/null
-#!/usr/bin/env python
-from __future__ import print_function
-import os
-import shutil
-import argparse
-
-chapterNames = []
-
-
-def isEquqalsSign(str):
- # Check if this line only contains '='
- if str.strip() == '':
- return False
- for ch in str:
- if ch != '=':
- return False
- return True
-
-
-def isGuideHeader(title, equalsSign):
- if not isEquqalsSign(equalsSign.rstrip()):
- return False
- if len(title.rstrip()) == len(equalsSign.rstrip()):
- return True
- else:
- return False
-
-
-def getLines(lines, start, end):
- # Get the text of one chapter
- out = ''
- while(start < end):
- out += lines[start]
- start += 1
- return out
-
-
-def getGuides(lines, lineNumbers):
- output = []
- for i in range(0, len(lineNumbers)):
- if i != len(lineNumbers) - 1:
- start = lineNumbers[i] - 1
- end = lineNumbers[i + 1] - 1
- output.append(getLines(lines, start, end))
- else:
- start = lineNumbers[i] - 1
- end = len(lines)
- output.append(getLines(lines, start, end))
- return output
-
-
-def printToFile(textList):
- chapterIndex = 0
-
- for text in textList:
- try:
- file = open(outputPath + '/' +
- chapterNames[chapterIndex] + '.rst', 'w')
- except:
- file = open(outputPath + '/' +
- chapterNames[chapterIndex] + '.rst', 'w')
- file.write(text)
- file.close()
- chapterIndex += 1
- return
-
-
-def copyDirectory(src, dest):
- try:
- shutil.copytree(src, dest)
- # Directories are the same
- except shutil.Error as e:
- print('Directory not copied. Error: %s' % e)
- # Any error saying that the directory doesn't exist
- except OSError as e:
- print('Directory not copied. Error: %s' % e)
-
-
-class FileWrapper(object):
- def __init__(self, f):
- self.f = f
- self.line = 0
-
- def close(self):
- return self.f.close
-
- def readline(self):
- self.line += 1
- return self.f.readline()
-
- def readlines(self):
- return self.f.readlines()
-
-# Obtain command line arguments
-parser = argparse.ArgumentParser(
- description='Obtain input/output and image directories')
-parser.add_argument('-i', '--input', help='Input reST file. ' +
- 'Default="developer-guide/index.rst"',
- default='developer-guide/index.rst')
-parser.add_argument('-r', '--resource', help='Image resource directory',
- default='argparse.SUPPRESS')
-parser.add_argument('-o', '--output', help='Output directory',
- default='argparse.SUPPRESS')
-args = parser.parse_args()
-inputFile = args.input
-inputPath = os.path.dirname(inputFile)
-if not hasattr(parser, 'resource'):
- imagePath = inputPath + '/images'
-else:
- imagePath = parser.resource
-if not hasattr(parser, 'output'):
- outputPath = inputPath + '-autogenerated'
-else:
- outputPath = parser.output
-
-# Create outputPath if necessary
-if not os.path.exists(outputPath):
- os.makedirs(outputPath)
-
-deGuide = FileWrapper(open(inputFile))
-
-lineAbove = deGuide.readline()
-line = deGuide.readline()
-
-lineNumbers = []
-
-while (line != ''):
- if isGuideHeader(lineAbove, line):
- lineNumbers.append(deGuide.line - 1)
- chapterNames.append(lineAbove.lower().replace(' ', '-').
- replace(':', '_').rstrip()) # replace ':' in case sphinx builder can't process.
- lineAbove = line
- line = deGuide.readline()
-deGuide.close()
-deGuide = FileWrapper(open(inputFile))
-lines = deGuide.readlines()
-deGuide.close()
-textList = getGuides(lines, lineNumbers)
-printToFile(textList)
-
-# Copy image path to developer-guide-autogenerated derectory
-copyDirectory(imagePath, outputPath + '/images')
-
-# Initialize the index.rst file
-# 1.rename opendaylight-developer-guide.rst(title + author) to index.rst
-# 2.write toctree info to index.rst
-indexPath = outputPath + '/' + 'index.rst'
-try:
- os.rename(outputPath + '/' + chapterNames[0] + '.rst', indexPath)
-except OSError:
- print(chapterNames[0] + '.rst ' + 'does not exists.')
-
-rstIndexText = open(indexPath, 'a')
-rstIndexText.write('.. toctree:: \n')
-rstIndexText.write('\t' + ':maxdepth: 1 \n')
-rstIndexText.write('\n')
-for i in range(1, len(chapterNames)):
- rstIndexText.write('\t' + chapterNames[i] + '\n')
-rstIndexText.close()
+++ /dev/null
-#!/bin/bash
-
-# This script compiles documenatation from asciidoc source by
-# converting asciidoc to reStructedText automatically using
-# asciidoctor maven plug in and pandoc (http://www.pandoc.org/).
-#
-# Please make sure you have pandoc (http://www.pandoc.org/), sphinx
-# (http://www.sphinx-doc.org/) and sphinx-bootstrap-theme(https://ryan-roemer.github.io/sphinx-bootstrap-theme/) installed.
-
-cwd=$(pwd)
-cp -r $cwd/docs/getting-started-guide $cwd/docs_autotranslation/getting-started-guide
-cp -r $cwd/docs/opendaylight-with-openstack $cwd/docs_autotranslation/opendaylight-with-openstack
-cp -r $cwd/docs/_static $cwd/docs_autotranslation/_static
-docs='developer-guide user-guide'
-for i in $docs
-do
- echo "Translating $i ..."
- cd $cwd/manuals/$i
- mvn clean compile
- cp -r $cwd/manuals/$i/target/generated-docs $cwd/docs_autotranslation/$i
- mvn clean
- cd $cwd/docs_autotranslation/$i
- pandoc -f docbook -t rst -s *.xml -o index.rst
-done
-
-cd $cwd/docs_autotranslation
-./split.py -i developer-guide/index.rst
-./split.py -i user-guide/index.rst
-
-sphinx-build -b html $cwd/docs_autotranslation $cwd/docs_autotranslation/html
-
-
+++ /dev/null
-<?xml version="1.0" encoding="UTF-8"?>
-<appendix xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
- xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="app_community_support">
- <?dbhtml stop-chunking?>
- <title>Community support</title>
- <para>Many resources are available to help you run and use OpenDaylight. Members of the
- OpenDaylight community can answer questions and help with bug suspicions. We are constantly
- improving and adding to the main features of OpenDaylight, but if you have any problems, do
- not hesitate to ask. Use the following resources to get OpenDaylight support and
- troubleshoot your existing installations.</para>
- <section xml:id="app_community_support-documentation">
- <title>Documentation</title>
- <para>For the available OpenDaylight documentation, see <link
- xlink:href="http://docs.openstack.org">docs.opendaylight.org</link>.</para>
- <para>The following books explain how to install and operate OpenDaylight SDN Controller: </para>
- <itemizedlist>
- <listitem>
- <para>
- <link
- xlink:href="http://docs.openstack.org/trunk/install-guide/install/apt-debian/content/"
- ><citetitle>Installation Guide</citetitle></link>
- </para>
- </listitem>
- <listitem>
- <para>
- <link xlink:href="http://docs.openstack.org/user-guide/content/"><citetitle>End
- User Guide</citetitle></link>
- </para>
- </listitem>
- <listitem>
- <para>
- <link xlink:href="http://docs.openstack.org/cli-reference/content/"
- ><citetitle>Command Line Interface Reference</citetitle></link>
- </para>
- </listitem>
- </itemizedlist>
- <para>The following documentation provides reference and guidance information for the
- OpenStack APIs:</para>
- <itemizedlist>
- <listitem>
- <para><link xlink:href="http://api.openstack.org/api-ref.html">OpenDaylight API
- Reference</link></para>
- </listitem>
- </itemizedlist>
- </section>
- <section xml:id="app_community_support-mailing-lists">
- <title>OpenDaylight mailing lists</title>
- <para>A great way to get answers and insights is to post your question or problematic
- scenario to the OpenStack mailing list. You can learn from and help others who might
- have similar issues. To subscribe or view the archives, go to <link
- xlink:href="https://lists.opendaylight.org/mailman/listinfo"
- >https://lists.opendaylight.org/mailman/listinfo</link>. You might be interested in
- the other mailing lists for specific projects or development, which you can find <link
- xlink:href="https://lists.opendaylight.org/mailman/listinfo">on the wiki</link>.
- </para>
- </section>
- <section xml:id="app_community_support-wiki">
- <title>The OpenDaylight wiki</title>
- <para>The <link xlink:href="https://wiki.opendaylight.org/view/Main_Page">OpenDaylight
- wiki</link> contains a broad range of topics but some of the information can be
- difficult to find or is a few pages deep. Fortunately, the wiki search feature enables
- you to search by title or content. If you search for specific information, such as about
- networking or nova, you can find lots of relevant material. More is being added all the
- time, so be sure to check back often. You can find the search box in the upper right
- corner of any OpenDaylight wiki page.</para>
- </section>
- <section xml:id="app_community_support-bugs-area">
- <title>Bugzilla Bugs</title>
- <para>The OpenDaylight community values your set up and testing efforts and wants your
- feedback. To log a bug, you must sign up for an OpenDaylight account at <link
- xlink:href="https://launchpad.net/+login">https://launchpad.net/+login</link>. You
- can view existing bugs and report bugs in the Bugzilla bug tracker at <link
- xlink:href="https://bugs.opendaylight.org/"/>. Use the search feature to determine
- whether the bug has already been reported or even better, already fixed. If it still
- seems like your bug is unreported, fill out a bug report.</para>
- <para>Some tips:</para>
- <itemizedlist>
- <listitem>
- <para>Give a clear, concise summary!</para>
- </listitem>
- <listitem>
- <para>Provide as much detail as possible in the description. Paste in your command
- output or stack traces, links to screen shots, and so on.</para>
- </listitem>
- <listitem>
- <para>Be sure to include the software and package versions that you are using,
- especially if you are using a development branch, such as, <literal>"Hydrogen
- release" vs git commit
- bc79c3ecc55929bac585d04a03475b72e06a3208</literal>.</para>
- </listitem>
- <listitem>
- <para>Any deployment specific information is helpful, such as Ubuntu 12.04 or
- multi-node install.</para>
- </listitem>
- </itemizedlist>
- </section>
- <section xml:id="app_support-irc_channel">
- <title>The OpenDaylight IRC channel</title>
- <para>The OpenDaylight community is usually available in the #opendaylight IRC channel on
- the Freenode network. You can hang out, ask questions, or get immediate feedback for
- urgent and pressing issues. To install an IRC client or use a browser-based client, go
- to <link xlink:href="http://webchat.freenode.net">http://webchat.freenode.net/</link>.
- You can also use Colloquy (Mac OS X, <link xlink:href="http://colloquy.info/"
- >http://colloquy.info/</link>), mIRC (Windows, <link
- xlink:href="http://www.mirc.com/">http://www.mirc.com/</link>), or XChat (Linux).
- When you are in the IRC channel and want to share code or command output, the generally
- accepted method is to use a Paste Bin. </para>
- </section>
-</appendix>
+++ /dev/null
-<project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
- <parent>
- <groupId>org.opendaylight.docs</groupId>
- <artifactId>manuals</artifactId>
- <version>0.4.0-SNAPSHOT</version>
- <relativePath>../pom.xml</relativePath>
- </parent>
- <modelVersion>4.0.0</modelVersion>
- <artifactId>developersguide</artifactId>
- <packaging>jar</packaging>
- <name>OpenDaylight Docs - Manuals - Developer's Guide</name>
- <properties>
- <!-- This is set by Jenkins according to the branch. -->
- <release.path.name>local</release.path.name>
- <comments.enabled>1</comments.enabled>
- <bookname>bk-developers-guide</bookname>
- </properties>
- <!-- ################################################ -->
- <!-- USE "mvn clean generate-sources" to run this POM -->
- <!-- ################################################ -->
- <build>
- <plugins>
- <plugin>
- <groupId>org.asciidoctor</groupId>
- <artifactId>asciidoctor-maven-plugin</artifactId>
- <version>${asciidoctor.version}</version>
- <executions>
- <execution>
- <id>output-docbook</id>
- <phase>generate-sources</phase>
- <goals>
- <goal>process-asciidoc</goal>
- </goals>
- <configuration>
- <backend>docbook5</backend>
- <doctype>book</doctype>
- </configuration>
- </execution>
- </executions>
- <configuration>
- <sourceDirectory>src/main/asciidoc</sourceDirectory>
- <sourceDocumentName>${bookname}.adoc</sourceDocumentName>
- <imagesDir>./images</imagesDir>
- </configuration>
- </plugin>
- <plugin>
- <artifactId>maven-resources-plugin</artifactId>
- <version>2.6</version>
- <executions>
- <execution>
- <id>copy-resources</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>copy-resources</goal>
- </goals>
- <configuration>
- <outputDirectory>${basedir}/target/generated-docs</outputDirectory>
- <resources>
- <resource>
- <directory>src/main/resources</directory>
- <includes>
- <include>**/*.*</include>
- </includes>
- </resource>
- </resources>
- </configuration>
- </execution>
- </executions>
- </plugin>
- <plugin>
- <groupId>com.inocybe.api</groupId>
- <artifactId>sdndocs-maven-plugin</artifactId>
- <version>0.1.0</version>
- <executions>
- <execution>
- <id>generate-webhelp</id>
- <goals>
- <goal>generate-webhelp</goal>
- </goals>
- <phase>compile</phase>
- <configuration>
- <profileAudience>enduser</profileAudience>
- <includes>target/generated-docs/${bookname}.xml</includes>
- <!-- <includes>bk-install-guide.xml</includes> -->
- <generateToc>
- appendix toc,title
- article/appendix nop
- article toc,title
- book toc,title,figure,table,example,equation
- chapter toc,title
- section toc
- part toc,title
- qandadiv toc
- qandaset toc
- reference toc,title
- set toc,title
- </generateToc>
- <webhelpDirname>${bookname}</webhelpDirname>
- <pdfFilenameBase>${bookname}</pdfFilenameBase>
- </configuration>
- </execution>
- </executions>
- <configuration>
- <profileAudience>enduser</profileAudience>
- <chapterAutolabel>1</chapterAutolabel>
- <sectionAutolabel>0</sectionAutolabel>
- <tocSectionDepth>1</tocSectionDepth>
- <formalProcedures>0</formalProcedures>
- <highlightSource>false</highlightSource>
- <xincludeSupported>true</xincludeSupported>
- <showXslMessages>true</showXslMessages>
- <sourceDirectory>.</sourceDirectory>
- <feedbackEmail>mlemay@inocybe.com</feedbackEmail>
- <branding>opendaylight</branding>
- <coverLogoLeft>2.6in</coverLogoLeft>
-<!-- <enableDisqus>${comments.enabled}</enableDisqus>
- <disqusShortname>os-user-guide</disqusShortname>
- <enableGoogleAnalytics>1</enableGoogleAnalytics>
- <googleAnalyticsId>UA-17511903-1</googleAnalyticsId>
- --> <suppressFooterNavigation>0</suppressFooterNavigation>
- <canonicalUrlBase>http://docs.opendaylight.org/user-guide/content/</canonicalUrlBase>
- <glossaryCollection>${basedir}/../glossary/glossary-terms.xml</glossaryCollection>
- </configuration>
- </plugin>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-site-plugin</artifactId>
- <version>3.1</version>
- <configuration>
- <inputDirectory>${project.build.directory}/docbkx/webhelp</inputDirectory>
- </configuration>
- <dependencies>
- <dependency>
- <groupId>org.apache.maven.wagon</groupId>
- <artifactId>wagon-webdav-jackrabbit</artifactId>
- <version>2.2</version>
- </dependency>
- <dependency>
- <groupId>org.slf4j</groupId>
- <artifactId>slf4j-api</artifactId>
- <version>1.6.1</version>
- </dependency>
- </dependencies>
- </plugin>
- </plugins>
- </build>
-</project>
+++ /dev/null
-== ALTO Developer Guide ==
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/alto-developer-guide.html
+++ /dev/null
- grouping "alto-ird-request" {
- container "ird-request" {
- }
- }
- grouping "alto-ird-response" {
- container "ird" {
- container "meta" {
- }
- list "resource" {
- key "resource-id";
- leaf "resource-id" {
- type "alto-types:resource-id";
- }
- }
- }
- }
- augment "/base:query/base:input/base:request" {
- case "ird-request-data" {
- uses "alto-ird-request";
- }
- }
- augment "/base:query/base:output/base:response" {
- case "ird-response-data" {
- uses "alto-ird-response";
- }
- }
\ No newline at end of file
+++ /dev/null
-== Atrium Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/atrium-developer-guide.html
+++ /dev/null
-== BGP Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/bgp-developer-guide.html
+++ /dev/null
-== BGP Monitoring Protocol Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/bgp-monitoring-protocol-developer-guide.html
+++ /dev/null
-== PCEP Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/pcep-developer-guide.html
+++ /dev/null
-
- <author>
- <personname>
- <firstname>OpenDaylight</firstname>
- <surname>Community</surname>
- </personname>
- <email>documentation@opendaylight.org</email>
- <affiliation>
- <orgname>Linux Foundation</orgname>
- </affiliation>
- </author>
- <copyright>
- <year>2016</year>
- <holder>Linux Foundation</holder>
- </copyright>
- <releaseinfo>Boron</releaseinfo>
- <productname>OpenDaylight</productname>
- <pubdate></pubdate>
- <legalnotice role="license">
- <para> This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at <link xlink:href="http://www.eclipse.org/legal/epl-v10.html"/></para>
- </legalnotice>
- <abstract>
- <para>This guide describes how to develop using OpenDaylight.</para>
- </abstract>
- <revhistory>
- <revision>
- <date>2014-08-03</date>
- <revdescription>
- <itemizedlist spacing="compact">
- <listitem>
- <para>Initial Guide Creation</para>
- </listitem>
- </itemizedlist>
- </revdescription>
- </revision>
- </revhistory>
-
+++ /dev/null
-[[bk-user-guide]]
-= OpenDaylight Developer Guide
-:docinfo:
-
-///////
-[dedication]
-Example Dedication
-------------------
-Optional dedication.
-
-This document is an AsciiDoc book skeleton containing briefly
-annotated example elements plus a couple of example index entries and
-footnotes.
-
-Books are normally used to generate DocBook markup and the titles of
-the preface, appendix, bibliography, glossary and index sections are
-significant ('specialsections').
-
-
-[preface]
-Example Preface
----------------
-Optional preface.
-
-Preface Sub-section
-~~~~~~~~~~~~~~~~~~~
-Preface sub-section body.
-///////
-
-//////////////////////////
-Please note and leave the blank line between include statements here.
-
-It is a defensive measure to prevent individual projects' .adoc files
-from eating the next section if they forget to leave a blank line at
-the end of their file.
-//////////////////////////
-
-A significant amount of this guide has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/index.html
-
-Please look there as well as here for any content.
-
-= Project-Specific Development Guides
-
-include::alto/alto-developer-guide.adoc[ALTO]
-
-include::atrium/odl-atrium-all-dev.adoc[Atrium]
-
-include::bgpcep/odl-bgpcep-bgp-all-dev.adoc[BGP]
-
-include::bgpcep/odl-bgpcep-bmp-dev.adoc[BGP]
-
-include::capwap/capwap-dev.adoc[CAPWAP]
-
-include::cardinal/odl-cardinal-dev.adoc[]
-
-include::controller/controller.adoc[Controller]
-
-include::didm/didm-dev.adoc[]
-
-include::dlux/dlux-core-dev.adoc[]
-
-include::iotdm/iotdm-dev.adoc[]
-
-include::l2switch/l2switch-dev.adoc[]
-
-include::lacp/lacp-dev.adoc[]
-
-include::controller/netconf/odl-netconf-dev.adoc[]
-
-include::nic/nic-dev.adoc[]
-
-include::netide/netide-developer-guide.adoc[]
-
-include::neutron/odl-neutron-service-dev.adoc[]
-
-include::neutron/neutron.adoc[]
-
-include::odlparent/odlparent-developer.adoc[]
-
-include::ocpplugin/ocp-developer-guide.adoc[OCP]
-
-include::sdninterfaceapp/odl-sdninterfaceapp-all-dev.adoc[]
-
-include::of-config/of-config-dev.adoc[]
-
-include::openflowjava/odl-openflowjava-protocol-dev.adoc[]
-
-include::openflowplugin/odl-ofp-developer-guide.adoc[]
-
-include::opflex/agent-ovs-dev.adoc[]
-
-include::opflex/genie-dev.adoc[]
-
-include::opflex/libopflex-dev.adoc[]
-
-include::natapp/odl-natapp-dev.adoc[NATAPP]
-
-include::ovsdb/ovsdb-developer.adoc[]
-
-include::bgpcep/odl-bgpcep-pcep-all-dev.adoc[PCEP]
-
-include::packetcable/packetcable-dev.adoc[Packet Cable PCMM Southbound Plugin]
-
-// commenting this out as it contains no content
-//include::reservation/reservation-dev.adoc[]
-
-include::faas/odl-faas-dev.adoc[]
-
-include::sfc/sfc.adoc[]
-
-include::snbi/odl-snbi-dev.adoc[]
-
-include::snmp4sdn/snmp4sdn-developer.adoc[SNMP4SDN]
-
-include::sxp/odl-sxp-dev.adoc[]
-
-include::topoprocessing/odl-topoprocessing-framework-dev.adoc[]
-
-include::ttp/ttp-model-dev.adoc[]
-
-include::ttp/ttp-cli-tools-dev.adoc[]
-
-include::unimgr/odl-unimgr-channel-dev.adoc[]
-
-include::usecplugin/odl-usecplugin-aaa-dev.adoc[USECPLUGIN-AAA]
-
-include::usecplugin/odl-usecplugin-openflow-dev.adoc[USECPLUGIN-OPENFLOW]
-
-include::usc/odl-usc-channel-dev.adoc[]
-
-include::vtn/vtn-dev.adoc[]
-
-include::yangtools/yangtools.adoc[]
-
-include::yang-push/odl-yang-push-dev.adoc[YANG-PUSH]
-
-:numbered!:
-
-///////
-[appendix]
-Example Appendix
-----------------
-One or more optional appendixes go here at section level 1.
-
-Appendix Sub-section
-~~~~~~~~~~~~~~~~~~~
-Sub-section body.
-
-
-[glossary]
-Example Glossary
-----------------
-Glossaries are optional. Glossaries entries are an example of a style
-of AsciiDoc labeled lists.
-
-[glossary]
-A glossary term::
- The corresponding (indented) definition.
-
-A second glossary term::
- The corresponding (indented) definition.
-
-
-[colophon]
-Example Colophon
-----------------
-Text at the end of a book describing facts about its production.
-
-
-[index]
-Example Index
--------------
-///////
-
-////////////////////////////////////////////////////////////////
-The index is normally left completely empty, it's contents being
-generated automatically by the DocBook toolchain.
-////////////////////////////////////////////////////////////////
+++ /dev/null
-== CAPWAP Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/capwap-developer-guide.html
+++ /dev/null
-== Cardinal: OpenDaylight Monitoring as a Service
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/cardinal_-opendaylight-monitoring-as-a-service.rst
+++ /dev/null
-// https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Configuration:Initial
-
-// FIXME: Update this section to provide correct Lithium related information
-
-=== Initial Configuration
-The Initial configuration of the controller involves two methods.
-
-
-* Using the etc/custom.properties property file to pass configuration properties to the OSGi bundles besides the config subsystem.
-* Using the Configuration Persisters to push the initial configuration for modules managed by the config subsystem.
-
-==== Using the etc/custom.properties property file
-
-The config.ini property file can be used to provide a set of properties for any OSGi bundle deployed to the controller. It is usually used to configure bundles that are not managed by the config subsystem. For details, see '_etc_custom_properties'.
-
-==== Using configuration persister
-
-Configuration persister is a default service in the controller, and is started automatically using the OSGi Activator. Its purpose is to load the initial configuration for the config subsystem and store a snapshot for every new configuration state pushed to the config-subsystem from external clients.
-For details, see '_configuration_persister'.
-
-
-==== etc/custom.properties
-
-Various parts of the system that are not under the configuration subsystem use the file `etc/custom.properties`. Changes to this file apply after a server restart. The tabulation of several important configuration keys and values follows:
-
-[cols="2*", width="75%"]
-|===
-
-|Setting | Description
-| yangstore.blacklist=.\*controller.model.* | This regular expression (can be OR-ed using pipe character) tells NETCONF to exclude the yang files found in the matching bundle symbolic name from the hello message. This is helpful when dealing with a NETCONF client that has parsing problems.
-| netconf.config.persister.* settings | See '_opendaylight_controller_configuration_initial'.
-| netconf.tcp.address=0.0.0.0 netconf.tcp.port=8383 +
-
-netconf.ssh.address=0.0.0.0 netconf.ssh.port=1830 netconf.ssh.pk.path = ./configuration/RSA.pk +
-
-netconf.tcp.client.address=127.0.0.1 netconf.tcp.client.port=8383 | These settings specify the netconf server bindings. IP address 0.0.0.0 is used when all available network interfaces must be used by the netconf server. When starting the ssh server, the user must provide a private key. The actual authentication is done in the user admin module. By default, users admin:admin and netconf:netconf can be used to connect by means of ssh. Since the ssh bridge acts as a proxy, one needs to specify the netconf plaintext TCP address and port. These settings must normally be identical to those specified by netconf.tcp.* .
-|===
-
-=== Configuration Persister
-One way of configuring the controller is to use the configuration persister to push the initial configuration for modules managed by the config subsystem.
-
-==== Using configuration persister
-
-The configuration persister is a default service in the controller, and is started automatically using the OSGi Activator.
-Its purpose: +
-
-* Load the initial configuration for the config subsystem.
-* Store a snapshot for every new configuration state pushed to the config-subsystem from external clients. +
-
-It retrieves the base configuration from the config.ini property file, and tries to load the configuration for the config subsystem.
-The configuration for the config subsystem is pushed as a set of edit-config netconf rpcs followed by a commit rpc since the config persister acts as a netconf client.
-
-*Configuration persister lifecycle:* +
-
-. Start the config persister service at _config-persister-impl_ bundle startup.
-. Retrieve the base configuration of the adapters from the config.ini property file.
-. Initialize the backing storage adapters.
-. Initialize the netconf client, and connect to the netconf endpoint of the config subsystem.
-. Load the initial configuration snapshots from the latest storage adapter.
-. Send the edit-config rpc with the initial configuration snapshots.
-. Send the commit rpc.
-. Listen for any of the following changes to the configuration and persist a snapshot.
-
-*Configuration Persister interactions:* +
-
-.Persister
-image::Persister.jpg[width=500]
-
-==== Current configuration for controller distribution
-
-The _config.ini_ property file contains the following configuration for the configuration persister: +
-----
-netconf.config.persister.active=1,2
-
-netconf.config.persister.1.storageAdapterClass=org.opendaylight.controller.config.persist.storage.directory.autodetect.AutodetectDirectoryStorageAdapter
-
-netconf.config.persister.1.properties.directoryStorage=configuration/initial/
-
-netconf.config.persister.1.readonly=true
-
-
-netconf.config.persister.2.storageAdapterClass=org.opendaylight.controller.config.persist.storage.file.xml.XmlFileStorageAdapter
-
-netconf.config.persister.2.properties.fileStorage=configuration/current/controller.currentconfig.xml
-
-netconf.config.persister.2.properties.numberOfBackups=1
-----
-
-With this configuration, the configuration persister initializes two adapters: +
-
-* **AutodetectDirectoryStorageAdapter** to load the initial configuration files from the _configuration/initial/_ folder. These files will be pushed as the initial configuration for the config subsystem. Since this adapter is Read only, it will not store any configuration snapshot during the controller lifecycle.
-* **XmlFileStorageAdapter** to store snapshots of the current configuration after any change in the file _configuration/current/controller.currentconfig.xml_ (Only 1 snapshot backup is kept; every new change overwrites the previous one). +
-
-The initial configuration in the controller distribution consists of 2 files in the https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Configuration:Initial#Persisted_snapshot_format[xml format]. +
-
-
-* configuration/initial/00-netty.xml: +
-[source,xml]
-----
-<snapshot>
- <required-capabilities>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:netty?module=netty&revision=2013-11-19</capability>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:netty:eventexecutor?module=netty-event-executor&revision=2013-11-12</capability>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:netty:threadgroup?module=threadgroup&revision=2013-11-07</capability>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:netty:timer?module=netty-timer&revision=2013-11-19</capability>
- </required-capabilities>
- <configuration>
-
- <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <module>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty:threadgroup">netty:netty-threadgroup-fixed</type>
- <name>global-boss-group</name>
- </module>
- <module>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty:threadgroup">netty:netty-threadgroup-fixed</type>
- <name>global-worker-group</name>
- </module>
- <module>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty:timer">netty:netty-hashed-wheel-timer</type>
- <name>global-timer</name>
- </module>
- <module>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty:eventexecutor">netty:netty-global-event-executor</type>
- <name>global-event-executor</name>
- </module>
- </modules>
-
- <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <service>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-threadgroup</type>
- <instance>
- <name>global-boss-group</name>
- <provider>/modules/module[type='netty-threadgroup-fixed'][name='global-boss-group']</provider>
- </instance>
- <instance>
- <name>global-worker-group</name>
- <provider>/modules/module[type='netty-threadgroup-fixed'][name='global-worker-group']</provider>
- </instance>
- </service>
- <service>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-event-executor</type>
- <instance>
- <name>global-event-executor</name>
- <provider>/modules/module[type='netty-global-event-executor'][name='global-event-executor']</provider>
- </instance>
- </service>
- <service>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-timer</type>
- <instance>
- <name>global-timer</name>
- <provider>/modules/module[type='netty-hashed-wheel-timer'][name='global-timer']</provider>
- </instance>
- </service>
- </services>
- </data>
-
- </configuration>
-</snapshot>
-----
-This configuration snapshot instantiates netty utilities, which will be utilized by the controller components that use netty internally. +
-
-*configuration/initial/01-md-sal.xml:* +
-----
-<snapshot>
-
- <configuration>
-
- <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:impl">prefix:schema-service-singleton</type>
- <name>yang-schema-service</name>
- </module>
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:impl">prefix:hash-map-data-store</type>
- <name>hash-map-data-store</name>
- </module>
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:impl">prefix:dom-broker-impl</type>
- <name>dom-broker</name>
- <data-store xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:impl">
- <type xmlns:dom="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">dom:dom-data-store</type>
- <!-- to switch to the clustered data store, comment out the hash-map-data-store <name> and uncomment the cluster-data-store one -->
- <name>hash-map-data-store</name>
- <!-- <name>cluster-data-store</name> -->
- </data-store>
- </module>
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">prefix:binding-broker-impl</type>
- <name>binding-broker-impl</name>
- <notification-service xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-notification-service</type>
- <name>binding-notification-broker</name>
- </notification-service>
- <data-broker xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-data-broker</type>
- <name>binding-data-broker</name>
- </data-broker>
- </module>
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">prefix:runtime-generated-mapping</type>
- <name>runtime-mapping-singleton</name>
- </module>
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">prefix:binding-notification-broker</type>
- <name>binding-notification-broker</name>
- </module>
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">prefix:binding-data-broker</type>
- <name>binding-data-broker</name>
- <dom-broker xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">
- <type xmlns:dom="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">dom:dom-broker-osgi-registry</type>
- <name>dom-broker</name>
- </dom-broker>
- <mapping-service xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">binding:binding-dom-mapping-service</type>
- <name>runtime-mapping-singleton</name>
- </mapping-service>
- </module>
-
- </modules>
-
- <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <service>
- <type xmlns:dom="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">dom:schema-service</type>
- <instance>
- <name>yang-schema-service</name>
- <provider>/modules/module[type='schema-service-singleton'][name='yang-schema-service']</provider>
- </instance>
- </service>
- <service>
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-notification-service</type>
- <instance>
- <name>binding-notification-broker</name>
- <provider>/modules/module[type='binding-notification-broker'][name='binding-notification-broker']</provider>
- </instance>
- </service>
- <service>
- <type xmlns:dom="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">dom:dom-data-store</type>
- <instance>
- <name>hash-map-data-store</name>
- <provider>/modules/module[type='hash-map-data-store'][name='hash-map-data-store']</provider>
- </instance>
- </service>
- <service>
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-broker-osgi-registry</type>
- <instance>
- <name>binding-osgi-broker</name>
- <provider>/modules/module[type='binding-broker-impl'][name='binding-broker-impl']</provider>
- </instance>
- </service>
- <service>
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-rpc-registry</type>
- <instance>
- <name>binding-rpc-broker</name>
- <provider>/modules/module[type='binding-broker-impl'][name='binding-broker-impl']</provider>
- </instance>
- </service>
- <service>
- <type xmlns:binding-impl="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">binding-impl:binding-dom-mapping-service</type>
- <instance>
- <name>runtime-mapping-singleton</name>
- <provider>/modules/module[type='runtime-generated-mapping'][name='runtime-mapping-singleton']</provider>
- </instance>
- </service>
- <service>
- <type xmlns:dom="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">dom:dom-broker-osgi-registry</type>
- <instance>
- <name>dom-broker</name>
- <provider>/modules/module[type='dom-broker-impl'][name='dom-broker']</provider>
- </instance>
- </service>
- <service>
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-data-broker</type>
- <instance>
- <name>binding-data-broker</name>
- <provider>/modules/module[type='binding-data-broker'][name='binding-data-broker']</provider>
- </instance>
- </service>
-
- </services>
- </data>
-
- </configuration>
-
- <required-capabilities>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:netty:eventexecutor?module=netty-event-executor&revision=2013-11-12</capability>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:threadpool?module=threadpool&revision=2013-04-09</capability>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding?module=opendaylight-md-sal-binding&revision=2013-10-28</capability>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom?module=opendaylight-md-sal-dom&revision=2013-10-28</capability>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl?module=opendaylight-sal-binding-broker-impl&revision=2013-10-28</capability>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:impl?module=opendaylight-sal-dom-broker-impl&revision=2013-10-28</capability>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:common?module=opendaylight-md-sal-common&revision=2013-10-28</capability>
- </required-capabilities>
-
-</snapshot>
-----
-This configuration snapshot instantiates md-sal modules.
-
-After the controller is started, all these modules will be instantiated and configured. They can be further referenced from the new modules as dependencies, reconfigured, or even deleted.
-These modules are considered to be the base configuration for the controller and the purpose of them being configured automatically is to simplify the process of controller configuration for users, since the base modules will already be ready for use.
-
-=== Adding custom initial configuration
-
-There are multiple ways to add the custom initial confguration to the controller distribution:
-
-. Manually create the config file, and put it in the initial configuration folder.
-. Reconfigure the running controller using the yuma yangcli tool. The XmlFileStorageAdapter adapter will store the current snapshot, and on the next startup of the controller (assuming it was not rebuilt since), it will load the configuration containing the changes.
-
-==== Custom initial configuration in bgpcep distribution
-
-The BGPCEP project will serve as an example for adding the custom initial configuration. The bgpcep project contains the custom initial configuration that is based on the initial configuration from the controller. It adds new modules, which depend on MD-SAL and netty modules created with the initial config files of the controller. There are multiple config files in the bgpcep project. Only the 30-programming.xml file located under the programming-parent/controller-config project will be described in this section. This file contains the configuration for an instance of the instruction-scheduler module:
-
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- vi: set et smarttab sw=4 tabstop=4: -->
-<!--
- Copyright (c) 2013 Cisco Systems, Inc. and others. All rights reserved.
-
- This program and the accompanying materials are made available under the
- terms of the Eclipse Public License v1.0 which accompanies this distribution,
- and is available at http://www.eclipse.org/legal/epl-v10.html.
--->
-<snapshot>
- <required-capabilities>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding?module=opendaylight-md-sal-binding&revision=2013-10-28</capability>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:netty?module=netty&revision=2013-11-19</capability>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:programming:impl?module=config-programming-impl&revision=2013-11-15</capability>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:programming:spi?module=config-programming-spi&revision=2013-11-15</capability>
- </required-capabilities>
- <configuration>
-
- <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:programming:impl">prefix:instruction-scheduler-impl</type>
- <name>global-instruction-scheduler</name>
- <data-provider>
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-data-broker</type>
- <name>binding-data-broker</name>
- </data-provider>
- <notification-service>
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-notification-service</type>
- <name>binding-notification-broker</name>
- </notification-service>
- <rpc-registry>
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-rpc-registry</type>
- <name>binding-rpc-broker</name>
- </rpc-registry>
- <timer>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-timer</type>
- <name>global-timer</name>
- </timer>
- </module>
- </modules>
-
- <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <service>
- <type xmlns:pgmspi="urn:opendaylight:params:xml:ns:yang:controller:programming:spi">pgmspi:instruction-scheduler</type>
- <instance>
- <name>global-instruction-scheduler</name>
- <provider>/modules/module[type='instruction-scheduler-impl'][name='global-instruction-scheduler']</provider>
- </instance>
- </service>
- </services>
- </data>
-
- </configuration>
-</snapshot>
-----
-Instruction-scheduler is instantiated as a module of type _instruction-scheduler-impl_ with the name *global-instruction-scheduler:* +
-----
-<module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:programming:impl">prefix:instruction-scheduler-impl</type>
- <name>global-instruction-scheduler</name>
- ...
-----
-There is also an alias created for this module instancfe, and the alias is *global-instruction-scheduler* of type _instruction-scheduler_: +
-----
-...
-<service>
- <type xmlns:pgmspi="urn:opendaylight:params:xml:ns:yang:controller:programming:spi">pgmspi:instruction-scheduler</type>
- <instance>
- <name>global-instruction-scheduler</name>
- <provider>/modules/module[type='instruction-scheduler-impl'][name='global-instruction-scheduler']</provider>
- </instance>
-</service>
-...
-----
-The type of the alias is instruction-scheduler. This type refers to a certain service that is implemented by the instruction-scheduler-impl module. With this service type, the global-instruction-scheduler instance can be injected into any other module that requires instruction-scheduler as a dependency.
-One module can provide (implement) multiple services, and each of these services can be assigned an alias. This alias can be later used to reference the implementation it is pointing to.
-If no alias is assigned by the user, a default alias will be assigned for each provided service.
-The default alias is constructed from the name of the module instance with a prefix *ref_* and a possible suffix containing a number to resolve name clashes.
-It is recommended that users provide aliases for each service of every module instance, and use these aliases for dependency injection. References to the alias global-instruction-scheduler can be found in subsequent config files in the bgpcep project for example, _32-pcep.xml_ located under the _pcep-parent/pcep-controller-config_ project.
-
-The configuration contains four dependencies on the MD-SAL and the netty modules: +
-----
-...
-<data-provider>
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-data-broker</type>
- <name>binding-data-broker</name>
-</data-provider>
-<notification-service>
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-notification-service</type>
- <name>binding-notification-broker</name>
-</notification-service>
-<rpc-registry>
- <type xmlns:binding="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">binding:binding-rpc-registry</type>
- <name>binding-rpc-broker</name>
-</rpc-registry>
-<timer>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-timer</type>
- <name>global-timer</name>
-</timer>
-...
-----
-
-MD-SAL dependencies: +
-
-* Data-provider dependency
-* Notification-service dependency
-* Rpc-registry dependency
-
-All MD-SAL dependencies can be found in the https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Configuration:Initial#Current_configuration_for_controller_distribution[MD-SAL initial configuration file]. For example, rpc-registry dependency points to an alias binding-rpc-broker of the type binding-rpc-registry. This alias further points to an instance of the binding-broker-impl named binding-broker-impl.
-The Yang module that defines the binding-broker-impl module : https://git.opendaylight.org/gerrit/gitweb?p=controller.git;f=opendaylight/md-sal/sal-binding-broker/src/main/yang/opendaylight-binding-broker-impl.yang;a=blob[opendaylight-binding-broker-impl.yang].
-
-*Netty dependencies:* +
-
-* Timer dependency
-
-This configuration expects these dependencies to be already up and ready. It is the responsibility of the configuration subsystem to find the dependency and inject it.
-If the configuration of a module points to a non-existing dependency, the configuration subsystem will produce an exception during the validation phase.
-Every user-created configuration needs to point to existing dependencies. In the case of multiple initial configuration files that depend on one another, the resolution order can be ensured by the names of the files. Files are sorted by their names in ascending order. This means that every configuration file will have the visibility of modules from all previous configuration files by means of aliases.
-
-NOTE: The configuration provided by initial config files can also be pushed to the controller at runtime using netconf client. The whole configuration located under the data tag needs to be inserted into the config tag in the edit-config rpc. For more information, see https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Main#Examples[Examples].
-
-==== Configuration Persister
-
-As a part of the configuration subsystem, the purpose of the persister is to save and load a permanent copy of a configuration. The Persister interface represents basic operations over a storage - persist configuration and load last config, configuration snapshot is represented as string and set of it's capabilities. StorageAdapter represents an adapter interface to the ConfigProvider - subset of BundleContext, allowing access to the OSGi framework system properties.
-
-===== Persister implementation
-
-Configuration persister implementation is part of the Controller NETCONF. PersisterAggregator class is the implementation of the Presister interface. The functionality is delegated to the storage adapters. Storage adapters are low level persisters that do the heavy lifting for this class. Instances of storage adapters can be injected directly by means of the constructor, or instantiated from a full name of its class provided in a properties file. There can be many persisters configured, and varying numbers of them can be used.
-
-*Example of presisters configuration:* +
-----
-netconf.config.persister.active=2,3
- # read startup configuration
- netconf.config.persister.1.storageAdapterClass=org.opendaylight.controller.config.persist.storage.directory.xml.XmlDirectoryStorageAdapter
- netconf.config.persister.1.properties.fileStorage=configuration/initial/
-
- netconf.config.persister.2.storageAdapterClass=org.opendaylight.controller.config.persist.storage.file.FileStorageAdapter
- netconf.config.persister.2.readonly=true
- netconf.config.persister.2.properties.fileStorage=configuration/current/controller.config.1.txt
-
- netconf.config.persister.3.storageAdapterClass=org.opendaylight.controller.config.persist.storage.file.FileStorageAdapter
- netconf.config.persister.3.properties.fileStorage=configuration/current/controller.config.2.txt
- netconf.config.persister.3.properties.numberOfBackups=3
-----
-
-During server startup, ConfigPersisterNotificationHandler requests the last snapshot from the underlying storages. Each storage can respond by giving a snapshot or an absent response. The PersisterAggregator#loadLastConfigs() will search for the first non-absent response from storages ordered backwards as user specified (first '3', then '2'). When a commit notification is received, '2' will be omitted because the read-only flag is set to true, so only '3' will have a chance to persist the new configuration.
-If read-only was false, or not specified, both storage adapters would be called in the order specified by 'netconf.config.persister' property.
-
-=== Persister Notification Handler
-
-ConfigPersisterNotificationHandler class is responsible for listening for netconf notifications containing the latest committed configuration.
-The listener can handle incoming notifications, or delegates the configuration saving or loading to the persister.
-
-==== Storage Adapter implementations
-
-*XML File Storage* +
-
-The XmlFileStorageAdapter implementation stores configuration in an xml file.
-
-*XML Directory Storage* +
-
-XmlDirectoryStorageAdapter retrieves the initial configuration from a directory. If multiple xml files are present, files are ordered based on the file names and pushed in this order (for example, 00.xml, then 01.xml..) Each file defines its required capabilities, so it will be pushed when those capabilities are advertized by ODL. Writing to this persister is not supported.
-
-*No-Operation Storage* +
-
-NoOpStorageAdapter serves as a dummy implementation of the storage adapter.
-
-*Obsolete storage adapters* +
-
-* File Storage
-
-* FileStorageAdapter implements StorageAdapter, and provides file based configuration persisting.
-File path and name is stored as a property and a number of stored backups, expressing the count of the last configurations to be persisted too.
-The implementation can handle persisting input configuration, and load the last configuration.
-
-* Directory Storage
-
-* DirectoryStorageAdapter retrieves initial configurations from a directory. If multiple files are present, snapshot and required capabilities will be merged together. See configuration later on this page for details. Writing to this persister is not supported.
-
-* Autodetect Directory Storage
-
-* AutodetectDirectoryStorageAdapter retrieves initial configuration from a directory (exactly as Xml Directory Storage) but supports xml as well as plaintext format for configuration files. Xml and plaintext files can be combined in one directory. Purpose of this persister is to keep backwards compatibility for plaintext configuration files.
-
-IMPORTANT: This functionality will be removed in later releases since Plaintext File/Directory adapters are deprecated, and will be fully replaced by xml storage adapters.
-
-===== Persisted snapshot format
-
-Configuration snapshots are persisted in xml files for both file and directory adapters. They share the same format: +
-----
-<snapshot>
- <required-capabilities>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:netty?module=netty&revision=2013-11-19</capability>
- ...
- </required-capabilities>
- <configuration>
-
- <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- ...
- </modules>
-
- <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- ...
- </services>
-
- </data>
-
- </configuration>
-</snapshot>
-----
-The whole snapshot is encapsulated in the snapshot tag that contains two children elements: +
-
-* The required-capabilities tag contains the list of yang capabilities that are required to push configurations located under the configuration tag. The config persister will not push the configuration before the netconf endpoint for the config subsystem reports all needed capabilities. Every yang model that is referenced within this xml file (as namespace for xml tag) must be referenced as a capability in this list.
-* The configuration tag contains the configurations to be pushed to the config subsystem. It is wrapped in a data tag with the base netconf namespace. The whole data tag, with all its child elements, will be inserted into an edit-config rpc as config tag. For more information about the structure of configuration data, see base yang model for the config subsystem and all the configuration yang files for the controller modules as well as those provided examples. Examples contain multiple explained edit-config rpcs that change the configuration.
-
-NOTE: XML File adapter adds additional tags to the xml format since it supports multiple snapshots per file.
-
-The xml format for xml file adapter: +
-----
-<persisted-snapshots>
- <snapshots>
- <snapshot>
- <required-capabilities>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:shutdown:impl?module=shutdown-impl&revision=2013-12-18</capability>
- </required-capabilities>
- <configuration>
- <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- ....
- </modules>
- <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- ...
- </services>
- </data>
- </configuration>
- </snapshot>
- <snapshot>
- <required-capabilities>
- <capability>urn:opendaylight:params:xml:ns:yang:controller:shutdown:impl?module=shutdown-impl&revision=2013-12-18</capability>
- </required-capabilities>
- <configuration>
- <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- ....
- </modules>
- <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- ...
- </services>
- </data>
- </configuration>
- </snapshot>
- </snapshots>
-</persisted-snapshots>
-----
+++ /dev/null
-// https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Java_Code_Generator
-==== Java Code Generator
-
-===== YANG to Java code generator
-
-The Java code for the configuration system is generated by the yang-maven-plugin
-and the yang-jmx-generator-plugin.
-The input Yang module files are converted to java files by the definition of
-the module and the specified templates. the generated java code can represent
-interfaces, classes, or abstract classes used for configuration.
-
-====== Service interfaces generating
-
-Service interfaces (SI) are generated from YANG "service-types". Each SI must
-be defined as "identity" with a "base" statement set to "config:service-type",
-or another SI. This is because a service must have a globally unique name.
-Each SI must be annotated with @ServiceInterfaceAnnotation, and must extend
-AbstractServiceInterface.
-
-*Sample YANG module representing service interface* +
-
-----
-module config-test {
- yang-version 1;
- namespace "urn:opendaylight:params:xml:ns:yang:controller:test";
- prefix "test";
-
- import config { prefix config; revision-date 2013-04-05; }
-
- description
- "Testing API";
-
- revision "2013-06-13" {
- description
- "Initial revision";
- }
-
- identity testing {
- description
- "Test api";
-
- base "config:service-type";
- config:java-class "java.lang.AutoCloseable";
- }
-}
-----
-The "description" node of identity is generated as javadoc in the service interface. +
-The "config:java-class" is generated as *ServiceInterfaceAnnotation*. It specifies
-java classes or interfaces in the "osgiRegistrationTypes" parameter. The module
-implementing this service interface must instantiate a java object that can be
-cast to any of the java types defined in "osgiRegistrationTypes".
-
-*Generated java source file: AutoCloseableServiceInterface* +
-
-----
-package %prefix%.test;
-
-/**
-* Test api
-*/
-@org.opendaylight.controller.config.api.annotations.Description(value = "Test api")
-@org.opendaylight.controller.config.api.annotations.ServiceInterfaceAnnotation(value = "testing", osgiRegistrationType = java.lang.AutoCloseable.class)
-public interface AutoCloseableServiceInterface extends org.opendaylight.controller.config.api.annotations.AbstractServiceInterface
-{
-
-}
-----
-
-====== Module stubs generating
-
-Modules are constructed during configuration transaction. A module implements
-the ModuleMXBean interface. The ModuleMXBean interface represents getters and
-setters for attributes that will be exposed to the configuration registry by
-means of JMX. Attributes can either be simple types, or composite types.
-
-Each ModuleMXBean must be defined in yang as "identity" with the base statement
-set to "config:module-type". Not only are ModuleMXBeans generated, but also
-ModuleFactory and Module stubs. Both are first generated as abstract classes
-with almost full functionality. Then their implementations, which are allowed
-to be modified by users, are generated, but only once.
-
-===== Runtime beans generating
-
-Runtime JMX beans are purposed to be the auditors: they capture data about
-running module instances. A module can have zero or more runtime beans. Runtime
-beans are hierarchically ordered, and each must be uniquely identified.
-A runtime bean is defined as a configuration augment of a module, from which
-interface RuntimeMXBean, RuntimeRegistrator, and RuntimeRegistretion are generated.
-Augment definition contains arguments representing the data of a module that
-must be watched.
-
-===== RPCs
-
-Method calls in yang must be specified as top level elements. The context,
-where an RPC operation exits, must be defined in the RPC definition itself,
-and in the runtime bean that provides method implementation.
+++ /dev/null
-// FIXME: Probably deprecated
-// https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Logback#Logback_configuration:_Netconf
-=== OpenDaylight Controller Configuration: Logback Examples
-==== Logback Configuration Example
-
-The Logback logger configuration is part of the config subsystem. This module allows changes to the Logback configuration at runtime. It is used here as an example to demonstrate the YANG to Java code generator and to show how the configuration transaction works.
-
-==== Java code generation
-The logging configuration YANG module definition can be found in the config-logging.yang file. The code is generated by the yang-maven-plugin and yang-jmx-generator-plugin. The output java files are located as defined in the plugin configuration, where additional configuration parameters can be set. The logback module is defined as identity, with the base "config:module-type"; it does not provide or depend on any service interface.
-----
-identity logback {
- description
- "Actual state of logback configuration.";
- base config:module-type;
- config:java-name-prefix Logback;
-}
-----
-The next logback module attributes are defined in the "/config:modules/config:module/config:configuration" augment as the snippet below shows.
-----
-augment "/config:modules/config:module/config:configuration" {
- case logback {
- when "/config:modules/config:module/config:type = 'logback'";
-
- list console-appenders {
-
- leaf encoder-pattern {
- type string;
- mandatory true;
- }
-
- leaf threshold-filter {
- type string;
- default 'ALL';
- }
-
- leaf name {
- type string;;
- mandatory true;
- }
- config:java-name-prefix ConsoleAppenderTO;
- }
- ...
-----
-Now LogbackModule and LogbackModuleFactory can be generated. In fact, three more java files related to this module will be generated. By the augment definition, TypeObjects too are generated (that is to say, ConsoleAppenderTO). They are regular java classes with getters and setters for arguments defined as leaves.
-
-* *LogbackModuleMXBean* is the interface containing getters and setters for attributes defined in the configuration augment.
-* *AbstractLogbackModule* is the abstract java class, which implements Module, RuntimeBeanRegistratorAwareModule, and LogbackModuleMXBean. It contains almost all functionality, except validate and createInstance methods.
-* *AbstractLogbackModuleFactory* is the abstract java class responsible for creating module instances. It implements the ModuleFactory interface.
-* *LogbackModule* class extends AbstractLogbackModule. It is located in a different place (source/main/java) and can be modified by the user, so that the abstract method is implemented and the validate method is overridden.
-* *LogbackModuleFactory* class extends AbstractLogbackModuleFactory and overrides its instantiateModule methods.
-Next, the runtime bean is defined in the "/config:modules/config:module/config:state" augment. +
-----
-augment "/config:modules/config:module/config:state" {
- case logback {
- when "/config:modules/config:module/config:type = 'logback'";
-
- rpcx:rpc-context-instance "logback-rpc";
-
- list status {
- config:java-name-prefix StatusTO;
-
- leaf level {
- type string;
- }
-
- leaf message {
- type string;
- }
-
- leaf date {
- type uint32;
- }
- }
- }
-}
-----
-* The *Generator* plugin creates another set of java files.
-* *LogbackRuntimeMXBean* is the interface extending RuntimeBean. It contains the getter method for the argument defined in the augment.
-* *LogbackRuntimeRegistrator* class serves as the registrator for runtime beans.
-* *LogbackRuntimeRegistration* class serves as the registration ticket. An instance is returned after registration.
-
-The Logback config also defines logback-rpc with the reset method. It is also defined in the state augment, owing to the context.
-----
-identity logback-rpc;
-rpc reset {
- input {
- uses rpcx:rpc-context-ref {
- refine context-instance {
- rpcx:rpc-context-instance logback-rpc;
- }
- }
- }
-}
-----
-The Reset method is defined in the LogbackRuntimeMXBean interface.
-
-==== Logback configuration: Jolokia
-
-To create configuration on the running OSGi server: Jolokia (http://www.jolokia.org/) is used as a JMX-HTTP bridge, which listens at http://localhost:8080/controller/nb/v2/jolokia and curl to request over HTTP.
-
-. Start the controller. Find more here: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Pulling,_Hacking,_and_Pushing_the_Code_from_the_CLI
-. Request Jolokia:
-----
-curl http://localhost:8080/controller/nb/v2/jolokia --user admin:admin
-----
-The response must resemble the following: +
-----
-{
- "timestamp": 1382425537,
- "status": 200,
- "request": {
- "type": "version"
- },
- "value": {
- "protocol": "7.0",
- "agent": "1.1.1",
- "info": {
- "product": "equinox",
- "vendor": "Eclipse",
- "version": "3.8.1.v20120830-144521"
- }
- }
-}
-----
-Jolokia is working.
-To configure Logback, first, create a configuration transaction. ConfigResgistryModule offers the operation beginConfig(), and to invoke it:
-----
-curl -X POST -H "Content-Type: application/json" -d '{"type":"exec","mbean":"org.opendaylight.controller:type=ConfigRegistry","arguments":[],"operation":"beginConfig"}' http://localhost:8080/controller/nb/v2/jolokia --user admin:admin
-----
-The configuration transaction was created. The response received: +
-----
-{
- "timestamp": 1383034210,
- "status": 200,
- "request": {
- "operation": "beginConfig",
- "mbean": "org.opendaylight.controller:type=ConfigRegistry",
- "type": "exec"
- },
- "value": {
- "objectName": "org.opendaylight.controller:TransactionName=ConfigTransaction-1-2,type=ConfigTransaction"
- }
-}
-----
-At this stage, the transaction can be aborted, but we want to create the module bean to be configured. In the created ConfigTransaction call createModule method, the module identifier is logback, and the name must be singleton as only one instance of the Logback configuration is needed.
-----
-curl -X POST -H "Content-Type: application/json" -d '{"type":"exec","mbean":"org.opendaylight.controller:TransactionName=ConfigTransaction-1-2,type=ConfigTransaction","arguments":["logback","singleton"],"operation":"createModule"}' http://localhost:8080/controller/nb/v2/jolokia --user admin:admin
-----
-The LogbackModule bean was created. The response returned:
-----
-{
- "timestamp": 1383034580,
- "status": 200,
- "request": {
- "operation": "createModule",
- "mbean": "org.opendaylight.controller:TransactionName=ConfigTransaction-1-2,type=ConfigTransaction",
- "arguments": [
- "logback",
- "singleton"
- ],
- "type": "exec"
- },
- "value": {
- "objectName": "org.opendaylight.controller:TransactionName=ConfigTransaction-1-2,instanceName=singleton,moduleFactoryName=logback,type=Module"
- }
-}
-----
-* The configuration bean attributes are set to values obtained from the loggers configuration, with which the server was started. To see attributes, request:
-----
-curl -X POST -H "Content-Type: application/json" -d '{"type":"read", "mbean":"org.opendaylight.controller:instanceName=singleton,TransactionName=ConfigTransaction-1-2,type=Module,moduleFactoryName=logback"}' http://localhost:8080/controller/nb/v2/jolokia --user admin:admin
-----
-In the response body, the value contains all attributes (CompositeData) and its nested attribute values.
-* Now, the proposed configuration can be committed.
-----
-curl -X POST -H "Content-Type: application/json" -d '{"type":"exec","mbean":"org.opendaylight.controller:type=ConfigRegistry","arguments":["org.opendaylight.controller:instanceName=singleton,TransactionName=ConfigTransaction-1-2,type=Module,moduleFactoryName=logback"],"operation":"commitConfig"}' http://localhost:8080/controller/nb/v2/jolokia --user admin:admin
-----
-The configuration was successfully validated and committed, and the module instance created.
-----
-{
- "timestamp": 1383034793,
- "status": 200,
- "request": {
- "operation": "commitConfig",
- "mbean": "org.opendaylight.controller:type=ConfigRegistry",
- "arguments": [
- "org.opendaylight.controller:instanceName=singleton,TransactionName=ConfigTransaction-1-2,type=Module,moduleFactoryName=logback"
- ],
- "type": "exec"
- },
- "value": {
- "newInstances": [
- {
- "objectName": "org.opendaylight.controller:instanceName=singleton,moduleFactoryName=logback,type=Module"
- }
- ],
- "reusedInstances": [],
- "recreatedInstances": []
- }
-}
-----
-* The runtime bean was registered, and can provide the status information of the configuration and rpc operation reset. To see the status, try requesting:
-----
-curl -X POST -H "Content-Type: application/json" -d '{"type":"read","mbean":"org.opendaylight.controller:instanceName=singleton,type=RuntimeBean,moduleFactoryName=logback"}' http://localhost:8080/controller/nb/v2/jolokia --user admin:admin
-----
-The entire logback status is in the response body.
-
-* To invoke the rpc method reset:
-----
-curl -X POST -H "Content-Type: application/json" -d '{"type":"exec",
-"mbean":"org.opendaylight.controller:instanceName=singleton,type=RuntimeBean,moduleFactoryName=logback",
-"operation":"reset","arguments":[]}' http://localhost:8080/controller/nb/v2/jolokia --user admin:admin
-----
-The answer:
-----
-{
- "timestamp": 1383035001,
- "status": 200,
- "request": {
- "operation": "reset",
- "mbean": "org.opendaylight.controller:instanceName=singleton,moduleFactoryName=logback,type=RuntimeBean",
- "type": "exec"
- },
- "value": null
-}
-----
-Now, the runtime bean status attribute will be empty:
-----
-{
- "timestamp": 1383035126,
- "status": 200,
- "request": {
- "mbean": "org.opendaylight.controller:instanceName=singleton,moduleFactoryName=logback,type=RuntimeBean",
- "type": "read"
- },
- "value": {
- "StatusTO": []
- }
-}
-----
-==== Logback configuration: NETCONF
-
-In this case, NETCONF RPCs are used to configure logback. The Netconf server listens at port 8383. To communicate over TCP, telnet is used. More about NETCONF is available at: http://tools.ietf.org/html/rfc6241. Netconf implementation is a part of the Controller - netconf-subsystem. The RPCs of Netconf are XML, and the operations are mapped to JMX operations.
-* A server re-start is required. The procedure is the same as above.
-* Open a terminal and connect to the server:
-----
-telnet localhost 8383
-----
-A Hello message received from the server contains the server capabilities and session-id. To establish connection to the client,send a hello message:
-----
-<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <capabilities>
- <capability>urn:ietf:params:netconf:base:1.0</capability>
- </capabilities>
-</hello>
-]]>]]>
-----
-* With the connection created, the client and server can communicate. To see the running modules and services, send an RPC to the server:
-----
-<rpc id="a" a="64" xmlnx="a:b:c:d" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
- <get-config>
- <source>
- <running/>
- </source>
- </get-config>
-</rpc>
-]]>]]>
-----
-
-* To configure logback, create a configuration transaction, and create a configuration module. It can be done in one step (in client point of view):
-----
-<rpc message-id="a" a="64" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <edit-config>
- <target>
- <candidate/>
- </target>
- <default-operation>merge</default-operation>
- <config>
- <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <module>
- <name>singleton</name>
- <type xmlns:logging="urn:opendaylight:params:xml:ns:yang:controller:logback:config">
- logging:logback
- </type>
- </module>
- </modules>
- </config>
- </edit-config>
-</rpc>
-]]>]]>
-----
-
-If the configuration worked, the client receives a positive response:
-
-----
-<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
-<ok/>
-</rpc-reply>
-]]>]]>
-----
-
-* The Logback configuration bean attributes contain values loaded from the running Logback configuration. Send a request to the server with an RPC:
-----
-<rpc id="a" a="64" xmlnx="a:b:c:d" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
- <get-config>
- <source>
- <candidate/>
- </source>
- </get-config>
-</rpc>
-]]>]]>
-----
-
-* The reply includes the entire configuration that started the server. Assume that we want to change the RollingFileAppender named opendaylight.log attributes - maxFileSize, filename, and maxHistory. ( attribute of TimeBasedRollingPolicy). The proposed configuration:
-
-----
-<rpc message-id="a" a="64" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <edit-config>
- <target>
- <candidate/>
- </target>
- <default-operation>merge</default-operation>
- <config>
- <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <module>
- <name>singleton</name>
- <type xmlns:logging="urn:opendaylight:params:xml:ns:yang:controller:logback:config">
- logging:logback
- </type>
- <rolling-appenders xmlns="urn:opendaylight:params:xml:ns:yang:controller:logback:config">
- <append>true</append>
- <max-file-size>5MB</max-file-size>
- <file-name>logs/opendaylight-new.log</file-name>
- <name>opendaylight.log</name>
- <file-name-pattern>logs/opendaylight.%d.log.zip</file-name-pattern>
- <encoder-pattern>%date{"yyyy-MM-dd HH:mm:ss.SSS z"} [%thread] %-5level %logger{35} - %msg%n</encoder-pattern>
- <clean-history-on-start>false</clean-history-on-start>
- <max-history>7</max-history>
- <rolling-policy-type>TimeBasedRollingPolicy</rolling-policy-type>
- </rolling-appenders>
- </module>
- </modules>
- </config>
- </edit-config>
-</rpc>
-]]>]]>
-----
-This configuration is merged with the proposed module configuration. If it passes the validation process successfully, an "ok" reply is received.
-
-* The configuration bean is ready to be committed:
-----
-<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
- <commit></commit>
-</rpc>
-]]>]]>
-----
-If successful, the ok message is received obtained, and the logback configuration is set. To verify, look into the logs directory to find a new log file named opendaylight-new.log
-
-* Correctly close the session with the session-id:
-----
-<rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <close-session xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
-</rpc>
-]]>]]>
-----
+++ /dev/null
-// https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Sample_Project#Generated_java_files
-==== Example sample project
-*Sample maven project* +
-
-In this example, we will create a maven project that provides two modules, each implementing one service. We will design a simple configuration, as well as runtime data for each module using yang.
-A sample maven project called config-demo was created. This project contains two Java interfaces: Foo and Bar. Each interface has one default implementation per interface, FooImpl and BarImpl. Bar is the producer in our example and produces integers when the method getNextEvent() is called. Foo is the consumer, and its implementation depends on a Bar instance. Both implementations require some configuration that is injected by means of constructors.
-
-* Bar.java:
-----
-package org.opendaylight.controller.config.demo;
-
-public interface Bar {
-
- int getNextEvent();
-
-}
-----
-* BarImpl.java:
-----
-package org.opendaylight.controller.config.demo;
-
-public class BarImpl implements Bar {
-
- private final int l1, l2;
- private final boolean b;
-
- public BarImpl(int l1, int l2, boolean b) {
- this.l1 = l1;
- this.currentL = l1;
- this.l2 = l2;
- this.b = b;
- }
-
- private int currentL;
-
- @Override
- public int getNextEvent() {
- if(currentL==l2)
- return -1;
- return currentL++;
- }
-}
-----
-* Foo.java:
-----
-package org.opendaylight.controller.config.demo;
-
-public interface Foo {
-
- int getEventCount();
-}
-----
-* FooImpl.java:
-----
-package org.opendaylight.controller.config.demo;
-
-public class FooImpl implements Foo {
-
- private final String strAttribute;
- private final Bar barDependency;
- private final int intAttribute;
-
- public FooImpl(String strAttribute, int intAttribute, Bar barDependency) {
- this.strAttribute = strAttribute;
- this.barDependency = barDependency;
- this.intAttribute = intAttribute;
- }
-
- @Override
- public int getEventCount() {
- int count = 0;
- while(barDependency.getNextEvent() != intAttribute) {
- count++;
- }
- return count;
- }
-}
-----
-* pom.xml (config-demo project is defined as a sub-module of the controller project, and at this point contains only the configuration for maven-bundle-plugin):
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
- <modelVersion>4.0.0</modelVersion>
-
- <parent>
- <artifactId>commons.opendaylight</artifactId>
- <groupId>org.opendaylight.controller</groupId>
- <version>1.4.1-SNAPSHOT</version>
- <relativePath>../commons/opendaylight/pom.xml</relativePath>
- </parent>
- <groupId>org.opendaylight.controller</groupId>
- <version>0.1.1-SNAPSHOT</version>
- <artifactId>config-demo</artifactId>
- <packaging>bundle</packaging>
- <name>${project.artifactId}</name>
- <prerequisites>
- <maven>3.0.4</maven>
- </prerequisites>
-
- <build>
- <plugins>
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-bundle-plugin</artifactId>
- <version>2.4.0</version>
- <extensions>true</extensions>
- <configuration>
- <instructions>
- <Bundle-Name>${project.groupId}.${project.artifactId}</Bundle-Name>
- <Export-Package>
- org.opendaylight.controller.config.demo,
- </Export-Package>
- </instructions>
- </configuration>
- </plugin>
- </plugins>
- </build>
-
-</project>
-----
-
-==== Describing the module configuration using yang
-In order to fully leverage the utilities of the configuration subsystem, we need to describe the services, modules, their configurations, and the runtime state using the yang modeling language. We will define two services and two modules, which will be used to configure the instances of FooImpl and BarImpl. This definition will be split into two yang files: config-demo.yang (service definition) and config-demo-impl.yang (module definition).
-
-* config-demo.yang
-----
-module config-demo {
- yang-version 1;
- namespace "urn:opendaylight:params:xml:ns:yang:controller:config:demo";
- prefix "demo";
-
- import config { prefix config; revision-date 2013-04-05; }
-
- description
- "Service definition for config-demo";
-
- revision "2013-10-14" {
- description
- "Initial revision";
- }
-
- // Service definition for service foo that encapsulates instances of org.opendaylight.controller.config.demo.Foo
- identity foo {
- description
- "Foo service definition";
-
- base "config:service-type";
- config:java-class "org.opendaylight.controller.config.demo.Foo";
- }
-
- identity bar {
- description
- "Bar service definition";
-
- base "config:service-type";
- config:java-class "org.opendaylight.controller.config.demo.Bar";
- }
-}
-----
-The config yang module needs to be imported in order to define the services. There are two services defined, and these services correspond to the Java interfaces Foo and Bar (specified by the config:java-class extension).
-
-* config-demo-impl.yang
-----
-module config-demo-impl {
-
- yang-version 1;
- namespace "urn:opendaylight:params:xml:ns:yang:controller:config:demo:java";
- prefix "demo-java";
-
- // Dependency on service definition for config-demo
- /* Service definitions could be also located in this yang file or even
- * in a separate maven project that is marked as maven dependency
- */
- import config-demo { prefix demo; revision-date 2013-10-14;}
-
- // Dependencies on config subsystem definition
- import config { prefix config; revision-date 2013-04-05; }
- import rpc-context { prefix rpcx; revision-date 2013-06-17; }
-
-
- description
- "Service implementation for config-demo";
-
- revision "2013-10-14" {
- description
- "Initial revision";
- }
- //----- module foo-impl ----- //
- // Module implementing foo service //
- identity foo-impl { //
- base config:module-type; //
- config:provided-service demo:foo; //
- config:java-name-prefix FooImpl; //
- } //
- //
- // Configuration for foo-impl module //
- augment "/config:modules/config:module/config:configuration" { //
- case foo-impl { //
- when "/config:modules/config:module/config:type = 'foo-impl'"; //
- //
- leaf str-attribute { //
- type string; //
- } //
- //
- leaf int-attribute { //
- type int32; //
- } //
- //
- //
- // Dependency on bar service instance //
- container bar-dependency { //
- uses config:service-ref { //
- refine type { //
- mandatory true; //
- config:required-identity demo:bar; //
- } //
- } //
- } //
- //
- } //
- } //
- //
- // Runtime state definition for foo-impl module //
- augment "/config:modules/config:module/config:state" { //
- case foo-impl { //
- when "/config:modules/config:module/config:type = 'foo-impl'"; //
- //
- //
- } //
- } //
- // ---------- //
- // Module implementing bar service
- identity bar-impl {
- base config:module-type;
- config:provided-service demo:bar;
- config:java-name-prefix BarImpl;
- }
-
- augment "/config:modules/config:module/config:configuration" {
- case bar-impl {
- when "/config:modules/config:module/config:type = 'bar-impl'";
-
- container dto-attribute {
- leaf int-attribute {
- type int32;
- }
-
- leaf int-attribute2 {
- type int32;
- }
-
- leaf bool-attribute {
- type boolean;
- }
- }
-
- }
- }
-
- augment "/config:modules/config:module/config:state" {
- case bar-impl {
- when "/config:modules/config:module/config:type = 'bar-impl'";
-
- }
- }
-
-}
-----
-The config yang module as well as the config-demo yang module need to be imported. There are two modules defined: foo-impl and bar-impl. Their configuration (defined in the augment "/config:modules/config:module/config:configuration" block) corresponds to the configuration of the FooImpl and BarImpl Java classes. In the constructor of FooImpl.java, we see that the configuration of foo-impl module defines three similar attributes. These arguments are used to instantiate the FooImpl class. These yang files are placed under the src/main/yang folder.
-
-==== Updating the maven configuration in pom.xml
-
-The yang-maven-plugin must be added to the pom.xml. This plugin will process the yang files, and generate the configuration code for the defined modules. Plugin configuration: +
-----
-<plugin>
- <groupId>org.opendaylight.yangtools</groupId>
- <artifactId>yang-maven-plugin</artifactId>
- <version>${yangtools.version}</version>
- <executions>
- <execution>
- <goals>
- <goal>generate-sources</goal>
- </goals>
- <configuration>
- <codeGenerators>
- <generator>
- <codeGeneratorClass>
- org.opendaylight.controller.config.yangjmxgenerator.plugin.JMXGenerator
- </codeGeneratorClass>
- <outputBaseDir>${project.build.directory}/generated-sources/config</outputBaseDir>
- <additionalConfiguration>
- <namespaceToPackage1>
- urn:opendaylight:params:xml:ns:yang:controller==org.opendaylight.controller.config.yang
- </namespaceToPackage1>
- </additionalConfiguration>
- </generator>
- </codeGenerators>
- <inspectDependencies>true</inspectDependencies>
- </configuration>
- </execution>
- </executions>
- <dependencies>
- <dependency>
- <groupId>org.opendaylight.controller</groupId>
- <artifactId>yang-jmx-generator-plugin</artifactId>
- <version>${config.version}</version>
- </dependency>
- </dependencies>
-</plugin>
-----
-The configuration important for the plugin: the output folder for the generated files, and the mapping between the yang namespaces and the java packages (Inspect dependencies must be set to true.). The default location for the yang files is under the src/main/yang folder. This plugin is backed by the artifact yang-jmx-generator-plugin and its class org.opendaylight.controller.config.yangjmxgenerator.plugin.JMXGenerator is responsible for code generation. This artifact is part of the configuration subsystem.
-
-In addition to the yang-maven-plugin, it is neccessary to add the build-helper-maven-plugin in order to add the generated sources to the build process:
-----
-<plugin>
- <groupId>org.codehaus.mojo</groupId>
- <artifactId>build-helper-maven-plugin</artifactId>
- <version>1.8</version>
- <executions>
- <execution>
- <id>add-source</id>
- <phase>generate-sources</phase>
- <goals>
- <goal>add-source</goal>
- </goals>
- <configuration>
- <sources>
- <source>${project.build.directory}/generated-sources/config</source>;
- </sources>
- </configuration>
- </execution>
- </executions>
-</plugin>
-----
-Earlier, the configuration yang module in the yang files was imported. In order to acquire this yang module, we need to add a dependency to the pom file:
-----
-<dependency>
- <groupId>org.opendaylight.controller</groupId>
- <artifactId>config-api</artifactId>
- <version>${config.version}</version>
-</dependency>
-----
-In addition, a couple of utility dependencies must be added:
-----
-<dependency>
- <groupId>org.slf4j</groupId>
- <artifactId>slf4j-api</artifactId>
-</dependency>
-<dependency>
- <groupId>com.google.guava</groupId>
- <artifactId>guava</artifactId>
-</dependency>
-----
-Run *mvn clean install*.
-
-==== Generated java files
-
-A set of new source files divided into two groups is seen. The first group is located under the ${project.build.directory}/generated-sources/config directory, which was specified in the yang-maven-plugin configuration. The second group is located under the src/main/java directory. Both groups then define the package org.opendaylight.controller.config.yang.config.demo.impl. The first group contains code that must not be edited in any way, since this code can be regenerated by the plugin if necessary. The code that needs to be edited belongs to the second group and is located under src/main/java.
-
-===== Generated config source files examples
-
-* BarImplModuleMXBean.java
-----
-public interface BarImplModuleMXBean
-{
- public org.opendaylight.controller.config.yang.config.demo.java.DtoAttribute getDtoAttribute();
-
- public void setDtoAttribute(org.opendaylight.controller.config.yang.config.demo.java.DtoAttribute dtoAttribute);
-
-}
-----
-The BarImplModuleMXBean interface represents the getter and the setter for dtoAttribute that will be exported to the configuration registry by means of JMX. The attribute was defined in the yang model: in this case, it is the composite type which was converted to OpenType.
-
-* Attribute definition from config-demo-impl.yang
-----
-// Module implementing bar service
- identity bar-impl {
- base config:module-type;
- config:provided-service demo:foo;
- config:java-name-prefix BarImpl;
- }
-
- augment "/config:modules/config:module/config:configuration" {
- case bar-impl {
- when "/config:modules/config:module/config:type = 'bar-impl'";
-
- container dto-attribute {
- leaf int-attribute {
- type int32;
- }
-
- leaf int-attribute2 {
- type int32;
- }
-
- leaf bool-attribute {
- type boolean;
- }
- }
-
- }
- }
-----
-From the container dto-attribute, the DtoAttribute java file was generated. The Class contains the plain constructor, and the getters and setters for the attributes defined as container leaves.
-Not only is ModuleMXBean generated from this module definition, but also BarImplModuleFactory and BarImplModule stubs (in fact AbstractBarImplModuleFactory and AbstractBarImplModule are generated too.).
-
-* AbstractBarImplModule.java +
-This abstract class is almost fully generated: only the method validate() has an empty body and the method createInstance() is abstract. The user must implement both methods by user. AbstractBarImplModule implements its ModuleMXBean, Module, RuntimeBeanRegistratorAwareModule, and the dependent service interface as defined in yang. Moreover, the class contains two types of constructors: one for the module created from the old module instance, and the second for module creation from scratch.
-
-* AbstractBarImplModuleFactory.java +
-Unlike AbstractModule, AbstractFactory is fully generated, but it is still an abstract class. The factory is responsible for module instances creation, and provides two type of instantiateModule methods for both module constructor types. It implements the ModuleFactory interface.
-
-Next, create the runtime bean for FooImplModule. Runtime beans are designated to capture data about the running module.
-
-* Add runtime bean definition to config-demo-impl.yang +
-
-===== Modifying generated sources
-
-Generated source files: +
-
-* src/main/java/**/BarImplModule
-* src/main/java/**/BarImplModuleFactory
-* src/main/java/**/FooImplModule
-* src/main/java/**/FooImplModuleFactory
-
-*BarImplModule* +
-We will start by modifying BarImplModule. Two constructors and two generated methods are seen:
-----
-@Override
- public void validate(){
- super.validate();
- // Add custom validation for module attributes here.
- }
-
- @Override
- public java.lang.AutoCloseable createInstance() {
- //TODO:implement
- throw new java.lang.UnsupportedOperationException("Unimplemented stub method");
- }
-----
-In *validate*, specify the validation for configuration attributes, for example:
-----
-@Override
- public void validate(){
- super.validate();
- Preconditions.checkNotNull(getDtoAttribute());
- Preconditions.checkNotNull(getDtoAttribute().getBoolAttribute());
- Preconditions.checkNotNull(getDtoAttribute().getIntAttribute());
- Preconditions.checkNotNull(getDtoAttribute().getIntAttribute2());
- Preconditions.checkState(getDtoAttribute().getIntAttribute() > getDtoAttribute().getIntAttribute2());
- }
-----
-In *createInstance* you need to create a new instance of the bar service => Bar interface, for example:
-----
-@Override
- public java.lang.AutoCloseable createInstance() {
- return new BarImpl(getDtoAttribute().getIntAttribute(), getDtoAttribute().getIntAttribute2(), getDtoAttribute()
- .getBoolAttribute());
- }
-----
-===== Notes:
-
-* createInstance returns AutoCloseable so the returned type needs to implement it. (You can make BarImpl implement AutoCloseable, or create a Wrapper class around the BarImpl instance that implements AutoCloseable, or even extend the BarImpl class and make it implement it.)
-* You can access all the configuration attributes by means of the getter methods.
-* In config-demo-impl.yang, we defined the bar-impl configuration as a container dto-attribute. The code generator creates a transfer object DtoAttribute that you can access by means of the getDtoAttribute() method, and retrieve configuration data from it. You can even add a new constructor to BarImpl that takes this transfer object, and reduces the number of arguments.
-
-*FooImplModule* +
-We will not add any custom validation in this module. The createInstance method will look as follows: +
-----
- @Override
- public java.lang.AutoCloseable createInstance() {
- return new FooImpl(getStrAttribute(), getIntAttribute(), getBarDependencyDependency());
- }
-----
-===== Adding support for default instances
-
-In order to provide a default instance of module bar-impl, we need to further modify the generated code by the overriding method getDefaultModules in src/main/java/**/BarImplModuleFactory class. The body of this class is empty thus far, and it inherits the default behaviour from its parent abstract factory. Use the following code to replace the empty body:
-----
-public static final ModuleIdentifier defaultInstance1Id = new ModuleIdentifier(NAME, "defaultInstance1");
-
- @Override
- public Set<BarImplModule> getDefaultModules(DependencyResolverFactory dependencyResolverFactory, BundleContext bundleContext) {
- DependencyResolver depResolver1 = dependencyResolverFactory.createDependencyResolver(defaultInstance1Id);
- BarImplModule defaultModule1 = new BarImplModule(defaultInstance1Id, depResolver1);
- defaultModule1.setDtoAttribute(getDefaultConfiguration(bundleContext));
-
- return Sets.newHashSet(defaultModule1);
- }
-
- private DtoAttribute getDefaultConfiguration(BundleContext bundleContext) {
- DtoAttribute defaultConfiguration = new DtoAttribute();
-
- String property = bundleContext.getProperty("default.bool");
- defaultConfiguration.setBoolAttribute(property == null ? false : Boolean.parseBoolean(property));
-
- property = bundleContext.getProperty("default.int1");
- defaultConfiguration.setIntAttribute(property == null ? 55 : Integer.parseInt(property));
-
- property = bundleContext.getProperty("default.int2");
- defaultConfiguration.setIntAttribute2(property == null ? 0 : Integer.parseInt(property));
-
- return defaultConfiguration;
- }
-----
-The _getDefaultModules_ method now produces an instance of the bar-impl module with the name _defaultInstance1_. (It is possible to produce multiple default instances since the return type is a Set of module instances.) Note the getDefaultConfiguration method. It provides the default configuration for default instances by trying to retrieve system properties from bundleContext (or provides hardcoded values in case the system property is not present).
-
-For the controller distribution, system properties can be fed by means of _config.ini_ file.
-
-The method _getDefaultModules_ is called automatically after a bundle containing this factory is started in the OSGi environment. Its default implementation returns an empty Set.
-
-The default instances approach is similar to the Activator class approach in OSGi with the advantage of default instances being managed by the configuration subsystem. This approach can either replace the Activator class approach, or be used along with it.
-
-*Verifying the default instances in distribution* +
-
-If we add the config-demo bundle to the opendaylight distribution, we can verify the presence of the default instance. The file pom.xml under the opendaylight/distribution/opendaylight folder needs to be modified by adding the config-demo dependency:
-----
-<dependency>
- <groupId>${project.groupId}</groupId>
- <artifactId>config-demo</artifactId>
- <version>0.1.1-SNAPSHOT</version>
-</dependency>
-----
-Now we need to rebuild the conf-demo module using mvn clean install. Then, we can build the distribution using the same mvn command under the _opendaylight/distribution/opendaylight_ folder. If we go to the _opendaylight/distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight_ folder, and execute run.sh, the opendaylight distribution should start.
-
-We can check the presence of the default instances by means of JMX using a tool such as _jvisualvm_.
+++ /dev/null
-=== Examples of Threadpool
-
-=== Configuration example of thread pools using yangcli-pro
-
-For a yangcli-pro example, see the https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:User_guide[Examples User Guide].
-
-=== Configuration example of thread pools using telnet
-It is also possible to manipulate the configuration without the yuma cli. With just a telnet or ssh connection, it is possible to send the plain text containing netconf rpcs encoded in the xml format and achieve the same results as with yuma cli.
-
-This example reproduces the configuration of a threadpool and a threadfactory from the previous example using just a telnet connection. We can also use ssh connection, with the netconf rpcs sending procedure remaining the same. For detailed information about initial configuration for the controller as well as the configuration process, see the example using yuma cli.
-
-=== Connecting to plaintext TCP socket
-
-. Open a telnet connection:
-----
-telnet 127.0.0.1 8383
-----
-[start=2]
-. Open an ssh connection:
-----
-ssh netconf@127.0.0.1 -p 1830 -s netconf
-----
-The password for user netconf is : netconf, and the separator for the messages is: +
-----
-]]>]]>
-----
-Every message needs end with these 6 characters.
-
-The server sends a hello message: +
-----
-<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
-<capabilities>
-<capability>urn:ietf:params:netconf:base:1.0</capability>
-<capability>urn:ietf:params:netconf:capability:exi:1.0</capability>
-<capability>urn:opendaylight:l2:types?module=opendaylight-l2-types&revision=2013-08-27</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:controller:netty:threadgroup?module=threadgroup&revision=2013-11-07</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding?module=opendaylight-md-sal-binding&revision=2013-10-28</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:controller:threadpool?module=threadpool&revision=2013-04-09</capability>
-<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:controller:config?module=config&revision=2013-04-05</capability>
-<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&revision=2010-10-04</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:controller:netty:eventexecutor?module=netty-event-executor&revision=2013-11-12</capability>
-<capability>urn:ietf:params:xml:ns:yang:rpc-context?module=rpc-context&revision=2013-06-17</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl?module=opendaylight-sal-binding-broker-impl&revision=2013-10-28</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:controller:netty:timer?module=netty-timer&revision=2013-11-19</capability>
-<capability>urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2010-09-24</capability>
-<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl?module=threadpool-impl&revision=2013-04-05</capability>
-<capability>urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&revision=2010-09-24</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:controller:logback:config?module=config-logging&revision=2013-07-16</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:iana?module=iana&revision=2013-08-16</capability>
-<capability>urn:opendaylight:yang:extension:yang-ext?module=yang-ext&revision=2013-07-09</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:controller:netty?module=netty&revision=2013-11-19</capability>
-<capability>http://netconfcentral.org/ns/toaster?module=toaster&revision=2009-11-20</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:ieee754?module=ieee754&revision=2013-08-19</capability>
-<capability>urn:opendaylight:params:xml:ns:yang:nps-concepts?module=nps-concepts&revision=2013-09-30</capability>
-</capabilities>
-
-<session-id>4</session-id>
-</hello>
-]]>]]>
-----
-[start=3]
-. As the client, you must respond with a hello message:
-----
-<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <capabilities>
- <capability>urn:ietf:params:netconf:base:1.0</capability>
- </capabilities>
-</hello>
-]]>]]>
-----
-Although there is no response to the hello message, the session is already established.
-
-=== Configuring threadfactory
-
-. The following is the Xml equivalent to *get-config source=running*: +
-----
-<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
- <get-config>
- <source>
- <running/>
- </source>
- </get-config>
-</rpc>
-]]>]]>
-----
-The response containing the current configuration: +
-----
-<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
- <data>
- <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">prefix:binding-broker-impl-singleton</type>
- <name>binding-broker-singleton</name>
- </module>
- </modules>
- <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <service>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-broker-osgi-registry</type>
- <instance>
- <name>ref_binding-broker-singleton</name>
- <provider>/modules/module[type='binding-broker-impl-singleton'][name='binding-broker-singleton']</provider>
- </instance>
- </service>
- </services>
- </data>
-</rpc-reply>]]>]]>
-----
-[start=2]
-. To create an instance of threadfactory-naming with the name threadfactory-bgp, and the attribute name-prefix set to bgp, send the message:
-----
-<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <edit-config>
- <target>
- <candidate/>
- </target>
- <default-operation>merge</default-operation>
- <config>
- <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <module xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
- <name>threadfactory-bgp</name>
- <type xmlns:th-java="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">th-java:threadfactory-naming</type>
- <name-prefix xmlns="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">bgp</name-prefix>
- </module>
- </modules>
- </config>
- </edit-config>
-</rpc>]]>]]>
-----
-[start=3]
-. To commit the threadfactory instance, send a commit message:
-----
-<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <commit/>
-</rpc>]]>]]>
-----
-The NETCONF endpoint should respond with ok to edit-config, as well as the commit message: +
-
-----
-<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
- <ok/>
-</rpc-reply>]]>]]>
-----
-[start=4]
-. The response to the get-config message (the same as the first message sent in this example) should contain the commited instance of threadfactory-naming:
-----
-<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
- <data>
- <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding:impl">prefix:binding-broker-impl-singleton</type>
- <name>binding-broker-singleton</name>
- </module>
-
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">prefix:threadfactory-naming</type>
- <name>threadfactory-bgp</name>
- <name-prefix xmlns="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">bgp</name-prefix>
- </module>
- </modules>
-
- <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <service>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:threadfactory</type>
- <instance>
- <name>ref_threadfactory-bgp</name>
- <provider>/modules/module[type='threadfactory-naming'][name='threadfactory-bgp']</provider>
- </instance>
- </service>
- <service>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-broker-osgi-registry</type>
- <instance>
- <name>ref_binding-broker-singleton</name>
- <provider>/modules/module[type='binding-broker-impl-singleton'][name='binding-broker-singleton']</provider>
- </instance>
- </service>
- </services>
- </data>
-</rpc-reply>]]>]]>
-----
-=== Configuring fixed threadpool
-
-* To create an instance of *threadpool-fixed* , with the same configuration and the same dependency as before, send the following message:
-
-----
-<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <edit-config>
- <target>
- <candidate/>
- </target>
- <default-operation>merge</default-operation>
- <config>
- <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <module xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
- <name>bgp-threadpool</name>
- <type xmlns:th-java="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">th-java:threadpool-fixed</type>
- <max-thread-count xmlns="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">100</max-thread-count>
- <threadFactory xmlns="urn:opendaylight:params:xml:ns:yang:controller:threadpool:impl">
- <type xmlns:th="urn:opendaylight:params:xml:ns:yang:controller:threadpool">th:threadfactory</type>
- <name>ref_th-bgp</name>
- </threadFactory>
- </module>
- </modules>
-
- <services xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <service>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:threadfactory</type>
- <instance>
- <name>ref_th-bgp</name>
- <provider>/modules/module[type='threadfactory-naming'][name='threadfactory-bgp']</provider>
- </instance>
- </service>
- </services>
- </config>
- </edit-config>
-</rpc>]]>]]>
-----
-Notice the _services_ tag. If an instance is to be referenced as a dependency by another module, it needs to be placed under this tag as a service instance with a unique reference name. Tag _provider_ points to a unique instance that is already present in the config subsystem, or is created within the current edit-config operation.
-The tag _name_ contains the reference name that can be referenced by other modules to create a dependency. In this case, a new instance of threadpool uses this reference in its configuration under the _threadFactory_ tag).
-
-You should get an ok response again, and the configuration subsystem will inject the dependency into the threadpool. Now you can commit the configuration (ok response once more) and the process is finished. The config subsystem is now in the same state as it was at the end of the previous example.
+++ /dev/null
-// https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:User_guide
-// FIXME: This should be updated and probably part of user / operations guide
-=== Configuration examples user guide
-==== Configuring thread pools with yangcli-pro
-Requirements: yangcli-pro version 13.04-9.2 or later +
-
-===== Connecting to plaintext TCP socket and ssh
-Currently SSH is exposed by the controller. The network interface and port are configured in configuration/config.ini . The current configuration of netconf is as follows: +
-----
-# Netconf startup configuration
-#netconf.tcp.address=127.0.0.l
-#netconf.tcp.port=8383
-
-netconf.ssh.address=0.0.0.0
-netconf.ssh.port=1830
-----
-To connect the yangcli-pro client, use the following syntax: +
-----
-yangcli-pro --user=admin --password=admin --transport=ssh --ncport=1830 --server=localhost
-----
-If the plaintext TCP port is not commented out, one can use the following: +
-----
-yangcli-pro --user=a --password=a --transport=tcp --ncport=8383 --server=localhost
-----
-Authentication in this case is ignored.
-
-For better debugging, include following arguments: +
-----
---log=/tmp/yuma.log --log-level=debug4 --log-console
-----
-
-NOTE: When the log file is set, the output will not appear on stdout.
-
-===== Configuring threadfactory
-The threadfactory is a service interface that can be plugged into threadpools, defined in config-threadpool-api (see the https://git.opendaylight.org/gerrit/gitweb?p=controller.git;a=blob;f=opendaylight/config/threadpool-config-api/src/main/yang/threadpool.yang;h=8f3064822be319dfee6fd7c7061c8bee14db268f;hb=refs/heads/master[yang file].
-The implementation to be used is called threadfactory-naming. This implementation will set a name for each thread created using a configurable prefix and auto incremented index. See the https://git.opendaylight.org/gerrit/gitweb?p=controller.git;a=blob;f=opendaylight/config/threadpool-config-impl/src/main/yang/threadpool-impl.yang;h=a2366f285a0c0b8682b1093f18fb5ee184c9cde3;hb=refs/heads/master[Yang file].
-
-. Launch yangcli-pro and connect to the server.
-. Enter *get-config source=running* to see the current configuration. +
-Example output: +
-----
-rpc-reply {
- data {
- modules {
- module binding-broker-singleton {
- type binding-impl:binding-broker-impl-singleton
- name binding-broker-singleton
- }
- }
- services {
- service md-sal-binding:binding-broker-osgi-registry {
- type md-sal-binding:binding-broker-osgi-registry
- instance ref_binding-broker-singleton {
- name ref_binding-broker-singleton
- provider /modules/module[type='binding-broker-impl-singleton'][name='binding-broker-singleton']
- }
- }
- }
- }
-}
-----
-[start=3]
-. Enter the merge /modules/module.
-. At the prompt, enter the string value for the leaf <name>. This is the name of the config module. Enter threadfactory-bgp.
-. Set the identityref for the leaf <type>. Press Tab to see a list of available module names. Enter threadfactory-naming.
-. At the prompt, choose the case statement. Example output:
-----
- 1: case netty-threadgroup-fixed:
- leaf thread-count
- 2: case netty-hashed-wheel-timer:
- leaf tick-duration
- leaf ticks-per-wheel
- container thread-factory
- 3: case async-eventbus:
- container threadpool
- 4: case threadfactory-naming:
- leaf name-prefix
- 5: case threadpool-fixed:
- leaf max-thread-count
- container threadFactory
- 6: case threadpool-flexible:
- leaf max-thread-count
- leaf minThreadCount
- leaf keepAliveMillis
- container threadFactory
- 7: case threadpool-scheduled:
- leaf max-thread-count
- container threadFactory
- 8: case logback:
- list file-appenders
- list rolling-appenders
- list console-appenders
- list loggers
-----
-In this case, we chose 4. +
-[start=7]
-. Next fill in the string value for the leaf <name-prefix>. Enter bgp.
-: (You should get an OK response from the server.)
-[start=8]
-. Optionally issue get-config source=candidate to verify the change.
-. Issue commit.
-. Issue get-config source=running. Example output: +
-----
-rpc-reply {
- data {
- modules {
- module binding-broker-singleton {
- type binding-impl:binding-broker-impl-singleton
- name binding-broker-singleton
- }
- module threadfactory-bgp {
- type th-java:threadfactory-naming
- name threadfactory-bgp
- name-prefix bgp
- }
- }
- services {
- service th:threadfactory {
- type th:threadfactory
- instance ref_threadfactory-bgp {
- name ref_threadfactory-bgp
- provider /modules/module[type='threadfactory-naming'][name='threadfactory-bgp']
- }
- }
- service md-sal-binding:binding-broker-osgi-registry {
- type md-sal-binding:binding-broker-osgi-registry
- instance ref_binding-broker-singleton {
- name ref_binding-broker-singleton
- provider /modules/module[type='binding-broker-impl-singleton'][name='binding-broker-singleton']
- }
- }
- }
- }
-}
-----
-==== Configuring fixed threadpool
-
-Service interface threadpool is defined in the config-threadpool-api. The implementation used is called threadpool-fixed that is defined in config-threadpool-impl. This implementation creates a threadpool of fixed size. There are two mandatory attributes: size and dependency on a threadfactory.
-
-. Issue get-config source=running. As you can see in the last step of configuring threadfactory, /services/service, the node associated with it has instance name ref_threadfactory-bgp.
-. Issue merge /modules/module.
-. Enter the name bgp-threadpool.
-. Enter the type threadpool.
-. Select the appropriate case statement.
-. Enter the value for leaf <max-thread-count>: 100.
-. Enter the threadfactory for attribute threadfactory/type. This is with reference to /services/service/type, in other words, the service interface.
-. Enter ref_threadfactory-bgp.
-Server response must be an OK message.
-[start=9]
-. Issue commit.
-. Issue get-config source=running.
-Example output: +
-----
-rpc-reply {
- data {
- modules {
- module binding-broker-singleton {
- type binding-impl:binding-broker-impl-singleton
- name binding-broker-singleton
- }
- module bgp-threadpool {
- type th-java:threadpool-fixed
- name bgp-threadpool
- threadFactory {
- type th:threadfactory
- name ref_threadfactory-bgp
- }
- max-thread-count 100
- }
- module threadfactory-bgp {
- type th-java:threadfactory-naming
- name threadfactory-bgp
- name-prefix bgp
- }
- }
- services {
- service th:threadpool {
- type th:threadpool
- instance ref_bgp-threadpool {
- name ref_bgp-threadpool
- provider /modules/module[type='threadpool-fixed'][name='bgp-threadpool']
- }
- }
- service th:threadfactory {
- type th:threadfactory
- instance ref_threadfactory-bgp {
- name ref_threadfactory-bgp
- provider /modules/module[type='threadfactory-naming'][name='threadfactory-bgp']
- }
- }
- service md-sal-binding:binding-broker-osgi-registry {
- type md-sal-binding:binding-broker-osgi-registry
- instance ref_binding-broker-singleton {
- name ref_binding-broker-singleton
- provider /modules/module[type='binding-broker-impl-singleton'][name='binding-broker-singleton']
- }
- }
- }
- }
-}
-----
-To see the actual netconf messages, use the logging arguments described at the top of this page. To validate that a threadpool has been created, a tool like VisualVM can be used.
-
-==== Logback configuration - Yuma
-This approach to configure logback will utilize a 3rd party cli netconf client from Yuma. We will modify existing console appender in logback and then call reset rpc on logback to clear its status list.
-
-For initial configuration of the controller and startup parameters for yuma, see the threadpool example: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Threadpool[Threadpool configuration using Yuma].
-
-Start the controller and yuma cli client as in the previous example.
-
-There is no need to initialize the configuration module wrapping logback manually, since it creates a default instance. Therefore you should see the output containing logback configuration after the execution of get-config source=running command in yuma:
-----
-rpc-reply {
- data {
- modules {
- module singleton {
- type logging:logback
- name singleton
- console-appenders {
- threshold-filter ERROR
- name STDOUT
- encoder-pattern '%date{"yyyy-MM-dd HH:mm:ss.SSS z"} [%thread] %-5level %logger{36} - %msg%n'
- }
- file-appenders {
- append true
- file-name logs/audit.log
- name audit-file
- encoder-pattern '%date{"yyyy-MM-dd HH:mm:ss.SSS z"} %msg %n'
- }
- loggers {
- level WARN
- logger-name org.opendaylight.controller.logging.bridge
- }
- loggers {
- level INFO
- logger-name audit
- appenders audit-file
- }
- loggers {
- level ERROR
- logger-name ROOT
- appenders STDOUT
- appenders opendaylight.log
- }
- loggers {
- level INFO
- logger-name org.opendaylight
- }
- loggers {
- level WARN
- logger-name io.netty
- }
- rolling-appenders {
- append true
- max-file-size 10MB
- file-name logs/opendaylight.log
- name opendaylight.log
- file-name-pattern logs/opendaylight.%d.log.zip
- encoder-pattern '%date{"yyyy-MM-dd HH:mm:ss.SSS z"} [%thread] %-5level %logger{35} - %msg%n'
- clean-history-on-start false
- max-history 1
- rolling-policy-type TimeBasedRollingPolicy
- }
- }
- module binding-broker-singleton {
- type binding-impl:binding-broker-impl-singleton
- name binding-broker-singleton
- }
- }
- services {
- service md-sal-binding:binding-broker-osgi-registry {
- type md-sal-binding:binding-broker-osgi-registry
- instance ref_binding-broker-singleton {
- name ref_binding-broker-singleton
- provider /modules/module[type='binding-broker-impl-singleton'][name='binding-broker-singleton']
- }
- }
- }
- }
-}
-----
-
-===== Modifying existing console appender in logback
-. Start edit-config with merge option:
-----
-merge /modules/module
-----
-[start=2]
-. For Name of the module, enter *singleton*.
-. For Type, enter *logback*.
-. Pick the corresponding case statement with the name logback.
-We do not want to modify file-appenders, rolling-appenders and loggers lists, so the answer to questions from yuma is N (for no):
-----
-Filling optional case /modules/module/configuration/logback:
-Add optional list 'file-appenders'?
-Enter Y for yes, N for no, or C to cancel: [default: Y]
-----
-[start=5]
-. As we want to modify console-appenders, the answer to the question from Yuma is Y:
-----
-Filling optional case /modules/module/configuration/logback:
-Add optional list 'console-appenders'?
-Enter Y for yes, N for no, or C to cancel: [default: Y]
-----
-[start=6]
-. This will start a new configuration process for console appender and we will fill following values:
-
-* <encoder-pattern> %date{"yyyy-MM-dd HH:mm:ss.SSS z"} %msg %n
-* <threshold-filter> INFO
-* <name> STDOUT
-[start=7]
-. Answer N to the next question.
-----
-Add another list?
-Enter Y for yes, N for no, or C to cancel: [default: N]
-----
-Notice that we changed the level for threshold-filter for STDOUT console appender from ERROR to INFO. Now issue a commit command to commit the changed configuration, and the response from get-config source=running command should look like this:
-----
-rpc-reply {
- data {
- modules {
- module singleton {
- type logging:logback
- name singleton
- console-appenders {
- threshold-filter INFO
- name STDOUT
- encoder-pattern '%date{"yyyy-MM-dd HH:mm:ss.SSS z"} [%thread] %-5level %logger{36} - %msg%n'
- }
- file-appenders {
- append true
- file-name logs/audit.log
- name audit-file
- encoder-pattern '%date{"yyyy-MM-dd HH:mm:ss.SSS z"} %msg %n'
- }
- loggers {
- level WARN
- logger-name org.opendaylight.controller.logging.bridge
- }
- loggers {
- level INFO
- logger-name audit
- appenders audit-file
- }
- loggers {
- level ERROR
- logger-name ROOT
- appenders STDOUT
- appenders opendaylight.log
- }
- loggers {
- level INFO
- logger-name org.opendaylight
- }
- loggers {
- level WARN
- logger-name io.netty
- }
- rolling-appenders {
- append true
- max-file-size 10MB
- file-name logs/opendaylight.log
- name opendaylight.log
- file-name-pattern logs/opendaylight.%d.log.zip
- encoder-pattern '%date{"yyyy-MM-dd HH:mm:ss.SSS z"} [%thread] %-5level %logger{35} - %msg%n'
- clean-history-on-start false
- max-history 1
- rolling-policy-type TimeBasedRollingPolicy
- }
- }
- module binding-broker-singleton {
- type binding-impl:binding-broker-impl-singleton
- name binding-broker-singleton
- }
- }
- services {
- service md-sal-binding:binding-broker-osgi-registry {
- type md-sal-binding:binding-broker-osgi-registry
- instance ref_binding-broker-singleton {
- name ref_binding-broker-singleton
- provider /modules/module[type='binding-broker-impl-singleton'][name='binding-broker-singleton']
- }
- }
- }
- }
-}
-----
-==== Invoking RPCs
-*Invoking Reset RPC on logback* +
-The configuration module for logback exposes some information about its current state(list of logback status messages). This information can be accessed using get netconf operation or get command from yuma. Example response after issuing get command in yuma:
-----
-rpc-reply {
- data {
- modules {
- module singleton {
- type logging:logback
- name singleton
- status {
- message 'Found resource [configuration/logback.xml] at
-[file:/.../controller/opendaylight/distribution/opendaylight/target/distribution.opendaylight-
-osgipackage/opendaylight/configuration/logback.xml]'
- level INFO
- date 2479534352
- }
- status {
- message 'debug attribute not set'
- level INFO
- date 2479534441
- }
- status {
- message 'Will scan for changes in
-[[/.../controller/opendaylight/distribution/opendaylight/target/distribution.opendaylight-
-osgipackage/opendaylight/configuration/logback.xml]]
-every 60 seconds.'
- level INFO
- date 2479534448
- }
- status {
- message 'Adding ReconfigureOnChangeFilter as a turbo filter'
- level INFO
- date 2479534448
- }
- ...
-----
-Logback also exposes an rpc called reset that wipes out the list of logback status messages and to invoke an rpc with name reset on module named singleton of type logback, following command needs to be issued in yuma:
-----
-reset context-instance="/modules/module[type='logback' and name='singleton']"
-----
-After an ok response, issuing get command should produce response with empty logback status message list:
-----
-rpc-reply {
- data {
- modules {
- module singleton {
- type logging:logback
- name singleton
- }
- }
- }
-}
-----
-This response confirms successful execution of the reset rpc on logback.
-
-*Invoking shutdown RPC* +
-This command entered in yuma will shut down the server. If all bundles do not stop correctly within 10 seconds, it will force the process to exit.
-----
-shutdown context-instance="/modules/module[type='shutdown' and name='shutdown']",input-secret="",max-wait-time="10000",reason="reason"
-----
+++ /dev/null
-== Controller
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/controller.html
+++ /dev/null
-=== OpenDaylight Controller: MD-SAL FAQs
-
-*Q-1: What is the overall MD-SAL architecture?*
-
-* **What is the overall architecture, components, and functionality?**
-* **Who supplies which components, and how are the components plumbed?**
-
-*A-1:* The overall Model-Driven SAL (MD-SAL) architecture did not really change
-from the API-Driven SAL (AD-SAL). As with the AD-SAL, plugins can be data
-providers, or data consumers, or both (although the AD-SAL did not explicitly
-name them as such). Just like the AD-SAL, the MD-SAL connects data consumers
-to appropriate data providers and (optionally) facilitates data adaptation
-between them.
-
-Now, in the AD-SAL, the SAL APIs request routing between consumers and
-providers, and data adaptations are all statically defined at compile or
-build time. In the MD-SAL, the SAL APIs and request routing between consumers
-and providers are defined from models, and data adaptations are provided by
-'internal' adaptation plugins. The API code is generated from models when
-a plugin is compiled. When the plugin OSGI bundle is loaded into the controller,
-the API code is loaded into the controller along with the rest of the plugin
-containing the model.
-
-.AD-SAL and MD-SAL
-image::MD-SAL.png[]
-
-The AD-SAL provides request routing (selects an SB plugin based on service type)
-and optionally provides service adaptation, if an NB (Service, abstract) API
-is different from its corresponding SB (protocol) API. For example, in the above
-figure, the AD-SAL routes requests from NB-Plugin 1 to SB Plugins 1 and 2. Note
-that the plugin SB and NB APIs in this example are essentially the same
-(although both of them need to be defined). Request routing is based on plugin
-type: the SAL knows which node instance is served by which plugin. When an NB
-Plugin requests an operation on a given node, the request is routed to the
-appropriate plugin which then routes the request to the appropriate node.
-The AD-SAL can also provide service abstractions and adaptations. For example,
-in the above figure, NB Plugin 2 is using an abstract API to access the services
-provided by SB Plugins 1 and 2. The translation between the SB Plugin API and
-the abstract NB API is done in the Abstraction module in the AD-SAL.
-
-The MD-SAL provides request routing and the infrastructure to support service
-adaptation. However, it does not provide service adaptation itself: service
-adaptation is provided by plugins. From the point of view of MD-SAL,
-the Adaptation Plugin is a regular plugin. It provides data to the SAL,
-and consumes data from the SAL through APIs generated from models.
-An Adaptation Plugin basically performs model-to-model translations
-between two APIs. Request Routing in the MD-SAL is done on both protocol type
-and node instances, since node instance data is exported from the plugin into
-the SAL (the model data contains routing information).
-
-The simplest MD-SAL APIs generated from models (RPCs and Notifications, both
-supported in the yang modeling language) are functionally equivalent to AD-SAL
-function call APIs. Additionally, the MD-SAL can store data for models defined
-by plugins. Provider and consumer plugins can exchange data through the MD-SAL
-storage. Data in the MD-SAL is accessed through getter and setter APIs generated
-from models. Note that this is in contrast to the AD-SAL, which is stateless.
-
-Note that in the above figure, both NB AD-SAL Plugins provide REST APIs to
-controller client applications.
-
-The functionality provided by the MD-SAL is basically to facilitate the plumbing
-between providers and consumers. A provider or a consumer can register itself
-with the MD-SAL. A consumer can find a provider that it is interested in.
-A provider can generate notifications; a consumer can receive notifications
-and issue RPCs to get data from providers. A provider can insert data into SAL
-storage; a consumer can read data from SAL storage.
-
-Note that the structure of SAL APIs is different in the MD-SAL from that in the
-AD-SAL. The AD-SAL typically has both NB and SB APIs even for functions or
-services that are mapped 1:1 between SB Plugins and NB Plugins. For example,
-in the current AD-SAL implementation of the OpenFlow Plugin and applications,
-the NB SAL APIs used by OF applications are mapped 1:1 onto SB OF Plugin APIs.
-The MD-SAL allows both the NB plugins and SB plugins to use the same
-API generated from a model. One plugin becomes an API (service) provider;
-the other becomes an API (service) Consumer. This eliminates the need to define
-two different APIs and to provide three different implementations even for cases
-where APIs are mapped to each other 1:1. The MD SAL provides instance-based
-request routing between multiple provider plugins.
-
-*Q-2: What functionality does the MD-SAL assume? For example, does the SAL
-assume that the network model is a part of the SAL?*
-
-*A-2:* The MD-SAL does not assume any model. All models are provided by plugins.
-The MD-SAL only provides the infrastructure and the plumbing for the plugins.
-
-
-*Q-3: What is the "day in the life" of an MD-SAL plugin?*
-
-
-*A-3:* All plugins (protocol, application, adaptation, and others) have the same
-lifecycle. The life of a plugin has two distinct phases: design and operation. +
-During the design phase, the plugin designer performs the following actions: +
-
-* The designer decides which data will be consumed by the plugin, and imports
-the SAL APIs generated from the API provider’s models. Note that the topology
-model is just one possible data type that may be consumed by a plugin. The list
-of currently available data models and their APIs can be found in
-YANG_Tools:Available_Models.
-* The designer decides which data and how it will be provided by the plugin,
-and designs the data model for the provided data. The data model
-(expressed in yang) is then run through the
-https://wiki.opendaylight.org/view/YANG_Tools:Available_Models[YANG Tools],
-which generate the SAL APIs for the model.
-* The implementations for the generated consumer and provider APIs, along with
- other plugin features and functionality, are developed. The resulting code
- is packaged in a “plugin” OSGI bundle. Note that a developer may package the
- code of a subsystem in multiple plugins or applications that may communicate
- with each other through the SAL.
-* The generated APIs and a set of helper classes are also built and packaged
- in an “API” OSGI bundle.
-
-The plugin development process is shown in the following figure. +
-
-.Plugin development process
-image::plugin-dev-process.png[]
-
-When the OSGI bundle of a plugin is loaded into the controller and activated,
-the operation phase begins. The plugin operation is probably best explained
-with a few examples describing the operation of the OF Protocol plugin and
-OF applications, such as the Flow Programmer Service, the ARP Handler,
-or the Topology Manager. The following figure shows a scenario where a
-“Flow Deleted” notification from a switch arrives at the controller.
-
-.Flow deleted at controller
-image::flow-deleted-at-controller.png[]
-
-The scenario is as follows: +
-
-. The Flow Programmer Service registers with the MD SAL for the `Flow Deleted'
- notification. This is done when the Controller and its plugins or applications
- are started.
-. A `Flow Deleted' OF packet arrives at the controller. The OF Library receives
-the packet on the TCP/TLS connection to the sending switch, and passes it to the
-OF Plugin.
-. The OF Plugin parses the packet, and uses the parsed data to create a
-`Flow Deleted' SAL notification. The notification is actually an immutable
-`Flow Deleted' Data Transfer Object (DTO) that is created or populated by means
-of methods from the model-generated OF Plugin API.
-. The OF Plugin sends the `Flow Deleted' SAL notification (containing the
- notification DTO) into the SAL. The SAL routes the notification to registered
- consumers, in this case, the Flow Programmer Service.
-. The Flow Programmer Service receives the notification containing the
- notification DTO.
-. The Flow Programmer Service uses methods from the API of the model-generated
- OF Plugin to get data from the immutable notification DTO received in Step 5.
- The processing is the same as in the AD-SAL.
-
-Note that other packet-in scenarios, where a switch punts a packet to
-the controller, such as an ARP or an LLDP packet, are similar. Interested
-applications register for the respective notifications. The OF plugin generates
-the notification from received OF packets, and sends them to the SAL.
-The SAL routes the notifications to the registered recipients. +
-The following figure shows a scenario where an external application adds a
-flow by means of the NB REST API of the controller.
-
-.External app adds flow
-image::md-sal-faqs-add_flow.png[]
-
-The scenario is as follows: +
-
-. Registrations are performed when the Controller and its plugins
- or applications are started.
-
-.. The Flow Programmer Service registers with the MD SAL for Flow configuration
-data notifications.
-.. The OF Plugin registers (among others) the ‘AddFlow’ RPC implementation with
- the SAL.
-Note that the RPC is defined in the OF Plugin model, and the API is generated
-during build time. +
-[start=2]
-. A client application requests a flow add through the REST API of the
-Controller. (Note that in the AD-SAL, there is a dedicated NB REST API on top
-of the Flow Programming Service. The MD-SAL provides a common infrastructure
-where data and functions defined in models can be accessed by means of a common
-REST API. For more information, see http://datatracker.ietf.org/doc/draft-bierman-netconf-restconf/). The client application provides all parameters for the flow in the REST call.
-. Data from the ‘Add Flow’ request is deserialized, and a new flow is created
- in the Flow Service configuration data tree. (Note that in this example
- the configuration and operational data trees are separated; this may be
- different for other services). Note also that the REST call returns success
- to the caller as soon as the flow data is written to the configuration data tree.
-. Since the Flow Programmer Service is registered to receive notifications
- for data changes in the Flow Service data tree, the MD-SAL generates a
- ‘data changed’ notification to the Flow Programmer Service.
-. The Flow Programmer Service reads the newly added flow, and performs
- a flow add operation (which is basically the same as in the AD-SAL).
-. At some point during the flow addition operation, the Flow Programmer Service
- needs to tell the OF Plugin to add the flow in the appropriate switch.
- The Flow Programmer Service uses the OF Plugin generated API to create
- the RPC input parameter DTO for the “AddFlow” RPC of the OF Plugin.
-. The Flow Programmer Service gets the service instance (actually, a proxy),
- and invokes the “AddFlow” RPC on the service. The MD-SAL will route
- the request to the appropriate OF Plugin (which implements the requested RPC).
-. The `AddFlow' RPC request is routed to the OF Plugin, and the implementation
- method of the “AddFlow” RPC is invoked.
-. The `AddFlow' RPC implementation uses the OF Plugin API to read values from
- the DTO of the RPC input parameter. (Note that the implementation will use
- the getter methods of the DTO generated from the yang model of the RPC to read
- the values from the received DTO.)
-. The `AddFlow' RPC is further processed (pretty much the same as in the AD-SAL)
- and at some point, the corresponding flowmod is sent to the corresponding switch.
-
-*Q-4: Is there a document that describes how code is generated from the models
-for the MD-SAL?*
-
-*A-4:* https://wiki.opendaylight.org/view/YANG_Tools:YANG_to_Java_Mapping[Yangtools]
-documents the Yang to Java generation, including examples of how the yang
-constructs are mapped into Java classes. You can write unit tests against
-the generated code. You will have to write implementations of the generated
-RPC interfaces. The generated code is just Java, and it debugs just like Java.
-
-If you want to play with generating Java from Yang there is a maven archetype
-to help you get going: https://wiki.opendaylight.org/view/Maven_Archetypes:odl-model-project[Maven Archetypes: ODL Model Project]. +
-Or, you can try creating a project in Eclipse as explained at: http://sdntutorials.com/yang-to-java-conversion-how-to-create-maven-project-in-eclipse/[YANG to Java conversion: How to create Maven project in Eclipse].
-
-*Q-5: The code generation tools mention 'producers' and consumers'.
-How are these related to 'southbound' and 'northbound SAL plugins?*
-
-*A-5:* The difference between southbound and northbound plugins is that
-the southbound plugins talk protocols to network nodes, and northbound
-plugins talk application APIs to the controller applications. As far
-as the SAL is concerned, there is really no north or south.
-The SAL is basically a data exchange and adaptation mechanism between plugins.
-The plugin SAL roles (consumer or producer) are defined with respect to
-the data being moved around or stored by the SAL. A producer implements an API,
-and provides the data of the API: a consumer uses the API, and consumes the data
-of the API. +
-While 'northbound' and 'southbound' provide a network engineer's view of the SAL,
- 'consumer' and 'producer' provide a software engineer's view of the SAL, and is
- shown in the following figure:
-
-.SAL consumer and producer view
-
-image::mdsal-sal-sw-eng.png[]
-
-*Q-6: Where can I find models that have already been defined in OpenDaylight?*
-
-*A-6:* The list of models that have been defined for the SAL and in various
-plugins can be found in https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Model_Reference[MD-SAL Model Reference].
-
-*Q-7: How do I migrate my existing plugins and services to MD-SAL?*
-
-*A-7:* The migration guide can be found in the
-https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Application_Migration_Guide[MD-SAL Application Migration Guide].
-
-*Q-8: Where can I find SAL example code?*
-
-*A-8:* The toaster sample provides a simple yet complete example of a model,
-a service provider (toaster), and a service consumer. It provides the model
-of a programmable toaster, a sample consumer application that uses
-MD-SAL APIs; a sample southbound plugin (a service provider) that implements
-toaster; and a unit test suite.
-
-The toaster example is in _controller.git_ under _opendaylight/md-sal/samples_.
-
-*Q-9: Where is the REST API code for the example?*
-
-*A-9:* The REST APIs are derived from models. You do not have to write any code
-for it. The controller will implement the
-http://datatracker.ietf.org/doc/draft-bierman-netconf-restconf/[RESTCONF protocol]
-which defines access to yang-formatted data through REST. Basically, all you
-need to do is define your service in a model, and expose that model to the SAL.
-REST access to your modeled data will then be provided by the SAL infrastructure.
-However, if you want to, you can create your own REST API (for example, to be
- compliant with an existing API).
-
-*Q-10: How can one use RESTCONF to access the MD-SAL datastore?*
-
-*A-10:* For information on accessing the MD-SAL datastore, see
-https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf[MD-SAL RESTCONF].
+++ /dev/null
-== NETCONF Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/netconf-developer-guide.html
+++ /dev/null
-== API design principles and patterns contributed by southbound plugins\r
-\r
-This section is intended to define common design patterns supporting extensions contributed by southbound plugins, which could be used in the SAL or or used in modelling any abstract extensible APIs.\r
-\r
-NOTE: Wire protocol specific information (serialization, serialization constants , TLV identifiers, bit masks, field ordering) should not be part of the SAL. Also, APIs (interfaces, classes) should support extensibility using subclassing or other extension patterns. This allows for abstract APIs and also for concrete APIs to coexist in the SAL and to use common infrastructure.\r
-\r
-=== Extensible enumeration pattern\r
-\r
-This pattern is suitable for modelling or defining APIs for the enumeration of immutable data or types, which for example could represent ether type, protocol type, and others. The workflow for API definition is simple:\r
-\r
-. Define a simple interface with the needed functionality.\r
-\r
-. Declare an enum implementing the interface where the enum constants represent the known values.\r
-\r
-. (optional) Include a factory method mapping from names to objects implementing the interface.\r
-\r
-For more information, see the following links:\r
-\r
-** http://jtechies.blogspot.com/2012/07/item-34-emulate-extensible-enums-with.html\r
-\r
-** http://blogs.oracle.com/darcy/entry/enums_and_mixins\r
-\r
-=== Type-value pairs pattern\r
-\r
-This pattern is suitable for modelling or defining APIs for extensible set of fields, where the values could be of different types. The requirements for type-value pairs are: Extensible and Type safety.\r
-\r
-==== Common antipatterns\r
-\r
-This pattern is to replace the following constructs:\r
-\r
-\r
-* Simple untyped approach to properties (pros: extensible, cons: does not provide semantics and type safety):\r
-\r
-[literal]\r
-// Ommited for clarity...\r
-HashMap<String,Object> properties;\r
-\r
-\r
-* More refined approach using the enumeration to define a set of supported field types (pros: provides semantics, cons: not extensible).\r
-\r
-[literal]\r
-enum Type {\r
- TYPE1(String.class),\r
- TYPE2(Boolean.class),\r
- private Class<?> valueType; // This line is optional.\r
- // ommited for clarity... \r
-}\r
-class Field {\r
- Type type;\r
- Object value;\r
- // ommited for clarity...\r
-}\r
-\r
-\r
-=== Actual pattern\r
-\r
-We can model this by using the abstract class and the generics to define value type and set of subclasses representing various types of fields. The instances of this class represents actual type-value pair, where class represents type and value is represented by object in the instance.\r
-\r
-[literal]\r
-abstract class Field<V> {\r
- private V value;\r
- public Field(V value) {\r
- this.value = value;\r
- }\r
- ...\r
-}\r
- class Type1Field extends Field<String> {\r
- public Type1Field(String value){super(value);}\r
-}\r
- class Type2Field extends Field<Boolean> {\r
- public Type2Field(Boolean value){super(value);}\r
-}\r
-\r
-The abstract class does not have to only define fields or values, but could also define additional methods (concrete or abstract) which could provide additional semantic about the field type. This example shows only one value field, but it is possible to have multiple fields. It is possible to model common part of API also as an interface and leave all the implementation to the super types. Map, which should store one instance of the field is: Map<Class<? extends Field<?>>,Field<?>>. It is possible to provide simpler facade on top of this map.\r
-\r
-=== Extension interface pattern\r
-\r
-The following Java design allows an object to be extended without changing its interface to clients. The object can implement additional extension interfaces. Clients can ask the object for extension interfaces that it implements.\r
-\r
-\r
-In the interface present in the SAL models general approach or abstraction, the client code (applications) could ask for extension interface (which could be used to model protocol specific functionality, interfaces, data) by querying for the extension. Extension is identified by Java interface (the client code using extension must be compiled against this interface).\r
-\r
-\r
-This pattern could be also used as an replacement for the field pattern. We have defined a set of fields provided by extension as separate class or interface, the values could be queried by using the extension class.\r
-The strong point of this pattern is that the client code needs to be aware of the extension and its contract (be compiled against the base interface and also extension) in order to use the extension. The code which was not compiled against extension is not affected by introducing new extensions.\r
-\r
-*Synopsis: Original pattern*\r
-\r
-[literal]\r
-public interface A {\r
- // Ommited for clarity...\r
- <T> T getExtension(Class<T> extensionType)\r
-}\r
-\r
-*Synopsis: Updated pattern*\r
-[literal]\r
-public interface Extensible<P> {\r
- // Ommited for clarity...\r
- <T extends Extension<P>> T getExtension(Class<T> extensionType)\r
-}\r
-public interface Extension<T> {\r
-}\r
-\r
-Where:\r
-\r
-* Extensible is interface which is to be implemented by classes which provides extension support\r
-\r
-* P - generic argument, usually interface / class which implements\r
-\r
-* Extension is marker interface (for type-safety reasons) which marks interfaces / classes which are extensions\r
-\r
-* T - generic argument, pointing to the class / interface to which this extension is associated.\r
-\r
-=== Usage example\r
-\r
-[literal]\r
-ublic class Node extends Extensible<Node> {\r
- // contents ommited\r
- // the instatiated version of extension interface isExtension method is\r
- @Override\r
- <T extends Extension<Node> T getExtension(Class<T> extensionType) {\r
- // contents ommited\r
- }\r
-}\r
-public class OpenflowNode extends Extension<Node> {\r
- // contents ommited\r
-}\r
-Node node = provider.getNode(); // sample call returning node\r
-OpenflowNode ofNode = node.getExtension(OpenflowNode.class);\r
-if(ofNode != null) {\r
- // do openflow specific stuff\r
-}\r
+++ /dev/null
-== OpenDaylight controller library descriptions\r
-\r
-Shared functions and methods are compiled and bundled into libraries. This page describes client libraries.\r
-\r
-=== C client library\r
-\r
-The C module generates the source code for the ANSI-C-compatible data structures and (de)serialization functions that can be used in conjunction with http://xmlsoft.org/[libxml2] to (de)serialize the REST resources as they are represented as XML data.\r
-\r
-\r
-The generated C source code depends on the http://xmlsoft.org/html/libxml-xmlreader.html[XML Reader API] and the http://xmlsoft.org/html/libxml-xmlwriter.html[XML Writer API] as well as the <time.h>, <string.h>, and <stdlib.h> C standard libraries.\r
-\r
-\r
-=== REST XML example\r
-\r
-[literal]\r
- #include <full.c>\r
- //...\r
- xmlTextReaderPtr reader = ...; //set up the reader to the url.\r
- full_ns0_edgeProps *response_element = ...;\r
- response_element = xml_read_full_ns0_edgeProps(reader);\r
- //handle the response as needed...\r
- //free the full_ns0_edgeProps\r
- free_full_ns0_edgeProps(response_element);\r
- \r
- \r
-=== .NET client library\r
-\r
-The .NET client-side library defines the classes that can be (de)serialized to/from XML. This is useful for accessing the REST endpoints that are published by this application.\r
-\r
-==== REST example\r
-\r
-[literal]\r
- //read a resource from a REST url\r
- Uri uri = new Uri(...);\r
- XmlSerializer s = new XmlSerializer(\r
- typeof( EdgeProps )\r
- );\r
- //Create the request object\r
- WebRequest req = WebRequest.Create(uri);\r
- WebResponse resp = req.GetResponse();\r
- Stream stream = resp.GetResponseStream();\r
- TextReader r = new StreamReader( stream );\r
- EdgeProps order = (EdgeProps) s.Deserialize( r );\r
- //handle the result as needed...\r
- \r
-This bundle contains C# source code.\r
-\r
-=== Java client library\r
-\r
-The Java client-side library is used to access the Web service API for this application.\r
-The JAX-WS client-side library is used to provide the set of Java objects that can be serialized to/from XML using https://jaxb.dev.java.net/[JAXB]. This is useful for accessing the REST endpoints that are published by this application.\r
-\r
-\r
-==== REST example (Raw JAXB)\r
-\r
-[literal]\r
- java.net.URL url = new java.net.URL(baseURL + "/{containerName}");\r
- JAXBContext context = JAXBContext.newInstance( EdgeProps.class );\r
- java.net.URLConnection connection = url.openConnection();\r
- connection.connect();\r
- Unmarshaller unmarshaller = context.createUnmarshaller();\r
- EdgeProps result = (EdgeProps) unmarshaller.unmarshal( connection.getInputStream() );\r
- //handle the result as needed...\r
- \r
- \r
-==== REST example (Jersey client)\r
-\r
-[literal]\r
-</nowiki>\r
-com.sun.jersey.api.client.Client client = com.sun.jersey.api.client.Client.create();\r
-EdgeProps result = client.resource(baseUrl + "/{containerName}")\r
- .get(EdgeProps.class);\r
-//handle the result as needed... \r
-</nowiki>\r
-\r
-=== Java JSON client library\r
-\r
-The Java client-side library is used to provide the set of Java objects that can be serialized to/from JSON using Jackson. This is useful for accessing the JSON REST endpoints that are published by this application.\r
-\r
-==== REST example (Raw Jackson)\r
-\r
-\r
-[literal]\r
- java.net.URL url = new java.net.URL(baseURL + "/{containerName}");\r
- ObjectMapper mapper = new ObjectMapper();\r
- java.net.URLConnection connection = url.openConnection();\r
- connection.connect();\r
- EdgeProps result = (EdgeProps) mapper.readValue( connection.getInputStream(), EdgeProps.class );\r
- //handle the result as needed...\r
- \r
- \r
-=== Objective C Client library\r
-\r
-The Objective C module generates the source code for the Objective C classes and (de)serialization functions that can be used in conjunction with http://xmlsoft.org/[libxml2] to (de)serialize the REST resources as they are represented as XML data.\r
-\r
-\r
-The generated Objective C source code depends on the http://xmlsoft.org/html/libxml-xmlreader.html[XML Reader API] and the http://xmlsoft.org/html/libxml-xmlwriter.html[XML Writer API] as well as the base OpenStep foundation classes.\r
-\r
-==== REST XML example\r
-\r
-[literal]\r
- #import <full.h>\r
- //...\r
- FULLNS0EdgeProps *responseElement;\r
- NSData *responseData; //data holding the XML from the response.\r
- NSURL *baseURL = ...; //the base url including the host and subpath.\r
- NSURL *url = [NSURL URLWithString: @"/{containerName}" relativeToURL: baseURL];\r
- NSMutableURLRequest *request = [[NSMutableURLRequest alloc] initWithURL:url];\r
- NSURLResponse *response = nil;\r
- NSError *error = NULL;\r
- [request setHTTPMethod: @"GET"];\r
- //this example uses a synchronous request,\r
- //but you'll probably want to use an asynchronous call\r
- responseData = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error];\r
- FULLNS0EdgeProps *responseElement = [FULLNS0EdgeProps readFromXML: responseData];\r
- [responseElement retain];\r
- //handle the response as needed...\r
- \r
-\r
- \r
- \r
- \r
-
\ No newline at end of file
+++ /dev/null
-== Configuring the OpenDaylight controller\r
-\r
-The common way to configure applications is to use configuration files such as xml or properties files. Although such files are easy for use in small scale applications, they offer limiterd capabilities in the case of fast growing and multi-module applications. Static config files become vast, non-transparent, and inconsistent. For highly dynamic and long living environments, proper configuration is an essential requirement. The OSGi framework provides configuration service (Config Admin), and allows runtime module configuration. However, it still lacks a validation process. A new module configuration can negatively affect other modules. It also does not solve problems relating to the atomicity of the change.\r
-\r
-=== Terms used in this section\r
-\r
-* *Module*: A compact part of a system, whose configuration is managed by the configuration subsystem.\r
-\r
-* *Module factory*: Important for creating module instances. Module factories are uniquely identified by name.\r
-\r
-\r
-* *Service*: Public API, which is used to access module instances, similar to interface in Java. Any module can implement or provide multiple services.\r
-\r
-\r
-* *Configuration*: Application state represented by modules definition, properties, and relations amongst them.\r
-\r
-=== Config component maps\r
-\r
-.Load balancer REST APIs summary\r
-\r
-[cols="3*", options="header"]\r
-\r
-|===\r
-\r
-|Artefact ID |Component |Description\r
-\r
-|config-api +\r
-\r
-config-manager +\r
-\r
-config-util\r
-\r
-|config-subsystem-core\r
-\r
-|Config subsystem core. Manages the configuration of the controller.\r
-Responsibilities include scanning of bundles for ModuleFactories, transactional management of lifecycle and dependency injection for config modules, and exposure of modules and their configuration into JMX.\r
-\r
-\r
-|netty-config-api +\r
-\r
-netty-timer-config +\r
-\r
-netty-threadgroup-config +\r
-\r
-netty-event-executor-config\r
-\r
-|netty-config\r
-\r
-|Config modules for netty related resources e.g. netty-threadgroup, netty-timer etc. \r
-Contains config module definition in form of yang schemas and generated code binding for config subsystem.\r
-\r
-\r
-|shutdown-api +\r
-\r
-shutdown-impl\r
-\r
-|controller-shutdown\r
-\r
-|Controller shutdown mechanism. Brings down the whole OSGi container of the controller. Authorization required in form of a *secret string*. Also contains config module definition in form of yang schemas and generated code binding for config subsystem. This makes it possible to invoke shutdown using config-sbusystem\r
-\r
-\r
-\r
-\r
-|threadpool-config-api +\r
-\r
-threadpool-config-impl\r
-\r
-|threadpool-config\r
-\r
-|Config modules for threading related resources such as threadfactories and fixed-threadpool. \r
-Contains config module definition in the form of yang schemas and generated code binding for config subsystem.\r
-\r
-\r
-\r
-|logback-config\r
-\r
-|logback-config\r
-\r
-|Config modules for logging(logback) related resources such as loggers and appenders. \r
-Contains config module definition in the form of yang schemas and generated code binding for config subsystem.\r
-\r
-\r
-\r
-|netconf-config-dispatcher\r
-\r
-|netconf-config-dispatcher-config\r
-\r
-|Config modules for netconf-dispatcher(from netconf subsystem). \r
-Contains config module definition in form of yang schemas and generated code binding for config subsystem.\r
-\r
-\r
-|yang-jmx-generator +\r
-\r
-yang-jmx-generator-plugin\r
-\r
-|yang-jmx-config-generator\r
-\r
-|Maven plugin that generates the config subsystem code binding from provided yang schemas. This binding is required when bundles want to participate in the config subsystem.\r
-\r
-\r
-\r
-\r
-|yang-test +\r
-\r
-yang-test-plugin\r
-\r
-|yang-jmx-config-generator-testing-modules\r
-\r
-|Testing resources for the maven plugin.\r
-\r
-\r
-|config-persister-api +\r
-\r
-config-persister-file-xml-adapter +\r
-\r
-config-persister-directory-xml-adapter\r
-\r
-\r
-|config-persister\r
-\r
-|Contains api definition for an extensible configuration persister(database for controller configuration). The persister (re)stores the configuration for the controller. Persister implementation can be found in the netconf subsystem. The adapter bundles contain concrete implementations of storage extension. They store the config as xml files on filesystem.\r
-\r
-|config-module-archetype\r
-\r
-|config-module-archetype\r
-\r
-|Maven archetype for *config subsystem aware* bundles. This archetype contains blueprints for yang-schemas, java classes and other files(e.g. pom.xml) required for a bundle to participate in the config subsystem. This archetype generates a bundle skeleton that can be developed into a full blown *config subsystem aware* bundle.\r
-\r
-\r
-|===\r
-\r
-=== Configuration and transactional processes for the OpenDaylight controller\r
-\r
-The Configuration operation has three stages:\r
-\r
-. A proposed configuration is created. Its target is to replace the old configuration.\r
-\r
-. The proposed configuration must be validated before it can be committed. If it passes validation successfully, the proposed state of the configuration is changed to validated. \r
-\r
-. A validated configuration can be committed and the affected modules can be reconfigured. \r
-\r
-In fact, each configuration operation is wrapped in a transaction. Once a transaction is created, it can be configured. A user can abort the transaction during this stage. After the transaction configuration is done, it is committed to the validation stage. In this stage, the validation procedures are invoked. If one or more validations fail, the transaction can be reconfigured. On success, the second phase commit is invoked. If this commit is successful, the transaction enters the last stage known as committed. After that, the required modules are reconfigured. If the second phase commit fails, it means that the transaction is unhealthy. Basically, a new configuration instance creation failed, and the application can be in an inconsistent state.\r
-\r
-image::configuration.jpg[title="Configuration stage", alt="Configuration stage"]\r
-\r
-image::Transaction.jpg[title="Transaction stage", alt="Transaction stage"]\r
-\r
-\r
-To secure the consistency and safety of a new configuration, and to avoid conflicts, the configuration validation process is necessary. Usually, validation checks the input parameters of a new configuration and verifies module-specific relationships. The validation procedure results in a decision indicating whether the proposed configuration is healthy.\r
-\r
-Since there can be dependencies between modules, a change of a module configuration can affect the state of other modules. Therefore, we need to verify whether dependencies on other modules can be resolved. The dependency resolver acts similar to dependency injectors. A dependency tree is built.\r
-\r
-=== SPIs\r
-\r
-Module org.opendaylight.controller.config.spi.Module is a common interface for all modules. Every module must implement it. The module is designated to hold configuration attributes, validate them, and create an instance of service based on the attributes. This instance must implement AutoCloseable interface, owing to resources clean up. If the module was created from an already running instance, it contains an old instance of the module. The module can implement multiple services. If the module depends on other modules, setters need to be annotated with @RequireInterface.\r
-\r
-In creating the module, firstly, the module needs to be configured, be set with all required attributes. Thereafter, the module is moved to the commit stage, where validation is performed. If it fails, the module attributes can be reconfigured. Otherwise, a new instance is created or an old instance is reconfigured. A module instance is identified by ModuleIdentifier which consists of the factory name and instance name.\r
-\r
-\r
-ModuleFactory org.opendaylight.controller.config.spi.ModuleFactory interface must be implemented by each module factory. The module factory can create new module instance in two ways: from an existing module instance or a pure new instance. Also, it can return default modules, useful for populating registry with an already existing configuration. A module factory implementation must have a globally unique name.\r
-\r
-=== APIs\r
-\r
-* *ConfigRegistry*: Represents functionality provided by configuration transaction (create, destroy module, validate, abort transaction).\r
-\r
-\r
-* *ConfigTransactionController?*: Represents functionality for manipulating configuration transactions (begin, commit config ).\r
-\r
-\r
-* *RuntimeBeanRegistratorAwareConfiBean*: The module implementing this interface will recieve RuntimeBeanRegistrator before getInstance is invoked.\r
-\r
-=== Runtime APIs\r
-\r
-* *RuntimeBean*: The common interface for all runtime beans.\r
-\r
-* *RootRuntimeBeanRegistrator*: Represents functionality for the root runtime bean registration, which subsequently allows hierarchical registrations.\r
-\r
-* *HierarchicalRuntimeBeanRegistration*: Represents functionality for the runtime bean registration and unreregistration from hierarchy.\r
-\r
-* *JMX APIs*: JMX API is purposed as a transition between Client API and JMX platform.\r
-\r
-* *ConfigTransactionControllerMXBean*: Extends ConfigTransactionController, executed by Jolokia clients on configuration transaction.\r
-\r
-* *ConfigRegistryMXBean*: Represents the entry point of configuration management for MXBeans.\r
-\r
-NOTE: The Object Name is the pattern used in JMX to locate JMX beans. It consists of domain and key properties (at least one key-value pair). Domain is defined as "org.opendaylight.controller". The only mandatory property is "type".\r
-\r
-=== Use case scenarios\r
-\r
-The list provides a few samples of successful and unsuccessful transactions scenarios.\r
-\r
-==== Successful commit scenario\r
-\r
-. The user creates a transaction calling creteTransaction() method on ConfigRegistry.\r
-\r
-. The ConfigRegisty creates a transaction controller and registers the transaction as a new bean.\r
-\r
-\r
-. Runtime configurations are copied to the transaction. The user can create modules, and set their attributes.\r
-\r
-\r
-. The configuration transaction is committed.\r
-\r
-\r
-. The validation process is performed.\r
-\r
-\r
-. After successful validation, the second phase commit begins.\r
-\r
-\r
-. Modules proposed to be destroyed are destroyed, their service instances are closed.\r
-\r
-\r
-. The Runtime beans are set to registrator.\r
-\r
-\r
-. The transaction controller invokes the method getInstance on each module.\r
-\r
-\r
-. The transaction is committed and resources are closed or released.\r
-\r
-\r
-\r
-==== Validation failure scenario\r
-\r
-The transaction is the same as previous case until the validation step.\r
-\r
-. The user creates a transaction calling creteTransaction() method on ConfigRegistry.\r
-\r
-. The ConfigRegisty creates a transaction controller and registers the transaction as a new bean.\r
-\r
-\r
-. Runtime configurations are copied to the transaction. The user can create modules, and set their attributes.\r
-\r
-\r
-. The configuration transaction is committed.\r
-\r
-\r
-. The validation process is performed.\r
-\r
-\r
-. If validation fails such as illegal input attributes values or dependency resolver failure, ValidationException is thrown and exposed to the user.\r
-\r
-. The user can decide to reconfigure the transaction, commit again, or abort current transaction.\r
-\r
-\r
-. On aborted transactions, TransactionController and JMXRegistrator are properly closed.\r
-\r
-\r
-. The Unregistration event is sent to ConfigRegistry.\r
-\r
-=== Default module instances\r
-\r
-The configuration subsystem provides a way for modules to create default instances. Default instance is an instance of a module that is created at the module bundle startup (module becomes visible for configuration subsystem for example, its bundle is activated in OSGi environment). By default, no default instances are produced.\r
-\r
-\r
-The default instance does not differ from instances created later in the module lifecycle. The only difference is that the configuration for the default instance cannot be provided by the configuration subsystem. The module has to acquire the configuration for these instances on its own, and it can be acquired from, for example, environment variables. After the creation of a default instance, it acts as a regular instance, and fully participates in the configuration subsystem (It can be reconfigured or deleted in following transactions.).\r
-\r
+++ /dev/null
-== Kick-starter for OpenDaylight developers\r
-\r
-See updated developer getting started information at the https://wiki.opendaylight.org/view/GettingStarted:Developer_Main[Getting Started for Developers Page].\r
-\r
-=== Downloading the OpenDaylight software\r
-\r
-You can either download the software using CLI or Eclipse. See the relevant sections in the OpenDaylight wiki.\r
-\r
-\r
-=== OpenDaylight infrastructure\r
-\r
-\r
-NOTE: This section is for developers who wish to contribute to the OpenDaylight project. For developers who wish to build proprietary applications based on OpenDaylight, see the section on RESTCONF.\r
-\r
-The OpenDaylight infrastructure consists of the following components.\r
-\r
-* *Source code manager:* http://git-scm.com/[Git]. For more information, see https://wiki.opendaylight.org/view/OpenDaylight_Controller:Gerrit_Setup[Getting started with Git and Gerrit].\r
-\r
-* *Code review tool:* https://git.opendaylight.org/gerrit/[Gerrit]. For more information, see https://wiki.opendaylight.org/view/OpenDaylight_Controller:Gerrit_Setup[Getting started with Git and Gerrit].\r
-\r
-* *Continuous integration:* https://jenkins.opendaylight.org/[OpenDaylight Jenkins]. For more information, see Getting started with Jenkins.\r
-\r
-* *Artefact repository:* https://nexus.opendaylight.org/[OpenDaylight Nexus] For more information, see https://wiki.opendaylight.org/view/Infrastructure:Nexus[Getting started with Nexus].\r
-\r
-* *Quality Management:* https://sonar.opendaylight.org/[OpenDaylight Sonar]. \r
-\r
-* *Bug tracking:* http://bugs.opendaylight.org/[OpenDaylight Bugzilla]. \r
-\r
-* *Wiki:* https://wiki.opendaylight.org/[OpenDaylight wiki]. \r
-\r
-=== Development workflow for contributing to the OpenDaylight project\r
-\r
-The steps below detail the development workflow for contributing to the OpenDaylight project, including any of its sub projects.\r
-\r
-\r
-. *Identifying the project:* Identify the project under OpenDaylight for which you are going to contribute code. For the list of available projects, see https://wiki.opendaylight.org/view/Main_Page#Projects[OpenDaylight Projects].\r
-\r
-[start=2]\r
-. *Locating the project repository:* Navigate to the selected project page and identify the repository for the project. It maybe listed in the main page or in one of the sub-pages.\r
-\r
-[start=4]\r
-. *Pulling the dependent artefacts:* Pull the dependent artefacts. Most Java and OSGI code bases have a large number of dependencies that are managed by maven. During build, the artefacts (usually binary jars) for those dependencies are pulled from a Development Nexus Artefact Repository.\r
-\r
-[start=3]\r
-. *Pulling the code:* Pull the code from the repository to your local system. For more information, see the relevant section about the project in this developer's guide.\r
-\r
-\r
-[start=5]\r
-. *Contributing to the code:* Start working on the code in your local system. If you think your contributions are ready for review by a group of peer collaborators, push the code to the repository.\r
-\r
-. *Triggering a Jenkins verification:* Trigger a Jenkins verification in Gerrit. Jenkins runs continuous integration tests.\r
-\r
-[start=8]\r
-. *Running CI and verifying the patch:* If the Jenkins tests are successful, the patch is verified in Gerrit.\r
-\r
-. *Reviewing the patch:* A committer picks the patch for consideration. The committer may have comments for you to fix in your code. In this case, make the code changes and re-submit the code for review.\r
-\r
-. *Submitting the patch:* If there are no more comments, the committer indicates to Gerrit that the patch is approved and verified.\r
-\r
-. *Merging the patch:* Gerrit merges the patch into the branch.\r
-\r
-. *Triggering a Jenkins verification:* Jenkins is triggered to run the continuous integration tests on the result of the merge.\r
-\r
-. *Running a Jenkins merge:* Jenkins kicks off the builds for the new artefacts that need to be in the Development Nexus Artifact Repository.\r
-\r
-. *Uploading new artefacts:* If builds (and possible other CI tasks) are successful, Jenkins uploads the new artefacts to the Development Nexus Artefact Repository.\r
-\r
-\r
-=== OpenDaylight architectural principles\r
-\r
-\r
-* *Runtime Modularity and Extensibility*: Allow for a modular, extensible controller that supports installation, removal, and updates to service implementations within a running controller. The feature is also known as in service software upgrade (ISSU).\r
-\r
-* *Multiprotocol Southbound*: Allow for more than one protocol interface with network elements with diverse capabilities southbound from the controller.\r
-\r
-\r
-* *Service Abstraction Layer (SAL)*: Where possible, allow for multiple southbound protocols to present the same northbound service interfaces.\r
-\r
-\r
-* *Open Extensible Northbound API*: Allow for an extensible set of application-facing APIs both across runtimes using REST (level 3 API) and within the same runtime using function calls (level 2 API). The set of accessible functions must be the same.\r
-\r
-\r
-* *Support for Multitenancy/Slicing*: Allow for the network to be logically (and/or physically) split into different slices or tenants with parts of the controller and modules explicitly dedicated to one or a subset of these slices. This includes allowing the controller to present different views of the controller depending on which slice the caller is from.\r
-\r
-\r
-* *Consistent Clustering*: Clustering that gives fine-grained redundancy and scale-out while insuring network consistency.\r
-\r
-\r
-=== Open extensible northbound API\r
-\r
-Allow for an extensible set of application-facing APIs both across runtimes using REST (level 3 API) and within the same runtime using function calls (level 2 API). The set of accessible functions must be the same.\r
-\r
-\r
-Here are the APIs presented by the OpenDaylight projects:\r
-\r
-* OpenDaylight Controller:\r
-** AD-SAL https://wiki.opendaylight.org/view/OpenDaylight_Controller:REST_Reference_and_Authentication[REST and Java APIs]\r
-\r
-\r
-** MD-SAL https://wiki.opendaylight.org/view/OpenDaylight_Controller:RESTCONF_Northbound_APIs[RESTCONF Northbound APIs]\r
-\r
-\r
-* OpenDaylight Virtual Tenant Network - https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Coordinator:RestApi[REST API]\r
-\r
-\r
-* Open DOVE - https://wiki.opendaylight.org/view/Open_DOVE:API[Northbound API]\r
-\r
-\r
-* OpenFlow Plugin - N/A\r
-\r
-\r
-* Affinity Metadata Service - N/A\r
-\r
-\r
-* YANG Tools - https://wiki.opendaylight.org/view/YANG_Tools:Available_Models[Available YANG models]\r
-\r
-\r
-* LISP Flow Mapping - https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Java_API[Java API] and https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:REST_API[REST API]\r
-\r
-\r
-* OVSDB - https://wiki.opendaylight.org/view/OVSDB_Integration:REST_API[REST API]\r
-\r
-\r
-* OpenFlow Protocol Library - https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main#Public_API[public API]\r
-\r
-\r
-* BGP-LS/PCEP - N/A\r
-\r
-\r
-* Defense4All - N/A\r
-\r
-\r
-* SNMP4SDN - https://wiki.opendaylight.org/view/File:SAL_API_for_SNMP_SouthBound_Plugin.pdf[(proposed) API]\r
-\r
+++ /dev/null
-== Overview of AD-SAL\r
-\r
-API-Driven Service Abstraction Layer (AD-SAL) is a flavour of the SAL created for the OpenDaylight controller project. The main task of AD-SAL is primarily to create a layer against which the applications can be developed without needing to know the underlying SDN protocols. Using AD-SAL, you can control two different type of network elements in an SDN fashion, meaning by accessing them in a programmatic way. \r
-\r
-AD-SAL was introduced based on the requirements of the network user, such as:\r
-\r
-* Given a network element, list the neighbours and build the network graph.\r
-\r
-* Given a network element, list the interfaces attached to it and what properties they carry.\r
-\r
-Starting from these requirements, we can also assume that certain aspects of the SDN protocols would be common no matter what the actual protocol is doing underneath. This idea allows us to describe the aspects in a generic way using a Java Contract which is usually a set of Java interfaces and supporting objects that represent the data. This way of creating contracts that allows a consumer of the contract to be insulated by the possible implementation is rather common in the Java world. Some examples are as follows:\r
-\r
-* https://www.jcp.org/en/jsr/detail?id=315[Servlet 3.0]\r
-\r
-* http://en.wikipedia.org/wiki/Jax-rs[JAX-RS]\r
-\r
-These examples use http://en.wikipedia.org/wiki/Java_Specification_Request[JSR (Java Specification Request)] which can be implemented by different providers.\r
-\r
-For example Servlet 3.0 contracts can be implemented by Tomcat or Jetty or other servlet container. Going by the same analogy, the protocol plugins (i.e. the components that can understand an SDN protocol and convert them to the common layer) can implement one or more of these contracts based on the capabilities. The SAL defined in AD-SAL is just an adaptation layer to enable the protocol plugins to speak common aspects but only if they can do it. The SAL does not force a lowest common denominator for all to be spoken, but rather given a certain aspect if the protocol plugins supports it, it will be supported in a common fashion.\r
-\r
-=== An example of protocols in AD-SAL\r
-\r
-image::multiprotocol_AD-SAL.jpg[title="Protocols in AD-SAL", alt="Protocols in AD-SAL"]\r
-\r
-\r
-In the image above, there are 4 types of contracts, identified by the coloured triangles, and there are 3 protocol plugins that provide implementation for those contracts. \r
-\r
-For example the *Topology* contract (the one used to learn the network graph) is implemented by all of the protocol plugins while the *Bridge Configuration* contract is only implemented by OVSDB because the others are not capable of it. That is perfectly fine and actually expected because that allows us not to revert to the lowest common denominator feature for all the protocol plugins. \r
-\r
-The image below explains how an application has to deal with the optional presence of a contract on a given network element. In the image, an application is trying to create a bridge on Nodes O1, O2 and OF1, the first two are capable of that contract, the third one is not, so the application has to take care of it and handle the return code.\r
-\r
-image::Applications_AD-SAL.jpg[title="Applications using AD-SAL", alt="Applications using AD-SAL"]\r
-\r
-In summary AD-SAL is just enforcing that the protocol plugins speak a common language for words that can be expressed in a common language. The dictionary of the common language is not hardcoded, it can be extended supplying new contracts to AD-SAL such that new protocols plugin can implement it and applications can consume them.\r
-\r
-To migrate from AD-SAL to MD-SAL, see https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:AD-SAL_Compatibility[MD-SAL:AD-SAL Compatibility].\r
-\r
-NOTE: For information on MD-SAL, see the relevant pages in this document.\r
-\r
-=== Differences between AD-SAL and MD-SAL\r
-\r
-.Differences between AD-SAL and MD-SAL\r
-\r
-[cols="2*", options="header"]\r
-\r
-|===\r
-\r
-|AD-SAL |MD-SAL \r
-\r
-|API-Driven SAL\r
-\r
-|Model-Driven SAL\r
-\r
-\r
-|The SAL APIs request routing between consumers and providers. Data adaptations are all statically defined at compile or build time.\r
-\r
-|The SAL APIs request routing between consumers and providers as defined from models, and data adaptations are provided by internal adaptation plugins.\r
-\r
-|The AD-SAL typically has both northbound and southbound APIs even for functions or services that are mapped 1:1 between southbound plugins and northbound plugins.\r
-\r
-|The MD-SAL allows both the northbound and southbound plugins to use the same API generated from a model. One plugin becomes an API (service) provider; the other becomes an API (service) consumer.\r
-\r
-|In AD-SAL there is a dedicated REST API for each northbound or southbound plugin.\r
-\r
-| MD-SAL provides a common REST API to access data and functions defined in models.\r
-\r
-|The AD-SAL provides request routing (selects a southbound plugin based on service type) and optionally provides service adaptation, if an northbound (Service, abstract) API is different from its corresponding southbound (protocol) API.\r
-\r
-| The MD-SAL provides request routing and the infrastructure to support service adaptation, but it does not provide service adaptation itself, service adaptation is provided by plugins.\r
-\r
-\r
-|Request routing is based on plugin type. The SAL knows which node instance is served by which plugin, and when a northbound plugin requests an operation on a given node, the request is routed to the appropriate plugin which then routes the request to the appropriate node.\r
-\r
-| Request Routing in the MD-SAL is done on both protocol type and node instances, since node instance data is exported from the plugin into the SAL.\r
-\r
-|AD-SAL is stateless.\r
-\r
-| MD-SAL can store data for models defined by plugins. Provider and consumer plugins can exchange data through the MD-SAL storage.\r
-\r
-\r
-|Limited to flow-capable device and service models only.\r
-\r
-|Model agnostic. It can support any device or service models and is not limited to flow-capable device and service models only.\r
-\r
-\r
-\r
-|AD-SAL services usually provide both asynchronous and synchronous versions of the same API method.\r
-\r
-|In MD-SAL, service model APIs only provide asynchronous APIs, but they return a *java.concurrent.Future* object, which allows a caller to block until the call is processed and a result object is available. Same API can be used for both synchronous and asynchronous approach. Thus MD-SAL encourages asynchronous approach to application design but does not preclude synchronous applications.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
+++ /dev/null
-== OpenDaylight controller overview\r
-\r
-The OpenDaylight controller is a JVM software and can be run from any operating system and hardware as long as it supports Java. It is a implementation of the concept of Software Defined Network (SDN).\r
-\r
-=== Background to the emergence of SDN\r
-\r
-Current generation networks and architectures are statically configured and vertically integrated. New generation applications require networks to be agile and flexibly adapt to application requirements. As networks get larger, especially in massively scalable datcenters and cloud, there is a large requirement for ease-of-management and orchestration.\r
-\r
-The following are the requirements of modern consumers of the networking industry:\r
-\r
-\r
-* *Agile networks*: As application programmers require their applications to be moved around in a datacenter or across clouds, it becomes imperative that the network becomes agile in meeting the requirements (bandwidth, services like load balancing, firewall) of the applications.\r
-\r
-* *Vendor neutrality*: Network abstraction and virtualization is required as it allows the network operators to operate the network at a higher level without worrying about the quirkiness of different products from the same or different vendors.\r
-\r
-\r
-* *Ease of building new applications*: Network operators require that they be able to influence the forwarding and other network behavior based on their own algorithms and business logic. That means there is a need for the network to not be vertically integrated with the networking control logic coming only from the networking vendor.\r
-\r
-\r
-=== SDN architecture principles\r
-\r
-SDN consists of a network applications layer on the top written to open API. There is a controller in the middle interacting with and managing network devices. Clearly there needs to be some sort of API or protocol needed for the controller and the network devices to communicate with each other. OpenFlow is one such protocol which has come out of the efforts of Open Networking Foundation (ONF). The network devices support agents which interpret the protocol and the API.\r
-\r
-\r
-Central to the SDN effort is the controller which provides the ability to deploy software to control the network gear and redeploy as needed. The vision is to have a modular controller with a well published Northbound API for network applications to write towards while utilizing southbound protocols such as OpenFlow to communicate with supported downstream network nodes. The industry and end users will benefit immensely by having an OpenSource controller with contributions from various industry players.\r
-\r
-The OpenDaylight controller supports not only the OpenFlow protocol but also other open protocols to allow communication with devices which have OpenFlow and/or respective agents. It also includes Northbound APIs to allow customer applications (software) to work with the controller in controlling the network. The customer applications cover a wide spectrum of solutions for solving customer needs across different vertical market segments.\r
-\r
-The controller architecture supports both the hybrid switch model as well as the classical OpenFlow model of having a fully centralized control plane.\r
-\r
-=== OpenDaylight controller framework\r
-\r
-The following image shows the framework of the OpenDaylight controller.\r
-\r
-\r
-image::odl-framework.jpg[title="Framework of OpenDaylight", alt="Framework of OpenDaylight"]\r
-\r
-OpenDaylight uses the following tools or paradigms:\r
-\r
-* *Maven*: OpenDaylight uses Maven for easier build automation. Maven uses pom.xml (Project Object Model) to script the dependencies between bundle and also to describe what bundles to load and start.\r
-\r
-* *OSGi*: This framework is the back-end of OpenDaylight as it allows dynamically loading bundles and packages JAR files, and binding bundles together for exchanging information.\r
-\r
-* *JAVA interfaces*: Java interfaces are used for event listening, specifications, and forming patterns. This is the main way in which specific bundles implement call-back functions for events and also to indicate awareness of specific state.\r
-\r
-* *REST APIs*: These are northbound APIs such as topology manager, host tracker, flow programmer, static routing, and so on.\r
-\r
-The controller exposes open northbound APIs which are used by applications. The OSGi framework and bidirectional REST are supported for the northbound APIs. The OSGi framework is used for applications that run in the same address space as the controller while the REST (web-based) API is used for applications that do not run in the same address space (or even the same system) as the controller. The business logic and algorithms reside in the applications. These applications use the controller to gather network intelligence, run its algorithm to do analytics, and then orchestrate the new rules throughout the network.\r
-\r
-On the southbound, multiple protocols are supported as plugins, e.g. OpenFlow 1.0, OpenFlow 1.3, BGP-LS, and so on. The OpenDaylight controller starts with an OpenFlow 1.0 southbound plugin. Other OpenDaylight contributors begin adding to the controller code. These modules are linked dynamically into a *Service Abstraction Layer* (SAL). \r
-\r
-The SAL exposes services to which the modules north of it are written. The SAL figures out how to fulfil the requested service irrespective of the underlying protocol used between the controller and the network devices. This provides investment protection to the applications as OpenFlow and other protocols evolve over time. For the controller to control devices in its domain, it needs to know about the devices, their capabilities, reachability, and so on. This information is stored and managed by the *Topology Manager*. The other components like ARP handler, Host Tracker, Device Manager, and Switch Manager help in generating the topology database for the Topology Manager.\r
-\r
-The controller has a built in GUI. The GUI is implemented as an application using the same Northbound API as would be available for any other user application.\r
-\r
-See the sections below for an overview of the main components of the OpenDaylight controller.\r
-\r
-=== Service Abstraction Layer framework\r
-\r
-Service Abstraction Layer (SAL) is at the heart of the modular design of the controller and allows it to support multiple protocols on the southbound. SAL also provides consistent services for modules and applications where the business logic is embedded.\r
-\r
-image::SAL.jpg[title="Framework of SAL", alt="Framework of SAL"]\r
-\r
-The OSGi framework allows dynamically linking plugins for the evolving southbound protocols. The SAL provides basic services such as device discovery which is used by modules like Topology Manager to build the topology and device capabilities. Services are constructed using the features exposed by the plugins (based on the presence of a plugin and capabilities of a network device). Based on the service request, the SAL maps to the appropriate plugin and uses the most appropriate southbound protocol to interact with a given network device. Each plugin is independent of others and is loosely coupled with the SAL.\r
-\r
-NOTE: The OpenFlow 1.0 plugin is currently provided with OpenDaylight and other plugins shown in the images are examples of the extensibility of the SAL framework. The SAL framework is included in the OpenDaylight controller contribution.\r
-\r
-=== SAL architecture\r
-\r
-\r
-image::sal_architecture.jpg[title="SAL system architecture", alt="SAL system architecture"]\r
-\r
-\r
-The subsystems in the above figure are as follows:\r
-\r
-* *Provider*: A component that exhibits functionality to applications and other providers (plugins) through its northbound API. A provider can be a consumer of other providers. There are two types of providers:\r
-\r
-** *Binding Independent Providers*: Their functionality is exhibited in the binding-independent Data DOM format.\r
-\r
-** *Binding Aware Providers*: Their functionality is exposed in a format compiled against one or more generated binding interfaces.\r
-\r
-* *Consumer*: A component that consumes functionality provided by one or more providers. There are two types of consumers:\r
-\r
-** *Binding Independent Consumers*: Their functionality is consumed in the binding-independent Data DOM format.\r
-\r
-** *Binding Independent Consumers*: Their functionality is consumed using one or more generated binding interfaces.\r
-\r
-* *Binding Independent Broker*: The core component of the model-driven SAL. It routes RPCs, notifications and data changes between various providers and consumers.\r
-\r
-* *Binding Aware Broker*: Provides programmatic APIs and Java language support to both consumers such as controller applications or plugins and providers. It is a façade or proxy built on top of the Binding Independent Broker that simplifies access to data and services provided by Binding-Independent providers and Binding-Aware providers.\r
-\r
-\r
-* *BI Data Repository*: A binding-independent infrastructure component of SAL that is responsible for storage of configuration and transient data.\r
-\r
-* *Binding Schema Repository*: An infrastructure component responsible for storing specifications of YANG–Java relationships and mapping between language-binding APIs to binding-independent API calls.\r
-\r
-* *Binding Generator*: A SAL infrastructure component which generates implementations of binding interfaces and data mappers to the binding-independent format.\r
-\r
-=== SAL architecture subsystems\r
-\r
-In context of the controller architecture, two subsystem categories are defined:\r
-\r
-\r
-* *Top-Level Subsystems*: Subsystems such as a data store, or a validator. There is typically only a single instance of a top-level subsystem per API revision. Top-level subsystems can be controller components or applications (providers or consumers) deployed in the controller that use the controller SAL to communicate with other controller components, applications, and plugins.\r
-Top-Level Subsystems usually have either a single instance per system or API, or multiple versioned instances, where each instance is unique to a revision of the contract defined by YANG models. In the latter case, each instance represents a single closed system. Prime examples for top-level subsystem are brokers and data repositories.\r
-\r
-* *Nested Subsystems*: A subsystem which could be local or remote. It can expose a set of functionality at multiple places or in multiple instances. A network element, such as a router or switch, is an example of a nested subsystem. Data of a nested subsystem is attached or mounted under a node in the controller’s datastore. The data in a nested subsystem may represent data present in another system or in a local controller component, such as a plugin. It may also be dynamically generated by a controller component, or translated from other protocols.\r
-\r
-NOTE: Consumers may need to invoke the functionality provided by nested subsystems. An RPC Broker must provide functionality that enableS nested RPC functionality in Providers. Furthermore, a Broker must be able to route RPCs to the Providers of nested subsystems for further processing.\r
-\r
-\r
-=== SAL service sets\r
-\r
-* *Topology services* is a set of services that allow to convey topology information such as discovering a new node, a new link, and so on.\r
-\r
-* *Data Packet services* are SAL services that deliver the packets coming from the agents to applications.\r
-\r
-* *Flow Programming services* provide the necessary logic to program different match-actions rules.\r
-\r
-* *Statistics services* export APIs to collect statistics per flow, node connector, queue, and so on.\r
-\r
-* *Inventory services* provide APIs for returning inventory information about the node and node connectors for example.\r
-\r
-* *Resource services* is a placeholder to query resource status.\r
-\r
-\r
-==== Data packet service as example of SAL service implementation\r
-\r
-As an example of a SAL service implementation, see the Data Packet Service with OpenFlow 1.0 plugin in the section below.\r
-\r
-image::data_packet_service.jpg[title="Data packet service ", alt="Data packet service"]\r
-\r
-\r
-* *IListenDataPacket* is a service implemented by the upper layer module or application (ARP Handler is one such module) which wants to receive data packets.\r
-\r
-\r
-* *IDataPacketService* is an interface that provides the service of sending and receiving packets from the agent. This service is registered in the OSGi service registry so that an application can retrieve it.\r
-\r
-* *IPluginOutDataPacketService* is an interface that is exported by SAL when a protocol plugin wants to deliver a packet toward the application layer.\r
-\r
-* *IPluginInDataPacketService* is an interface that is exported by the protocol plugin and is used to send out the packets through SAL towards the agent on the network devices.\r
-\r
-The process followed by the SAL is described as follows:\r
-\r
-. The OpenFlow plugin receives an ARP packet that must be dispatched to the ARP handler application.\r
-\r
-. The OpenFlow Plugin calls *IPluginOutDataPacketService* to get the packet to the SAL.\r
-\r
-. The ARP handler application is registered to the *IListenDataPacket Service*. The SAL hands over the packet to the ARP handler application.\r
-\r
-\r
-. The application now processes the packet.\r
-\r
-\r
-For the reverse process of the application sending a packet out, the process followed is described below:\r
-\r
-. The application constructs the packet and calls the interface *IDataPacketService* to send the packet. The destination network device is to be provided as part of the API.\r
-\r
-. SAL calls the *IPluginInDataPacketService* interface for a given protocol plugin based on the destination network device, the protocol is OpenFlow in this case.\r
-\r
-. The protocol plugin then ships the packet to the appropriate network element. The plugin handles all protocol-specific processing.\r
-\r
-NOTE: For more information on other service sets, see the Java and API documentation.\r
-\r
-=== Northbound and southbound plugins\r
-\r
-See the images below for examples of SAL northbound and southbound plugins.\r
-\r
-image::SAL_NB_Plugins.jpg[title="SAL northbound plugins", alt="SAL northbound plugins"]\r
-\r
-\r
-image::SAL_sb.jpg[title="SAL southbound plugins", alt="SAL southbound plugins"]\r
-\r
-=== OpenDaylight modules\r
-\r
-The following are the OpenDaylight modules. See the relevant sections for an overview of each module.\r
-\r
-* AD-SAL - API-Driven Service Abstraction Layer\r
-\r
-* AD-SAL Network Service Functions for OpenFlow-capable nodes:\r
-\r
-** Switch Manager\r
-\r
-** Statistics Manager\r
-\r
-** Host Tracker\r
-\r
-** ARP Handler\r
-\r
-** Forwarding Rules Manager (FRM)\r
-\r
-** Topology Manager\r
-\r
-* Clustering and High-Availability Services for AD-SAL\r
-\r
-* MD-SAL - Model-Driven Service Adaptation Layer\r
-\r
-* MD-SAL Base Network Functions:\r
-\r
-** Topology Exporters\r
-\r
-** Inventory Managers\r
-\r
-* MD-SAL Network Service Functions for OpenFlow-capable nodes:\r
-\r
-** Forwarding Rules Manager (FRM)\r
-\r
-** Statistics Manager\r
-\r
-* MD-SAL NETCONF Connector (Southbound NETCONF Plugin)\r
-\r
-* MD-SAL RESTCONF Connector (Northbound RESTCONF Plugin) - an infrastructure component that renders REST APIs for device/service models loaded into the controller\r
-\r
-* Config Subsystem - NETCONF/YANG based framework for configuration, performance and fault management of controller infrastructure and plugins deployed into the controller\r
-\r
-* NSF Adapters - Network Service Function Adapter that allow the MD-SAL based OF1.0/1.3 Plugin to talk with AS-SAL based Network Service Functions\r
-\r
-\r
-=== OpenDaylight controller GUI\r
-\r
-The GUI is implemented as an application and uses the northbound REST API to interact with the other modules of the controller. The architecture thus ensures that whatever is available with the GUI is also available using the REST API. The controller can be integrated easily into other management or orchestration systems.\r
-\r
-=== High Availability\r
-\r
-The OpenDaylight controller supports a cluster-based high availability model. There are several instances of the OpenDaylight controller which logically act as one logical controller. This not only gives redundancy but also allows a scale-out model for linear scalability. To make the controller highly available, resilience needs to be added at the controller, OpenFlow-enabled switches, and the applications.\r
-\r
-The OpenFlow enabled switches connect to two or more instances of the controller using persistent point-to-point TCP/IP connection. On the northbound side, between the controller and the applications, the interaction is done using RESTful webservices. This is applicable for all the request-response types of interaction. The interactions based on HTTP and being HTTP based on non-persistent connections between the server and the client, it's possible to leverage all the high-available techniques used to give resilience on the web such as:\r
-\r
-* Providing the cluster of controller with a virtual IP to be reached using an anycast type of solution\r
-\r
-\r
-* Having the application to talk to the cluster after a DNS request is done using a DNS round-robin technique\r
-\r
-* Deploying between the applications and the cluster of controller an HTTP load-balancer that can not only provide resilience but also distributed the workload accordingly to the URL requested.\r
-\r
-The interaction between the controller(s) and the Open-Flow enabled switches is essentially to have one Openflow switch multi-homed to multiple controller, so if one of the controller goes down another is ready to control the switch. This interaction has already been specified in the OpenFlow 1.2 specifications in particular Section 6.3 of Openflow 1.2 specifications. To summarize it when having multiple controllers connected to one switch, the openflow 1.2 specification specify two mode of operations:\r
-\r
-* Equal interaction: in this case all the controllers have read/write access to the switch, which means they have to syncronize in order no to step on each other feet.\r
-\r
-\r
-* Master/Slave interaction: in this case there will be one master and multiple slaves (there could be still multiple equal as well)\r
-\r
-\r
-For more information, see the OpenDaylight wiki.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
+++ /dev/null
-== Getting started with Git and Gerrit\r
-\r
-Git is an opensource distributed version control system (dvcs) written in the C language and originally developed by Linus Torvalds and others to manage the Linux kernel. In Git, there is no central copy of the repository. After you have cloned the repository, you have a functioning copy of the source code with all the branches and tagged releases, in your local repository.\r
-\r
-Gerrit is an opensource web-based collaborative code review tool that integrates with Git. It was developed at Google by Shawn Pearce. Gerrit provides a framework for reviewing code commits before they are accepted into the code base. Changes can be uploaded to Gerrit by any user. However, the changes are not made a part of the project until a code review is completed. Gerrit is also a good collaboration tool for storing the conversations that occur around the code commits.\r
-\r
-The OpenDaylight source code is hosted in a repository in Git. Developers must use Gerrit to commit code to the OpenDaylight repository.\r
-\r
-NOTE: For more information on Git, see http://git-scm.com/. For more information on Gerrit, see https://code.google.com/p/gerrit/.\r
-\r
-=== Setting up a Gerrit account\r
-\r
-. Using a Google Chrome or Mozilla Firefox browser, go to https://git.opendaylight.org/gerrit\r
-\r
-The main page shows existing Gerrit requests. These are patches that have been pushed to the repository and not yet verified, reviewed, and merged.\r
-\r
-NOTE: If you already have an OpenDaylight account, you can click *Sign In* in the top right corner of the page and follow the instructions to enter the OpenDaylight page.\r
-\r
-.Signing in to OpenDaylight account\r
-\r
-image::Sign_in.jpg[Signing in to OpenDaylight account]\r
-\r
-[start=2]\r
-\r
-. If you do not have an existing OpenDaylight account, click *Account signup/management* on the top bar of the main Gerrit page.\r
-\r
-The *WS02 Identity Server* page is displayed.\r
-\r
-\r
-.Gerrit Account signup/management link\r
-\r
-image::Gerrit_setup.jpg[Account signup/management link]\r
-\r
-[start=3]\r
-\r
-. In the *WS02 Identity Server* page, click *Sign-up* in the left pane.\r
-\r
-There is also an option to authenticate your sign in with OpenID. This option is not described in this document.\r
-\r
-.Sign-up link for Gerrit account\r
-\r
-image::sign-up.jpg[Sign-up link for Gerrit account]\r
-\r
-[start=4]\r
-\r
-. Click on the *Sign-up with User Name/Password* image on the right pane to continue to the actual sign-up page.\r
-\r
-.Sign-up with User Name/Password Image\r
-\r
-image::signup_image.jpg[Sign-up with User Name / Password Image]\r
-\r
-[start=5]\r
-\r
-. Fill out the details in the account creation form and then click *Submit*.\r
-\r
-.Filling out the details\r
-\r
-image::form_details.jpg[Filling out the details]\r
-\r
-You now have an OpenDaylight account that can be used with Gerrit to pull the OpenDaylight code.\r
-\r
-=== Generating SSH keys for your system\r
-\r
-You must have SSH keys for your system to register with your Gerrit account. The method for generating SSH keys is different for different types of operating systems.\r
-\r
-The key you register with Gerrit must be identical to the one you will use later to pull or edit the code. For example, if you have a development VM which has a different UID login and keygen than that of your laptop, the SSH key you generate for the VM is different from the laptop. If you register the SSH key generated on your VM with Gerrit and do not reuse it on your laptop when using Git on the laptop, the pull fails.\r
-\r
-NOTE: For more information on SSH keys for Ubuntu, see https://help.ubuntu.com/community/SSH/OpenSSH/Keys. For generating SSH keys for Windows, see https://help.github.com/articles/generating-ssh-keys.\r
-\r
-For a system running Ubuntu operating system, follow the steps below:\r
-\r
-. Run the following command:\r
-\r
-[literal]\r
-\r
-mkdir ~/.ssh\r
-chmod 700 ~/.ssh\r
-ssh-keygen -t rsa\r
-\r
-[start=2]\r
-\r
-. You are prompted for a location to save the keys, and a passphrase for the keys.\r
-\r
-This passphrase protects your private key while it is stored on the hard drive. You must use the passphrase to use the keys every time you need to login to a key-based system.\r
-\r
-[literal]\r
-\r
-Generating public/private rsa key pair.\r
-Enter file in which to save the key (/home/b/.ssh/id_rsa):\r
-Enter passphrase (empty for no passphrase):\r
-Enter same passphrase again:\r
-Your identification has been saved in /home/b/.ssh/id_rsa.\r
-Your public key has been saved in /home/b/.ssh/id_rsa.pub.\r
-\r
-Your public key is now available as *.ssh/id_rsa.pub* in your home folder.\r
-\r
-=== Registering your SSH key with Gerrit\r
-\r
-. Using a Google Chrome or Mozilla Firefox browser, go to https://git.opendaylight.org/gerrit.\r
-\r
-[start=2]\r
-. Click *Sign In* to access the OpenDaylight repository.\r
-\r
-.Signin in to OpenDaylight repository\r
-\r
-image::Sign_in.jpg[Signin in to OpenDaylight repository]\r
-\r
-[start=3]\r
-. Click your name in the top right corner of the window and then click *Settings*.\r
-\r
-The *Settings* page is displayed.\r
-\r
-.Settings page for your Gerrit account\r
-\r
-image::Gerrit_settings.jpg[Settings page for your Gerrit account]\r
-\r
-[start=4]\r
-. Click *SSH Public Keys* under *Settings*.\r
-\r
-. Click *Add Key*.\r
-\r
-. In the *Add SSH Public Key* text box, paste the contents of your *id_rsa.pub* file and then click *Add*.\r
-\r
-.Adding your SSH key\r
-\r
-image::SSH_keys.jpg[Adding your SSH key]\r
-\r
-To verify your SSH key is working correctly, try using an SSH client to connect to Gerrit's SSHD port. \r
-\r
-[literal]\r
-\r
-$ ssh -p 29418 <sshusername>@git.opendaylight.org\r
-Enter passphrase for key '/home/cisco/.ssh/id_rsa': \r
-**** Welcome to Gerrit Code Review ****\r
-Hi <user>, you have successfully connected over SSH.\r
-Unfortunately, interactive shells are disabled.\r
-To clone a hosted Git repository, use: git clone ssh://<user>@git.opendaylight.org:29418/REPOSITORY_NAME.git\r
-Connection to git.opendaylight.org closed.\r
-\r
-You can now proceed to either Pulling, Hacking, and Pushing the Code from the CLI or Pulling, Hacking, and Pushing the Code from Eclipse depending on your implementation.\r
-\r
-\r
-\r
-\r
+++ /dev/null
-== Load balancer service as a sample OpenDaylight application\r
-\r
-This is a sample load balancer application that balances traffic to back-end servers based on the source address and source port on each incoming packet. The service reactively installs OpenFlow rules to direct all packets with a specific source address and source port to one of the appropriate back-end servers. The servers may be selected using a round robin policy or a random policy. This service can be configured using a REST API which is similar to the OpenStack Quantum LBaaS (Load-balancer-as-a-Service) v1.0 API proposal at http://wiki.openstack.org/Quantum/LBaaS.\r
-\r
-To use the load balancer service, a virtual IP (or VIP) must be introduced to the clients of the service and used as the destination address. \r
-\r
-NOTE: A VIP is an entity that comprises of a virtual IP, port, and protocol (TCP or UDP).\r
-\r
-=== Assumptions for the VIP\r
-\r
-The assumptions for the VIP are as follows:\r
-\r
-* One or more VIPs may be mapped to the same server pool. \r
-\r
-* All VIPs that share the same pool must also share the same load balancing policy. The policy may be random or round robin.\r
-\r
-* Only one server pool can be be assigned to a VIP.\r
-\r
-* All flow rules are installed with an idle time-out of 5 seconds.\r
-\r
-* The flow rules must automatically time out after the idle time-out of 5 seconds.\r
-\r
-* Packets to a VIP must leave the OpenFlow cluster from the same switch from where they entered.\r
-\r
-\r
-* When you delete a VIP or a server pool or a server from a pool, the service does not delete the already installed flow rules. \r
-\r
-\r
-=== Load balancer REST APIs summary\r
-\r
-.Load balancer REST APIs summary\r
-\r
-[cols="5*", options="header"]\r
-\r
-|===\r
-\r
-|Description |URI |Type |Request Body/Arguments |Response Codes\r
-\r
-|List details of all existing pools\r
-\r
-|/one/nb/v2/lb/{container-name*}/\r
-\r
-|GET\r
-\r
-| \r
-\r
-\r
-|200 ("Operation successful") +\r
-\r
-404 ("The containerName is not found") +\r
-\r
-503 "Load balancer service is unavailable")\r
-\r
-\r
-\r
-|List details of all existing VIPs\r
-\r
-|/one/nb/v2/lb/{container-name}/vips\r
-\r
-|GET\r
-\r
-|\r
-\r
-\r
-|200 ("Operation successful") +\r
-\r
-404 ("The containerName is not found") +\r
-\r
-503 ("Load balancer service is unavailable")\r
-\r
-\r
-\r
-|Create pool \r
-\r
-|/one/nb/v2/lb/{container-name}/create/pool\r
-\r
-\r
-|POST\r
-\r
-\r
-|{\r
-"name":"",\r
-"lbmethod":""\r
-}\r
-\r
-|201 ("Pool created successfully") +\r
-\r
-404 ("The containerName not found") +\r
-\r
-503 ("Load balancer service is unavailable") +\r
-\r
-409 ("Pool already exist") +\r
-\r
-415 ("Invalid input data") +\r
- \r
-\r
-|Delete pool\r
-\r
-|/one/nb/v2/lb/{container-name}/delete/pool/{pool-name}\r
-\r
-|Delete\r
-\r
-|\r
-\r
-\r
-|200 ("Pool deleted successfully") + \r
-\r
-404 ("The containerName not found") +\r
-\r
-503 ("Load balancer service is unavailable") +\r
-\r
-404 ("Pool not found") +\r
-\r
-500 ("Failed to delete pool")\r
-\r
-|Create VIP\r
-\r
-|/one/nb/v2/lb/{container-name}/create/vip\r
-\r
-|POST\r
-\r
-|{\r
-"name":"", \r
-"ip":"ip in (xxx.xxx.xxx.xxx) format", \r
-"protocol":"TCP/UDP", \r
-"port":"any valid port number", \r
-"poolname":"" (optional) \r
-}\r
-\r
-|201 ("VIP created successfully")+\r
- \r
-404 ("The containerName not found") +\r
-\r
-503 ("Load balancer service is unavailable")+\r
- \r
-409 ("VIP already exists") +\r
-\r
-415 ("Invalid input data")\r
-\r
-\r
-|Update VIP\r
-\r
-|/one/nb/v2/lb/{container-name}/update/vip\r
-\r
-|PUT\r
-\r
-|{ \r
-"name":"", \r
-"poolname":"" \r
-}\r
-\r
-|201 ("VIP updated successfully") +\r
-\r
-404 ("The containerName not found") +\r
-\r
-503 ("VIP not found") +\r
-\r
-404 ("Pool not found") +\r
-\r
-405 ("Pool already attached to the VIP") +\r
-\r
-415 ("Invalid input name")\r
-\r
-|Delete VIP\r
-\r
-|/one/nb/v2/lb/{container-name}/delete/vip/{vip-name}\r
-\r
-|DELETE\r
-\r
-|\r
-\r
-\r
-|200 ("VIP deleted successfully") +\r
-\r
-404 ("The containerName not found") +\r
-\r
-503 ("Load balancer service is unavailable") +\r
-\r
-404 ("VIP not found") +\r
-\r
-500 ("Failed to delete VIP") \r
-\r
-\r
-|Create pool member\r
-\r
-\r
-|/one/nb/v2/lb/{container-name}/create/poolmember\r
-\r
-\r
-|POST\r
-\r
-|{ \r
-"name":"", \r
-"ip":"ip in (xxx.xxx.xxx.xxx) format", \r
-"poolname":"existing pool name" \r
-}\r
-\r
-\r
-|201 ("Pool member created successfully") +\r
- \r
-404 ("The containerName not found") +\r
-\r
-503 ("Load balancer service is unavailable") +\r
-\r
-404 ("Pool not found") +\r
-\r
-409 ("Pool member already exists") +\r
-\r
-415 ("Invalid input data") +\r
- \r
-\r
-|Delete pool member \r
-\r
-|/one/nb/v2/lb/{container-name}/delete/poolmember/{pool-member-name}/{pool-name}\r
-\r
-|DELETE\r
-\r
-|\r
-\r
-|200 ("Pool member deleted successfully") +\r
-\r
-404 ("The containerName not found") +\r
-\r
-503 ("Load balancer service is unavailable") +\r
-\r
-404 ("Pool member not found") +\r
-\r
-404 ("Pool not found")\r
-\r
-|===\r
-\r
-\r
-NOTE: Current implementation of OpenDaylight uses `default` as a container name. Property `name` of each individual entity must be unique.\r
-\r
-=== Starting the load balancer\r
-\r
-. Start the OpenDaylight controller. Ensure that the *samples.loadbalancer* and *samples.loadbalancer.northbound* modules are loaded by the controller.\r
-\r
-. Create any mininet topology and connect it to the controller. For this example, assume a tree topology with *depth=2* and *fanout=4*. This topology creates 16 hosts, 4 edge switches each connected to 4 hosts, and 1 core switch connected to all the 4 edge switches. You can use the following command to start mininet with this tree topology.\r
-\r
-[literal]\r
-\r
-mn --topo=tree,2,4 --controller=remote,ip=<Host IP where controller is running>,port=6633\r
-\r
-This default tree topology assigns ip addresses from 10.0.0.1 to 10.0.0.16/8 IP to its 16 hosts.\r
-\r
-[start=3]\r
-\r
-. Add a default gateway in OpenDaylight for the mininet network as mentioned in the following URL: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Installation\r
-\r
-. Run the command *pingall* in mininet and make sure that all the hosts are reachable from each other.\r
-\r
-. Create the load balancer pool with round robin load balancing policy as follows:\r
-\r
-[literal]\r
-\r
-curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST\r
-http://<Controller_IP>:8080/one/nb/v2/lb/default/create/pool -d '{"name":"PoolRR","lbmethod":"roundrobin"}'\r
-\r
-[start=6]\r
-. Create the load balancer VIP as follows:\r
-\r
-[literal]\r
-curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST\r
-http://<Controller_IP>:8080/one/nb/v2/lb/default/create/vip -d '{"name":"VIP-RR","ip":"10.0.0.20","protocol":"TCP","port":"5550","poolname":"PoolRR"}'\r
-\r
-Pool-name data in the REST call above is optional. In case no pool exists while creating the VIP, you can attach the pool at a later point of time by using the following REST call:\r
-\r
-[literal]\r
-curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT\r
-http://<Controller_IP>:8080/one/nb/v2/lb/default/update/vip -d '{"name":"VIP-RR","poolname":"PoolRR"}'\r
-\r
-\r
-[start=7]\r
-. Add pool members to the load balancer pool. Host H1 (10.0.0.1) will be used as a source or client that sends traffic to the VIP.\r
-\r
-[literal]\r
-curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST\r
-http://<Controller_IP>:8080/one/nb/v2/lb/default/create/poolmember -d '{"name":"PM2","ip":"10.0.0.2","poolname":"PoolRR"}'\r
-curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST\r
-http://<Controller_IP>:8080/one/nb/v2/lb/default/create/poolmember -d '{"name":"PM3","ip":"10.0.0.3","poolname":"PoolRR"}'\r
-\r
-Similarly you can add all the remaining 13 hosts to the pool.\r
-\r
-[start=8]\r
-. Since the VIP created in step 6 does not exist in the network, the controller does not resolve the ARP for the IP of the VIP. The load balancer application assumes that if the VIP is configured and exposed by the user to an internal or external network. Packets that are destined to the VIP's IP address gets routed to it through external mechanisms. For this example, we can locally resolve the ARP for the VIP's IP, by adding static entry to the ARP table of the client or source host. The steps below takes you through details of how to accomplish the step.\r
-\r
-==== Locally resolving ARP for the VIP's IP\r
-\r
-. Spawn xterm for hosts h1 to h4 from the mininet prompt.\r
-\r
-. Add static ARP entry for VIP's IP address in the host h1 ARP cache. Run the following command in the h1 xterm window to add the ARP entry.\r
-\r
-[literal]\r
-arp -s 10.0.0.20 00:00:10:00:00:20\r
-\r
-[start=3]\r
-\r
-. On h1, start iperf client that sends traffic to the virtual ip address.\r
-\r
-[literal]\r
-iperf -c 10.0.0.20 -p 5550\r
-\r
-The iperf client connects to the iperf server running on host h2.\r
-\r
-[start=4]\r
-\r
-. After the previous test of iperf finishes, trigger the iperf client again. The iperf client connects to the iperf server running on host h3. Similarly, in the next iteration, it connects to the h4 node in round robin fashion.\r
-\r
-Similarly, you can try the random load balancing policy by creating the load balancer pool with `random` policy. \r
-\r
-\r
-=== Cleaning the load balancer entity\r
-\r
-You can run the following curl commands to clean up the load balancer entities you created in the previous section.\r
-\r
-==== Deleting pool members\r
-\r
-Delete pool members by running the command below:\r
-\r
-[literal]\r
-\r
-curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X DELETE\r
-http://<Controller_IP>:8080/one/nb/v2/lb/default/delete/poolmember/PM2/PoolRR'\r
-\r
-You can delete the remaining pool members similarly.\r
-\r
-==== Deleting VIP\r
-\r
-Delete VIP by running the command below:\r
-\r
-[literal]\r
-\r
-curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X DELETE\r
-http://<Controller_IP>:8080/one/nb/v2/lb/default/delete/vip/VIP-RR\r
-\r
-\r
-==== Deleting pool\r
-\r
-Delete pool by running the command below:\r
-\r
-[literal]\r
-curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X DELETE\r
-http://<Controller_IP>:8080/one/nb/v2/lb/default/delete/pool/PoolRR\r
-\r
+++ /dev/null
-== Pulling, contributing, and pushing the OpenDaylight controller code using the GIT CLI\r
-\r
-The OpenDaylight project has a number of sub-projects under it. Each of these sub-projects have their own repositories in Gerrit. You can use either Git or Eclipse to contribute to the code for any of these sub-projects.\r
-\r
-For a list of OpenDaylight projects, see https://wiki.opendaylight.org/view/Main_Page#Projects[OpenDaylight Projects].\r
-\r
-=== Prerequisites for contributing code to the OpenDaylight project\r
-\r
-* You have created a Gerrit account and have registered a public-private key pair for using Git over SSH. For more information, see https://wiki.opendaylight.org/view/OpenDaylight_Controller:Gerrit_Setup[Getting started with Git and Gerrit].\r
-\r
-* Your credentials (name, email) are configured properly in Git by running the following command:\r
-\r
-[literal]\r
-git config --global user.name "John Doe"\r
-git config --global user.email johndoe@example.com\r
-\r
-* You are familiar with Git commands. For more information, see https://wiki.opendaylight.org/view/GIT_Cheat_Sheet[GIT Cheat Sheet].\r
-\r
-* You have installed Maven in your system. For more information about Maven, see http://maven.apache.org/[Apache Maven Project].\r
-\r
-To install Maven using *yum* as the package manager, run the command:\r
-\r
-[literal]\r
-sudo yum install maven\r
-\r
-* You have installed Java 1.7+ in your system, including the JDK. For more information, see http://www.oracle.com/technetwork/java/javase/downloads/index.html[Java SE Downloads].\r
-\r
-To install Java using *yum* as the package manager, run the command:\r
-\r
-[literal]\r
-sudo yum install java-1.7.0-openjdk\r
-\r
-The output must match the sample message given below:\r
-\r
-[literal]\r
-[~]$ java -version\r
-java version "1.7.0_55"\r
-OpenJDK Runtime Environment (fedora-2.4.7.0.fc20-x86_64 u55-b13)\r
-OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)\r
-\r
-NOTE: For more information on setting up the environment for developing code for OpenDaylight, see https://wiki.opendaylight.org/view/GettingStarted:Development_Environment_Setup[Getting Started with the Development Environment].\r
-\r
-NOTE: You may also use the git review tool to push your changes to the repository. For more information, see https://wiki.opendaylight.org/view/Git-review_Workflow[Git Review Workflow]\r
-\r
-\r
-\r
-\r
-=== Building the OpenDaylight code\r
-\r
-Run the following command:\r
-\r
-[literal]\r
-cd opendaylight/distribution/opendaylight/\r
-mvn clean install\r
-\r
-=== Troubleshooting Maven issues\r
-\r
-* The Maven build may run out of PermGen depending on the number of artifacts built. This issue usually occurs when building the opendaylight distribution. To resolve the issue, increase the PermGens. Set the value of the environment variable as follows:\r
-\r
-[literal]\r
-MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m"\r
-/* syntax for setting varies on the OS used by the build machine.*/\r
-\r
-* If you receive a Maven error when building northbound integration tests, you can skip building the tests by running the following command:\r
-\r
-[literal]\r
-mvn clean install -DskipTests \r
-/* instead of "mvn clean install" */\r
-\r
-* If you have issues with maven needing a proxy, see http://www.mkyong.com/maven/how-to-enable-proxy-setting-in-maven/[How To Enable Proxy Setting In Maven].\r
-\r
-=== Running the OpenDaylight controller\r
-\r
-. Run the following command:\r
-\r
-[literal]\r
-cd controller/opendaylight/distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/\r
-./run.sh\r
-\r
-\r
-[start=2]\r
-. Go to *http://localhost:8080/* and login in with username *admin* and password *admin*.\r
-\r
-\r
-NOTE: For more information in running the controller, see the Installation Guide.\r
-\r
-\r
-=== Pulling the code from the remote repository\r
-\r
-To pull the latest changes from the Git repository, run the following command:\r
-\r
-[literal]\r
-git pull ssh://<username>@git.opendaylight.org:29418/controller.git HEAD:refs/for/master\r
-\r
-=== Committing the code using the Developer Certificate of Origin\r
-\r
-Your contributions to the OpenDaylight code is accepted only if you attach the http://elinux.org/Developer_Certificate_Of_Origin[Developer Certificate Of Origin]. The certificate implies that you have made the changes and the work was done as part of an open-source license.\r
-\r
-To attach the certificate, run the command below:\r
-\r
-[literal]\r
-git commit --signoff\r
-\r
-Or\r
-\r
-[literal]\r
-git commit -s\r
-\r
-You are prompted for a commit message. If you are fixing an issue from Bugzilla, you can add the information to your commit message and it will get linked from Gerrit.\r
-\r
-[literal]\r
-Fix for bug 2.\r
-Signed-off-by: Ed Warnicke <eaw@cisco.com>\r
-# Please enter the commit message for your changes. Lines starting\r
-# with '#' will be ignored, and an empty message aborts the commit.\r
-# On branch master\r
-# Changes to be committed:\r
-# (use "git reset HEAD <file>..." to unstage)\r
-#\r
-# modified: README\r
-#\r
-\r
-If you wish to add the signoff to the commit message on your every commit without the need to specify *--s* or *--signoff*, add the following lines in the end of *.git/hooks/commit-msg*, after the line *"add_ChangeId"*:\r
-\r
-[literal]\r
-SOB=$(git var GIT_AUTHOR_IDENT | sed -n 's/^\(.*>\).*$/Signed-off-by: \1/p')\r
-grep -qs "^$SOB" "$1" || echo "$SOB" >> "$1"\r
-\r
-\r
-=== Pushing the code\r
-\r
-* To push your changes to the repository, run the command below:\r
-\r
-[literal]\r
-git push ssh://<username>@git.opendaylight.org:29418/controller.git HEAD:refs/for/master\r
-\r
-To push a draft that is not to be merged, run the command below:\r
-\r
-[literal]\r
-git push ssh://<username>@git.opendaylight.org:29418/controller.git HEAD:refs/drafts/master\r
-\r
-A message similar to the following is displayed:\r
-\r
-[literal]\r
-remote: Resolving deltas: 100% (2/2)\r
-remote: Processing changes: new: 1, refs: 1, done \r
-remote: \r
-remote: New Changes:\r
-remote: http://git.opendaylight.org/gerrit/64\r
-remote: \r
-\r
-=== Reviewing and merging the code\r
-\r
-. Copy the link from the display message of your git push command and run it in a browser.\r
-The link must display that the code is verified by the Jenkins Controller User and a link is provided to the Jenkins build. See the figure below.\r
-\r
-image::Jenkins_message.jpg[title="Code Changes in Gerrit", alt="Code Changes in Gerrit"]\r
-\r
-\r
-[start=2]\r
-. After your code is reviewed and submitted by a committer, it will be merged into the authoritative repository. See the figure below.\r
-\r
-image::merged_code.jpg[title="Merging Code in Gerrit", alt="Merging Code in Gerrit"]\r
-\r
-=== Troubleshooting blocked port 29418\r
-\r
-There have been reports that many firewalls may block port 29418. To resolve the issue, use HTTP to clone the repository.\r
-\r
-[literal]\r
-git clone https://<your_username>@git.opendaylight.org/gerrit/p/controller.git\r
-\r
-You are prompted for the password you generated in https://wiki.opendaylight.org/view/OpenDaylight_Controller:Setting_up_HTTP_in_Gerrit[Setting up HTTP in Gerrit].\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
+++ /dev/null
-== Running the OpenDaylight controller\r
-\r
-NOTE: Download the latest build of the controller from https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/opendaylight/distribution/opendaylight/target/[here]. The source code of the OpenDaylight controller is in a directory called opendaylight. In this directory (the corresponding directory in the git repository is usually the distribution/opendaylight/target/distribution.opendaylight-0.1.0-SNAPSHOT-osgipackage/opendaylight).\r
-\r
-NOTE: The controller platform has specific core bundles, each of which export important services through Java interfaces. Here is a brief list of important ones that come in handy while developing network services. These are located at https://wiki.opendaylight.org/view/Controller_Projects%27_Modules/Bundles_and_Interfaces[Controller Projects' Modules, Bundles, and Interfaces].\r
-\r
-NOTE: For a list of files in OpenDaylight karaf, see https://wiki.opendaylight.org/view/Karaf_Distribution_Folder_and_File_Guide[Karaf Distribution Folder and File Guide].\r
-\r
-Apache Karaf is a small OSGi based runtime which provides a lightweight container onto which various components and applications can be deployed. It tends to be helpful to think of Karaf as providing an ecosystem for an application where various libraries and frameworks are collected and tested that they work well together, simplifying your runtime experience.\r
-\r
-There are two ways to start the controller in Karaf.\r
-\r
-. Run the command below to access the Karaf console:\r
-\r
-[literal]\r
-\r
-bin/karaf\r
-\r
-. Run the command below to start Karaf as a background task, accessing the console using SSH:\r
-\r
-[literal]\r
-\r
-bin/start\r
-\r
-SSH is listening on 8101 and the default username and password is karaf/karaf. Run the command below to access the console\r
-\r
-[literal]\r
-ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 8101 karaf@<controllerIP>\r
-\r
-To log out of the SSH shell, run the command below:\r
-\r
-[literal]\r
-shell: logout\r
-\r
-==== Installing or uninstalling controller features\r
-\r
-Features that are installed as part of the karaf-compatible-all integration job include the following files: \r
-\r
-* odl-restconf\r
-* odl-mdsal-apidocs\r
-* odl-integration-compatible-with-l2switch \r
-\r
-Before starting karaf, you can edit the file *etc/org.apache.karaf.features.cfg* to install additional features. Modify the line `featuresBoot=config,standard,region,package,kar,ssh,management` to be `featuresBoot=config,standard,region,package,kar,ssh,management,odl-restconf,odl-mdsal-apidocs, odl-integration-compatible-with-l2switch`\r
-\r
-\r
-\r
-=== Karaf CLI\r
-\r
-* To list only installed features, run the command: \r
-\r
-[literal]\r
- feature:list -i \r
- \r
-\r
-* Filter with grep\r
-\r
-[literal]\r
-feature:list | grep openflowplugin \r
-\r
-* List bundles loaded\r
-\r
-[literal]\r
- bundle:list -s\r
- \r
-List web endpoints\r
-\r
-[literal]\r
-web:list\r
-\r
-\r
-Uninstall a feature\r
-\r
-\r
-[literal]\r
- feature:uninstall odl-l2switch-switch \r
-\r
- \r
-=== Running the controller GUI\r
-\r
-\r
-. Navigate to http://controller-ip:8080 to open the web interface, then use the following credentials to log in:\r
-\r
-** *User*: admin\r
-\r
-** *Password*: admin\r
-\r
-\r
+++ /dev/null
-== Welcome to the OpenDaylight project\r
-\r
-\r
-The Open Daylight Project is a collaborative open source project under the Linux foundation that aims to accelerate adoption of Software-Defined Networking (SDN) and create a solid foundation for Network Functions Virtualization (NFV) for a more transparent approach that fosters new innovation and reduces risk. Founded by industry leaders and open to all, the OpenDaylight community is developing a common, open SDN framework consisting of code and blueprints.\r
-\r
-\r
-=== OpenDaylight project scope\r
-\r
-The projects chosen by the Technical Steering Committee (TSC) are limited to the following areas:\r
-\r
-* The OpenDaylight controller\r
-\r
-* Software for forwarding elements\r
-\r
-* Southbound plugins to enable the controller to speak to the OpenDaylight supplied and other network elements\r
-\r
-* Northbound plugins to expose interfaces to those writing applications to the controller\r
-\r
-* Network services and applications intended to run on top of the controller, integration between the controller and other elements\r
-\r
-* Support projects such as tools, infrastructure, or testing\r
-\r
-* Plugins for inter-controller communication\r
-\r
-\r
-=== OpenDaylight project goals\r
-\r
-* *Code*: To create a robust, extensible, open source code base that covers the major common components required to build an SDN solution.\r
-\r
-* *Acceptance*: To get broad industry acceptance amongst vendors and users.\r
-\r
-* *Community*: To have a thriving and growing technical community contributing to the code base, using the code in commercial products, and adding value above, below and around. \r
-\r
-=== Additional information for the OpenDaylight project\r
-\r
-* For frequently asked questions about the OpenDaylight project, see the http://www.opendaylight.org/project/faq[FAQ].\r
-\r
-\r
-* You can join OpenDaylight as a user, developer, or as a member of the project. See the http://www.opendaylight.org/resources/getting-started-guide[ Getting Started with OpenDaylight].\r
-\r
-\r
-* Exhaustive information about OpenDaylight is available in the https://wiki.opendaylight.org/view/Main_Page[OpenDaylight Wiki].\r
-\r
-\r
-\r
-\r
+++ /dev/null
-== Overview of RESTCONF\r
-\r
-NOTE: Important characteristics of RESTCONF are described below. For more information, see the http://www.ietf.org/archive/id/draft-bierman-netconf-restconf-04.txt[RESTCONF Protocol].\r
-\r
-* RESTCONF is a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF.\r
-\r
-* RESTCONF is not intended to replace NETCONF, but rather provide an additional simplified interface that follows REST-like principles and is compatible with a resource-oriented device abstraction.\r
-\r
-* The RESTCONF protocol operates on a conceptual datastore defined with the YANG data modeling language. The server lists each YANG module it supports under “/restconf/modules” in the top-level API resource type, using a structure based on the YANG module capability URI format.\r
-\r
-* The conceptual datastore contents, data-model-specific operations and notification events are identified by the set of YANG module resources. All RESTCONF content identified as either a data resource, operation resource, or event stream resource is defined with the YANG language.\r
-\r
-* The classification of data as configuration or non-configuration is derived from the YANG “config” statement. Data ordering behavior is derived from the YANG “ordered-by” statement.\r
-\r
-* RESTCONF allows access to datastores located in the controller. There are two datastores\r
-*Config* that contains data inserted via the controller and *Operational* that contains data inserted via the network.\r
-\r
-* RESTCONF listens on port 8080 for HTTP requests\r
-\r
-* RESTCONF supports OPTIONS, GET, PUT, POST, DELETE operations.\r
-\r
-* Request and response data can be in XML or JSON format. XML has structure according to yang by XML-YANG and JSON by JSON-YANG.\r
-\r
-\r
-The NETCONF protocol defines configuration datastores and a set of Create, Retrieve, Update, Delete (CRUD) operations that can be used to access these datastores. For more information on NETCONF, see RFC6241.\r
-\r
-The YANG language defines the syntax and semantics of datastore content, operational data, protocol operations, and notification events. For more information on YANG, see RFC6020.\r
-\r
-The RESTCONF protocol uses HTTP methods to identify the CRUD operation requested for a particular resource. The following table shows how the RESTCONF operations relate to NETCONF protocol operations:\r
-\r
-\r
-=== RESTCONF in OpenDaylight\r
-\r
-Restconf allows access to datastores in the controller. There are two datastores:\r
-\r
-* Config: Contains data inserted via controller\r
-\r
-* Operational: Contains other data\r
-\r
-NOTE: Each request must start with URI /restconf. Restconf listens on port 8080 for HTTP requests.\r
-\r
-Restconf supports `OPTIONS`, `GET`, `PUT`, `POST`, and `DELETE` operations. Request and response data can either be in the XML or JSON format. XML structures according to yang are defined at: http://tools.ietf.org/html/rfc6020[XML-YANG]. JSON structures are defined at: http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-02[JSON-YANG]. Data in the request must have a correctly set “Content-Type” field in the http header with the allowed value of the media type. The media type of the requested data has to be set in the “Accept” field. Get the media types for each resource by calling the OPTIONS operation. \r
-\r
-\r
-Most of the RESTCONF endpoints paths use Instance Identifier. <identifier> is used in the explanation of the operations. \r
-\r
-\r
-`<identifier>`\r
-\r
-\r
-* It must start with <moduleName>:<nodeName> where <moduleName> is a name of the module and <nodeName> is the name of a node in the module. It is sufficient to just use <nodeName> after <moduleName>:<nodeName>. Each <nodeName> has to be separated by /.\r
-\r
-\r
-* <nodeName> can represent a data node which is a list or container yang built-in type. If the data node is a list, there must be defined keys of the list behind the data node name for example, <nodeName>/<valueOfKey1>/<valueOfKey2>.\r
-\r
-\r
-* The format <moduleName>:<nodeName> has to be used in this case as well:\r
-Module A has node A1. Module B augments node A1 by adding node X. Module C augments node A1 by adding node X. Then for clarification it has to be known which node X is thought (e.g. C:X).\r
-\r
-\r
-For more details about encoding see: http://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-5.3.1[Restconf 02 - Encoding YANG Instance Identifiers in the Request URI].\r
-\r
-NOTE: A Node can be behind a mount point. In this case, the URI has to be in format <identifier>/yang-ext:mount/<identifier>. The first <identifier> is the path to a mount point and the second <identifier> is the path to a node behind the mount point. A URI can end in a mount point itself by using <identifier>/yang-ext:mount. For more information, see https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf.\r
-\r
-NOTE: For more information on RESTCONF, see https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf.\r
-\r
-\r
-=== URLs exposed by RESTCONF in OpenDaylight\r
-\r
-* The RESTCONF API to access nodes in OpenDaylight inventory is http://<controller-ip>:8080/restconf/operational/opendaylight-inventory:nodes/\r
-\r
-* The RESTCONF API to access information of a particular node in OpenDaylight inventory is http://<controller-ip>:8080/restconf/operational/opendaylight-inventory:nodes/node/id [replace id by the actual node id]\r
-\r
-* The RESTCONF API to access OpenDaylight topology information is http://<controller-ip>:8080/restconf/operational/network-topology:network-topology/topology/flow:1\r
-\r
-=== RESTCONF Northbound APIs for OpenDaylight controller\r
-\r
-Yang models are used in the MD-SAL and in MD-SAL-based applications to define all APIs such as inter-component APIs, plugin APIs, northbound APIs, etc. Yang models are used to generate Java APIs at compile time with OpenDaylight Yang Tools and to render REST APIs at run time according to the RESTCONF specification. Plugins designed for MD-SAL define yang models for their northbound REST APIs, which are then exposed to applications via an MD-SAL RESTCONF adapter.\r
-\r
-\r
-image::SAL_nb_pugins.jpg[title="SAL Northbound Examples", alt="SAL Northbound Plugin Examples"]\r
-\r
-\r
-=== Writing a new application for OpenDaylight\r
-\r
-. Download the OpenDaylight VM and set up the controller. For more information, see the Installation Guide for the OpenDaylight controller.\r
-\r
-. Update the dependencies and services exported in the new bundle's pom.xml.\r
-\r
-. List dependencies imported and interfaces implemented in the module's activator.java.\r
-\r
-. Update set or unset bindings in the module's class so as to access other bundle objects.\r
-\r
-. Implement the interface functions to handle the async events or use other bundle objects to edit the state.\r
-\r
-. Add the required northbound REST API and associate with the web bundle.\r
-\r
-\r
-=== Creating a new northbound REST bundle\r
-\r
-\r
-The easiest way of introducing a new northbound REST API is to copy an existing one and making the relevant changes as below:\r
-\r
-. pom.xml – update the artifact-name , Web-ContextPath and dependencies.\r
-\r
-. enunciate.xml – update the defaultRestSubContext and the description.\r
-\r
-. src/main/java/…/*Northbound*.java – Rename/Update the request handler and the necessary logic as required.\r
-\r
-. src/main/test/… - Add necessary unit tests.\r
-\r
-\r
-. commons/northbound-integrationtest module - Add necessary integration tests.\r
-\r
-. Reference the bundle from the distribution assembly descriptor to be included in the distribution.\r
-\r
-\r
-\r
-\r
-\r
-\r
+++ /dev/null
-== OpenDaylight controller REST reference and authentication\r
-\r
-You can locate the REST API reference information for each of the modules by navigating to the northbound module directories in your installation. The OpenDaylight Controller REST API contains the following modules. The associated module directory for the API reference content is listed:\r
-\r
-For more information, see https://wiki.opendaylight.org/view/OpenDaylight_Controller:REST_Reference_and_Authentication.\r
-\r
+++ /dev/null
-=== Using Mininet\r
-\r
-Mininet creates a realistic virtual network, running real kernel, switch and application code, on a single machine (VM, cloud or native) with a single command and within a short time. Using Mininet, you can easily interact with your network using the Mininet CLI (and API), customize it, share it with others, or deploy it on real hardware, Mininet is useful for development, teaching, and research.\r
-\r
-Mininet is also a great way to develop, share, and experiment with OpenFlow and Software-Defined Networking systems.\r
-\r
-NOTE: To know more about Mininet, see http://mininet.org/walkthrough/[Mininet Walkthrough].\r
-\r
-To use Mininet for OpenDaylight, \r
-\r
-. Download http://mininet.github.com/download/[Mininet] . OpenDaylight controller is tested against the Mininet VM (Option 1). It has not been tested against other Mininet installation options.\r
-\r
-. Launch the Mininet VM with VirtualBox or another virtualization application.\r
-\r
-. Log on to the Mininet VM with the following credentials:\r
-\r
-*** *user*: mininet\r
-\r
-*** *password*: mininet\r
-\r
-. Determine the IP address of the server hosting the OpenDaylight controller, and use it to start a virtual network by running the following command:\r
-\r
-[literal]\r
-\r
-sudo mn --controller=remote,ip=controller-ip --topo tree,3\r
-\r
-Mininet connects to OpenDaylight controller and sets up a three-level tree topology.\r
-\r
-\r
-[literal]\r
-mininet@mininet-vm:~$ sudo mn --controller=remote,ip=172.16.102.161 --topo tree,3\r
-*** Creating network\r
-*** Adding controller\r
-*** Adding hosts:\r
-h1 h2 h3 h4 h5 h6 h7 h8 \r
-*** Adding switches:\r
-s1 s2 s3 s4 s5 s6 s7 \r
-*** Adding links:\r
-(h1, s3) (h2, s3) (h3, s4) (h4, s4) (h5, s6) (h6, s6) (h7, s7) (h8, s7) (s1, s2) (s1, s5) (s2, s3) (s2, s4) (s5, s6) (s5, s7) \r
-*** Configuring hosts \r
-h1 h2 h3 h4 h5 h6 h7 h8 \r
-*** Starting controller\r
-*** Starting 7 switches\r
-s1 s2 s3 s4 s5 s6 s7 \r
-*** Starting CLI:\r
-mininet>\r
-\r
-NOTE: See the http://mininet.github.com/walkthrough/Mininet[Mininet Walkthrough] for a more detailed explanation of Mininet configuration options. There is an appendix that explains how to configure Mininet to use a remote controller.\r
-\r
-=== Troubleshooting Mininet\r
-\r
-If you are running VirtualBox on the same host or desktop where the controller is running, and trying to start the virtual network on Mininet VM, the following error is displayed `"Unable to contact the remote controller at ...",` then the following steps resolves the issue:\r
-\r
-. In VirtualBox, go to File > Preferences > Network and make sure you have at least one interface defined as *Host-Only*. Lets say its name is `vboxnet0`.\r
-\r
-. In VirtualBox > Mininet VM > Settings > Network, check that the adapter is of type *Host-Only*, and is connected to the interface from item 1 `(vboxnet0)`.\r
-\r
-. On your host where the controller and VirtualBox run, run the `ifconfig` command to display all network interfaces on the machine.\r
-\r
-Search for the interface as in item 1 (`vboxnet0` in our example). Take the ip address specified (most probably 192.168.56.1 - default), and use that as the correct remote controller ip address when starting a VM in mininet as stated in the example above (--controller=remote,ip=192.168.56.1).\r
-\r
-. If you are still not able to connect, you might want to consider temporarily disabling firewall on the host running the controller (on Linux, for example, `iptables -F` will do the job).\r
-\r
-. Sometimes, the way you start the mininet is can be an issue. It does not give an error, but does not connect to the remote server either. Here is such an example:\r
-\r
-[literal]\r
-sudo mn --topo=tree,3 --mac --switch=ovsk --controller=remote, ip=192.168.16.10\r
-\r
-Here is the correct example:\r
-\r
-[literal]\r
-sudo mn --topo=tree,3 --mac --switch=ovsk --controller=remote,ip=192.168.16.10\r
-\r
-NOTE: The difference is the "SPACE" between "remote," and "ip".\r
-\r
-If Mininet crashes or if you lose your console from a remote connection, the switches remain configured in the database. Run the following command to clean up:\r
-\r
-[literal]\r
-\r
-$ sudo mn -c\r
-\r
-=== Resetting Mininet\r
-\r
-Here's a perl from the appendix mentioned above:\r
-\r
-If Mininet crashes or if you lose your console from a remote connection, the switches remain configured in the database and you'll want to clean them up.\r
-\r
-[literal]\r
-\r
-$ sudo mn -c\r
-\r
-\r
-\r
-=== Using the Simple Forwarding Application\r
-\r
-The OpenDaylight Controller includes an application called Simple Forwarding that lets you use the basic services for making forwarding decisions and install flows across all devices on the OpenFlow network. This application discovers the presence of a host via ARP message and installs dest-only /32 entries across all switches in the network, with the corresponding output ports toward the host.\r
-\r
-. With OpenDaylight Controller and Mininet running as described in previous sections, log into the web interface.\r
-\r
-image::Devices1.jpg[title="OpenDaylight GUI", alt="OpenDaylight GUI"]\r
-\r
-[start=2]\r
-. Drag and drop devices to organize the topology into its logical arrangement, then save the configuration.\r
-\r
-image::Devices2.jpg[title="Clicking Save", alt="Clicking Save"]\r
-\r
-\r
-[start=3]\r
-. Click the *Add Gateway IP Address* (shown in the figure above) and add the IP and subnet of `10.0.0.254/8`.\r
-\r
-\r
-image::GatewayIP.jpg[title="Adding the Gateway IP Address", alt="Adding the Gateway IP Address"]\r
-\r
-[start=4]\r
-. Confirm that hosts are now reachable from one another. On the console where Mininet is running, have one host ping another.\r
-\r
-[literal]\r
-\r
-mininet> h1 ping h7\r
-PING 10.0.0.7 (10.0.0.7) 56(84) bytes of data.\r
-64 bytes from 10.0.0.7: icmp_req=1 ttl=64 time=1.52 ms\r
-64 bytes from 10.0.0.7: icmp_req=2 ttl=64 time=0.054 ms\r
-64 bytes from 10.0.0.7: icmp_req=3 ttl=64 time=0.060 ms\r
-64 bytes from 10.0.0.7: icmp_req=4 ttl=64 time=0.052 ms\r
---- 10.0.0.7 ping statistics ---\r
-4 packets transmitted, 4 received, 0% packet loss, time 2999ms\r
-rtt min/avg/max/mdev = 0.052/0.422/1.523/0.635 ms\r
-mininet> \r
-\r
-[start=5]\r
-. Click the *Troubleshooting* tab and then load the *Flows* for one of the switches.\r
-\r
-image::FlowStatitistics.jpg[title="Flow statistics", alt="Flow statistics"]\r
-\r
-\r
-[start=6]\r
-. View the *Ports* details.\r
-image::PortsStatistics.jpg[title="Port Statistics", alt="Port Statistics"]\r
-\r
-\r
-[start=7]\r
-. On the OSGI console, type `ss simple`. You will see that the Simple Forwarding application is ACTIVE.\r
-\r
-[literal]\r
-osgi> ss simple\r
-"Framework is launched."\r
-id State Bundle\r
-45 ACTIVE org.opendaylight.controller.samples.simpleforwarding_0.4.0.SNAPSHOT\r
-\r
-\r
-\r
+++ /dev/null
-== DIDM Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/didm-developer-guide.html
+++ /dev/null
-== DLUX
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/dlux.html
+++ /dev/null
-== Fabric As A Service
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/fabric-as-a-service.html
+++ /dev/null
-== IoTDM Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/iotdm-developer-guide.html
+++ /dev/null
-== L2Switch Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/l2switch-developer-guide.html
+++ /dev/null
-== LACP Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/lacp-developer-guide.html
+++ /dev/null
-== NATApp Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/natapp-developer-guide.html
+++ /dev/null
-== NetIDE Developer Guide ==
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/netide-developer-guide.html
+++ /dev/null
-== Neutron Northbound
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/neutron-northbound.html
+++ /dev/null
-== Neutron Service Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/neutron-service-developer-guide.html
+++ /dev/null
-== Network Intent Composition (NIC) Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/network-intent-composition-(nic)-developer-guide.html
+++ /dev/null
-== OCP Plugin Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/ocp-plugin-developer-guide.html
+++ /dev/null
-== OpenDaylight controller overview\r
-\r
-The OpenDaylight controller is a JVM software and can be run from any operating system and hardware as long as it supports Java. It is a implementation of the concept of Software Defined Network (SDN).\r
-\r
-=== Background to the emergence of SDN\r
-\r
-Current generation networks and architectures are statically configured and vertically integrated. New generation applications require networks to be agile and flexibly adapt to application requirements. As networks get larger, especially in massively scalable datcenters and cloud, there is a large requirement for ease-of-management and orchestration.\r
-\r
-The following are the requirements of modern consumers of the networking industry:\r
-\r
-\r
-* *Agile networks*: As application programmers require their applications to be moved around in a datacenter or across clouds, it becomes imperative that the network becomes agile in meeting the requirements (bandwidth, services like load balancing, firewall) of the applications.\r
-\r
-* *Vendor neutrality*: Network abstraction and virtualization is required as it allows the network operators to operate the network at a higher level without worrying about the quirkiness of different products from the same or different vendors.\r
-\r
-\r
-* *Ease of building new applications*: Network operators require that they be able to influence the forwarding and other network behavior based on their own algorithms and business logic. That means there is a need for the network to not be vertically integrated with the networking control logic coming only from the networking vendor.\r
-\r
-\r
-=== SDN architecture principles\r
-\r
-SDN consists of a network applications layer on the top written to open API. There is a controller in the middle interacting with and managing network devices. Clearly there needs to be some sort of API or protocol needed for the controller and the network devices to communicate with each other. OpenFlow is one such protocol which has come out of the efforts of Open Networking Foundation (ONF). The network devices support agents which interpret the protocol and the API.\r
-\r
-\r
-Central to the SDN effort is the controller which provides the ability to deploy software to control the network gear and redeploy as needed. The vision is to have a modular controller with a well published Northbound API for network applications to write towards while utilizing southbound protocols such as OpenFlow to communicate with supported downstream network nodes. The industry and end users will benefit immensely by having an OpenSource controller with contributions from various industry players.\r
-\r
-The OpenDaylight controller supports not only the OpenFlow protocol but also other open protocols to allow communication with devices which have OpenFlow and/or respective agents. It also includes Northbound APIs to allow customer applications (software) to work with the controller in controlling the network. The customer applications cover a wide spectrum of solutions for solving customer needs across different vertical market segments.\r
-\r
-The controller architecture supports both the hybrid switch model as well as the classical OpenFlow model of having a fully centralized control plane.\r
-\r
-=== OpenDaylight controller framework\r
-\r
-The following image shows the framework of the OpenDaylight controller.\r
-\r
-\r
-image::odl-framework.jpg[title="Framework of OpenDaylight", alt="Framework of OpenDaylight"]\r
-\r
-OpenDaylight uses the following tools or paradigms:\r
-\r
-* *Maven*: OpenDaylight uses Maven for easier build automation. Maven uses pom.xml (Project Object Model) to script the dependencies between bundle and also to describe what bundles to load and start.\r
-\r
-* *OSGi*: This framework is the back-end of OpenDaylight as it allows dynamically loading bundles and packages JAR files, and binding bundles together for exchanging information.\r
-\r
-* *JAVA interfaces*: Java interfaces are used for event listening, specifications, and forming patterns. This is the main way in which specific bundles implement call-back functions for events and also to indicate awareness of specific state.\r
-\r
-* *REST APIs*: These are northbound APIs such as topology manager, host tracker, flow programmer, static routing, and so on.\r
-\r
-The controller exposes open northbound APIs which are used by applications. The OSGi framework and bidirectional REST are supported for the northbound APIs. The OSGi framework is used for applications that run in the same address space as the controller while the REST (web-based) API is used for applications that do not run in the same address space (or even the same system) as the controller. The business logic and algorithms reside in the applications. These applications use the controller to gather network intelligence, run its algorithm to do analytics, and then orchestrate the new rules throughout the network.\r
-\r
-On the southbound, multiple protocols are supported as plugins, e.g. OpenFlow 1.0, OpenFlow 1.3, BGP-LS, and so on. The OpenDaylight controller starts with an OpenFlow 1.0 southbound plugin. Other OpenDaylight contributors begin adding to the controller code. These modules are linked dynamically into a *Service Abstraction Layer* (SAL). \r
-\r
-The SAL exposes services to which the modules north of it are written. The SAL figures out how to fulfil the requested service irrespective of the underlying protocol used between the controller and the network devices. This provides investment protection to the applications as OpenFlow and other protocols evolve over time. For the controller to control devices in its domain, it needs to know about the devices, their capabilities, reachability, and so on. This information is stored and managed by the *Topology Manager*. The other components like ARP handler, Host Tracker, Device Manager, and Switch Manager help in generating the topology database for the Topology Manager.\r
-\r
-The controller has a built in GUI. The GUI is implemented as an application using the same Northbound API as would be available for any other user application.\r
-\r
-See the sections below for an overview of the main components of the OpenDaylight controller.\r
-\r
-=== Service Abstraction Layer framework\r
-\r
-Service Abstraction Layer (SAL) is at the heart of the modular design of the controller and allows it to support multiple protocols on the southbound. SAL also provides consistent services for modules and applications where the business logic is embedded.\r
-\r
-image::SAL.jpg[title="Framework of SAL", alt="Framework of SAL"]\r
-\r
-The OSGi framework allows dynamically linking plugins for the evolving southbound protocols. The SAL provides basic services such as device discovery which is used by modules like Topology Manager to build the topology and device capabilities. Services are constructed using the features exposed by the plugins (based on the presence of a plugin and capabilities of a network device). Based on the service request, the SAL maps to the appropriate plugin and uses the most appropriate southbound protocol to interact with a given network device. Each plugin is independent of others and is loosely coupled with the SAL.\r
-\r
-NOTE: The OpenFlow 1.0 plugin is currently provided with OpenDaylight and other plugins shown in the images are examples of the extensibility of the SAL framework. The SAL framework is included in the OpenDaylight controller contribution.\r
-\r
-=== SAL architecture\r
-\r
-\r
-image::sal_architecture.jpg[title="SAL system architecture", alt="SAL system architecture"]\r
-\r
-\r
-The subsystems in the above figure are as follows:\r
-\r
-* *Provider*: A component that exhibits functionality to applications and other providers (plugins) through its northbound API. A provider can be a consumer of other providers. There are two types of providers:\r
-\r
-** *Binding Independent Providers*: Their functionality is exhibited in the binding-independent Data DOM format.\r
-\r
-** *Binding Aware Providers*: Their functionality is exposed in a format compiled against one or more generated binding interfaces.\r
-\r
-* *Consumer*: A component that consumes functionality provided by one or more providers. There are two types of consumers:\r
-\r
-** *Binding Independent Consumers*: Their functionality is consumed in the binding-independent Data DOM format.\r
-\r
-** *Binding Independent Consumers*: Their functionality is consumed using one or more generated binding interfaces.\r
-\r
-* *Binding Independent Broker*: The core component of the model-driven SAL. It routes RPCs, notifications and data changes between various providers and consumers.\r
-\r
-* *Binding Aware Broker*: Provides programmatic APIs and Java language support to both consumers such as controller applications or plugins and providers. It is a façade or proxy built on top of the Binding Independent Broker that simplifies access to data and services provided by Binding-Independent providers and Binding-Aware providers.\r
-\r
-\r
-* *BI Data Repository*: A binding-independent infrastructure component of SAL that is responsible for storage of configuration and transient data.\r
-\r
-* *Binding Schema Repository*: An infrastructure component responsible for storing specifications of YANG–Java relationships and mapping between language-binding APIs to binding-independent API calls.\r
-\r
-* *Binding Generator*: A SAL infrastructure component which generates implementations of binding interfaces and data mappers to the binding-independent format.\r
-\r
-=== SAL architecture subsystems\r
-\r
-In context of the controller architecture, two subsystem categories are defined:\r
-\r
-\r
-* *Top-Level Subsystems*: Subsystems such as a data store, or a validator. There is typically only a single instance of a top-level subsystem per API revision. Top-level subsystems can be controller components or applications (providers or consumers) deployed in the controller that use the controller SAL to communicate with other controller components, applications, and plugins.\r
-Top-Level Subsystems usually have either a single instance per system or API, or multiple versioned instances, where each instance is unique to a revision of the contract defined by YANG models. In the latter case, each instance represents a single closed system. Prime examples for top-level subsystem are brokers and data repositories.\r
-\r
-* *Nested Subsystems*: A subsystem which could be local or remote. It can expose a set of functionality at multiple places or in multiple instances. A network element, such as a router or switch, is an example of a nested subsystem. Data of a nested subsystem is attached or mounted under a node in the controller’s datastore. The data in a nested subsystem may represent data present in another system or in a local controller component, such as a plugin. It may also be dynamically generated by a controller component, or translated from other protocols.\r
-\r
-NOTE: Consumers may need to invoke the functionality provided by nested subsystems. An RPC Broker must provide functionality that enableS nested RPC functionality in Providers. Furthermore, a Broker must be able to route RPCs to the Providers of nested subsystems for further processing.\r
-\r
-\r
-=== SAL service sets\r
-\r
-* *Topology services* is a set of services that allow to convey topology information such as discovering a new node, a new link, and so on.\r
-\r
-* *Data Packet services* are SAL services that deliver the packets coming from the agents to applications.\r
-\r
-* *Flow Programming services* provide the necessary logic to program different match-actions rules.\r
-\r
-* *Statistics services* export APIs to collect statistics per flow, node connector, queue, and so on.\r
-\r
-* *Inventory services* provide APIs for returning inventory information about the node and node connectors for example.\r
-\r
-* *Resource services* is a placeholder to query resource status.\r
-\r
-\r
-==== Data packet service as example of SAL service implementation\r
-\r
-As an example of a SAL service implementation, see the Data Packet Service with OpenFlow 1.0 plugin in the section below.\r
-\r
-image::data_packet_service.jpg[title="Data packet service ", alt="Data packet service"]\r
-\r
-\r
-* *IListenDataPacket* is a service implemented by the upper layer module or application (ARP Handler is one such module) which wants to receive data packets.\r
-\r
-\r
-* *IDataPacketService* is an interface that provides the service of sending and receiving packets from the agent. This service is registered in the OSGi service registry so that an application can retrieve it.\r
-\r
-* *IPluginOutDataPacketService* is an interface that is exported by SAL when a protocol plugin wants to deliver a packet toward the application layer.\r
-\r
-* *IPluginInDataPacketService* is an interface that is exported by the protocol plugin and is used to send out the packets through SAL towards the agent on the network devices.\r
-\r
-The process followed by the SAL is described as follows:\r
-\r
-. The OpenFlow plugin receives an ARP packet that must be dispatched to the ARP handler application.\r
-\r
-. The OpenFlow Plugin calls *IPluginOutDataPacketService* to get the packet to the SAL.\r
-\r
-. The ARP handler application is registered to the *IListenDataPacket Service*. The SAL hands over the packet to the ARP handler application.\r
-\r
-\r
-. The application now processes the packet.\r
-\r
-\r
-For the reverse process of the application sending a packet out, the process followed is described below:\r
-\r
-. The application constructs the packet and calls the interface *IDataPacketService* to send the packet. The destination network device is to be provided as part of the API.\r
-\r
-. SAL calls the *IPluginInDataPacketService* interface for a given protocol plugin based on the destination network device, the protocol is OpenFlow in this case.\r
-\r
-. The protocol plugin then ships the packet to the appropriate network element. The plugin handles all protocol-specific processing.\r
-\r
-NOTE: For more information on other service sets, see the Java and API documentation.\r
-\r
-=== Northbound and southbound plugins\r
-\r
-See the images below for examples of SAL northbound and southbound plugins.\r
-\r
-image::SAL_NB_Plugins.jpg[title="SAL northbound plugins", alt="SAL northbound plugins"]\r
-\r
-\r
-image::SAL_sb.jpg[title="SAL southbound plugins", alt="SAL southbound plugins"]\r
-\r
-=== OpenDaylight modules\r
-\r
-The following are the OpenDaylight modules. See the relevant sections for an overview of each module.\r
-\r
-* AD-SAL - API-Driven Service Abstraction Layer\r
-\r
-* AD-SAL Network Service Functions for OpenFlow-capable nodes:\r
-\r
-** Switch Manager\r
-\r
-** Statistics Manager\r
-\r
-** Host Tracker\r
-\r
-** ARP Handler\r
-\r
-** Forwarding Rules Manager (FRM)\r
-\r
-** Topology Manager\r
-\r
-* Clustering and High-Availability Services for AD-SAL\r
-\r
-* MD-SAL - Model-Driven Service Adaptation Layer\r
-\r
-* MD-SAL Base Network Functions:\r
-\r
-** Topology Exporters\r
-\r
-** Inventory Managers\r
-\r
-* MD-SAL Network Service Functions for OpenFlow-capable nodes:\r
-\r
-** Forwarding Rules Manager (FRM)\r
-\r
-** Statistics Manager\r
-\r
-* MD-SAL NETCONF Connector (Southbound RESTCONF Plugin)\r
-\r
-* MD-SAL RESTCONF Connector (Northbound NETCONF Plugin) - an infrastructure component that renders REST APIs for device/service models loaded into the controller\r
-\r
-* Config Subsystem - NETCONF/YANG based framework for configuration, performance and fault management of controller infrastructure and plugins deployed into the controller\r
-\r
-* NSF Adapters - Network Service Function Adapter that allow the MD-SAL based OF1.0/1.3 Plugin to talk with AS-SAL based Network Service Functions\r
-\r
-\r
-=== OpenDaylight controller GUI\r
-\r
-The GUI is implemented as an application and uses the northbound REST API to interact with the other modules of the controller. The architecture thus ensures that whatever is available with the GUI is also available using the REST API. The controller can be integrated easily into other management or orchestration systems.\r
-\r
-=== High Availability\r
-\r
-The OpenDaylight controller supports a cluster-based high availability model. There are several instances of the OpenDaylight controller which logically act as one logical controller. This not only gives redundancy but also allows a scale-out model for linear scalability. To make the controller highly available, resilience needs to be added at the controller, OpenFlow-enabled switches, and the applications.\r
-\r
-The OpenFlow enabled switches connect to two or more instances of the controller using persistent point-to-point TCP/IP connection. On the northbound side, between the controller and the applications, the interaction is done using RESTful webservices. This is applicable for all the request-response types of interaction. The interactions based on HTTP and being HTTP based on non-persistent connections between the server and the client, it's possible to leverage all the high-available techniques used to give resilience on the web such as:\r
-\r
-* Providing the cluster of controller with a virtual IP to be reached using an anycast type of solution\r
-\r
-\r
-* Having the application to talk to the cluster after a DNS request is done using a DNS round-robin technique\r
-\r
-* Deploying between the applications and the cluster of controller an HTTP load-balancer that can not only provide resilience but also distributed the workload accordingly to the URL requested.\r
-\r
-The interaction between the controller(s) and the Open-Flow enabled switches is essentially to have one Openflow switch multi-homed to multiple controller, so if one of the controller goes down another is ready to control the switch. This interaction has already been specified in the OpenFlow 1.2 specifications in particular Section 6.3 of Openflow 1.2 specifications. To summarize it when having multiple controllers connected to one switch, the openflow 1.2 specification specify two mode of operations:\r
-\r
-* Equal interaction: in this case all the controllers have read/write access to the switch, which means they have to syncronize in order no to step on each other feet.\r
-\r
-\r
-* Master/Slave interaction: in this case there will be one master and multiple slaves (there could be still multiple equal as well)\r
-\r
-\r
-For more information, see the OpenDaylight wiki.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
+++ /dev/null
-== ODL Parent Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/odl-parent-developer-guide.html
+++ /dev/null
-== OF-CONFIG Developer Guide ==
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/of-config-developer-guide.html
+++ /dev/null
-== OpenFlow Protocol Library Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/openflow-protocol-library-developer-guide.html
+++ /dev/null
-[[openflow-plugin-project-developer-guide]]
-== OpenFlow Plugin Project Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/openflow-plugin-project-developer-guide.html
+++ /dev/null
-== OpFlex agent-ovs Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/opflex-agent-ovs-developer-guide.html
+++ /dev/null
-== OpFlex genie Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/opflex-genie-developer-guide.html
+++ /dev/null
-== OpFlex libopflex Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/opflex-libopflex-developer-guide.html
+++ /dev/null
-== OVSDB NetVirt
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/ovsdb-netvirt.html
-
+++ /dev/null
-== PacketCable Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/packetcable-developer-guide.html
+++ /dev/null
-== ODL-SDNi Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/odl-sdni-developer-guide.html
+++ /dev/null
-== Service Function Chaining
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/alto-developer-guide.html
+++ /dev/null
-== SNBI Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/snbi-developer-guide.html
+++ /dev/null
-== SNMP4SDN Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/alto-developer-guide.html
+++ /dev/null
-== SXP Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/sxp-developer-guide.html
+++ /dev/null
-== Topology Processing Framework Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/topology-processing-framework-developer-guide.html
+++ /dev/null
-== TTP CLI Tools Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/ttp-cli-tools-developer-guide.html
+++ /dev/null
-== TTP Model Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/ttp-model-developer-guide.html
+++ /dev/null
-== UNI Manager Plug-In Developer Guide\r
-\r
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/uni-manager-plug-in-developer-guide.html\r
+++ /dev/null
-== Unified Secure Channel
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/unified-secure-channel.html
+++ /dev/null
-== Usecplugin-AAA Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/usecplugin-aaa-developer-guide.html
+++ /dev/null
-== Usecplugin-OpenFlow Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/usecplugin-openflow-developer-guide.html
+++ /dev/null
-== Virtual Tenant Network (VTN)
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/virtual-tenant-network-(vtn)-developer-guide.html
+++ /dev/null
-== YANG-PUSH Developer Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/yang-push-developer-guide.html
+++ /dev/null
-== YANG Tools
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/yang-tools.html
+++ /dev/null
-<project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
- <parent>
- <groupId>org.opendaylight.docs</groupId>
- <artifactId>root</artifactId>
- <version>0.4.0-SNAPSHOT</version>
- <relativePath>../pom.xml</relativePath>
- </parent>
- <modelVersion>4.0.0</modelVersion>
- <groupId>org.opendaylight.docs</groupId>
- <artifactId>manuals</artifactId>
- <version>0.4.0-SNAPSHOT</version>
- <name>OpenDaylight Docs - Manuals</name>
- <packaging>pom</packaging>
- <scm>
- <connection>scm:git:ssh://git.opendaylight.org:29418/docs.git</connection>
- <developerConnection>scm:git:ssh://git.opendaylight.org:29418/docs.git</developerConnection>
- <url>https://wiki.opendaylight.org/view/CrossProject:Documentation_Group</url>
- <tag>HEAD</tag>
- </scm>
- <properties>
- <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
- </properties>
- <modules>
- <module>readme</module> <!-- this is just to make sure readme builds -->
- <module>developer-guide</module>
- <module>user-guide</module>
- </modules>
-
-</project>
+++ /dev/null
-<project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
- <parent>
- <groupId>org.opendaylight.docs</groupId>
- <artifactId>manuals</artifactId>
- <version>0.4.0-SNAPSHOT</version>
- <relativePath>../pom.xml</relativePath>
- </parent>
- <modelVersion>4.0.0</modelVersion>
- <artifactId>readme</artifactId>
- <packaging>jar</packaging>
- <name>OpenDaylight Docs - Manuals - Readme</name>
- <properties>
- <!-- This is set by Jenkins according to the branch. -->
- <release.path.name>local</release.path.name>
- <comments.enabled>1</comments.enabled>
- <bookname>readme</bookname>
- </properties>
- <!-- ################################################ -->
- <!-- USE "mvn clean generate-sources" to run this POM -->
- <!-- ################################################ -->
- <build>
- <plugins>
- <plugin>
- <groupId>org.asciidoctor</groupId>
- <artifactId>asciidoctor-maven-plugin</artifactId>
- <version>${asciidoctor.version}</version>
- <executions>
- <execution>
- <id>output-docbook</id>
- <phase>generate-sources</phase>
- <goals>
- <goal>process-asciidoc</goal>
- </goals>
- <configuration>
- <backend>docbook5</backend>
- <doctype>book</doctype>
- </configuration>
- </execution>
- </executions>
- <configuration>
- <sourceDirectory>src/main/asciidoc</sourceDirectory>
- <sourceDocumentName>${bookname}.adoc</sourceDocumentName>
- <imagesDir>./images</imagesDir>
- </configuration>
- </plugin>
- <plugin>
- <artifactId>maven-resources-plugin</artifactId>
- <version>2.6</version>
- <executions>
- <execution>
- <id>copy-resources</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>copy-resources</goal>
- </goals>
- <configuration>
- <outputDirectory>${basedir}/target/generated-docs</outputDirectory>
- <resources>
- <resource>
- <directory>src/main/resources</directory>
- <includes>
- <include>**/*.*</include>
- </includes>
- </resource>
- </resources>
- </configuration>
- </execution>
- </executions>
- </plugin>
- <plugin>
- <groupId>com.inocybe.api</groupId>
- <artifactId>sdndocs-maven-plugin</artifactId>
- <version>0.1.0</version>
- <executions>
- <execution>
- <id>generate-webhelp</id>
- <goals>
- <goal>generate-webhelp</goal>
- </goals>
- <phase>compile</phase>
- <configuration>
- <profileAudience>enduser</profileAudience>
- <includes>target/generated-docs/${bookname}.xml</includes>
- <!-- <includes>bk-install-guide.xml</includes> -->
- <generateToc>
- appendix toc,title
- article/appendix nop
- article toc,title
- book toc,title,figure,table,example,equation
- chapter toc,title
- section toc
- part toc,title
- qandadiv toc
- qandaset toc
- reference toc,title
- set toc,title
- </generateToc>
- <webhelpDirname>${bookname}</webhelpDirname>
- <pdfFilenameBase>${bookname}</pdfFilenameBase>
- </configuration>
- </execution>
- </executions>
- <configuration>
- <profileAudience>enduser</profileAudience>
- <chapterAutolabel>1</chapterAutolabel>
- <sectionAutolabel>0</sectionAutolabel>
- <tocSectionDepth>1</tocSectionDepth>
- <formalProcedures>0</formalProcedures>
- <highlightSource>false</highlightSource>
- <xincludeSupported>true</xincludeSupported>
- <showXslMessages>true</showXslMessages>
- <sourceDirectory>.</sourceDirectory>
- <feedbackEmail>mlemay@inocybe.com</feedbackEmail>
- <branding>opendaylight</branding>
- <coverLogoLeft>2.6in</coverLogoLeft>
-<!-- <enableDisqus>${comments.enabled}</enableDisqus>
- <disqusShortname>os-user-guide</disqusShortname>
- <enableGoogleAnalytics>1</enableGoogleAnalytics>
- <googleAnalyticsId>UA-17511903-1</googleAnalyticsId>
- --> <suppressFooterNavigation>0</suppressFooterNavigation>
- <canonicalUrlBase>http://docs.opendaylight.org/user-guide/content/</canonicalUrlBase>
- <glossaryCollection>${basedir}/../glossary/glossary-terms.xml</glossaryCollection>
- </configuration>
- </plugin>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-site-plugin</artifactId>
- <version>3.1</version>
- <configuration>
- <inputDirectory>${project.build.directory}/docbkx/webhelp</inputDirectory>
- </configuration>
- <dependencies>
- <dependency>
- <groupId>org.apache.maven.wagon</groupId>
- <artifactId>wagon-webdav-jackrabbit</artifactId>
- <version>2.2</version>
- </dependency>
- <dependency>
- <groupId>org.slf4j</groupId>
- <artifactId>slf4j-api</artifactId>
- <version>1.6.1</version>
- </dependency>
- </dependencies>
- </plugin>
- </plugins>
- </build>
-</project>
+++ /dev/null
-
- <author>
- <personname>
- <firstname>OpenDaylight</firstname>
- <surname>Community</surname>
- </personname>
- <email>documentation@opendaylight.org</email>
- <affiliation>
- <orgname>Linux Foundation</orgname>
- </affiliation>
- </author>
- <copyright>
- <year>2015</year>
- <holder>Linux Foundation</holder>
- </copyright>
- <releaseinfo>Beryllium</releaseinfo>
- <productname>OpenDaylight</productname>
- <pubdate></pubdate>
- <legalnotice role="license">
- <para> This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at <link xlink:href="http://www.eclipse.org/legal/epl-v10.html"/></para>
- </legalnotice>
- <abstract>
- <para>This guide shows the various documentation templates for OpenDaylight.</para>
- </abstract>
- <revhistory>
- <revision>
- <date>2014-07-16</date>
- <revdescription>
- <itemizedlist spacing="compact">
- <listitem>
- <para>Initial Guide Creation</para>
- </listitem>
- </itemizedlist>
- </revdescription>
- </revision>
- </revhistory>
-
+++ /dev/null
-[[readme]]
-= OpenDaylight Documentation Readme
-:docinfo:
-
-[preface]
-== Overview
-This document is here to give example templates for OpenDaylight
-projects to create their own documentation. It is not intended to be
-part of the shipping OpenDaylight documentation.
-
-include::template_installation_guide.adoc[Installation Guide Template]
-
-include::template_user_guide.adoc[User Guide Template]
-
-include::template_developer_guide.adoc[Developer Guide Template]
-
-include::template_tutorial.adoc[Tutorial Template]
-
-include::template_release_notes.adoc[Release Notes Template]
+++ /dev/null
-== <Feature> Developer Guide
-
-=== Overview
-Provide an overview of the feature, what it logical functionality it
-provides and why you might use it as a developer. To be clear the target
-audience for this guide is a developer who will be _using_ the feature
-to build something separate, but _not_ somebody who will be developing
-code for this feature itself.
-
-NOTE: More so than with user guides, the guide may cover more than one
-feature. If that is the case, be sure to list all of the features this
-covers.
-
-=== <Feature> Architecture
-Provide information about feature components and how they work together.
-Also include information about how the feature integrates with
-OpenDaylight. An architecture diagram could help. This may be the same
-as the diagram used in the user guide, but it should likely be less
-abstract and provide more information that would be applicable to a
-developer.
-
-=== Key APIs and Interfaces
-Document the key things a user would want to use. For some features,
-there will only be one logical grouping of APIs. For others there may be
-more than one grouping.
-
-Assuming the API is MD-SAL- and YANG-based, the APIs will be available
-both via RESTCONF and via Java APIs. Giving a few examples using each is
-likely a good idea.
-
-==== API Group 1
-Provide a description of what the API does and some examples of how to
-use it.
-
-==== API Group 2
-Provide a description of what the API does and some examples of how to
-use it.
-
-=== API Reference Documentation
-Provide links to JavaDoc, REST API documentation, etc.
+++ /dev/null
-== <Feature> Installation Guide
-NOTE: *Only* use this template if installation is more complicated than
-simply installing a feature in the Karaf distribution. Otherwise simply
-provide the names of all user-facing features in your M3 readout.
-
-This is a template for installing a feature or a project developed in
-the ODL project. The *feature* could be interfaces, protocol plug-ins,
-or applications.
-
-=== Overview
-Add overview of the feature. Include Architecture diagram and the
-positioning of this feature in overall controller architecture.
-Highlighting the feature in a different color within the overall
-architecture must help. Include information to describe if the project
-is within ODL installation package or to be installed separately.
-
-=== Pre Requisites for Installing <Feature>
-* Hardware Requirements
-* Software Requirements
-
-=== Preparing for Installation
-Include any pre configuration, database, or other software downloads
-required to install <feature>.
-
-=== Installing <Feature>
-Include if you have separate procedures for Windows and Linux
-
-=== Verifying your Installation
-Describe how to verify the installation.
-
-==== Troubleshooting
-<optional>
-Text goes here.
-
-=== Post Installation Configuration
-Post Installation Configuration section must include some basic
-(must-do) procedures if any, to get started.
-
-Mandatory instructions to get started with the product.
-* Logging in
-* Getting Started
-* Integration points with controller
-
-=== Upgrading From a Previous Release
-Text goes here.
-
-=== Uninstalling <Feature>
-Text goes here.
+++ /dev/null
-== <Project Name> <Release Name> Release Notes
-For example, the title might be "OpenFlow Plugin Lithium Release Notes"
-
-Provide an overview about the high level feature. Explain the smaller
-features developed within the highlevel feature to provide a solution.
-For example,OpenFlow Support could contain sub features such as TLS
-support, Tables, Ports, Queue Configuration, and so on.
-
-=== Major Capabilities and Enhancements
-Provide information about the major capabilities this project provides
-in this release. Include those from previous release unless they have
-been deprecated or removed (see below).
-
-==== New Capabilities and Enhancements
-Call out the new capabilities and/or enhancements that are present in
-this release, but were not present in prior releases.
-
-==== Resolved Bugs
-List open and resolved bugs if any.
-
-=== Deprecated and Removed Capabilities
-Provide information about the capabilities that are removed or
-deprecated in this release.
-
-=== Known Limitations
-List any feature limitations that the user must be aware.
-
-==== Open Bugs
-List any remaining open bugs. Ideally provide a short description and a
-link to the entry in bugzilla.
-
-=== Compatibility with Previous Releases
-<optional, required if there's a previous release>
-
-Is it compatible? Did anything about how a user or developer would
-consume it change? If so, document it here.
-
-=== Migration from Previous Releases
-<optional, required if there's a previous release>
-
-Describe any special step somebody would have to take to migrate from a
-previous release to this one. If migration isn't supported for some
-combinations, state that as well.
+++ /dev/null
-== <Name of Tutorial> Tutorial
-NOTE: Tutorials here are assumed to be cross-project because otherwise they would be documented in the user guide for a given feature for the single project.
-
-If you are working on a cross-project tutorial, please reach out to the documentation team at documentation@lists.opendaylight.org and let us know so we can help.
-
-=== Overview
-Provide a general idea of what this will tell somebody how to do.
-
-=== Prerequisites
-
-.Before you begin ensure that:
-* Requirement one
-* Requirement two
-* Requirement three
-
-=== Target Environment
-Add overview information, topology, related information. This example has the following topology.
-
-=== Instructions
-Include steps here
-
-=== Verification
-Add verification of the how-to example if any
-
-==== Troubleshooting
-Provide guidance about common things that can go wrong and how to fix them.
+++ /dev/null
-== <Feature> User Guide
-Refer to this template to identify the required sections and information
-that you should provide for a User Guide. The user guide should contain
-configuration, administration, management, using, and troubleshooting
-sections for the feature.
-
-=== Overview
-Provide an overview of the feature and the use case. Also include the
-audience who will use the feature. For example, audience can be the
-network administrator, cloud administrator, network engineer, system
-administrators, and so on.
-
-=== <Feature> Architecture
-Provide information about feature components and how they work together.
-Also include information about how the feature integrates with
-OpenDaylight. An architecture diagram could help.
-
-=== Configuring <feature>
-
-Describe how to configure the feature or the project after installation.
-Configuration information could include day-one activities for a project
-such as configuring users, configuring clients/servers and so on.
-
-=== Administering or Managing <feature>
-Include related command reference or operations that you could perform
-using the feature. For example viewing network statistics, monitoring
-the network, generating reports, and so on.
-
-NOTE: Ensure that you create a step procedure whenever required and
-avoid concepts.
-
-For example:
-
-.To configure L2switch components perform the following steps.
-. Step 1:
-. Step 2:
-. Step 3:
-
-=== Tutorials
-<optional>
-If there is only one tutorial, you skip the "Tutorials" section and
-instead just lead with the single tutorial's name.
-
-==== <Tutorial Name>
-Ensure that the title starts with a gerund. For example using,
-monitoring, creating, and so on.
-
-===== Overview
-An overview of the use case.
-
-===== Prerequisites
-Provide any prerequisite information, assumed knowledge, or environment
-required to execute the use case.
-
-===== Target Environment
-Include any topology requirement for the use case. Ideally, provide
-visual (abstract) layout of network diagrams and any other useful visual
-aides.
-
-===== Instructions
-Use case could be a set of configuration procedures. Including
-screenshots to help demonstrate what is happening is especially useful.
-Ensure that you specify them separately. For example:
-
-. *Setting up the VM*
-To set up a VM perform the following steps.
-.. Step 1
-.. Step 2
-.. Step 3
-
-. *Installing the feature*
-To install the feature perform the following steps.
-.. Step 1
-.. Step 2
-.. Step 3
-
-. *Configuring the environment*
-To configure the system perform the following steps.
-.. Step 1
-.. Step 2
-.. Step 3
+++ /dev/null
-<project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
- <parent>
- <groupId>org.opendaylight.docs</groupId>
- <artifactId>manuals</artifactId>
- <version>0.4.0-SNAPSHOT</version>
- <relativePath>../pom.xml</relativePath>
- </parent>
- <modelVersion>4.0.0</modelVersion>
- <artifactId>userguide</artifactId>
- <packaging>jar</packaging>
- <name>OpenDaylight Docs - Manuals - User Guide</name>
- <properties>
- <!-- This is set by Jenkins according to the branch. -->
- <release.path.name>local</release.path.name>
- <comments.enabled>1</comments.enabled>
- <bookname>bk-user-guide</bookname>
- </properties>
- <!-- ################################################ -->
- <!-- USE "mvn clean generate-sources" to run this POM -->
- <!-- ################################################ -->
- <build>
- <plugins>
- <plugin>
- <groupId>org.asciidoctor</groupId>
- <artifactId>asciidoctor-maven-plugin</artifactId>
- <version>${asciidoctor.version}</version>
- <executions>
- <execution>
- <id>output-docbook</id>
- <phase>generate-sources</phase>
- <goals>
- <goal>process-asciidoc</goal>
- </goals>
- <configuration>
- <backend>docbook5</backend>
- <doctype>book</doctype>
- </configuration>
- </execution>
- </executions>
- <configuration>
- <sourceDirectory>src/main/asciidoc</sourceDirectory>
- <sourceDocumentName>${bookname}.adoc</sourceDocumentName>
- <imagesDir>./images</imagesDir>
- </configuration>
- </plugin>
- <plugin>
- <artifactId>maven-resources-plugin</artifactId>
- <version>2.6</version>
- <executions>
- <execution>
- <id>copy-resources</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>copy-resources</goal>
- </goals>
- <configuration>
- <outputDirectory>${basedir}/target/generated-docs</outputDirectory>
- <resources>
- <resource>
- <directory>src/main/resources</directory>
- <includes>
- <include>**/*.*</include>
- </includes>
- </resource>
- </resources>
- </configuration>
- </execution>
- </executions>
- </plugin>
- <plugin>
- <groupId>com.inocybe.api</groupId>
- <artifactId>sdndocs-maven-plugin</artifactId>
- <version>0.1.0</version>
- <executions>
- <execution>
- <id>generate-webhelp</id>
- <goals>
- <goal>generate-webhelp</goal>
- </goals>
- <phase>compile</phase>
- <configuration>
- <profileAudience>enduser</profileAudience>
- <includes>target/generated-docs/${bookname}.xml</includes>
- <!-- <includes>bk-install-guide.xml</includes> -->
- <generateToc>
- appendix toc,title
- article/appendix nop
- article toc,title
- book toc,title,figure,table,example,equation
- chapter toc,title
- section toc
- part toc,title
- qandadiv toc
- qandaset toc
- reference toc,title
- set toc,title
- </generateToc>
- <webhelpDirname>${bookname}</webhelpDirname>
- <pdfFilenameBase>${bookname}</pdfFilenameBase>
- </configuration>
- </execution>
- </executions>
- <configuration>
- <profileAudience>enduser</profileAudience>
- <chapterAutolabel>1</chapterAutolabel>
- <sectionAutolabel>0</sectionAutolabel>
- <tocSectionDepth>1</tocSectionDepth>
- <formalProcedures>0</formalProcedures>
- <highlightSource>false</highlightSource>
- <xincludeSupported>true</xincludeSupported>
- <showXslMessages>true</showXslMessages>
- <sourceDirectory>.</sourceDirectory>
- <feedbackEmail>mlemay@inocybe.com</feedbackEmail>
- <branding>opendaylight</branding>
- <coverLogoLeft>2.6in</coverLogoLeft>
-<!-- <enableDisqus>${comments.enabled}</enableDisqus>
- <disqusShortname>os-user-guide</disqusShortname>
- <enableGoogleAnalytics>1</enableGoogleAnalytics>
- <googleAnalyticsId>UA-17511903-1</googleAnalyticsId>
- --> <suppressFooterNavigation>0</suppressFooterNavigation>
- <canonicalUrlBase>http://docs.opendaylight.org/user-guide/content/</canonicalUrlBase>
- <glossaryCollection>${basedir}/../glossary/glossary-terms.xml</glossaryCollection>
- </configuration>
- </plugin>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-site-plugin</artifactId>
- <version>3.1</version>
- <configuration>
- <inputDirectory>${project.build.directory}/docbkx/webhelp</inputDirectory>
- </configuration>
- <dependencies>
- <dependency>
- <groupId>org.apache.maven.wagon</groupId>
- <artifactId>wagon-webdav-jackrabbit</artifactId>
- <version>2.2</version>
- </dependency>
- <dependency>
- <groupId>org.slf4j</groupId>
- <artifactId>slf4j-api</artifactId>
- <version>1.6.1</version>
- </dependency>
- </dependencies>
- </plugin>
- </plugins>
- </build>
-</project>
+++ /dev/null
-== Authentication, Authorization and Accounting (AAA) Services
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/authentication-and-authorization-services.html
+++ /dev/null
-== ALTO User Guide ==
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/alto-user-guide.html
+++ /dev/null
-{
- "alto-service:network-map": [
- {
- "alto-service:map": [
- {
- "alto-service:endpoint-address-group": [
- {
- "alto-service:address-type": "ipv4",
- "alto-service:endpoint-prefix": [
- "192.0.2.0/24",
- "198.51.100.0/25"
- ]
- }
- ],
- "alto-service:pid": "PID1"
- },
- {
- "alto-service:endpoint-address-group": [
- {
- "alto-service:address-type": "ipv4",
- "alto-service:endpoint-prefix": [
- "198.51.100.128/25"
- ]
- }
- ],
- "alto-service:pid": "PID2"
- },
- {
- "alto-service:endpoint-address-group": [
- {
- "alto-service:address-type": "ipv4",
- "alto-service:endpoint-prefix": [
- "0.0.0.0/0"
- ]
- },
- {
- "alto-service:address-type": "ipv6",
- "alto-service:endpoint-prefix": [
- "::/0"
- ]
- }
- ],
- "alto-service:pid": "PID3"
- }
- ],
- "alto-service:resource-id": "test_odl",
- "alto-service:tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
- }
- ]
-}
+++ /dev/null
-{
- "meta" : {
- "resource-id": "test_odl",
- "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
- },
- "network-map" : {
- "PID1" : {
- "ipv4": [
- "192.0.2.0/24",
- "192.51.100.0/25"
- ]
- },
- "PID2": {
- "ipv4": [
- "192.51.100.128/25"
- ]
- },
- "PID3": {
- "ipv4": [
- "0.0.0.0/0"
- ],
- "ipv6": [
- "::/0"
- ]
- }
- }
-}
+++ /dev/null
-== Atrium User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/atrium-user-guide.html
+++ /dev/null
-== BGP User Guide ==
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/bgp-user-guide.html
+++ /dev/null
-== BGP Monitoring Protocol User Guide ==
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/bgp-monitoring-protocol-user-guide.html
+++ /dev/null
-== PCEP User Guide ==
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/pcep-user-guide.html
+++ /dev/null
-
- <author>
- <personname>
- <firstname>OpenDaylight</firstname>
- <surname>Community</surname>
- </personname>
- <email>documentation@opendaylight.org</email>
- <affiliation>
- <orgname>Linux Foundation</orgname>
- </affiliation>
- </author>
- <copyright>
- <year>2016</year>
- <holder>Linux Foundation</holder>
- </copyright>
- <releaseinfo>Boron</releaseinfo>
- <productname>OpenDaylight</productname>
- <pubdate></pubdate>
- <legalnotice role="license">
- <para> This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at <link xlink:href="http://www.eclipse.org/legal/epl-v10.html"/></para>
- </legalnotice>
- <abstract>
- <para>This guide describes how to use and deploy OpenDaylight.</para>
- </abstract>
- <revhistory>
- <revision>
- <date>2014-07-16</date>
- <revdescription>
- <itemizedlist spacing="compact">
- <listitem>
- <para>Initial Guide Creation</para>
- </listitem>
- </itemizedlist>
- </revdescription>
- </revision>
- </revhistory>
-
+++ /dev/null
-[[bk-user-guide]]
-= OpenDaylight User Guide
-:docinfo:
-
-/////
-[preface]
-include::core-release-notes.adoc[OpenDaylight Release Notes]
-/////
-
-A significant amount of this guide has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/index.html
-
-Please look there as well as here for any content.
-
-= Applications and Plugins
-
-include::alto/alto-user-guide.adoc[ALTO]
-
-include::aaa/aaa.adoc[AAA]
-
-include::atrium/odl-atrium-all-user.adoc[Atrium]
-
-include::bgpcep/odl-bgpcep-bgp-all-user.adoc[BGP]
-
-include::bgpcep/odl-bgpcep-bmp-user.adoc[BMP]
-
-include::capwap/capwap-user.adoc[CAPWAP]
-
-include::cardinal/odl-cardinal-user.adoc[]
-
-include::centinel/centinel-user-guide.adoc[]
-
-include::didm/didm-user.adoc[]
-
-include::faas/odl-faas-user.adoc[]
-
-include::groupbasedpolicy/odl-groupbasedpolicy-user-guide.adoc[]
-
-include::l2switch/l2switch-user.adoc[]
-
-include::vpnservice/vpnservice-user.adoc[VPN Service]
-
-include::lacp/lacp-user.adoc[LACP]
-
-include::lfm/lispflowmapping-msmr-user.adoc[LISP flow mapping]
-
-include::natapp/odl-natapp-user.adoc[NATAPP]
-
-include::nemo/odl-nemo-engine-user.adoc[NEMO]
-
-include::controller/netconf/odl-netconf-user.adoc[]
-
-include::netide/odl-netide-user-guide.adoc[NetIDE]
-
-include::neutron/odl-neutron-service-user.adoc[]
-
-include::nic/nic-user.adoc[NIC]
-
-include::ocpplugin/ocp-user-guide.adoc[OCP]
-
-include::sdninterfaceapp/odl-sdninterfaceapp-all-user.adoc[ODL-SDNi]
-
-include::of-config/ofconfig-user.adoc[OF-CONFIG]
-
-include::openflowplugin/odl-ofp-user-guide.adoc[OpenFlow Plugin]
-
-include::opflex/agent-ovs-user.adoc[]
-
-include::ovsdb/odl-ovsdb-netvirt-user-guide.adoc[]
-
-include::bgpcep/odl-bgpcep-pcep-all-user.adoc[PCEP]
-
-include::packetcable/packetcable-user.adoc[PacketCable PCMM - CMTS Management]
-
-include::sfc/sfc.adoc[Service Function Chain]
-
-include::snbi/odl-snbi-user.adoc[]
-
-include::snmp/snmp-user-guide.adoc[SNMP]
-
-include::snmp4sdn/snmp4sdn-user-guide.adoc[SNMP4SDN]
-
-include::sxp/odl-sxp-user.adoc[]
-
-include::tsdr/tsdr-user-guide.adoc[]
-
-include::ttp/ttp-cli-tools-user.adoc[TTP]
-
-include::unimgr/unimgr-user.adoc[]
-
-include::usecplugin/odl-usecplugin-aaa-user.adoc[USECPLUGIN-AAA]
-
-include::usecplugin/odl-usecplugin-openflow-user.adoc[USECPLUGIN-OPENFLOW]
-
-include::usc/odl-usc-channel-user.adoc[USC]
-
-include::vtn/vtn-user.adoc[]
-
-include::yangide/yangide-user.adoc[]
-
-include::yang-push/odl-yang-push-user.adoc[YANG-PUSH]
-
-include::genius/genius-user-guide.adoc[Genius]
+++ /dev/null
-[[bk-user-guide]]
-= OpenDaylight User Guide
-:docinfo:
-
-/////
-[preface]
-include::core-release-notes.adoc[OpenDaylight Release Notes]
-/////
-
-= Getting Started with OpenDaylight
-
-[partintro]
-
-This first part of the user guide covers the basic user operations of the OpenDaylight Release using the generic base functionality.
-
-include::ch-introduction.adoc[OpenDaylight Controller Overview]
-
-include::ch-dlux-userguide.adoc[Using the OpenDaylight User Interface (DLUX)]
-
-include::ch-xsql-commands.adoc[Running XSQL Console Commands and Queries]
-
-include::ch-clustering.adoc[Setting Up Clustering on an OpenDaylight Controller]
-
-= Applications and Plugins
-
-[partintro]
-
-This second part of the user guide covers project specific usage instructions.
-
-include::alto/alto-user-guide.adoc[ALTO]
-
-include::aaa/aaa.adoc[AAA]
-
-include::bgpcep/odl-bgpcep-bgp-all-user.adoc[BGP]
-
-include::capwap/capwap-user.adoc[CAPWAP]
-
-include::didm/didm-user.adoc[]
-
-include::groupbasedpolicy/odl-groupbasedpolicy-user-guide.adoc[]
-
-include::l2switch/l2switch-user.adoc[]
-
-include::vpnservice/vpnservice-user.adoc[VPN Service]
-
-include::lacp/lacp-user.adoc[LACP]
-
-include::lfm/lispflowmapping-all-user.adoc[LISP flow mapping]
-
-include::nic/nic-user.adoc[NIC]
-
-include::sdninterfaceapp/odl-sdninterfaceapp-all-user.adoc[ODL-SDNi]
-
-include::opflex/agent-ovs-user.adoc[]
-
-include::bgpcep/odl-bgpcep-pcep-all-user.adoc[PCEP]
-
-include::packetcable/packetcable-user.adoc[PacketCable PCMM - CMTS Management]
-
-include::sfc/sfc.adoc[Service Function Chain]
-
-include::snmp/snmp-user-guide.adoc[SNMP]
-
-include::sxp/odl-sxp-user.adoc[]
-
-include::tcpmd5/odl-tcpmd5-all-user.adoc[TCP-MD5]
-
-include::tsdr/tsdr-h2-user.adoc[]
-
-include::tsdr/tsdr-hbase-user.adoc[]
-
-include::ttp/ttp-cli-tools-user.adoc[TTP]
-
-include::usc/odl-usc-channel-user.adoc[USC]
-
-<<<<<<< HEAD
-include::vtn/vtn-user.adoc[]
-=======
-include::sxp/odl-sxp-user.adoc[]
-
-include::controller/netconf/odl-netconf-user.adoc[]
->>>>>>> Introduce user-guide for netconf
+++ /dev/null
-== CAPWAP User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/capwap-user-guide.html
+++ /dev/null
-== Cardinal: OpenDaylight Monitoring as a Service
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/cardinal_-opendaylight-monitoring-as-a-service.html
+++ /dev/null
-== Centinel User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/centinel-user-guide.html
+++ /dev/null
-[[_southbound_netconf_connector]]
-== NETCONF User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/netconf-user-guide.html
+++ /dev/null
-== DIDM User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/didm-user-guide.html
+++ /dev/null
-== Fabric As A Service
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/fabric-as-a-service.html
+++ /dev/null
-== Genius User Guide ==
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/genius-user-guide.html
+++ /dev/null
-== Group Based Policy User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/group-based-policy-user-guide.html
+++ /dev/null
-== L2Switch User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/l2switch-user-guide.html
+++ /dev/null
-== Link Aggregation Control Protocol User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/link-aggregation-control-protocol-user-guide.html
+++ /dev/null
-== LISP Flow Mapping User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/lisp-flow-mapping-user-guide.html
+++ /dev/null
-== NATApp User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/natapp-user-guide.html
+++ /dev/null
-== NetIDE User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/netide-user-guide.html
+++ /dev/null
-== Neutron Service User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/neutron-service-user-guide.html
+++ /dev/null
-== Network Intent Composition (NIC) User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/network-intent-composition-(nic)-user-guide.html
+++ /dev/null
-== OCP Plugin User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/ocp-plugin-user-guide.html
+++ /dev/null
-== OF-CONFIG User Guide ==
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/of-config-user-guide.html
+++ /dev/null
-== OpenFlow Plugin Project User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/openflow-plugin-project-user-guide.html
+++ /dev/null
-== OpFlex agent-ovs User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/opflex-agend-ovs-user-guide.html
+++ /dev/null
-== OVSDB NetVirt
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/ovsdb-netvirt.html
+++ /dev/null
-== PacketCable User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/packetcable-user-guide.html
+++ /dev/null
-== ODL-SDNi User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/odl-sdni-user-guide.html
+++ /dev/null
-== Service Function Chaining
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/service-function-chaining.html
+++ /dev/null
-== SNBI User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/snbi-user-guide.html
+++ /dev/null
-== SNMP Plugin User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/snmp-plugin-user-guide.html
+++ /dev/null
-== SNMP4SDN User Guide\r
-\r
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/snmp4sdn-user-guide.html\r
+++ /dev/null
-== SXP User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/sxp-user-guide.html
+++ /dev/null
-== TSDR User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/tsdr-user-guide.html
+++ /dev/null
-== TTP CLI Tools User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/ttp-cli-tools-user-guide.html
+++ /dev/null
-== UNI Manager Plug In Project
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/uni-manager-plug-in-project.html
+++ /dev/null
-== Unified Secure Channel
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/unified-secure-channel.html
+++ /dev/null
-== Usecplugin-AAA User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/usecplugin-aaa-user-guide.html
+++ /dev/null
-== Usecplugin-OpenFlow User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/usecplugin-openflow-user-guide.html
+++ /dev/null
-== L3VPN Service: User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/l3vpn-service_-user-guide.html
+++ /dev/null
-== Virtual Tenant Network (VTN)
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/virtual-tenant-network-(vtn).html
+++ /dev/null
-== YANG-PUSH
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/yang-push.html
+++ /dev/null
-== YANG IDE User Guide
-
-This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/yang-ide-user-guide.html
+++ /dev/null
-<project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
- <modelVersion>4.0.0</modelVersion>
- <groupId>org.opendaylight.docs</groupId>
- <artifactId>root</artifactId>
- <version>0.4.0-SNAPSHOT</version>
- <name>docs</name> <!-- Used by Sonar to set project name -->
- <packaging>pom</packaging>
- <url>${sitedeploy}</url>
- <scm>
- <connection>scm:git:ssh://git.opendaylight.org:29418/docs.git</connection>
- <developerConnection>scm:git:ssh://git.opendaylight.org:29418/docs.git</developerConnection>
- <url>https://wiki.opendaylight.org/view/CrossProject:Documentation_Group</url>
- <tag>HEAD</tag>
- </scm>
- <properties>
- <asciidoctor.version>0.1.4</asciidoctor.version>
- <current.branch>master</current.branch>
- <nexusproxy>https://nexus.opendaylight.org/content</nexusproxy>
- <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
- <sitedeploy>${nexusproxy}/sites/site/${project.groupId}/${current.branch}/${project.artifactId}</sitedeploy>
- </properties>
- <modules>
- <module>manuals</module>
- </modules>
-
- <distributionManagement>
- <!-- OpenDayLight Released artifact -->
- <repository>
- <id>opendaylight-release</id>
- <url>${nexusproxy}/repositories/opendaylight.release/</url>
- </repository>
- <!-- OpenDayLight Snapshot artifact -->
- <snapshotRepository>
- <id>opendaylight-snapshot</id>
- <url>${nexusproxy}/repositories/opendaylight.snapshot/</url>
- </snapshotRepository>
- <site>
- <id>opendaylight-site</id>
- <url>dav:${sitedeploy}/</url>
- </site>
- </distributionManagement>
- <build>
- <plugins>
- <plugin>
- <groupId>com.inocybe.api</groupId>
- <artifactId>sdndocs-maven-plugin</artifactId>
- <version>0.1.0</version>
- </plugin>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-site-plugin</artifactId>
- <version>3.1</version>
- <dependencies>
- <dependency>
- <groupId>org.apache.maven.wagon</groupId>
- <artifactId>wagon-webdav-jackrabbit</artifactId>
- <version>2.2</version>
- </dependency>
- <dependency>
- <groupId>org.slf4j</groupId>
- <artifactId>slf4j-api</artifactId>
- <version>1.6.1</version>
- </dependency>
- </dependencies>
- </plugin>
- </plugins>
- </build>
-</project>
-sphinx==1.4.4
+sphinx>=1.4.8
sphinx_bootstrap_theme>=0.4.11
robotframework
Code Review / docs.git / commitdiff
