controller
didm-developer-guide
dlux
+ infrautils-developer-guide
iotdm-developer-guide
l2switch-developer-guide
lacp-developer-guide
+ ../user-guide/lisp-flow-mapping-user-guide
+ nemo-developer-guide
netconf-developer-guide
network-intent-composition-(nic)-developer-guide
netide-developer-guide
--- /dev/null
+Infrautils
+==========
+
+Overview
+--------
+
+Infrautils offer various utilities and infrastructures for other projects to use:
+
+Counters Infrastructure
+-----------------------
+Create, update and output counters is a basic tool for debugging and generating statistics in any system.
+We have developed a counter infrastructure integrated into ODL which has already been successfully used with
+multiple products, and more recently in debugging and fixing the OpenFlow plugin/Java and LACP modules.
+`Getting started with Counters <https://wiki.opendaylight.org/view/Getting_started_with_Counters>`__
+
+Async Infrastructure
+-----------------------
+The decision to split a service into one or more threads with asynchronous interactions between them is
+frequently dependent on constraints learned late in the development and even the deployment cycle.
+In order to allow flexibility in making these decisions we have developed an infrastructure which is
+configuration driven allowing agnostic code to be written under generic constrains which can then later
+be customized according to the required constraints.
+`Getting started with Async <https://git.opendaylight.org/gerrit/gitweb?p=infrautils.git;a=tree;f=samples/sample-async;h=dedd664da4a1bcfbe62261df73d19044d334f0b9;hb=refs/heads/master>`__
+
--- /dev/null
+NEtwork MOdeling (NEMO)
+=======================
+
+Overview
+--------
+
+The NEMO engine provides REST APIs to express intent, and manage it. With this
+northbound API, user could query what intents have been handled successfully, and
+what types have been predefined.
+
+NEMO Architecture
+-----------------
+
+In NEMO project, it provides three features facing developer.
+
+* ``odl-nemo-engine``: it is a whole model to handle intent.
+
+* ``odl-nemo-openflow-renderer``: it is a southbound render to translate intent to flow
+ table in devices supporting for OpenFlow protocol.
+
+* ``odl-nemo-cli-render``: it is also a southbound render to translate intent into forwarding
+ table in devices supporting for traditional protocol.
+
+Key APIs and Interfaces
+-----------------------
+
+NEMO projects provide four basic REST methods for user to use.
+
+* PUT: store the information expressed in NEMO model directly without handled by NEMO engine.
+
+* POST: the information expressed in NEMO model will be handled by NEMO engine, and will
+ be translated into southbound configuration.
+
+* GET: obtain the data stored in data store.
+
+* DELETE: delete the data in data store.
+
+NEMO Intent API
+~~~~~~~~~~~~~~~
+
+NEMO provides several RPCs to handle user's intent. All RPCs use POST method.
+
+- ``http://{controller-ip}:8181/restconf/operations/nemo-intent:register-user``: a REST API
+ to register a new user. It is the first and necessary step to express intent.
+
+- ``http://{controller-ip}:8181/restconf/operations/nemo-intent:transaction-begin``: a REST
+ type to start a transaction. The intent exist in the transaction will be handled together.
+
+- ``http://{controller-ip}:8181/restconf/operations/nemo-intent:transaction-end``: a REST API
+ to end a transaction. The intent exist in the transaction will be handled together.
+
+- ``http://{controller-ip}:8181/restconf/operations/nemo-intent:structure-style-nemo-update``: a
+ REST API to create, import or update intent in a structure style, that is, user could express the
+ structure of intent in json body.
+
+- ``http://{controller-ip}:8181/restconf/operations/nemo-intent:structure-style-nemo-delete``: a
+ REST API to delete intent in a structure style.
+
+- ``http://{controller-ip}:8181/restconf/operations/nemo-intent:language-style-nemo-request``: a REST
+ API to create, import, update and delete intent in a language style, that is, user could express
+ intent with NEMO script. On the other hand, with this interface, user could query which intent have
+ been handled successfully.
+
+API Reference Documentation
+---------------------------
+
+Go to ``http://${IPADDRESS}:8181/apidoc/explorer/index.html``. User could see many useful APIs to
+deploy or query intent.
+
Testing
~~~~~~~
-If you want to test our implementation you must apply `this
-patch <https://git.opendaylight.org/gerrit/#/c/26612>`__. It adds an
-OpenFlow Plugin dependency so we can use it in the Karaf distribution as
-a feature. After adding patch and building the whole framework, you can
-start Karaf. Next, you have to install necessary features. In our case
-it is:
+If you want to test topoprocessing with some manually created underlay
+topologies (like in this guide), than you have to tell Topoprocessing
+to listen for underlay topologies on Configuration datastore
+instead of Operational.
-``feature:install odl-restconf-noauth odl-topoprocessing-inventory-rendering odl-openflowplugin-southbound odl-openflowplugin-nsf-model``
+| You can do this in this config file
+| ``<topoprocessing_directory>/topoprocessing-config/src/main/resources/80-topoprocessing-config.xml``.
+| Here you have to change
+| ``<datastore-type>OPERATIONAL</datastore-type>``
+| to
+| ``<datastore-type>CONFIGURATION</datastore-type>``.
+
+
+Also you have to add dependency required to test "inventory" topologies.
+
+| In ``<topoprocessing_directory>/features/pom.xml``
+| add ``<openflowplugin.version>latest_snapshot</openflowplugin.version>``
+ to properties section
+| and add this dependency to dependencies section
+
+.. code:: xml
+
+ <dependency>
+ <groupId>org.opendaylight.openflowplugin</groupId>
+ <artifactId>features-openflowplugin</artifactId>
+ <version>${openflowplugin.version}</version>
+ <classifier>features</classifier><type>xml</type>
+ </dependency>
+
+``latest_snapshot`` in ``<openflowplugin.version>`` replace with latest snapshot, which can be found `here <https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/openflowplugin/openflowplugin/>`__.
+
+| And in ``<topoprocessing_directory>/features/src/main/resources/features.xml``
+| add ``<repository>mvn:org.opendaylight.openflowplugin/features-openflowplugin/${openflowplugin.version}/xml/features</repository>``
+ to repositories section.
+
+Now after you rebuild project and start Karaf, you can install necessary features.
+
+| You can install all with one command:
+| ``feature:install odl-restconf-noauth odl-topoprocessing-inventory-rendering odl-openflowplugin-southbound odl-openflowplugin-nsf-model``
Now you can send messages to REST from any REST client (e.g. Postman in
Chrome). Messages have to have following headers:
</topology>
</network-topology>
+Use Cases
+---------
+
+You can find use case examples on `this wiki page
+<https://wiki.opendaylight.org/view/Topology_Processing_Framework:Developer_Guide:Use_Case_Tutorial>`__.
+
Key APIs and Interfaces
-----------------------
---------------------------
You can find API examples on `this wiki
-page <https://wiki.opendaylight.org/view/Topology_Processing_Framework:Developer_Guide:End_to_End_Example>`__.
+page <https://wiki.opendaylight.org/view/Topology_Processing_Framework:Developer_Guide:REST_API_Specification>`__.
-Subproject commit c089871739de52fbf824667f68f4384cb541c3d0
+Subproject commit 70361ef13a1f794bcfd81505837de8decc2829e3
-Subproject commit b28444e372162528d42d86363918bfcf49d00058
+Subproject commit ea39ae2c0e86efa9e42b5244cdf0ab0e69208a01
-Subproject commit b96110b4b08355cd2440555d99f53135293956ea
+Subproject commit 88568040740d8598f048991a082c66fc30a3a763
--- /dev/null
+ALTO User Guide
+===============
+
+Overview
+--------
+
+The ALTO project is aimed to provide support for **Application Layer
+Traffic Optimization** services defined in `RFC
+7285 <https://tools.ietf.org/html/rfc7285>`__ in OpenDaylight.
+
+This user guide will introduce the three basic services (namely
+``simple-ird``, ``manual-maps`` and ``host-tracker``) which are
+implemented since the Beryllium release, and give instructions on how to
+configure them to provide corresponding ALTO services.
+
+A new feature named ``simple-pce`` (**Simple Path Computation Engine**)
+is added into Boron release as an ALTO extension service.
+
+How to Identify ALTO Resources
+------------------------------
+
+Each ALTO resource can be uniquely identified by a tuple . For each
+resource, a *version-tag* is used to support historical look-ups.
+
+The formats of *resource-id* and *version-tag* are defined in `section
+10.2 <https://tools.ietf.org/html/rfc7285#section-10.2>`__ and `section
+10.3 <https://tools.ietf.org/html/rfc7285#section-10.3>`__ respectively.
+The *context-id* is not part of the protocol and we choose the same
+format as a *universal unique identifier* (UUID) which is defined in
+`RFC 4122 <http://tools.ietf.org/html/rfc4122>`__.
+
+A context is like a namespace for ALTO resources, which eliminates
+*resource-id* collisions. For simplicity, we also provide a default
+context with the id **000000000000-0000-0000-0000-00000000**.
+
+How to Use Simple IRD
+---------------------
+
+The simple IRD feature provides a simple *information resource
+directory* (IRD) service defined in `RFC
+7285 <https://tools.ietf.org/html/rfc7285#section-9>`__.
+
+Install the Feature
+~~~~~~~~~~~~~~~~~~~
+
+To enable simple IRD, run the following command in the karaf CLI:
+
+.. code:: bash
+
+ karaf > feature:install odl-alto-simpleird
+
+After the feature is successfully installed, a special context will be
+created for all simple IRD resources. The id for this context can be
+seen by executing the following command in a terminal:
+
+.. code:: bash
+
+ curl -X GET -u admin:admin http://localhost:8181/restconf/operational/alto-simple-ird:information/
+
+Create a new IRD
+~~~~~~~~~~~~~~~~
+
+To create a new IRD resource, two fields MUST be provided:
+
+- Field **instance-id**: the *resource-id* of the IRD resource;
+
+- Field **entry-context**: the context-id for non-IRD entries managed
+ by this IRD resource.
+
+Using the following script, one can create an empty IRD resource:
+
+.. code:: bash
+
+ #!/bin/bash
+ # filename: ird-create
+ INSTANCE_ID=$1
+ if [ $2 ]; then
+ CONTEXT_ID=$2
+ else
+ CONTEXT_ID="00000000-0000-0000-0000-000000000000"
+ fi
+ URL="`http://localhost:8181/restconf/config/alto-simple-ird:ird-instance-configuration/"$INSTANCE_ID"/[`http://localhost:8181/restconf/config/alto-simple-ird:ird-instance-configuration/"$INSTANCE_ID"/`]`"
+ DATA=$(cat template \
+ | sed 's/\$1/'$CONTEXT_ID'/g' \
+ | sed 's/\$2/'$INSTANCE_ID'/g')
+ curl -4 -D - -X PUT -u admin:admin \
+ -H "Content-Type: application/json" -d "$(echo $DATA)"\
+ $URL
+
+For example, the following command will create a new IRD named *ird*
+which can accept entries with the default context-id:
+
+.. code:: bash
+
+ $ ./ird-create ird 000000000000-0000-0000-0000-00000000
+
+And below is the what the template file looks like:
+
+.. code:: json
+
+ {
+ "ird-instance-configuration": {
+ "entry-context": "/alto-resourcepool:context[alto-resourcepool:context-id='$1']",
+ "instance-id": "$2"
+ }
+ }
+
+Remove an IRD
+~~~~~~~~~~~~~
+
+To remove an existing IRD (and all the entries in it), one can use the
+following command in a terminal:
+
+.. code:: bash
+
+ curl -X DELETE -u admin:admin http://localhost:8181/restconf/config/alto-simple-ird:ird-instance-configuration/$INSTANCE_ID
+
+Add a new entry
+~~~~~~~~~~~~~~~
+
+There are several ways to add entries to an IRD and in this section we
+introduce only the simplest method. Using the following script, one can
+add a new entry to the target IRD.
+
+For each new entry, four parameters MUST be provided:
+
+- Parameter *ird-id*: the *resource-id* of the target IRD;
+
+- Parameter *entry-id*: the *resource-id* of the ALTO service to be
+ added;
+
+- Parameter *context-id*: the *context-id* of the ALTO service to be
+ added, which MUST be identical to the target IRD’s *entry-context*;
+
+- Parameter *location*: either a URI or a relative path to the ALTO
+ service.
+
+The following script can be used to add one entry to the target IRD,
+where the relative path is used:
+
+.. code:: bash
+
+ #!/bin/bash
+ # filename: ird-add-entry
+ IRD_ID=$1
+ ENTRY_ID=$2
+ CONTEXT_ID=$3
+ BASE_URL=$4
+ URL="`http://localhost:8181/restconf/config/alto-simple-ird:ird-instance-configuration/"$IRD_ID"/ird-configuration-entry/"$ENTRY_ID"/"
+ DATA=$(cat template \
+ | sed 's/\$1/'$ENTRY_ID'/g' \
+ | sed 's/\$2/'$CONTEXT_ID'/g' \
+ | sed 's/\$3/'$BASE_URL'/g' )
+ curl -4 -D - -X PUT -u admin:admin \
+ -H "Content-Type: application/json" -d "$(echo $DATA)" \
+ $URL
+
+For example, the following command will add a new resource named
+*networkmap*, whose context-id is the default context-id and the base
+URL is /alto/networkmap, to the IRD named *ird*:
+
+.. code:: bash
+
+ $ ./ird-add-entry ird networkmap 000000000000-0000-0000-0000-00000000 /alto/networkmap
+
+And below is the template file:
+
+.. code:: json
+
+ {
+ "ird-configuration-entry": {
+ "entry-id": "$1",
+ "instance": "/alto-resourcepool:context[alto-resourcepool:context-id='$2']/alto-resourcepool:resource[alto-resourcepool:resource-id='$1']",
+ "path": "$3/$1"
+ }
+ }
+
+Remove an entry
+~~~~~~~~~~~~~~~
+
+To remove an entry from an IRD, one can use the following one-line
+command:
+
+.. code:: bash
+
+ curl -X DELETE -u admin:admin http://localhost:8181/restconf/config/alto-simple-ird:ird-instance-configuration/$IRD_ID/ird-configuration-entry/$ENTRY_ID/
+
+How to Use Host-tracker-based ECS
+---------------------------------
+
+As a real instance of ALTO services, ***alto-hosttracker*** reads data
+from ***l2switch*** and generates a network map with resource id
+***hosttracker-network-map*** and a cost map with resource id
+***hostracker-cost-map***. It can only work with OpenFlow-enabled
+networks.
+
+After installing the ***odl-alto-hosttracker*** feature, the
+corresponding network map and cost map will be inserted into the data
+store.
+
+Managing Resource with ``alto-resourcepool``
+--------------------------------------------
+
+After installing ``odl-alto-release`` feature in Karaf,
+``alto-resourcepool`` feature will be installed automatically. And you
+can manage all resources in ALTO via RESTCONF APIs provided by
+``alto-resourcepool``.
+
+With the example bash script below you can get any resource infomation
+in a given context.
+
+.. code:: bash
+
+ #!/bin/bash
+ RESOURCE_ID=$1
+ if [ $2 ] ; then
+ CONTEXT_ID=$2
+ else
+ CONTEXT_ID="00000000-0000-0000-0000-000000000000"
+ fi
+ URL="http://localhost:8181/restconf/operational/alto-resourcepool:context/"$CONTEXT_ID"/alto-resourcepool:resource/"$RESOURCE_ID
+ curl -X GET -u admin:admin $URL | python -m json.tool | sed -n '/default-tag/p' | sed 's/.*:.*\"\(.*\)\".*/\1/g'
+
+Manual Configuration
+--------------------
+
+Using RESTCONF API
+~~~~~~~~~~~~~~~~~~
+
+After installing ``odl-alto-release`` feature in Karaf, it is possible
+to manage network-maps and cost-maps using RESTCONF. Take a look at all
+the operations provided by ``resource-config`` at the API service page
+which can be found at
+``http://localhost:8181/apidoc/explorer/index.html``.
+
+The easiest method to operate network-maps and cost-maps is to modify
+data broker via RESTCONF API directly.
+
+Using RPC
+~~~~~~~~~
+
+The ``resource-config`` package also provides a query RPC to config the
+resources. You can CREATE, UPDATE and DELETE **network-maps** and
+**cost-maps** via query RPC.
+
+Simple Path Computation Engine
+------------------------------
+
+The ``simple-pce`` module provides a simple path computation engine for
+ALTO and other projects. It supports basic CRUD (create, read, update,
+delete) operations to manage L2 and L3 routing with/without rate
+limitation. This module is an independent feature, so you can follow the
+instruction below to install it independently.
+
+.. code:: bash
+
+ karaf > feature:install odl-alto-extenstion
+
+.. note::
+
+ The rate limitation meter requires OpenFlow 1.3 support.
+
+Basic Usage with RESTCONF API
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can use the simple path computation engine with RESTCONF API, which
+is defined in the YANG model
+`here <https://git.opendaylight.org/gerrit/gitweb?p=alto.git;a=blob;f=alto-extensions/simple-pce/api/src/main/yang/alto-spce.yang;h=f5bbe6744f7dfba493edd275aa18114e363727ab;hb=refs/heads/stable/boron>`__.
+
+Use Case
+--------
+
+Server Selection
+~~~~~~~~~~~~~~~~
+
+One of the key use case for ALTO is server selection. For example, a
+client (with IP address 10.0.0.1) sends a data transferring request to
+Data Transferring Service (DTS). And there are three data replica
+servers (with IP address 10.60.0.1, 10.60.0.2 and 10.60.0.3) which can
+response the request. In this case, DTS can send a query request to ALTO
+server to make server selection decision.
+
+Following is an example ALTO query:
+
+::
+
+ POST /alto/endpointcost HTTP/1.1
+ Host: localhost:8080
+ Content-Type: application/alto-endpointcostparams+json
+ Accept: application/alto-endpointcost+json,application/alto-error+json
+ {
+ "cost-type": {
+ "cost-mode": "ordinal",
+ "cost-metric": "hopcount"
+ },
+ "endpoints": {
+ "srcs": [ "ipv4:10.0.0.1" ],
+ "dsts": [
+ "ipv4:10.60.0.1",
+ "ipv4:10.60.0.2",
+ "ipv4:10.60.0.3"
+ ]
+ }
+ }
+
--- /dev/null
+Authentication, Authorization and Accounting (AAA) Services
+===========================================================
+
+The Boron AAA services are based on the Apache Shiro Java Security
+Framework. The main configuration file for AAA is located at
+“etc/shiro.ini” relative to the ODL karaf home directory.
+
+Terms And Definitions
+---------------------
+
+Token
+ A claim of access to a group of resources on the controller
+
+Domain
+ A group of resources, direct or indirect, physical, logical, or
+ virtual, for the purpose of access control. ODL recommends using the
+ default “sdn" domain in the Boron release.
+
+User
+ A person who either owns or has access to a resource or group of
+ resources on the controller
+
+Role
+ Opaque representation of a set of permissions, which is merely a
+ unique string as admin or guest
+
+Credential
+ Proof of identity such as username and password, OTP, biometrics, or
+ others
+
+Client
+ A service or application that requires access to the controller
+
+Claim
+ A data set of validated assertions regarding a user, e.g. the role,
+ domain, name, etc.
+
+How to enable AAA
+-----------------
+
+AAA is enabled through installing the odl-aaa-shiro feature.
+odl-aaa-shiro is automatically installed as part of the odl-restconf
+offering.
+
+How to disable AAA
+------------------
+
+Edit the “etc/shiro.ini” file and replace the following:
+
+::
+
+ /** = authcBasic
+
+with
+
+::
+
+ /** = anon
+
+Then restart the karaf process.
+
+.. note::
+
+ This is a change from the Lithium release, in which
+ “etc/org.opendaylight.aaa.authn.cfg” was edited to set
+ “authEnabled=false”. Please use the “shiro.ini” mechanism to disable
+ AAA going forward.
+
+How application developers can leverage AAA to provide servlet security
+-----------------------------------------------------------------------
+
+In order to provide security to a servlet, add the following to the
+servlet’s web.xml file as the first filter definition:
+
+::
+
+ <context-param>
+ <param-name>shiroEnvironmentClass</param-name>
+ <param-value>org.opendaylight.aaa.shiro.web.env.KarafIniWebEnvironment</param-value>
+ </context-param>
+
+ <listener>
+ <listener-class>org.apache.shiro.web.env.EnvironmentLoaderListener</listener-class>
+ </listener>
+
+ <filter>
+ <filter-name>ShiroFilter</filter-name>
+ <filter-class>org.opendaylight.aaa.shiro.filters.AAAShiroFilter</filter-class>
+ </filter>
+
+ <filter-mapping>
+ <filter-name>AAAShiroFilter</filter-name>
+ <url-pattern>/*</url-pattern>
+ </filter-mapping>
+
+.. note::
+
+ It is very important to place this AAAShiroFilter as the first
+ javax.servlet.Filter, as Jersey applies Filters in the order they
+ appear within web.xml. Placing the AAAShiroFilter first ensures
+ incoming HTTP/HTTPS requests have proper credentials before any
+ other filtering is attempted.
+
+AAA Realms
+----------
+
+AAA plugin utilizes realms to support pluggable authentication &
+authorization schemes. There are two parent types of realms:
+
+- AuthenticatingRealm
+
+ - Provides no Authorization capability.
+
+ - Users authenticated through this type of realm are treated
+ equally.
+
+- AuthorizingRealm
+
+ - AuthorizingRealm is a more sophisticated AuthenticatingRealm,
+ which provides the additional mechanisms to distinguish users
+ based on roles.
+
+ - Useful for applications in which roles determine allowed
+ cabilities.
+
+ODL Contains Four Implementations
+
+- TokenAuthRealm
+
+ - An AuthorizingRealm built to bridge the Shiro-based AAA service
+ with the Lithium h2-based AAA implementation.
+
+ - Exposes a RESTful web service to manipulate IdM policy on a
+ per-node basis. If identical AAA policy is desired across a
+ cluster, the backing data store must be synchronized using an out
+ of band method.
+
+ - A python script located at “etc/idmtool” is included to help
+ manipulate data contained in the TokenAuthRealm.
+
+ - Enabled out of the box.
+
+- ODLJndiLdapRealm
+
+ - An AuthorizingRealm built to extract identity information from IdM
+ data contained on an LDAP server.
+
+ - Extracts group information from LDAP, which is translated into ODL
+ roles.
+
+ - Useful when federating against an existing LDAP server, in which
+ only certain types of users should have certain access privileges.
+
+ - Disabled out of the box.
+
+- ODLJndiLdapRealmAuthNOnly
+
+ - The same as ODLJndiLdapRealm, except without role extraction.
+ Thus, all LDAP users have equal authentication and authorization
+ rights.
+
+ - Disabled out of the box.
+
+- ActiveDirectoryRealm
+
+.. note::
+
+ More than one Realm implementation can be specified. Realms are
+ attempted in order until authentication succeeds or all realm
+ sources are exhausted.
+
+TokenAuthRealm Configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TokenAuthRealm stores IdM data in an h2 database on each node. Thus,
+configuration of a cluster currently requires configuring the desired
+IdM policy on each node. There are two supported methods to manipulate
+the TokenAuthRealm IdM configuration:
+
+- idmtool Configuration
+
+- RESTful Web Service Configuration
+
+idmtool Configuration
+^^^^^^^^^^^^^^^^^^^^^
+
+A utility script located at “etc/idmtool” is used to manipulate the
+TokenAuthRealm IdM policy. idmtool assumes a single domain (sdn), since
+multiple domains are not leveraged in the Boron release. General usage
+information for idmtool is derived through issuing the following
+command:
+
+::
+
+ $ python etc/idmtool -h
+ usage: idmtool [-h] [--target-host TARGET_HOST]
+ user
+ {list-users,add-user,change-password,delete-user,list-domains,list-roles,add-role,delete-role,add-grant,get-grants,delete-grant}
+ ...
+
+ positional arguments:
+ user username for BSC node
+ {list-users,add-user,change-password,delete-user,list-domains,list-roles,add-role,delete-role,add-grant,get-grants,delete-grant}
+ sub-command help
+ list-users list all users
+ add-user add a user
+ change-password change a password
+ delete-user delete a user
+ list-domains list all domains
+ list-roles list all roles
+ add-role add a role
+ delete-role delete a role
+ add-grant add a grant
+ get-grants get grants for userid on sdn
+ delete-grant delete a grant
+
+ optional arguments:
+ -h, --help show this help message and exit
+ --target-host TARGET_HOST
+ target host node
+
+Add a user
+''''''''''
+
+::
+
+ python etc/idmtool admin add-user newUser
+ Password:
+ Enter new password:
+ Re-enter password:
+ add_user(admin)
+
+ command succeeded!
+
+ json:
+ {
+ "description": "",
+ "domainid": "sdn",
+ "email": "",
+ "enabled": true,
+ "name": "newUser",
+ "password": "**********",
+ "salt": "**********",
+ "userid": "newUser@sdn"
+ }
+
+.. note::
+
+ AAA redacts the password and salt fields for security purposes.
+
+Delete a user
+'''''''''''''
+
+::
+
+ $ python etc/idmtool admin delete-user newUser@sdn
+ Password:
+ delete_user(newUser@sdn)
+
+ command succeeded!
+
+List all users
+''''''''''''''
+
+::
+
+ $ python etc/idmtool admin list-users
+ Password:
+ list_users
+
+ command succeeded!
+
+ json:
+ {
+ "users": [
+ {
+ "description": "user user",
+ "domainid": "sdn",
+ "email": "",
+ "enabled": true,
+ "name": "user",
+ "password": "**********",
+ "salt": "**********",
+ "userid": "user@sdn"
+ },
+ {
+ "description": "admin user",
+ "domainid": "sdn",
+ "email": "",
+ "enabled": true,
+ "name": "admin",
+ "password": "**********",
+ "salt": "**********",
+ "userid": "admin@sdn"
+ }
+ ]
+ }
+
+Change a user’s password
+''''''''''''''''''''''''
+
+::
+
+ $ python etc/idmtool admin change-password admin@sdn
+ Password:
+ Enter new password:
+ Re-enter password:
+ change_password(admin)
+
+ command succeeded!
+
+ json:
+ {
+ "description": "admin user",
+ "domainid": "sdn",
+ "email": "",
+ "enabled": true,
+ "name": "admin",
+ "password": "**********",
+ "salt": "**********",
+ "userid": "admin@sdn"
+ }
+
+Add a role
+''''''''''
+
+::
+
+ $ python etc/idmtool admin add-role network-admin
+ Password:
+ add_role(network-admin)
+
+ command succeeded!
+
+ json:
+ {
+ "description": "",
+ "domainid": "sdn",
+ "name": "network-admin",
+ "roleid": "network-admin@sdn"
+ }
+
+Delete a role
+'''''''''''''
+
+::
+
+ $ python etc/idmtool admin delete-role network-admin@sdn
+ Password:
+ delete_role(network-admin@sdn)
+
+ command succeeded!
+
+List all roles
+''''''''''''''
+
+::
+
+ $ python etc/idmtool admin list-roles
+ Password:
+ list_roles
+
+ command succeeded!
+
+ json:
+ {
+ "roles": [
+ {
+ "description": "a role for admins",
+ "domainid": "sdn",
+ "name": "admin",
+ "roleid": "admin@sdn"
+ },
+ {
+ "description": "a role for users",
+ "domainid": "sdn",
+ "name": "user",
+ "roleid": "user@sdn"
+ }
+ ]
+ }
+
+List all domains
+''''''''''''''''
+
+::
+
+ $ python etc/idmtool admin list-domains
+ Password:
+ list_domains
+
+ command succeeded!
+
+ json:
+ {
+ "domains": [
+ {
+ "description": "default odl sdn domain",
+ "domainid": "sdn",
+ "enabled": true,
+ "name": "sdn"
+ }
+ ]
+ }
+
+Add a grant
+'''''''''''
+
+::
+
+ $ python etc/idmtool admin add-grant user@sdn admin@sdn
+ Password:
+ add_grant(userid=user@sdn,roleid=admin@sdn)
+
+ command succeeded!
+
+ json:
+ {
+ "domainid": "sdn",
+ "grantid": "user@sdn@admin@sdn@sdn",
+ "roleid": "admin@sdn",
+ "userid": "user@sdn"
+ }
+
+Delete a grant
+''''''''''''''
+
+::
+
+ $ python etc/idmtool admin delete-grant user@sdn admin@sdn
+ Password:
+ http://localhost:8181/auth/v1/domains/sdn/users/user@sdn/roles/admin@sdn
+ delete_grant(userid=user@sdn,roleid=admin@sdn)
+
+ command succeeded!
+
+Get grants for a user
+'''''''''''''''''''''
+
+::
+
+ python etc/idmtool admin get-grants admin@sdn
+ Password:
+ get_grants(admin@sdn)
+
+ command succeeded!
+
+ json:
+ {
+ "roles": [
+ {
+ "description": "a role for users",
+ "domainid": "sdn",
+ "name": "user",
+ "roleid": "user@sdn"
+ },
+ {
+ "description": "a role for admins",
+ "domainid": "sdn",
+ "name": "admin",
+ "roleid": "admin@sdn"
+ }
+ ]
+ }
+
+RESTful Web Service
+^^^^^^^^^^^^^^^^^^^
+
+The TokenAuthRealm IdM policy is fully configurable through a RESTful
+web service. Full documentation for manipulating AAA IdM data is located
+online (https://wiki.opendaylight.org/images/0/00/AAA_Test_Plan.docx),
+and a few examples are included in this guide:
+
+Get All Users
+'''''''''''''
+
+::
+
+ curl -u admin:admin http://localhost:8181/auth/v1/users
+ OUTPUT:
+ {
+ "users": [
+ {
+ "description": "user user",
+ "domainid": "sdn",
+ "email": "",
+ "enabled": true,
+ "name": "user",
+ "password": "**********",
+ "salt": "**********",
+ "userid": "user@sdn"
+ },
+ {
+ "description": "admin user",
+ "domainid": "sdn",
+ "email": "",
+ "enabled": true,
+ "name": "admin",
+ "password": "**********",
+ "salt": "**********",
+ "userid": "admin@sdn"
+ }
+ ]
+ }
+
+Create a User
+'''''''''''''
+
+::
+
+ curl -u admin:admin -X POST -H "Content-Type: application/json" --data-binary @./user.json http://localhost:8181/auth/v1/users
+ PAYLOAD:
+ {
+ "name": "ryan",
+ "userid": "ryan@sdn",
+ "password": "ryan",
+ "domainid": "sdn",
+ "description": "Ryan's User Account",
+ "email": "ryandgoulding@gmail.com"
+ }
+
+ OUTPUT:
+ {
+ "userid":"ryan@sdn",
+ "name":"ryan",
+ "description":"Ryan's User Account",
+ "enabled":true,
+ "email":"ryandgoulding@gmail.com",
+ "password":"**********",
+ "salt":"**********",
+ "domainid":"sdn"
+ }
+
+Create an OAuth2 Token For Admin Scoped to SDN
+''''''''''''''''''''''''''''''''''''''''''''''
+
+::
+
+ curl -d 'grant_type=password&username=admin&password=a&scope=sdn' http://localhost:8181/oauth2/token
+
+ OUTPUT:
+ {
+ "expires_in":3600,
+ "token_type":"Bearer",
+ "access_token":"5a615fbc-bcad-3759-95f4-ad97e831c730"
+ }
+
+Use an OAuth2 Token
+'''''''''''''''''''
+
+::
+
+ curl -H "Authorization: Bearer 5a615fbc-bcad-3759-95f4-ad97e831c730" http://localhost:8181/auth/v1/domains
+ {
+ "domains":
+ [
+ {
+ "domainid":"sdn",
+ "name":"sdn”,
+ "description":"default odl sdn domain",
+ "enabled":true
+ }
+ ]
+ }
+
+ODLJndiLdapRealm Configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+LDAP integration is provided in order to externalize identity
+management. To configure LDAP parameters, modify "etc/shiro.ini"
+parameters to include the ODLJndiLdapRealm:
+
+::
+
+ # ODL provides a few LDAP implementations, which are disabled out of the box.
+ # ODLJndiLdapRealm includes authorization functionality based on LDAP elements
+ # extracted through and LDAP search. This requires a bit of knowledge about
+ # how your LDAP system is setup. An example is provided below:
+ ldapRealm = org.opendaylight.aaa.shiro.realm.ODLJndiLdapRealm
+ ldapRealm.userDnTemplate = uid={0},ou=People,dc=DOMAIN,dc=TLD
+ ldapRealm.contextFactory.url = ldap://<URL>:389
+ ldapRealm.searchBase = dc=DOMAIN,dc=TLD
+ ldapRealm.ldapAttributeForComparison = objectClass
+ ldapRealm.groupRolesMap = "Person":"admin"
+ # ...
+ # further down in the file...
+ # Stacked realm configuration; realms are round-robbined until authentication succeeds or realm sources are exhausted.
+ securityManager.realms = $tokenAuthRealm, $ldapRealm
+
+This configuration allows federation with an external LDAP server, and
+the user’s ODL role parameters are mapped to corresponding LDAP
+attributes as specified by the groupRolesMap. Thus, an LDAP operator can
+provision attributes for LDAP users that support different ODL role
+structures.
+
+ODLJndiLdapRealmAuthNOnly Configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Edit the "etc/shiro.ini" file and modify the following:
+
+::
+
+ ldapRealm = org.opendaylight.aaa.shiro.realm.ODLJndiLdapRealm
+ ldapRealm.userDnTemplate = uid={0},ou=People,dc=DOMAIN,dc=TLD
+ ldapRealm.contextFactory.url = ldap://<URL>:389
+ # ...
+ # further down in the file...
+ # Stacked realm configuration; realms are round-robbined until authentication succeeds or realm sources are exhausted.
+ securityManager.realms = $tokenAuthRealm, $ldapRealm
+
+This is useful for setups where all LDAP users are allowed equal access.
+
+Token Store Configuration Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Edit the file “etc/opendaylight/karaf/08-authn-config.xml” and edit the
+following: .\ **timeToLive**: Configure the maximum time, in
+milliseconds, that tokens are to be cached. Default is 360000. Save the
+file.
+
+Authorization Configuration
+---------------------------
+
+Shiro-Based Authorization
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+OpenDaylight AAA has support for Role Based Access Control based on the
+Apache Shiro permissions system. Configuration of the authorization
+system is done offline; authorization currently cannot be configured
+after the controller is started. Thus, Authorization in the Beryllium
+release is aimed towards supporting coarse-grained security policies,
+with the aim to provide more robust configuration capabilities in the
+future. Shiro-based Authorization is documented on the Apache Shiro
+website (http://shiro.apache.org/web.html#Web-%7B%7B%5Curls%5C%7D%7D).
+
+Enable “admin” Role Based Access to the IdMLight RESTful web service
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Edit the “etc/shiro.ini” configuration file and add “/auth/v1/\ **=
+authcBasic, roles[admin]” above the line “/** = authcBasic” within the
+“urls” section.
+
+::
+
+ /auth/v1/** = authcBasic, roles[admin]
+ /** = authcBasic
+
+This will restrict the idmlight rest endpoints so that a grant for admin
+role must be present for the requesting user.
+
+.. note::
+
+ The ordering of the authorization rules above is important!
+
+AuthZ Broker Facade
+~~~~~~~~~~~~~~~~~~~
+
+ODL includes an experimental Authorization Broker Facade, which allows
+finer grained access control for REST endpoints. Since this feature was
+not well tested in the Boron release, it is recommended to use the
+Shiro-based mechanism instead, and rely on the Authorization Broker
+Facade for POC use only.
+
+AuthZ Broker Facade Feature Installation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To install the authorization broker facade, please issue the following
+command in the karaf shell:
+
+::
+
+ feature:install odl-restconf odl-aaa-authz
+
+Add an Authorization Rule
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following shows how one might go about securing the controller so
+that only admins can access restconf.
+
+::
+
+ curl -u admin:admin -H “Content-Type: application/xml” --data-binary @./rule.json http://localhost:8181/restconf/config/authorization-schema:simple-authorization/policies/RestConfService/
+ cat ./rule.json
+ {
+ "policies": {
+ "resource": "*",
+ "service":"RestConfService",
+ "role": "admin"
+ }
+ }
+
+Accounting Configuration
+------------------------
+
+All AAA logging is output to the standard karaf.log file.
+
+::
+
+ log:set TRACE org.opendaylight.aaa
+
+This command enables the most verbose level of logging for AAA
+components.
+
--- /dev/null
+Genius User Guide
+=================
+
+Overview
+--------
+
+The Genius project provides generic network interfaces, utilities and
+services. Any OpenDaylight application can use these to achieve
+interference-free co-existence with other applications using Genius.
+
+Modules and Interfaces
+----------------------
+
+In the the first phase delivered in OpenDaylight Boron release, Genius
+provides following modules —
+
+- Modules providing a common view of network interfaces for different
+ services
+
+ - **Interface (logical port) Manager**
+
+ - *Allows bindings/registration of multiple services to logical
+ ports/interfaces*
+
+ - *Ability to plug in different types of southbound protocol
+ renderers*
+
+ - **Overlay Tunnel Manager**
+
+ - *Creates and maintains overlay tunnels between configured
+ Tunnel Endpoints (TEPs)*
+
+- Modules providing commonly used functions as shared services to avoid
+ duplication of code and waste of resources
+
+ - **Liveness Monitor**
+
+ - *Provides tunnel/nexthop liveness monitoring services*
+
+ - **ID Manager**
+
+ - *Generates persistent unique integer IDs*
+
+ - **MD-SAL Utils**
+
+ - *Provides common generic APIs for interaction with MD-SAL*
+
+Interface Manager Operations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Creating interfaces
+^^^^^^^^^^^^^^^^^^^
+
+The YANG file Data Model
+`odl-interface.yang <https://github.com/opendaylight/genius/blob/master/interfacemanager/interfacemanager-api/src/main/yang/odl-interface.yang>`__
+contains the interface configuration data-model.
+
+You can create interfaces at the MD-SAL Data Node Path
+**/config/if:interfaces/interface**, with the following attributes —
+
+***Common attributes***
+
+- **name** — unique interface name, can be any unique string (e.g.,
+ UUID string)
+
+- **type** — interface type, currently supported *iana-if-type:l2vlan
+ and iana-if-type:tunnel*
+
+- **enabled** — admin status, possible values *true* or *false*
+
+- **parent-refs** : used to specify references to parent interface/port
+ feeding to this interface
+
+- datapath-node-identifier — identifier for a fixed/physical dataplane
+ node, can be physical switch identifier
+
+- parent-interface — can be a physical switch port (in conjunction of
+ above), virtual switch port (e.g., neutron port) or another interface
+
+- list node-identifier — identifier of the dependant underlying
+ configuration protocol
+
+ - *topology-id* — can be ovsdb configuration protocol
+
+ - *node-id* — can be hwvtep node-id
+
+***Type specific attributes***
+
+- when type = l2vlan
+
+ - **vlan-id** — VLAN id for trunk-member l2vlan interfaces
+
+ - **l2vlan-mode** — currently supported ones are *transparent*,
+ *trunk* or *trunk-member*
+
+- when type = stacked\_vlan (Not supported yet)
+
+ - **stacked-vlan-id** — VLAN-Id for additional/second VLAN tag
+
+- when type = tunnel
+
+ - **tunnel-interface-type** — tunnel type, currently supported ones
+ are:
+
+ - tunnel-type-vxlan
+
+ - tunnel-type-gre
+
+ - tunnel-type-mpls-over-gre
+
+ - **tunnel-source** — tunnel source IP address
+
+ - **tunnel-destination** — tunnel destination IP address
+
+ - **tunnel-gateway** — gateway IP address
+
+ - **monitor-enabled** — tunnel monitoring enable control
+
+ - **monitor-interval** — tunnel monitoring interval in millisiconds
+
+- when type = mpls (Not supported yet)
+
+ - **list labelStack** — list of lables
+
+ - **num-labels** — number of lables configured
+
+Supported REST calls are **GET, PUT, DELETE, POST**
+
+Creating L2 port interfaces
+'''''''''''''''''''''''''''
+
+Interfaces on normal L2 ports (e.g. Neutron tap ports) are created with
+type *l2vlan* and *l2vlan-mode* as *transparent*. This type of interfce
+classifies packets passing through a particular L2 (OpenFlow) port. In
+dataplane, packets belonging to this interface are classified by
+matching in-port against the of-port-id assigned to the base port as
+specified in parent-interface.
+
+**URL:** /restconf/config/ietf-interfaces:interfaces
+
+**Sample JSON data**
+
+::
+
+ "interfaces": {
+ "interface": [
+ {
+ "name": "4158408c-942b-487c-9a03-0b603c39d3dd",
+ "type": "iana-if-type:l2vlan", <--- interface type 'l2vlan' for normal L2 port
+ "odl-interface:l2vlan-mode": "transparent", <--- 'transparent' VLAN port mode allows any (tagged, untagged) ethernet packet
+ "odl-interface:parent-interface": "tap4158408c-94", <--- port-name as it appears on southbound interface
+ "enabled": true
+ }
+ ]
+ }
+
+Creating VLAN interfaces
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+A VLAN interface is created as a *l2vlan* interface in *trunk-member*
+mode, by configuring a VLAN-Id and a particular L2 (vlan trunk)
+interface. Parent VLAN trunk interface is created in the same way as the
+*transparent* interface as specified above. A *trunk-member* interface
+defines a flow on a particular L2 port and having a particular VLAN tag.
+On ingress, after classification the VLAN tag is popped out and
+corresponding unique dataplane-id is associated with the packet, before
+delivering the packet to service processing. When a service module
+delivers the packet to this interface for egress, it pushes
+corresponding VLAN tag and sends the packet out of the parent L2 port.
+
+**URL:** /restconf/config/ietf-interfaces:interfaces
+
+**Sample JSON data**
+
+::
+
+ "interfaces": {
+ "interface": [
+ {
+ "name": "4158408c-942b-487c-9a03-0b603c39d3dd:100",
+ "type": "iana-if-type:l2vlan",
+ "odl-interface:l2vlan-mode": "trunk-member", <--- for 'trunk-member', flow is classified with particular vlan-id on an l2 port
+ "odl-interface:parent-interface": "4158408c-942b-487c-9a03-0b603c39d3dd", <--- Parent 'trunk' iterface name
+ "odl-interface:vlan-id": "100",
+ "enabled": true
+ }
+ ]
+ }
+
+Creating Overlay Tunnel Interfaces
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An overlay tunnel interface is created with type *tunnel* and particular
+*tunnel-interface-type*. Tunnel interfaces are created on a particular
+data plane node (virtual switches) with a pair of (local, remote) IP
+addresses. Currently supported tunnel interface types are VxLAN, GRE and
+MPLSoverGRE.
+
+**URL:** /restconf/config/ietf-interfaces:interfaces
+
+**Sample JSON data**
+
+::
+
+ "interfaces": {
+ "interface": [
+ {
+ "name": "MGRE_TUNNEL:1",
+ "type": "iana-if-type:tunnel",
+ "odl-interface:tunnel-interface-type": "odl-interface:tunnel-type-mpls-over-gre",
+ "odl-interface:datapath-node-identifier": 156613701272907,
+ "odl-interface:tunnel-source": "11.0.0.43",
+ "odl-interface:tunnel-destination": "11.0.0.66",
+ "odl-interface:monitor-enabled": false,
+ "odl-interface:monitor-interval": 10000,
+ "enabled": true
+ }
+ ]
+ }
+
+Binding services on interface
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The YANG file
+`odl-interface-service-bindings.yang <https://github.com/opendaylight/genius/blob/stable/boron/interfacemanager/interfacemanager-api/src/main/yang/odl-interface-service-bindings.yang>`__
+contains the service binding configuration data model.
+
+An application can bind services to a particular interface by
+configuring MD-SAL data node at path /config/interface-service-binding.
+Binding services on interface allows particular service to pull traffic
+arriving on that interafce depending upon the a service priority.
+Service modules can specify openflow-rules to be applied on the packet
+belonging to the inetrface. Usually these rules include sending the
+packet to specific service table/pipeline. Service modules are
+responsible for sending the packet back (if not consumed) to service
+dispatcher table, for next service to process the packet.
+
+**URL:**/restconf/config/interface-service-bindings:service-bindings/
+
+**Sample JSON data**
+
+::
+
+ "service-bindings": {
+ "services-info": [
+ {
+ "interface-name": "4152de47-29eb-4e95-8727-2939ac03ef84",
+ "bound-services": [
+ {
+ "service-name": "ELAN",
+ "service-type": "interface-service-bindings:service-type-flow-based"
+ "service-priority": 3,
+ "flow-priority": 5,
+ "flow-cookie": 134479872,
+ "instruction": [
+ {
+ "order": 2,
+ "go-to-table": {
+ "table_id": 50
+ }
+ },
+ {
+ "order": 1,
+ "write-metadata": {
+ "metadata": 83953188864,
+ "metadata-mask": 1099494850560
+ }
+ }
+ ],
+ },
+ {
+ "service-name": "L3VPN",
+ "service-type": "interface-service-bindings:service-type-flow-based"
+ "service-priority": 2,
+ "flow-priority": 10,
+ "flow-cookie": 134217729,
+ "instruction": [
+ {
+ "order": 2,
+ "go-to-table": {
+ "table_id": 21
+ }
+ },
+ {
+ "order": 1,
+ "write-metadata": {
+ "metadata": 100,
+ "metadata-mask": 4294967295
+ }
+ }
+ ],
+ }
+ ]
+ }
+ ]
+ }
+
+Interface Manager RPCs
+~~~~~~~~~~~~~~~~~~~~~~
+
+In addition to the above defined configuration interfaces, Interface
+Manager also provides several RPCs to access interface operational data
+and other helpful information. Interface Manger RPCs are defined in
+`odl-interface-rpc.yang <https://github.com/opendaylight/genius/blob/stable/boron/interfacemanager/interfacemanager-api/src/main/yang/odl-interface-rpc.yang>`__
+
+The following RPCs are available —
+
+get-dpid-from-interface
+^^^^^^^^^^^^^^^^^^^^^^^
+
+This RPC is used to retrieve dpid/switch hosting the root port from
+given interface name.
+
+::
+
+ rpc get-dpid-from-interface {
+ description "used to retrieve dpid from interface name";
+ input {
+ leaf intf-name {
+ type string;
+ }
+ }
+ output {
+ leaf dpid {
+ type uint64;
+ }
+ }
+ }
+
+get-port-from-interface
+^^^^^^^^^^^^^^^^^^^^^^^
+
+This RPC is used to retrieve south bound port attributes from the
+interface name.
+
+::
+
+ rpc get-port-from-interface {
+ description "used to retrieve south bound port attributes from the interface name";
+ input {
+ leaf intf-name {
+ type string;
+ }
+ }
+ output {
+ leaf dpid {
+ type uint64;
+ }
+ leaf portno {
+ type uint32;
+ }
+ leaf portname {
+ type string;
+ }
+ }
+ }
+
+get-egress-actions-for-interface
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This RPC is used to retrieve group actions to use from interface name.
+
+::
+
+ rpc get-egress-actions-for-interface {
+ description "used to retrieve group actions to use from interface name";
+ input {
+ leaf intf-name {
+ type string;
+ mandatory true;
+ }
+ leaf tunnel-key {
+ description "It can be VNI for VxLAN tunnel ifaces, Gre Key for GRE tunnels, etc.";
+ type uint32;
+ mandatory false;
+ }
+ }
+ output {
+ uses action:action-list;
+ }
+ }
+
+get-egress-instructions-for-interface
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This RPC is used to retrieve flow instructions to use from interface
+name.
+
+::
+
+ rpc get-egress-instructions-for-interface {
+ description "used to retrieve flow instructions to use from interface name";
+ input {
+ leaf intf-name {
+ type string;
+ mandatory true;
+ }
+ leaf tunnel-key {
+ description "It can be VNI for VxLAN tunnel ifaces, Gre Key for GRE tunnels, etc.";
+ type uint32;
+ mandatory false;
+ }
+ }
+ output {
+ uses offlow:instruction-list;
+ }
+ }
+
+get-endpoint-ip-for-dpn
+^^^^^^^^^^^^^^^^^^^^^^^
+
+This RPC is used to get the local ip of the tunnel/trunk interface on a
+particular DPN (Data Plane Node).
+
+::
+
+ rpc get-endpoint-ip-for-dpn {
+ description "to get the local ip of the tunnel/trunk interface";
+ input {
+ leaf dpid {
+ type uint64;
+ }
+ }
+ output {
+ leaf-list local-ips {
+ type inet:ip-address;
+ }
+ }
+ }
+
+get-interface-type
+^^^^^^^^^^^^^^^^^^
+
+This RPC is used to get the type of the interface (vlan/vxlan or gre).
+
+::
+
+ rpc get-interface-type {
+ description "to get the type of the interface (vlan/vxlan or gre)";
+ input {
+ leaf intf-name {
+ type string;
+ }
+ }
+ output {
+ leaf interface-type {
+ type identityref {
+ base if:interface-type;
+ }
+ }
+ }
+ }
+
+get-tunnel-type
+^^^^^^^^^^^^^^^
+
+This RPC is used to get the type of the tunnel interface(vxlan or gre).
+
+::
+
+ rpc get-tunnel-type {
+ description "to get the type of the tunnel interface (vxlan or gre)";
+ input {
+ leaf intf-name {
+ type string;
+ }
+ }
+ output {
+ leaf tunnel-type {
+ type identityref {
+ base odlif:tunnel-type-base;
+ }
+ }
+ }
+ }
+
+get-nodeconnector-id-from-interface
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This RPC is used to get node-connector-id associated with an interface.
+
+::
+
+ rpc get-nodeconnector-id-from-interface {
+ description "to get nodeconnector id associated with an interface";
+ input {
+ leaf intf-name {
+ type string;
+ }
+ }
+ output {
+ leaf nodeconnector-id {
+ type inv:node-connector-id;
+ }
+ }
+ }
+
+get-interface-from-if-index
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This RPC is used to get interface associated with an if-index (dataplane
+interface id).
+
+::
+
+ rpc get-interface-from-if-index {
+ description "to get interface associated with an if-index";
+ input {
+ leaf if-index {
+ type int32;
+ }
+ }
+ output {
+ leaf interface-name {
+ type string;
+ }
+ }
+ }
+
+create-terminating-service-actions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This RPC is used to create the tunnel termination service table entries.
+
+::
+
+ rpc create-terminating-service-actions {
+ description "create the ingress terminating service table entries";
+ input {
+ leaf dpid {
+ type uint64;
+ }
+ leaf tunnel-key {
+ type uint64;
+ }
+ leaf interface-name {
+ type string;
+ }
+ uses offlow:instruction-list;
+ }
+ }
+
+remove-terminating-service-actions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This RPC is used to remove the tunnel termination service table entries.
+
+::
+
+ rpc remove-terminating-service-actions {
+ description "remove the ingress terminating service table entries";
+ input {
+ leaf dpid {
+ type uint64;
+ }
+ leaf interface-name {
+ type string;
+ }
+ leaf tunnel-key {
+ type uint64;
+ }
+ }
+ }
+
+ID Manager
+----------
+
+TBD.
A DevStack demo environment can be found on the `**GBP**
wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`__.
+GBP Renderer manager
+--------------------
+
+Overview
+~~~~~~~~
+
+The GBP Renderer manager is an integral part of **GBP** base module.
+It dispatches information about endpoints'
+policy configuration to specific device renderer
+by writing a renderer policy configuration into the
+registered renderer's policy store.
+
+Installing and Pre-requisites
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Renderer manager is integrated into GBP base module,
+so no additional installation is required.
+
+Architecture
+~~~~~~~~~~~~
+
+Renderer manager gets data notifications about:
+
+- Endoints (base-endpoint.yang)
+
+- EndpointLocations (base-endpoint.yang)
+
+- ResolvedPolicies (resolved-policy.yang)
+
+- Forwarding (forwarding.yang)
+
+Based on data from notifications it creates a configuration task for
+specific renderers by writing a renderer policy configuration into the
+registered renderer's policy store.
+Configuration is stored to CONF data store as Renderers (renderer.yang).
+
+Configuration is signed with version number which is incremented by every change.
+All renderers are supposed to be on the same version. Renderer manager waits
+for all renderers to respond with version update in OPER data store.
+After a version of every renderer in OPER data store has the same value
+as the one in CONF data store,
+renderer manager moves to the next configuration with incremented version.
+
+GBP Location manager
+--------------------
+
+Overview
+~~~~~~~~
+
+Location manager monitors information about Endpoint Location providers
+(see endpoint-location-provider.yang) and manages Endpoint locations in OPER data store accordingly.
+
+Installing and Pre-requisites
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Location manager is integrated into GBP base module,
+so no additional installation is required.
+
+Architecture
+~~~~~~~~~~~~
+
+The endpoint-locations container in OPER data store (see base-endpoint.yang)
+contains two lists for two types of EP location,
+namely address-endpoint-location and containment-endpoint-location.
+LocationResolver is a class that processes Location providers in CONF data store
+and puts location information to OPER data store.
+
+When a new Location provider is created in CONF data store, its Address EP locations
+are being processed first, and their info is stored locally in accordance with processed
+Location provider's priority. Then a location of type "absolute" with the highest priority
+is selected for an EP, and is put in OPER data store. If Address EP locations contain
+locations of type "relative", those are put to OPER data store.
+
+If current Location provider contains Containment EP locations of type "relative",
+then those are put to OPER data store.
+
+Similarly, when a Location provider is deleted, information of its locations
+is removed from the OPER data store.
+
Using the GBP OpenFlow Overlay (OfOverlay) renderer
---------------------------------------------------
cardinal_-opendaylight-monitoring-as-a-service
centinel-user-guide
didm-user-guide
+ genius-user-guide
group-based-policy-user-guide
l2switch-user-guide
l3vpn-service_-user-guide
link-aggregation-control-protocol-user-guide
lisp-flow-mapping-user-guide
+ nemo-user-guide
netconf-user-guide
netide-user-guide
neutron-service-user-guide
pcep-user-guide
packetcable-user-guide
service-function-chaining
+ snbi-user-guide
snmp-plugin-user-guide
snmp4sdn-user-guide
sxp-user-guide
--- /dev/null
+NEtwork MOdeling (NEMO)
+=======================
+
+This section describes how to use the NEMO feature in OpenDaylight
+and contains contains configuration, administration, and management
+sections for the feature.
+
+Overview
+--------
+
+With the network becoming more complicated, users and applications must handle
+more complex configurations to deploy new services. NEMO project aims to simplify
+the usage of network by providing a new intent northbound interface (NBI). Instead
+of tons of APIs, users/applications just need to describe their intent without
+caring about complex physical devices and implementation means. The intent will
+be translated into detailed configurations on the devices in the NEMO engine. A
+typical scenario is user just need to assign which nodes to implement an VPN,
+without considering which technique is used.
+
+NEMO Engine Architecture
+------------------------
+
+* NEMO API
+ * The NEMO API provide users the NEMO model, which guides users how to construct the
+ instance of intent, and how to construct the instance of predefined types.
+* NEMO REST
+ * The NEMO REST provides users REST APIs to access NEMO engine, that is, user could
+ transmit the intent instance to NEMO engine through basic REST methods.
+* NEMO UI
+ * The NEMO UI provides users a visual interface to deploy service with NEMO model,
+ and display the state in DLUX UI.
+
+Installing NEMO engine
+----------------------
+
+To install NEMO engine, download OpenDaylight and use the Karaf console
+to install the following feature:
+
+odl-nemo-engine-ui
+
+Administering or Managing NEMO Engine
+-------------------------------------
+
+After install features NEMO engine used, user could use NEMO to express his intent
+with NEMO UI or REST APIs in apidoc.
+
+Go to ``http://{controller-ip}:8181/index.html``. In this interface, user could go to
+NEMO UI, and use the tabs and input box to input intent, and see the state of intent
+deployment with the image.
+
+Go to ``http://{controller-ip}:8181/apidoc/explorer/index.html``. In this interface, user
+could REST methods "POST", "PUT","GET" and "DELETE" to deploy intent or query the state
+of deployment.
+
+Tutorials
+---------
+
+Below are tutorials for NEMO Engine.
+
+Using NEMO Engine
+~~~~~~~~~~~~~~~~~
+
+The purpose of the tutorial is to describe how to use use UI to deploy intent.
+
+Overview
+^^^^^^^^
+
+This tutorial will describe how to use the NEMO UI to check the operated resources, the steps
+to deploy service, and the ultimate state.
+
+Prerequisites
+^^^^^^^^^^^^^
+
+To understand the tutorial well, we hope there are a physical or virtual network exist, and
+OpenDaylight with NEMO engine must be deployed in one host.
+
+Target Environment
+^^^^^^^^^^^^^^^^^^
+
+The intent expressed by NEMO model is depended on network resources, so user need to have enough
+resources to use, or else, the deployment of intent will fail.
+
+Instructions
+^^^^^^^^^^^^
+
+- Run the OpenDaylight distribution and install odl-nemo-engine-ui from the Karaf console.
+- Go to ``http://{controller-ip}:8181/index.html``, and sign in.
+- Go the NEMO UI interface. And Register a new user with user name, password, and tenant.
+- Check the existing resources to see if it is consistent with yours.
+- Deploy service with NEMO model by the create intent menu.
+
- `RFC-6022 <https://tools.ietf.org/html/rfc6022>`__
+- `draft-ietf-netconf-yang-library-06 <https://tools.ietf.org/html/draft-ietf-netconf-yang-library-06>`__
+
**Netconf-connector is fully model-driven (utilizing the YANG modeling
language) so in addition to the above RFCs, it supports any
data/RPC/notifications described by a YANG model that is implemented by
DELETE http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device
+Connecting to a device supporting only NETCONF 1.0
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+OpenDaylight is schema-based distribution and heavily depends on YANG
+models. However some legacy NETCONF devices are not schema-based and
+implement just RFC 4741. This type of device does not utilize YANG
+models internally and OpenDaylight does not know how to communicate
+with such devices, how to validate data, or what the semantics of data
+are.
+
+NETCONF connector can communicate also with these devices, but the
+trade-offs are worsened possibilities in utilization of NETCONF
+mountpoints. Using RESTCONF with such devices is not suported. Also
+communicating with schemaless devices from application code is slightly
+different.
+
+To connect to schemaless device, there is a optional configuration option
+in netconf-node-topology model called schemaless. You have to set this
+option to true.
+
Clustered NETCONF connector
~~~~~~~~~~~~~~~~~~~~~~~~~~~
- `RFC-6022 <https://tools.ietf.org/html/rfc6022>`__
+- `draft-ietf-netconf-yang-library-06 <https://tools.ietf.org/html/draft-ietf-netconf-yang-library-06>`__
+
Notifications over NETCONF are not supported in the Beryllium release.
**Tip**
Very similar to NETCONF stress tool with the difference of using
RESTCONF protocol instead of NETCONF.
+YANGLIB remote repository
+-------------------------
+
+There are scenarios in NETCONF deployment, that require for a centralized
+YANG models repository. YANGLIB plugin provides such remote repository.
+
+To start this plugin, you have to install odl-yanglib feature. Then you
+have to configure YANGLIB either through RESTCONF or NETCONF. We will
+show how to configure YANGLIB through RESTCONF.
+
+YANGLIB configuration through RESTCONF
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You have to specify what local YANG modules directory you want to provide.
+Then you have to specify address and port whre you want to provide YANG
+sources. For example, we want to serve yang sources from folder /sources
+on localhost:5000 adress. The configuration for this scenario will be
+as follows:
+
+::
+
+ PUT http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/yanglib:yanglib/example
+
+Headers:
+
+- Accept: application/xml
+
+- Content-Type: application/xml
+
+Payload:
+
+::
+
+ <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
+ <name>example</name>
+ <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:yanglib:impl">prefix:yanglib</type>
+ <broker xmlns="urn:opendaylight:params:xml:ns:yang:controller:yanglib:impl">
+ <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-broker-osgi-registry</type>
+ <name>binding-osgi-broker</name>
+ </broker>
+ <cache-folder xmlns="urn:opendaylight:params:xml:ns:yang:controller:yanglib:impl">/sources</cache-folder>
+ <binding-addr xmlns="urn:opendaylight:params:xml:ns:yang:controller:yanglib:impl">localhost</binding-addr>
+ <binding-port xmlns="urn:opendaylight:params:xml:ns:yang:controller:yanglib:impl">5000</binding-port>
+ </module>
+
+This should result in a 2xx response and new YANGLIB instance should be
+created. This YANGLIB takes all YANG sources from /sources folder and
+for each generates URL in form:
+
+::
+
+ http://localhost:5000/schemas/{modelName}/{revision}
+
+On this URL will be hosted YANG source for particular module.
+
+YANGLIB instance also write this URL along with source identifier to
+ietf-netconf-yang-library/modules-state/module list.
+
+Netconf-connector with YANG library as fallback
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There is an optional configuration in netconf-connector called
+yang-library. You can specify YANG library to be plugged as additional
+source provider into the mount's schema repository. Since YANGLIB
+plugin is advertising provided modules through yang-library model, we
+can use it in mount point's configuration as YANG library. To do this,
+we need to modify the configuration of netconf-connector by adding this
+XML
+
+::
+
+ <yang-library xmlns="urn:opendaylight:netconf-node-topology">
+ <yang-library-url xmlns="urn:opendaylight:netconf-node-topology">http://localhost:8181/restconf/operational/ietf-yang-library:modules-state</yang-library-url>
+ <username xmlns="urn:opendaylight:netconf-node-topology">admin</username>
+ <password xmlns="urn:opendaylight:netconf-node-topology">admin</password>
+ </yang-library>
+
+This will register YANGLIB provided sources as a fallback schemas for
+particular mount point.
--- /dev/null
+SNBI User Guide
+===============
+
+This section describes how to use the SNBI feature in OpenDaylight and
+contains configuration, administration, and management section for the
+feature.
+
+Overview
+--------
+
+Key distribution in a scaled network has always been a challenge.
+Typically, operators must perform some manual key distribution process
+before secure communication is possible between a set of network
+devices. The Secure Network Bootstrapping Infrastructure (SNBI) project
+securely and automatically brings up an integrated set of network
+devices and controllers, simplifying the process of bootstrapping
+network devices with the keys required for secure communication. SNBI
+enables connectivity to the network devices by assigning unique IPv6
+addresses and bootstrapping devices with the required keys. Admission
+control of devices into a specific domain is achieved using whitelist of
+authorized devices.
+
+SNBI Architecture
+-----------------
+
+At a high level, SNBI architecture consists of the following components:
+
+- SNBI Registrar
+
+- SNBI Forwarding Element (FE)
+
+.. figure:: ./images/snbi/snbi_arch.png
+ :alt: SNBI Architecture Diagram
+
+ SNBI Architecture Diagram
+
+SNBI Registrar
+~~~~~~~~~~~~~~
+
+Registrar is a device in a network that validates device against a
+whitelist and delivers device domain certificate. Registrar includes the
+following:
+
+- RESCONF API for Domain Whitelist Configuration
+
+- SNBI Southbound Plugin
+
+- Certificate Authority
+
+**RESTCONF API for Domain Whitelist Configuration:.**
+
+Below is the YANG model to configure the whitelist of devices for a
+particular domain.
+
+::
+
+ module snbi {
+ //The yang version - today only 1 version exists. If omitted defaults to 1.
+ yang-version 1;
+
+ //a unique namespace for this SNBI module, to uniquely identify it from other modules that may have the same name.
+ namespace "http://netconfcentral.org/ns/snbi";
+
+ //a shorter prefix that represents the namespace for references used below
+ prefix snbi;
+
+ //Defines the organization which defined / owns this .yang file.
+ organization "Netconf Central";
+
+ //defines the primary contact of this yang file.
+ contact "snbi-dev";
+
+ //provides a description of this .yang file.
+ description "YANG version for SNBI.";
+
+ //defines the dates of revisions for this yang file
+ revision "2024-07-02" {
+ description "SNBI module";
+ }
+
+ typedef UDI {
+ type string;
+ description "Unique Device Identifier";
+ }
+
+ container snbi-domain {
+ leaf domain-name {
+ type string;
+ description "The SNBI domain name";
+ }
+
+ list device-list {
+ key "list-name";
+
+ leaf list-name {
+ type string;
+ description "Name of the device list";
+ }
+
+ leaf list-type {
+ type enumeration {
+ enum "white";
+ }
+ description "Indicates the type of the list";
+ }
+
+ leaf active {
+ type boolean;
+ description "Indicates whether the list is active or not";
+ }
+
+ list devices {
+ key "device-identifier";
+ leaf device-identifier {
+ type union {
+ type UDI;
+ }
+ }
+ }
+ }
+ }
+ }
+
+**Southbound Plugin:.**
+
+The Southbound Plugin implements the protocol state machine necessary to
+exchange device identifiers, and deliver certificates.
+
+**Certificate Authority:.**
+
+A simple certificate authority is implemented using the Bouncy Castle
+package. The Certificate Authority creates the certificates from the
+device CSR requests received from the devices. The certificates thus
+generated are delivered to the devices using the Southbound Plugin.
+
+SNBI Forwarding Element
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The forwarding element must be installed or unpacked on a Linux host
+whose network layer traffic must be secured. The FE performs the
+following functions:
+
+- Neighour Discovery
+
+- Bootstrap
+
+- Host Configuration
+
+**Neighbour Discovery:.**
+
+Neighbour Discovery (ND) is the first step in accommodating devices in a
+secure network. SNBI performs periodic neighbour discovery of SNBI
+agents by transmitting ND hello packets. The discovered devices are
+populated in an ND table. Neighbour Discovery is periodic and
+bidirectional. ND hello packets are transmitted every 10 seconds. A 40
+second refresh timer is set for each discovered neighbour. On expiry of
+the refresh timer, the Neighbour Adjacency is removed from the ND table
+as the Neighbour Adjacency is no longer valid. It is possible that the
+same SNBI neighbour is discovered on multiple links, the expiry of a
+device on one link does not automatically remove the device entry from
+the ND table.
+
+**Bootstrapping:.**
+
+Bootstrapping a device involves the following sequential steps:
+
+- Authenticate a device using device identifier (UDI or SUDI)
+
+- Allocate the appropriate device ID and IPv6 address to uniquely
+ identify the device in the network
+
+- Allocate the required keys by installing a Device Domain Certificate
+
+- Accommodate the device in the domain
+
+**Host Configuration:.**
+
+Involves configuring a host to create a secure overlay network,
+assigning appropriate ipv6 address, setting up gre tunnels, securing the
+tunnels traffic via IPsec and enabling connectivity via a routing
+protocol.
+
+The SNBI Forwarding Element is packaged in a docker container available
+at this link: https://hub.docker.com/r/snbi/boron/. For more information
+on docker, refer to this link: https://docs.docker.com/linux/.
+
+Prerequisites for Configuring SNBI
+----------------------------------
+
+Before proceeding further, ensure that the following system requirements
+are met:
+
+- 64bit Ubunutu 14.04 LTS
+
+- 4GB RAM
+
+- 4GB of hard disk space, sufficient enough to store certificates
+
+- Java Virtual Machine 1.8 or above
+
+- Apache Maven 3.3.3 or above
+
+- Make sure the time on all the devices or synced either manually or
+ using NTP
+
+- The docker version must be greater than 1.0 on a 14.04 Ubuntu
+
+Configuring SNBI
+----------------
+
+This section contains the following:
+
+- Setting up SNBI Registrar on the controller
+
+- Configuring Whitelist
+
+- Setting up SNBI FE on Linux Hosts
+
+Setting up SNBI Registrar on the controller
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This section contains the following:
+
+- Configuring the Registrar Host
+
+- Installing Karaf Package
+
+- Configuring SNBI Registrar
+
+**Configuring the Registrar Host:.**
+
+Before enabling the SNBI registrar service, assign an IPv6 address to an
+interface on the registrar host. This is to bind the registrar service
+to an IPv6 address (**fd08::aaaa:bbbb:1/128**).
+
+::
+
+ sudo ip link add snbi-ra type dummy
+ sudo ip addr add fd08::aaaa:bbbb:1/128 dev snbi-ra
+ sudo ifconfig snbi-ra up
+
+**Installing Karaf Package:.**
+
+Download the karaf package from this link:
+http://www.opendaylight.org/software/downloads, unzip and run the
+``karaf`` executable present in the bin folder. Here is an example of
+this step:
+
+::
+
+ cd distribution-karaf-0.3.0-Boron/bin
+ ./karaf
+
+Additional information on useful Karaf commands are available at this
+link:
+https://wiki.opendaylight.org/view/CrossProject:Integration_Group:karaf.
+
+**Configuring SNBI Registrar:.**
+
+Before you perform this step, ensure that you have completed the tasks
+`above <#_configuring_snbi>`__:
+
+To use RESTCONF APIs, install the RESTCONF feature available in the
+Karaf package. If required, install mdsal-apidocs module for access to
+documentation. Refer
+https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf_API_Explorer
+for more information on MDSAL API docs.
+
+Use the commands below to install the required features and verify the
+same.
+
+::
+
+ feature:install odl-restconf
+ feature:install odl-mdsal-apidocs
+ feature:install odl-snbi-all
+ feature:list -i
+
+After confirming that the features are installed, use the following
+command to start SNBI registrar:
+
+::
+
+ snbi:start <domain-name>
+
+Configuring Whitelist
+~~~~~~~~~~~~~~~~~~~~~
+
+The registrar must be configured with a whitelist of devices that are
+accommodated in a specific domain. The YANG for configuring the domain
+and the associated whitelist in the controller is avaialble at this
+link:
+https://wiki.opendaylight.org/view/SNBI_Architecture_and_Design#Registrar_YANG_Definition.
+It is recommended to use Postman to configure the registrar using
+RESTCONF.
+
+This section contains the following:
+
+- Installing PostMan
+
+- Configuring Whitelist using REST API
+
+**Installing PostMan:.**
+
+Follow the steps below to install postman on your Google Chrome Browser.
+
+- Install Postman via Google Chrome browser available at this link:
+ https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en
+
+- In the chrome browser address bar, enter: chrome://apps/
+
+- Click Postman.
+
+- Enter the URL.
+
+- Click Headers.
+
+- Enter Accept: header.
+
+- Click Basic Auth tab to create user credentials, such as user name
+ and password.
+
+- Send.
+
+You can download a sample Postman configuration to get started from this
+link: https://www.getpostman.com/collections/c929a2a4007ffd0a7b51
+
+**Configuring Whitelist using REST API:.**
+
+The POST method below configures a domain - "secure-domain" and
+configures a whitelist set of devices to be accommodated to the domain.
+
+::
+
+ {
+ "snbi-domain": {
+ "domain-name": "secure-domain",
+ "device-list": [
+ {
+ "list-name": "demo list",
+ "list-type": "white",
+ "active": true,
+ "devices": [
+ {
+ "device-id": "UDI-FirstFE"
+ },
+ {
+ "device-id": "UDI-dev1"
+ },
+ {
+ "device-id": "UDI-dev2"
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+The associated device ID must be configured on the SNBI FE (see below).
+You can also use REST APIs using the API docs interface to push the
+domain and whitelist information. The API docs could be accessed at
+link:http://localhost:8080/apidoc/explorer. More details on the API docs
+is available at
+link:https://wiki.opendaylight.org/view/OpenDaylight\_Controller:MD-SAL:Restconf\_API\_Explorer
+
+Setting up SNBI FE on Linux Hosts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The SNBI Daemon is used to bootstrap the host device with a valid device
+domain certificate and IP address for connectivity and to create a
+reachable overlay network by interacting with multiple software modules.
+
+**Device UDI:.**
+
+The Device UDI or the device Unique Identifier can be derived from a
+multitude of parameters in the host machine, but most derived parameters
+are already known or do not remain constant across reloads. Therefore,
+every SNBI FE must be configured explicitly with a UDI that is present
+in the device whitelist.
+
+**First Forwarding Element:.**
+
+The registrar service IP address must be provided to the first host
+(Forwarding Element) to be bootstrapped. As mentioned in the
+"Configuring the Registrar Host" section, the registrar service IP
+address is **fd08::aaaa:bbbb:1**. The First Forwarding Element must be
+configured with this IPv6 address.
+
+**Running the SNBI docker image:.**
+
+The SNBI FE in the docker image picks the UDI of the ForwardingElement
+via an environment variable provided when executing docker instance. If
+the Forwarding Element is a first forwarding element, the IP address of
+the registrar service should also be provided.
+
+::
+
+ sudo docker run -v /etc/timezone:/etc/timezone:ro --net=host --privileged=true
+ --rm -t -i -e SNBI_UDI=UDI-FirstFE -e SNBI_REGISTRAR=fd08::aaaa:bbbb:1 snbi/boron:latest /bin/bash
+
+After the docker image is executed, you are placed in the snbi.d command
+prompt.
+
+A new Forwarding Element is bootstrapped in the same way, except that
+the registrar IP address is not required while running the docker image.
+
+::
+
+ sudo docker run --net=host --privileged=true --rm -t -i -e SNBI_UDI=UDI-dev1 snbi/boron:latest /bin/bash
+
+Administering or Managing SNBI
+------------------------------
+
+The SNBI daemon provides various show commands to verify the current
+state of the daemon. The commands are completed automatically when you
+press Tab in your keyboard. There are help strings "?" to list commands.
+
+::
+
+ snbi.d > show snbi
+ device Host deevice
+ neighbors SNBI Neighbors
+ debugs Debugs enabled
+ certificate Certificate information
+
--- /dev/null
+YANG-PUSH
+=========
+
+This section describes how to use the YANG-PUSH feature in OpenDaylight
+and contains contains configuration, administration, and management
+sections for the feature.
+
+Overview
+--------
+
+YANG PUBSUB project allows applications to place subscriptions upon
+targeted subtrees of YANG datastores residing on remote devices. Changes
+in YANG objects within the remote subtree can be pushed to an
+OpenDaylight MD-SAL and to the application as specified without a
+requiring the controller to make a continuous set of fetch requests.
+
+YANG-PUSH capabilities available
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This module contains the base code which embodies the intent of
+YANG-PUSH requirements for subscription as defined in
+{i2rs-pub-sub-requirements}
+[https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/].
+The mechanism for delivering on these YANG-PUSH requirements over
+Netconf transport is defined in {netconf-yang-push} [netconf-yang-push:
+https://tools.ietf.org/html/draft-ietf-netconf-yang-push-00].
+
+Note that in the current release, not all capabilities of
+draft-ietf-netconf-yang-push are realized. Currently only implemented is
+**create-subscription** RPC support from
+ietf-datastore-push@2015-10-15.yang; and this will be for periodic
+subscriptions only. There of course is intent to provide much additional
+functionality in future OpenDaylight releases.
+
+Future YANG-PUSH capabilities
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Over time, the intent is to flesh out more robust capabilities which
+will allow OpenDaylight applications to subscribe to YANG-PUSH compliant
+devices. Capabilities for future releases will include:
+
+Support for subscription change/delete: **modify-subscription** rpc
+support for all mountpoint devices or particular mountpoint device
+**delete-subscription** rpc support for all mountpoint devices or
+particular mountpoint device
+
+Support for static subscriptions: This will enable the receipt of
+subscription updates pushed from publishing devices where no signaling
+from the controller has been used to establish the subscriptions.
+
+Support for additional transports: NETCONF is not the only transport of
+interest to OpenDaylight or the subscribed devices. Over time this code
+will support Restconf and HTTP/2 transport requirements defined in
+{netconf-restconf-yang-push}
+[https://tools.ietf.org/html/draft-voit-netconf-restconf-yang-push-01]
+
+YANG-PUSH Architecture
+----------------------
+
+The code architecture of Yang push consists of two main elements
+
+YANGPUSH Provider YANGPUSH Listener
+
+YANGPUSH Provider receives create-subscription requests from
+applications and then establishes/registers the corresponding listener
+which will receive information pushed by a publisher. In addition,
+YANGPUSH Provider also invokes an augmented OpenDaylight
+create-subscription RPC which enables applications to register for
+notification as per rfc5277. This augmentation adds periodic time period
+(duration) and subscription-id values to the existing RPC parameters.
+The Java package supporting this capability is
+“org.opendaylight.yangpush.impl”. YangpushDomProvider is the class which
+supports this YANGPUSH Provider capability.
+
+The YANGPUSH Listener accepts update notifications from a device after
+they have been de-encapsulated from the NETCONF transport. The YANGPUSH
+Listener then passes these updates to MD-SAL. This function is
+implemented via the YangpushDOMNotificationListener class within the
+“org.opendaylight.yangpush.listner” Java package. Applications should
+monitor MD-SAL for the availability of newly pushed subscription
+updates.
+
include::sfc/sfc.adoc[]
+include::snbi/odl-snbi-dev.adoc[]
+
include::snmp4sdn/snmp4sdn-developer.adoc[SNMP4SDN]
include::sxp/odl-sxp-dev.adoc[]
include::odl-ofp-message-spy.adoc[]
+include::odl-ofp-forwardingrules-sync.adoc[]
+
+include::odl-ofp-singleton-cluster-aproach.adoc[]
+
// * OpenDaylight_OpenFlow_Plugin:Backlog:Extensibility[Extensibility Framework]
include::odl-ofp-yang-models.adoc[]
--- /dev/null
+=== Application: Forwarding Rules Synchronizer
+
+==== Basics
+
+===== Description
+
+Forwarding Rules Synchronizer (FRS) is a newer version of Forwarding Rules Manager (FRM). It was created to solve most shortcomings of FRM. FRS solving errors with retry mechanism. Sending barrier if needed. Using one service for flows, groups and meters. And it has less changes requests send to device since calculating difference and using compression queue.
+
+It is located in the Java package:
+
+[source, java]
+----
+package org.opendaylight.openflowplugin.applications.frsync;
+----
+
+===== Listeners
+
+* 1x config - FlowCapableNode
+* 1x operational - Node
+
+===== System of work
+
+* one listener in config datastore waiting for changes
+
+** update cache
+** skip event if operational not present for node
+** send syncup entry to reactor for synchronization
+*** node added: after part of modification and whole operational snapshot
+*** node updated: after and before part of modification
+*** node deleted: null and before part of modification
+
+
+* one listener in operational datastore waiting for changes
+
+** update cache
+** on device connected
+*** register for cluster services
+** on device disconnected remove from cache
+*** remove from cache
+*** unregister for cluster services
+** if registered for reconciliation
+*** do reconciliation through syncup (only when config present)
+
+
+* reactor
+_(provides syncup w/decorators assembled in this order)_
+
+** Cluster decorator - skip action if not master for device
+** FutureZip decorator (FutureZip extends Future decorator)
+*** Future - run delegate syncup in future - submit task to executor service
+*** FutureZip - provides state compression - compress optimized config delta if waiting for execution with new one
+** Guard decorator - per device level locking
+** Retry decorator - register for reconciliation if syncup failed
+** Reactor impl - calculate diff from after/before parts of syncup entry and execute
+
+===== Strategy
+
+In the _old_ FRM uses an incremental strategy with all changes made one by one, where FRS uses a flat batch system with changes made in bulk. It uses one service SalFlatBatchService instead of three (flow, group, meter).
+
+===== Boron release
+
+FRS is used in Boron as separate feature and it is not loaded by any other feature. It has to be run separately.
+
+ odl-openflowplugin-app-forwardingrules-sync
+
+==== FRS additions
+
+===== Retry mechanism
+
+* is started when change request to device return as failed (register for reconcile)
+* wait for next consistent operational and do reconciliation with actual config (not only diff)
+
+===== ZipQueue
+
+* only the diff (before/after) between last config changes is sent to device
+* when there are more config changes for device in a row waiting to be processed they are compressed into one entry (after is still replaced with the latest)
+
+===== Cluster-aware
+
+* FRS is cluster aware using ClusteringSingletonServiceProvider from the MD-SAL
+* on mastership change reconciliation is done (register for reconcile)
+
+===== SalFlatBatchService
+
+FRS uses service with implemented barrier waiting logic between dependent objects
+
+==== SalFlatBatchService for FRS
+
+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.
+
+===== Workflow
+
+* prepare plan of actions
+** mark actions where the barrier is needed before continue
+* run appropriate service calls
+** start all actions that can be run simultaneously
+** if there is barrier-needed mark, wait for all fired jobs and only then continue with the next action
+
+error handling:
+
+* there is flag to stop process on the first error (default set to false)
--- /dev/null
+=== Cluster singleton approach in plugin
+
+==== Basics
+
+===== Description
+
+The existing OpenDaylight service deployment model assumes symmetric clusters, where all services are activated on all nodes in the cluster. However, many services require that there is a single active service instance per cluster. We call such services 'singleton services'. The Entity Ownership Service (EOS) represents the base Leadership choice for one Entity instance. Every Cluster Singleton service *type* must have its own Entity and every Cluster Singleton service *instance* must have its own Entity Candidate. Every registered Entity Candidate should be notified about its actual role. All this "work" is done by MD-SAL so the Openflowplugin need "only" to register as service in *SingletonClusteringServiceProvider* given by MD-SAL.
+
+===== Change against using EOS service listener
+
+In this new clustering singleton approach plugin uses API from the MD-SAL project: SingletonClusteringService which comes with three methods.
+
+ instantiateServiceInstance()
+ closeServiceInstance()
+ getIdentifier()
+
+This service has to be registered to a SingletonClusteringServiceProvider from MD-SAL which take care if mastership is changed in cluster environment.
+
+First method in SingletonClusteringService is being called when the cluster node becomes a MASTER. Second is being called when status changes to SLAVE or device is disconnected from cluster. Last method plugins returns NodeId as ServiceGroupIdentifier
+Startup after device is connected
+
+On the start up the plugin we need to initialize first four managers for each working area providing information and services
+
+* Device manager
+* RPC manager
+* Role manager
+* Statistics manager
+
+After connection the device the listener Device manager get the event and start up to creating the context for this connection.
+Startup after device connection
+
+Services are managed by SinlgetonClusteringServiceProvider from MD-SAL project. So in startup we simply create a instance of LifecycleService and register all contexts into it.
+
+==== Role change
+
+Plugin is no longer registered as Entity Ownership Service (EOS) listener therefore does not need to and cannot respond on EOS ownership changes.
+
+===== Service start
+
+Services start asynchronously but the start is managed by LifecycleService. If something goes wrong LifecycleService stop starting services in context and this speeds up the reconnect process. But the services haven't changed and plugin need to start all this:
+
+* Activating transaction chain manager
+* Initial gathering of device statistics
+* Initial submit to DS
+* Sending role MASTER to device
+* RPC services registration
+* Statistics gathering start
+
+===== Service stop
+
+If closeServiceInstance occurred plugin just simply try to store all unsubmitted transactions and close the transaction chain manager, stop RPC services, stop Statistics gathering and after that all unregister txEntity from EOS.
\ No newline at end of file
--- /dev/null
+== SNBI Developer Guide
+
+=== Overview
+Key distribution in a scaled network has always been a challenge. Typically, operators must perform some manual key distribution process before secure communication is possible between a set of network devices. The Secure Network Bootstrapping Infrastructure (SNBI) project securely and automatically brings up an integrated set of network devices and controllers, simplifying the process of bootstrapping network devices with the keys required for secure communication. SNBI enables connectivity to the network devices by assigning unique IPv6 addresses and bootstrapping devices with the required keys. Admission control of devices into a specific domain is achieved using whitelist of authorized devices.
+
+=== SNBI Architecture
+At a high level, SNBI architecture consists of the following components:
+
+* SNBI Registrar
+* SNBI Forwarding Element (FE)
+
+.SNBI Architecture Diagram
+image::snbi/snbi_arch.png["SNBI Architecture",width=500]
+
+==== SNBI Registrar
+Registrar is a device in a network that validates device against a whitelist and delivers device domain certificate. Registrar includes the following:
+
+* RESTCONF API for Domain Whitelist Configuration
+* Certificate Authority
+* SNBI Southbound Plugin
+
+.RESTCONF API for Domain Whitelist Configuration:
+RESTCONF APIs are used to configure the whitelist set device in the registrar in the controller. The registrar interacts with the MD-SAL to obtain the whitelist set of devices and validate the device trying to join a domain. Furthermore it is possible to run multiple registrar instances pertaining to each domain.
+
+.SNBI Southbound Plugin:
+The Southbound Plugin implements the protocol state machine necessary to exchange device identifiers, and deliver certificates. The southbound plugin interacts with MD-SAL and the certificate authority to validate and create device domain certificates. The device domain certificate thus generated could be used to prove the validity of the devices within the domain.
+
+.Certificate Authority:
+A simple certificate authority is implemented using the Bouncy Castle package. The Certificate Authority creates the certificates from the device CSR requests received from the devices. The certificates thus generated are delievered to the devices using the Southbound Plugin as discussed earlier.
+
+==== SNBI Forwarding Element (FE)
+The SNBI Forwarding Element runs on Linux machines which have to join the domain. The Device UDI(Universal Device Identifier) or the device identifier could be derived from a multitude of parameters in the host machine, but most of the parameters derived from the host are known ahead or doesn't remain constant across reloads. Therefore, each of the SNBI FE should be configured explicitly with a UDI that is already present in the device white list. The registrar service IP address must be provided to the first host (Forwarding Element) to be bootstrapped. As mentioned in the <<_host_configuration>> section, the registrar service IP address is *fd08::aaaa:bbbb:1*. The First Forwarding Element must be configured with this IPv6 address.
+
+The forwarding element must be installed or unpacked on a Linux host whose network layer traffic must be secured. The FE performs the following functions:
+
+* Neighour Discovery
+* Bootstrapping with device domain certificates
+* Host Configuration
+
+===== Neighbour Discovery
+Neighbour Discovery (ND) is the first step in accommodating devices in a secure network. SNBI performs periodic neighbour discovery of SNBI agents by transmitting ND hello packets. The discovered devices are populated in an ND table. Neighbour Discovery is periodic and bidirectional. ND hello packets are transmitted every 10 seconds. A 40 second refresh timer is set for each discovered neighbour. On expiry of the refresh timer, the Neighbour Adjacency is removed from the ND table as the Neighbour Adjacency is no longer valid. It is possible that the same SNBI neighbour is discovered on multiple links, the expiry of a device on one link does not automatically remove the device entry from the ND table. In the exchange of ND keepalives, the device UDI is exchanged.
+
+===== Bootstrapping with Device Domain Certificates
+Bootstrapping a device involves the following sequential steps:
+
+* Authenticate a device using device identifier (UDI-Universal Device Identifier or SUDI-Secure Universal Device Identifier) - The device
+identifier is exchanged in the hello messages.
+* Allocate the appropriate device ID and IPv6 address to uniquely identify the device in the network
+* Allocate the required keys by installing a Device Domain Certificate
+* Accommodate the device in the domain
+
+A device which is already bootstrapped acts as a proxy to bootstrap the new device which is trying to join the domain.
+
+* Neighbour Invite phase - When a proxy device detects a new neighbor bootStrap connect message is initiated on behalf of the New device --*NEIGHBOUR CONNECT* Msg. The message is sent to the registrar to authenticate the device UDI against the whitelist of devices. The source IPv6 address is the proxy IPv6 address and the destination IPv6 address is the registrar IPv6 address. The SNBI Registrar provides appropriate device ID and IPv6 address to uniquely identify the device in the network and then invites the device to join the domain. -- *NEIGHBOUR INVITE* Msg.
+
+* Neighbour Reject - If the Device UDI is not in the white list of devices, then the device is rejected and is not accepted into the domain. The proxy device just updates its DB with the reject information but still maintains the Neighbour relationship.
+
+* Neighbour BootStrap Phase - Once the new device gets a neighbour invite message, it tries to boot strap itself by generating a key pair. The device generates a Certificate Sign Request (CSR) PKCS10 request and gets it signed by the CA running at the SNBI Registrar. -- *BS REQ* Msg. Once the certificate is enrolled and signed by the CA, the generated x.509 certificate is returned to the new device to complete the bootstrap process. -- *BS RESP* Msg.
+
+==== Host Configuration
+Host configuration involves configuring a host to create a secure overlay network, assigning appropriate IPv6 address, setting up GRE tunnels, securing the tunnels traffic via IPsec and enabling connectivity via a routing protocol. Docker is used to package all the required dependent software modules.
+
+.SNBI Bootstrap Process
+image::snbi/first_fe_bs.png["SNBI Bootstrap Process", width=500]
+
+* Interace configuration: The Iproute2 package, which comes by default packaged in the Linux distributions, is used to configure the required interface (snbi-fe) and assign the appropriate IPv6 address.
+* GRE Tunnel Creation: LinkLocal GRE tunnels are created to each of the discovered devices that are part of the domain. The GRE tunnels are used to create the overlay network for the domain.
+* Routing over the Overlay: To enable reachability of devices within the overlay network a light weight routing protocol is used. The routing protocol of choice is the RPL (Routing Protocol for Low-Power and Lossy Networks) protocol. The routing protocol advertises the device domain IPv6 address over the overlay network. *Unstrung* is the open source implementation of RPL and is packaged within the docker image. More details on unstrung is available at http://unstrung.sandelman.ca/
+* IPsec: IPsec is used to secure any traffic routed over the tunnels. StrongSwan is used to encrypt traffic using IPsec. More details on StrongSwan is available at https://www.strongswan.org/
+
+==== Docker Image
+
+The SNBI Forwarding Element is packaged in a docker container available at this
+link: https://hub.docker.com/r/snbi/boron/.
+For more information on docker, refer to this link:
+https://docs.docker.com/linux/.
+
+To update an SNBI FE Daemon, build the image and copy the image to /home/snbi
+directory. When the docker image is run, it autoamtically generates a startup
+configuration file for the SNBI FE daemon. The startup configuration script is
+also available at /home/snbi.
+
+.SNBI Docker Image
+image::snbi/docker_snbi.png["SNBI Docker Image",width=500]
+
+
+=== Key APIs and Interfaces
+The only API that SNBI exposes is to configure the whitelist of devices for a domain.
+
+The POST method below configures a domain - "secure-domain" and configures a whitelist set of devices to be accommodated to the domain.
+----
+{
+ "snbi-domain": {
+ "domain-name": "secure-domain",
+ "device-list": [
+ {
+ "list-name": "demo list",
+ "list-type": "white",
+ "active": true,
+ "devices": [
+ {
+ "device-id": "UDI-FirstFE"
+ },
+ {
+ "device-id": "UDI-dev1"
+ },
+ {
+ "device-id": "UDI-dev2"
+ }
+ ]
+ }
+ ]
+ }
+}
+----
+The associated device ID must be configured on the SNBI FE (see above).
+
+
+=== API Reference Documentation
+
+See the generated RESTCONF API documentation at:
+http://localhost:8181/apidoc/explorer/index.html
+
+Look for the SNBI module to expand and see the various RESTCONF APIs.
-== Authentication and Authorization Services\r
-\r
-=== Authentication Service\r
-Authentication uses the credentials presented by a user to identify the user.\r
-\r
-NOTE: The Authentication user store provided in the Lithium release does not fully support a clustered node deployment. Specifically, the AAA user store provided by the H2 database needs to be synchronized using out of band means. The AAA Token cache is however cluster-capable.\r
-\r
-==== Authentication data model\r
-A user requests authentication within a domain in which the user has defined roles.\r
-The user chooses either of the following ways to request authentication:\r
-\r
-* Provides credentials\r
-* Creates a token scoped to a domain. In OpenDaylight, a domain is a grouping of resources (direct or indirect, physical, logical, or virtual) for the purpose of access control.\r
-\r
-===== Terms and definitions in the model\r
-Token:: A claim of access to a group of resources on the controller\r
-Domain:: A group of resources, direct or indirect, physical, logical, or virtual, for the purpose of access control\r
-User:: A person who either owns or has access to a resource or group of resources on the controller\r
-Role:: Opaque representation of a set of permissions, which is merely a unique string as admin or guest\r
-Credential:: Proof of identity such as username and password, OTP, biometrics, or others\r
-Client:: A service or application that requires access to the controller\r
-Claim:: A data set of validated assertions regarding a user, e.g. the role, domain, name, etc.\r
-\r
-===== Authentication methods\r
-There are three ways a user may authenticate in OpenDaylight: +\r
-\r
-* Basic HTTP Authentication\r
-** Regular, non-token based, authentication with username/password.\r
-* Token-based Authentication\r
-** Direct authentication: A user presents username/password and a domain the user wishes to access to the controller and obtains a timed (default is 1 hour) scoped access token. The user then uses this token to access RESTCONF (for example).\r
-** Federated authentication: A user presents credentials to a third-party Identity Provider (for example, SSSD) trusted by the controller. Upon successful authentication, the controller returns a refresh (unscoped) token with a list of domains that the user has access to. The user then presents this refresh token scoped to a domain that the user has access to obtain a scoped access token. The user then uses this access token to access RESTCONF (for example).\r
-\r
-\r
-====== Example with token authentication using curl:\r
-\r
-(username/password = admin/admin, domain = sdn)\r
-\r
-[source,bash] \r
-----\r
-# Create a token\r
-curl -ik -d 'grant_type=password&username=admin&password=admin&scope=sdn' http://localhost:8181/oauth2/token\r
-\r
-# Use the token (e.g., ed3e5e05-b5e7-3865-9f63-eb8ed5c87fb9) obtained from above (default token validity is 1 hour):\r
-curl -ik -H 'Authorization:Bearer ed3e5e05-b5e7-3865-9f63-eb8ed5c87fb9' http://localhost:8181/restconf/config/toaster:toaster\r
-----\r
-\r
-====== Example with basic HTTP auth using curl: +\r
-\r
-[source,bash] \r
----- \r
-curl -ik -u 'admin:admin' http://localhost:8181/restconf/config/toaster:toaster\r
-----\r
-\r
-==== How the OpenDaylight Authentication Service works\r
-In direct authentication, a service relationship exists between the user and the OpenDaylight controller. The user and the controller establish trust that allows them to use, and validate credentials.\r
-The user establishes user identity through credentials.\r
-\r
-In direct authentication, a user request progresses through the following steps:\r
-\r
-. The user requests the controller administrator for a user account. \r
-+\r
-:: Associated with the user account are user credentials, initially created by the administrator. OpenDaylight supports only username/password credentials. By default, an administrator account is present in OpenDaylight out-of-the-box with the default username and password being admin/admin. \r
-In addition to creating the user account, the controller administrator also assigns roles to that account on one or more domain. By default, there are two user roles; admin, and user, and there is only one domain; sdn.\r
-+\r
-. The user presents credentials in a token request to the token service within a domain. \r
-. The request is then passed on to the controller token endpoint.\r
-. The controller token endpoint uses the credential authentication entity which returns a claim for the client. \r
-. The controller token entity transforms the claim (user, domain, and roles) into a token which it then provides to the user.\r
-\r
-In federated authentication, with the absence of a direct trust relationship between the user and the service, a third-party Identity Provider (IdP) is used for authentication. Federated authentication relies on third-party identity providers (IdP) to authenticate the user.\r
-\r
-The user is authenticated by the trusted IdP and a claim is returned to the OpenDaylight authentication service. The claim is transformed into an OpenDaylight claim and successively into a token that is passed on to the user. \r
-\r
-In a federated authentication set-up, the OpenDaylight controller AAA module provides SSSD claim support. SSSD can be used to map users in an external LDAP server to users defined on the OpenDaylight controller.\r
-\r
-==== Configuring Authentication service\r
-Changes to AAA configurations can be made as follows:\r
-\r
-For Authentication functionality via one of:\r
-\r
-* Webconsole\r
-* CLI (config command in the Karaf shell)\r
-* Editing the etc/org.opendaylight.aaa.*.cfg files directly\r
-\r
-For Token Cache Store settings via one of:\r
-\r
-* Editing the 08-authn-config.xml configuration file in etc/opendaylight/karaf\r
-* Using RESTCONF\r
-\r
-NOTE: Configurations for AAA are all dynamic and require no restart.\r
-\r
-===== Configuring Authentication\r
-\r
-To configure features from the Web console: +\r
-\r
-. Install the Web console:\r
-+\r
-----\r
-feature:install webconsole\r
-----\r
-+\r
-. On the console (http://localhost:8181/system/console) (default Karaf username/password: karaf/karaf), go to *OSGi* > *Configuration* > *OpenDaylight AAA Authentication Configuration*.\r
-.. *Authorized Clients*: List of software clients that are authorized to access OpenDaylight northbound APIs.\r
-.. *Enable Authentication*: Enable or disable authentication. (The default is enable.)\r
-\r
-===== Configuring the token store\r
-. Open in a text editor etc/opendaylight/karaf/08-authn-config.xml\r
-:: The fields you can configure are as follows:\r
-.. *timeToLive*: Configure the maximum time, in milliseconds, that tokens are to be cached. Default is 360000.\r
-. Save the file.\r
-\r
-NOTE: When token's are expired, they are lazily removed from the cache.\r
-\r
-===== Configuring AAA federation\r
-\r
-. On the console, click *OpenDaylight AAA Federation Configuration*.\r
-. Use the *Custom HTTP Headers* or *Custom HTTP Attributes* fields to specify the HTTP headers or attributes for federated authentication. Normally, additional specification beyond the default is not \r
-required.\r
-\r
-NOTE: As the changes you make to the configurations are automatically committed when they are saved, no restart of the Authentication service is required.\r
-\r
-====== Configuring federated authentication\r
-Use the following steps to set up federated authentication: +\r
-\r
-. Set up an Apache front-end and Apache mods for the OpenDaylight controller.\r
-. Set up mapping rules (from LDAP users to OpenDaylight users).\r
-. Use the ClaimAuthFilter in federation to allow claim transformation.\r
-\r
-====== Mapping users to roles and domains\r
-The OpenDaylight authentication service transforms assertions from an external federated IdP into Authentication Service data: +\r
-\r
-. The Apache web server which fronts OpenDaylight AAA sends data to SssdAuthFilter.\r
-. SssdAuthFilter constructs a JSON document from the data.\r
-. OpenDaylight Authentication Service uses a general purpose transformation mapper to transform the JSON document.\r
-\r
-====== Operational model\r
-The mapping model works as follows: +\r
-\r
-. Assertions from an IdP are stored in an associative array.\r
-. A sequence of rules is applied, and the first rule which returns success is considered a match.\r
-. Upon success, an associative array of mapped values is returned.\r
-\r
-** The mapped values are taken from the local variables set during the rule execution.\r
-** The definition of the rules and mapped results are expressed in JSON notation.\r
-\r
-====== Operational Model: Sample code\r
-[source,java]\r
-----\r
-mapped = null\r
-foreach rule in rules {\r
- result = null\r
- initialize rule.variables with pre-defined values\r
-\r
- foreach block in rule.statement_blocks {\r
- for statement in block.statements {\r
- if statement.verb is exit {\r
- result = exit.status\r
- break\r
- }\r
- elif statement.verb is continue {\r
- break\r
- }\r
- }\r
- if result {\r
- break\r
- }\r
- if result == null {\r
- result = success\r
- }\r
-if result == success {\r
- mapped = rule.mapping(rule.variables)\r
-}\r
-return mapped\r
-----\r
-\r
-====== Mapping Users\r
-A JSON Object acts as a mapping template to produce the final associative array of name/value pairs. The value in a name/value pair can be a constant or a variable.\r
-An example of a mapping template and rule variables in JSON: +\r
-Template: +\r
-[source,json]\r
-----\r
-{\r
- "organization": "BigCorp.com",\r
- "user: "$subject",\r
- "roles": "$roles"\r
-}\r
-----\r
-Local variables: +\r
-[source,json]\r
-----\r
-{\r
- "subject": "Sally",\r
- "roles": ["user", "admin"]\r
-}\r
-----\r
-The final mapped result will be: +\r
-[source,json]\r
-----\r
-{\r
- "organization": "BigCorp.com",\r
- "user: "Sally",\r
- "roles": ["user", "admin"]\r
-}\r
-----\r
-\r
-====== Example: Splitting a fully qualified username into user and realm components\r
-Some IdPs return a fully qualified username (for example, principal or subject). The fully qualified username is the concatenation of the user name, separator, and realm name.\r
-The following example shows the mapped result that returns the user and realm as independent values for the fully qualified username is bob@example.com .\r
-\r
-The mapping in JSON: +\r
-[source,json]\r
-----\r
-{\r
- "user": "$username",\r
- "realm": "$domain"\r
-}\r
-----\r
-The assertion in JSON: +\r
-[source,json]\r
-----\r
-{\r
- "Principal": "bob@example.com"\r
-}\r
-----\r
-The rule applied: +\r
-[source,json]\r
-----\r
-[\r
- [\r
- ["in", "Principal", "assertion"],\r
- ["exit", "rule_fails", "if_not_success"],\r
- ["regexp", "$assertion[Principal]", (?P<username>\\w+)@(?P<domain>.+)"],\r
- ["set", "$username", "$regexp_map[username]"],\r
- ["set", "$domain", "$regexp_map[domain]"],\r
- ["exit, "rule_succeeds", "always"]\r
- ]\r
-]\r
-----\r
-The mapped result in JSON: +\r
-[source,json]\r
-----\r
-{\r
- "user": "bob",\r
- "realm": "example.com"\r
-}\r
-----\r
-Also, users may be granted roles based on their membership in certain groups.\r
-\r
-The Authentication Service allows white lists for users with specific roles. The white lists ensure that users are unconditionally accepted and authorized with specific roles. Users who must be unconditionally denied access can be placed in a black list.\r
-\r
-=== Administering OpenDaylight Authentication Services\r
-\r
-==== Actors in the System\r
-*OpenDaylight Controller administrator* +\r
-The OpenDaylight Controller administrator has the following responsibilities:\r
-\r
-* Author Authentication policies using the IdmLight Service API\r
-* Provides credentials, usernames and passwords to users who request them\r
-\r
-*OpenDaylight resource owners* +\r
-Resource owners authenticate (either by means of federation or directly providing their own credentials to the controller) to obtain an access token. This access token can then be used to access resources on the controller.\r
-An OpenDaylight resource owner enjoys the following privileges:\r
-\r
-* Creates, refreshes, or deletes access tokens\r
-* Gets access tokens from the Secure Token Service\r
-* Passes secure tokens to resource users\r
-\r
-*OpenDaylight resource users* +\r
-Resource users do not need to authenticate: they can access resources if they are given an access tokens by the resource owner. The default timeout for access tokens is 1 hour (This duration is configurable.).\r
-An OpenDaylight resource user does the following:\r
-\r
-* Gets access tokens either from a resource owner or the controller administrator\r
-* Uses tokens at access applications from the north-bound APIs\r
-\r
-==== System Components\r
-IdmLight Identity manager:: Stores local user authentication and authorization data, provides an Admin REST API for CRUD operations.\r
-Pluggable authenticators:: Provides domain-specific authentication mechanisms\r
-Authenticator:: Authenticates users against and establishes claims\r
-Authentication Cache:: Caches all authentication states and tokens\r
-Authentication Filter:: Verifies tokens and extracts claims\r
-Authentication Manager:: Contains the session token and authentication claim store\r
-\r
-\r
-===== IdmLight Identity manager\r
-The Light-weight Identity Manager (IdmLight) Stores local user authentication and authorization data, and roles and provides an Admin REST API for CRUD operations on the users/roles/domains database.\r
-The IdmLight REST API is by default accessed via the {controller baseURI:8181}/auth/v1/ API end point. \r
-Access to the API is restricted to authenticated clients only, or those possessing a token:\r
-\r
-Example: To retrieve the users list.\r
-\r
-[source,bash] \r
----- \r
-curl http://admin:admin@localhost:8181/auth/v1/users\r
-----\r
-\r
-\r
-The following document contains a detailed list of supported CRUD operations allowed by the API:\r
-\r
- https://wiki.opendaylight.org/images/a/ad/AAA_Idmlight_REST_APIs.xlsx\r
-\r
-\r
-=== OpenDaylight Authorization Service\r
-The authorization service currently included in OpenDaylight is of an experimental kind and only briefly documented here. \r
-Authorization follows successful authentication and is modeled on the Role Based Access Control (RBAC) approach for defining permissions and decide access levels to API resources on the controller.\r
-\r
+== 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
== ALTO User Guide ==
-=== Overview ===
-
-The ALTO project is aimed to provide support for *Application Layer
-Traffic Optimization* services defined in
-https://tools.ietf.org/html/rfc7285[RFC 7285] in OpenDaylight.
-
-This user guide will introduce the three basic services (namely
-`simple-ird`, `manual-maps` and `host-tracker`) which are implemented since
-the Beryllium release, and give instructions on how to configure them to
-provide corresponding ALTO services.
-
-A new feature named `simple-pce` (**Simple Path Computation Engine**) is
-added into Boron release as an ALTO extension service.
-
-=== How to Identify ALTO Resources ===
-
-Each ALTO resource can be uniquely identified by a tuple . For each
-resource, a _version-tag_ is used to support historical look-ups.
-
-The formats of _resource-id_ and _version-tag_ are defined in
-https://tools.ietf.org/html/rfc7285#section-10.2[section 10.2] and
-https://tools.ietf.org/html/rfc7285#section-10.3[section 10.3]
-respectively. The _context-id_ is not part of the protocol and we choose
-the same format as a _universal unique identifier_ (UUID) which is
-defined in http://tools.ietf.org/html/rfc4122[RFC 4122].
-
-A context is like a namespace for ALTO resources, which eliminates
-_resource-id_ collisions. For simplicity, we also provide a default
-context with the id **000000000000-0000-0000-0000-00000000**.
-
-=== How to Use Simple IRD ===
-
-The simple IRD feature provides a simple _information resource
-directory_ (IRD) service defined in
-https://tools.ietf.org/html/rfc7285#section-9[RFC 7285].
-
-==== Install the Feature ====
-
-To enable simple IRD, run the following command in the karaf CLI:
-
-[source,bash]
-karaf > feature:install odl-alto-simpleird
-
-After the feature is successfully installed, a special context will be
-created for all simple IRD resources. The id for this context can be
-seen by executing the following command in a terminal:
-
-[source,bash]
-curl -X GET -u admin:admin http://localhost:8181/restconf/operational/alto-simple-ird:information/
-
-==== Create a new IRD ====
-
-To create a new IRD resource, two fields MUST be provided:
-
-* Field **instance-id**: the _resource-id_ of the IRD resource;
-* Field **entry-context**: the context-id for non-IRD entries managed by
-this IRD resource.
-
-Using the following script, one can create an empty IRD resource:
-
-[source,bash]
-#!/bin/bash
-# filename: ird-create
-INSTANCE_ID=$1
-if [ $2 ]; then
- CONTEXT_ID=$2
-else
- CONTEXT_ID="00000000-0000-0000-0000-000000000000"
-fi
-URL="`http://localhost:8181/restconf/config/alto-simple-ird:ird-instance-configuration/"$INSTANCE_ID"/[`http://localhost:8181/restconf/config/alto-simple-ird:ird-instance-configuration/"$INSTANCE_ID"/`]`"
-DATA=$(cat template \
- | sed 's/\$1/'$CONTEXT_ID'/g' \
- | sed 's/\$2/'$INSTANCE_ID'/g')
-curl -4 -D - -X PUT -u admin:admin \
- -H "Content-Type: application/json" -d "$(echo $DATA)"\
- $URL
-
-For example, the following command will create a new IRD named _ird_
-which can accept entries with the default context-id:
-
-[source,bash]
-$ ./ird-create ird 000000000000-0000-0000-0000-00000000
-
-And below is the what the template file looks like:
-
-[source,json]
-{
- "ird-instance-configuration": {
- "entry-context": "/alto-resourcepool:context[alto-resourcepool:context-id='$1']",
- "instance-id": "$2"
- }
-}
-
-==== Remove an IRD ====
-
-To remove an existing IRD (and all the entries in it), one can use the
-following command in a terminal:
-
-[source,bash]
-curl -X DELETE -u admin:admin http://localhost:8181/restconf/config/alto-simple-ird:ird-instance-configuration/$INSTANCE_ID
-
-==== Add a new entry ====
-
-There are several ways to add entries to an IRD and in this section we
-introduce only the simplest method. Using the following script, one can
-add a new entry to the target IRD.
-
-For each new entry, four parameters MUST be provided:
-
-* Parameter __ird-id__: the _resource-id_ of the target IRD;
-* Parameter __entry-id__: the _resource-id_ of the ALTO service to be
-added;
-* Parameter __context-id__: the _context-id_ of the ALTO service to be
-added, which MUST be identical to the target IRD's __entry-context__;
-* Parameter __location__: either a URI or a relative path to the ALTO
-service.
-
-The following script can be used to add one entry to the target IRD,
-where the relative path is used:
-
-[source,bash]
-#!/bin/bash
-# filename: ird-add-entry
-IRD_ID=$1
-ENTRY_ID=$2
-CONTEXT_ID=$3
-BASE_URL=$4
-URL="`http://localhost:8181/restconf/config/alto-simple-ird:ird-instance-configuration/"$IRD_ID"/ird-configuration-entry/"$ENTRY_ID"/"
-DATA=$(cat template \
- | sed 's/\$1/'$ENTRY_ID'/g' \
- | sed 's/\$2/'$CONTEXT_ID'/g' \
- | sed 's/\$3/'$BASE_URL'/g' )
-curl -4 -D - -X PUT -u admin:admin \
- -H "Content-Type: application/json" -d "$(echo $DATA)" \
- $URL
-
-For example, the following command will add a new resource named
-__networkmap__, whose context-id is the default context-id and the base
-URL is /alto/networkmap, to the IRD named __ird__:
-
-[source,bash]
-$ ./ird-add-entry ird networkmap 000000000000-0000-0000-0000-00000000 /alto/networkmap
-
-And below is the template file:
-
-[source,json]
-{
- "ird-configuration-entry": {
- "entry-id": "$1",
- "instance": "/alto-resourcepool:context[alto-resourcepool:context-id='$2']/alto-resourcepool:resource[alto-resourcepool:resource-id='$1']",
- "path": "$3/$1"
- }
-}
-
-==== Remove an entry ====
-
-To remove an entry from an IRD, one can use the following one-line
-command:
-
-[source,bash]
-curl -X DELETE -u admin:admin http://localhost:8181/restconf/config/alto-simple-ird:ird-instance-configuration/$IRD_ID/ird-configuration-entry/$ENTRY_ID/
-
-=== How to Use Host-tracker-based ECS ===
-
-As a real instance of ALTO services, *_alto-hosttracker_* reads data
-from *_l2switch_* and generates a network map with resource id
-*_hosttracker-network-map_* and a cost map with resource id
-*_hostracker-cost-map_*. It can only work with OpenFlow-enabled
-networks.
-
-After installing the *_odl-alto-hosttracker_* feature, the corresponding
-network map and cost map will be inserted into the data store.
-
-=== Managing Resource with `alto-resourcepool` ===
-
-After installing `odl-alto-release` feature in Karaf, `alto-resourcepool` feature
-will be installed automatically. And you can manage all resources in ALTO via
-RESTCONF APIs provided by `alto-resourcepool`.
-
-With the example bash script below you can get any resource infomation in a
-given context.
-
-[source,bash]
-#!/bin/bash
-RESOURCE_ID=$1
-if [ $2 ] ; then
- CONTEXT_ID=$2
-else
- CONTEXT_ID="00000000-0000-0000-0000-000000000000"
-fi
-URL="http://localhost:8181/restconf/operational/alto-resourcepool:context/"$CONTEXT_ID"/alto-resourcepool:resource/"$RESOURCE_ID
-curl -X GET -u admin:admin $URL | python -m json.tool | sed -n '/default-tag/p' | sed 's/.*:.*\"\(.*\)\".*/\1/g'
-
-=== Manual Configuration ===
-
-==== Using RESTCONF API ====
-
-After installing `odl-alto-release` feature in Karaf, it is possible to manage
-network-maps and cost-maps using RESTCONF. Take a look at all the operations
-provided by `resource-config` at the API service page which can be found at
-`http://localhost:8181/apidoc/explorer/index.html`.
-
-The easiest method to operate network-maps and cost-maps is to modify data broker
-via RESTCONF API directly.
-
-==== Using RPC ====
-
-The `resource-config` package also provides a query RPC to config the resources.
-You can CREATE, UPDATE and DELETE *network-maps* and *cost-maps* via query RPC.
-
-=== Simple Path Computation Engine ===
-
-The `simple-pce` module provides a simple path computation engine for ALTO and other
-projects. It supports basic CRUD (create, read, update, delete) operations to manage
-L2 and L3 routing with/without rate limitation. This module is an independent
-feature, so you can follow the instruction below to install it independently.
-
-[source,bash]
-karaf > feature:install odl-alto-extenstion
-
-NOTE: The rate limitation meter requires OpenFlow 1.3 support.
-
-==== Basic Usage with RESTCONF API ====
-
-You can use the simple path computation engine with RESTCONF API, which is defined
-in the YANG model https://git.opendaylight.org/gerrit/gitweb?p=alto.git;a=blob;f=alto-extensions/simple-pce/api/src/main/yang/alto-spce.yang;h=f5bbe6744f7dfba493edd275aa18114e363727ab;hb=refs/heads/stable/boron[here].
-
-=== Use Case ===
-
-==== Server Selection ====
-
-One of the key use case for ALTO is server selection. For example, a client (with
-IP address 10.0.0.1) sends a data transferring request to Data Transferring Service
-(DTS). And there are three data replica servers (with IP address 10.60.0.1, 10.60.0.2
-and 10.60.0.3) which can response the request. In this case, DTS can send a query
-request to ALTO server to make server selection decision.
-
-Following is an example ALTO query:
-
-[source]
-POST /alto/endpointcost HTTP/1.1
-Host: localhost:8080
-Content-Type: application/alto-endpointcostparams+json
-Accept: application/alto-endpointcost+json,application/alto-error+json
-{
- "cost-type": {
- "cost-mode": "ordinal",
- "cost-metric": "hopcount"
- },
- "endpoints": {
- "srcs": [ "ipv4:10.0.0.1" ],
- "dsts": [
- "ipv4:10.60.0.1",
- "ipv4:10.60.0.2",
- "ipv4:10.60.0.3"
- ]
- }
-}
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/alto-user-guide.html
include::lfm/lispflowmapping-msmr-user.adoc[LISP flow mapping]
-include::nemo/odl-nemo-engine-user.adoc[NEMO]
-
include::controller/netconf/odl-netconf-user.adoc[]
include::netide/odl-netide-user-guide.adoc[NetIDE]
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::yangide/yangide-user.adoc[]
include::yang-push/odl-yang-push-user.adoc[YANG-PUSH]
+
+include::genius/genius-user-guide.adoc[Genius]
--- /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
-== NEtwork MOdeling (NEMO)
-This section describes how to use the NEMO feature in OpenDaylight
-and contains contains configuration, administration, and management
-sections for the feature.
-
-=== Overview
-TBD: An overview of the NEMO feature and the use case and the
-audience who will use the feature.
-
-=== NEMO Engine Architecture
-TBD: Information about NEMO Engine components and how they work together.
-Also include information about how the feature integrates with
-OpenDaylight.
-
-=== Configuring NEMO Engine
-TBD: Describe how to configure the NEMO Engine after installation.
-
-=== Administering or Managing NEMO Engine
-TBD: Include related command reference or operations
-for using the NEMO Engine.
-
-=== Tutorials
-Below are tutorials for NEMO Engine.
-
-==== Using NEMO Engine
-TBD: State the purpose of tutorial
-
-===== Overview
-TBD: An overview of the NEMO tutorial
-
-===== Prerequisites
-TBD: Provide any prerequisite information, assumed knowledge, or environment
-required to execute the use case.
-
-===== Target Environment
-TBD: Include any topology requirement for the use case.
-
-===== Instructions
-TBD: Step by step procedure for using NEMO Engine.
[source,xml]
------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<flow
+<flow
xmlns="urn:opendaylight:flow:inventory">
<flow-name>push-mpls-action</flow-name>
<instructions>
[source,xml]
------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<flow
+<flow
xmlns="urn:opendaylight:flow:inventory">
<flow-name>push-mpls-action</flow-name>
<instructions>
[source,xml]
------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<flow
+<flow
xmlns="urn:opendaylight:flow:inventory">
<flow-name>FooXf10</flow-name>
<instructions>
<table_id>0</table_id>
</flow>
------------------------------------------------------------------------
+
+[[learn]]
+====== Learn
+* Nicira extension defined in https://github.com/osrg/openvswitch/blob/master/include/openflow/nicira-ext.h
+* Example section is - https://github.com/osrg/openvswitch/blob/master/include/openflow/nicira-ext.h#L788
+
+[source,xml]
+------------------------------------------------------------------------
+<flow>
+ <id>ICMP_Ingress258a5a5ad-08a8-4ff7-98f5-ef0b96ca3bb8</id>
+ <hard-timeout>0</hard-timeout>
+ <idle-timeout>0</idle-timeout>
+ <match>
+ <ethernet-match>
+ <ethernet-type>
+ <type>2048</type>
+ </ethernet-type>
+ </ethernet-match>
+ <metadata>
+ <metadata>2199023255552</metadata>
+ <metadata-mask>2305841909702066176</metadata-mask>
+ </metadata>
+ <ip-match>
+ <ip-protocol>1</ip-protocol>
+ </ip-match>
+ </match>
+ <cookie>110100480</cookie>
+ <instructions>
+ <instruction>
+ <order>0</order>
+ <apply-actions>
+ <action>
+ <order>1</order>
+ <nx-resubmit
+ xmlns="urn:opendaylight:openflowplugin:extension:nicira:action">
+ <table>220</table>
+ </nx-resubmit>
+ </action>
+ <action>
+ <order>0</order>
+ <nx-learn
+ xmlns="urn:opendaylight:openflowplugin:extension:nicira:action">
+ <idle-timeout>60</idle-timeout>
+ <fin-idle-timeout>0</fin-idle-timeout>
+ <hard-timeout>60</hard-timeout>
+ <flags>0</flags>
+ <table-id>41</table-id>
+ <priority>61010</priority>
+ <fin-hard-timeout>0</fin-hard-timeout>
+ <flow-mods>
+ <flow-mod-add-match-from-value>
+ <src-ofs>0</src-ofs>
+ <value>2048</value>
+ <src-field>1538</src-field>
+ <flow-mod-num-bits>16</flow-mod-num-bits>
+ </flow-mod-add-match-from-value>
+ </flow-mods>
+ <flow-mods>
+ <flow-mod-add-match-from-field>
+ <src-ofs>0</src-ofs>
+ <dst-ofs>0</dst-ofs>
+ <dst-field>4100</dst-field>
+ <src-field>3588</src-field>
+ <flow-mod-num-bits>32</flow-mod-num-bits>
+ </flow-mod-add-match-from-field>
+ </flow-mods>
+ <flow-mods>
+ <flow-mod-add-match-from-field>
+ <src-ofs>0</src-ofs>
+ <dst-ofs>0</dst-ofs>
+ <dst-field>518</dst-field>
+ <src-field>1030</src-field>
+ <flow-mod-num-bits>48</flow-mod-num-bits>
+ </flow-mod-add-match-from-field>
+ </flow-mods>
+ <flow-mods>
+ <flow-mod-add-match-from-field>
+ <src-ofs>0</src-ofs>
+ <dst-ofs>0</dst-ofs>
+ <dst-field>3073</dst-field>
+ <src-field>3073</src-field>
+ <flow-mod-num-bits>8</flow-mod-num-bits>
+ </flow-mod-add-match-from-field>
+ </flow-mods>
+ <flow-mods>
+ <flow-mod-copy-value-into-field>
+ <dst-ofs>0</dst-ofs>
+ <value>1</value>
+ <dst-field>65540</dst-field>
+ <flow-mod-num-bits>8</flow-mod-num-bits>
+ </flow-mod-copy-value-into-field>
+ </flow-mods>
+ <cookie>110100480</cookie>
+ </nx-learn>
+ </action>
+ </apply-actions>
+ </instruction>
+ </instructions>
+ <installHw>true</installHw>
+ <barrier>false</barrier>
+ <strict>false</strict>
+ <priority>61010</priority>
+ <table_id>253</table_id>
+ <flow-name>ACL</flow-name>
+</flow>
+------------------------------------------------------------------------
--- /dev/null
+== SNBI User Guide
+
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/snbi-user-guide.html
== YANG-PUSH
-This section describes how to use the YANG-PUSH feature in OpenDaylight
-and contains contains configuration, administration, and management
-sections for the feature.
-=== Overview
-YANG PUBSUB project allows applications to place subscriptions upon targeted subtrees of YANG datastores residing on remote devices. Changes in YANG objects within the remote subtree can be pushed to an OpenDaylight MD-SAL and to the application as specified without a requiring the controller to make a continuous set of fetch requests.
-
-==== YANG-PUSH capabilities available
-
-This module contains the base code which embodies the intent of YANG-PUSH requirements for subscription as defined in {i2rs-pub-sub-requirements} [https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/]. The mechanism for delivering on these YANG-PUSH requirements over Netconf transport is defined in {netconf-yang-push} [netconf-yang-push: https://tools.ietf.org/html/draft-ietf-netconf-yang-push-00].
-
-Note that in the current release, not all capabilities of draft-ietf-netconf-yang-push are realized. Currently only implemented is *create-subscription* RPC support from ietf-datastore-push@2015-10-15.yang; and this will be for periodic subscriptions only. There of course is intent to provide much additional functionality in future OpenDaylight releases.
-
-==== Future YANG-PUSH capabilities
-
-Over time, the intent is to flesh out more robust capabilities which will allow OpenDaylight applications to subscribe to YANG-PUSH compliant devices. Capabilities for future releases will include:
-
-Support for subscription change/delete:
-*modify-subscription* rpc support for all mountpoint devices or particular mountpoint device
-*delete-subscription* rpc support for all mountpoint devices or particular mountpoint device
-
-Support for static subscriptions:
-This will enable the receipt of subscription updates pushed from publishing devices where no signaling from the controller has been used to establish the subscriptions.
-
-Support for additional transports:
-NETCONF is not the only transport of interest to OpenDaylight or the subscribed devices. Over time this code will support Restconf and HTTP/2 transport requirements defined in {netconf-restconf-yang-push} [https://tools.ietf.org/html/draft-voit-netconf-restconf-yang-push-01]
-
-
-=== YANG-PUSH Architecture
-The code architecture of Yang push consists of two main elements
-
-YANGPUSH Provider
-YANGPUSH Listener
-
-YANGPUSH Provider receives create-subscription requests from applications and then establishes/registers the corresponding listener which will receive information pushed by a publisher. In addition, YANGPUSH Provider also invokes an augmented OpenDaylight create-subscription RPC which enables applications to register for notification as per rfc5277. This augmentation adds periodic time period (duration) and subscription-id values to the existing RPC parameters. The Java package supporting this capability is “org.opendaylight.yangpush.impl”. YangpushDomProvider is the class which supports this YANGPUSH Provider capability.
-
-The YANGPUSH Listener accepts update notifications from a device after they have been de-encapsulated from the NETCONF transport. The YANGPUSH Listener then passes these updates to MD-SAL. This function is implemented via the YangpushDOMNotificationListener class within the “org.opendaylight.yangpush.listner” Java package. Applications should monitor MD-SAL for the availability of newly pushed subscription updates.
-
-=== YANG-PUSH Catalog
-The NF Catalog contains metadata describing a NF.
-
-==== Configuring YANG-PUSH Catalog
-TBD: Describe how to configure YANG-PUSH Catalog after installation.
-
-==== Administering YANG-PUSH Catalog
-TBD: Include related command reference or operations
-for using YANG-PUSH Catalog.
-
-=== YANG-PUSH Workload Manager
-The Workload Manager defines RPCs to manage instances.
-
-=== Configuring YANG-PUSH Workload Manager
-TBD: Describe how to configure YANG-PUSH Workload Manager after installation.
-
-=== Administering YANG-PUSH Workload Manager
-TBD: Include related command reference or operations
-for using YANG-PUSH Workload Manager.
-
-=== Tutorials
-Below are tutorials for YANG-PUSH.
-
-==== Using YANG-PUSH Catalog
-TBD: State the purpose of tutorial
-
-===== Overview
-TBD: An overview of the YANG-PUSH Catalog tutorial
-
-===== Prerequisites
-TBD: Provide any prerequisite information, assumed knowledge, or environment
-required to execute the use case.
-
-===== Target Environment
-There are no topology requirement for using YANG-PUSH. A single node able interact as per https://tools.ietf.org/html/draft-ietf-netconf-yang-push-00 is sufficient to use this capability.
-
-===== Instructions
-TBD: Step by step procedure for using YANG-PUSH Catalog.
-
-==== Using YANG-PUSH Workload Manager
-TBD: State the purpose of tutorial
-
-===== Overview
-TBD: An overview of the YANG-PUSH Workload Manager tutorial
-
-===== Prerequisites
-TBD: Provide any prerequisite information, assumed knowledge, or environment
-required to execute the use case.
-
-===== Target Environment
-TBD: Include any topology requirement for the use case.
-
-===== Instructions
-TBD: Step by step procedure for using YANG-PUSH Workload Manager.
\ No newline at end of file
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/yang-push.html
Code Review / docs.git / commitdiff
