&issuetype=10104
&components=10228
&priority=2
-&description=version:+{{version}}%0Apage:+{{pagename}}%0A%0A">
+&description=version:+{{version}}%0Apage:+{{pagename}}%0A%0A" target="_blank">
Report Issue
</a>
</div>
# Append to intersphinx_mapping
intersphinx_mapping['mdsal'] = ('https://docs.opendaylight.org/projects/mdsal/en/latest/', None)
intersphinx_mapping['odl-integration-test'] = ('https://docs.opendaylight.org/projects/integration-test/en/latest/', None)
-intersphinx_mapping['odl-integration-distribution'] = ('https://docs.opendaylight.org/projects/integration-distribution/en/latest/', None)
intersphinx_mapping['odl-integration-packaging'] = ('https://docs.opendaylight.org/projects/integration-packaging/en/latest/', None)
intersphinx_mapping['odl-releng-builder'] = ('https://docs.opendaylight.org/projects/releng-builder/en/latest/', None)
+intersphinx_mapping['opflex'] = ('https://docs.opendaylight.org/projects/opflex/en/latest/', None)
# Projects that have stable/branches
+intersphinx_mapping['aaa'] = ('https://docs.opendaylight.org/projects/aaa/en/latest/', None)
+intersphinx_mapping['bgpcep'] = ('https://docs.opendaylight.org/projects/bgpcep/en/latest/', None)
intersphinx_mapping['coe'] = ('https://docs.opendaylight.org/projects/coe/en/latest/', None)
+intersphinx_mapping['controller'] = ('https://docs.opendaylight.org/projects/controller/en/latest/', None)
+intersphinx_mapping['daexim'] = ('https://docs.opendaylight.org/projects/daexim/en/latest/', None)
intersphinx_mapping['genius'] = ('https://docs.opendaylight.org/projects/genius/en/latest/', None)
intersphinx_mapping['infrautils'] = ('https://docs.opendaylight.org/projects/infrautils/en/latest/', None)
+intersphinx_mapping['integration-distribution'] = ('https://docs.opendaylight.org/projects/integration-distribution/en/latest/', None)
+intersphinx_mapping['lispflowmapping'] = ('https://docs.opendaylight.org/projects/lispflowmapping/en/latest/', None)
+intersphinx_mapping['netconf'] = ('https://docs.opendaylight.org/projects/netconf/en/latest/', None)
intersphinx_mapping['netvirt'] = ('https://docs.opendaylight.org/projects/netvirt/en/latest/', None)
intersphinx_mapping['openflowplugin'] = ('https://docs.opendaylight.org/projects/openflowplugin/en/latest/', None)
intersphinx_mapping['ovsdb'] = ('https://docs.opendaylight.org/projects/ovsdb/en/latest/', None)
+intersphinx_mapping['sxp'] = ('https://docs.opendaylight.org/projects/sxp/en/latest/', None)
+intersphinx_mapping['tsdr'] = ('https://docs.opendaylight.org/projects/tsdr/en/latest/', None)
+intersphinx_mapping['unimgr'] = ('https://docs.opendaylight.org/projects/unimgr/en/latest/', None)
# OpenDaylight Documentation Releases
intersphinx_mapping['odl-oxygen'] = ('https://docs.opendaylight.org/en/stable-oxygen/', None)
intersphinx_mapping['odl-carbon'] = ('https://docs.opendaylight.org/en/stable-carbon/', None)
linkcheck_ignore = [
+ 'http://localhost',
# Ignore jenkins because it's often slow to respond.
'https://jenkins.opendaylight.org/releng',
'https://jenkins.opendaylight.org/sandbox',
# The '#' in the path makes sphinx think it's an anchor
'https://git.opendaylight.org/gerrit/#/admin/projects/releng/builder',
+ 'https://git.opendaylight.org/gerrit/gitweb',
]
nitpicky = True
+++ /dev/null
-.. _alto-developer-guide:
-
-ALTO Developer Guide
-====================
-
-Overview
---------
-
-The topics of this guide are:
-
-1. How to add alto projects as dependencies;
-
-2. How to put/fetch data from ALTO;
-
-3. Basic API and DataType;
-
-4. How to use customized service implementations.
-
-Adding ALTO Projects as Dependencies
-------------------------------------
-
-Most ALTO packages can be added as dependencies in Maven projects by
-putting the following code in the *pom.xml* file.
-
-::
-
- <dependency>
- <groupId>org.opendaylight.alto</groupId>
- <artifactId>${THE_NAME_OF_THE_PACKAGE_YOU_NEED}</artifactId>
- <version>${ALTO_VERSION}</version>
- </dependency>
-
-The current stable version for ALTO is ``0.3.0-Boron``.
-
-Putting/Fetching data from ALTO
--------------------------------
-
-Using RESTful API
-~~~~~~~~~~~~~~~~~
-
-There are two kinds of RESTful APIs for ALTO: the one provided by
-``alto-northbound`` which follows the formats defined in `RFC
-7285 <https://tools.ietf.org/html/rfc7285>`__, and the one provided by
-RESTCONF whose format is defined by the YANG model proposed in `this
-draft <https://tools.ietf.org/html/draft-shi-alto-yang-model-03>`__.
-
-One way to get the URLs for the resources from ``alto-northbound`` is to
-visit the IRD service first where there is a ``uri`` field for every
-entry. However, the IRD service is not yet implemented so currently the
-developers have to construct the URLs themselves. The base URL is
-``/alto`` and below is a list of the specific paths defined in
-``alto-core/standard-northbound-route`` using Jersey ``@Path``
-annotation:
-
-- ``/ird/{rid}``: the path to access *IRD* services;
-
-- ``/networkmap/{rid}[/{tag}]``: the path to access *Network Map* and
- *Filtered Network Map* services;
-
-- ``/costmap/{rid}[/{tag}[/{mode}/{metric}]]``: the path to access
- *Cost Map* and *Filtered Cost Map* services;
-
-- ``/endpointprop``: the path to access *Endpoint Property* services;
-
-- ``/endpointcost``: the path to access *Endpoint Cost* services.
-
-.. note::
-
- The segments in brackets are optional.
-
-If you want to fetch the data using RESTCONF, it is highly recommended
-to take a look at the ``apidoc`` page
-(`http://{controller\_ip}:8181/apidoc/explorer/index.html <http://{controller_ip}:8181/apidoc/explorer/index.html>`__)
-after installing the ``odl-alto-release`` feature in karaf.
-
-It is also worth pointing out that ``alto-northbound`` only supports
-``GET`` and ``POST`` operations so it is impossible to manipulate the
-data through its RESTful APIs. To modify the data, use ``PUT`` and
-``DELETE`` methods with RESTCONF.
-
-.. note::
-
- The current implementation uses the ``configuration`` data store and
- that enables the developers to modify the data directly through
- RESTCONF. In the future this approach might be disabled in the core
- packages of ALTO but may still be available as an extension.
-
-Using MD-SAL
-~~~~~~~~~~~~
-
-You can also fetch data from the datastore directly.
-
-First you must get the access to the datastore by registering your
-module with a data broker.
-
-Then an ``InstanceIdentifier`` must be created. Here is an example of
-how to build an ``InstanceIdentifier`` for a *network map*:
-
-::
-
- import org.opendaylight...alto...Resources;
- import org.opendaylight...alto...resources.NetworkMaps;
- import org.opendaylight...alto...resources.network.maps.NetworkMap;
- import org.opendaylight...alto...resources.network.maps.NetworkMapKey;
- ...
- protected
- InstanceIdentifier<NetworkMap> getNetworkMapIID(String resource_id) {
- ResourceId rid = ResourceId.getDefaultInstance(resource_id);
- NetworkMapKey key = new NetworkMapKey(rid);
- InstanceIdentifier<NetworkMap> iid = null;
- iid = InstanceIdentifier.builder(Resources.class)
- .child(NetworkMaps.class)
- .child(NetworkMap.class, key)
- .build();
- return iid;
- }
- ...
-
-With the ``InstanceIdentifier`` you can use ``ReadOnlyTransaction``,
-``WriteTransaction`` and ``ReadWriteTransaction`` to manipulate the data
-accordingly. The ``simple-impl`` package, which provides some of the
-AD-SAL APIs mentioned above, is using this method to get data from the
-datastore and then convert them into RFC7285-compatible objects.
-
-Basic API and DataType
-----------------------
-
-a. alto-basic-types: Defines basic types of ALTO protocol.
-
-b. alto-service-model-api: Includes the YANG models for the five basic
- ALTO services defined in `RFC
- 7285 <https://tools.ietf.org/html/rfc7285>`__.
-
-c. alto-resourcepool: Manages the meta data of each ALTO service,
- including capabilities and versions.
-
-d. alto-northbound: Provides the root of RFC7285-compatible services at
- http://localhost:8080/alto.
-
-e. alto-northbound-route: Provides the root of the network map resources
- at http://localhost:8080/alto/networkmap/.
-
-How to customize service
-------------------------
-
-Define new service API
-~~~~~~~~~~~~~~~~~~~~~~
-
-Add a new module in ``alto-core/standard-service-models``. For example,
-we named our service model module as ``model-example``.
-
-Implement service RPC
-~~~~~~~~~~~~~~~~~~~~~
-
-Add a new module in ``alto-basic`` to implement a service RPC in
-``alto-core``.
-
-Currently ``alto-core/standard-service-models/model-base`` has defined a
-template of the service RPC. You can define your own RPC using
-``augment`` in YANG. Here is an example in ``alto-simpleird``.
-
-.. code::
-
- grouping "alto-ird-request" {
- container "ird-request" {
- }
- }
- grouping "alto-ird-response" {
- container "ird" {
- container "meta" {
- }
- list "resource" {
- key "resource-id";
- leaf "resource-id" {
- type "alto-types:resource-id";
- }
- }
- }
- }
- augment "/base:query/base:input/base:request" {
- case "ird-request-data" {
- uses "alto-ird-request";
- }
- }
- augment "/base:query/base:output/base:response" {
- case "ird-response-data" {
- uses "alto-ird-response";
- }
- }
-
-Register northbound route
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If necessary, you can add a northbound route module in
-``alto-core/standard-northbound-routes``.
+++ /dev/null
-.. _aaa-dev-guide:
-
-Authentication, Authorization and Accounting (AAA) Services
-===========================================================
-
-Overview
---------
-
-Authentication, Authorization and Accounting (AAA) is a term for a
-framework controlling access to resources, enforcing policies to use
-those resources and auditing their usage. These processes are the
-fundamental building blocks for effective network management and security.
-
-Authentication provides a way of identifying a user, typically by
-having the user enter a valid user name and valid password before access
-is granted. The process of authentication is based on each user having a unique
-set of criteria for gaining access. The AAA framework compares a user's
-authentication credentials with other user credentials stored in a database.
-If the credentials match, the user is granted access to the network.
-If the credentials don't match, authentication fails and access is denied.
-
-Authorization is the process of finding out what an authenticated user is
-allowed to do within the system, which tasks can do, which API can call, etc.
-The authorization process determines whether the user has the authority
-to perform such actions.
-
-Accounting is the process of logging the activity of an authenticated user,
-for example, the amount of data a user has sent and/or received during a
-session, which APIs called, etc.
-
-Terms And Definitions
-^^^^^^^^^^^^^^^^^^^^^
-
-AAA
- Authentication, Authorization and Accounting.
-
-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.
-
-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 user name 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.
-
-IdP
- Identity Provider.
-
-
-Quick Start
------------
-
-Building
-^^^^^^^^
-Get the code:
-
-.. code-block:: bash
-
- git clone https://git.opendaylight.org/gerrit/aaa
-
-Build it:
-
-.. code-block:: bash
-
- cd aaa && mvn clean install
-
-
-Installing
-^^^^^^^^^^
-
-AAA is automatically installed upon installation of odl-restconf, but you can
-install it yourself directly from the Karaf console through the following
-command:
-
-::
-
- feature:install odl-aaa-shiro
-
-Pushing changes
-^^^^^^^^^^^^^^^
-
-The following are basic instructions to push your contributions to the project's
-GIT repository:
-
-.. code-block:: bash
-
- git add .
- git commit -s
- # make changes, add change id, etc.
- git commit --amend
- git push ssh://{username}@git.opendaylight.org:29418/aaa.git HEAD:refs/for/master
-
-AAA Framework implementations
------------------------------
-
-Since Boron release, the OpenDaylight's AAA services are based on the
-`Apache Shiro <https://shiro.apache.org/>`_ Java Security Framework. The main
-configuration file for AAA is located at “etc/shiro.ini” relative to the
-OpenDaylight Karaf home directory.
-
-Known limitations
-^^^^^^^^^^^^^^^^^
-
-The database (H2) used by ODL AAA Authentication store is not-cluster enabled.
-When deployed in a clustered environment each node needs to have its AAA user
-file synchronized using out of band means.
-
-How to enable AAA
------------------
-
-AAA is enabled through installing the odl-aaa-shiro feature. The vast majority
-of OpenDaylight's northbound APIs (and all RESTCONF APIs) are protected by AAA
-by default when installing the +odl-restconf+ feature, since the odl-aaa-shiro
-is automatically installed as part of them.
-
-How to disable AAA
-------------------
-
-Edit the “etc/shiro.ini” file and replace the following:
-
-::
-
- /** = authcBasic
-
-with
-
-::
-
- /** = anon
-
-Then, restart the Karaf process.
-
-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:
-
-.. code-block:: xml
-
- <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 the Shiro 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
- capabilities.
-
-OpenDaylight contains five implementations:
-
-- TokenAuthRealm
-
- - An AuthorizingRealm built to bridge the Shiro-based AAA service
- with the 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. This is the realm configured by default.
-
-- 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
- OpenDaylight 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.
-
-- ODLActiveDirectoryRealm
-
- - Wraps the generic ActiveDirectoryRealm provided by Shiro. This allows for
- enhanced logging as well as isolation of all realms in a single package,
- which enables easier import by consuming servlets.
-
- - Disabled out of the box.
-
-- KeystoneAuthRealm
-
- - This realm authenticates OpenDaylight users against the OpenStack's
- Keystone server by using the
- `Keystone's Identity API v3 <https://developer.openstack.org/api-ref/identity/v3/>`_
- or later.
-
- - Disabled out of the box.
-
-.. note::
-
- More than one Realm implementation can be specified. Realms are attempted
- in order until authentication succeeds or all realm sources are exhausted.
- Edit the **securityManager.realms = $tokenAuthRealm** property in shiro.ini
- and add all the realms needed separated by commas.
-
-TokenAuthRealm
-^^^^^^^^^^^^^^
-
-How it works
-~~~~~~~~~~~~
-
-The TokenAuthRealm is the default Authorization Realm deployed in OpenDaylight.
-TokenAuthRealm uses a direct authentication mechanism as shown in the following
-picture:
-
-.. figure:: ./images/aaa/direct-authentication.png
- :alt: TokenAuthRealm direct authentication mechanism
-
- TokenAuthRealm direct authentication mechanism
-
-A user presents some credentials (e.g., username/password) directly to the
-OpenDaylight controller token endpoint /oauth2/token and receives an access
-token, which then can be used to access protected resources on the controller.
-
-How to access the H2 database
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The H2 database provides an optional front-end Web interface, which can be very
-useful for new users. From the KARAF_HOME directory, you can run the following
-command to enable the user interface:
-
-.. code-block:: bash
-
- java -cp ./data/cache/org.eclipse.osgi/bundles/217/1/.cp/h2-1.4.185.jar
- org.h2.tools.Server -trace -pg -web -webAllowOthers -baseDir `pwd`
-
-
-You can navigate to the following and login via the browser:
-
-::
-
- http://{IP}:8082/
-
-ODLJndiLdapRealm
-^^^^^^^^^^^^^^^^
-
-How it works
-~~~~~~~~~~~~
-
-LDAP integration is provided in order to externalize identity management.
-This configuration allows federation with an external LDAP server.
-The user’s OpenDaylight 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 OpenDaylight role
-structures.
-
-ODLJndiLdapRealmAuthNOnly
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-How it works
-~~~~~~~~~~~~
-
-This is useful for setups where all LDAP users are allowed equal access.
-
-KeystoneAuthRealm
-^^^^^^^^^^^^^^^^^
-
-How it works
-~~~~~~~~~~~~
-
-This realm authenticates OpenDaylight users against the OpenStack's Keystone
-server. This realm uses the
-`Keystone's Identity API v3 <https://developer.openstack.org/api-ref/identity/v3/>`_
-or later.
-
-.. figure:: ./images/aaa/keystonerealm-authentication.png
- :alt: KeystoneAuthRealm authentication mechanism
-
- KeystoneAuthRealm authentication/authorization mechanism
-
-As can shown on the above diagram, once configured, all the RESTCONF APIs calls
-will require sending **user**, **password** and optionally **domain** (1). Those
-credentials are used to authenticate the call against the Keystone server (2) and,
-if the authentication succeeds, the call will proceed to the MDSAL (3). The
-credentials must be provisioned in advance within the Keystone Server. The user
-and password are mandatory, while the domain is optional, in case it is not
-provided within the REST call, the realm will default to (**Default**),
-which is hard-coded. The default domain can be also configured through the
-*shiro.ini* file (see the :doc:`AAA User Guide <../user-guide/authentication-and-authorization-services>`).
-
-The protocol between the Controller and the Keystone Server (2) can be either
-HTTPS or HTTP. In order to use HTTPS the Keystone Server's certificate
-must be exported and imported on the Controller (see the :ref:`Certificate Management <aaa-certificate-management>` section).
-
-Authorization Configuration
----------------------------
-
-OpenDaylight supports two authorization engines at present, both of which are
-roughly similar in behavior:
-
-- Shiro-Based Authorization
-
-- MDSAL-Based Dynamic Authorization
-
-.. note::
-
- The preferred mechanism for configuring AAA Authentication is the
- MDSAL-Based Dynamic Authorization. Read the following section.
-
-Shiro-Based Static Authorization
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-OpenDaylight AAA has support for Role Based Access Control (RBAC) based
-on the Apache Shiro permissions system. Configuration of the authorization
-system is done off-line; authorization currently cannot be configured
-after the controller is started. The Authorization provided by this mechanism
-is aimed towards supporting coarse-grained security policies, the MDSAL-Based
-mechanism allows for a more robust configuration capabilities. `Shiro-based
-Authorization <http://shiro.apache.org/web.html#Web-%7B%7B%5Curls%5C%7D%7D>`_
-describes how to configure the Authentication feature in detail.
-
-.. note::
-
- The Shiro-Based Authorization that uses the *shiro.ini* URLs section to
- define roles requirements is **deprecated** and **discouraged** since the
- changes made to the file are only honored on a controller restart.
-
- Shiro-Based Authorization is not **cluster-aware**, so the changes made on
- the *shiro.ini* file have to be replicated on every controller instance
- belonging to the cluster.
-
- The URL patterns are matched relative to the Servlet context leaving room
- for ambiguity, since many endpoints may match (i.e., "/restconf/modules" and
- "/auth/modules" would both match a "/modules/\**" rule).
-
-MDSAL-Based Dynamic Authorization
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The MDSAL-Based Dynamic authorization uses the MDSALDynamicAuthorizationFilter
-engine to restrict access to particular URL endpoint patterns. Users may define
-a list of policies that are insertion-ordered. Order matters for that list of
-policies, since the first matching policy is applied. This choice was made to
-emulate behavior of the Shiro-Based Authorization mechanism.
-
-A **policy** is a key/value pair, where the key is a **resource**
-(i.e., a "URL pattern") and the value is a list of **permissions** for the
-resource. The following describes the various elements of a policy:
-
-- **Resource**: the resource is a string URL pattern as outlined by
- Apache Shiro. For more information, see http://shiro.apache.org/web.html.
-
-- **Description**: an optional description of the URL endpoint and why it is
- being secured.
-
-- **Permissions list**: a list of permissions for a particular policy. If more
- than one permission exists in the permissions list they are evaluated using
- logical "OR". A permission describes the prerequisites to perform HTTP
- operations on a particular endpoint. The following describes the various
- elements of a permission:
-
- + **Role**: the role required to access the target URL endpoint.
- + **Actions list**: a leaf-list of HTTP permissions that are allowed for a
- Subject possessing the required role.
-
-This an example on how to limit access to the modules endpoint:
-
-::
-
- HTTP Operation:
- put URL: /restconf/config/aaa:http-authorization/policies
-
- headers: Content-Type: application/json Accept: application/json
-
- body:
- { "aaa:policies":
- { "aaa:policies":
- [ { "aaa:resource": "/restconf/modules/**",
- "aaa:permissions": [ { "aaa:role": "admin",
- "aaa:actions": [ "get",
- "post",
- "put",
- "patch",
- "delete"
- ]
- }
- ]
- }
- ]
- }
- }
-
-The above example locks down access to the modules endpoint (and any URLS
-available past modules) to the "admin" role. Thus, an attempt from the OOB
-*admin* user will succeed with 2XX HTTP status code, while an attempt from the
-OOB *user* user will fail with HTTP status code 401, as the user *user* is not
-granted the "admin" role.
-
-Accounting Configuration
-------------------------
-
-Accounting is handled through the standard slf4j logging mechanisms used by the
-rest of OpenDaylight. Thus, one can control logging verbosity through
-manipulating the log levels for individual packages and classes directly through
-the Karaf console, JMX, or etc/org.ops4j.pax.logging.cfg. In normal operations,
-the default levels exposed do not provide much information about AAA services;
-this is due to the fact that logging can severely degrade performance.
-
-All AAA logging is output to the standard karaf.log file. For debugging purposes
-(i.e., to enable maximum verbosity), issue the following command:
-
-::
-
- log:set TRACE org.opendaylight.aaa
-
-Enable Successful/Unsuccessful Authentication Attempts Logging
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-By default, successful/unsuccessful authentication attempts are NOT logged. This
-is due to the fact that logging can severely decrease REST performance.
-
-It is possible to add custom AuthenticationListener(s) to the Shiro-based
-configuration, allowing different ways to listen for successful/unsuccessful
-authentication attempts. Custom AuthenticationListener(s) must implement
-the org.apache.shiro.authc.AuthenticationListener interface.
-
-.. _aaa-certificate-management:
-
-Certificate Management
-----------------------
-
-The **Certificate Management Service** is used to manage the keystores and
-certificates at the OpenDaylight distribution to easily provides the TLS
-communication.
-
-The Certificate Management Service managing two keystores:
-
-1. **OpenDaylight Keystore** which holds the OpenDaylight distribution
- certificate self sign certificate or signed certificate from a root CA based
- on generated certificate request.
-
-2. **Trust Keystore** which holds all the network nodes certificates that shall
- to communicate with the OpenDaylight distribution through TLS communication.
-
-The Certificate Management Service stores the keystores (OpenDaylight & Trust)
-as *.jks* files under configuration/ssl/ directory. Also the keystores
-could be stored at the MD-SAL datastore in case OpenDaylight distribution
-running at cluster environment. When the keystores are stored at MD-SAL,
-the Certificate Management Service rely on the **Encryption-Service** to encrypt
-the keystore data before storing it to MD-SAL and decrypted at runtime.
-
-How to use the Certificate Management Service to manage the TLS communication
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The following are the steps to configure the TLS communication within your
-feature or module:
-
-1. It is assumed that there exists an already created OpenDaylight distribution
- project following `this guide
- <https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Startup_Project_Archetype#Part_1_-_Build_with_a_simple_.27Example.27_module>`_.
-
-2. In the implementation bundle the following artifact must be added to its
- *pom.xml* file as dependency.
-
-.. code-block:: xml
-
- <dependency>
- <groupId>org.opendaylight.aaa</groupId>
- <artifactId>aaa-cert</artifactId>
- <version>0.5.0-SNAPSHOT</version>
- </dependency>
-
-3. Using the provider class in the implementation bundle needs to define a
- variable holding the Certificate Manager Service as in the following example:
-
-.. code-block:: java
-
- import org.opendaylight.aaa.cert.api.ICertificateManager;
- import org.opendaylight.controller.md.sal.binding.api.DataBroker;
-
- public class UseCertManagerExampleProvider {
- private final DataBroker dataBroker;
- private final ICertificateManager caManager;
-
- public EncSrvExampleProvider(final DataBroker dataBroker, final ICertificateManager caManager) {
- this.dataBroker = dataBroker;
- this.caManager = caManager;
- }
- public SSLEngine createSSLEngine() {
- final SSLContext sslContext = caManager.getServerContext();
- if (sslContext != null) {
- final SSLEngine sslEngine = sslContext.createSSLEngine();
- sslEngine.setEnabledCipherSuites(caManager.getCipherSuites());
- // DO the Implementation
- return sslEngine;
- }
- }
- public void init() {
- // TODO
- }
- public void close() {
- // TODO
- }
- }
-
-4. The Certificate Manager Service provides two main methods that are needed to
- establish the *SSLEngine* object, *getServerContext()* and *getCipherSuites()*
- as the above example shows. It also provides other methods such as
- *getODLKeyStore()* and *getTrustKeyStore()* that gives access to the
- OpenDaylight and Trust keystores.
-
-5. Now the *ICertificateManager* need to be passed as an argument to the
- *UseCertManagerExampleProvider* within the implementation bundle blueprint
- configuration. The following example shows how:
-
-.. code-block:: xml
-
- <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
- xmlns:odl="http://opendaylight.org/xmlns/blueprint/v1.0.0"
- odl:use-default-for-reference-types="true">
- <reference id="dataBroker"
- interface="org.opendaylight.controller.md.sal.binding.api.DataBroker"
- odl:type="default" />
- <reference id="aaaCertificateManager"
- interface="org.opendaylight.aaa.cert.api.ICertificateManager"
- odl:type="default-certificate-manager" />
- <bean id="provider"
- class="org.opendaylight.UseCertManagerExample.impl.UseCertManagerExampleProvider"
- init-method="init" destroy-method="close">
- <argument ref="dataBroker" />
- <argument ref="aaaCertificateManager" />
- </bean>
- </blueprint>
-
-6. After finishing the bundle implementation the feature module needs to be
- updated to include the *aaa-cert* feature in its feature bundle pom.xml file.
-
-.. code-block:: xml
-
- <properties>
- <aaa.version>0.5.0-SNAPSHOT</aaa.version>
- </properties>
- <dependency>
- <groupId>org.opendaylight.aaa</groupId>
- <artifactId>features-aaa</artifactId>
- <version>${aaa.version}</version>
- <classifier>features</classifier>
- <type>xml</type>
- </dependency>
-
-7. Now, in the feature.xml file add the Certificate Manager Service feature and
- its repository.
-
-.. code-block:: xml
-
- <repository>mvn:org.opendaylight.aaa/features-aaa/{VERSION}/xml/features</repository>
-
-The Certificate Manager Service feature can be included inside the
-implementation bundle feature as shown in the following example:
-
-.. code-block:: xml
-
- <feature name='odl-UseCertManagerExample' version='${project.version}'
- description='OpenDaylight :: UseCertManagerExample'>
- <feature version='${mdsal.version}'>odl-mdsal-broker</feature>
- <feature version='${aaa.version}'>odl-aaa-cert</feature>
- <bundle>mvn:org.opendaylight.UseCertManagerExample/UseCertManagerExample-impl/{VERSION}</bundle>
- </feature>
-
-8. Now the project can be built and the OpenDaylight distribution started to
- continue with the configuration process. See the User Guide for more details.
-
-Encryption Service
-------------------
-
-The **AAA Encryption Service** is used to encrypt the OpenDaylight users'
-passwords and TLS communication certificates. This section shows how to use the
-AAA Encryption Service with an OpenDaylight distribution project to encrypt data.
-
-1. It is assumed that there exists an already created OpenDaylight distribution
- project following `this guide
- <https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Startup_Project_Archetype#Part_1_-_Build_with_a_simple_.27Example.27_module>`_.
-
-2. In the implementation bundle the following artifact must be added to its
- *pom.xml* file as dependency.
-
-.. code-block:: xml
-
- <dependency>
- <groupId>org.opendaylight.aaa</groupId>
- <artifactId>aaa-encrypt-service</artifactId>
- <version>0.5.0-SNAPSHOT</version>
- </dependency>
-
-3. Using the provider class in the implementation bundle needs to define a
- variable holding the Encryption Service as in the following example:
-
-.. code-block:: java
-
- import org.opendaylight.aaa.encrypt.AAAEncryptionService;
- import org.opendaylight.controller.md.sal.binding.api.DataBroker;
-
- public class EncSrvExampleProvider {
- private final DataBroker dataBroker;
- private final AAAEncryptionService encryService;
-
- public EncSrvExampleProvider(final DataBroker dataBroker, final AAAEncryptionService encryService) {
- this.dataBroker = dataBroker;
- this.encryService = encryService;
- }
- public void init() {
- // TODO
- }
- public void close() {
- // TODO
- }
- }
-
-The AAAEncryptionService can be used to encrypt and decrypt any data based on
-project's needs.
-
-4. Now the *AAAEncryptionService* needs to be passed as an argument to the
- *EncSrvExampleProvider* within the implementation bundle blueprint
- configuration. The following example shows how:
-
-.. code-block:: xml
-
- <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
- xmlns:odl="http://opendaylight.org/xmlns/blueprint/v1.0.0"
- odl:use-default-for-reference-types="true">
- <reference id="dataBroker"
- interface="org.opendaylight.controller.md.sal.binding.api.DataBroker"
- odl:type="default" />
- <reference id="encryService" interface="org.opendaylight.aaa.encrypt.AAAEncryptionService"/>
- <bean id="provider"
- class="org.opendaylight.EncSrvExample.impl.EncSrvExampleProvider"
- init-method="init" destroy-method="close">
- <argument ref="dataBroker" />
- <argument ref="encryService" />
- </bean>
- </blueprint>
-
-5. After finishing the bundle implementation the feature module needs to be
- updated to include the *aaa-encryption-service* feature in its feature bundle
- pom.xml file.
-
-.. code-block:: xml
-
- <dependency>
- <groupId>org.opendaylight.aaa</groupId>
- <artifactId>features-aaa</artifactId>
- <version>${aaa.version}</version>
- <classifier>features</classifier>
- <type>xml</type>
- </dependency>
-
-It is also necessary to add the *aaa.version* in the properties section:
-
-.. code-block:: xml
-
- <properties>
- <aaa.version>0.5.0-SNAPSHOT</aaa.version>
- </properties>
-
-6. Now, in the feature.xml file add the Encryption Service feature and its
- repository.
-
-.. code-block:: xml
-
- <repository>mvn:org.opendaylight.aaa/features-aaa/{VERSION}/xml/features</repository>
-
-The Encryption Service feature can be included inside the implementation bundle
-feature as shown in the following example:
-
-.. code-block:: xml
-
- <feature name='odl-EncSrvExample' version='${project.version}' description='OpenDaylight :: EncSrvExample'>
- <feature version='${mdsal.version}'>odl-mdsal-broker</feature>
- <feature version='${aaa.version}'>odl-aaa-encryption-service</feature>
- <feature version='${project.version}'>odl-EncSrvExample-api</feature>
- <bundle>mvn:org.opendaylight.EncSrvExample/EncSrvExample-impl/{VERSION}</bundle>
- </feature>
-
-7. Now the project can be built and the OpenDaylight distribution started to
- continue with the configuration process. See the User Guide for more details.
+++ /dev/null
-.. _bgp-developer-guide:
-
-BGP Developer Guide
-===================
-
-Overview
---------
-
-This section provides an overview of the ``odl-bgpcep-bgp-all`` Karaf
-feature. This feature will install everything needed for BGP (Border
-Gateway Protocol) from establishing the connection, storing the data in
-RIBs (Route Information Base) and displaying data in network-topology
-overview.
-
-BGP Architecture
-----------------
-
-Each feature represents a module in the BGPCEP codebase. The following
-diagram illustrates how the features are related.
-
-.. figure:: ./images/bgpcep/bgp-dependency-tree.png
- :alt: BGP Dependency Tree
-
- BGP Dependency Tree
-
-Key APIs and Interfaces
------------------------
-
-BGP concepts
-~~~~~~~~~~~~
-
-This module contains the base BGP concepts contained in `RFC
-4271 <http://tools.ietf.org/html/rfc4271>`__, `RFC
-4760 <http://tools.ietf.org/html/rfc4760>`__, `RFC
-4456 <http://tools.ietf.org/html/rfc4456>`__, `RFC
-1997 <http://tools.ietf.org/html/rfc1997>`__ and `RFC
-4360 <http://tools.ietf.org/html/rfc4360>`__.
-
-All the concepts are described in one yang model:
-`bgp-types.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/yang/bgp-types.yang;hb=refs/heads/stable/boron>`__.
-
-Outside generated classes, there is just one class
-`NextHopUtil <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/java/org/opendaylight/bgp/concepts/NextHopUtil.java;hb=refs/heads/stable/boron>`__
-that contains methods for serializing and parsing NextHop.
-
-BGP parser
-~~~~~~~~~~
-
-Base BGP parser includes messages and attributes from `RFC
-4271 <http://tools.ietf.org/html/rfc4271>`__, `RFC
-4760 <http://tools.ietf.org/html/rfc4760>`__, `RFC
-1997 <http://tools.ietf.org/html/rfc1997>`__ and `RFC
-4360 <http://tools.ietf.org/html/rfc4360>`__.
-
-*API* module defines BGP messages in YANG.
-
-*IMPL* module contains actual parsers and serializers for BGP messages
-and
-`Activator <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-impl/src/main/java/org/opendaylight/protocol/bgp/parser/impl/BGPActivator.java;hb=refs/heads/stable/boron>`__
-class
-
-*SPI* module contains helper classes needed for registering parsers into
-activators
-
-Registration
-^^^^^^^^^^^^
-
-All parsers and serializers need to be registered into the *Extension
-provider*. This *Extension provider* is configured in initial
-configuration of the parser-spi module (``31-bgp.xml``).
-
-.. code:: xml
-
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bgp:parser:spi">prefix:bgp-extensions-impl</type>
- <name>global-bgp-extensions</name>
- <extension>
- <type xmlns:bgpspi="urn:opendaylight:params:xml:ns:yang:controller:bgp:parser:spi">bgpspi:extension</type>
- <name>base-bgp-parser</name>
- </extension>
- <extension>
- <type xmlns:bgpspi="urn:opendaylight:params:xml:ns:yang:controller:bgp:parser:spi">bgpspi:extension</type>
- <name>bgp-linkstate</name>
- </extension>
- </module>
-
-- *base-bgp-parser* - will register parsers and serializers implemented
- in the bgp-parser-impl module
-
-- *bgp-linkstate* - will register parsers and serializers implemented
- in the bgp-linkstate module
-
-The bgp-linkstate module is a good example of a BGP parser extension.
-
-The configuration of bgp-parser-spi specifies one implementation of
-*Extension provider* that will take care of registering mentioned parser
-extensions:
-`SimpleBGPExtensionProviderContext <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi/pojo/SimpleBGPExtensionProviderContext.java;hb=refs/heads/stable/boron>`__.
-All registries are implemented in package
-`bgp-parser-spi <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi;hb=refs/heads/stable/boron>`__.
-
-Serializing
-^^^^^^^^^^^
-
-The serializing of BGP elements is mostly done in the same way as in
-`PCEP <#_pcep_developer_guide>`__, the only exception is the
-serialization of path attributes, which is described here. Path
-attributes are different from any other BGP element, as path attributes
-don’t implement one common interface, but this interface contains
-getters for individual path attributes (this structure is because update
-message can contain exactly one instance of each path attribute). This
-means, that a given *PathAttributes* object, you can only get to the
-specific type of the path attribute through checking its presence.
-Therefore method *serialize()* in *AttributeRegistry*, won’t look up the
-registered class, instead it will go through the registrations and offer
-this object to the each registered parser. This way the object will be
-passed also to serializers unknown to module bgp-parser, for example to
-LinkstateAttributeParser. RFC 4271 recommends ordering path attributes,
-hence the serializers are ordered in a list as they are registered in
-the *Activator*. In other words, this is the only case, where
-registration ordering matters.
-
-.. figure:: ./images/bgpcep/PathAttributesSerialization.png
- :alt: PathAttributesSerialization
-
- PathAttributesSerialization
-
-*serialize()* method in each Path Attribute parser contains check for
-presence of its attribute in the PathAttributes object, which simply
-returns, if the attribute is not there:
-
-.. code:: java
-
- if (pathAttributes.getAtomicAggregate() == null) {
- return;
- }
- //continue with serialization of Atomic Aggregate
-
-BGP RIB
--------
-
-The BGP RIB module can be divided into two parts:
-
-- BGP listener and speaker session handling
-
-- RIB handling.
-
-Session handling
-~~~~~~~~~~~~~~~~
-
-``31-bgp.xml`` defines only bgp-dispatcher and the parser it should be
-using (global-bgp-extensions).
-
-.. code:: xml
-
- <module>
- <type>prefix:bgp-dispatcher-impl</type>
- <name>global-bgp-dispatcher</name>
- <bgp-extensions>
- <type>bgpspi:extensions</type>
- <name>global-bgp-extensions</name>
- </bgp-extensions>
- <boss-group>
- <type>netty:netty-threadgroup</type>
- <name>global-boss-group</name>
- </boss-group>
- <worker-group>
- <type>netty:netty-threadgroup</type>
- <name>global-worker-group</name>
- </worker-group>
- </module>
-
-For user configuration of BGP, check User Guide.
-
-Synchronization
-~~~~~~~~~~~~~~~
-
-Synchronization is a phase, where upon connection, a BGP speaker sends
-all available data about topology to its new client. After the whole
-topology has been advertised, the synchronization is over. For the
-listener, the synchronization is over when the RIB receives End-of-RIB
-(EOR) messages. There is a special EOR message for each AFI (Address
-Family Identifier).
-
-- IPv4 EOR is an empty Update message.
-
-- Ipv6 EOR is an Update message with empty MP\_UNREACH attribute where
- AFI and SAFI (Subsequent Address Family Identifier) are set to Ipv6.
- OpenDaylight also supports EOR for IPv4 in this format.
-
-- Linkstate EOR is an Update message with empty MP\_UNREACH attribute
- where AFI and SAFI are set to Linkstate.
-
-For BGP connections, where both peers support graceful restart, the EORs
-are sent by the BGP speaker and are redirected to RIB, where the
-specific AFI/SAFI table is set to *true*. Without graceful restart, the
-messages are generated by OpenDaylight itself and sent after second
-keepalive for each AFI/SAFI. This is done in
-`BGPSynchronization <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPSynchronization.java;hb=refs/heads/stable/boron>`__.
-
-**Peers**
-
-`BGPPeer <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPPeer.java;hb=refs/heads/stable/boron>`__
-has various meanings. If you configure BGP listener, *BGPPeer*
-represents the BGP listener itself. If you are configuring BGP speaker,
-you need to provide a list of peers, that are allowed to connect to this
-speaker. Unknown peer represents, in this case, a peer that is allowed
-to be refused. *BGPPeer* represents in this case peer, that is supposed
-to connect to your speaker. *BGPPeer* is stored in
-`BGPPeerRegistry <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/StrictBGPPeerRegistry.java;hb=refs/heads/stable/boron>`__.
-This registry controls the number of sessions. Our strict implementation
-limits sessions to one per peer.
-
-`ApplicationPeer <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/ApplicationPeer.java;hb=refs/heads/stable/boron>`__
-is a special case of peer, that has it’s own RIB. This RIB is populated
-from RESTCONF. The RIB is synchronized with default BGP RIB. Incoming
-routes to the default RIB are treated in the same way as they were from
-a BGP peer (speaker or listener) in the network.
-
-RIB handling
-~~~~~~~~~~~~
-
-RIB (Route Information Base) is defined as a concept in `RFC
-4271 <http://tools.ietf.org/html/rfc4271#section-3.2>`__. RFC does not
-define how it should be implemented. In our implementation, the routes
-are stored in the MD-SAL datastore. There are four supported routes -
-*Ipv4Routes*, *Ipv6Routes*, *LinkstateRoutes* and *FlowspecRoutes*.
-
-Each route type needs to provide a
-`RIBSupport.java <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-spi/src/main/java/org/opendaylight/protocol/bgp/rib/spi/RIBSupport.java;hb=refs/heads/stable/boron>`__
-implementation. *RIBSupport* tells RIB how to parse binding-aware data
-(BGP Update message) to binding-independent (datastore format).
-
-Following picture describes the data flow from BGP message that is sent
-to *BGPPeer* to datastore and various types of RIB.
-
-.. figure:: ./images/bgpcep/RIB.png
- :alt: RIB
-
- RIB
-
-`AdjRibInWriter <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibInWriter.java;hb=refs/heads/stable/boron>`__
-- represents the first step in putting data to datastore. This writer is
-notified whenever a peer receives an Update message. The message is
-transformed into binding-independent format and pushed into datastore to
-*adj-rib-in*. This RIB is associated with a peer.
-
-`EffectiveRibInWriter <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/EffectiveRibInWriter.java;hb=refs/heads/stable/boron>`__
-- this writer is notified whenever *adj-rib-in* is updated. It applies
-all configured import policies to the routes and stores them in
-*effective-rib-in*. This RIB is also associated with a peer.
-
-`LocRibWriter <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/LocRibWriter.java;hb=refs/heads/stable/boron>`__
-- this writer is notified whenever **any** *effective-rib-in* is updated
-(in any peer). Performs best path selection filtering and stores the
-routes in *loc-rib*. It also determines which routes need to be
-advertised and fills in *adj-rib-out* that is per peer as well.
-
-`AdjRibOutListener <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibOutListener.java;h=a14fd54a29ea613b381a36248f67491d968963b8;hb=refs/heads/stable/boron>`__
-- listens for changes in *adj-rib-out*, transforms the routes into
-BGPUpdate messages and sends them to its associated peer.
-
-BGP inet
---------
-
-This module contains only one YANG model
-`bgp-inet.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/inet/src/main/yang/bgp-inet.yang;hb=refs/heads/stable/boron>`__
-that summarizes the ipv4 and ipv6 extensions to RIB routes and BGP
-messages.
-
-BGP flowspec
-------------
-
-BGP flowspec is a module that implements `RFC
-5575 <http://tools.ietf.org/html/rfc5575>`__ for IPv4 AFI and
-`draft-ietf-idr-flow-spec-v6-06 <https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-06>`__
-for IPv6 AFI. The RFC defines an extension to BGP in form of a new
-subsequent address family, NLRI and extended communities. All of those
-are defined in the
-`bgp-flowspec.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/flowspec/src/main/yang/bgp-flowspec.yang;hb=refs/heads/stable/boron>`__
-model. In addition to generated sources, the module contains parsers for
-newly defined elements and RIBSupport for flowspec-routes. The route key
-of flowspec routes is a string representing human-readable flowspec
-request.
-
-BGP linkstate
--------------
-
-BGP linkstate is a module that implements
-`draft-ietf-idr-ls-distribution <http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-04>`__
-version 04. The draft defines an extension to BGP in form of a new
-address family, subsequent address family, NLRI and path attribute. All
-of those are defined in the
-`bgp-linkstate.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/yang/bgp-linkstate.yang;hb=refs/heads/stable/boron>`__
-model. In addition to generated sources, the module contains
-`LinkstateAttributeParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/attribute/LinkstateAttributeParser.java;hb=refs/heads/stable/boron>`__,
-`LinkstateNlriParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/nlri/LinkstateNlriParser.java;hb=refs/heads/stable/boron>`__,
-activators for both, parser and RIB, and RIBSupport handler for
-linkstate address family. As each route needs a key, in case of
-linkstate, the route key is defined as a binary string, containing all
-the NLRI serialized to byte format. The BGP linkstate extension also
-supports distribution of MPLS TE state as defined in
-`draft-ietf-idr-te-lsp-distribution-03 <https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-03>`__,
-extension for Segment Routing
-`draft-gredler-idr-bgp-ls-segment-routing-ext-00 <https://tools.ietf.org/html/draft-gredler-idr-bgp-ls-segment-routing-ext-00>`__
-and Segment Routing Egress Peer Engineering
-`draft-ietf-idr-bgpls-segment-routing-epe-02 <https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-02>`__.
-
-BGP labeled-unicast
--------------------
-
-BGP labeled unicast is a module that implements `RFC
-3107 <https://tools.ietf.org/html/rfc3107>`__. The RFC defines an
-extension to the BGP MP to carry Label Mapping Information as a part of
-the NLRI. The AFI indicates, as usual, the address family of the
-associated route. The fact that the NLRI contains a label is indicated
-by using SAFI value 4. All of those are defined in
-`bgp-labeled-unicast.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob_plain;f=bgp/labeled-unicast/src/main/yang/bgp-labeled-unicast.yang;hb=refs/heads/stable/boron>`__
-model. In addition to the generated sources, the module contains new
-NLRI codec and RIBSupport. The route key is defined as a binary, where
-whole NLRI information is encoded.
-
-BGP topology provider
----------------------
-
-BGP data besides RIB, is stored in network-topology view. The format of
-how the data is displayed there conforms to
-`draft-clemm-netmod-yang-network-topo <https://tools.ietf.org/html/draft-clemm-netmod-yang-network-topo-01>`__.
-
-API Reference Documentation
----------------------------
-
-Javadocs are generated while creating mvn:site and they are located in
-target/ directory in each module.
+++ /dev/null
-.. _bgp-monitoring-protocol-developer-guide:
-
-BGP Monitoring Protocol Developer Guide
-=======================================
-
-Overview
---------
-
-This section provides an overview of **feature odl-bgpcep-bmp**. This
-feature will install everything needed for BMP (BGP Monitoring Protocol)
-including establishing the connection, processing messages, storing
-information about monitored routers, peers and their Adj-RIB-In
-(unprocessed routing information) and Post-Policy Adj-RIB-In and
-displaying data in BGP RIBs overview. The OpenDaylight BMP plugin plays
-the role of a monitoring station.
-
-Key APIs and Interfaces
------------------------
-
-Session handling
-~~~~~~~~~~~~~~~~
-
-*32-bmp.xml* defines only bmp-dispatcher the parser should be using
-(global-bmp-extensions).
-
-.. code:: xml
-
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">prefix:bmp-dispatcher-impl</type>
- <name>global-bmp-dispatcher</name>
- <bmp-extensions>
- <type xmlns:bmp-spi="urn:opendaylight:params:xml:ns:yang:controller:bmp:spi">bmp-spi:extensions</type>
- <name>global-bmp-extensions</name>
- </bmp-extensions>
- <boss-group>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-threadgroup</type>
- <name>global-boss-group</name>
- </boss-group>
- <worker-group>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-threadgroup</type>
- <name>global-worker-group</name>
- </worker-group>
- </module>
-
-For user configuration of BMP, check User Guide.
-
-Parser
-~~~~~~
-
-The base BMP parser includes messages and attributes from
-https://tools.ietf.org/html/draft-ietf-grow-bmp-15
-
-Registration
-~~~~~~~~~~~~
-
-All parsers and serializers need to be registered into *Extension
-provider*. This *Extension provider* is configured in initial
-configuration of the parser (*32-bmp.xml*).
-
-.. code:: xml
-
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bmp:spi">prefix:bmp-extensions-impl</type>
- <name>global-bmp-extensions</name>
- <extension>
- <type xmlns:bmp-spi="urn:opendaylight:params:xml:ns:yang:controller:bmp:spi">bmp-spi:extension</type>
- <name>bmp-parser-base</name>
- </extension>
- </module>
-
-- *bmp-parser-base* - will register parsers and serializers implemented
- in bmp-impl module
-
-Parsing
-~~~~~~~
-
-Parsing of BMP elements is mostly done equally to BGP. Some of the BMP
-messages includes wrapped BGP messages.
-
-BMP Monitoring Station
-~~~~~~~~~~~~~~~~~~~~~~
-
-The BMP application (Monitoring Station) serves as message processor
-incoming from monitored routers. The processed message is transformed
-and relevant information is stored. Route information is stored in a BGP
-RIB data structure.
-
-BMP data is displayed only through one URL that is accessible from the
-base BMP URL:
-
-*`http://<controllerIP>:8181/restconf/operational/bmp-monitor:bmp-monitor <http://<controllerIP>:8181/restconf/operational/bmp-monitor:bmp-monitor>`__*
-
-Each Monitor station will be displayed and it may contains multiple
-monitored routers and peers within:
-
-.. code:: xml
-
- <bmp-monitor xmlns="urn:opendaylight:params:xml:ns:yang:bmp-monitor">
- <monitor>
- <monitor-id>example-bmp-monitor</monitor-id>
- <router>
- <router-id>127.0.0.11</router-id>
- <status>up</status>
- <peer>
- <peer-id>20.20.20.20</peer-id>
- <as>72</as>
- <type>global</type>
- <peer-session>
- <remote-port>5000</remote-port>
- <timestamp-sec>5</timestamp-sec>
- <status>up</status>
- <local-address>10.10.10.10</local-address>
- <local-port>220</local-port>
- </peer-session>
- <pre-policy-rib>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv4-route>
- <prefix>10.10.10.0/24</prefix>
- <attributes>
- ...
- </attributes>
- </ipv4-route>
- </ipv4-routes>
- <attributes>
- <uptodate>true</uptodate>
- </attributes>
- </tables>
- </pre-policy-rib>
- <address>10.10.10.10</address>
- <post-policy-rib>
- ...
- </post-policy-rib>
- <bgp-id>20.20.20.20</bgp-id>
- <stats>
- <timestamp-sec>5</timestamp-sec>
- <invalidated-cluster-list-loop>53</invalidated-cluster-list-loop>
- <duplicate-prefix-advertisements>16</duplicate-prefix-advertisements>
- <loc-rib-routes>100</loc-rib-routes>
- <duplicate-withdraws>11</duplicate-withdraws>
- <invalidated-as-confed-loop>55</invalidated-as-confed-loop>
- <adj-ribs-in-routes>10</adj-ribs-in-routes>
- <invalidated-as-path-loop>66</invalidated-as-path-loop>
- <invalidated-originator-id>70</invalidated-originator-id>
- <rejected-prefixes>8</rejected-prefixes>
- </stats>
- </peer>
- <name>name</name>
- <description>description</description>
- <info>some info;</info>
- </router>
- </monitor>
- </bmp-monitor>
- </source>
-
-API Reference Documentation
----------------------------
-
-Javadocs are generated while creating mvn:site and they are located in
-target/ directory in each module.
+++ /dev/null
-.. _bier-dev-guide:
-
-BIER Developer Guide
-====================
-
-BIER Architecture
------------------
-
-- **Channel**
-
- - Channel (multicast flow) configuration and deploying information management.
-
-- **Common**
-
- - Common YANG models collection.
-
-- **Drivers**
-
- - South-bound NETCONF interface for BIER, it has implemented standard interface (ietf-bier).
- If your BFR's NETCONF interface is Non-standard, you should add your own interface for driver.
-
-- **Sbi-Adapter**
-
- - Adapter for different BIER south-bound NETCONF interfaces.
-
-- **Service**
-
- - Major processor function for BIER.
-
-- **Bierman**
-
- - BIER topology management, and BIER information (BIER, BIER-TE, lable info) configuration.
-
-- **Pce**
-
- - Path computation element for BIER-TE.
-
-- **Bierapp**
-
- - BIER UI, show topology and configure BIER/BIER-TE and channel.
-
-
-APIs in BIER
-------------
-
-The sections below give details about the configuration settings for
-the components that can be configured.
-
-BIER Information Manager
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-API Description
-^^^^^^^^^^^^^^^
-
-- bier/bierman/api/src/main/yang/bier-topology-api.yang
-
- - **load-topology**
-
- - Load BIER topology, and list all topo-name in all BIER topologies.
-
- - **configure-domain**
-
- - Configure domain in given BIER topology.
-
- - **configure-subdomain**
-
- - Configure sub-domain in given BIER domain and topology.
-
- - **delete-domain**
-
- - Delete given domain in given topology.
-
- - **delete-subdomain**
-
- - Delete given sub-domain in given domain and topology.
-
- - **query-topology**
-
- - Query given topology in BIER topology, and then display this
- topology's detail, such as information of node and link.
-
- - **query-node**
-
- - Query given nodes in given topology, and then display these nodes'
- detail, such as information of node-name, router-id,
- termination-point list, BIER domain and sub-domain list, etc.
-
- - **query-link**
-
- - Query given link in given topology, and then display this link's detail.
-
- - **query-domain**
-
- - Query domain in given BIER topology, and then display the domain-id list.
-
- - **query-subdomain**
-
- - Query sub-domain in given domain and given topology, and then display
- the sub-domain-id list.
-
- - **query-subdomain-node**
-
- - Query nodes which have been assigned to given sub-domain and domain in given
- topology, and then display these nodes' details.
-
- - **query-subdomain-link**
-
- - Query links which have been assigned to given sub-domain and domain in given
- topology, and then display these links' details.
-
- - **query-te-subdomain-node**
-
- - Query te-nodes which have been assigned to given sub-domain and domain in given
- topology, and then display these te-nodes' details.
-
- - **query-te-subdomain-link**
-
- - Query te-links which have been assigned to given sub-domain and domain in given
- topology, and then display these te-links' details.
-
-
-- bier/bierman/api/src/main/yang/bier-config-api.yang
-
- - **configure-node**
-
- - Configure node information in given topology, which defined in ietf-bier,
- such as domains, sub-domains, bitstringlength, bfr-id, encapsulation-type, etc.
-
- - **delete-node**
-
- - Delete given node which be assigned to given sub-domain and domain in
- given topology.
-
- - **delete-ipv4**
-
- - Delete bier mapping entry of ipv4.
-
- - **delete-ipv6**
-
- - Delete bier mapping entry of ipv6.
-
-
-- bier/bierman/api/src/main/yang/bier-te-config-api.yang
-
- - **configure-te-node**
-
- - Configure adjancency information for node, such as domains, sub-domains, si,
- bitstringlength, tpid, bitposition, etc.
-
- - **configure-te-label**
-
- - Configure BIER-TE label range for node.
-
- - **delete-te-babel**
-
- - Delete BIER-TE label range of node.
-
- - **delete-te-bsl**
-
- - Delete BIER-TE bitstringlength, including all SIs which belongs to this bitstringlenght.
-
- - **delete-te-si**
-
- - Delete BIER-TE SI, including all bitpositions which belongs to this SI.
-
- - **delete-te-bp**
-
- - Delete BIER-TE bitposition of an adjancency.
-
-Parameters Description
-^^^^^^^^^^^^^^^^^^^^^^
-
-- **topology-id**
-
- - BIER topology identifier.
-
-- **node-id**
-
- - Node identifier in network topology.
-
-- **latitude**
-
- - Node’s latitude, default value is 0.
-
-- **longitude**
-
- - Node’s longitude, default value is 0.
-
-- **tp-id**
-
- - Termination point identifier.
-
-- **domain-id**
-
- - BIER domain identifier.
-
-- **encapsulation-type**
-
- - Base identity for BIER encapsulation. Default value is "bier-encapsulation-mpls".
-
-- **bitstringlength**
-
- - The bitstringlength type for imposition mode. It's value can be chosen from 64,
- 128, 256, 512, 1024, 2048, and 4096.
-
- - The BitStringLength ("Imposition BitStringLength") and sub-domain ("Imposition
- sub-domain") to use when it imposes (as a BFIR) a BIER encapsulation on a
- particular set of packets.
-
-- **bfr-id**
-
- - BIER bfr identifier. BFR-id is a number in the range [1, 65535].
-
- - Bfr-id is unique within the sub-domain. A BFR-id is a small unstructured positive
- integer. For instance, if a particular BIER sub-domain contains 1, 374 BFRs, each
- one could be given a BFR-id in the range 1-1374.
-
- - If a given BFR belongs to more than one sub-domain, it may (though it need not)
- have a different BFR-id for each sub-domain.
-
-- **ipv4-bfr-prefix**
-
- - BIER BFR IPv4 prefix.
-
- - A BFR's BFR-Prefix MUST be an IP address (either IPv4 or IPv6) of the BFR, and MUST be
- unique and routable within the BIER domain. It is RECOMMENDED that the BFR-prefix be a
- loopback address of the BFR. Two BFRs in the same BIER domain MUST NOT be assigned the
- same BFR-Prefix. Note that a BFR in a given BIER domain has the same BFR-prefix in all
- the sub-domains of that BIER domain.
-
-- **ipv6-bfr-prefix**
-
- - BIER BFR IPv6 prefix.
-
-- **sub-domain-id**
-
- - Sub-domain identifier. Each sub-domain is identified by a sub-domain-id in the range [0, 255].
-
- - A BIER domain may contain one or more sub-domains. Each BIER domain MUST contain at least one
- sub-domain, the "default sub-domain" (also denoted "sub-domain zero"). If a BIER domain
- contains more than one sub-domain, each BFR in the domain MUST be provisioned to know the set
- of sub-domains to which it belongs.
-
-- **igp-type**
-
- - The IGP type. Enum type contains OSPF and ISIS.
-
-- **mt-id**
-
- - Multi-topology associated with BIER sub-domain.
-
-- **bitstringlength**
-
- - Disposition bitstringlength.
-
- - The BitStringLengths ("Disposition BitStringLengths") that it will process when
- (as a BFR or BFER) it receives packets from a particular sub-domain.
-
-- **bier-mpls-label-base**
-
- - BIER mpls-label, range in [0, 1048575].
-
-- **bier-mpls-label-range-size**
-
- - BIER mpls-label range size.
-
-- **link-id**
-
- - The identifier of a link in the topology.
-
- - A link is specific to a topology to which it belongs.
-
-
-- **source-node**
-
- - Source node identifier, must be in same topology.
-
-- **source-tp**
-
- - Termination point within source node that terminates the link.
-
-- **dest-node**
-
- - Destination node identifier and must be in same topology.
-
-- **dest-tp**
-
- - Termination point within destination node that terminates the link.
-
-- **delay**
-
- - The link delay, default value is 0.
-
-- **loss**
-
- - The number of packet loss on the link and default value is 0.
-
-Channel Manager
-~~~~~~~~~~~~~~~
-
-API Description
-^^^^^^^^^^^^^^^
-
-- bier/channel/api/src/main/yang/bier-channel-api.yang
-
- - **get-channel**
-
- - Display all channel's names in given BIER topology.
-
- - **query-channel**
-
- - Query specific channel in given topology and display this channel's information (multicast
- flow information and related BFIR,BFER information).
-
- - **add-channel**
-
- - Create channel with multicast information in given BIER topology.
-
- - **modify-channel**
-
- - Modify the channel's information which created above.
-
- - **remove-channel**
-
- - Remove given channel in given topology.
-
- - **deploy-channel**
-
- - Deploy channel, and configure BFIR and BFERs about this multicast flow in given topology.
-
-Parameters Description
-^^^^^^^^^^^^^^^^^^^^^^
-
-- **topology-id**
-
- - BIER topology identifier.
-
-- **channel-name**
-
- - BIER channel (multicast flow information) name.
-
-- **src-ip**
-
- - The IPv4 of multicast source. The value set to zero means that the receiver interests in
- all source that relevant to one group.
-
-- **dst-group**
-
- - The IPv4 of multicast group.
-
-- **domain-id**
-
- - BIER domain identifier.
-
-- **sub-domain-id**
-
- - BIER sub-domain identifier.
-
-- **source-wildcard**
-
- - The wildcard information of source, in the range [1, 32].
-
-- **group-wildcard**
-
- - The wildcard information of multi-cast group, in the range [1, 32].
-
-- **ingress-node**
-
- - BFIR (Bit-Forwarding Ingress Router).
-
-- **ingress-bfr-id**
-
- - The bfr-id of BRIR.
-
-- **egress-node**
-
- - BFER (Bit-Forwarding Egress Router).
-
-- **egress-bfr-id**
-
- - The bfr-id of BRER.
-
-- **bier-forwarding-type**
-
- - The forwarding type, enum type contains BIER and BIER-TE.
-
-.. note:: For more information about BIER terminology, see `YANG Data Model for BIER Protocol <https://datatracker.ietf.org/doc/draft-ietf-bier-bier-yang/?include_text=1>`_.
-
-
-Sample Configurations
----------------------
-
-1. Configure Domain And Sub-domain
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-1.1. Configure Domain
-^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:configure-domain*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topo-id": " bier-topo" ,
- "domain ":[
- {
- "domain-id": " 1",
- },
- {
- "domain-id": " 2",
- }
- ]
- }
- }
-
-1.2. Configure Sub-domain
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:configure-subdomain*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topo-id": " bier-topo" ,
- "domain-id":" 1",
- "sub-domain":[
- {
- "sub-domain-id":" 0",
- },
- {
- "sub-domain-id":"1",
- }
- ]
- }
- }
-
-2. Configure Node
-~~~~~~~~~~~~~~~~~
-
-2.1. Configure BIER Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-config-api:configure-node*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo",
- "node-id": "node1",
- "domain": [
- {
- "domain-id": "2",
- "bier-global": {
- "sub-domain": [
- {
- "sub-domain-id": "0",
- "igp-type": "ISIS",
- "mt-id": "1",
- "bfr-id": "3",
- "bitstringlength": "64-bit",
- "af": {
- "ipv4": [
- {
- "bitstringlength": "64",
- "bier-mpls-label-base": "56",
- "bier-mpls-label-range-size": "100"
- }
- ]
- }
- }
- ],
- "encapsulation-type": "bier-encapsulation-mpls",
- "bitstringlength": "64-bit",
- "bfr-id": "33",
- "ipv4-bfr-prefix": "192.168.1.1/24",
- "ipv6-bfr-prefix": "1030:0:0:0:C9B4:FF12:48AA:1A2B/60"
- }
- }
- ]
- }
- }
-
-2.2. Configure BIER-TE label
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-te-config-api:configure-te-label*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo",
- "node-id": "node1",
- "label-base": "100",
- "label-range-size": "20"
- }
- }
-
-2.3. Configure BIER-TE Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-te-config-api:configure-te-node*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo",
- "node-id": "node1",
- "te-domain": [
- {
- "domain-id": "1",
- "te-sub-domain": [
- {
- "sub-domain-id": "0",
- "te-bsl": [
- {
- "bitstringlength": "64-bit",
- "te-si": [
- {
- "si": "1",
- "te-bp": [
- {
- "tp-id":"tp1",
- "bitposition": "1"
- }
- ]
- }
- ]
- }
- ]
- }
- ]
- }
- ]
- }
- }
-
-3. Query BIER Topology Information
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-3.1. Load Topology
-^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:load-topology*
-
-no request body.
-
-3.2. Query Topology
-^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:query-topology*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topo-id": "bier-topo"
- }
- }
-
-3.3. Query BIER Node
-^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:query-node*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topo-id": "bier-topo",
- "node-id": "node1"
- }
- }
-
-3.4. Query BIER Link
-^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:query-link*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topo-id": "bier-topo",
- "node-id": "node1"
- }
- }
-
-3.5. Query Domain
-^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:query-domain*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topo-id": "bier-topo"
- }
- }
-
-3.6. Query Sub-domain
-^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:query-subdomain*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topo-id": "bier-topo",
- "domain-id": "1"
- }
- }
-
-3.7. Query Sub-domain Node
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:query-subdomain-node*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo",
- "domain-id": "1",
- "sub-domain-id": "0"
- }
- }
-
-3.8. Query Sub-domain Link
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:query-subdomain-link*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo",
- "domain-id": "1",
- "sub-domain-id": "0"
- }
- }
-
-3.9. Query BIER-TE Sub-domain Node
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:query-te-subdomain-node*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo",
- "domain-id": "1",
- "sub-domain-id": "0"
- }
- }
-
-3.10. Query BIER-TE Sub-domain Link
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:query-te-subdomain-link*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo",
- "domain-id": "1",
- "sub-domain-id": "0"
- }
- }
-
-4. BIER Channel Configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-4.1. Configure Channel
-^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-channel-api:add-channel*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo",
- "name": "channel-1",
- "src-ip": "1.1.1.1",
- "dst-group": "224.1.1.1",
- "domain-id": "1",
- "sub-domain-id": "11",
- "source-wildcard": "24",
- "group-wildcard": "30"
- }
- }
-
-4.2. Modify Channel
-^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-channel-api:modify-channel*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo",
- "name": "channel-1",
- "src-ip": "2.2.2.2",
- "dst-group": "225.1.1.1",
- "domain-id": "1",
- "sub-domain-id": "11",
- "source-wildcard": "24",
- "group-wildcard": "30"
- }
- }
-
-5. Deploy Channel
-~~~~~~~~~~~~~~~~~
-
-**REST API** : *POST /restconf/operations/bier-channel-api:deploy-channel*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo",
- "channel-name": "channel-1",
- "bier-forwarding-type":"bier-te"
- "ingress-node": "node1",
- "egress-node": [
- {
- "node-id": "node2"
- },
- {
- "node-id": "node3"
- }
- ]
- }
- }
-
-6. Query Channel Information
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-6.1. Get Channel
-^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-channel-api:get-channel*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo"
- }
- }
-
-6.2. Query Channel
-^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-channel-api:query-channel*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo",
- "channel-name": [
- "channel-1",
- "channel-2"
- ]
- }
- }
-
-7. Remove Channel
-~~~~~~~~~~~~~~~~~
-
-**REST API** : *POST /restconf/operations/bier-channel-api:remove-channel*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topology-id": "bier-topo",
- "channel-name": "channel-1"
- }
- }
-
-8. Delete BIER and BIER-TE Configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-8.1. Delete BIER Node
-^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-config-api:delete-node*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topo-id": "bier-topo",
- "node-id": "node3",
- "domain-id": "1",
- "subdomain-id": "0"
- }
- }
-
-8.2. Delete IPv4 of BIER Node
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-config-api:delete-ipv4*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- input: {
- "topology-id": "bier-topo",
- "domain-id": "1",
- "sub-domain-id": "0",
- "node-id": "node1",
- "ipv4": {
- "bier-mpls-label-base": "10",
- "bier-mpls-label-range-size": "16",
- "bitstringlength": "64"
- }
- }
- }
-
-8.3. Delete IPv6 of BIER Node
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-config-api:delete-ipv6*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- input: {
- "topology-id": "bier-topo",
- "domain-id": "1",
- "sub-domain-id": "0",
- "node-id": "node1",
- "ipv6": {
- "bier-mpls-label-base": "10",
- "bier-mpls-label-range-size": "16",
- "bitstringlength": "64"
- }
- }
- }
-
-8.4. Delete BIER-TE BSL
-^^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-te-config-api:delete-te-bsl*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- input:{
- "topology-id": "bier-topo",
- "node-id": "node1",
- "domain-id": "1",
- "sub-domain-id": "0",
- "bitstringlength": "64-bit"
- }
- }
-
-8.5. Delete BIER-TE SI
-^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-te-config-api:delete-te-si*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- input:{
- "topology-id": "bier-topo",
- "node-id": "node1",
- "domain-id": "1",
- "sub-domain-id": "0",
- "bitstringlength": "64-bit",
- "si": "1"
- }
- }
-
-8.6. Delete BIER-TE BP
-^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-te-config-api:delete-te-bp*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- input: {
- "topology-id": "bier-topo",
- "node-id": "node1",
- "domain-id": "1",
- "sub-domain-id": "0",
- "bitstringlength": "64-bit",
- "si": "1",
- "tp-id": "tp1"
- }
- }
-
-8.7. Delete BIER-TE Label
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-te-config-api:delete-te-label*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topo-id": "bier-topo",
- "node-id": "node1"
- }
- }
-
-8.8. Delete Sub-domain
-^^^^^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:delete-subdomian*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topo-id": "bier-topo",
- "domain-id": "1",
- "subdomain-id": "0"
- }
- }
-
-8.9. Delete Domain
-^^^^^^^^^^^^^^^^^^
-
-**REST API** : *POST /restconf/operations/bier-topology-api:delete-domian*
-
-**Sample JSON Data**
-
-.. code:: json
-
- {
- "input": {
- "topo-id": "bier-topo",
- "domain-id": "1"
- }
- }
+++ /dev/null
-CAPWAP Developer Guide
-======================
-
-Overview
---------
-
-The Control And Provisioning of Wireless Access Points (CAPWAP) plugin
-project aims to provide new southbound interface for controller to be
-able to monitor and manage CAPWAP compliant wireless termination point
-(WTP) network devices. The CAPWAP feature will provide REST based
-northbound APIs.
-
-CAPWAP Architecture
--------------------
-
-The CAPWAP feature is implemented as an MD-SAL based provider module,
-which helps discover WTP devices and update their states in the MD-SAL
-operational datastore.
-
-CAPWAP APIs and Interfaces
---------------------------
-
-This section describes the APIs for interacting with the CAPWAP plugin.
-
-Discovered WTPs
-~~~~~~~~~~~~~~~
-
-The CAPWAP project maintains list of discovered CAPWAP WTPs that is
-YANG-based in MD-SAL. These models are available via RESTCONF.
-
-- Name: Discovered-WTPs
-
-- URL:
- `http://${ipaddress}:8181/restconf/operational/capwap-impl:capwap-ac-root/ <http://${ipaddress}:8181/restconf/operational/capwap-impl:capwap-ac-root/>`__
-
-- Description: Displays list of discovered WTPs and their basic
- attributes
-
-API Reference Documentation
----------------------------
-
-Go to
-`http://${ipaddress}:8181/apidoc/explorer/index.html <http://${ipaddress}:8181/apidoc/explorer/index.html>`__,
-sign in, and expand the capwap-impl panel. From there, users can execute
-various API calls to test their CAPWAP deployment.
-
+++ /dev/null
-.. _cardinal-dev-guide:
-
-Cardinal: OpenDaylight Monitoring as a Service
-==============================================
-
-Overview
---------
-
-Cardinal (OpenDaylight Monitoring as a Service) enables OpenDaylight and
-the underlying software defined network to be remotely monitored by
-deployed Network Management Systems (NMS) or Analytics suite. In the
-Boron release, Cardinal adds:
-
-1. OpenDaylight MIB.
-
-2. Enable ODL diagnostics/monitoring to be exposed across SNMP (v2c, v3)
- and REST north-bound.
-
-3. Extend ODL System health, Karaf parameter and feature info, ODL
- plugin scalability and network parameters.
-
-4. Support autonomous notifications (SNMP Traps).
-
-Cardinal Architecture
----------------------
-
-The Cardinal architecture can be found at the below link:
-
-https://wiki.opendaylight.org/images/8/89/Cardinal-ODL_Monitoring_as_a_Service_V2.pdf
-
-Key APIs and Interfaces
------------------------
-
-There are 6 main APIs for requesting snmpget request of the Karaf info,
-System info, Openflow devices and Netconf Devices. To expose these APIs,
-it assumes that you already have the ``odl-cardinal`` and ``odl-restconf``
-features installed. You can do that by entering the following at the Karaf console:
-
-::
-
- feature:install odl-cardinal
- feature:install odl-restconf-all
- feature:install odl-l2switch-switch
- feature:install odl-netconf-all
- feature:install odl-netconf-connector-all
- feature:install odl-netconf-mdsal
- feature:install cardinal-features4
- feature:install odl-cardinal-api
- feature:install odl-cardinal-ui
- feature:install odl-cardinal-rest
-
-System Info APIs
-~~~~~~~~~~~~~~~~
-
-Open the REST interface and using the basic authentication, execute REST
-APIs for system info as:
-
-::
-
- http://localhost:8181/restconf/operational/cardinal:CardinalSystemInfo/
-
-You should get the response code of the same as 200 OK with the
-following output as:
-
-::
-
- {
- "CardinalSystemInfo": {
- "odlSystemMemUsage": " 9",
- "odlSystemSysInfo": " OpenDaylight Node Information",
- "odlSystemOdlUptime": " 00:29",
- "odlSystemCpuUsage": " 271",
- "odlSystemHostAddress": " Address of the Host should come up"
- }
- }
-
-Karaf Info APIs
-~~~~~~~~~~~~~~~
-
-Open the REST interface and using the basic authentication, execute REST
-APIs for system info as:
-
-::
-
- http://localhost:8181/restconf/operational/cardinal-karaf:CardinalKarafInfo/
-
-You should get the response code of the same as 200 OK with the
-following output as:
-
-::
-
- {
- "CardinalKarafInfo": {
- "odlKarafBundleListActive1": " org.ops4j.pax.url.mvn_2.4.5 [1]",
- "odlKarafBundleListActive2": " org.ops4j.pax.url.wrap_2.4.5 [2]",
- "odlKarafBundleListActive3": " org.ops4j.pax.logging.pax-logging-api_1.8.4 [3]",
- "odlKarafBundleListActive4": " org.ops4j.pax.logging.pax-logging-service_1.8.4 [4]",
- "odlKarafBundleListActive5": " org.apache.karaf.service.guard_3.0.6 [5]",
- "odlKarafBundleListActive6": " org.apache.felix.configadmin_1.8.4 [6]",
- "odlKarafBundleListActive7": " org.apache.felix.fileinstall_3.5.2 [7]",
- "odlKarafBundleListActive8": " org.objectweb.asm.all_5.0.3 [8]",
- "odlKarafBundleListActive9": " org.apache.aries.util_1.1.1 [9]",
- "odlKarafBundleListActive10": " org.apache.aries.proxy.api_1.0.1 [10]",
- "odlKarafBundleListInstalled1": " org.ops4j.pax.url.mvn_2.4.5 [1]",
- "odlKarafBundleListInstalled2": " org.ops4j.pax.url.wrap_2.4.5 [2]",
- "odlKarafBundleListInstalled3": " org.ops4j.pax.logging.pax-logging-api_1.8.4 [3]",
- "odlKarafBundleListInstalled4": " org.ops4j.pax.logging.pax-logging-service_1.8.4 [4]",
- "odlKarafBundleListInstalled5": " org.apache.karaf.service.guard_3.0.6 [5]",
- "odlKarafFeatureListInstalled1": " config",
- "odlKarafFeatureListInstalled2": " region",
- "odlKarafFeatureListInstalled3": " package",
- "odlKarafFeatureListInstalled4": " http",
- "odlKarafFeatureListInstalled5": " war",
- "odlKarafFeatureListInstalled6": " kar",
- "odlKarafFeatureListInstalled7": " ssh",
- "odlKarafFeatureListInstalled8": " management",
- "odlKarafFeatureListInstalled9": " odl-netty",
- "odlKarafFeatureListInstalled10": " odl-lmax",
- "odlKarafBundleListResolved1": " org.ops4j.pax.url.mvn_2.4.5 [1]",
- "odlKarafBundleListResolved2": " org.ops4j.pax.url.wrap_2.4.5 [2]",
- "odlKarafBundleListResolved3": " org.ops4j.pax.logging.pax-logging-api_1.8.4 [3]",
- "odlKarafBundleListResolved4": " org.ops4j.pax.logging.pax-logging-service_1.8.4 [4]",
- "odlKarafBundleListResolved5": " org.apache.karaf.service.guard_3.0.6 [5]",
- "odlKarafFeatureListUnInstalled1": " aries-annotation",
- "odlKarafFeatureListUnInstalled2": " wrapper",
- "odlKarafFeatureListUnInstalled3": " service-wrapper",
- "odlKarafFeatureListUnInstalled4": " obr",
- "odlKarafFeatureListUnInstalled5": " http-whiteboard",
- "odlKarafFeatureListUnInstalled6": " jetty",
- "odlKarafFeatureListUnInstalled7": " webconsole",
- "odlKarafFeatureListUnInstalled8": " scheduler",
- "odlKarafFeatureListUnInstalled9": " eventadmin",
- "odlKarafFeatureListUnInstalled10": " jasypt-encryption"
- }
- }
-
-OpenFlowInfo Apis
-~~~~~~~~~~~~~~~~~
-
-Open the REST interface and using the basic authentication, execute REST APIs for system info as:
-
-http://localhost:8181/restconf/operational/cardinal-openflow:Devices
-
-You should get the response code of the same as 200 OK with the following output as:
-
-::
-
- {
- "Devices": {
- "openflow": [
- {
- "macAddress": "6a:80:ef:06:d3:46",
- "status": "Connected",
- "flowStats": " ",
- "interface": "s1",
- "manufacturer": "Nicira, Inc.",
- "nodeName": "openflow:1:LOCAL",
- "meterStats": " "
- },
- {
- "macAddress": "32:56:c7:41:5d:9a",
- "status": "Connected",
- "flowStats": " ",
- "interface": "s2-eth2",
- "manufacturer": "Nicira, Inc.",
- "nodeName": "openflow:2:2",
- "meterStats": " "
- },
- {
- "macAddress": "36:a8:3b:fe:e2:21",
- "status": "Connected",
- "flowStats": " ",
- "interface": "s3-eth1",
- "manufacturer": "Nicira, Inc.",
- "nodeName": "openflow:3:1",
- "meterStats": " "
- }
- ]
- }
- }
-
-
-Configuration for Netconf Devices:-
-
-1. To configure or update a netconf-connector via topology you need to send following request to Restconf:
-
-::
-
- Method: PUT
- URI: http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device
- Headers:
- Accept: application/xml
- Content-Type: application/xml
-
-Payload:
-
-.. code-block:: xml
-
- <node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <node-id>new-netconf-device</node-id>
- <host xmlns="urn:opendaylight:netconf-node-topology">127.0.0.1</host>
- <port xmlns="urn:opendaylight:netconf-node-topology">17830</port>
- <username xmlns="urn:opendaylight:netconf-node-topology">admin</username>
- <password xmlns="urn:opendaylight:netconf-node-topology">admin</password>
- <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
- <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">0</keepalive-delay>
- </node>
-
-2. To delete a netconf connector issue a DELETE request to the following url:
-URI:http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device
-
-NetConf Info Apis
-Open the REST interface and using the basic authentication, execute REST APIs for system info as:
-
-http://localhost:8181/restconf/operational/cardinal-netconf:Devices
-
-You should get the response code of the same as 200 OK with the following output as:
-
-::
-
- {
- "Devices": {
- "netconf": [
- {
- "status": "connecting",
- "host": "127.0.0.1",
- "nodeId": "new-netconf-device1",
- "port": "17830"
- },
- {
- "status": "connecting",
- "host": "127.0.0.1",
- "nodeId": "new-netconf-device",
- "port": "17830"
- },
- {
- "status": "connecting",
- "host": "127.0.0.1",
- "nodeId": "controller-config",
- "port": "1830"
- }
- ]
- }
- }
+++ /dev/null
-.. _controller-dev-guide:
-
-Controller
-==========
-
-Overview
---------
-
-OpenDaylight Controller is Java-based, model-driven controller using
-YANG as its modeling language for various aspects of the system and
-applications and with its components serves as a base platform for other
-OpenDaylight applications.
-
-The OpenDaylight Controller relies on the following technologies:
-
-- **OSGI** - This framework is the back-end of OpenDaylight as it
- allows dynamically loading of bundles and packages JAR files, and
- binding bundles together for exchanging information.
-
-- **Karaf** - Application container built on top of OSGI, which
- simplifies operational aspects of packaging and installing
- applications.
-
-- **YANG** - a data modeling language used to model configuration and
- state data manipulated by the applications, remote procedure calls,
- and notifications.
-
-The OpenDaylight Controller provides following model-driven subsystems
-as a foundation for Java applications:
-
-- :ref:`config_subsystem` - an activation,
- dependency-injection and configuration framework, which allows
- two-phase commits of configuration and dependency-injection, and
- allows for run-time rewiring.
-
-- :ref:`MD-SAL <mdsal_dev_guide>` - messaging and data storage
- functionality for data, notifications and RPCs modeled by application
- developers. MD-SAL uses YANG as the modeling for both interface and
- data definitions, and provides a messaging and data-centric runtime
- for such services based on YANG modeling.
-
-- **MD-SAL Clustering** - enables cluster support for core MD-SAL
- functionality and provides location-transparent accesss to
- YANG-modeled data.
-
-The OpenDaylight Controller supports external access to applications and
-data using following model-driven protocols:
-
-- **NETCONF** - XML-based RPC protocol, which provides abilities for
- client to invoke YANG-modeled RPCs, receive notifications and to
- read, modify and manipulate YANG modeled data.
-
-- **RESTCONF** - HTTP-based protocol, which provides REST-like APIs to
- manipulate YANG modeled data and invoke YANG modeled RPCs, using XML
- or JSON as payload format.
-
-.. _mdsal_dev_guide:
-
-MD-SAL Overview
----------------
-
-The Model-Driven Service Adaptation Layer (MD-SAL) is message-bus
-inspired extensible middleware component that provides messaging and
-data storage functionality based on data and interface models defined by
-application developers (i.e. user-defined models).
-
-The MD-SAL:
-
-- Defines a **common-layer, concepts, data model building blocks and
- messaging patterns** and provides infrastructure / framework for
- applications and inter-application communication.
-
-- Provide common support for user-defined transport and payload
- formats, including payload serialization and adaptation (e.g. binary,
- XML or JSON).
-
-The MD-SAL uses **YANG** as the modeling language for both interface and
-data definitions, and provides a messaging and data-centric runtime for
-such services based on YANG modeling.
-
-| The MD-SAL provides two different API types (flavours):
-
-- **MD-SAL Binding:** MD-SAL APIs which extensively uses APIs and
- classes generated from YANG models, which provides compile-time
- safety.
-
-- **MD-SAL DOM:** (Document Object Model) APIs which uses DOM-like
- representation of data, which makes them more powerful, but provides
- less compile-time safety.
-
-.. note::
-
- Model-driven nature of the MD-SAL and **DOM**-based APIs allows for
- behind-the-scene API and payload type mediation and transformation
- to facilitate seamless communication between applications - this
- enables for other components and applications to provide connectors
- / expose different set of APIs and derive most of its functionality
- purely from models, which all existing code can benefit from without
- modification. For example **RESTCONF Connector** is an application
- built on top of MD-SAL and exposes YANG-modeled application APIs
- transparently via HTTP and adds support for XML and JSON payload
- type.
-
-Basic concepts
-~~~~~~~~~~~~~~
-
-Basic concepts are building blocks which are used by applications, and
-from which MD-SAL uses to define messaging patterns and to provide
-services and behavior based on developer-supplied YANG models.
-
-Data Tree
- All state-related data are modeled and represented as data tree,
- with possibility to address any element / subtree
-
- - **Operational Data Tree** - Reported state of the system,
- published by the providers using MD-SAL. Represents a feedback
- loop for applications to observe state of the network / system.
-
- - **Configuration Data Tree** - Intended state of the system or
- network, populated by consumers, which expresses their intention.
-
-Instance Identifier
- Unique identifier of node / subtree in data tree, which provides
- unambiguous information, how to reference and retrieve node /
- subtree from conceptual data trees.
-
-Notification
- Asynchronous transient event which may be consumed by subscribers
- and they may act upon it
-
-RPC
- asynchronous request-reply message pair, when request is triggered
- by consumer, send to the provider, which in future replies with
- reply message.
-
- .. note::
-
- In MD-SAL terminology, the term *RPC* is used to define the
- input and output for a procedure (function) that is to be
- provided by a provider, and mediated by the MD-SAL, that means
- it may not result in remote call.
-
-Messaging Patterns
-~~~~~~~~~~~~~~~~~~
-
-MD-SAL provides several messaging patterns using broker derived from
-basic concepts, which are intended to transfer YANG modeled data between
-applications to provide data-centric integration between applications
-instead of API-centric integration.
-
-- **Unicast communication**
-
- - **Remote Procedure Calls** - unicast between consumer and
- provider, where consumer sends **request** message to provider,
- which asynchronously responds with **reply** message
-
-- **Publish / Subscribe**
-
- - **Notifications** - multicast transient message which is published
- by provider and is delivered to subscribers
-
- - **Data Change Events** - multicast asynchronous event, which is
- sent by data broker if there is change in conceptual data tree,
- and is delivered to subscribers
-
-- **Transactional access to Data Tree**
-
- - Transactional **reads** from conceptual **data tree** - read-only
- transactions with isolation from other running transactions.
-
- - Transactional **modification** to conceptual **data tree** - write
- transactions with isolation from other running transactions.
-
- - **Transaction chaining**
-
-MD-SAL Data Transactions
-------------------------
-
-MD-SAL **Data Broker** provides transactional access to conceptual
-**data trees** representing configuration and operational state.
-
-.. note::
-
- **Data tree** usually represents state of the modeled data, usually
- this is state of controller, applications and also external systems
- (network devices).
-
-**Transactions** provide :ref:`stable and isolated
-view <transaction_isolation>` from other currently running
-transactions. The state of running transaction and underlying data tree
-is not affected by other concurrently running transactions.
-
-Write-Only
- Transaction provides only modification capabilities, but does not
- provide read capabilities. Write-only transaction is allocated using
- ``newWriteOnlyTransaction()``.
-
- .. note::
-
- This allows less state tracking for write-only transactions and
- allows MD-SAL Clustering to optimize internal representation of
- transaction in cluster.
-
-Read-Write
- Transaction provides both read and write capabilities. It is
- allocated using ``newReadWriteTransaction()``.
-
-Read-Only
- Transaction provides stable read-only view based on current data
- tree. Read-only view is not affected by any subsequent write
- transactions. Read-only transaction is allocated using
- ``newReadOnlyTransaction()``.
-
- .. note::
-
- If an application needs to observe changes itself in data tree,
- it should use **data tree listeners** instead of read-only
- transactions and polling data tree.
-
-Transactions may be allocated using the **data broker** itself or using
-**transaction chain**. In the case of **transaction chain**, the new
-allocated transaction is not based on current state of data tree, but
-rather on state introduced by previous transaction from the same chain,
-even if the commit for previous transaction has not yet occurred (but
-transaction was submitted).
-
-Write-Only & Read-Write Transaction
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Write-Only and Read-Write transactions provide modification capabilities
-for the conceptual data trees.
-
-1. application allocates new transactions using
- ``newWriteOnlyTransaction()`` or ``newReadWriteTransaction()``.
-
-2. application `modifies data tree <#_modification_of_data_tree>`__
- using ``put``, ``merge`` and/or ``delete``.
-
-3. application finishes transaction using
- ``submit()``, which :ref:`seals transaction
- and submits <submitting_transaction>` it to be processed.
-
-4. application observes the result of the transaction commit using
- either blocking or asynchronous calls.
-
-The **initial state** of the write transaction is a **stable snapshot**
-of the current data tree state captured when transaction was created and
-it’s state and underlying data tree are not affected by other
-concurrently running transactions.
-
-Write transactions are **isolated** from other concurrent write
-transactions. All :ref:`writes are local <transaction_local_state>`
-to the transaction and represents only a **proposal of state change**
-for data tree and **are not visible** to any other concurrently running
-transactions (including read-only transactions).
-
-The transaction :ref:`commit may fail <commit_failure_scenarios>` due
-to failing verification of data or concurrent transaction modifying and
-affected data in an incompatible way.
-
-Modification of Data Tree
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Write-only and read-write transaction provides following methods to
-modify data tree:
-
-put
- .. code:: java
-
- <T> void put(LogicalDatastoreType store, InstanceIdentifier<T> path, T data);
-
- Stores a piece of data at a specified path. This acts as an **add /
- replace** operation, which is to say that whole subtree will be
- replaced by the specified data.
-
-merge
- .. code:: java
-
- <T> void merge(LogicalDatastoreType store, InstanceIdentifier<T> path, T data);
-
- Merges a piece of data with the existing data at a specified path.
- Any **pre-existing data** which are not explicitly overwritten
- **will be preserved**. This means that if you store a container, its
- child subtrees will be merged.
-
-delete
- .. code:: java
-
- void delete(LogicalDatastoreType store, InstanceIdentifier<?> path);
-
- Removes a whole subtree from a specified path.
-
-.. _submitting_transaction:
-
-Submitting transaction
-^^^^^^^^^^^^^^^^^^^^^^
-
-Transaction is submitted to be processed and committed using following
-method:
-
-.. code:: java
-
- CheckedFuture<Void,TransactionCommitFailedException> submit();
-
-Applications publish the changes proposed in the transaction by calling
-``submit()`` on the transaction. This **seals the transaction**
-(preventing any further writes using this transaction) and submits it to
-be processed and applied to global conceptual data tree. The
-``submit()`` method does not block, but rather returns
-``ListenableFuture``, which will complete successfully once processing
-of transaction is finished and changes are applied to data tree. If
-**commit** of data failed, the future will fail with
-``TransactionFailedException``.
-
-Application may listen on commit state asynchronously using
-``ListenableFuture``.
-
-.. code:: java
-
- Futures.addCallback( writeTx.submit(), new FutureCallback<Void>() {
- public void onSuccess( Void result ) {
- LOG.debug("Transaction committed successfully.");
- }
-
- public void onFailure( Throwable t ) {
- LOG.error("Commit failed.",e);
- }
- });
-
-- Submits ``writeTx`` and registers application provided
- ``FutureCallback`` on returned future.
-
-- Invoked when future completed successfully - transaction ``writeTx``
- was successfully committed to data tree.
-
-- Invoked when future failed - commit of transaction ``writeTx``
- failed. Supplied exception provides additional details and cause of
- failure.
-
-If application need to block till commit is finished it may use
-``checkedGet()`` to wait till commit is finished.
-
-.. code:: java
-
- try {
- writeTx.submit().checkedGet();
- } catch (TransactionCommitFailedException e) {
- LOG.error("Commit failed.",e);
- }
-
-- Submits ``writeTx`` and blocks till commit of ``writeTx`` is
- finished. If commit fails ``TransactionCommitFailedException`` will
- be thrown.
-
-- Catches ``TransactionCommitFailedException`` and logs it.
-
-.. _transaction_local_state:
-
-Transaction local state
-^^^^^^^^^^^^^^^^^^^^^^^
-
-Read-Write transactions maintain transaction-local state, which renders
-all modifications as if they happened, but this is only local to
-transaction.
-
-Reads from the transaction returns data as if the previous modifications
-in transaction already happened.
-
-Let assume initial state of data tree for ``PATH`` is ``A``.
-
-.. code:: java
-
- ReadWriteTransaction rwTx = broker.newReadWriteTransaction();
-
- rwRx.read(OPERATIONAL,PATH).get();
- rwRx.put(OPERATIONAL,PATH,B);
- rwRx.read(OPERATIONAL,PATH).get();
- rwRx.put(OPERATIONAL,PATH,C);
- rwRx.read(OPERATIONAL,PATH).get();
-
-- Allocates new ``ReadWriteTransaction``.
-
-- Read from ``rwTx`` will return value ``A`` for ``PATH``.
-
-- Writes value ``B`` to ``PATH`` using ``rwTx``.
-
-- Read will return value ``B`` for ``PATH``, since previous write
- occurred in same transaction.
-
-- Writes value ``C`` to ``PATH`` using ``rwTx``.
-
-- Read will return value ``C`` for ``PATH``, since previous write
- occurred in same transaction.
-
-.. _transaction_isolation:
-
-Transaction isolation
-~~~~~~~~~~~~~~~~~~~~~
-
-Running (not submitted) transactions are isolated from each other and
-changes done in one transaction are not observable in other currently
-running transaction.
-
-Lets assume initial state of data tree for ``PATH`` is ``A``.
-
-.. code:: java
-
- ReadOnlyTransaction txRead = broker.newReadOnlyTransaction();
- ReadWriteTransaction txWrite = broker.newReadWriteTransaction();
-
- txRead.read(OPERATIONAL,PATH).get();
- txWrite.put(OPERATIONAL,PATH,B);
- txWrite.read(OPERATIONAL,PATH).get();
- txWrite.submit().get();
- txRead.read(OPERATIONAL,PATH).get();
- txAfterCommit = broker.newReadOnlyTransaction();
- txAfterCommit.read(OPERATIONAL,PATH).get();
-
-- Allocates read only transaction, which is based on data tree which
- contains value ``A`` for ``PATH``.
-
-- Allocates read write transaction, which is based on data tree which
- contains value ``A`` for ``PATH``.
-
-- Read from read-only transaction returns value ``A`` for ``PATH``.
-
-- Data tree is updated using read-write transaction, ``PATH`` contains
- ``B``. Change is not public and only local to transaction.
-
-- Read from read-write transaction returns value ``B`` for ``PATH``.
-
-- Submits changes in read-write transaction to be committed to data
- tree. Once commit will finish, changes will be published and ``PATH``
- will be updated for value ``B``. Previously allocated transactions
- are not affected by this change.
-
-- Read from previously allocated read-only transaction still returns
- value ``A`` for ``PATH``, since it provides stable and isolated view.
-
-- Allocates new read-only transaction, which is based on data tree,
- which contains value ``B`` for ``PATH``.
-
-- Read from new read-only transaction return value ``B`` for ``PATH``
- since read-write transaction was committed.
-
-.. note::
-
- Examples contain blocking calls on future only to illustrate that
- action happened after other asynchronous action. The use of the
- blocking call ``ListenableFuture#get()`` is discouraged for most
- use-cases and you should use
- ``Futures#addCallback(ListenableFuture, FutureCallback)`` to listen
- asynchronously for result.
-
-.. _commit_failure_scenarios:
-
-Commit failure scenarios
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-A transaction commit may fail because of following reasons:
-
-Optimistic Lock Failure
- Another transaction finished earlier and **modified the same node in
- a non-compatible way**. The commit (and the returned future) will
- fail with an ``OptimisticLockFailedException``.
-
- It is the responsibility of the caller to create a new transaction
- and submit the same modification again in order to update data tree.
-
- .. warning::
-
- ``OptimisticLockFailedException`` usually exposes **multiple
- writers** to the same data subtree, which may conflict on same
- resources.
-
- In most cases, retrying may result in a probability of success.
-
- There are scenarios, albeit unusual, where any number of retries
- will not succeed. Therefore it is strongly recommended to limit
- the number of retries (2 or 3) to avoid an endless loop.
-
-Data Validation
- The data change introduced by this transaction **did not pass
- validation** by commit handlers or data was incorrectly structured.
- The returned future will fail with a
- ``DataValidationFailedException``. User **should not retry** to
- create new transaction with same data, since it probably will fail
- again.
-
-Example conflict of two transactions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This example illustrates two concurrent transactions, which derived from
-same initial state of data tree and proposes conflicting modifications.
-
-.. code:: java
-
- WriteTransaction txA = broker.newWriteTransaction();
- WriteTransaction txB = broker.newWriteTransaction();
-
- txA.put(CONFIGURATION, PATH, A);
- txB.put(CONFIGURATION, PATH, B);
-
- CheckedFuture<?,?> futureA = txA.submit();
- CheckedFuture<?,?> futureB = txB.submit();
-
-- Updates ``PATH`` to value ``A`` using ``txA``
-
-- Updates ``PATH`` to value ``B`` using ``txB``
-
-- Seals & submits ``txA``. The commit will be processed asynchronously
- and data tree will be updated to contain value ``A`` for ``PATH``.
- The returned ‘ListenableFuture’ will complete successfully once state
- is applied to data tree.
-
-- Seals & submits ``txB``. Commit of ``txB`` will fail, because
- previous transaction also modified path in a concurrent way. The
- state introduced by ``txB`` will not be applied. The returned
- ``ListenableFuture`` will fail with ``OptimisticLockFailedException``
- exception, which indicates that concurrent transaction prevented the
- submitted transaction from being applied.
-
-Example asynchronous retry-loop
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. code:: java
-
- private void doWrite( final int tries ) {
- WriteTransaction writeTx = dataBroker.newWriteOnlyTransaction();
-
- MyDataObject data = ...;
- InstanceIdentifier<MyDataObject> path = ...;
- writeTx.put( LogicalDatastoreType.OPERATIONAL, path, data );
-
- Futures.addCallback( writeTx.submit(), new FutureCallback<Void>() {
- public void onSuccess( Void result ) {
- // succeeded
- }
-
- public void onFailure( Throwable t ) {
- if( t instanceof OptimisticLockFailedException && (( tries - 1 ) > 0)) {
- doWrite( tries - 1 );
- }
- }
- });
- }
- ...
- doWrite( 2 );
-
-Concurrent change compatibility
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-There are several sets of changes which could be considered incompatible
-between two transactions which are derived from same initial state.
-Rules for conflict detection applies recursively for each subtree level.
-
-Following table shows state changes and failures between two concurrent
-transactions, which are based on same initial state, ``tx1`` is
-submitted before ``tx2``.
-
-INFO: Following tables stores numeric values and shows data using
-``toString()`` to simplify examples.
-
-+--------------------+--------------------+--------------------+--------------------+
-| Initial state | tx1 | tx2 | Observable Result |
-+====================+====================+====================+====================+
-| Empty | ``put(A,1)`` | ``put(A,2)`` | ``tx2`` will fail, |
-| | | | value of ``A`` is |
-| | | | ``1`` |
-+--------------------+--------------------+--------------------+--------------------+
-| Empty | ``put(A,1)`` | ``merge(A,2)`` | value of ``A`` is |
-| | | | ``2`` |
-+--------------------+--------------------+--------------------+--------------------+
-| Empty | ``merge(A,1)`` | ``put(A,2)`` | ``tx2`` will fail, |
-| | | | value of ``A`` is |
-| | | | ``1`` |
-+--------------------+--------------------+--------------------+--------------------+
-| Empty | ``merge(A,1)`` | ``merge(A,2)`` | ``A`` is ``2`` |
-+--------------------+--------------------+--------------------+--------------------+
-| A=0 | ``put(A,1)`` | ``put(A,2)`` | ``tx2`` will fail, |
-| | | | ``A`` is ``1`` |
-+--------------------+--------------------+--------------------+--------------------+
-| A=0 | ``put(A,1)`` | ``merge(A,2)`` | ``A`` is ``2`` |
-+--------------------+--------------------+--------------------+--------------------+
-| A=0 | ``merge(A,1)`` | ``put(A,2)`` | ``tx2`` will fail, |
-| | | | value of ``A`` is |
-| | | | ``1`` |
-+--------------------+--------------------+--------------------+--------------------+
-| A=0 | ``merge(A,1)`` | ``merge(A,2)`` | ``A`` is ``2`` |
-+--------------------+--------------------+--------------------+--------------------+
-| A=0 | ``delete(A)`` | ``put(A,2)`` | ``tx2`` will fail, |
-| | | | ``A`` does not |
-| | | | exists |
-+--------------------+--------------------+--------------------+--------------------+
-| A=0 | ``delete(A)`` | ``merge(A,2)`` | ``A`` is ``2`` |
-+--------------------+--------------------+--------------------+--------------------+
-
-Table: Concurrent change resolution for leaves and leaf-list items
-
-+--------------------+--------------------+--------------------+--------------------+
-| Initial state | ``tx1`` | ``tx2`` | Result |
-+====================+====================+====================+====================+
-| Empty | put(TOP,[]) | put(TOP,[]) | ``tx2`` will fail, |
-| | | | state is TOP=[] |
-+--------------------+--------------------+--------------------+--------------------+
-| Empty | put(TOP,[]) | merge(TOP,[]) | TOP=[] |
-+--------------------+--------------------+--------------------+--------------------+
-| Empty | put(TOP,[FOO=1]) | put(TOP,[BAR=1]) | ``tx2`` will fail, |
-| | | | state is |
-| | | | TOP=[FOO=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| Empty | put(TOP,[FOO=1]) | merge(TOP,[BAR=1]) | TOP=[FOO=1,BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| Empty | merge(TOP,[FOO=1]) | put(TOP,[BAR=1]) | ``tx2`` will fail, |
-| | | | state is |
-| | | | TOP=[FOO=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| Empty | merge(TOP,[FOO=1]) | merge(TOP,[BAR=1]) | TOP=[FOO=1,BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[] | put(TOP,[FOO=1]) | put(TOP,[BAR=1]) | ``tx2`` will fail, |
-| | | | state is |
-| | | | TOP=[FOO=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[] | put(TOP,[FOO=1]) | merge(TOP,[BAR=1]) | state is |
-| | | | TOP=[FOO=1,BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[] | merge(TOP,[FOO=1]) | put(TOP,[BAR=1]) | ``tx2`` will fail, |
-| | | | state is |
-| | | | TOP=[FOO=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[] | merge(TOP,[FOO=1]) | merge(TOP,[BAR=1]) | state is |
-| | | | TOP=[FOO=1,BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[] | delete(TOP) | put(TOP,[BAR=1]) | ``tx2`` will fail, |
-| | | | state is empty |
-| | | | store |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[] | delete(TOP) | merge(TOP,[BAR=1]) | state is |
-| | | | TOP=[BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[] | put(TOP/FOO,1) | put(TOP/BAR,1]) | state is |
-| | | | TOP=[FOO=1,BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[] | put(TOP/FOO,1) | merge(TOP/BAR,1) | state is |
-| | | | TOP=[FOO=1,BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[] | merge(TOP/FOO,1) | put(TOP/BAR,1) | state is |
-| | | | TOP=[FOO=1,BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[] | merge(TOP/FOO,1) | merge(TOP/BAR,1) | state is |
-| | | | TOP=[FOO=1,BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[] | delete(TOP) | put(TOP/BAR,1) | ``tx2`` will fail, |
-| | | | state is empty |
-| | | | store |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[] | delete(TOP) | merge(TOP/BAR,1] | ``tx2`` will fail, |
-| | | | state is empty |
-| | | | store |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[FOO=1] | put(TOP/FOO,2) | put(TOP/BAR,1) | state is |
-| | | | TOP=[FOO=2,BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[FOO=1] | put(TOP/FOO,2) | merge(TOP/BAR,1) | state is |
-| | | | TOP=[FOO=2,BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[FOO=1] | merge(TOP/FOO,2) | put(TOP/BAR,1) | state is |
-| | | | TOP=[FOO=2,BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[FOO=1] | merge(TOP/FOO,2) | merge(TOP/BAR,1) | state is |
-| | | | TOP=[FOO=2,BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[FOO=1] | delete(TOP/FOO) | put(TOP/BAR,1) | state is |
-| | | | TOP=[BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-| TOP=[FOO=1] | delete(TOP/FOO) | merge(TOP/BAR,1] | state is |
-| | | | TOP=[BAR=1] |
-+--------------------+--------------------+--------------------+--------------------+
-
-Table: Concurrent change resolution for containers, lists, list items
-
-MD-SAL RPC routing
-------------------
-
-The MD-SAL provides a way to deliver Remote Procedure Calls (RPCs) to a
-particular implementation based on content in the input as it is modeled
-in YANG. This part of the the RPC input is referred to as a **context
-reference**.
-
-The MD-SAL does not dictate the name of the leaf which is used for this
-RPC routing, but provides necessary functionality for YANG model author
-to define their **context reference** in their model of RPCs.
-
-MD-SAL routing behavior is modeled using following terminology and its
-application to YANG models:
-
-Context Type
- Logical type of RPC routing. Context type is modeled as YANG
- ``identity`` and is referenced in model to provide scoping
- information.
-
-Context Instance
- Conceptual location in data tree, which represents context in which
- RPC could be executed. Context instance usually represent logical
- point to which RPC execution is attached.
-
-Context Reference
- Field of RPC input payload which contains Instance Identifier
- referencing **context instance** in which the RPC should be
- executed.
-
-Modeling a routed RPC
-~~~~~~~~~~~~~~~~~~~~~
-
-In order to define routed RPCs, the YANG model author needs to declare
-(or reuse) a **context type**, set of possible **context instances** and
-finally RPCs which will contain **context reference** on which they will
-be routed.
-
-Declaring a routing context type
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. code::
-
- identity node-context {
- description "Identity used to mark node context";
- }
-
-This declares an identity named ``node-context``, which is used as
-marker for node-based routing and is used in other places to reference
-that routing type.
-
-Declaring possible context instances
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-In order to define possible values of **context instances** for routed
-RPCs, we need to model that set accordingly using ``context-instance``
-extension from the ``yang-ext`` model.
-
-.. code::
-
- import yang-ext { prefix ext; }
-
- /** Base structure **/
- container nodes {
- list node {
- key "id";
- ext:context-instance "node-context";
- // other node-related fields would go here
- }
- }
-
-The statement ``ext:context-instance "node-context";`` marks any element
-of the ``list node`` as a possible valid **context instance** in
-``node-context`` based routing.
-
-.. note::
-
- The existence of a **context instance** node in operational or
- config data tree is not strongly tied to existence of RPC
- implementation.
-
- For most routed RPC models, there is relationship between the data
- present in operational data tree and RPC implementation
- availability, but this is not enforced by MD-SAL. This provides some
- flexibility for YANG model writers to better specify their routing
- model and requirements for implementations. Details when RPC
- implementations are available should be documented in YANG model.
-
- If user invokes RPC with a **context instance** that has no
- registered implementation, the RPC invocation will fail with the
- exception ``DOMRpcImplementationNotAvailableException``.
-
-Declaring a routed RPC
-^^^^^^^^^^^^^^^^^^^^^^
-
-To declare RPC to be routed based on ``node-context`` we need to add
-leaf of ``instance-identifier`` type (or type derived from
-``instance-identifier``) to the RPC and mark it as **context
-reference**.
-
-This is achieved using YANG extension ``context-reference`` from
-``yang-ext`` model on leaf, which will be used for RPC routing.
-
-.. code::
-
- rpc example-routed-rpc {
- input {
- leaf node {
- ext:context-reference "node-context";
- type "instance-identifier";
- }
- // other input to the RPC would go here
- }
- }
-
-The statement ``ext:context-reference "node-context"`` marks
-``leaf node`` as **context reference** of type ``node-context``. The
-value of this leaf, will be used by the MD-SAL to select the particular
-RPC implementation that registered itself as the implementation of the
-RPC for particular **context instance**.
-
-Using routed RPCs
-~~~~~~~~~~~~~~~~~
-
-From a user perspective (e.g. invoking RPCs) there is no difference
-between routed and non-routed RPCs. Routing information is just an
-additional leaf in RPC which must be populated.
-
-Implementing a routed RPC
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Implementation
-
-Registering implementations
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Implementations of a routed RPC (e.g., southbound plugins) will specify
-an instance-identifier for the **context reference** (in this case a
-node) for which they want to provide an implementation during
-registration. Consumers, e.g., those calling the RPC are required to
-specify that instance-identifier (in this case the identifier of a node)
-when invoking RPC.
-
-Simple code which showcases that for add-flow via Binding-Aware APIs
-(`RoutedServiceTest.java <https://git.opendaylight.org/gerrit/gitweb?p=controller.git;a=blob;f=opendaylight/md-sal/sal-binding-it/src/test/java/org/opendaylight/controller/test/sal/binding/it/RoutedServiceTest.java;h=d49d6f0e25e271e43c8550feb5eef63d96301184;hb=HEAD>`__
-):
-
-.. code:: java
-
- 61 @Override
- 62 public void onSessionInitiated(ProviderContext session) {
- 63 assertNotNull(session);
- 64 firstReg = session.addRoutedRpcImplementation(SalFlowService.class, salFlowService1);
- 65 }
-
-Line 64: We are registering salFlowService1 as implementation of
-SalFlowService RPC
-
-.. code:: java
-
- 107 NodeRef nodeOne = createNodeRef("foo:node:1");
- 109 /**
- 110 * Provider 1 registers path of node 1
- 111 */
- 112 firstReg.registerPath(NodeContext.class, nodeOne);
-
-Line 107: We are creating NodeRef (encapsulation of InstanceIdentifier)
-for "foo:node:1".
-
-Line 112: We register salFlowService1 as implementation for nodeOne.
-
-The salFlowService1 will be executed only for RPCs which contains
-Instance Identifier for foo:node:1.
-
-RPCs and cluster
-^^^^^^^^^^^^^^^^
-
-In case there is is only a single provider of an RPC in the cluster
-the RPC registration is propagated to other nodes via Gossip protocol
-and the RPC calls from other nodes are correctly routed to the
-provider. Since the registrations are not expected to change rapidly
-there is a latency of about 1 second until the registration is reflected
-on the remote nodes.
-
-
-OpenDaylight Controller MD-SAL: RESTCONF
-----------------------------------------
-
-RESTCONF operations overview
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-| RESTCONF allows access to datastores in the controller.
-| There are two datastores:
-
-- Config: Contains data inserted via controller
-
-- Operational: Contains other data
-
-.. note::
-
- | Each request must start with the URI /restconf.
- | RESTCONF listens on port 8080 for HTTP requests.
-
-RESTCONF supports **OPTIONS**, **GET**, **PUT**, **POST**, and
-**DELETE** operations. Request and response data can either be in the
-XML or JSON format. XML structures according to yang are defined at:
-`XML-YANG <http://tools.ietf.org/html/rfc6020>`__. JSON structures are
-defined at:
-`JSON-YANG <http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-02>`__.
-Data in the request must have a correctly set **Content-Type** field in
-the http header with the allowed value of the media type. The media type
-of the requested data has to be set in the **Accept** field. Get the
-media types for each resource by calling the OPTIONS operation. Most of
-the paths of the pathsRestconf endpoints use `Instance
-Identifier <https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Concepts#Instance_Identifier>`__.
-``<identifier>`` is used in the explanation of the operations.
-
-| **<identifier>**
-
-- It must start with <moduleName>:<nodeName> where <moduleName> is a
- name of the module and <nodeName> is the name of a node in the
- module. It is sufficient to just use <nodeName> after
- <moduleName>:<nodeName>. Each <nodeName> has to be separated by /.
-
-- <nodeName> can represent a data node which is a list or container
- yang built-in type. If the data node is a list, there must be defined
- keys of the list behind the data node name for example,
- <nodeName>/<valueOfKey1>/<valueOfKey2>.
-
-- | The format <moduleName>:<nodeName> has to be used in this case as
- well:
- | Module A has node A1. Module B augments node A1 by adding node X.
- Module C augments node A1 by adding node X. For clarity, it has to
- be known which node is X (for example: C:X). For more details about
- encoding, see: `RESTCONF 02 - Encoding YANG Instance Identifiers in
- the Request
- URI. <http://tools.ietf.org/html/draft-bierman-netconf-restconf-02#section-5.3.1>`__
-
-Mount point
-~~~~~~~~~~~
-
-| A Node can be behind a mount point. In this case, the URI has to be in
- format <identifier>/**yang-ext:mount**/<identifier>. The first
- <identifier> is the path to a mount point and the second <identifier>
- is the path to a node behind the mount point. A URI can end in a mount
- point itself by using <identifier>/**yang-ext:mount**.
-| More information on how to actually use mountpoints is available at:
- `OpenDaylight
- Controller:Config:Examples:Netconf <https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf>`__.
-
-HTTP methods
-~~~~~~~~~~~~
-
-OPTIONS /restconf
-^^^^^^^^^^^^^^^^^
-
-- Returns the XML description of the resources with the required
- request and response media types in Web Application Description
- Language (WADL)
-
-GET /restconf/config/<identifier>
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Returns a data node from the Config datastore.
-
-- <identifier> points to a data node which must be retrieved.
-
-GET /restconf/operational/<identifier>
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Returns the value of the data node from the Operational datastore.
-
-- <identifier> points to a data node which must be retrieved.
-
-PUT /restconf/config/<identifier>
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Updates or creates data in the Config datastore and returns the state
- about success.
-
-- <identifier> points to a data node which must be stored.
-
-| **Example:**
-
-::
-
- PUT http://<controllerIP>:8080/restconf/config/module1:foo/bar
- Content-Type: applicaton/xml
- <bar>
- …
- </bar>
-
-| **Example with mount point:**
-
-::
-
- PUT http://<controllerIP>:8080/restconf/config/module1:foo1/foo2/yang-ext:mount/module2:foo/bar
- Content-Type: applicaton/xml
- <bar>
- …
- </bar>
-
-POST /restconf/config
-^^^^^^^^^^^^^^^^^^^^^
-
-- Creates the data if it does not exist
-
-| For example:
-
-::
-
- POST URL: http://localhost:8080/restconf/config/
- content-type: application/yang.data+json
- JSON payload:
-
- {
- "toaster:toaster" :
- {
- "toaster:toasterManufacturer" : "General Electric",
- "toaster:toasterModelNumber" : "123",
- "toaster:toasterStatus" : "up"
- }
- }
-
-POST /restconf/config/<identifier>
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Creates the data if it does not exist in the Config datastore, and
- returns the state about success.
-
-- <identifier> points to a data node where data must be stored.
-
-- The root element of data must have the namespace (data are in XML) or
- module name (data are in JSON.)
-
-| **Example:**
-
-::
-
- POST http://<controllerIP>:8080/restconf/config/module1:foo
- Content-Type: applicaton/xml/
- <bar xmlns=“module1namespace”>
- …
- </bar>
-
-**Example with mount point:**
-
-::
-
- http://<controllerIP>:8080/restconf/config/module1:foo1/foo2/yang-ext:mount/module2:foo
- Content-Type: applicaton/xml
- <bar xmlns=“module2namespace”>
- …
- </bar>
-
-POST /restconf/operations/<moduleName>:<rpcName>
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Invokes RPC.
-
-- <moduleName>:<rpcName> - <moduleName> is the name of the module and
- <rpcName> is the name of the RPC in this module.
-
-- The Root element of the data sent to RPC must have the name “input”.
-
-- The result can be the status code or the retrieved data having the
- root element “output”.
-
-| **Example:**
-
-::
-
- POST http://<controllerIP>:8080/restconf/operations/module1:fooRpc
- Content-Type: applicaton/xml
- Accept: applicaton/xml
- <input>
- …
- </input>
-
- The answer from the server could be:
- <output>
- …
- </output>
-
-| **An example using a JSON payload:**
-
-::
-
- POST http://localhost:8080/restconf/operations/toaster:make-toast
- Content-Type: application/yang.data+json
- {
- "input" :
- {
- "toaster:toasterDoneness" : "10",
- "toaster:toasterToastType":"wheat-bread"
- }
- }
-
-.. note::
-
- Even though this is a default for the toasterToastType value in the
- yang, you still need to define it.
-
-DELETE /restconf/config/<identifier>
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Removes the data node in the Config datastore and returns the state
- about success.
-
-- <identifier> points to a data node which must be removed.
-
-More information is available in the `RESTCONF
-RFC <http://tools.ietf.org/html/draft-bierman-netconf-restconf-02>`__.
-
-How RESTCONF works
-~~~~~~~~~~~~~~~~~~
-
-| RESTCONF uses these base classes:
-
-InstanceIdentifier
- Represents the path in the data tree
-
-ConsumerSession
- Used for invoking RPCs
-
-DataBrokerService
- Offers manipulation with transactions and reading data from the
- datastores
-
-SchemaContext
- Holds information about yang modules
-
-MountService
- Returns MountInstance based on the InstanceIdentifier pointing to a
- mount point
-
-MountInstace
- Contains the SchemaContext behind the mount point
-
-DataSchemaNode
- Provides information about the schema node
-
-SimpleNode
- Possesses the same name as the schema node, and contains the value
- representing the data node value
-
-CompositeNode
- Can contain CompositeNode-s and SimpleNode-s
-
-GET in action
-~~~~~~~~~~~~~
-
-Figure 1 shows the GET operation with URI restconf/config/M:N where M is
-the module name, and N is the node name.
-
-.. figure:: ./images/Get.png
- :alt: Get
-
- Get
-
-1. The requested URI is translated into the InstanceIdentifier which
- points to the data node. During this translation, the DataSchemaNode
- that conforms to the data node is obtained. If the data node is
- behind the mount point, the MountInstance is obtained as well.
-
-2. RESTCONF asks for the value of the data node from DataBrokerService
- based on InstanceIdentifier.
-
-3. DataBrokerService returns CompositeNode as data.
-
-4. StructuredDataToXmlProvider or StructuredDataToJsonProvider is called
- based on the **Accept** field from the http request. These two
- providers can transform CompositeNode regarding DataSchemaNode to an
- XML or JSON document.
-
-5. XML or JSON is returned as the answer on the request from the client.
-
-PUT in action
-~~~~~~~~~~~~~
-
-Figure 2 shows the PUT operation with the URI restconf/config/M:N where
-M is the module name, and N is the node name. Data is sent in the
-request either in the XML or JSON format.
-
-.. figure:: ./images/Put.png
- :alt: Put
-
- Put
-
-1. Input data is sent to JsonToCompositeNodeProvider or
- XmlToCompositeNodeProvider. The correct provider is selected based on
- the Content-Type field from the http request. These two providers can
- transform input data to CompositeNode. However, this CompositeNode
- does not contain enough information for transactions.
-
-2. The requested URI is translated into InstanceIdentifier which points
- to the data node. DataSchemaNode conforming to the data node is
- obtained during this translation. If the data node is behind the
- mount point, the MountInstance is obtained as well.
-
-3. CompositeNode can be normalized by adding additional information from
- DataSchemaNode.
-
-4. RESTCONF begins the transaction, and puts CompositeNode with
- InstanceIdentifier into it. The response on the request from the
- client is the status code which depends on the result from the
- transaction.
-
-Something practical
-~~~~~~~~~~~~~~~~~~~
-
-1. Create a new flow on the switch openflow:1 in table 2.
-
-| **HTTP request**
-
-::
-
- Operation: POST
- URI: http://192.168.11.1:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2
- Content-Type: application/xml
-
-::
-
- <?xml version="1.0" encoding="UTF-8" standalone="no"?>
- <flow
- xmlns="urn:opendaylight:flow:inventory">
- <strict>false</strict>
- <instructions>
- <instruction>
- <order>1</order>
- <apply-actions>
- <action>
- <order>1</order>
- <flood-all-action/>
- </action>
- </apply-actions>
- </instruction>
- </instructions>
- <table_id>2</table_id>
- <id>111</id>
- <cookie_mask>10</cookie_mask>
- <out_port>10</out_port>
- <installHw>false</installHw>
- <out_group>2</out_group>
- <match>
- <ethernet-match>
- <ethernet-type>
- <type>2048</type>
- </ethernet-type>
- </ethernet-match>
- <ipv4-destination>10.0.0.1/24</ipv4-destination>
- </match>
- <hard-timeout>0</hard-timeout>
- <cookie>10</cookie>
- <idle-timeout>0</idle-timeout>
- <flow-name>FooXf22</flow-name>
- <priority>2</priority>
- <barrier>false</barrier>
- </flow>
-
-| **HTTP response**
-
-::
-
- Status: 204 No Content
-
-1. Change *strict* to *true* in the previous flow.
-
-| **HTTP request**
-
-::
-
- Operation: PUT
- URI: http://192.168.11.1:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/111
- Content-Type: application/xml
-
-::
-
- <?xml version="1.0" encoding="UTF-8" standalone="no"?>
- <flow
- xmlns="urn:opendaylight:flow:inventory">
- <strict>true</strict>
- <instructions>
- <instruction>
- <order>1</order>
- <apply-actions>
- <action>
- <order>1</order>
- <flood-all-action/>
- </action>
- </apply-actions>
- </instruction>
- </instructions>
- <table_id>2</table_id>
- <id>111</id>
- <cookie_mask>10</cookie_mask>
- <out_port>10</out_port>
- <installHw>false</installHw>
- <out_group>2</out_group>
- <match>
- <ethernet-match>
- <ethernet-type>
- <type>2048</type>
- </ethernet-type>
- </ethernet-match>
- <ipv4-destination>10.0.0.1/24</ipv4-destination>
- </match>
- <hard-timeout>0</hard-timeout>
- <cookie>10</cookie>
- <idle-timeout>0</idle-timeout>
- <flow-name>FooXf22</flow-name>
- <priority>2</priority>
- <barrier>false</barrier>
- </flow>
-
-| **HTTP response**
-
-::
-
- Status: 200 OK
-
-1. Show flow: check that *strict* is *true*.
-
-| **HTTP request**
-
-::
-
- Operation: GET
- URI: http://192.168.11.1:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/111
- Accept: application/xml
-
-| **HTTP response**
-
-::
-
- Status: 200 OK
-
-::
-
- <?xml version="1.0" encoding="UTF-8" standalone="no"?>
- <flow
- xmlns="urn:opendaylight:flow:inventory">
- <strict>true</strict>
- <instructions>
- <instruction>
- <order>1</order>
- <apply-actions>
- <action>
- <order>1</order>
- <flood-all-action/>
- </action>
- </apply-actions>
- </instruction>
- </instructions>
- <table_id>2</table_id>
- <id>111</id>
- <cookie_mask>10</cookie_mask>
- <out_port>10</out_port>
- <installHw>false</installHw>
- <out_group>2</out_group>
- <match>
- <ethernet-match>
- <ethernet-type>
- <type>2048</type>
- </ethernet-type>
- </ethernet-match>
- <ipv4-destination>10.0.0.1/24</ipv4-destination>
- </match>
- <hard-timeout>0</hard-timeout>
- <cookie>10</cookie>
- <idle-timeout>0</idle-timeout>
- <flow-name>FooXf22</flow-name>
- <priority>2</priority>
- <barrier>false</barrier>
- </flow>
-
-1. Delete the flow created.
-
-| **HTTP request**
-
-::
-
- Operation: DELETE
- URI: http://192.168.11.1:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/2/flow/111
-
-| **HTTP response**
-
-::
-
- Status: 200 OK
-
-Websocket change event notification subscription tutorial
----------------------------------------------------------
-
-Subscribing to data change notifications makes it possible to obtain
-notifications about data manipulation (insert, change, delete) which are
-done on any specified **path** of any specified **datastore** with
-specific **scope**. In following examples *{odlAddress}* is address of
-server where ODL is running and *{odlPort}* is port on which
-OpenDaylight is running.
-
-Websocket notifications subscription process
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-In this section we will learn what steps need to be taken in order to
-successfully subscribe to data change event notifications.
-
-Create stream
-^^^^^^^^^^^^^
-
-In order to use event notifications you first need to call RPC that
-creates notification stream that you can later listen to. You need to
-provide three parameters to this RPC:
-
-- **path**: data store path that you plan to listen to. You can
- register listener on containers, lists and leaves.
-
-- **datastore**: data store type. *OPERATIONAL* or *CONFIGURATION*.
-
-- **scope**: Represents scope of data change. Possible options are:
-
- - BASE: only changes directly to the data tree node specified in the
- path will be reported
-
- - ONE: changes to the node and to direct child nodes will be
- reported
-
- - SUBTREE: changes anywhere in the subtree starting at the node will
- be reported
-
-The RPC to create the stream can be invoked via RESTCONF like this:
-
-- URI:
- http://{odlAddress}:{odlPort}/restconf/operations/sal-remote:create-data-change-event-subscription
-
-- HEADER: Content-Type=application/json
-
-- OPERATION: POST
-
-- DATA:
-
- .. code:: json
-
- {
- "input": {
- "path": "/toaster:toaster/toaster:toasterStatus",
- "sal-remote-augment:datastore": "OPERATIONAL",
- "sal-remote-augment:scope": "ONE"
- }
- }
-
-The response should look something like this:
-
-.. code:: json
-
- {
- "output": {
- "stream-name": "data-change-event-subscription/toaster:toaster/toaster:toasterStatus/datastore=CONFIGURATION/scope=SUBTREE"
- }
- }
-
-**stream-name** is important because you will need to use it when you
-subscribe to the stream in the next step.
-
-.. note::
-
- Internally, this will create a new listener for *stream-name* if it
- did not already exist.
-
-Subscribe to stream
-^^^^^^^^^^^^^^^^^^^
-
-In order to subscribe to stream and obtain WebSocket location you need
-to call *GET* on your stream path. The URI should generally be
-http://{odlAddress}:{odlPort}/restconf/streams/stream/{streamName},
-where *{streamName}* is the *stream-name* parameter contained in
-response from *create-data-change-event-subscription* RPC from the
-previous step.
-
-- URI:
- http://{odlAddress}:{odlPort}/restconf/streams/stream/data-change-event-subscription/toaster:toaster/datastore=CONFIGURATION/scope=SUBTREE
-
-- OPERATION: GET
-
-The subscription call may be modified with the following query parameters defined in the RESTCONF RFC:
-
-- `filter <https://tools.ietf.org/html/draft-ietf-netconf-restconf-05#section-4.8.6>`__
-
-- `start-time <https://tools.ietf.org/html/draft-ietf-netconf-restconf-05#section-4.8.7>`__
-
-- `end-time <https://tools.ietf.org/html/draft-ietf-netconf-restconf-05#section-4.8.8>`__
-
-In addition, the following ODL extension query parameter is supported:
-
-:odl-leaf-nodes-only:
- If this parameter is set to "true", create and update notifications will only
- contain the leaf nodes modified instead of the entire subscription subtree.
- This can help in reducing the size of the notifications.
-
-The expected response status is 200 OK and response body should be
-empty. You will get your WebSocket location from **Location** header of
-response. For example in our particular toaster example location header
-would have this value:
-*ws://{odlAddress}:8185/toaster:toaster/datastore=CONFIGURATION/scope=SUBTREE*
-
-.. note::
-
- During this phase there is an internal check for to see if a
- listener for the *stream-name* from the URI exists. If not, new a
- new listener is registered with the DOM data broker.
-
-Receive notifications
-^^^^^^^^^^^^^^^^^^^^^
-
-You should now have a data change notification stream created and have
-location of a WebSocket. You can use this WebSocket to listen to data
-change notifications. To listen to notifications you can use a
-JavaScript client or if you are using chrome browser you can use the
-`Simple WebSocket
-Client <https://chrome.google.com/webstore/detail/simple-websocket-client/pfdhoblngboilpfeibdedpjgfnlcodoo>`__.
-
-Also, for testing purposes, there is simple Java application named
-WebSocketClient. The application is placed in the
-*-sal-rest-connector-classes.class* project. It accepts a WebSocket URI
-as and input parameter. After starting the utility (WebSocketClient
-class directly in Eclipse/InteliJ Idea) received notifications should be
-displayed in console.
-
-Notifications are always in XML format and look like this:
-
-.. code:: xml
-
- <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
- <eventTime>2014-09-11T09:58:23+02:00</eventTime>
- <data-changed-notification xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:remote">
- <data-change-event>
- <path xmlns:meae="http://netconfcentral.org/ns/toaster">/meae:toaster</path>
- <operation>updated</operation>
- <data>
- <!-- updated data -->
- </data>
- </data-change-event>
- </data-changed-notification>
- </notification>
-
-Example use case
-~~~~~~~~~~~~~~~~
-
-The typical use case is listening to data change events to update web
-page data in real-time. In this tutorial we will be using toaster as the
-base.
-
-When you call *make-toast* RPC, it sets *toasterStatus* to "down" to
-reflect that the toaster is busy making toast. When it finishes,
-*toasterStatus* is set to "up" again. We will listen to this toaster
-status changes in data store and will reflect it on our web page in
-real-time thanks to WebSocket data change notification.
-
-Simple javascript client implementation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-We will create simple JavaScript web application that will listen
-updates on *toasterStatus* leaf and update some element of our web page
-according to new toaster status state.
-
-Create stream
-^^^^^^^^^^^^^
-
-First you need to create stream that you are planing to subscribe to.
-This can be achieved by invoking "create-data-change-event-subscription"
-RPC on RESTCONF via AJAX request. You need to provide data store
-**path** that you plan to listen on, **data store type** and **scope**.
-If the request is successful you can extract the **stream-name** from
-the response and use that to subscribe to the newly created stream. The
-*{username}* and *{password}* fields represent your credentials that you
-use to connect to OpenDaylight via RESTCONF:
-
-.. note::
-
- The default user name and password are "admin".
-
-.. code:: javascript
-
- function createStream() {
- $.ajax(
- {
- url: 'http://{odlAddress}:{odlPort}/restconf/operations/sal-remote:create-data-change-event-subscription',
- type: 'POST',
- headers: {
- 'Authorization': 'Basic ' + btoa('{username}:{password}'),
- 'Content-Type': 'application/json'
- },
- data: JSON.stringify(
- {
- 'input': {
- 'path': '/toaster:toaster/toaster:toasterStatus',
- 'sal-remote-augment:datastore': 'OPERATIONAL',
- 'sal-remote-augment:scope': 'ONE'
- }
- }
- )
- }).done(function (data) {
- // this function will be called when ajax call is executed successfully
- subscribeToStream(data.output['stream-name']);
- }).fail(function (data) {
- // this function will be called when ajax call fails
- console.log("Create stream call unsuccessful");
- })
- }
-
-Subscribe to stream
-^^^^^^^^^^^^^^^^^^^
-
-The Next step is to subscribe to the stream. To subscribe to the stream
-you need to call *GET* on
-*http://{odlAddress}:{odlPort}/restconf/streams/stream/{stream-name}*.
-If the call is successful, you get WebSocket address for this stream in
-**Location** parameter inside response header. You can get response
-header by calling *getResponseHeader(\ *Location*)* on HttpRequest
-object inside *done()* function call:
-
-.. code:: javascript
-
- function subscribeToStream(streamName) {
- $.ajax(
- {
- url: 'http://{odlAddress}:{odlPort}/restconf/streams/stream/' + streamName;
- type: 'GET',
- headers: {
- 'Authorization': 'Basic ' + btoa('{username}:{password}'),
- }
- }
- ).done(function (data, textStatus, httpReq) {
- // we need function that has http request object parameter in order to access response headers.
- listenToNotifications(httpReq.getResponseHeader('Location'));
- }).fail(function (data) {
- console.log("Subscribe to stream call unsuccessful");
- });
- }
-
-Receive notifications
-^^^^^^^^^^^^^^^^^^^^^
-
-Once you got WebSocket server location you can now connect to it and
-start receiving data change events. You need to define functions that
-will handle events on WebSocket. In order to process incoming events
-from OpenDaylight you need to provide a function that will handle
-*onmessage* events. The function must have one parameter that represents
-the received event object. The event data will be stored in
-*event.data*. The data will be in an XML format that you can then easily
-parse using jQuery.
-
-.. code:: javascript
-
- function listenToNotifications(socketLocation) {
- try {
- var notificatinSocket = new WebSocket(socketLocation);
-
- notificatinSocket.onmessage = function (event) {
- // we process our received event here
- console.log('Received toaster data change event.');
- $($.parseXML(event.data)).find('data-change-event').each(
- function (index) {
- var operation = $(this).find('operation').text();
- if (operation == 'updated') {
- // toaster status was updated so we call function that gets the value of toasterStatus leaf
- updateToasterStatus();
- return false;
- }
- }
- );
- }
- notificatinSocket.onerror = function (error) {
- console.log("Socket error: " + error);
- }
- notificatinSocket.onopen = function (event) {
- console.log("Socket connection opened.");
- }
- notificatinSocket.onclose = function (event) {
- console.log("Socket connection closed.");
- }
- // if there is a problem on socket creation we get exception (i.e. when socket address is incorrect)
- } catch(e) {
- alert("Error when creating WebSocket" + e );
- }
- }
-
-The *updateToasterStatus()* function represents function that calls
-*GET* on the path that was modified and sets toaster status in some web
-page element according to received data. After the WebSocket connection
-has been established you can test events by calling make-toast RPC via
-RESTCONF.
-
-.. note::
-
- for more information about WebSockets in JavaScript visit `Writing
- WebSocket client
- applications <https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_client_applications>`__
-
-.. _config_subsystem:
-
-Config Subsystem
-----------------
-
-Overview
-~~~~~~~~
-
-The Controller configuration operation has three stages:
-
-- First, a Proposed configuration is created. Its target is to replace
- the old configuration.
-
-- Second, the Proposed configuration is validated, and then committed.
- If it passes validation successfully, the Proposed configuration
- state will be changed to Validated.
-
-- Finally, a Validated configuration can be Committed, and the affected
- modules can be reconfigured.
-
-In fact, each configuration operation is wrapped in a transaction. Once
-a transaction is created, it can be configured, that is to say, a user
-can abort the transaction during this stage. After the transaction
-configuration is done, it is committed to the validation stage. In this
-stage, the validation procedures are invoked. If one or more validations
-fail, the transaction can be reconfigured. Upon success, the second
-phase commit is invoked. If this commit is successful, the transaction
-enters the last stage, committed. After that, the desired modules are
-reconfigured. If the second phase commit fails, it means that the
-transaction is unhealthy - basically, a new configuration instance
-creation failed, and the application can be in an inconsistent state.
-
-.. figure:: ./images/configuration.jpg
- :alt: Configuration states
-
- Configuration states
-
-.. figure:: ./images/Transaction.jpg
- :alt: Transaction states
-
- Transaction states
-
-Validation
-~~~~~~~~~~
-
-To secure the consistency and safety of the new configuration and to
-avoid conflicts, the configuration validation process is necessary.
-Usually, validation checks the input parameters of a new configuration,
-and mostly verifies module-specific relationships. The validation
-procedure results in a decision on whether the proposed configuration is
-healthy.
-
-Dependency resolver
-~~~~~~~~~~~~~~~~~~~
-
-Since there can be dependencies between modules, a change in a module
-configuration can affect the state of other modules. Therefore, we need
-to verify whether dependencies on other modules can be resolved. The
-Dependency Resolver acts in a manner similar to dependency injectors.
-Basically, a dependency tree is built.
-
-APIs and SPIs
-~~~~~~~~~~~~~
-
-This section describes configuration system APIs and SPIs.
-
-SPIs
-^^^^
-
-**Module** org.opendaylight.controller.config.spi. Module is the common
-interface for all modules: every module must implement it. The module is
-designated to hold configuration attributes, validate them, and create
-instances of service based on the attributes. This instance must
-implement the AutoCloseable interface, owing to resources clean up. If
-the module was created from an already running instance, it contains an
-old instance of the module. A module can implement multiple services. If
-the module depends on other modules, setters need to be annotated with
-@RequireInterface.
-
-**Module creation**
-
-1. The module needs to be configured, set with all required attributes.
-
-2. The module is then moved to the commit stage for validation. If the
- validation fails, the module attributes can be reconfigured.
- Otherwise, a new instance is either created, or an old instance is
- reconfigured. A module instance is identified by ModuleIdentifier,
- consisting of the factory name and instance name.
-
-| **ModuleFactory** org.opendaylight.controller.config.spi. The
- ModuleFactory interface must be implemented by each module factory.
-| A module factory can create a new module instance in two ways:
-
-- From an existing module instance
-
-- | An entirely new instance
- | ModuleFactory can also return default modules, useful for
- populating registry with already existing configurations. A module
- factory implementation must have a globally unique name.
-
-APIs
-^^^^
-
-+--------------------------------------+--------------------------------------+
-| ConfigRegistry | Represents functionality provided by |
-| | a configuration transaction (create, |
-| | destroy module, validate, or abort |
-| | transaction). |
-+--------------------------------------+--------------------------------------+
-| ConfigTransactionController | Represents functionality for |
-| | manipulating with configuration |
-| | transactions (begin, commit config). |
-+--------------------------------------+--------------------------------------+
-| RuntimeBeanRegistratorAwareConfiBean | The module implementing this |
-| | interface will receive |
-| | RuntimeBeanRegistrator before |
-| | getInstance is invoked. |
-+--------------------------------------+--------------------------------------+
-
-Runtime APIs
-^^^^^^^^^^^^
-
-+--------------------------------------+--------------------------------------+
-| RuntimeBean | Common interface for all runtime |
-| | beans |
-+--------------------------------------+--------------------------------------+
-| RootRuntimeBeanRegistrator | Represents functionality for root |
-| | runtime bean registration, which |
-| | subsequently allows hierarchical |
-| | registrations |
-+--------------------------------------+--------------------------------------+
-| HierarchicalRuntimeBeanRegistration | Represents functionality for runtime |
-| | bean registration and |
-| | unreregistration from hierarchy |
-+--------------------------------------+--------------------------------------+
-
-JMX APIs
-^^^^^^^^
-
-| JMX API is purposed as a transition between the Client API and the JMX
- platform.
-
-+--------------------------------------+--------------------------------------+
-| ConfigTransactionControllerMXBean | Extends ConfigTransactionController, |
-| | executed by Jolokia clients on |
-| | configuration transaction. |
-+--------------------------------------+--------------------------------------+
-| ConfigRegistryMXBean | Represents entry point of |
-| | configuration management for |
-| | MXBeans. |
-+--------------------------------------+--------------------------------------+
-| Object names | Object Name is the pattern used in |
-| | JMX to locate JMX beans. It consists |
-| | of domain and key properties (at |
-| | least one key-value pair). Domain is |
-| | defined as |
-| | "org.opendaylight.controller". The |
-| | only mandatory property is "type". |
-+--------------------------------------+--------------------------------------+
-
-Use case scenarios
-^^^^^^^^^^^^^^^^^^
-
-| A few samples of successful and unsuccessful transaction scenarios
- follow:
-
-**Successful commit scenario**
-
-1. The user creates a transaction calling creteTransaction() method on
- ConfigRegistry.
-
-2. ConfigRegisty creates a transaction controller, and registers the
- transaction as a new bean.
-
-3. Runtime configurations are copied to the transaction. The user can
- create modules and set their attributes.
-
-4. The configuration transaction is to be committed.
-
-5. The validation process is performed.
-
-6. After successful validation, the second phase commit begins.
-
-7. Modules proposed to be destroyed are destroyed, and their service
- instances are closed.
-
-8. Runtime beans are set to registrator.
-
-9. The transaction controller invokes the method getInstance on each
- module.
-
-10. The transaction is committed, and resources are either closed or
- released.
-
-| **Validation failure scenario**
-| The transaction is the same as the previous case until the validation
- process.
-
-1. If validation fails, (that is to day, illegal input attributes values
- or dependency resolver failure), the validationException is thrown
- and exposed to the user.
-
-2. The user can decide to reconfigure the transaction and commit again,
- or abort the current transaction.
-
-3. On aborted transactions, TransactionController and JMXRegistrator are
- properly closed.
-
-4. Unregistration event is sent to ConfigRegistry.
-
-Default module instances
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-The configuration subsystem provides a way for modules to create default
-instances. A default instance is an instance of a module, that is
-created at the module bundle start-up (module becomes visible for
-configuration subsystem, for example, its bundle is activated in the
-OSGi environment). By default, no default instances are produced.
-
-The default instance does not differ from instances created later in the
-module life-cycle. The only difference is that the configuration for the
-default instance cannot be provided by the configuration subsystem. The
-module has to acquire the configuration for these instances on its own.
-It can be acquired from, for example, environment variables. After the
-creation of a default instance, it acts as a regular instance and fully
-participates in the configuration subsystem (It can be reconfigured or
-deleted in following transactions.).
+++ /dev/null
-.. _daexim-dev-guide:
-
-##################################
-Data Export/Import Developer Guide
-##################################
-
-Overview
-========
-
-This feature is used to export the system data tree state, or part of,
-to the system's file system. It may also be used to import the system
-data tree state, or part of, from the system's file system.
-
-
-Data Export/Import Architecture
-===============================
-
-The daexim feature consists of a single feature, which interacts with
-MD-SAL to export and import the system data.
-
-
-Key APIs and Interfaces
-=======================
-
-The APIs are available via REST. The details are provided are in user-guide.
-
-
-API Reference Documentation
-===========================
-
-The details of the API are also available in the YANG model for this
-feature. This model is accessiable via the APIDOC explorer interface.
| For example, use the following information in the Firefox plugin
*RESTClient*
- [`https://github.com/chao/RESTClient} <https://github.com/chao/RESTClient}>`__
+ `https://github.com/chao/RESTClient <https://github.com/chao/RESTClient>`_
::
+++ /dev/null
-.. _didm-developer-guide:
-
-DIDM Developer Guide
-====================
-
-Overview
---------
-
-The Device Identification and Driver Management (DIDM) project addresses
-the need to provide device-specific functionality. Device-specific
-functionality is code that performs a feature, and the code is
-knowledgeable of the capability and limitations of the device. For
-example, configuring VLANs and adjusting FlowMods are features, and
-there may be different implementations for different device types.
-Device-specific functionality is implemented as Device Drivers. Device
-Drivers need to be associated with the devices they can be used with. To
-determine this association requires the ability to identify the device
-type.
-
-DIDM Architecture
------------------
-
-The DIDM project creates the infrastructure to support the following
-functions:
-
-- **Discovery** - Determination that a device exists in the controller
- management domain and connectivity to the device can be established.
- For devices that support the OpenFlow protocol, the existing
- discovery mechanism in OpenDaylight suffices. Devices that do not
- support OpenFlow will be discovered through manual means such as the
- operator entering device information via GUI or REST API.
-
-- **Identification** – Determination of the device type.
-
-- **Driver Registration** – Registration of Device Drivers as routed
- RPCs.
-
-- **Synchronization** – Collection of device information, device
- configuration, and link (connection) information.
-
-- **Data Models for Common Features** – Data models will be defined to
- perform common features such as VLAN configuration. For example,
- applications can configure a VLAN by writing the VLAN data to the
- data store as specified by the common data model.
-
-- **RPCs for Common Features** – Configuring VLANs and adjusting
- FlowMods are example of features. RPCs will be defined that specify
- the APIs for these features. Drivers implement features for specific
- devices and support the APIs defined by the RPCs. There may be
- different Driver implementations for different device types.
-
-Key APIs and Interfaces
------------------------
-
-.. _didm-flow-objective-api:
-
-FlowObjective API
-~~~~~~~~~~~~~~~~~
-
-Following are the list of the APIs to create the flow objectives to
-install the flow rule in OpenFlow switch in pipeline agnostic way.
-Currently these APIs are getting consumed by Atrium project.
-
-Install the Forwarding Objective:
-
-``http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward``
-
-Install the Filter Objective
-
-``http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter``
-
-Install the Next Objective:
-
-``http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next``
-
-Flow mod driver API
-~~~~~~~~~~~~~~~~~~~
-
-This release includes a flow mod driver for the HP 3800. This
-driver adjusts the flows and push the same to the device. This API takes
-the flow to be adjusted as input and displays the adjusted flow as
-output in the REST output container. Here is the REST API to adjust and
-push flows to HP 3800 device:
-
-::
-
- http://<CONTROLLER-IP:8181>/restconf/operations/openflow-feature:adjust-flow
-
-Here is an example of an ARP flow and how it gets adjusted and pushed to
-device HP3800:
-
-**adjust-flow input.**
-
-::
-
- <?xml version="1.0" encoding="UTF-8" standalone="no"?>
- <input xmlns="urn:opendaylight:params:xml:ns:yang:didm:drivers:openflow" xmlns:opendaylight-inventory="urn:opendaylight:inventory">
- <node>/opendaylight-inventory:nodes/opendaylight-inventory:node[opendaylight-inventory:id='openflow:673249119553088']</node>
- <flow>
- <match>
- <ethernet-match>
- <ethernet-type>
- <type>2054</type>
- </ethernet-type>
- </ethernet-match>
- </match>
- <flags>SEND_FLOW_REM</flags>
- <priority>0</priority>
- <flow-name>ARP_FLOW</flow-name>
- <instructions>
- <instruction>
- <order>0</order>
- <apply-actions>
- <action>
- <order>0</order>
- <output-action>
- <output-node-connector>CONTROLLER</output-node-connector>
- <max-length>65535</max-length>
- </output-action>
- </action>
- <action>
- <order>1</order>
- <output-action>
- <output-node-connector>NORMAL</output-node-connector>
- <max-length>65535</max-length>
- </output-action>
- </action>
- </apply-actions>
- </instruction>
- </instructions>
- <idle-timeout>180</idle-timeout>
- <hard-timeout>1800</hard-timeout>
- <cookie>10</cookie>
- </flow>
- </input>
-
-In the output, you can see that the table ID has been identified for the
-given flow and two flow mods are created as a result of adjustment. The
-first one is to catch ARP packets in Hardware table 100 with an action
-to goto table 200. The second flow mod is in table 200 with actions:
-output normal and output controller.
-
-**adjust-flow output.**
-
-::
-
- {
- "output": {
- "flow": [
- {
- "idle-timeout": 180,
- "instructions": {
- "instruction": [
- {
- "order": 0,
- "apply-actions": {
- "action": [
- {
- "order": 1,
- "output-action": {
- "output-node-connector": "NORMAL",
- "max-length": 65535
- }
- },
- {
- "order": 0,
- "output-action": {
- "output-node-connector": "CONTROLLER",
- "max-length": 65535
- }
- }
- ]
- }
- }
- ]
- },
- "strict": false,
- "table_id": 200,
- "flags": "SEND_FLOW_REM",
- "cookie": 10,
- "hard-timeout": 1800,
- "match": {
- "ethernet-match": {
- "ethernet-type": {
- "type": 2054
- }
- }
- },
- "flow-name": "ARP_FLOW",
- "priority": 0
- },
- {
- "idle-timeout": 180,
- "instructions": {
- "instruction": [
- {
- "order": 0,
- "go-to-table": {
- "table_id": 200
- }
- }
- ]
- },
- "strict": false,
- "table_id": 100,
- "flags": "SEND_FLOW_REM",
- "cookie": 10,
- "hard-timeout": 1800,
- "match": {},
- "flow-name": "ARP_FLOW",
- "priority": 0
- }
- ]
- }
- }
-
-API Reference Documentation
----------------------------
-
-Go to
-http://${controller-ip}:8181/apidoc/explorer/index.html,
-and look under DIDM section to see all the available REST calls and
-tables
+++ /dev/null
-.. _eman-dev-guide:
-
-eman Developer Guide
-====================
-
-Overview
---------
-
-The OpenDaylight Energy Management (eman) plugin implements an abstract
-Information Model that describes energy measurement and control features
-that may be supported by a variety of device types. The eman plugin may
-support a number of southbound interfaces to accommodate a set of
-protocols, including but not limited to SNMP, NETCONF, IPDR. The plugin
-presents a northbound REST API. This framework enables any number of
-applications to interoperate with any number of devices in order to
-measure and optimize energy usage. The Information Model will be
-inherited from the `SCTE 216 standard – Adaptive Power Systems Interface
-Specification (APSIS)
-<http://www.scte.org/SCTEDocs/Standards/ANSI_SCTE%20216%202015.pdf>`_,
-which in turn inherits definitions within the `IETF eman document set
-<https://datatracker.ietf.org/wg/eman/documents/>`_.
-
-This documentation is directed to developers who may use the eman features
-to build other OpenDaylight features or applications.
-
-eman is composed of 3 Karaf features:
- * ``eman`` incudes the YANG model and its implementation
- * ``eman-api`` adds support for REST
-
-Developers will typically interface with ``eman-api``.
-
-
-eman Architecture
------------------
-
-``eman`` defines a YANG model that represents the IETF energy management
-Information Model, and includes RPCs. The implementation of the model
-currently supports an SNMP 'binding' via interfacing with the
-OpenDaylight SNMP module. In the future, other Southbound protocols may
-be supported.
-
-Developers my use the ``eman-api`` feature to read and write energy
-related data and commands to devices that support the IETF eman MIBS.
-
-Key APIs and Interfaces
------------------------
-
-The eman API currently supports a subset of the IETF eman Information Model,
-including the EnergyObjectPowerMeasurement table. Users of the API may
-get individual attributes or the entire table. When querying the table, the
-results are written into the MD-SAL, for subsequent access. For example,
-a developer may periodically poll a device for its powerMeasurements,
-and fetch a collection of measurements to discover a history of measurements.
-
-
-Operational API
----------------
-
-Via MD-SAL, the following endpoint provides access to previously
-captured power measurements.
-
-.. note::
- "eo" indicates "energy object" as per the IETF Information Model
-
-operational::
-
- eman:eoDevices/eoDevice{id}/eoPowerMeasurement{id}
-
- id indicates an index into a collection
-
-EoDevices may contain a collection of individual eoDevice objects, which
-in turn may contain a collection of eoPowerMeasurement objects
-
-Operations API
---------------
-
-A set of RPCs enable interactions with devices.
-
-get-eoAttribute enables query on an individual attribute of a energy object::
-
- get-eoAttribute
-
- deviceIP indicates IP address of target device
- attribute indicates name of requested attribute
-
-.. note:: Future releases will provide a enumeration of allowed names.
-
-The supported name are:
-
-* eoPower
-* eoPowerNameplate
-* eoPowerUnitMultiplier
-* eoPowerAccuracy
-* eoPowerMeasurementCaliber
-* eoPowerCurrentType
-* eoPowerMeasurementLocal
-* eoPowerAdminState
-* eoPowerOperState
-* eoPowerStateEnterReason
-
-set-eoAttribute enables sending a command to an energy object::
-
- set-eoAttribute
-
- deviceIP. IP address of target device
- attribute. string indicating name of attribute. Currently, no attributes
-
-get-eoDevicePowerMeasures reads an eoPowerMEasurements table from a device
-and stores the result in MD-SAL, making it available vie the operational API::
-
- get-eoDevicePowerMeasures
-
- deviceIP. IP address of target device
-
-API Reference Documentation
----------------------------
-
-See eman project page for additional information:
-https://wiki.opendaylight.org/view/eman:Main
+++ /dev/null
-.. _faas_dev_guide:
-
-Fabric As A Service
-===================
-
-FaaS (Fabric As A service) has two layers of APIs. We describe the top
-level API in the user guide. This document focuses on the Fabric level
-API and describes each API’s semantics and example implementation. The
-second layer defines an abstraction layer called *''Fabric*'' API. The
-idea is to abstract network into a topology formed by a collections of
-fabric objects other than varies of physical devices.Each Fabric object
-provides a collection of unified services.The top level API enables
-application developers or users to write applications to map high level
-model such as GBP, Intent etc… into a logical network model, while the
-lower level gives the application more control to individual fabric
-object level. More importantly the Fabric API is more like SP (Service
-Provider API) a fabric provider or vendor can implement the SPI based on
-its own Fabric technique such as TRILL, SPB etc …
-
-For how to use first level API operation, please refer to user guide for
-more details.
-
-FaaS Architecture
------------------
-
-FaaS Architecture is an 3 layered architecture, on the top is the FaaS
-Application layer, in the middle is the Fabric manager and at the bottom
-are different types of fabric objects. From bottom up, it is
-
-Fabric and its controller (Fabric Controller)
- The Fabric object provides an abstraction of a homogeneous network
- or portion of the network and also has a built in Fabric controller
- which provides management plane and control plane for the fabric.
- The fabric controller implements the services required in Fabric
- Service and monitor and control the fabric operation.
-
-Fabric Manager
- Fabric Manager manages all the fabric objects. also Fabric manager
- acts as a Unified Fabric Controller which provides inter-connect
- fabric control and configuration Also Fabric Manager is FaaS API
- service via Which FaaS user level logical network API (the top level
- API as mentioned previously) exposed and implemented.
-
-FaaS renderer for GBP (Group Based Policy)
- FaaS renderer for GBP is an application of FaaS and provides the
- rendering service between GBP model and logical network model
- provided by Fabric Manager.
-
-Fabric APIs and Interfaces
---------------------------
-
-FaaS APIs have 4 groups as defined below
-
-Fabric Provisioning API
- This set of APIs is used to create and remove Fabric Abstractions,
- in other words, those APIs is to provision the underlay networks and
- prepare to create overlay network(the logical network) on top of it.
-
-Fabric Service API
- This set of APIs is used to create logical network over the Fabrics.
-
-EndPoint API
- EndPoint API is used to bind a physical port which is the location
- of the attachment of an EndPoint happens or will happen.
-
-OAM API
- Those APIs are for Operations, Administration and Maintenance
- purpose and In current release, OAM API is not implemented yet.
-
-Fabric Provisioning API
-~~~~~~~~~~~~~~~~~~~~~~~
-
-- `http://${ipaddress}:8181/restconf/operations/fabric:compose-fabric <http://${ipaddress}:8181/restconf/operations/fabric:compose-fabric>`__
-
-- `http://${ipaddress}:8181/restconf/operations/fabric:decompose-fabric <http://${ipaddress}:8181/restconf/operations/fabric:decompose-fabric>`__
-
-- `http://${ipaddress}:8181/restconf/operations/fabric:get-all-fabrics <http://${ipaddress}:8181/restconf/operations/fabric:get-all-fabrics>`__
-
-Fabric Service API
-~~~~~~~~~~~~~~~~~~
-
-- RESTCONF for creating Logical port, switch, router, routing entries
- and link. Among them, both switches and routers have ports. links
- connect ports.these 5 logical elements are basic building blocks of a
- logical network.
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:create-logical-switch <http://${ipaddress}:8181/restconf/operations/fabric-service:create-logical-switch>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:rm-logical-switch <http://${ipaddress}:8181/restconf/operations/fabric-service:rm-logical-switch>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:create-logical-router <http://${ipaddress}:8181/restconf/operations/fabric-service:create-logical-router>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:rm-logical-router <http://${ipaddress}:8181/restconf/operations/fabric-service:rm-logical-router>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:add-static-route <http://${ipaddress}:8181/restconf/operations/fabric-service:add-static-route>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:create-logic-port <http://${ipaddress}:8181/restconf/operations/fabric-service:create-logic-port>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:rm-logic-port <http://${ipaddress}:8181/restconf/operations/fabric-service:rm-logic-port>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:create-gateway <http://${ipaddress}:8181/restconf/operations/fabric-service:create-gateway>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:rm-gateway <http://${ipaddress}:8181/restconf/operations/fabric-service:rm-gateway>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:port-binding-logical-to-fabric <http://${ipaddress}:8181/restconf/operations/fabric-service:port-binding-logical-to-fabric>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:port-binding-logical-to-device <http://${ipaddress}:8181/restconf/operations/fabric-service:port-binding-logical-to-device>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:add-port-function <http://${ipaddress}:8181/restconf/operations/fabric-service:add-port-function>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:add-acl <http://${ipaddress}:8181/restconf/operations/fabric-service:add-acl>`__
-
- - `http://${ipaddress}:8181/restconf/operations/fabric-service:del-acl <http://${ipaddress}:8181/restconf/operations/fabric-service:del-acl>`__
-
-EndPoint API
-~~~~~~~~~~~~
-
-The following APIs is to bind the physical ports to the logical ports on
-the logical switches:
-
-- `http://${ipaddress}:8181/restconf/operations/fabric-endpoint:register-endpoint <http://${ipaddress}:8181/restconf/operations/fabric-endpoint:register-endpoint>`__
-
-- `http://${ipaddress}:8181/restconf/operations/fabric-endpoint:unregister-endpoint <http://${ipaddress}:8181/restconf/operations/fabric-endpoint:unregister-endpoint>`__
-
-- `http://${ipaddress}:8181/restconf/operations/fabric-endpoint:locate-endpoint <http://${ipaddress}:8181/restconf/operations/fabric-endpoint:locate-endpoint>`__
-
-Others API
-~~~~~~~~~~
-
-- `http://${ipaddress}:8181/restconf/operations/fabric-resource:create-fabric-port <http://${ipaddress}:8181/restconf/operations/fabric-resource:create-fabric-port>`__
-
-API Reference Documentation
----------------------------
-
-Go to
-`http://${ipaddress}:8181/restconf/apidoc/index.html <http://${ipaddress}:8181/restconf/apidoc/index.html>`__
-and expand on *''FaaS*'' related panel for more APIs.
-
.. toctree::
:maxdepth: 1
- alto-developer-guide
- authentication-and-authorization-services
- bgp-developer-guide
- bgp-monitoring-protocol-developer-guide
- bier-developer-guide
- capwap-developer-guide
- cardinal_-opendaylight-monitoring-as-a-service
- controller
- daexim-developer-guide
- didm-developer-guide
distribution-version
distribution-test-features
- eman-developer-guide
- fabric-as-a-service
- iotdm-developer-guide
jsonrpc
- 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
neutron-service-developer-guide
neutron-northbound
odl-parent-developer-guide
- ocp-plugin-developer-guide
- odl-sdni-developer-guide
- of-config-developer-guide
openflow-protocol-library-developer-guide
openflow-plugin-project-developer-guide
- opflex-agent-ovs-developer-guide
- opflex-genie-developer-guide
- opflex-libopflex-developer-guide
ovsdb-developer-guide
- pcep-developer-guide
- packetcable-developer-guide
p4plugin-developer-guide
service-function-chaining
snmp4sdn-developer-guide
- sxp-developer-guide
- topology-processing-framework-developer-guide
- ttp-model-developer-guide
- ttp-cli-tools-developer-guide
- uni-manager-plug-in-developer-guide
unified-secure-channel
- virtual-tenant-network-(vtn)
yang-tools
mvn animal-sniffer:check
-.. _odlparent gerrit patch: https://git.opendaylight.org/gerrit/#/c/64688/
+.. _odlparent gerrit patch: https://git.opendaylight.org/gerrit/64688/
.. _yangtools gerrit patch: https://git.opendaylight.org/gerrit/64781
.. _Animal Sniffer plugin: http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/examples/checking-signatures.html
+++ /dev/null
-.. _iotdm_dev_guide:
-
-IoTDM Developer Guide
-=====================
-
-Overview
---------
-
-The Internet of Things Data Management (IoTDM) on OpenDaylight project
-is about developing a data-centric middleware that will act as a oneM2M
-compliant IoT Data Broker and enable authorized applications to retrieve
-IoT data uploaded by any device. The OpenDaylight platform is used to
-implement the oneM2M data store which models a hierarchical containment
-tree, where each node in the tree represents an oneM2M resource.
-Typically, IoT devices and applications interact with the resource tree
-over standard protocols such as CoAP, MQTT, and HTTP. Initially, the
-oneM2M resource tree is used by applications to retrieve data. Possible
-applications are inventory or device management systems or big data
-analytic systems designed to make sense of the collected data. But, at
-some point, applications will need to configure the devices. Features
-and tools will have to be provided to enable configuration of the
-devices based on applications responding to user input, network
-conditions, or some set of programmable rules or policies possibly
-triggered by the receipt of data collected from the devices. The
-OpenDaylight platform, with its rich unique cross-section of SDN
-capabilities, NFV, and now IoT device and application management, can be
-bundled with a targeted set of features and deployed anywhere in the
-network to give the network service provider ultimate control. Depending
-on the use case, the OpenDaylight IoT platform can be configured with
-only IoT data collection capabilities where it is deployed near the IoT
-devices and its footprint needs to be small, or it can be configured to
-run as a highly scaled up and out distributed cluster with IoT, SDN and
-NFV functions enabled and deployed in a high traffic data center.
-
-oneM2M Architecture
--------------------
-
-The architecture provides a framework that enables the support of the
-oneM2M resource containment tree. The onem2m-core implements the MDSAL
-RPCs defined in the onem2m-api YANG files. These RPCs enable oneM2M
-resources to be created, read, updated, and deleted (CRUD), and also
-enables the management of subscriptions. When resources are CRUDed, the
-onem2m-notifier issues oneM2M notification events to interested
-subscribers. TS0001: oneM2M Functional Architecture and TS0004: oneM2M
-Service Layer Protocol are great reference documents to learn details of
-oneM2M resource types, message flow, formats, and CRUD/N semantics. Both
-of these specifications can be found at
-http://onem2m.org/technical/published-documents
-
-The oneM2M resource tree is modeled in YANG and essentially is a
-meta-model for the tree. The oneM2M wire protocols allow the resource
-tree to be constructed via HTTP or CoAP messages that populate nodes in
-the tree with resource specific attributes. Each oneM2M resource type
-has semantic behaviour associated with it. For example: a container
-resource has attributes which control quotas on how many and how big the
-collection of data or content instance objects that can exist below it
-in the tree. Depending on the resource type, the oneM2M core software
-implements and enforces the resource type specific rules to ensure a
-well-behaved resource tree.
-
-The resource tree can be simultaneously accessed by many concurrent
-applications wishing to manage or access the tree, and also many devices
-can be reporting in new data or sensor readings into their appropriate
-place in the tree.
-
-Key APIs and Interfaces
------------------------
-
-The API’s to access the oneM2M datastore are well documented in TS0004
-(referred above) found on onem2m.org
-
-RESTCONF is available too but generally HTTP and CoAP are used to access
-the oneM2M data tree.
-
+++ /dev/null
-.. _l2switch-dev-guide:
-
-L2Switch Developer Guide
-========================
-
-Overview
---------
-
-The L2Switch project provides Layer2 switch functionality.
-
-L2Switch Architecture
----------------------
-
-- Packet Handler
-
- - Decodes the packets coming to the controller and dispatches them
- appropriately
-
-- Loop Remover
-
- - Removes loops in the network
-
-- Arp Handler
-
- - Handles the decoded ARP packets
-
-- Address Tracker
-
- - Learns the Addresses (MAC and IP) of entities in the network
-
-- Host Tracker
-
- - Tracks the locations of hosts in the network
-
-- L2Switch Main
-
- - Installs flows on each switch based on network traffic
-
-Key APIs and Interfaces
------------------------
-
-- Packet Handler
-
-- Loop Remover
-
-- Arp Handler
-
-- Address Tracker
-
-- Host Tracker
-
-- L2Switch Main
-
-Packet Dispatcher
-~~~~~~~~~~~~~~~~~
-
-Classes
-^^^^^^^
-
-- AbstractPacketDecoder
-
- - Defines the methods that all decoders must implement
-
-- EthernetDecoder
-
- - The base decoder which decodes the packet into an Ethernet packet
-
-- ArpDecoder, Ipv4Decoder, Ipv6Decoder
-
- - Decodes Ethernet packets into the either an ARP or IPv4 or IPv6
- packet
-
-Further development
-^^^^^^^^^^^^^^^^^^^
-
-There is a need for more decoders. A developer can write
-
-- A decoder for another EtherType, i.e. LLDP.
-
-- A higher layer decoder for the body of the IPv4 packet or IPv6
- packet, i.e. TCP and UDP.
-
-How to write a new decoder
-
-- extends AbstractDecoder<A, B>
-
- - A refers to the notification that the new decoder consumes
-
- - B refers to the notification that the new decoder produces
-
-- implements xPacketListener
-
- - The new decoder must specify which notification it is listening to
-
-- canDecode method
-
- - This method should examine the consumed notification to see
- whether the new decoder can decode the contents of the packet
-
-- decode method
-
- - This method does the actual decoding of the packet
-
-Loop Remover
-~~~~~~~~~~~~
-
-Classes
-^^^^^^^
-
-- **LoopRemoverModule**
-
- - Reads config subsystem value for *is-install-lldp-flow*
-
- - If *is-install-lldp-flow* is true, then an
- **InitialFlowWriter** is created
-
- - Creates and initializes the other LoopRemover classes
-
-- **InitialFlowWriter**
-
- - Only created when *is-install-lldp-flow* is true
-
- - Installs a flow, which forwards all LLDP packets to the
- controller, on each switch
-
-- **TopologyLinkDataChangeHandler**
-
- - Listens to data change events on the Topology tree
-
- - When these changes occur, it waits *graph-refresh-delay* seconds
- and then tells **NetworkGraphImpl** to update
-
- - Writes an STP (Spanning Tree Protocol) status of "forwarding" or
- "discarding" to each link in the Topology data tree
-
- - Forwarding links can forward packets.
-
- - Discarding links cannot forward packets.
-
-- **NetworkGraphImpl**
-
- - Creates a loop-free graph of the network
-
-Configuration
-^^^^^^^^^^^^^
-
-- graph-refresh-delay
-
- - Used in TopologyLinkDataChangeHandler
-
- - A higher value has the advantage of doing less graph updates, at
- the potential cost of losing some packets because the graph didn’t
- update immediately.
-
- - A lower value has the advantage of handling network topology
- changes quicker, at the cost of doing more computation.
-
-- is-install-lldp-flow
-
- - Used in LoopRemoverModule
-
- - "true" means a flow that sends all LLDP packets to the controller
- will be installed on each switch
-
- - "false" means this flow will not be installed
-
-- lldp-flow-table-id
-
- - The LLDP flow will be installed on the specified flow table of
- each switch
-
-- lldp-flow-priority
-
- - The LLDP flow will be installed with the specified priority
-
-- lldp-flow-idle-timeout
-
- - The LLDP flow will timeout (removed from the switch) if the flow
- doesn’t forward a packet for *x* seconds
-
-- lldp-flow-hard-timeout
-
- - The LLDP flow will timeout (removed from the switch) after *x*
- seconds, regardless of how many packets it is forwarding
-
-Further development
-^^^^^^^^^^^^^^^^^^^
-
-No suggestions at the moment.
-
-Validating changes to Loop Remover
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-STP Status information is added to the Inventory data tree.
-
-- A status of "forwarding" means the link is active and packets are
- flowing on it.
-
-- A status of "discarding" means the link is inactive and packets are
- not sent over it.
-
-The STP status of a link can be checked through a browser or a REST
-Client.
-
-::
-
- http://10.194.126.91:8080/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/node-connector/openflow:1:2
-
-The STP status should still be there after changes are made.
-
-Arp Handler
-~~~~~~~~~~~
-
-Classes
-^^^^^^^
-
-- **ArpHandlerModule**
-
- - Reads config subsystem value for *is-proactive-flood-mode*
-
- - If *is-proactive-flood-mode* is true, then a
- ProactiveFloodFlowWriter is created
-
- - If *is-proactive-flood-mode* is false, then an
- InitialFlowWriter is created
-
-- **ProactiveFloodFlowWriter**
-
- - Only created when *is-proactive-flood-mode* is true
-
- - Installs a flood flow on each switch. With this flood flow, a
- packet that doesn’t match any other flows will be
- flooded/broadcast from that switch.
-
-- **InitialFlowWriter**
-
- - Only created when *is-proactive-flood-mode* is false
-
- - Installs a flow, which sends all ARP packets to the controller, on
- each switch
-
-- **ArpPacketHandler**
-
- - Only created when *is-proactive-flood-mode* is false
-
- - Handles and processes the controller’s incoming ARP packets
-
- - Uses **PacketDispatcher** to send the ARP packet back into the
- network
-
-- **PacketDispatcher**
-
- - Only created when *is-proactive-flood-mode* is false
-
- - Sends packets out to the network
-
- - Uses **InventoryReader** to determine which node-connector to a
- send a packet on
-
-- **InventoryReader**
-
- - Only created when *is-proactive-flood-mode* is false
-
- - Maintains a list of each switch’s node-connectors
-
-Configuration
-^^^^^^^^^^^^^
-
-- is-proactive-flood-mode
-
- - "true" means that flood flows will be installed on each switch.
- With this flood flow, each switch will flood a packet that doesn’t
- match any other flows.
-
- - Advantage: Fewer packets are sent to the controller because
- those packets are flooded to the network.
-
- - Disadvantage: A lot of network traffic is generated.
-
- - "false" means the previously mentioned flood flows will not be
- installed. Instead an ARP flow will be installed on each switch
- that sends all ARP packets to the controller.
-
- - Advantage: Less network traffic is generated.
-
- - Disadvantage: The controller handles more packets (ARP requests
- & replies) and the ARP process takes longer than if there were
- flood flows.
-
-- flood-flow-table-id
-
- - The flood flow will be installed on the specified flow table of
- each switch
-
-- flood-flow-priority
-
- - The flood flow will be installed with the specified priority
-
-- flood-flow-idle-timeout
-
- - The flood flow will timeout (removed from the switch) if the flow
- doesn’t forward a packet for *x* seconds
-
-- flood-flow-hard-timeout
-
- - The flood flow will timeout (removed from the switch) after *x*
- seconds, regardless of how many packets it is forwarding
-
-- arp-flow-table-id
-
- - The ARP flow will be installed on the specified flow table of each
- switch
-
-- arp-flow-priority
-
- - The ARP flow will be installed with the specified priority
-
-- arp-flow-idle-timeout
-
- - The ARP flow will timeout (removed from the switch) if the flow
- doesn’t forward a packet for *x* seconds
-
-- arp-flow-hard-timeout
-
- - The ARP flow will timeout (removed from the switch) after
- *arp-flow-hard-timeout* seconds, regardless of how many packets it
- is forwarding
-
-Further development
-^^^^^^^^^^^^^^^^^^^
-
-The **ProactiveFloodFlowWriter** needs to be improved. It does have the
-advantage of having less traffic come to the controller; however, it
-generates too much network traffic.
-
-Address Tracker
-~~~~~~~~~~~~~~~
-
-Classes
-^^^^^^^
-
-- AddressTrackerModule
-
- - Reads config subsystem value for *observe-addresses-from*
-
- - If *observe-addresses-from* contains "arp", then an
- AddressObserverUsingArp is created
-
- - If *observe-addresses-from* contains "ipv4", then an
- AddressObserverUsingIpv4 is created
-
- - If *observe-addresses-from* contains "ipv6", then an
- AddressObserverUsingIpv6 is created
-
-- AddressObserverUsingArp
-
- - Registers for ARP packet notifications
-
- - Uses **AddressObservationWriter** to write address observations
- from ARP packets
-
-- AddressObserverUsingIpv4
-
- - Registers for IPv4 packet notifications
-
- - Uses **AddressObservationWriter** to write address observations
- from IPv4 packets
-
-- AddressObserverUsingIpv6
-
- - Registers for IPv6 packet notifications
-
- - Uses **AddressObservationWriter** to write address observations
- from IPv6 packets
-
-- AddressObservationWriter
-
- - Writes new Address Observations to the Inventory data tree
-
- - Updates existing Address Observations with updated "last seen"
- timestamps
-
- - Uses the *timestamp-update-intervval* configuration variable to
- determine whether or not to update
-
-Configuration
-^^^^^^^^^^^^^
-
-- timestamp-update-interval
-
- - A last-seen timestamp is associated with each address. This
- last-seen timestamp will only be updated after
- *timestamp-update-interval* milliseconds.
-
- - A higher value has the advantage of performing less writes to the
- database.
-
- - A lower value has the advantage of knowing how fresh an address
- is.
-
-- observe-addresses-from
-
- - IP and MAC addresses can be observed/learned from ARP, IPv4, and
- IPv6 packets. Set which packets to make these observations from.
-
-Further development
-^^^^^^^^^^^^^^^^^^^
-
-Further improvements can be made to the **AddressObservationWriter** so
-that it (1) doesn’t make any unnecessary writes to the DB and (2) is
-optimized for multi-threaded environments.
-
-Validating changes to Address Tracker
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Address Observations are added to the Inventory data tree.
-
-The Address Observations on a Node Connector can be checked through a
-browser or a REST Client.
-
-::
-
- http://10.194.126.91:8080/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/node-connector/openflow:1:1
-
-The Address Observations should still be there after changes.
-
-Developer’s Guide for Host Tracker
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Validationg changes to Host Tracker
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Host information is added to the Topology data tree.
-
-- Host address
-
-- Attachment point (link) to a node/switch
-
-This host information and attachment point information can be checked
-through a browser or a REST Client.
-
-::
-
- http://10.194.126.91:8080/restconf/operational/network-topology:network-topology/topology/flow:1/
-
-Host information should still be there after changes.
-
-L2Switch Main
-~~~~~~~~~~~~~
-
-Classes
-^^^^^^^
-
-- L2SwitchMainModule
-
- - Reads config subsystem value for *is-install-dropall-flow*
-
- - If *is-install-dropall-flow* is true, then an
- **InitialFlowWriter** is created
-
- - Reads config subsystem value for *is-learning-only-mode*
-
- - If *is-learning-only-mode* is false, then a
- **ReactiveFlowWriter** is created
-
-- InitialFlowWriter
-
- - Only created when *is-install-dropall-flow* is true
-
- - Installs a flow, which drops all packets, on each switch. This
- flow has low priority and means that packets that don’t match any
- higher-priority flows will simply be dropped.
-
-- ReactiveFlowWriter
-
- - Reacts to network traffic and installs MAC-to-MAC flows on
- switches. These flows have matches based on MAC source and MAC
- destination.
-
- - Uses **FlowWriterServiceImpl** to write these flows to the
- switches
-
-- FlowWriterService / FlowWriterServiceImpl
-
- - Writes flows to switches
-
-Configuration
-^^^^^^^^^^^^^
-
-- is-install-dropall-flow
-
- - "true" means a drop-all flow will be installed on each switch, so
- the default action will be to drop a packet instead of sending it
- to the controller
-
- - "false" means this flow will not be installed
-
-- dropall-flow-table-id
-
- - The dropall flow will be installed on the specified flow table of
- each switch
-
- - This field is only relevant when "is-install-dropall-flow" is set
- to "true"
-
-- dropall-flow-priority
-
- - The dropall flow will be installed with the specified priority
-
- - This field is only relevant when "is-install-dropall-flow" is set
- to "true"
-
-- dropall-flow-idle-timeout
-
- - The dropall flow will timeout (removed from the switch) if the
- flow doesn’t forward a packet for *x* seconds
-
- - This field is only relevant when "is-install-dropall-flow" is set
- to "true"
-
-- dropall-flow-hard-timeout
-
- - The dropall flow will timeout (removed from the switch) after *x*
- seconds, regardless of how many packets it is forwarding
-
- - This field is only relevant when "is-install-dropall-flow" is set
- to "true"
-
-- is-learning-only-mode
-
- - "true" means that the L2Switch will only be learning addresses. No
- additional flows to optimize network traffic will be installed.
-
- - "false" means that the L2Switch will react to network traffic and
- install flows on the switches to optimize traffic. Currently,
- MAC-to-MAC flows are installed.
-
-- reactive-flow-table-id
-
- - The reactive flow will be installed on the specified flow table of
- each switch
-
- - This field is only relevant when "is-learning-only-mode" is set to
- "false"
-
-- reactive-flow-priority
-
- - The reactive flow will be installed with the specified priority
-
- - This field is only relevant when "is-learning-only-mode" is set to
- "false"
-
-- reactive-flow-idle-timeout
-
- - The reactive flow will timeout (removed from the switch) if the
- flow doesn’t forward a packet for *x* seconds
-
- - This field is only relevant when "is-learning-only-mode" is set to
- "false"
-
-- reactive-flow-hard-timeout
-
- - The reactive flow will timeout (removed from the switch) after *x*
- seconds, regardless of how many packets it is forwarding
-
- - This field is only relevant when "is-learning-only-mode" is set to
- "false"
-
-Further development
-^^^^^^^^^^^^^^^^^^^
-
-The **ReactiveFlowWriter** needs to be improved to install the
-MAC-to-MAC flows faster. For the first ping, the ARP request and reply
-are successful. However, then the ping packets are sent out. The first
-ping packet is dropped sometimes because the MAC-to-MAC flow isn’t
-installed quickly enough. The second, third, and following ping packets
-are successful though.
-
-API Reference Documentation
----------------------------
-
-Further documentation can be found by checking out the L2Switch project.
-
-Checking out the L2Switch project
----------------------------------
-
-::
-
- git clone https://git.opendaylight.org/gerrit/p/l2switch.git
-
-The above command will create a directory called "l2switch" with the
-project.
-
-Testing your changes to the L2Switch project
---------------------------------------------
-
-Running the L2Switch project
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-To run the base distribution, you can use the following command
-
-::
-
- ./distribution/base/target/distributions-l2switch-base-0.1.0-SNAPSHOT-osgipackage/opendaylight/run.sh
-
-If you need additional resources, you can use these command line
-arguments:
-
-::
-
- -Xms1024m -Xmx2048m -XX:PermSize=512m -XX:MaxPermSize=1024m'
-
-To run the karaf distribution, you can use the following command:
-
-::
-
- ./distribution/karaf/target/assembly/bin/karaf
-
-Create a network using mininet
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-::
-
- sudo mn --controller=remote,ip=<Controller IP> --topo=linear,3 --switch ovsk,protocols=OpenFlow13
- sudo mn --controller=remote,ip=127.0.0.1 --topo=linear,3 --switch ovsk,protocols=OpenFlow13
-
-The above command will create a virtual network consisting of 3
-switches. Each switch will connect to the controller located at the
-specified IP, i.e. 127.0.0.1
-
-::
-
- sudo mn --controller=remote,ip=127.0.0.1 --mac --topo=linear,3 --switch ovsk,protocols=OpenFlow13
-
-The above command has the "mac" option, which makes it easier to
-distinguish between Host MAC addresses and Switch MAC addresses.
-
-Generating network traffic using mininet
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-::
-
- h1 ping h2
-
-The above command will cause host1 (h1) to ping host2 (h2)
-
-::
-
- pingall
-
-*pingall* will cause each host to ping every other host.
-
-Miscellaneous mininet commands
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-::
-
- link s1 s2 down
-
-This will bring the link between switch1 (s1) and switch2 (s2) down
-
-::
-
- link s1 s2 up
-
-This will bring the link between switch1 (s1) and switch2 (s2) up
-
-::
-
- link s1 h1 down
-
-This will bring the link between switch1 (s1) and host1 (h1) down
-
+++ /dev/null
-.. _lacp-dev-guide:
-
-LACP Developer Guide
-====================
-
-LACP Overview
--------------
-
-The OpenDaylight LACP (Link Aggregation Control Protocol) project can be
-used to aggregate multiple links between OpenDaylight controlled network
-switches and LACP enabled legacy switches or hosts operating in active
-LACP mode.
-
-OpenDaylight LACP passively negotiates automatic bundling of multiple
-links to form a single LAG (Link Aggregation Group). LAGs are realised
-in the OpenDaylight controlled switches using OpenFlow 1.3+ group table
-functionality.
-
-LACP Architecture
------------------
-
-- **inventory**
-
- - Maintains list of OpenDaylight controlled switches and port
- information
-
- - List of LAGs created and physical ports that are part of the LAG
-
- - Interacts with MD-SAL to update LACP related information
-
-- **inventorylistener**
-
- - This module interacts with MD-SAL for receiving
- node/node-connector notifications
-
-- **flow**
-
- - Programs the switch to punt LACP PDU (Protocol Data Unit) to
- controller
-
-- **packethandler**
-
- - Receives and transmits LACP PDUs to the LACP enabled endpoint
-
- - Provides infrastructure services for group table programming
-
-- **core**
-
- - Performs LACP state machine processing
-
-How LAG programming is implemented
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The LAG representing the aggregated multiple physical ports are realized
-in the OpenDaylight controlled switches by creating a group table entry
-(Group table supported from OpenFlow 1.3 onwards). The group table entry
-has a group type **Select** and action referring to the aggregated
-physical ports. Any data traffic to be sent out through the LAG can be
-sent through the **group entry** available for the LAG.
-
-Suppose there are ports P1-P8 in a node. When LACP project is installed,
-a group table entry for handling broadcast traffic is automatically
-created on all the switches that have registered to the controller.
-
-+--------------------------+--------------------------+--------------------------+
-| GroupID | GroupType | EgressPorts |
-+==========================+==========================+==========================+
-| <B’castgID> | ALL | P1,P2,…P8 |
-+--------------------------+--------------------------+--------------------------+
-
-Now, assume P1 & P2 are now part of LAG1. The group table would be
-programmed as follows:
-
-+--------------------------+--------------------------+--------------------------+
-| GroupID | GroupType | EgressPorts |
-+==========================+==========================+==========================+
-| <B’castgID> | ALL | P3,P4,…P8 |
-+--------------------------+--------------------------+--------------------------+
-| <LAG1> | SELECT | P1,P2 |
-+--------------------------+--------------------------+--------------------------+
-
-When a second LAG, LAG2, is formed with ports P3 and P4,
-
-+--------------------------+--------------------------+--------------------------+
-| GroupID | GroupType | EgressPorts |
-+==========================+==========================+==========================+
-| <B’castgID> | ALL | P5,P6,…P8 |
-+--------------------------+--------------------------+--------------------------+
-| <LAG1> | SELECT | P1,P2 |
-+--------------------------+--------------------------+--------------------------+
-| <LAG2> | SELECT | P3,P4 |
-+--------------------------+--------------------------+--------------------------+
-
-How applications can program OpenFlow flows using LACP-created LAG groups
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-OpenDaylight controller modules can get the information of LAG by
-listening/querying the LACP Aggregator datastore.
-
-When any application receives packets, it can check, if the ingress port
-is part of a LAG by verifying the LAG Aggregator reference
-(lacp-agg-ref) for the source nodeConnector that OpenFlow plugin
-provides.
-
-When applications want to add flows to egress out of the LAG, they must
-use the group entry corresponding to the LAG.
-
-From the above example, for a flow to egress out of LAG1,
-
-**add-flow eth\_type=<xxxx>,ip\_dst=<x.x.x.x>,actions=output:<LAG1>**
-
-Similarly, when applications want traffic to be broadcasted, they should
-use the group table entries **<B’castgID>,<LAG1>,<LAG2>** in output
-action.
-
-For all applications, the group table information is accessible from
-LACP Aggregator datastore.
-
+++ /dev/null
-.. _netconf-dev-guide:
-
-NETCONF Developer Guide
-=======================
-
-.. note::
-
- Reading the NETCONF section in the User Guide is likely useful as it
- contains an overview of NETCONF in OpenDaylight and a how-to for
- spawning and configuring NETCONF connectors.
-
-This chapter is recommended for application developers who want to
-interact with mounted NETCONF devices from their application code. It
-tries to demonstrate all the use cases from user guide with RESTCONF but
-now from the code level. One important difference would be the
-demonstration of NETCONF notifications and notification listeners. The
-notifications were not shown using RESTCONF because **RESTCONF does not
-support notifications from mounted NETCONF devices.**
-
-.. note::
-
- It may also be useful to read the generic `OpenDaylight MD-SAL app
- development
- tutorial <https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:MD-SAL_App_Tutorial>`__
- before diving into this chapter. This guide assumes awareness of
- basic OpenDaylight application development.
-
-Sample app overview
--------------------
-
-All the examples presented here are implemented by a sample OpenDaylight
-application called **ncmount** in the ``coretutorials`` OpenDaylight
-project. It can be found on the github mirror of OpenDaylight’s
-repositories:
-
-- https://github.com/opendaylight/coretutorials/tree/stable/boron/ncmount
-
-or checked out from the official OpenDaylight repository:
-
-- https://git.opendaylight.org/gerrit/#/admin/projects/coretutorials
-
-**The application was built using the** `project startup maven
-archetype <https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Startup_Project_Archetype>`__
-**and demonstrates how to:**
-
-- preconfigure connectors to NETCONF devices
-
-- retrieve MountPointService (registry of available mount points)
-
-- listen and react to changing connection state of netconf-connector
-
-- add custom device YANG models to the app and work with them
-
-- read data from device in binding aware format (generated java APIs
- from provided YANG models)
-
-- write data into device in binding aware format
-
-- trigger and listen to NETCONF notifications in binding aware format
-
-Detailed information about the structure of the application can be found
-at:
-https://wiki.opendaylight.org/view/Controller_Core_Functionality_Tutorials:Tutorials:Netconf_Mount
-
-.. note::
-
- The code in ncmount is fully **binding aware** (works with generated
- java APIs from provided YANG models). However it is also possible to
- perform the same operations in **binding independent** manner.
-
-NcmountProvider
-~~~~~~~~~~~~~~~
-
-The NcmountProvider class (found in NcmountProvider.java) is the central
-point of the ncmount application and all the application logic is
-contained there. The following sections will detail its most interesting
-pieces.
-
-Retrieve MountPointService
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The MountPointService is a central registry of all available mount
-points in OpenDaylight. It is just another MD-SAL service and is
-available from the ``session`` attribute passed by
-``onSessionInitiated`` callback:
-
-::
-
- @Override
- public void onSessionInitiated(ProviderContext session) {
- LOG.info("NcmountProvider Session Initiated");
-
- // Get references to the data broker and mount service
- this.mountService = session.getSALService(MountPointService.class);
-
- ...
-
- }
- }
-
-Listen for connection state changes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-It is important to know when a mount point appears, when it is fully
-connected and when it is disconnected or removed. The exact states of a
-mount point are:
-
-- Connected
-
-- Connecting
-
-- Unable to connect
-
-To receive this kind of information, an application has to register
-itself as a notification listener for the preconfigured netconf-topology
-subtree in MD-SAL’s datastore. This can be performed in the
-``onSessionInitiated`` callback as well:
-
-::
-
- @Override
- public void onSessionInitiated(ProviderContext session) {
-
- ...
-
- this.dataBroker = session.getSALService(DataBroker.class);
-
- // Register ourselves as the REST API RPC implementation
- this.rpcReg = session.addRpcImplementation(NcmountService.class, this);
-
- // Register ourselves as data change listener for changes on Netconf
- // nodes. Netconf nodes are accessed via "Netconf Topology" - a special
- // topology that is created by the system infrastructure. It contains
- // all Netconf nodes the Netconf connector knows about. NETCONF_TOPO_IID
- // is equivalent to the following URL:
- // .../restconf/operational/network-topology:network-topology/topology/topology-netconf
- if (dataBroker != null) {
- this.dclReg = dataBroker.registerDataChangeListener(LogicalDatastoreType.OPERATIONAL,
- NETCONF_TOPO_IID.child(Node.class),
- this,
- DataChangeScope.SUBTREE);
- }
- }
-
-The implementation of the callback from MD-SAL when the data change can
-be found in the
-``onDataChanged(AsyncDataChangeEvent<InstanceIdentifier<?>, DataObject>
-change)`` callback of `NcmountProvider
-class <https://github.com/opendaylight/coretutorials/blob/stable/boron/ncmount/impl/src/main/java/ncmount/impl/NcmountProvider.java>`__.
-
-Reading data from the device
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The first step when trying to interact with the device is to get the
-exact mount point instance (identified by an instance identifier) from
-the MountPointService:
-
-::
-
- @Override
- public Future<RpcResult<ShowNodeOutput>> showNode(ShowNodeInput input) {
- LOG.info("showNode called, input {}", input);
-
- // Get the mount point for the specified node
- // Equivalent to '.../restconf/<config | operational>/opendaylight-inventory:nodes/node/<node-name>/yang-ext:mount/'
- // Note that we can read both config and operational data from the same
- // mount point
- final Optional<MountPoint> xrNodeOptional = mountService.getMountPoint(NETCONF_TOPO_IID
- .child(Node.class, new NodeKey(new NodeId(input.getNodeName()))));
-
- Preconditions.checkArgument(xrNodeOptional.isPresent(),
- "Unable to locate mountpoint: %s, not mounted yet or not configured",
- input.getNodeName());
- final MountPoint xrNode = xrNodeOptional.get();
-
- ....
- }
-
-.. note::
-
- The triggering method in this case is called ``showNode``. It is a
- YANG-defined RPC and NcmountProvider serves as an MD-SAL RPC
- implementation among other things. This means that ``showNode`` an
- be triggered using RESTCONF.
-
-The next step is to retrieve an instance of the ``DataBroker`` API from
-the mount point and start a read transaction:
-
-::
-
- @Override
- public Future<RpcResult<ShowNodeOutput>> showNode(ShowNodeInput input) {
-
- ...
-
- // Get the DataBroker for the mounted node
- final DataBroker xrNodeBroker = xrNode.getService(DataBroker.class).get();
- // Start a new read only transaction that we will use to read data
- // from the device
- final ReadOnlyTransaction xrNodeReadTx = xrNodeBroker.newReadOnlyTransaction();
-
- ...
- }
-
-Finally, it is possible to perform the read operation:
-
-::
-
- @Override
- public Future<RpcResult<ShowNodeOutput>> showNode(ShowNodeInput input) {
-
- ...
-
- InstanceIdentifier<InterfaceConfigurations> iid =
- InstanceIdentifier.create(InterfaceConfigurations.class);
-
- Optional<InterfaceConfigurations> ifConfig;
- try {
- // Read from a transaction is asynchronous, but a simple
- // get/checkedGet makes the call synchronous
- ifConfig = xrNodeReadTx.read(LogicalDatastoreType.CONFIGURATION, iid).checkedGet();
- } catch (ReadFailedException e) {
- throw new IllegalStateException("Unexpected error reading data from " + input.getNodeName(), e);
- }
-
- ...
- }
-
-The instance identifier is used here again to specify a subtree to read
-from the device. At this point application can process the data as it
-sees fit. The ncmount app transforms the data into its own format and
-returns it from ``showNode``.
-
-.. note::
-
- More information can be found in the source code of ncmount sample
- app + on wiki:
- https://wiki.opendaylight.org/view/Controller_Core_Functionality_Tutorials:Tutorials:Netconf_Mount
-
+++ /dev/null
-.. _netide-dev-guide:
-
-NetIDE Developer Guide
-======================
-
-Overview
---------
-
-The NetIDE Network Engine enables portability and cooperation inside a
-single network by using a client/server multi-controller SDN
-architecture. Separate "Client SDN Controllers" host the various SDN
-Applications with their access to the actual physical network abstracted
-and coordinated through a single "Server SDN Controller", in this
-instance OpenDaylight. This allows applications written for
-Ryu/Floodlight/Pyretic to execute on OpenDaylight managed
-infrastructure.
-
-The "Network Engine" is modular by design:
-
-- An OpenDaylight plugin, "shim", sends/receives messages to/from
- subscribed SDN Client Controllers. This consumes the ODL OpenFlow
- Plugin
-
-- An initial suite of SDN Client Controller "Backends": Floodlight,
- Ryu, Pyretic. Further controllers may be added over time as the
- engine is extensible.
-
-The Network Engine provides a compatibility layer capable of translating
-calls of the network applications running on top of the client
-controllers, into calls for the server controller framework. The
-communication between the client and the server layers is achieved
-through the NetIDE intermediate protocol, which is an application-layer
-protocol on top of TCP that transmits the network control/management
-messages from the client to the server controller and vice-versa.
-Between client and server controller sits the Core Layer which also
-"speaks" the intermediate protocol. The core layer implements three main
-functions:
-
-i. interfacing with the client backends and server shim, controlling
- the lifecycle of controllers as well as modules in them,
-
-ii. orchestrating the execution of individual modules (in one client
- controller) or complete applications (possibly spread across
- multiple client controllers),
-
-iii. interfacing with the tools.
-
-.. figure:: ./images/netide/arch-engine.jpg
- :alt: NetIDE Network Engine Architecture
-
- NetIDE Network Engine Architecture
-
-NetIDE Intermediate Protocol
-----------------------------
-
-The Intermediate Protocol serves several needs, it has to:
-
-i. carry control messages between core and shim/backend, e.g., to
- start up/take down a particular module, providing unique
- identifiers for modules,
-
-ii. carry event and action messages between shim, core, and backend,
- properly demultiplexing such messages to the right module based on
- identifiers,
-
-iii. encapsulate messages specific to a particular SBI protocol version
- (e.g., OpenFlow 1.X, NETCONF, etc.) towards the client controllers
- with proper information to recognize these messages as such.
-
-The NetIDE packages can be added as dependencies in Maven projects by
-putting the following code in the *pom.xml* file.
-
-::
-
- <dependency>
- <groupId>org.opendaylight.netide</groupId>
- <artifactId>api</artifactId>
- <version>${NETIDE_VERSION}</version>
- </dependency>
-
-The current stable version for NetIDE is ``0.2.0-Boron``.
-
-Protocol specification
-~~~~~~~~~~~~~~~~~~~~~~
-
-Messages of the NetIDE protocol contain two basic elements: the NetIDE
-header and the data (or payload). The NetIDE header, described below, is
-placed before the payload and serves as the communication and control
-link between the different components of the Network Engine. The payload
-can contain management messages, used by the components of the Network
-Engine to exchange relevant information, or control/configuration
-messages (such as OpenFlow, NETCONF, etc.) crossing the Network Engine
-generated by either network application modules or by the network
-elements.
-
-The NetIDE header is defined as follows:
-
-::
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | netide_ver | type | length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xid |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | module_id |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + datapath_id +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-where each tick mark represents one bit position. Alternatively, in a
-C-style coding format, the NetIDE header can be represented with the
-following structure:
-
-::
-
- struct netide_header {
- uint8_t netide_ver ;
- uint8_t type ;
- uint16_t length ;
- uint32_t xid
- uint32_t module_id
- uint64_t datapath_id
- };
-
-- ``netide_ver`` is the version of the NetIDE protocol (the current
- version is v1.2, which is identified with value 0x03).
-
-- ``length`` is the total length of the payload in bytes.
-
-- ``type`` contains a code that indicates the type of the message
- according with the following values:
-
- ::
-
- enum type {
- NETIDE_HELLO = 0x01 ,
- NETIDE_ERROR = 0x02 ,
- NETIDE_MGMT = 0x03 ,
- MODULE_ANNOUNCEMENT = 0x04 ,
- MODULE_ACKNOWLEDGE = 0x05 ,
- NETIDE_HEARTBEAT = 0x06 ,
- NETIDE_OPENFLOW = 0x11 ,
- NETIDE_NETCONF = 0x12 ,
- NETIDE_OPFLEX = 0x13
- };
-
-- ``datapath_id`` is a 64-bit field that uniquely identifies the
- network elements.
-
-- ``module_id`` is a 32-bits field that uniquely identifies Backends
- and application modules running on top of each client controller. The
- composition mechanism in the core layer leverages on this field to
- implement the correct execution flow of these modules.
-
-- ``xid`` is the transaction identifier associated to the each message.
- Replies must use the same value to facilitate the pairing.
-
-Module announcement
-~~~~~~~~~~~~~~~~~~~
-
-The first operation performed by a Backend is registering itself and the
-modules that it is running to the Core. This is done by using the
-``MODULE_ANNOUNCEMENT`` and ``MODULE_ACKNOWLEDGE`` message types. As a
-result of this process, each Backend and application module can be
-recognized by the Core through an identifier (the ``module_id``) placed
-in the NetIDE header. First, a Backend registers itself by using the
-following schema: backend-<platform name>-<pid>.
-
-For example,odule a Ryu Backend will register by using the following
-name in the message backend-ryu-12345 where 12345 is the process ID of
-the registering instance of the Ryu platform. The format of the message
-is the following:
-
-::
-
- struct NetIDE_message {
- netide_ver = 0x03
- type = MODULE_ANNOUNCEMENT
- length = len(" backend -< platform_name >-<pid >")
- xid = 0
- module_id = 0
- datapath_id = 0
- data = " backend -< platform_name >-<pid >"
- }
-
-The answer generated by the Core will include a ``module_id`` number and
-the Backend name in the payload (the same indicated in the
-``MODULE_ANNOUNCEMENT`` message):
-
-::
-
- struct NetIDE_message {
- netide_ver = 0x03
- type = MODULE_ACKNOWLEDGE
- length = len(" backend -< platform_name >-<pid >")
- xid = 0
- module_id = MODULE_ID
- datapath_id = 0
- data = " backend -< platform_name >-<pid >"
- }
-
-Once a Backend has successfully registered itself, it can start
-registering its modules with the same procedure described above by
-indicating the name of the module in the data (e.g. data="Firewall").
-From this point on, the Backend will insert its own ``module_id`` in the
-header of the messages it generates (e.g. heartbeat, hello messages,
-OpenFlow echo messages from the client controllers, etc.). Otherwise, it
-will encapsulate the control/configuration messages (e.g. FlowMod,
-PacketOut, FeatureRequest, NETCONF request, etc.) generated by network
-application modules with the specific +module\_id+s.
-
-Heartbeat
-~~~~~~~~~
-
-The heartbeat mechanism has been introduced after the adoption of the
-ZeroMQ messaging queuing library to transmit the NetIDE messages.
-Unfortunately, the ZeroMQ library does not offer any mechanism to find
-out about disrupted connections (and also completely unresponsive
-peers). This limitation of the ZeroMQ library can be an issue for the
-Core’s composition mechanism and for the tools connected to the Network
-Engine, as they cannot understand when an client controller disconnects
-or crashes. As a consequence, Backends must periodically send (let’s say
-every 5 seconds) a "heartbeat" message to the Core. If the Core does not
-receive at least one "heartbeat" message from the Backend within a
-certain timeframe, the Core considers it disconnected, removes all the
-related data from its memory structures and informs the relevant tools.
-The format of the message is the following:
-
-::
-
- struct NetIDE_message {
- netide_ver = 0x03
- type = NETIDE_HEARTBEAT
- length = 0
- xid = 0
- module_id = backend -id
- datapath_id = 0
- data = 0
- }
-
-Handshake
-~~~~~~~~~
-
-Upon a successful connection with the Core, the client controller must
-immediately send a hello message with the list of the control and/or
-management protocols needed by the applications deployed on top of it.
-
-::
-
- struct NetIDE_message {
- struct netide_header header ;
- uint8 data [0]
- };
-
-The header contains the following values:
-
-- ``netide ver=0x03``
-
-- ``type=NETIDE_HELLO``
-
-- ``length=2*NR_PROTOCOLS``
-
-- ``data`` contains one 2-byte word (in big endian order) for each
- protocol, with the first byte containing the code of the protocol
- according to the above enum, while the second byte in- dictates the
- version of the protocol (e.g. according to the ONF specification,
- 0x01 for OpenFlow v1.0, 0x02 for OpenFlow v1.1, etc.). NETCONF
- version is marked with 0x01 that refers to the specification in the
- RFC6241, while OpFlex version is marked with 0x00 since this protocol
- is still in work-in-progress stage.
-
-The Core relays hello messages to the server controller which responds
-with another hello message containing the following:
-
-- ``netide ver=0x03``
-
-- ``type=NETIDE_HELLO``
-
-- ``length=2*NR_PROTOCOLS``
-
-If at least one of the protocols requested by the client is supported.
-In particular, ``data`` contains the codes of the protocols that match
-the client’s request (2-bytes words, big endian order). If the hand-
-shake fails because none of the requested protocols is supported by the
-server controller, the header of the answer is as follows:
-
-- ``netide ver=0x03``
-
-- ``type=NETIDE_ERROR``
-
-- ``length=2*NR_PROTOCOLS``
-
-- ``data`` contains the codes of all the protocols supported by the
- server controller (2-bytes words, big endian order). In this case,
- the TCP session is terminated by the server controller just after the
- answer is received by the client. \`
-
+++ /dev/null
-.. _nic-dev-guide:
-
-Network Intent Composition (NIC) Developer Guide
-================================================
-
-Overview
---------
-
-The Network Intent Composition (NIC) provides four features:
-
-- odl-nic-core-hazelcast: Provides a distributed intent mapping
- service, implemented using hazelcast, that stores metadata needed by
- odl-nic-core feature.
-
-- odl-nic-core-mdsal: Provides an intent rest API to external
- applications for CRUD operations on intents, conflict resolution and
- event handling. Uses MD-SAL as backend.
-
-- odl-nic-console: Provides a karaf CLI extension for intent CRUD
- operations and mapping service operations.
-
-- odl-nic-renderer-of - Generic OpenFlow Renderer.
-
-- odl-nic-renderer-vtn - a feature that transforms an intent to a
- network modification using the VTN project
-
-- odl-nic-renderer-gbp - a feature that transforms an intent to a
- network modification using the Group Policy project
-
-- odl-nic-renderer-nemo - a feature that transforms an intent to a
- network modification using the NEMO project
-
-- odl-nic-listeners - adds support for event listening. (depends on:
- odl-nic-renderer-of)
-
-- odl-nic-neutron-integration - allow integration with openstack
- neutron to allow coexistence between existing neutron security rules
- and intents pushed by ODL applications.
-
-*Only a single renderer feature should be installed at a time for the
-Boron release.*
-
-odl-nic-core-mdsal XOR odl-nic-core-hazelcast
----------------------------------------------
-
-This feature supplies the base models for the Network Intent Composition
-(NIC) capability. This includes the definition of intent as well as the
-configuration and operational data trees.
-
-This feature only provides an information model. The interface for NIC
-is to modify the information model via the configuraiton data tree,
-which will trigger the renderer to make the appropriate changes in the
-controlled network.
-
-Installation
-------------
-
-First you need to install one of the core installations:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-::
-
- feature:install odl-nic-core-service-mdsal odl-nic-console
-
-*OR*
-
-::
-
- feature:install odl-nic-core-service-hazelcast odl-nic-console
-
-Then pick a renderer:
-~~~~~~~~~~~~~~~~~~~~~
-
-::
-
- feature:install odl-nic-listeners (will install odl-nic-renderer-of)
-
-*OR*
-
-::
-
- feature:install odl-nic-renderer-vtn
-
-*OR*
-
-::
-
- feature:install odl-nic-renderer-gbp
-
-*OR*
-
-::
-
- feature:install odl-nic-renderer-nemo
-
-REST Supported operations
--------------------------
-
-POST / PUT (configuration)
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This operations create instances of an intent in the configuration data
-tree and trigger the creation or modification of an intent.
-
-GET (configuration / operational)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This operation lists all or fetches a single intent from the data tree.
-
-DELETE (configuration)
-~~~~~~~~~~~~~~~~~~~~~~
-
-This operation will cause an intent to be removed from the system and
-trigger any configuration changes on the network rendered from this
-intent to be removed.
-
-odl-nic-cli user guide
-----------------------
-
-This feature provides karaf console CLI command to manipulate the intent
-data model. The CLI essentailly invokes the equivalent data operations.
-
-intent:add
-~~~~~~~~~~
-
-Creates a new intent in the configuration data tree
-
-::
-
- DESCRIPTION
- intent:add
-
- Adds an intent to the controller.
-
- Examples: --actions [ALLOW] --from <subject> --to <subject>
- --actions [BLOCK] --from <subject>
-
- SYNTAX
- intent:add [options]
-
- OPTIONS
- -a, --actions
- Action to be performed.
- -a / --actions BLOCK/ALLOW
- (defaults to [BLOCK])
- --help
- Display this help message
- -t, --to
- Second Subject.
- -t / --to <subject>
- (defaults to any)
- -f, --from
- First subject.
- -f / --from <subject>
- (defaults to any)
-
-intent:delete
-~~~~~~~~~~~~~
-
-Removes an existing intent from the system
-
-::
-
- DESCRIPTION
- intent:remove
-
- Removes an intent from the controller.
-
- SYNTAX
- intent:remove id
-
- ARGUMENTS
- id Intent Id
-
-intent:list
-~~~~~~~~~~~
-
-Lists all the intents in the system
-
-::
-
- DESCRIPTION
- intent:list
-
- Lists all intents in the controller.
-
- SYNTAX
- intent:list [options]
-
- OPTIONS
- -c, --config
- List Configuration Data (optional).
- -c / --config <ENTER>
- --help
- Display this help message
-
-intent:show
-~~~~~~~~~~~
-
-Displays the details of a single intent
-
-::
-
- DESCRIPTION
- intent:show
-
- Shows detailed information about an intent.
-
- SYNTAX
- intent:show id
-
- ARGUMENTS
- id Intent Id
-
-intent:map
-~~~~~~~~~~
-
-List/Add/Delete current state from/to the mapping service.
-
-::
-
- DESCRIPTION
- intent:map
-
- List/Add/Delete current state from/to the mapping service.
-
- SYNTAX
- intent:map [options]
-
- Examples: --list, -l [ENTER], to retrieve all keys.
- --add-key <key> [ENTER], to add a new key with empty contents.
- --del-key <key> [ENTER], to remove a key with it's values."
- --add-key <key> --value [<value 1>, <value 2>, ...] [ENTER],
- to add a new key with some values (json format).
- OPTIONS
- --help
- Display this help message
- -l, --list
- List values associated with a particular key.
- -l / --filter <regular expression> [ENTER]
- --add-key
- Adds a new key to the mapping service.
- --add-key <key name> [ENTER]
- --value
- Specifies which value should be added/delete from the mapping service.
- --value "key=>value"... --value "key=>value" [ENTER]
- (defaults to [])
- --del-key
- Deletes a key from the mapping service.
- --del-key <key name> [ENTER]
-
-Sample Use case: MPLS
----------------------
-
-Description
-~~~~~~~~~~~
-
-The scope of this use-case is to add MPLS intents between two MPLS
-endpoints. The use-case tries to address the real-world scenario
-illustrated in the diagram below:
-
-.. figure:: ./images/nic/MPLS_VPN_Service_Diagram.png
- :alt: MPLS VPN Service Diagram
-
- MPLS VPN Service Diagram
-
-where PE (Provider Edge) and P (Provider) switches are managed by
-OpenDaylight. In NIC’s terminology the endpoints are the PE switches.
-There could be many P switches between the PEs.
-
-In order for NIC to recognize endpoints as MPLS endpoints, the user is
-expected to add mapping information about the PE switches to NIC’s
-mapping service to include the below properties:
-
-1. MPLS Label to identify a PE
-
-2. IPv4 Prefix for the customer site that are connected to a PE
-
-3. Switch-Port: Ingress (or Egress) for source (or Destination) endpoint
- of the source (or Destination) PE
-
-An intent:add between two MPLS endpoints renders OpenFlow rules for: 1.
-push/pop labels to the MPLS endpoint nodes after an IPv4 Prefix match.
-2. forward to port rule after MPLS label match to all the switches that
-form the shortest path between the endpoints (calculated using Dijkstra
-algorithm).
-
-Additionally, we have also added constraints to Intent model for
-protection and failover mechanism to ensure end-to-end connectivity
-between endpoints. By specifying these constraints to intent:add the
-use-case aims to reduces the risk of connectivity failure due to a
-single link or port down event on a forwarding device.
-
-- Protection constraint: Constraint that requires an end-to-end
- connectivity to be protected by providing redundant paths.
-
-- Failover constraint: Constraint that specifies the type of failover
- implementation. slow-reroute: Uses disjoint path calculation
- algorithms like Suurballe to provide alternate end-to-end routes.
- fast-reroute: Uses failure detection feature in hardware forwarding
- device through OF group table features (Future plans) When no
- constraint is requested by the user we default to offering a since
- end-to-end route using Dijkstra shortest path.
-
-How to use it?
-~~~~~~~~~~~~~~
-
-1. Start Karaf and install related features:
-
- ::
-
- feature:install odl-nic-core-service-mdsal odl-nic-core odl-nic-console odl-nic-listeners
-
-2. Start mininet topology. (verification of topology can be done with the topology
- URI using RESTCONF)
-
- ::
-
- mn --controller=remote,ip=$CONTROLLER_IP --custom ~/shortest_path.py --topo shortest_path --switch ovsk,protocols=OpenFlow13
-
- ::
-
- cat shortest.py -->
- from mininet.topo import Topo
- from mininet.cli import CLI
- from mininet.net import Mininet
- from mininet.link import TCLink
- from mininet.util import irange,dumpNodeConnections
- from mininet.log import setLogLevel
-
- ::
-
- class Fast_Failover_Demo_Topo(Topo):
-
- ::
-
- def __init__(self):
- # Initialize topology and default options
- Topo.__init__(self)
-
- ::
-
- s1 = self.addSwitch('s1',dpid='0000000000000001')
- s2a = self.addSwitch('s2a',dpid='000000000000002a')
- s2b = self.addSwitch('s2b',dpid='000000000000002b')
- s2c = self.addSwitch('s2c',dpid='000000000000002c')
- s3 = self.addSwitch('s3',dpid='0000000000000003')
- self.addLink(s1, s2a)
- self.addLink(s1, s2b)
- self.addLink(s2b, s2c)
- self.addLink(s3, s2a)
- self.addLink(s3, s2c)
- host_1 = self.addHost('h1',ip='10.0.0.1',mac='10:00:00:00:00:01')
- host_2 = self.addHost('h2',ip='10.0.0.2',mac='10:00:00:00:00:02')
- self.addLink(host_1, s1)
- self.addLink(host_2, s3)
-
- ::
-
- topos = { 'shortest_path': ( lambda: Demo_Topo() ) }
-
-3. Update the mapping service with required information
-
- Sample payload:
-
- ::
-
- {
- "mappings": {
- "outer-map": [
- {
- "id": "uva",
- "inner-map": [
- {
- "inner-key": "ip_prefix",
- "value": "10.0.0.1/32"
- },
- {
- "inner-key": "mpls_label",
- "value": "15"
- },
- {
- "inner-key": "switch_port",
- "value": "openflow:1:1"
- }
- ]
- },
- {
- "id": "eur",
- "inner-map": [
- {
- "inner-key": "ip_prefix",
- "value": "10.0.0.2/32"
- },
- {
- "inner-key": "mpls_label",
- "value": "16"
- },
- {
- "inner-key": "switch_port",
- "value": "openflow:3:1"
- }
- ]
- }
- ]
- }
- }
-
-4. Create bidirectional Intents using Karaf command line or RestCONF:
-
- Example:
-
- ::
-
- intent:add -f uva -t eur -a ALLOW
- intent:add -f eur -t uva -a ALLOW
-
-5. Verify by running ovs-ofctl command on mininet if the flows were pushed
- correctly to the nodes that form the shortest path.
-
- Example:
-
- ::
-
- ovs-ofctl -O OpenFlow13 dump-flows s1
-
details. There is nothing special to utilize those Neutron YANG models.
The basic procedure will be:
-1. subscribe for changes made to the the model
+1. subscribe for changes made to the model
2. respond on the data change notification for each models
How to populate this for pseudo agent port binding is documented at
-- http://git.openstack.org/cgit/openstack/networking-odl/tree/doc/source/devref/hostconfig.rst
+- https://git.openstack.org/cgit/openstack/networking-odl/tree/doc/source/devref/hostconfig.rst?id=7fd1258f6e161c035da41c8e95361648a0fb0d7c
Neutron extension config
~~~~~~~~~~~~~~~~~~~~~~~~
- http://developer.openstack.org/api-ref-networking-v2.html
- http://developer.openstack.org/api-ref-networking-v2-ext.html
-
+++ /dev/null
-.. _ocpplugin-dev-guide:
-
-OCP Plugin Developer Guide
-==========================
-
-This document is intended for both OCP (ORI [Open Radio Interface] C&M
-[Control and Management] Protocol) agent developers and OpenDaylight
-service/application developers. It describes essential information
-needed to implement an OCP agent that is capable of interoperating with
-the OCP plugin running in OpenDaylight, including the OCP connection
-establishment and state machines used on both ends of the connection. It
-also provides a detailed description of the northbound/southbound APIs
-that the OCP plugin exposes to allow automation and programmability.
-
-Overview
---------
-
-OCP is an ETSI standard protocol for control and management of Remote
-Radio Head (RRH) equipment. The OCP Project addresses the need for a
-southbound plugin that allows applications and controller services to
-interact with RRHs using OCP. The OCP southbound plugin will allow
-applications acting as a Radio Equipment Control (REC) to interact with
-RRHs that support an OCP agent.
-
-.. figure:: ./images/ocpplugin/ocp-sb-plugin.jpg
- :alt: OCP southbound plugin
-
- OCP southbound plugin
-
-Architecture
-------------
-
-OCP is a vendor-neutral standard communications interface defined to
-enable control and management between RE and REC of an ORI architecture.
-The OCP Plugin supports the implementation of the OCP specification; it
-is based on the Model Driven Service Abstraction Layer (MD-SAL)
-architecture.
-
-The OCP Plugin project consists of three main components: OCP southbound
-plugin, OCP protocol library and OCP service. For details on each of
-them, refer to the OCP Plugin User Guide.
-
-.. figure:: ./images/ocpplugin/plugin-design.jpg
- :alt: Overall architecture
-
- Overall architecture
-
-Connection Establishment
-------------------------
-
-The OCP layer is transported over a TCP/IP connection established
-between the RE and the REC. OCP provides the following functions:
-
-- Control & Management of the RE by the REC
-
-- Transport of AISG/3GPP Iuant Layer 7 messages and alarms between REC
- and RE
-
-Hello Message
-~~~~~~~~~~~~~
-
-Hello message is used by the OCP agent during connection setup. It is
-used for version negotiation. When the connection is established, the
-OCP agent immediately sends a Hello message with the version field set
-to highest OCP version supported by itself, along with the verdor ID and
-serial number of the radio head it is running on.
-
-The combinaiton of the verdor ID and serial number will be used by the
-OCP plugin to uniquely identify a managed radio head. When not receiving
-reply from the OCP plugin, the OCP agent can resend Hello message with
-pre-defined Hello timeout (THLO) and Hello resend times (NHLO).
-
-According to ORI spec, the default value of TCP Link Monitoring Timer
-(TTLM) is 50 seconds. The RE shall trigger an OCP layer restart while
-TTLM expires in RE or the RE detects a TCP link failure. So we may
-define NHLO \* THLO = 50 seconds (e.g. NHLO = 10, THLO = 5 seconds).
-
-By nature the Hello message is a new type of indication, and it contains
-supported OCP version, vendor ID and serial number as shown below.
-
-**Hello message.**
-
-::
-
- <?xml version="1.0" encoding="UTF-8"?>
- <msg xmlns="http://uri.etsi.org/ori/002-2/v4.1.1">
- <header>
- <msgType>IND</msgType>
- <msgUID>0</msgUID>
- </header>
- <body>
- <helloInd>
- <version>4.1.1</version>
- <vendorId>XYZ</vendorId>
- <serialNumber>ABC123</serialNumber>
- </helloInd>
- </body>
- </msg>
-
-Ack Message
-~~~~~~~~~~~
-
-Hello from the OCP agent will always make the OCP plugin respond with
-ACK. In case everything is OK, it will be ACK(OK). In case something is
-wrong, it will be ACK(FAIL).
-
-If the OCP agent receives ACK(OK), it goes to Established state. If the
-OCP agent receives ACK(FAIL), it goes to Maintenance state. The failure
-code and reason of ACK(FAIL) are defined as below:
-
-- FAIL\_OCP\_VERSION (OCP version not supported)
-
-- FAIL\_NO\_MORE\_CAPACITY (OCP plugin cannot control any more radio
- heads)
-
-The result inside Ack message indicates OK or FAIL with different
-reasons.
-
-**Ack message.**
-
-::
-
- <?xml version="1.0" encoding="UTF-8"?>
- <msg xmlns="http://uri.etsi.org/ori/002-2/v4.1.1">
- <header>
- <msgType>ACK</msgType>
- <msgUID>0</msgUID>
- </header>
- <body>
- <helloAck>
- <result>FAIL_OCP_VERSION</result>
- </helloAck>
- </body>
- </msg>
-
-State Machines
-~~~~~~~~~~~~~~
-
-The following figures illustrate the Finite State Machine (FSM) of the
-OCP agent and OCP plugin for new connection procedure.
-
-.. figure:: ./images/ocpplugin/ocpagent-state-machine.jpg
- :alt: OCP agent state machine
-
- OCP agent state machine
-
-.. figure:: ./images/ocpplugin/ocpplugin-state-machine.jpg
- :alt: OCP plugin state machine
-
- OCP plugin state machine
-
-Northbound APIs
----------------
-
-There are ten exposed northbound APIs: health-check, set-time, re-reset,
-get-param, modify-param, create-obj, delete-obj, get-state, modify-state
-and get-fault
-
-health-check
-~~~~~~~~~~~~
-
-The Health Check procedure allows the application to verify that the OCP
-layer is functioning correctly at the RE.
-
-Default URL:
-http://localhost:8181/restconf/operations/ocp-service:health-check-nb
-
-POST Input
-^^^^^^^^^^
-
-+--------------------+----------+--------------------+--------------------+----------+
-| Field Name | Type | Description | Example | Required |
-| | | | | ? |
-+====================+==========+====================+====================+==========+
-| nodeId | String | Inventory node | ocp:MTI-101-200 | Yes |
-| | | reference for OCP | | |
-| | | radio head | | |
-+--------------------+----------+--------------------+--------------------+----------+
-| tcpLinkMonTimeout | unsigned | TCP Link | 50 | Yes |
-| | Short | Monitoring Timeout | | |
-| | | (unit: seconds) | | |
-+--------------------+----------+--------------------+--------------------+----------+
-
-**Example.**
-
-::
-
- {
- "health-check-nb": {
- "input": {
- "nodeId": "ocp:MTI-101-200",
- "tcpLinkMonTimeout": "50"
- }
- }
- }
-
-POST Output
-^^^^^^^^^^^
-
-+--------------------+--------------------+--------------------------------------+
-| Field Name | Type | Description |
-+====================+====================+======================================+
-| result | String, enumerated | Common default result codes |
-+--------------------+--------------------+--------------------------------------+
-
-**Example.**
-
-::
-
- {
- "output": {
- "result": "SUCCESS"
- }
- }
-
-set-time
-~~~~~~~~
-
-The Set Time procedure allows the application to set/update the absolute
-time reference that shall be used by the RE.
-
-Default URL:
-http://localhost:8181/restconf/operations/ocp-service:set-time-nb
-
-POST Input
-^^^^^^^^^^
-
-+------------+------------+----------------------+----------------------+------------+
-| Field Name | Type | Description | Example | Required? |
-+============+============+======================+======================+============+
-| nodeId | String | Inventory node | ocp:MTI-101-200 | Yes |
-| | | reference for OCP | | |
-| | | radio head | | |
-+------------+------------+----------------------+----------------------+------------+
-| newTime | dateTime | New datetime setting | 2016-04-26T10:23:00- | Yes |
-| | | for radio head | 05:00 | |
-+------------+------------+----------------------+----------------------+------------+
-
-**Example.**
-
-::
-
- {
- "set-time-nb": {
- "input": {
- "nodeId": "ocp:MTI-101-200",
- "newTime": "2016-04-26T10:23:00-05:00"
- }
- }
- }
-
-POST Output
-^^^^^^^^^^^
-
-+--------------------+--------------------+--------------------------------------+
-| Field Name | Type | Description |
-+====================+====================+======================================+
-| result | String, enumerated | Common default result codes + |
-| | | FAIL\_INVALID\_TIMEDATA |
-+--------------------+--------------------+--------------------------------------+
-
-**Example.**
-
-::
-
- {
- "output": {
- "result": "SUCCESS"
- }
- }
-
-re-reset
-~~~~~~~~
-
-The RE Reset procedure allows the application to reset a specific RE.
-
-Default URL:
-http://localhost:8181/restconf/operations/ocp-service:re-reset-nb
-
-POST Input
-^^^^^^^^^^
-
-+------------+------------+----------------------+----------------------+------------+
-| Field Name | Type | Description | Example | Required? |
-+============+============+======================+======================+============+
-| nodeId | String | Inventory node | ocp:MTI-101-200 | Yes |
-| | | reference for OCP | | |
-| | | radio head | | |
-+------------+------------+----------------------+----------------------+------------+
-
-**Example.**
-
-::
-
- {
- "re-reset-nb": {
- "input": {
- "nodeId": "ocp:MTI-101-200"
- }
- }
- }
-
-POST Output
-^^^^^^^^^^^
-
-+--------------------+--------------------+--------------------------------------+
-| Field Name | Type | Description |
-+====================+====================+======================================+
-| result | String, enumerated | Common default result codes |
-+--------------------+--------------------+--------------------------------------+
-
-**Example.**
-
-::
-
- {
- "output": {
- "result": "SUCCESS"
- }
- }
-
-get-param
-~~~~~~~~~
-
-The Object Parameter Reporting procedure allows the application to
-retrieve the following information:
-
-1. the defined object types and instances within the Resource Model of
- the RE
-
-2. the values of the parameters of the objects
-
-Default URL:
-http://localhost:8181/restconf/operations/ocp-service:get-param-nb
-
-POST Input
-^^^^^^^^^^
-
-+------------+------------+----------------------+----------------------+------------+
-| Field Name | Type | Description | Example | Required? |
-+============+============+======================+======================+============+
-| nodeId | String | Inventory node | ocp:MTI-101-200 | Yes |
-| | | reference for OCP | | |
-| | | radio head | | |
-+------------+------------+----------------------+----------------------+------------+
-| objId | String | Object ID | RxSigPath\_5G:1 | Yes |
-+------------+------------+----------------------+----------------------+------------+
-| paramName | String | Parameter name | dataLink | Yes |
-+------------+------------+----------------------+----------------------+------------+
-
-**Example.**
-
-::
-
- {
- "get-param-nb": {
- "input": {
- "nodeId": "ocp:MTI-101-200",
- "objId": "RxSigPath_5G:1",
- "paramName": "dataLink"
- }
- }
- }
-
-POST Output
-^^^^^^^^^^^
-
-+--------------------+--------------------+--------------------------------------+
-| Field Name | Type | Description |
-+====================+====================+======================================+
-| id | String | Object ID |
-+--------------------+--------------------+--------------------------------------+
-| name | String | Object parameter name |
-+--------------------+--------------------+--------------------------------------+
-| value | String | Object parameter value |
-+--------------------+--------------------+--------------------------------------+
-| result | String, enumerated | Common default result codes + |
-| | | "FAIL\_UNKNOWN\_OBJECT", |
-| | | "FAIL\_UNKNOWN\_PARAM" |
-+--------------------+--------------------+--------------------------------------+
-
-**Example.**
-
-::
-
- {
- "output": {
- "obj": [
- {
- "id": "RxSigPath_5G:1",
- "param": [
- {
- "name": "dataLink",
- "value": "dataLink:1"
- }
- ]
- }
- ],
- "result": "SUCCESS"
- }
- }
-
-modify-param
-~~~~~~~~~~~~
-
-The Object Parameter Modification procedure allows the application to
-configure the values of the parameters of the objects identified by the
-Resource Model.
-
-Default URL:
-http://localhost:8181/restconf/operations/ocp-service:modify-param-nb
-
-POST Input
-^^^^^^^^^^
-
-+------------+------------+----------------------+----------------------+------------+
-| Field Name | Type | Description | Example | Required? |
-+============+============+======================+======================+============+
-| nodeId | String | Inventory node | ocp:MTI-101-200 | Yes |
-| | | reference for OCP | | |
-| | | radio head | | |
-+------------+------------+----------------------+----------------------+------------+
-| objId | String | Object ID | RxSigPath\_5G:1 | Yes |
-+------------+------------+----------------------+----------------------+------------+
-| name | String | Object parameter | dataLink | Yes |
-| | | name | | |
-+------------+------------+----------------------+----------------------+------------+
-| value | String | Object parameter | dataLink:1 | Yes |
-| | | value | | |
-+------------+------------+----------------------+----------------------+------------+
-
-**Example.**
-
-::
-
- {
- "modify-param-nb": {
- "input": {
- "nodeId": "ocp:MTI-101-200",
- "objId": "RxSigPath_5G:1",
- "param": [
- {
- "name": "dataLink",
- "value": "dataLink:1"
- }
- ]
- }
- }
- }
-
-POST Output
-^^^^^^^^^^^
-
-+--------------------+--------------------+--------------------------------------+
-| Field Name | Type | Description |
-+====================+====================+======================================+
-| objId | String | Object ID |
-+--------------------+--------------------+--------------------------------------+
-| globResult | String, enumerated | Common default result codes + |
-| | | "FAIL\_UNKNOWN\_OBJECT", |
-| | | "FAIL\_PARAMETER\_FAIL", |
-| | | "FAIL\_NOSUCH\_RESOURCE" |
-+--------------------+--------------------+--------------------------------------+
-| name | String | Object parameter name |
-+--------------------+--------------------+--------------------------------------+
-| result | String, enumerated | "SUCCESS", "FAIL\_UNKNOWN\_PARAM", |
-| | | "FAIL\_PARAM\_READONLY", |
-| | | "FAIL\_PARAM\_LOCKREQUIRED", |
-| | | "FAIL\_VALUE\_OUTOF\_RANGE", |
-| | | "FAIL\_VALUE\_TYPE\_ERROR" |
-+--------------------+--------------------+--------------------------------------+
-
-**Example.**
-
-::
-
- {
- "output": {
- "objId": "RxSigPath_5G:1",
- "globResult": "SUCCESS",
- "param": [
- {
- "name": "dataLink",
- "result": "SUCCESS"
- }
- ]
- }
- }
-
-create-obj
-~~~~~~~~~~
-
-The Object Creation procedure allows the application to create and
-initialize a new instance of the given object type on the RE.
-
-Default URL:
-http://localhost:8181/restconf/operations/ocp-service:create-obj-nb
-
-POST Input
-^^^^^^^^^^
-
-+------------+------------+----------------------+----------------------+------------+
-| Field Name | Type | Description | Example | Required? |
-+============+============+======================+======================+============+
-| nodeId | String | Inventory node | ocp:MTI-101-200 | Yes |
-| | | reference for OCP | | |
-| | | radio head | | |
-+------------+------------+----------------------+----------------------+------------+
-| objType | String | Object type | RxSigPath\_5G | Yes |
-+------------+------------+----------------------+----------------------+------------+
-| name | String | Object parameter | dataLink | No |
-| | | name | | |
-+------------+------------+----------------------+----------------------+------------+
-| value | String | Object parameter | dataLink:1 | No |
-| | | value | | |
-+------------+------------+----------------------+----------------------+------------+
-
-**Example.**
-
-::
-
- {
- "create-obj-nb": {
- "input": {
- "nodeId": "ocp:MTI-101-200",
- "objType": "RxSigPath_5G",
- "param": [
- {
- "name": "dataLink",
- "value": "dataLink:1"
- }
- ]
- }
- }
- }
-
-POST Output
-^^^^^^^^^^^
-
-+--------------------+--------------------+--------------------------------------+
-| Field Name | Type | Description |
-+====================+====================+======================================+
-| objId | String | Object ID |
-+--------------------+--------------------+--------------------------------------+
-| globResult | String, enumerated | Common default result codes + |
-| | | "FAIL\_UNKNOWN\_OBJTYPE", |
-| | | "FAIL\_STATIC\_OBJTYPE", |
-| | | "FAIL\_UNKNOWN\_OBJECT", |
-| | | "FAIL\_CHILD\_NOTALLOWED", |
-| | | "FAIL\_OUTOF\_RESOURCES" |
-| | | "FAIL\_PARAMETER\_FAIL", |
-| | | "FAIL\_NOSUCH\_RESOURCE" |
-+--------------------+--------------------+--------------------------------------+
-| name | String | Object parameter name |
-+--------------------+--------------------+--------------------------------------+
-| result | String, enumerated | "SUCCESS", "FAIL\_UNKNOWN\_PARAM", |
-| | | "FAIL\_PARAM\_READONLY", |
-| | | "FAIL\_PARAM\_LOCKREQUIRED", |
-| | | "FAIL\_VALUE\_OUTOF\_RANGE", |
-| | | "FAIL\_VALUE\_TYPE\_ERROR" |
-+--------------------+--------------------+--------------------------------------+
-
-**Example.**
-
-::
-
- {
- "output": {
- "objId": "RxSigPath_5G:0",
- "globResult": "SUCCESS",
- "param": [
- {
- "name": "dataLink",
- "result": "SUCCESS"
- }
- ]
- }
- }
-
-delete-obj
-~~~~~~~~~~
-
-The Object Deletion procedure allows the application to delete a given
-object instance and recursively its entire child objects on the RE.
-
-Default URL:
-http://localhost:8181/restconf/operations/ocp-service:delete-obj-nb
-
-POST Input
-^^^^^^^^^^
-
-+------------+------------+----------------------+----------------------+------------+
-| Field Name | Type | Description | Example | Required? |
-+============+============+======================+======================+============+
-| nodeId | String | Inventory node | ocp:MTI-101-200 | Yes |
-| | | reference for OCP | | |
-| | | radio head | | |
-+------------+------------+----------------------+----------------------+------------+
-| objId | String | Object ID | RxSigPath\_5G:1 | Yes |
-+------------+------------+----------------------+----------------------+------------+
-
-**Example.**
-
-::
-
- {
- "delete-obj-nb": {
- "input": {
- "nodeId": "ocp:MTI-101-200",
- "obj-id": "RxSigPath_5G:0"
- }
- }
- }
-
-POST Output
-^^^^^^^^^^^
-
-+--------------------+--------------------+--------------------------------------+
-| Field Name | Type | Description |
-+====================+====================+======================================+
-| result | String, enumerated | Common default result codes + |
-| | | "FAIL\_UNKNOWN\_OBJECT", |
-| | | "FAIL\_STATIC\_OBJTYPE", |
-| | | "FAIL\_LOCKREQUIRED" |
-+--------------------+--------------------+--------------------------------------+
-
-**Example.**
-
-::
-
- {
- "output": {
- "result": "SUCCESS"
- }
- }
-
-get-state
-~~~~~~~~~
-
-The Object State Reporting procedure allows the application to acquire
-the current state (for the requested state type) of one or more objects
-of the RE resource model, and additionally configure event-triggered
-reporting of the detected state changes for all state types of the
-indicated objects.
-
-Default URL:
-http://localhost:8181/restconf/operations/ocp-service:get-state-nb
-
-POST Input
-^^^^^^^^^^
-
-+--------------------+----------+--------------------+--------------------+----------+
-| Field Name | Type | Description | Example | Required |
-| | | | | ? |
-+====================+==========+====================+====================+==========+
-| nodeId | String | Inventory node | ocp:MTI-101-200 | Yes |
-| | | reference for OCP | | |
-| | | radio head | | |
-+--------------------+----------+--------------------+--------------------+----------+
-| objId | String | Object ID | RxSigPath\_5G:1 | Yes |
-+--------------------+----------+--------------------+--------------------+----------+
-| stateType | String, | Valid values: | ALL | Yes |
-| | enumerat | "AST", "FST", | | |
-| | ed | "ALL" | | |
-+--------------------+----------+--------------------+--------------------+----------+
-| eventDrivenReporti | Boolean | Event-triggered | true | Yes |
-| ng | | reporting of state | | |
-| | | change | | |
-+--------------------+----------+--------------------+--------------------+----------+
-
-**Example.**
-
-::
-
- {
- "get-state-nb": {
- "input": {
- "nodeId": "ocp:MTI-101-200",
- "objId": "antPort:0",
- "stateType": "ALL",
- "eventDrivenReporting": "true"
- }
- }
- }
-
-POST Output
-^^^^^^^^^^^
-
-+--------------------+--------------------+--------------------------------------+
-| Field Name | Type | Description |
-+====================+====================+======================================+
-| id | String | Object ID |
-+--------------------+--------------------+--------------------------------------+
-| type | String, enumerated | State type. Valid values: "AST", |
-| | | "FST |
-+--------------------+--------------------+--------------------------------------+
-| value | String, enumerated | State value. Valid values: For state |
-| | | type = "AST": "LOCKED", "UNLOCKED". |
-| | | For state type = "FST": |
-| | | "PRE\_OPERATIONAL", "OPERATIONAL", |
-| | | "DEGRADED", "FAILED", |
-| | | "NOT\_OPERATIONAL", "DISABLED" |
-+--------------------+--------------------+--------------------------------------+
-| result | String, enumerated | Common default result codes + |
-| | | "FAIL\_UNKNOWN\_OBJECT", |
-| | | "FAIL\_UNKNOWN\_STATETYPE", |
-| | | "FAIL\_VALUE\_OUTOF\_RANGE" |
-+--------------------+--------------------+--------------------------------------+
-
-**Example.**
-
-::
-
- {
- "output": {
- "obj": [
- {
- "id": "antPort:0",
- "state": [
- {
- "type": "FST",
- "value": "DISABLED"
- },
- {
- "type": "AST",
- "value": "LOCKED"
- }
- ]
- }
- ],
- "result": "SUCCESS"
- }
- }
-
-modify-state
-~~~~~~~~~~~~
-
-The Object State Modification procedure allows the application to
-trigger a change in the state of an object of the RE Resource Model.
-
-Default URL:
-http://localhost:8181/restconf/operations/ocp-service:modify-state-nb
-
-POST Input
-^^^^^^^^^^
-
-+------------+------------+----------------------+----------------------+------------+
-| Field Name | Type | Description | Example | Required? |
-+============+============+======================+======================+============+
-| nodeId | String | Inventory node | ocp:MTI-101-200 | Yes |
-| | | reference for OCP | | |
-| | | radio head | | |
-+------------+------------+----------------------+----------------------+------------+
-| objId | String | Object ID | RxSigPath\_5G:1 | Yes |
-+------------+------------+----------------------+----------------------+------------+
-| stateType | String, | Valid values: "AST", | AST | Yes |
-| | enumerated | "FST", "ALL" | | |
-+------------+------------+----------------------+----------------------+------------+
-| stateValue | String, | Valid values: For | LOCKED | Yes |
-| | enumerated | state type = "AST": | | |
-| | | "LOCKED", | | |
-| | | "UNLOCKED". For | | |
-| | | state type = "FST": | | |
-| | | "PRE\_OPERATIONAL", | | |
-| | | "OPERATIONAL", | | |
-| | | "DEGRADED", | | |
-| | | "FAILED", | | |
-| | | "NOT\_OPERATIONAL", | | |
-| | | "DISABLED" | | |
-+------------+------------+----------------------+----------------------+------------+
-
-**Example.**
-
-::
-
- {
- "modify-state-nb": {
- "input": {
- "nodeId": "ocp:MTI-101-200",
- "objId": "RxSigPath_5G:1",
- "stateType": "AST",
- "stateValue": "LOCKED"
- }
- }
- }
-
-POST Output
-^^^^^^^^^^^
-
-+--------------------+--------------------+--------------------------------------+
-| Field Name | Type | Description |
-+====================+====================+======================================+
-| objId | String | Object ID |
-+--------------------+--------------------+--------------------------------------+
-| stateType | String, enumerated | State type. Valid values: "AST", |
-| | | "FST |
-+--------------------+--------------------+--------------------------------------+
-| stateValue | String, enumerated | State value. Valid values: For state |
-| | | type = "AST": "LOCKED", "UNLOCKED". |
-| | | For state type = "FST": |
-| | | "PRE\_OPERATIONAL", "OPERATIONAL", |
-| | | "DEGRADED", "FAILED", |
-| | | "NOT\_OPERATIONAL", "DISABLED" |
-+--------------------+--------------------+--------------------------------------+
-| result | String, enumerated | Common default result codes + |
-| | | "FAIL\_UNKNOWN\_OBJECT", |
-| | | "FAIL\_UNKNOWN\_STATETYPE", |
-| | | "FAIL\_UNKNOWN\_STATEVALUE", |
-| | | "FAIL\_STATE\_READONLY", |
-| | | "FAIL\_RESOURCE\_UNAVAILABLE", |
-| | | "FAIL\_RESOURCE\_INUSE", |
-| | | "FAIL\_PARENT\_CHILD\_CONFLICT", |
-| | | "FAIL\_PRECONDITION\_NOTMET |
-+--------------------+--------------------+--------------------------------------+
-
-**Example.**
-
-::
-
- {
- "output": {
- "objId": "RxSigPath_5G:1",
- "stateType": "AST",
- "stateValue": "LOCKED",
- "result": "SUCCESS",
- }
- }
-
-get-fault
-~~~~~~~~~
-
-The Fault Reporting procedure allows the application to acquire
-information about all current active faults associated with a primary
-object, as well as configure the RE to report when the fault status
-changes for any of faults associated with the indicated primary object.
-
-Default URL:
-http://localhost:8181/restconf/operations/ocp-service:get-fault-nb
-
-POST Input
-^^^^^^^^^^
-
-+------------+------------+----------------------+----------------------+------------+
-| Field Name | Type | Description | Example | Required? |
-+============+============+======================+======================+============+
-| nodeId | String | Inventory node | ocp:MTI-101-200 | Yes |
-| | | reference for OCP | | |
-| | | radio head | | |
-+------------+------------+----------------------+----------------------+------------+
-| objId | String | Object ID | RE:0 | Yes |
-+------------+------------+----------------------+----------------------+------------+
-| eventDrive | Boolean | Event-triggered | true | Yes |
-| nReporting | | reporting of fault | | |
-+------------+------------+----------------------+----------------------+------------+
-
-**Example.**
-
-::
-
- {
- "get-fault-nb": {
- "input": {
- "nodeId": "ocp:MTI-101-200",
- "objId": "RE:0",
- "eventDrivenReporting": "true"
- }
- }
- }
-
-POST Output
-^^^^^^^^^^^
-
-+--------------------+--------------------+--------------------------------------+
-| Field Name | Type | Description |
-+====================+====================+======================================+
-| result | String, enumerated | Common default result codes + |
-| | | "FAIL\_UNKNOWN\_OBJECT", |
-| | | "FAIL\_VALUE\_OUTOF\_RANGE" |
-+--------------------+--------------------+--------------------------------------+
-| id (obj) | String | Object ID |
-+--------------------+--------------------+--------------------------------------+
-| id (fault) | String | Fault ID |
-+--------------------+--------------------+--------------------------------------+
-| severity | String | Fault severity |
-+--------------------+--------------------+--------------------------------------+
-| timestamp | dateTime | Time stamp |
-+--------------------+--------------------+--------------------------------------+
-| descr | String | Text description |
-+--------------------+--------------------+--------------------------------------+
-| affectedObj | String | Affected object |
-+--------------------+--------------------+--------------------------------------+
-
-**Example.**
-
-::
-
- {
- "output": {
- "result": "SUCCESS",
- "obj": [
- {
- "id": "RE:0",
- "fault": [
- {
- "id": "FAULT_OVERTEMP",
- "severity": "DEGRADED",
- "timestamp": "2012-02-12T16:35:00",
- "descr": "PA temp too high; Pout reduced",
- "affectedObj": [
- "TxSigPath_EUTRA:0",
- "TxSigPath_EUTRA:1"
- ]
- },
- {
- "id": "FAULT_VSWR_OUTOF_RANGE",
- "severity": "WARNING",
- "timestamp": "2012-02-12T16:01:05",
- }
- ]
- }
- ],
- }
- }
-
-.. note::
-
- The northbound APIs described above wrap the southbound APIs to make
- them accessible to external applications via RESTCONF, as well as
- take care of synchronizing the RE resource model between radio heads
- and the controller’s datastore. See
- applications/ocp-service/src/main/yang/ocp-resourcemodel.yang for
- the yang representation of the RE resource model.
-
-Java Interfaces (Southbound APIs)
----------------------------------
-
-The southbound APIs provide concrete implementation of the following OCP
-elementary functions: health-check, set-time, re-reset, get-param,
-modify-param, create-obj, delete-obj, get-state, modify-state and
-get-fault. Any OpenDaylight services/applications (of course, including
-OCP service) wanting to speak OCP to radio heads will need to use them.
-
-SalDeviceMgmtService
-~~~~~~~~~~~~~~~~~~~~
-
-Interface SalDeviceMgmtService defines three methods corresponding to
-health-check, set-time and re-reset.
-
-**SalDeviceMgmtService.java.**
-
-::
-
- package org.opendaylight.yang.gen.v1.urn.opendaylight.ocp.device.mgmt.rev150811;
-
- public interface SalDeviceMgmtService
- extends
- RpcService
- {
-
- Future<RpcResult<HealthCheckOutput>> healthCheck(HealthCheckInput input);
-
- Future<RpcResult<SetTimeOutput>> setTime(SetTimeInput input);
-
- Future<RpcResult<ReResetOutput>> reReset(ReResetInput input);
-
- }
-
-SalConfigMgmtService
-~~~~~~~~~~~~~~~~~~~~
-
-Interface SalConfigMgmtService defines two methods corresponding to
-get-param and modify-param.
-
-**SalConfigMgmtService.java.**
-
-::
-
- package org.opendaylight.yang.gen.v1.urn.opendaylight.ocp.config.mgmt.rev150811;
-
- public interface SalConfigMgmtService
- extends
- RpcService
- {
-
- Future<RpcResult<GetParamOutput>> getParam(GetParamInput input);
-
- Future<RpcResult<ModifyParamOutput>> modifyParam(ModifyParamInput input);
-
- }
-
-SalObjectLifecycleService
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Interface SalObjectLifecycleService defines two methods corresponding to
-create-obj and delete-obj.
-
-**SalObjectLifecycleService.java.**
-
-::
-
- package org.opendaylight.yang.gen.v1.urn.opendaylight.ocp.object.lifecycle.rev150811;
-
- public interface SalObjectLifecycleService
- extends
- RpcService
- {
-
- Future<RpcResult<CreateObjOutput>> createObj(CreateObjInput input);
-
- Future<RpcResult<DeleteObjOutput>> deleteObj(DeleteObjInput input);
-
- }
-
-SalObjectStateMgmtService
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Interface SalObjectStateMgmtService defines two methods corresponding to
-get-state and modify-state.
-
-**SalObjectStateMgmtService.java.**
-
-::
-
- package org.opendaylight.yang.gen.v1.urn.opendaylight.ocp.object.state.mgmt.rev150811;
-
- public interface SalObjectStateMgmtService
- extends
- RpcService
- {
-
- Future<RpcResult<GetStateOutput>> getState(GetStateInput input);
-
- Future<RpcResult<ModifyStateOutput>> modifyState(ModifyStateInput input);
-
- }
-
-SalFaultMgmtService
-~~~~~~~~~~~~~~~~~~~
-
-Interface SalFaultMgmtService defines only one method corresponding to
-get-fault.
-
-**SalFaultMgmtService.java.**
-
-::
-
- package org.opendaylight.yang.gen.v1.urn.opendaylight.ocp.fault.mgmt.rev150811;
-
- public interface SalFaultMgmtService
- extends
- RpcService
- {
-
- Future<RpcResult<GetFaultOutput>> getFault(GetFaultInput input);
-
- }
-
-Notifications
--------------
-
-In addition to indication messages, the OCP southbound plugin will
-translate specific events (e.g., connect, disconnect) coming up from the
-OCP protocol library into MD-SAL Notification objects and then publish
-them to the MD-SAL. Also, the OCP service will notify the completion of
-certain operation via Notification as well.
-
-SalDeviceMgmtListener
-~~~~~~~~~~~~~~~~~~~~~
-
-An onDeviceConnected Notification will be published to the MD-SAL as
-soon as a radio head is connected to the controller, and when that radio
-head is disconnected the OCP southbound plugin will publish an
-onDeviceDisconnected Notification in response to the disconnect event
-propagated from the OCP protocol library.
-
-**SalDeviceMgmtListener.java.**
-
-::
-
- package org.opendaylight.yang.gen.v1.urn.opendaylight.ocp.device.mgmt.rev150811;
-
- public interface SalDeviceMgmtListener
- extends
- NotificationListener
- {
-
- void onDeviceConnected(DeviceConnected notification);
-
- void onDeviceDisconnected(DeviceDisconnected notification);
-
- }
-
-OcpServiceListener
-~~~~~~~~~~~~~~~~~~
-
-The OCP service will publish an onAlignmentCompleted Notification to the
-MD-SAL once it has completed the OCP alignment procedure with the radio
-head.
-
-**OcpServiceListener.java.**
-
-::
-
- package org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ocp.applications.ocp.service.rev150811;
-
- public interface OcpServiceListener
- extends
- NotificationListener
- {
-
- void onAlignmentCompleted(AlignmentCompleted notification);
-
- }
-
-SalObjectStateMgmtListener
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When receiving a state change indication message, the OCP southbound
-plugin will propagate the indication message to upper layer
-services/applications by publishing a corresponding onStateChangeInd
-Notification to the MD-SAL.
-
-**SalObjectStateMgmtListener.java.**
-
-::
-
- package org.opendaylight.yang.gen.v1.urn.opendaylight.ocp.object.state.mgmt.rev150811;
-
- public interface SalObjectStateMgmtListener
- extends
- NotificationListener
- {
-
- void onStateChangeInd(StateChangeInd notification);
-
- }
-
-SalFaultMgmtListener
-~~~~~~~~~~~~~~~~~~~~
-
-When receiving a fault indication message, the OCP southbound plugin
-will propagate the indication message to upper layer
-services/applications by publishing a corresponding onFaultInd
-Notification to the MD-SAL.
-
-**SalFaultMgmtListener.java.**
-
-::
-
- package org.opendaylight.yang.gen.v1.urn.opendaylight.ocp.fault.mgmt.rev150811;
-
- public interface SalFaultMgmtListener
- extends
- NotificationListener
- {
-
- void onFaultInd(FaultInd notification);
-
- }
+++ /dev/null
-.. _sdni-dev-guide:
-
-ODL-SDNi Developer Guide
-========================
-
-Overview
---------
-
-This project aims at enabling inter-SDN controller communication by
-developing SDNi (Software Defined Networking interface) as an
-application (ODL-SDNi App).
-
-ODL-SDNi Architecture
----------------------
-
-- SDNi Aggregator: Northbound SDNi plugin acts as an aggregator for
- collecting network information such as topology, stats, host etc.
- This plugin can be evolving as per needs of network data requested to
- be shared across federated SDN controllers.
-
-- SDNi API: API view autogenerated and accessible through RESTCONF to
- fetch the aggregated information from the northbound plugin – SDNi
- aggregator.The RESTCONF protocol operates on a conceptual datastore
- defined with the YANG data modeling language.
-
-- SDNi Wrapper: SDNi BGP Wrapper will be responsible for the sharing
- and collecting information to/from federated controllers.
-
-- SDNi UI:This component displays the SDN controllers connected to each
- other.
-
-SDNi Aggregator
----------------
-
-- SDNiAggregator connects with the Base Network Service Functions of
- the controller. Currently it is querying network topology through
- MD-SAL for creating SDNi network capability.
-
-- SDNiAggregator is customized to retrieve the host controller’s
- details, while running the controller in cluster mode. Rest of the
- northbound APIs of controller will retrieve the entire topology
- information of all the connected controllers.
-
-- The SDNiAggregator creates a topology structure.This structure is
- populated by the various network funtions.
-
-SDNi API
---------
-
-Topology and QoS data is fetched from SDNiAggregator through RESTCONF.
-
-`http://${controlleripaddress}:8181/apidoc/explorer/index.html <http://${controlleripaddress}:8181/apidoc/explorer/index.html>`__
-
-`http://${ipaddress}:8181/restconf/operations/opendaylight-sdni-topology-msg:getAllPeerTopology <http://${ipaddress}:8181/restconf/operations/opendaylight-sdni-topology-msg:getAllPeerTopology>`__
-
-**Peer Topology Data:** Controller IP Address, Links, Nodes, Link
-Bandwidths, MAC Address of switches, Latency, Host IP address.
-
-`http://${ipaddress}:8181/restconf/operations/opendaylight-sdni-qos-msg:get-all-node-connectors-statistics <http://${ipaddress}:8181/restconf/operations/opendaylight-sdni-qos-msg:get-all-node-connectors-statistics>`__
-
-**QOS Data:** Node, Port, Transmit Packets, Receive Packets, Collision
-Count, Receive Frame Error, Receive Over Run Error, Receive Crc Error
-
-`http://${ipaddress}:8181/restconf/operations/opendaylight-sdni-qos-msg:get-all-peer-node-connectors-statistics <http://${ipaddress}:8181/restconf/operations/opendaylight-sdni-qos-msg:get-all-peer-node-connectors-statistics>`__
-
-**Peer QOS Data:** Node, Port, Transmit Packets, Receive Packets,
-Collision Count, Receive Frame Error, Receive Over Run Error, Receive
-Crc Error
-
-SDNi Wrapper
-------------
-
-.. figure:: ./images/SDNiWrapper.png
- :alt: SDNiWrapper
-
- SDNiWrapper
-
-- SDNiWrapper is an extension of ODL-BGPCEP where SDNi topology data is
- exchange along with the Update NLRI message. Refer
- http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-04 for more
- information on NLRI.
-
-- SDNiWrapper gets the controller’s network capabilities through SDNi
- Aggregator and serialize it in Update NLRI message. This NLRI message
- will get exchange between the clustered controllers through
- BGP-UPDATE message. Similarly peer controller’s UPDATE message is
- received and unpacked then format to SDNi Network capability data,
- which will be stored for further purpose.
-
-SDNi UI
--------
-
-This component displays the SDN controllers connected to each other.
-
-http://localhost:8181/index.html#/sdniUI/sdnController
-
-API Reference Documentation
----------------------------
-
-Go to
-`http://${controlleripaddress}:8181/apidoc/explorer/index.html <http://${controlleripaddress}:8181/apidoc/explorer/index.html>`__,
-sign in, and expand the opendaylight-sdni panel. From there, users can
-execute various API calls to test their SDNi deployment.
+++ /dev/null
-.. _ofconfig-dev-guide:
-
-OF-CONFIG Developer Guide
-=========================
-
-Overview
---------
-
-OF-CONFIG defines an OpenFlow switch as an abstraction called an
-OpenFlow Logical Switch. The OF-CONFIG protocol enables configuration of
-essential artifacts of an OpenFlow Logical Switch so that an OpenFlow
-controller can communicate and control the OpenFlow Logical switch via
-the OpenFlow protocol. OF-CONFIG introduces an operating context for one
-or more OpenFlow data paths called an OpenFlow Capable Switch for one or
-more switches. An OpenFlow Capable Switch is intended to be equivalent
-to an actual physical or virtual network element (e.g. an Ethernet
-switch) which is hosting one or more OpenFlow data paths by partitioning
-a set of OpenFlow related resources such as ports and queues among the
-hosted OpenFlow data paths. The OF-CONFIG protocol enables dynamic
-association of the OpenFlow related resources of an OpenFlow Capable
-Switch with specific OpenFlow Logical Switches which are being hosted on
-the OpenFlow Capable Switch. OF-CONFIG does not specify or report how
-the partitioning of resources on an OpenFlow Capable Switch is achieved.
-OF-CONFIG assumes that resources such as ports and queues are
-partitioned amongst multiple OpenFlow Logical Switches such that each
-OpenFlow Logical Switch can assume full control over the resources that
-is assigned to it.
-
-How to start
-------------
-
-- start OF-CONFIG feature as below:
-
- ::
-
- feature:install odl-of-config-all
-
-Compatible with NETCONF
------------------------
-
-- Config OpenFlow Capable Switch via OpenFlow Configuration Points
-
- Method: POST
-
- URI:
- http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules
-
- Headers: Content-Type" and "Accept" header attributes set to
- application/xml
-
- Payload:
-
- .. code:: xml
-
- <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">prefix:sal-netconf-connector</type>
- <name>testtool</name>
- <address xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">10.74.151.67</address>
- <port xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">830</port>
- <username xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">mininet</username>
- <password xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">mininet</password>
- <tcp-only xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">false</tcp-only>
- <event-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:netty">prefix:netty-event-executor</type>
- <name>global-event-executor</name>
- </event-executor>
- <binding-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-broker-osgi-registry</type>
- <name>binding-osgi-broker</name>
- </binding-registry>
- <dom-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">prefix:dom-broker-osgi-registry</type>
- <name>dom-broker</name>
- </dom-registry>
- <client-dispatcher xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:config:netconf">prefix:netconf-client-dispatcher</type>
- <name>global-netconf-dispatcher</name>
- </client-dispatcher>
- <processing-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:threadpool</type>
- <name>global-netconf-processing-executor</name>
- </processing-executor>
- </module>
-
-- NETCONF establishes the connections with OpenFlow Capable Switches
- using the parameters in the previous step. NETCONF also gets the
- information of whether the OpenFlow Switch supports NETCONF during
- the signal handshaking. The information will be stored in the NETCONF
- topology as prosperity of a node.
-
-- OF-CONFIG can be aware of the switches accessing and leaving by
- monitoring the data changes in the NETCONF topology. For the detailed
- information it can be refered to the
- `implementation <https://git.opendaylight.org/gerrit/gitweb?p=of-config.git;a=blob_plain;f=southbound/southbound-impl/src/main/java/org/opendaylight/ofconfig/southbound/impl/OdlOfconfigApiServiceImpl.java;hb=refs/heads/stable/boron>`__.
-
-The establishment of OF-CONFIG topology
----------------------------------------
-
-Firstly, OF-CONFIG will check whether the newly accessed switch supports
-OF-CONFIG by querying the NETCONF interface.
-
-1. During the NETCONF connection’s establishment, the NETCONF and the
- switches will exchange the their capabilities via the "hello"
- message.
-
-2. OF-CONFIG gets the connection information between the NETCONF and
- switches by monitoring the data changes via the interface of
- DataChangeListener.
-
-3. After the NETCONF connection established, the OF-CONFIG module will
- check whether OF-CONFIG capability is in the switch’s capabilities
- list which is got in step 1.
-
-4. If the result of step 3 is yes, the OF-CONFIG will call the following
- processing steps to create the topology database.
-
-For the detailed information it can be referred to the
-`implementation <https://git.opendaylight.org/gerrit/gitweb?p=of-config.git;a=blob_plain;f=southbound/southbound-impl/src/main/java/org/opendaylight/ofconfig/southbound/impl/listener/OfconfigListenerHelper.java;hb=refs/heads/stable/boron>`__.
-
-Secondly, the capable switch node and logical switch node are added in
-the OF-CONFIG topology if the switch supports OF-CONFIG.
-
-OF-CONFIG’s topology compromise: Capable Switch topology (underlay) and
-logical Switch topology (overlay). Both of them are enhanced (augment)
-on
-
-/topo:network-topology/topo:topology/topo:node
-
-The NETCONF will add the nodes in the Topology via the path of
-"/topo:network-topology/topo:topology/topo:node" if it gets the
-configuration information of the switches.
-
-For the detailed information it can be referred to the
-`implementation <https://git.opendaylight.org/gerrit/gitweb?p=of-config.git;a=blob;f=southbound/southbound-api/src/main/yang/odl-ofconfig-topology.yang;h=dbdaec46ee59da3791386011f571d7434dd1e416;hb=refs/heads/stable/boron>`__.
-
+++ /dev/null
-.. _opflex-agent-ovs-dev-guide:
-
-OpFlex agent-ovs Developer Guide
-================================
-
-Overview
---------
-
-agent-ovs is a policy agent that works with OVS to enforce a group-based
-policy networking model with locally attached virtual machines or
-containers. The policy agent is designed to work well with orchestration
-tools like OpenStack.
-
-agent-ovs Architecture
-----------------------
-
-agent-ovs uses libopflex to communicate with an OpFlex-based policy
-repository to enforce policy on network endpoints attached to OVS by an
-orchestration system.
-
-The key components are:
-
-- Agent - coordinates startup and configuration
-
-- Renderers - Renderers are responsible for rendering policy. This is a
- very general mechanism but the currently-implemented renderer is the
- stitched-mode renderer that can work along with with hardware fabrics
- such as ACI that support policy enforcement.
-
-- EndpointManager - Keep track of network endpoints and declare them to
- the endpoint repository
-
-- PolicyManager - Keep track of and index policies
-
-- IntFlowManager - render policies to OVS integration bridge
-
-- AccessFlowManager - render policies to OVS access bridge
-
-API Reference Documentation
----------------------------
-
-Internal API documentation can be found by in doc/html/index.html in
-any build.
+++ /dev/null
-.. _opflex-genie-dev-guide:
-
-OpFlex genie Developer Guide
-============================
-
-Overview
---------
-
-Genie is a tool for code generation from a model. It supports generating
-C++ and Java code. C++ can be generated suitable for use with libopflex.
-C++ and Java can be generated as a plain set of objects.
-
-Group-based Policy Model
-------------------------
-
-The group-based policy model is included with the genie tool and can be
-found under the MODEL directory. By running mvn exec:java, libmodelgbp
-will be generated as a library project that, when built and installed,
-will work with libopflex. This model is used by the OVS agent.
-
-API Reference Documentation
----------------------------
-
-Complete API documentation for the generated libmodelgbp can be found
-in doc/html/index.html in any build
+++ /dev/null
-.. _opflex-libopflex-dev-guide:
-
-OpFlex libopflex Developer Guide
-================================
-
-Overview
---------
-
-The OpFlex framework allows you to develop agents that can communicate
-using the OpFlex protocol and act as a policy element in an OpFlex-based
-distributed control system. The OpFlex architecture provides a
-distributed control system based on a declarative policy information
-model. The policies are defined at a logically centralized policy
-repository and enforced within a set of distributed policy elements. The
-policy repository communicates with the subordinate policy elements
-using the OpFlex control protocol. This protocol allows for
-bidirectional communication of policy, events, statistics, and faults.
-
-Rather than simply providing access to the OpFlex protocol, this
-framework allows you to directly manipulate a management information
-tree containing a hierarchy of managed objects. This tree is kept in
-sync as needed with other policy elements in the system, and you are
-automatically notified when important changes to the model occur.
-Additionally, we can ensure that only those managed objects that are
-important to the local policy element are synchronized locally.
-
-Object Model
-~~~~~~~~~~~~
-
-Interactions with the OpFlex framework happen through the management
-information tree. This is a tree of managed objects defined by an object
-model specific to your application. There are a few important major
-category of objects that can appear in the model.
-
-- First, there is the policy object. A policy object represents some
- data related to a policy that describes a user intent for how the
- system should behave. A policy object is stored in the policy
- repository which is the source of "truth" for this object.
-
-- Second, there is an endpoint object. A endpoint represents an entity
- in the system to which we want to apply policy, which could be a
- network interface, a storage array, or other relevent policy
- endpoint. Endpoints are discovered and reported by policy elements
- locally, and are synchronized into the endpoint repository. The
- originating policy element is the source of truth for the endpoints
- it discovers. Policy elements can retrieve information about
- endpoints discovered by other policy elements by resolving endpoints
- from the endpoint repository.
-
-- Third, there is the observable object. An observable object
- represents some state related to the operational status or health of
- the policy element. Observable objects will be reported to the
- observer.
-
-- Finally, there is the local-only object. This is the simplest object
- because it exists only local to a particular policy element. These
- objects can be used to store state specific to that policy element,
- or as helpers to resolve other objects. Read on to learn more.
-
-You can use the genie tool that is included with the framework to
-produce your application model along with a set of generated accessor
-classes that can work with this framework library. You should refer to
-the documentation that accompanies the genie tool for information on how
-to use to to generate your object model. Later in this guide, we’ll go
-through examples of how to use the generated managed object accessor
-classes.
-
-Programming by Side Effect
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When developing software on the OpFlex framework, you’ll need to think
-in a slightly different way. Rather than calling an API function that
-would perform some specific action, you’ll need to write a managed
-object to the managed object database. Writing that object to the store
-will trigger the side effect of performing the action that you want.
-
-For example, a policy element will need to have a component responsible
-for discovering policy endpoints. When it discovers a policy endpoint,
-it would write an endpoint object into the managed object database. That
-endpoint object will contain a reference to policy that is relevant to
-the endpoint object. This will trigger a whole cascade of events. First,
-the framework will notice that an endpoint object has been created and
-it will write it to the endpoint repository. Second, the framework to
-will attempt to resolve the unresolved reference to the relevent policy
-object. There might be a whole chain of policy resolutions that will be
-automatically performed to download all the relevent policy until there
-are no longer any dangling references.
-
-As long as there is a locally-created object in the system with a
-reference to that policy, the framework will continually ensure that the
-policy and any transitive policies are kept up to date. The policy
-element can subscribe to updates to these policy classes that will be
-invoked either the first time the policy is resolved or any time the
-policy changes.
-
-A consequence of this design is that the managed object database can be
-temporarily in an inconsistent state with unresolved dangling
-references. Eventually, however, the inconsistency will be fully
-resolved. The policy element must be able to cleanly handle
-partially-resolved or inconsistent state and eventually reach the
-correct state as it receives these update notifications. Note that, in
-the OpFlex architecture, when there is no policy that specifically
-allows a particular action, that action must be prevented.
-
-Let’s cover one slightly more complex example. If a policy element needs
-to discover information about an endpoint that is not local to that
-policy element, it will need to retrieve that information from the
-endpoint repository. However, just as there is no API call to retrieve a
-policy object from the policy repository, there is no API call to
-retrieve an endpoint from the endpoint repository.
-
-To get this information, the policy element needs to create a local-only
-object that references the endpoint. Once it creates this local-only
-object, if the endpoint is not already resolved, the framework will
-notice the dangling reference and automatically resolve the endpoint
-from the endpoint respository. When the endpoint resolution completes,
-the framework deliver an update notification to the policy element. The
-policy element will continue to receive any updates related to that
-endpoint until the policy element remove the local-only reference to the
-object. Once this occurs, the framework can garbage-collect any
-unreferenced objects.
-
-Threading and Ownership
-~~~~~~~~~~~~~~~~~~~~~~~
-
-The OpFlex framework uses a somewhat unique threading model. Each
-managed object in the system belongs to a particular owner. An owner
-would typically be a single thread that is reponsible for all updates to
-objects with that owner. Though anything can read the state of a managed
-object, only the owner of a managed object is permitted to write to it.
-Though this is not strictly required for correctness, the performance of
-the system wil be best if you ensure that only one thread at a time is
-writing to objects with a particular owner.
-
-Change notifications are delivered in a serialized fashion by a single
-thread. Blocking this thread from a notification callback will stall
-delivery of all notifications. It is therefore best practice to ensure
-that you do not block or perform long-running operations from a
-notification callback.
-
-Key APIs and Interfaces
------------------------
-
-Basic Usage and Initialization
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The primary interface point into the framework is
-opflex::ofcore::OFFramework. You can choose to instantiate your own copy
-of the framework, or you can use the static default instance.
-
-Before you can use the framework, you must initialize it by installing
-your model metadata. The model metadata is accessible through the
-generated model library. In this case, it assumes your model is called
-"mymodel":
-
-.. code:: cpp
-
- #include <opflex/ofcore/OFFramework.h>
- #include <mymodel/metadata/metadata.hpp>
- // ...
- using opflex::ofcore::OFFramework;
- OFFramework::defaultInstance().setModel(mymodel::getMetadata());
-
-The other critical piece of information required for initialization is
-the OpFlex identity information. The identity information is required in
-order to successfully connect to OpFlex peers. In OpFlex, each component
-has a unique name within its policy domain, and each policy domain is
-identified by a globally unique domain name. You can set this identity
-information by calling:
-
-.. code:: cpp
-
- OFFramework::defaultInstance()
- .setOpflexIdentity("[component name]", "[unique domain]");
-
-You can then start the framework simply by calling:
-
-.. code:: cpp
-
- OFFramework::defaultInstance().start();
-
-Finally, you can add peers after the framework is started by calling the
-``opflex::ofcore::OFFramework::addPeer`` method:
-
-.. code:: cpp
-
- OFFramework::defaultInstance().addPeer("192.168.1.5", 1234);
-
-When connecting to the peer, that peer may provide an additional list of
-peers to connect to, which will be automatically added as peers. If the
-peer does not include itself in the list, then the framework will
-disconnect from that peer and add the peers in the list. In this way, it
-is possible to automatically bootstrap the correct set of peers using a
-known hostname or IP address or a known, fixed anycast IP address.
-
-To cleanly shut down, you can call:
-
-.. code:: cpp
-
- OFFramework::defaultInstance().stop();
-
-Working with Data in the Tree
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Reading from the Tree
-^^^^^^^^^^^^^^^^^^^^^
-
-You can access data in the managed tree using the generated accessor
-classes. The details of exactly which classes you’ll use will depend on
-the model you’re using, but let’s assume that we have a simple model
-called "simple" with the following classes:
-
-- root - The root node. The URI for the root node is "/"
-
-- foo - A policy object, and a child of root, with a scalar string
- property called "bar", and a unsigned 64-bit integer property called
- baz. The bar property is the naming property for foo. The URI for a
- foo object would be "/foo/[value of bar]/"
-
-- fooref - A local-only child of root, with a reference to a foo, and a
- scalar string property called "bar". The bar property is the naming
- property for foo. The URI for a fooref object would be
- "/fooref/[value of bar]/"
-
-In this example, we’ll have a generated class for each of the objects.
-There are two main ways to get access to an object in the tree.
-
-First, we can get instantiate an accessor class to any node in the tree
-by calling one of its static resolve functions. The resolve functions
-can take either an already-built URI that represents the object, or you
-can call the version that will locate the object by its naming
-properties.
-
-Second, we can access the object also from its parent object using the
-appropriate child resolver member functions.
-
-However we read it, the object we get back is an immutable view into the
-object it references. The properties set locally on that object will not
-change even though the underlying object may have been updated in the
-store. Note, however, that its children can change between when you
-first retrieve the object and when you resolve any children.
-
-Another thing that is critical to note again is that when you attempt to
-resolve an object, you can get back nothing, even if the object actually
-does exist on another OpFlex node. You must ensure that some object in
-the managed object database references the remote managed object you
-want before it will be visible to you.
-
-To get access to the root node using the default framework instance, we
-can simply call:
-
-.. code:: cpp
-
- using boost::shared_ptr;
- using boost::optional;
- optional<shared_ptr<simple::root> > r(simple::root::resolve());
-
-Note that whenever we can a resolve function, we get back our data in
-the form of an optional shared pointer to the object instance. If the
-node does not exist, then the optional will be set to boost::none. Note
-that if you dereference an optional that has not been set, you’ll
-trigger an assert, so you must check the return as follows:
-
-.. code:: cpp
-
- if (!r) {
- // handle missing object
- }
-
-Now let’s get a child node of the root in three different ways:
-
-.. code:: cpp
-
- // Get foo1 by constructing its URI from the root
- optional<shared_ptr<simple::foo> > foo1(simple::foo::resolve("test"));
- // get foo1 by constructing its URI relative to its parent
- foo1 = r.get()->resolveFoo("test");
- // get foo1 by manually building its URI
- foo1 = simple::foo::resolve(opflex::modb::URIBuilder()
- .addElement("foo")
- .addElement("test")
- .build());
-
-All three of these calls will give us the same object, which is the
-"foo" object located at "/foo/test/".
-
-The foo class has a single string property called "bar". We can easily
-access it as follows:
-
-.. code:: cpp
-
- const std::string& barv = foo1.getBar();
-
-Writing to the Tree
-^^^^^^^^^^^^^^^^^^^
-
-Writing to the tree is nearly as easy as reading from it. The key
-concept to understand is the mutator object. If you want to make changes
-to the tree, you must allocate a mutator object. The mutator will
-register itself in some thread-local storage in the framework instance
-you’re using. The mutator is specific to a single "owner" for the data,
-so you can only make changes to data associated with that owner.
-
-Whenever you modify one of the accessor classes, the change is actually
-forwarded to the currently-active mutator. You won’t see any of the
-changes you make until you call the commit member function on the
-mutator. When you do that, all the changes you made are written into the
-store.
-
-Once the changes are written into the store, you will need to call the
-appropriate resolve function again to see the changes.
-
-Allocating a mutator is simple. To create a mutator for the default
-framework instance associated with the owner "owner1", just allocate the
-mutator on the stack. Be sure to call commit() before it goes out of
-scope or you’ll lose your changes.
-
-.. code:: cpp
-
- {
- opflex::modb::Mutator mutator("owner1");
- // make changes here
- mutator.commit();
- }
-
-Note that if an exception is thrown while making changes but before
-committing, the mutator will go out of scope and the changes will be
-discarded.
-
-To create a new node, you must call the appropriate add[Child] member
-function on its parent. This function takes parameters for each of the
-naming properties for the object:
-
-.. code:: cpp
-
- shared_ptr<simple::foo> newfoo(root->addFoo("test"));
-
-This will return a shared pointer to a new foo object that has been
-registered in the active mutator but not yet committed. The "bar" naming
-property will be set automatically, but if you want to set the "baz"
-property now, you can do so by calling:
-
-.. code:: cpp
-
- newfoo->setBaz(42);
-
-Note that creating the root node requires a call to the special static
-class method createRootElement:
-
-.. code:: cpp
-
- shared_ptr<simple::root> newroot(simple::root::createRootElement());
-
-Here’s a complete example that ties this all together:
-
-.. code:: cpp
-
- {
- opflex::modb::Mutator mutator("owner1");
- shared_ptr<simple::root> newroot(simple::root::createRootElement());
- shared_ptr<simple::root> newfoo(newroot->addFoo("test"));
- newfoo->setBaz(42);
-
- mutator.commit();
- }
-
-Update Notifications
-~~~~~~~~~~~~~~~~~~~~
-
-When using the OpFlex framework, you’re likely to find that most of your
-time is spend responding to changes in the managed object database. To
-get these notifications, you’re going to need to register some number of
-listeners.
-
-You can register an object listener to see all changes related to a
-particular class by calling a static function for that class. You’ll
-then get notifications whenever any object in that class is added,
-updated, or deleted. The listener should queue a task to read the new
-state and perform appropriate processing. If this function blocks or
-peforms a long-running operation, then the dispatching of update
-notifications will be stalled, but there will not be any other
-deleterious effects.
-
-If multiple changes happen to the same URI, then at least one
-notification will be delivered but some events may be consolidated.
-
-The update you get will tell you the URI and the Class ID of the changed
-object. The class ID is a unique ID for each class. When you get the
-update, you’ll need to call the appropriate resolve function to retrieve
-the new value.
-
-You’ll need to create your own object listener derived from
-opflex::modb::ObjectListener:
-
-.. code:: cpp
-
- class MyListener : public ObjectListener {
- public:
- MyListener() { }
- virtual void objectUpdated(class_id_t class_id, const URI& uri) {
- // Your handler here
- }
- };
-
-To register your listener with the default framework instance, just call
-the appropriate class static method:
-
-.. code:: cpp
-
- MyListener listener;
- simple::foo::registerListener(&listener);
- // main loop
- simple::foo::unregisterListener(&listener);
-
-The listener will now recieve notifications whenever any foo or any
-children of any foo object changes.
-
-Note that you must ensure that you unregister your listeners before
-deallocating them.
-
-API Reference Documentation
----------------------------
-
-Complete API documentation can be found by in doc/html/index.html in
-any build.
http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf
- hardwarevtep: Schema wrapper that represents
- http://openvswitch.org/docs/vtep.5.pdf
+ http://www.openvswitch.org/support/dist-docs/vtep.5.pdf
OVSDB Library Developer Guide
-----------------------------
The OVSDB Southbound MD-SAL operates using a YANG model which is based
on the abstract topology node model found in the `network topology
-model <https://github.com/opendaylight/yangtools/blob/stable/boron/model/ietf/ietf-topology/src/main/yang/network-topology%402013-10-21.yang>`__.
+model <https://github.com/opendaylight/yangtools/blob/7ec507df717ecde4c716c6811b71f322f8409626/model/ietf/ietf-topology/src/main/yang/network-topology%402013-10-21.yang>`_.
The augmentations for the OVSDB Southbound MD-SAL are defined in the
-`ovsdb.yang <https://github.com/opendaylight/ovsdb/blob/stable/boron/southbound/southbound-api/src/main/yang/ovsdb.yang>`__
+`ovsdb.yang <https://github.com/opendaylight/ovsdb/blob/stable/boron/southbound/southbound-api/src/main/yang/ovsdb.yang>`_
file.
There are three augmentations:
- Set the election ID. For more information about the election IDs and
and their meaning, refer to the following URL:
- https://github.com/p4lang/PI/blob/master/proto/docs/arbitration.md
+ https://github.com/p4lang/PI/blob/dc2f4c6cce86e310055677c8b18831fd8f6d1f2c/proto/docs/arbitration.md
When a new election ID is set, it sends master arbitration update
messages to all devices it connected.
+++ /dev/null
-.. _packetcable-dev-guide:
-
-PacketCable Developer Guide
-===========================
-
-PCMM Specification
-------------------
-
-`PacketCable™ Multimedia
-Specification <http://www.cablelabs.com/specification/packetcable-multimedia-specification>`__
-
-System Overview
----------------
-
-These components introduce a DOCSIS QoS Service Flow management using
-the PCMM protocol. The driver component is responsible for the
-PCMM/COPS/PDP functionality required to service requests from
-PacketCable Provider and FlowManager. Requests are transposed into PCMM
-Gate Control messages and transmitted via COPS to the CCAP/CMTS. This
-plugin adheres to the PCMM/COPS/PDP functionality defined in the
-CableLabs specification. PacketCable solution is an MDSAL compliant
-component.
-
-PacketCable Components
-----------------------
-
-The packetcable maven project is comprised of several modules.
-
-+--------------------------------------+--------------------------------------+
-| Bundle | Description |
-+======================================+======================================+
-| packetcable-driver | A common module that containts the |
-| | COPS stack and manages all |
-| | connections to CCAPS/CMTSes. |
-+--------------------------------------+--------------------------------------+
-| packetcable-emulator | A basic CCAP emulator to facilitate |
-| | testing the the plugin when no |
-| | physical CCAP is avaible. |
-+--------------------------------------+--------------------------------------+
-| packetcable-policy-karaf | Generates a Karaf distribution with |
-| | a config that loads all the |
-| | packetcable features at runtime. |
-+--------------------------------------+--------------------------------------+
-| packetcable-policy-model | Contains the YANG information model. |
-+--------------------------------------+--------------------------------------+
-| packetcable-policy-server | Provider hosts the model processing, |
-| | RESTCONF, and API implementation. |
-+--------------------------------------+--------------------------------------+
-
-Setting Logging Levels
-~~~~~~~~~~~~~~~~~~~~~~
-
-From the Karaf console
-
-::
-
- log:set <LEVEL> (<PACKAGE>|<BUNDLE>)
- Example
- log:set DEBUG org.opendaylight.packetcable.packetcable-policy-server
-
-Tools for Testing
------------------
-
-Postman REST client for Chrome
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-`Install the Chrome
-extension <https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en>`__
-
-`Download and import sample packetcable
-collection <https://git.opendaylight.org/gerrit/gitweb?p=packetcable.git;a=tree;f=packetcable-policy-server/doc/restconf-samples>`__
-
-View Rest API
-~~~~~~~~~~~~~
-
-1. Install the ``odl-mdsal-apidocs`` feature from the karaf console.
-
-2. Open http://localhost:8181/apidoc/explorer/index.html default dev
- build user/pass is admin/admin
-
-3. Navigate to the PacketCable section.
-
-Yang-IDE
-~~~~~~~~
-
-Editing yang can be done in any text editor but Yang-IDE will help
-prevent mistakes.
-
-`Setup and Build Yang-IDE for
-Eclipse <https://github.com/xored/yang-ide/wiki/Setup-and-build>`__
-
-Using Wireshark to Trace PCMM
------------------------------
-
-1. To start wireshark with privileges issue the following command:
-
- ::
-
- sudo wireshark &
-
-2. Select the interface to monitor.
-
-3. Use the Filter to only display COPS messages by applying “cops” in
- the filter field.
-
- .. figure:: ./images/packetcable-developer-wireshark.png
-
- Wireshark looking for COPS messages.
-
-Debugging and Verifying DQoS Gate (Flows) on the CCAP/CMTS
-----------------------------------------------------------
-
-Below are some of the most useful CCAP/CMTS commands to verify flows
-have been enabled on the CMTS.
-
-Cisco
-~~~~~
-
-`Cisco CMTS Cable Command
-Reference <http://www.cisco.com/c/en/us/td/docs/cable/cmts/cmd_ref/b_cmts_cable_cmd_ref.pdf>`__
-
-Find the Cable Modem
-~~~~~~~~~~~~~~~~~~~~
-
-::
-
- 10k2-DSG#show cable modem
- D
- MAC Address IP Address I/F MAC Prim RxPwr Timing Num I
- State Sid (dBmv) Offset CPE P
- 0010.188a.faf6 0.0.0.0 C8/0/0/U0 offline 1 0.00 1482 0 N
- 74ae.7600.01f3 10.32.115.150 C8/0/10/U0 online 1 -0.50 1431 0 Y
- 0010.188a.fad8 10.32.115.142 C8/0/10/UB w-online 2 -0.50 1507 1 Y
- 000e.0900.00dd 10.32.115.143 C8/0/10/UB w-online 3 1.00 1677 0 Y
- e86d.5271.304f 10.32.115.168 C8/0/10/UB w-online 6 -0.50 1419 1 Y
-
-Show PCMM Plugin Connection
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-::
-
- 10k2-DSG#show packetcabl ?
- cms Gate Controllers connected to this PacketCable client
- event Event message server information
- gate PacketCable gate information
- global PacketCable global information
-
- 10k2-DSG#show packetcable cms
- GC-Addr GC-Port Client-Addr COPS-handle Version PSID Key PDD-Cfg
-
-
- 10k2-DSG#show packetcable cms
- GC-Addr GC-Port Client-Addr COPS-handle Version PSID Key PDD-Cfg
- 10.32.0.240 54238 10.32.15.3 0x4B9C8150/1 4.0 0 0 0
-
-Show COPS Messages
-~~~~~~~~~~~~~~~~~~
-
-::
-
- debug cops details
-
-Use CM Mac Address to List Service Flows
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-::
-
- 10k2-DSG#show cable modem
- D
- MAC Address IP Address I/F MAC Prim RxPwr Timing Num I
- State Sid (dBmv) Offset CPE P
- 0010.188a.faf6 --- C8/0/0/UB w-online 1 0.50 1480 1 N
- 74ae.7600.01f3 10.32.115.150 C8/0/10/U0 online 1 -0.50 1431 0 Y
- 0010.188a.fad8 10.32.115.142 C8/0/10/UB w-online 2 -0.50 1507 1 Y
- 000e.0900.00dd 10.32.115.143 C8/0/10/UB w-online 3 0.00 1677 0 Y
- e86d.5271.304f 10.32.115.168 C8/0/10/UB w-online 6 -0.50 1419 1 Y
-
-
- 10k2-DSG#show cable modem 000e.0900.00dd service-flow
-
-
- SUMMARY:
- MAC Address IP Address Host MAC Prim Num Primary DS
- Interface State Sid CPE Downstream RfId
- 000e.0900.00dd 10.32.115.143 C8/0/10/UB w-online 3 0 Mo8/0/2:1 2353
-
-
- Sfid Dir Curr Sid Sched Prio MaxSusRate MaxBrst MinRsvRate Throughput
- State Type
- 23 US act 3 BE 0 0 3044 0 39
- 30 US act 16 BE 0 500000 3044 0 0
- 24 DS act N/A N/A 0 0 3044 0 17
-
-
-
- UPSTREAM SERVICE FLOW DETAIL:
-
- SFID SID Requests Polls Grants Delayed Dropped Packets
- Grants Grants
- 23 3 784 0 784 0 0 784
- 30 16 0 0 0 0 0 0
-
-
- DOWNSTREAM SERVICE FLOW DETAIL:
-
- SFID RP_SFID QID Flg Policer Scheduler FrwdIF
- Xmits Drops Xmits Drops
- 24 33019 131550 0 0 777 0 Wi8/0/2:2
-
- Flags Legend:
- $: Low Latency Queue (aggregated)
- ~: CIR Queue
-
-Deleting a PCMM Gate Message from the CMTS
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-::
-
- 10k2-DSG#test cable dsd 000e.0900.00dd 30
-
-Find service flows
-~~~~~~~~~~~~~~~~~~
-
-All gate controllers currently connected to the PacketCable client are
-displayed
-
-::
-
- show cable modem 00:11:22:33:44:55 service flow ????
- show cable modem
-
-Debug and display PCMM Gate messages
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-::
-
- debug packetcable gate control
- debug packetcable gate events
- show packetcable gate summary
- show packetcable global
- show packetcable cms
-
-Debug COPS messages
-~~~~~~~~~~~~~~~~~~~
-
-::
-
- debug cops detail
- debug packetcable cops
- debug cable dynamic_qos trace
-
-Integration Verification
-------------------------
-
-Checkout the integration project and perform regression tests.
-
-::
-
- git clone ssh://${ODL_USERNAME}@git.opendaylight.org:29418/integration.git
- git clone https:/git.opendaylight.org/gerrit/integration.git
-
-1. Check and edit the
- integration/features/src/main/resources/features.xml and follow the
- directions there.
-
-2. Check and edit the integration/features/pom.xml and add a dependency
- for your feature file
-
-3. Build integration/features and debug
-
-`` mvn clean install``
-
-Test your feature in the integration/distributions/extra/karaf/
-distribution
-
-::
-
- cd integration/distributions/extra/karaf/
- mvn clean install
- cd target/assembly/bin
- ./karaf
-
-service-wrapper
-~~~~~~~~~~~~~~~
-
-Install http://karaf.apache.org/manual/latest/users-guide/wrapper.html
-
-::
-
- opendaylight-user@root>feature:install service-wrapper
- opendaylight-user@root>wrapper:install --help
- DESCRIPTION
- wrapper:install
-
- Install the container as a system service in the OS.
-
- SYNTAX
- wrapper:install [options]
-
- OPTIONS
- -d, --display
- The display name of the service.
- (defaults to karaf)
- --help
- Display this help message
- -s, --start-type
- Mode in which the service is installed. AUTO_START or DEMAND_START (Default: AUTO_START)
- (defaults to AUTO_START)
- -n, --name
- The service name that will be used when installing the service. (Default: karaf)
- (defaults to karaf)
- -D, --description
- The description of the service.
- (defaults to )
-
- opendaylight-user@root> wrapper:install
- Creating file: /home/user/odl/distribution-karaf-0.5.0-Boron/bin/karaf-wrapper
- Creating file: /home/user/odl/distribution-karaf-0.5.0-Boron/bin/karaf-service
- Creating file: /home/user/odl/distribution-karaf-0.5.0-Boron/etc/karaf-wrapper.conf
- Creating file: /home/user/odl/distribution-karaf-0.5.0-Boron/lib/libwrapper.so
- Creating file: /home/user/odl/distribution-karaf-0.5.0-Boron/lib/karaf-wrapper.jar
- Creating file: /home/user/odl/distribution-karaf-0.5.0-Boron/lib/karaf-wrapper-main.jar
-
- Setup complete. You may wish to tweak the JVM properties in the wrapper configuration file:
- /home/user/odl/distribution-karaf-0.5.0-Boron/etc/karaf-wrapper.conf
- before installing and starting the service.
-
-
- Ubuntu/Debian Linux system detected:
- To install the service:
- $ ln -s /home/user/odl/distribution-karaf-0.5.0-Boron/bin/karaf-service /etc/init.d/
-
- To start the service when the machine is rebooted:
- $ update-rc.d karaf-service defaults
-
- To disable starting the service when the machine is rebooted:
- $ update-rc.d -f karaf-service remove
-
- To start the service:
- $ /etc/init.d/karaf-service start
-
- To stop the service:
- $ /etc/init.d/karaf-service stop
-
- To uninstall the service :
- $ rm /etc/init.d/karaf-service
+++ /dev/null
-.. _pcep-developer-guide:
-
-PCEP Developer Guide
-====================
-
-Overview
---------
-
-This section provides an overview of **feature odl-bgpcep-pcep-all** .
-This feature will install everything needed for PCEP (Path Computation
-Element Protocol) including establishing the connection, storing
-information about LSPs (Label Switched Paths) and displaying data in
-network-topology overview.
-
-PCEP Architecture
------------------
-
-Each feature represents a module in the BGPCEP codebase. The following
-diagram illustrates how the features are related.
-
-.. figure:: ./images/bgpcep/pcep-dependency-tree.png
- :alt: PCEP Dependency Tree
-
- PCEP Dependency Tree
-
-Key APIs and Interfaces
------------------------
-
-PCEP
-~~~~
-
-Session handling
-^^^^^^^^^^^^^^^^
-
-*32-pcep.xml* defines only pcep-dispatcher the parser should be using
-(global-pcep-extensions), factory for creating session proposals (you
-can create different proposals for different PCCs (Path Computation
-Clients)).
-
-.. code:: xml
-
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:pcep:impl">prefix:pcep-dispatcher-impl</type>
- <name>global-pcep-dispatcher</name>
- <pcep-extensions>
- <type xmlns:pcepspi="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">pcepspi:extensions</type>
- <name>global-pcep-extensions</name>
- </pcep-extensions>
- <pcep-session-proposal-factory>
- <type xmlns:pcep="urn:opendaylight:params:xml:ns:yang:controller:pcep">pcep:pcep-session-proposal-factory</type>
- <name>global-pcep-session-proposal-factory</name>
- </pcep-session-proposal-factory>
- <boss-group>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-threadgroup</type>
- <name>global-boss-group</name>
- </boss-group>
- <worker-group>
- <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-threadgroup</type>
- <name>global-worker-group</name>
- </worker-group>
- </module>
-
-For user configuration of PCEP, check User Guide.
-
-Parser
-^^^^^^
-
-The base PCEP parser includes messages and attributes from
-`RFC5441 <http://tools.ietf.org/html/rfc5441>`__,
-`RFC5541 <http://tools.ietf.org/html/rfc5541>`__,
-`RFC5455 <http://tools.ietf.org/html/rfc5455>`__,
-`RFC5557 <http://tools.ietf.org/html/rfc5557>`__ and
-`RFC5521 <http://tools.ietf.org/html/rfc5521>`__.
-
-Registration
-^^^^^^^^^^^^
-
-All parsers and serializers need to be registered into *Extension
-provider*. This *Extension provider* is configured in initial
-configuration of the parser-spi module (*32-pcep.xml*).
-
-.. code:: xml
-
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">prefix:pcep-extensions-impl</type>
- <name>global-pcep-extensions</name>
- <extension>
- <type xmlns:pcepspi="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">pcepspi:extension</type>
- <name>pcep-parser-base</name>
- </extension>
- <extension>
- <type xmlns:pcepspi="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">pcepspi:extension</type>
- <name>pcep-parser-ietf-stateful07</name>
- </extension>
- <extension>
- <type xmlns:pcepspi="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">pcepspi:extension</type>
- <name>pcep-parser-ietf-initiated00</name>
- </extension>
- <extension>
- <type xmlns:pcepspi="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">pcepspi:extension</type>
- <name>pcep-parser-sync-optimizations</name>
- </extension>
- </module>
-
-- *pcep-parser-base* - will register parsers and serializers
- implemented in pcep-impl module
-
-- *pcep-parser-ietf-stateful07* - will register parsers and serializers
- of draft-ietf-pce-stateful-pce-07 implementation
-
-- *pcep-parser-ietf-initiated00* - will register parser and serializer
- of draft-ietf-pce-pce-initiated-lsp-00 implementation
-
-- *pcep-parser-sync-optimizations* - will register parser and
- serializers of draft-ietf-pce-stateful-sync-optimizations-03
- implementation
-
-Stateful07 module is a good example of a PCEP parser extension.
-
-Configuration of PCEP parsers specifies one implementation of *Extension
-provider* that will take care of registering mentioned parser
-extensions:
-`SimplePCEPExtensionProviderContext <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/spi/src/main/java/org/opendaylight/protocol/pcep/spi/pojo/SimplePCEPExtensionProviderContext.java;hb=refs/for/stable/boron>`__.
-All registries are implemented in package
-`pcep-spi <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=pcep/spi/src/main/java/org/opendaylight/protocol/pcep/spi/pojo;hb=refs/for/stable/boron>`__.
-
-Parsing
-^^^^^^^
-
-Parsing of PCEP elements is mostly done equally to BGP, the only
-exception is message parsing, that is described here.
-
-In BGP messages, parsing of first-level elements (path-attributes) can
-be validated in a simple way, as the attributes should be ordered
-chronologically. PCEP, on the other hand, has a strict object order
-policy, that is described in RBNF (Routing Backus-Naur Form) in each
-RFC. Therefore the algorithm for parsing here is to parse all objects in
-order as they appear in the message. The result of parsing is a list of
-*PCEPObjects*, that is put through validation. *validate()* methods are
-present in each message parser. Depending on the complexity of the
-message, it can contain either a simple condition (checking the presence
-of a mandatory object) or a full state machine.
-
-In addition to that, PCEP requires sending error message for each
-documented parsing error. This is handled by creating an empty list of
-messages *errors* which is then passed as argument throughout whole
-parsing process. If some parser encounters *PCEPDocumentedException*, it
-has the duty to create appropriate PCEP error message and add it to this
-list. In the end, when the parsing is finished, this list is examined
-and all messages are sent to peer.
-
-Better understanding provides this sequence diagram:
-
-.. figure:: ./images/bgpcep/pcep-parsing.png
- :alt: Parsing
-
- Parsing
-
-PCEP IETF stateful
-~~~~~~~~~~~~~~~~~~
-
-This section summarizes module pcep-ietf-stateful07. The term *stateful*
-refers to
-`draft-ietf-pce-stateful-pce <http://tools.ietf.org/html/draft-ietf-pce-stateful-pce>`__
-and
-`draft-ietf-pce-pce-initiated-lsp <http://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp>`__
-in versions draft-ietf-pce-stateful-pce-07 with
-draft-ietf-pce-pce-initiated-lsp-00.
-
-We will upgrade our implementation, when the stateful draft gets
-promoted to RFC.
-
-The stateful module is implemented as extensions to pcep-base-parser.
-The stateful draft declared new elements as well as additional fields or
-TLVs (type,length,value) to known objects. All new elements are defined
-in yang models, that contain augmentations to elements defined in
-`pcep-types.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/api/src/main/yang/pcep-types.yang;hb=refs/for/stable/boron>`__.
-In the case of extending known elements, the *Parser* class merely
-extends the base class and overrides necessary methods as shown in
-following diagram:
-
-.. figure:: ./images/bgpcep/validation.png
- :alt: Extending existing parsers
-
- Extending existing parsers
-
-All parsers (including those for newly defined PCEP elements) have to be
-registered via the *Activator* class. This class is present in both
-modules.
-
-In addition to parsers, the stateful module also introduces additional
-session proposal. This proposal includes new fields defined in stateful
-drafts for Open object.
-
-PCEP segment routing (SR)
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-PCEP Segment Routing is an extension of base PCEP and
-pcep-ietf-stateful-07 extension. The pcep-segment-routing module
-implements
-`draft-ietf-pce-segment-routing-01 <http://tools.ietf.org/html/draft-ietf-pce-segment-routing-01>`__.
-
-The extension brings new SR-ERO (Explicit Route Object) and SR-RRO
-(Reported Route Object) subobject composed of SID (Segment Identifier)
-and/or NAI (Node or Adjacency Identifier). The segment Routing path is
-carried in the ERO and RRO object, as a list of SR-ERO/SR-RRO subobjects
-in an order specified by the user. The draft defines new TLV -
-SR-PCE-CAPABILITY TLV, carried in PCEP Open object, used to negotiate
-Segment Routing ability.
-
-| The yang models of subobject, SR-PCE-CAPABILITY TLV and appropriate
- augmentations are defined in
- `odl-pcep-segment-routing.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/yang/odl-pcep-segment-routing.yang;hb=refs/for/stable/boron>`__.
-| The pcep-segment-routing module includes parsers/serializers for new
- subobject
- (`SrEroSubobjectParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/java/org/opendaylight/protocol/pcep/segment/routing/SrEroSubobjectParser.java;hb=refs/for/stable/boron>`__)
- and TLV
- (`SrPceCapabilityTlvParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/java/org/opendaylight/protocol/pcep/segment/routing/SrPceCapabilityTlvParser.java;hb=refs/for/stable/boron>`__).
-
-The pcep-segment-routing module implements
-`draft-ietf-pce-lsp-setup-type-01 <http://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-01>`__,
-too. The draft defines new TLV - Path Setup Type TLV, which value
-indicate path setup signaling technique. The TLV may be included in
-RP(Request Parameters)/SRP(Stateful PCE Request Parameters) object. For
-the default RSVP-TE (Resource Reservation Protocol), the TLV is omitted.
-For Segment Routing, PST = 1 is defined.
-
-The Path Setup Type TLV is modeled with yang in module
-`pcep-types.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/api/src/main/yang/pcep-types.yang;hb=refs/for/stable/boron>`__.
-A parser/serializer is implemented in
-`PathSetupTypeTlvParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/impl/src/main/java/org/opendaylight/protocol/pcep/impl/tlv/PathSetupTypeTlvParser.java;hb=refs/for/stable/boron>`__
-and it is overriden in segment-routing module to provide the aditional
-PST.
-
-PCEP Synchronization Procedures Optimization
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Optimizations of Label Switched Path State Synchronization Procedures
-for a Stateful PCE draft-ietf-pce-stateful-sync-optimizations-03
-specifies following optimizations for state synchronization and the
-corresponding PCEP procedures and extensions:
-
-- **State Synchronization Avoidance:** To skip state synchronization if
- the state has survived and not changed during session restart.
-
-- **Incremental State Synchronization:** To do incremental (delta)
- state synchronization when possible.
-
-- **PCE-triggered Initial Synchronization:** To let PCE control the
- timing of the initial state synchronization. The capability can be
- applied to both full and incremental state synchronization.
-
-- **PCE-triggered Re-synchronization:** To let PCE re-synchronize the
- state for sanity check.
-
-PCEP Topology
-~~~~~~~~~~~~~
-
-PCEP data is displayed only through one URL that is accessible from the
-base network-topology URL:
-
-*http://localhost:8181/restconf/operational/network-topology:network-topology/topology/pcep-topology*
-
-Each PCC will be displayed as a node:
-
-.. code:: xml
-
- <node>
- <path-computation-client>
- <ip-address>42.42.42.42</ip-address>
- <state-sync>synchronized</state-sync>
- <stateful-tlv>
- <stateful>
- <initiation>true</initiation>
- <lsp-update-capability>true</lsp-update-capability>
- </stateful>
- </stateful-tlv>
- </path-computation-client>
- <node-id>pcc://42.42.42.42</node-id>
- </node>
- </source>
-
-If some tunnels are configured on the network, they would be displayed
-on the same page, within a node that initiated the tunnel:
-
-.. code:: xml
-
- <node>
- <path-computation-client>
- <state-sync>synchronized</state-sync>
- <stateful-tlv>
- <stateful>
- <initiation>true</initiation>
- <lsp-update-capability>true</lsp-update-capability>
- </stateful>
- </stateful-tlv>
- <reported-lsp>
- <name>foo</name>
- <lsp>
- <operational>down</operational>
- <sync>false</sync>
- <ignore>false</ignore>
- <plsp-id>1</plsp-id>
- <create>false</create>
- <administrative>true</administrative>
- <remove>false</remove>
- <delegate>true</delegate>
- <processing-rule>false</processing-rule>
- <tlvs>
- <lsp-identifiers>
- <ipv4>
- <ipv4-tunnel-sender-address>43.43.43.43</ipv4-tunnel-sender-address>
- <ipv4-tunnel-endpoint-address>0.0.0.0</ipv4-tunnel-endpoint-address>
- <ipv4-extended-tunnel-id>0.0.0.0</ipv4-extended-tunnel-id>
- </ipv4>
- <tunnel-id>0</tunnel-id>
- <lsp-id>0</lsp-id>
- </lsp-identifiers>
- <symbolic-path-name>
- <path-name>Zm9v</path-name>
- </symbolic-path-name>
- </tlvs>
- </lsp>
- </reported-lsp>
- <ip-address>43.43.43.43</ip-address>
- </path-computation-client>
- <node-id>pcc://43.43.43.43</node-id>
- </node>
-
-Note that, the *<path-name>* tag displays tunnel name in Base64
-encoding.
-
-API Reference Documentation
----------------------------
-
-Javadocs are generated while creating mvn:site and they are located in
-target/ directory in each module.
+++ /dev/null
-.. _sxp-dev-guide:
-
-SXP Developer Guide
-===================
-
-Overview
---------
-
-SXP (Scalable-Group Tag eXchange Protocol) project is an effort to enhance
-OpenDaylight platform with IP-SGT (IP Address to Source Group Tag)
-bindings that can be learned from connected SXP-aware network nodes. The
-current implementation supports SXP protocol version 4 according to the
-Smith, Kandula - SXP `IETF
-draft <https://tools.ietf.org/html/draft-smith-kandula-sxp-06>`__ and
-grouping of peers and creating filters based on ACL/Prefix-list syntax
-for filtering outbound and inbound IP-SGT bindings. All protocol legacy
-versions 1-3 are supported as well. Additionally, version 4 adds
-bidirectional connection type as an extension of a unidirectional one.
-
-SXP Architecture
-----------------
-
-The SXP Server manages all connected clients in separate threads and a
-common SXP protocol agreement is used between connected peers. Each SXP
-network peer is modelled with its pertaining class, e.g., SXP Server
-represents the SXP Speaker, SXP Listener the Client. The server program
-creates the ServerSocket object on a specified port and waits until a
-client starts up and requests connect on the IP address and port of the
-server. The client program opens a Socket that is connected to the
-server running on the specified host IP address and port.
-
-The SXP Listener maintains connection with its speaker peer. From an
-opened channel pipeline, all incoming SXP messages are processed by
-various handlers. Message must be decoded, parsed and validated.
-
-The SXP Speaker is a counterpart to the SXP Listener. It maintains a
-connection with its listener peer and sends composed messages.
-
-The SXP Binding Handler extracts the IP-SGT binding from a message and
-pulls it into the SXP-Database. If an error is detected during the
-IP-SGT extraction, an appropriate error code and sub-code is selected
-and an error message is sent back to the connected peer. All transitive
-messages are routed directly to the output queue of SXP Binding
-Dispatcher.
-
-The SXP Binding Dispatcher represents a selector that will decides how
-many data from the SXP-database will be sent and when. It is responsible
-for message content composition based on maximum message length.
-
-The SXP Binding Filters handles filtering of outgoing and incoming
-IP-SGT bindings according to BGP filtering using ACL and Prefix List
-syntax for specifying filter or based on Peer-sequence length.
-
-The SXP Domains feature provides isolation of SXP peers and bindings
-learned between them, also exchange of Bindings is possible across
-SXP-Domains by ACL, Prefix List or Peer-Sequence filters
-
-Key APIs and Interfaces
------------------------
-
-As this project is fairly small, it provides only few features that
-install and provide all APIs and implementations for this project.
-
-- sxp-api
-
-- spx-core
-
-- sxp-controller
-
-- sxp-cluster-route
-
-- sxp-karaf
-
-- sxp-robot
-
-- sxp-system-tests
-
-sxp-api
-~~~~~~~
-
-Contains data holders and entities
-
-spx-core
-~~~~~~~~
-
-Main logic and core features
-
-sxp-controller
-~~~~~~~~~~~~~~
-
-RPC request handling
-
-sxp-cluster-route
-~~~~~~~~~~~~~~~~~
-
-Performs managing of SXP devices in cluster environment
-
-sxp-karaf
-~~~~~~~~~
-
-Defines Karaf4 dependencies
-
-sxp-robot
-~~~~~~~~~
-
-Contains JRobot libraries used in `CSIT Robot tests <https://jenkins.opendaylight.org/releng/view/sxp/>`__
-
-sxp-system-tests
-~~~~~~~~~~~~~~~~
-
-Contains REST client used for testing purposes
-
-API Reference Documentation
----------------------------
-
-* `RESTCONF Interface and Dynamic Tree <https://wiki.opendaylight.org/images/9/91/SXP_Restconf_Interface_and_Dynamic_Tree.pdf>`__
-* `Specification and Architecture <https://wiki.opendaylight.org/images/4/44/SXP_Specification_and_Architecture_v05.pdf>`__
+++ /dev/null
-.. _topoprocessing-dev-guide:
-
-Topology Processing Framework Developer Guide
-=============================================
-
-Overview
---------
-
-The Topology Processing Framework allows developers to aggregate and
-filter topologies according to defined correlations. It also provides
-functionality, which you can use to make your own topology model by
-automating the translation from one model to another. For example to
-translate from the opendaylight-inventory model to only using the
-network-topology model.
-
-Architecture
-------------
-
-Chapter Overview
-~~~~~~~~~~~~~~~~
-
-In this chapter we describe the architecture of the Topology Processing
-Framework. In the first part, we provide information about available
-features and basic class relationships. In the second part, we describe
-our model specific approach, which is used to provide support for
-different models.
-
-Basic Architecture
-~~~~~~~~~~~~~~~~~~
-
-The Topology Processing Framework consists of several Karaf features:
-
-- odl-topoprocessing-framework
-
-- odl-topoprocessing-inventory
-
-- odl-topoprocessing-network-topology
-
-- odl-topoprocessing-i2rs
-
-- odl-topoprocessing-inventory-rendering
-
-The feature odl-topoprocessing-framework contains the
-topoprocessing-api, topoprocessing-spi and topoprocessing-impl bundles.
-This feature is the core of the Topology Processing Framework and is
-required by all others features.
-
-- topoprocessing-api - contains correlation definitions and definitions
- required for rendering
-
-- topoprocessing-spi - entry point for topoprocessing service (start
- and close)
-
-- topoprocessing-impl - contains base implementations of handlers,
- listeners, aggregators and filtrators
-
-TopoProcessingProvider is the entry point for Topology Processing
-Framework. It requires a DataBroker instance. The DataBroker is needed
-for listener registration. There is also the TopologyRequestListener
-which listens on aggregated topology requests (placed into the
-configuration datastore) and UnderlayTopologyListeners which listen on
-underlay topology data changes (made in operational datastore). The
-TopologyRequestHandler saves toporequest data and provides a method for
-translating a path to the specified leaf. When a change in the topology
-occurs, the registered UnderlayTopologyListener processes this
-information for further aggregation and/or filtration. Finally, after an
-overlay topology is created, it is passed to the TopologyWriter, which
-writes this topology into operational datastore.
-
-.. figure:: ./images/topoprocessing/TopologyRequestHandler_classesRelationship.png
- :alt: Class relationship
-
- Class relationship
-
-[1] TopologyRequestHandler instantiates TopologyWriter and
-TopologyManager. Then, according to the request, initializes either
-TopologyAggregator, TopologyFiltrator or LinkCalculator.
-
-[2] It creates as many instances of UnderlayTopologyListener as there
-are underlay topologies.
-
-[3] PhysicalNodes are created for relevant incoming nodes (those having
-node ID).
-
-[4a] It performs aggregation and creates logical nodes.
-
-[4b] It performs filtration and creates logical nodes.
-
-[4c] It performs link computation and creates links between logical
-nodes.
-
-[5] Logical nodes are put into wrapper.
-
-[6] The wrapper is translated into the appropriate format and written
-into datastore.
-
-Model Specific Approach
-~~~~~~~~~~~~~~~~~~~~~~~
-
-The Topology Processing Framework consists of several modules and Karaf
-features, which provide support for different input models. Currently we
-support the network-topology, opendaylight-inventory and i2rs models.
-For each of these input models, the Topology Processing Framework has
-one module and one Karaf feature.
-
-How it works
-^^^^^^^^^^^^
-
-**User point of view:**
-
-When you start the odl-topoprocessing-framework feature, the Topology
-Processing Framework starts without knowledge how to work with any input
-models. In order to allow the Topology Processing Framework to process
-some kind of input model, you must install one (or more) model specific
-features. Installing these features will also start
-odl-topoprocessing-framework feature if it is not already running. These
-features inject appropriate logic into the odl-topoprocessing-framework
-feature. From that point, the Topology Processing Framework is able to
-process different kinds of input models, specifically those that you
-install features for.
-
-**Developer point of view:**
-
-The topoprocessing-impl module contains (among other things) classes and
-interfaces, which are common for every model specific topoprocessing
-module. These classes and interfaces are implemented and extended by
-classes in particular model specific modules. Model specific modules
-also depend on the TopoProcessingProvider class in the
-topoprocessing-spi module. This dependency is injected during
-installation of model specific features in Karaf. When a model specific
-feature is started, it calls the registerAdapters(adapters) method of
-the injected TopoProcessingProvider object. After this step, the
-Topology Processing Framework is able to use registered model adapters
-to work with input models.
-
-To achieve the described functionality we created a ModelAdapter
-interface. It represents installed feature and provides methods for
-creating crucial structures specific to each model.
-
-.. figure:: ./images/topoprocessing/ModelAdapter.png
- :alt: ModelAdapter interface
-
- ModelAdapter interface
-
-Model Specific Features
-^^^^^^^^^^^^^^^^^^^^^^^
-
-- odl-topoprocessing-network-topology - this feature contains logic to
- work with network-topology model
-
-- odl-topoprocessing-inventory - this feature contains logic to work
- with opendaylight-inventory model
-
-- odl-topoprocessing-i2rs - this feature contains logic to work with
- i2rs model
-
-Inventory Model Support
-~~~~~~~~~~~~~~~~~~~~~~~
-
-The opendaylight-inventory model contains only nodes, termination
-points, information regarding these structures. This model co-operates
-with network-topology model, where other topology related information is
-stored. This means that we have to handle two input models at once. To
-support the inventory model, InventoryListener and
-NotificationInterConnector classes were introduced. Please see the flow
-diagrams below.
-
-.. figure:: ./images/topoprocessing/Network_topology_model_flow_diagram.png
- :alt: Network topology model
-
- Network topology model
-
-.. figure:: ./images/topoprocessing/Inventory_model_listener_diagram.png
- :alt: Inventory model
-
- Inventory model
-
-Here we can see the InventoryListener and NotificationInterConnector
-classes. InventoryListener listens on data changes in the inventory
-model and passes these changes wrapped as an UnderlayItem for further
-processing to NotificationInterConnector. It doesn’t contain node
-information - it contains a leafNode (node based on which aggregation
-occurs) instead. The node information is stored in the topology model,
-where UnderlayTopologyListener is registered as usual. This listener
-delivers the missing information.
-
-Then the NotificationInterConnector combines the two notifications into
-a complete UnderlayItem (no null values) and delivers this UnderlayItem
-for further processing (to next TopologyOperator).
-
-Aggregation and Filtration
---------------------------
-
-Chapter Overview
-~~~~~~~~~~~~~~~~
-
-The Topology Processing Framework allows the creation of aggregated
-topologies and filtered views over existing topologies. Currently,
-aggregation and filtration is supported for topologies that follow
-`network-topology <https://github.com/opendaylight/yangtools/blob/master/model/ietf/ietf-topology/src/main/yang/network-topology%402013-10-21.yang>`__,
-opendaylight-inventory or i2rs model. When a request to create an
-aggregated or filtered topology is received, the framework creates one
-listener per underlay topology. Whenever any specified underlay topology
-is changed, the appropriate listener is triggered with the change and
-the change is processed. Two types of correlations (functionalities) are
-currently supported:
-
-- Aggregation
-
- - Unification
-
- - Equality
-
-- Filtration
-
-Terminology
-~~~~~~~~~~~
-
-We use the term underlay item (physical node) for items (nodes, links,
-termination-points) from underlay and overlay item (logical node) for
-items from overlay topologies regardless of whether those are actually
-physical network elements.
-
-Aggregation
-~~~~~~~~~~~
-
-Aggregation is an operation which creates an aggregated item from two or
-more items in the underlay topology if the aggregation condition is
-fulfilled. Requests for aggregated topologies must specify a list of
-underlay topologies over which the overlay (aggregated) topology will be
-created and a target field in the underlay item that the framework will
-check for equality.
-
-Create Overlay Node
-^^^^^^^^^^^^^^^^^^^
-
-First, each new underlay item is inserted into the proper topology
-store. Once the item is stored, the framework compares it (using the
-target field value) with all stored underlay items from underlay
-topologies. If there is a target-field match, a new overlay item is
-created containing pointers to all *equal* underlay items. The newly
-created overlay item is also given new references to its supporting
-underlay items.
-
-**Equality case:**
-
-If an item doesn’t fulfill the equality condition with any other items,
-processing finishes after adding the item into topology store. It will
-stay there for future use, ready to create an aggregated item with a new
-underlay item, with which it would satisfy the equality condition.
-
-**Unification case:**
-
-An overlay item is created for all underlay items, even those which
-don’t fulfill the equality condition with any other items. This means
-that an overlay item is created for every underlay item, but for items
-which satisfy the equality condition, an aggregated item is created.
-
-Update Node
-^^^^^^^^^^^
-
-Processing of updated underlay items depends on whether the target field
-has been modified. If yes, then:
-
-- if the underlay item belonged to some overlay item, it is removed
- from that item. Next, if the aggregation condition on the target
- field is satisfied, the item is inserted into another overlay item.
- If the condition isn’t met then:
-
- - in equality case - the item will not be present in overlay
- topology.
-
- - in unification case - the item will create an overlay item with a
- single underlay item and this will be written into overlay
- topology.
-
-- if the item didn’t belong to some overlay item, it is checked again
- for aggregation with other underlay items.
-
-Remove Node
-^^^^^^^^^^^
-
-The underlay item is removed from the corresponding topology store, from
-it’s overlay item (if it belongs to one) and this way it is also removed
-from overlay topology.
-
-**Equality case:**
-
-If there is only one underlay item left in the overlay item, the overlay
-item is removed.
-
-**Unification case:**
-
-The overlay item is removed once it refers to no underlay item.
-
-Filtration
-~~~~~~~~~~
-
-Filtration is an operation which results in creation of overlay topology
-containing only items fulfilling conditions set in the topoprocessing
-request.
-
-Create Underlay Item
-^^^^^^^^^^^^^^^^^^^^
-
-If a newly created underlay item passes all filtrators and their
-conditions, then it is stored in topology store and a creation
-notification is delivered into topology manager. No operation otherwise.
-
-Update Underlay Item
-^^^^^^^^^^^^^^^^^^^^
-
-First, the updated item is checked for presence in topology store:
-
-- if it is present in topology store:
-
- - if it meets the filtering conditions, then processUpdatedData
- notification is triggered
-
- - else processRemovedData notification is triggered
-
-- if item isn’t present in topology store
-
- - if item meets filtering conditions, then processCreatedData
- notification is triggered
-
- - else it is ignored
-
-Remove Underlay Item
-^^^^^^^^^^^^^^^^^^^^
-
-If an underlay node is supporting some overlay node, the overlay node is
-simply removed.
-
-Default Filtrator Types
-^^^^^^^^^^^^^^^^^^^^^^^
-
-There are seven types of default filtrators defined in the framework:
-
-- IPv4-address filtrator - checks if specified field meets IPv4 address
- + mask criteria
-
-- IPv6-address filtrator - checks if specified field meets IPv6 address
- + mask criteria
-
-- Specific number filtrator - checks for specific number
-
-- Specific string filtrator - checks for specific string
-
-- Range number filtrator - checks if specified field is higher than
- provided minimum (inclusive) and lower than provided maximum
- (inclusive)
-
-- Range string filtrator - checks if specified field is alphabetically
- greater than provided minimum (inclusive) and alphabetically lower
- than provided maximum (inclusive)
-
-- Script filtrator - allows a user or application to implement their
- own filtrator
-
-Register Custom Filtrator
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-There might be some use case that cannot be achieved with the default
-filtrators. In these cases, the framework offers the possibility for a
-user or application to register a custom filtrator.
-
-Pre-Filtration / Filtration & Aggregation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This feature was introduced in order to lower memory and performance
-demands. It is a combination of the filtration and aggregation
-operations. First, uninteresting items are filtered out and then
-aggregation is performed only on items that passed filtration. This way
-the framework saves on compute time. The PreAggregationFiltrator and
-TopologyAggregator share the same TopoStoreProvider (and thus topology
-store) which results in lower memory demands (as underlay items are
-stored only in one topology store - they aren’t stored twice).
-
-Link Computation
-----------------
-
-Chapter Overview
-~~~~~~~~~~~~~~~~
-
-While processing the topology request, we create overlay nodes with
-lists of supporting underlay nodes. Because these overlay nodes have
-completely new identifiers, we lose link information. To regain this
-link information, we provide Link Computation functionality. Its main
-purpose is to create new overlay links based on the links from the
-underlay topologies and underlay items from overlay items. The required
-information for Link Computation is provided via the Link Computation
-model in
-(`topology-link-computation.yang <https://git.opendaylight.org/gerrit/gitweb?p=topoprocessing.git;a=blob;f=topoprocessing-api/src/main/yang/topology-link-computation.yang;hb=refs/heads/stable/boron>`__).
-
-Link Computation Functionality
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Let us consider two topologies with following components:
-
-Topology 1:
-
-- Node: ``node:1:1``
-
-- Node: ``node:1:2``
-
-- Node: ``node:1:3``
-
-- Link: ``link:1:1`` (from ``node:1:1`` to ``node:1:2``)
-
-- Link: ``link:1:2`` (from ``node:1:3`` to ``node:1:2``)
-
-Topology 2:
-
-- Node: ``node:2:1``
-
-- Node: ``node:2:2``
-
-- Node: ``node:2:3``
-
-- Link: ``link:2:1`` (from ``node:2:1`` to ``node:2:3``)
-
-Now let’s say that we applied some operations over these topologies that
-results into aggregating together
-
-- ``node:1:1`` and ``node:2:3`` (``node:1``)
-
-- ``node:1:2`` and ``node:2:2`` (``node:2``)
-
-- ``node:1:3`` and ``node:2:1`` (``node:3``)
-
-At this point we can no longer use available links in new topology
-because of the node ID change, so we must create new overlay links with
-source and destination node set to new nodes IDs. It means that
-``link:1:1`` from topology 1 will create new link ``link:1``. Since
-original source (``node:1:1``) is already aggregated under ``node:1``,
-it will become source node for ``link:1``. Using same method the
-destination will be ``node:2``. And the final output will be three
-links:
-
-- ``link:1``, from ``node:1`` to ``node:2``
-
-- ``link:2``, from ``node:3`` to ``node:2``
-
-- ``link:3``, from ``node:3`` to ``node:1``
-
-.. figure:: ./images/topoprocessing/LinkComputation.png
- :alt: Overlay topology with computed links
-
- Overlay topology with computed links
-
-In-Depth Look
-~~~~~~~~~~~~~
-
-The main logic behind Link Computation is executed in the LinkCalculator
-operator. The required information is passed to LinkCalculator through
-the LinkComputation section of the topology request. This section is
-defined in the topology-link-computation.yang file. The main logic also
-covers cases when some underlay nodes may not pass through other
-topology operators.
-
-Link Computation Model
-^^^^^^^^^^^^^^^^^^^^^^
-
-There are three essential pieces of information for link computations.
-All of them are provided within the LinkComputation section. These
-pieces are:
-
-- output model
-
-.. code::
-
- leaf output-model {
- type identityref {
- base topo-corr:model;
- }
- description "Desired output model for computed links.";
- }
-
-- overlay topology with new nodes
-
-.. code::
-
- container node-info {
- leaf node-topology {
- type string;
- mandatory true;
- description "Topology that contains aggregated nodes.
- This topology will be used for storing computed links.";
- }
- uses topo-corr:input-model-grouping;
- }
-
-- underlay topologies with original links
-
-.. code::
-
- list link-info {
- key "link-topology input-model";
- leaf link-topology {
- type string;
- mandatory true;
- description "Topology that contains underlay (base) links.";
- }
- leaf aggregated-links {
- type boolean;
- description "Defines if link computation should be based on supporting-links.";
- }
- uses topo-corr:input-model-grouping;
- }
-
-This whole section is augmented into ``network-topology:topology``. By
-placing this section out of correlations section, it allows us to send
-link computation request separately from topology operations request.
-
-Main Logic
-^^^^^^^^^^
-
-Taking into consideration that some of the underlay nodes may not
-transform into overlay nodes (e.g. they are filtered out), we created
-two possible states for links:
-
-- matched - a link is considered as matched when both original source
- and destination node were transformed to overlay nodes
-
-- waiting - a link is considered as waiting if original source,
- destination or both nodes are missing from the overlay topology
-
-All links in waiting the state are stored in waitingLinks list, already
-matched links are stored in matchedLinks list and overlay nodes are
-stored in the storedOverlayNodes list. All processing is based only on
-information in these lists. Processing created, updated and removed
-underlay items is slightly different and described in next sections
-separately.
-
-**Processing Created Items**
-
-Created items can be either nodes or links, depending on the type of
-listener from which they came. In the case of a link, it is immediately
-added to waitingLinks and calculation for possible overlay link
-creations (calculatePossibleLink) is started. The flow diagram for this
-process is shown in the following picture:
-
-.. figure:: ./images/topoprocessing/LinkComputationFlowDiagram.png
- :alt: Flow diagram of processing created items
-
- Flow diagram of processing created items
-
-Searching for the source and destination nodes in the
-calculatePossibleLink method runs over each node in storedOverlayNodes
-and the IDs of each supporting node is compared against IDs from the
-underlay link’s source and destination nodes. If there are any nodes
-missing, the link remains in the waiting state. If both the source and
-destination nodes are found, the corresponding overlay nodes is recorded
-as the new source and destination. The link is then removed from
-waitingLinks and a new CalculatedLink is added to the matched links. At
-the end, the new link (if it exists) is written into the datastore.
-
-If the created item is an overlayNode, this is added to
-storedOverlayNodes and we call calculatePossibleLink for every link in
-waitingLinks.
-
-**Processing Updated Items**
-
-The difference from processing created items is that we have three
-possible types of updated items: overlay nodes, waiting underlay links,
-and matched underlay links.
-
-- In the case of a change in a matched link, this must be recalculated
- and based on the result it will either be matched with new source and
- destination or will be returned to waiting links. If the link is
- moved back to a waiting state, it must also be removed from the
- datastore.
-
-- In the case of change in a waiting link, it is passed to the
- calculation process and based on the result will either remain in
- waiting state or be promoted to the matched state.
-
-- In the case of a change in an overlay node, storedOverlayNodes must
- be updated properly and all links must be recalculated in case of
- changes.
-
-**Processing Removed items**
-
-Same as for processing updated item. There can be three types of removed
-items:
-
-- In case of waiting link removal, the link is just removed from
- waitingLinks
-
-- In case of matched link removal, the link is removed from
- matchingLinks and datastore
-
-- In case of overlay node removal, the node must be removed form
- storedOverlayNodes and all matching links must be recalculated
-
-Wrapper, RPC Republishing, Writing Mechanism
---------------------------------------------
-
-Chapter Overview
-~~~~~~~~~~~~~~~~
-
-During the process of aggregation and filtration, overlay items (so
-called logical nodes) were created from underlay items (physical nodes).
-In the topology manager, overlay items are put into a wrapper. A wrapper
-is identified with unique ID and contains list of logical nodes.
-Wrappers are used to deal with transitivity of underlay items - which
-permits grouping of overlay items (into wrappers).
-
-.. figure:: ./images/topoprocessing/wrapper.png
- :alt: Wrapper
-
- Wrapper
-
-PN1, PN2, PN3 = physical nodes
-
-LN1, LN2 = logical nodes
-
-RPC Republishing
-~~~~~~~~~~~~~~~~
-
-All RPCs registered to handle underlay items are re-registered under
-their corresponding wrapper ID. RPCs of underlay items (belonging to an
-overlay item) are gathered, and registered under ID of their wrapper.
-
-RPC Call
-^^^^^^^^
-
-When RPC is called on overlay item, this call is delegated to it’s
-underlay items, this means that the RPC is called on all underlay items
-of this overlay item.
-
-Writing Mechanism
-~~~~~~~~~~~~~~~~~
-
-When a wrapper (containing overlay item(s) with it’s underlay item(s))
-is ready to be written into data store, it has to be converted into DOM
-format. After this translation is done, the result is written into
-datastore. Physical nodes are stored as supporting-nodes. In order to
-use resources responsibly, writing operation is divided into two steps.
-First, a set of threads registers prepared operations (deletes and puts)
-and one thread makes actual write operation in batch.
-
-Topology Rendering Guide - Inventory Rendering
-----------------------------------------------
-
-Chapter Overview
-~~~~~~~~~~~~~~~~
-
-In the most recent OpenDaylight release, the opendaylight-inventory
-model is marked as deprecated. To facilitate migration from it to the
-network-topology model, there were requests to render (translate) data
-from inventory model (whether augmented or not) to another model for
-further processing. The Topology Processing Framework was extended to
-provide this functionality by implementing several rendering-specific
-classes. This chapter is a step-by-step guide on how to implement your
-own topology rendering using our inventory rendering as an example.
-
-Use case
-~~~~~~~~
-
-For the purpose of this guide we are going to render the following
-augmented fields from the OpenFlow model:
-
-- from inventory node:
-
- - manufacturer
-
- - hardware
-
- - software
-
- - serial-number
-
- - description
-
- - ip-address
-
-- from inventory node-connector:
-
- - name
-
- - hardware-address
-
- - current-speed
-
- - maximum-speed
-
-We also want to preserve the node ID and termination-point ID from
-opendaylight-topology-inventory model, which is network-topology part of
-the inventory model.
-
-Implementation
-~~~~~~~~~~~~~~
-
-There are two ways to implement support for your specific topology
-rendering:
-
-- add a module to your project that depends on the Topology Processing
- Framework
-
-- add a module to the Topology Processing Framework itself
-
-Regardless, a successful implementation must complete all of the
-following steps.
-
-Step1 - Target Model Creation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Because the network-topology node does not have fields to store all
-desired data, it is necessary to create new model to render this extra
-data in to. For this guide we created the inventory-rendering model. The
-picture below shows how data will be rendered and stored.
-
-.. figure:: ./images/topoprocessing/Inventory_Rendering_Use_case.png
- :alt: Rendering to the inventory-rendering model
-
- Rendering to the inventory-rendering model
-
-.. important::
-
- When implementing your version of the topology-rendering model in
- the Topology Processing Framework, the source file of the model
- (.yang) must be saved in /topoprocessing-api/src/main/yang folder so
- corresponding structures can be generated during build and can be
- accessed from every module through dependencies.
-
-When the target model is created you have to add an identifier through
-which you can set your new model as output model. To do that you have to
-add another identity item to topology-correlation.yang file. For our
-inventory-rendering model identity looks like this:
-
-.. code::
-
- identity inventory-rendering-model {
- description "inventory-rendering.yang";
- base model;
- }
-
-After that you will be able to set inventory-rendering-model as output
-model in XML.
-
-Step2 - Module and Feature Creation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. important::
-
- This and following steps are based on the `model specific
- approach <#_model_specific_approach>`__ in the Topology Processing
- Framework. We highly recommend that you familiarize yourself with
- this approach in advance.
-
-To create a base module and add it as a feature to Karaf in the Topology
-Processing Framework we made the changes in following
-`commit <https://git.opendaylight.org/gerrit/#/c/26223/>`__. Changes in
-other projects will likely be similar.
-
-+--------------------------------------+--------------------------------------+
-| File | Changes |
-+======================================+======================================+
-| pom.xml | add new module to topoprocessing |
-+--------------------------------------+--------------------------------------+
-| features.xml | add feature to topoprocessing |
-+--------------------------------------+--------------------------------------+
-| features/pom.xml | add dependencies needed by features |
-+--------------------------------------+--------------------------------------+
-| topoprocessing-artifacts/pom.xml | add artifact |
-+--------------------------------------+--------------------------------------+
-| topoprocessing-config/pom.xml | add configuration file |
-+--------------------------------------+--------------------------------------+
-| 81-topoprocessing-inventory-renderin | configuration file for new module |
-| g-config.xml | |
-+--------------------------------------+--------------------------------------+
-| topoprocessing-inventory-rendering/p | main pom for new module |
-| om.xml | |
-+--------------------------------------+--------------------------------------+
-| TopoProcessingProviderIR.java | contains startup method which |
-| | register new model adapter |
-+--------------------------------------+--------------------------------------+
-| TopoProcessingProviderIRModule.java | generated class which contains |
-| | createInstance method. You should |
-| | call your startup method from here. |
-+--------------------------------------+--------------------------------------+
-| TopoProcessingProviderIRModuleFactor | generated class. You will probably |
-| y.java | not need to edit this file |
-+--------------------------------------+--------------------------------------+
-| log4j.xml | configuration file for logger |
-| | topoprocessing-inventory-rendering-p |
-| | rovider-impl.yang |
-+--------------------------------------+--------------------------------------+
-
-Step3 - Module Adapters Creation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-There are seven mandatory interfaces or abstract classes that needs to
-be implemented in each module. They are:
-
-- TopoProcessingProvider - provides module registration
-
-- ModelAdapter - provides model specific instances
-
-- TopologyRequestListener - listens on changes in the configuration
- datastore
-
-- TopologyRequestHandler - processes configuration datastore changes
-
-- UnderlayTopologyListener - listens for changes in the specific model
-
-- LinkTransaltor and NodeTranslator - used by OverlayItemTranslator to
- create NormalizedNodes from OverlayItems
-
-The name convention we used was to add an abbreviation for the specific
-model to the beginning of implementing class name (e.g. the
-IRModelAdapter refers to class which implements ModelAdapter in module
-Inventory Rendering). In the case of the provider class, we put the
-abbreviation at the end.
-
-.. important::
-
- - In the next sections, we use the terms TopologyRequestListener,
- TopologyRequestHandler, etc. without a prepended or appended
- abbreviation because the steps apply regardless of which specific
- model you are targeting.
-
- - If you want to implement rendering from inventory to
- network-topology, you can just copy-paste our module and
- additional changes will be required only in the output part.
-
-**Provider part**
-
-This part is the starting point of the whole module. It is responsible
-for creating and registering TopologyRequestListeners. It is necessary
-to create three classes which will import:
-
-- **TopoProcessingProviderModule** - is a generated class from
- topoprocessing-inventory-rendering-provider-impl.yang (created in
- previous step, file will appear after first build). Its method
- ``createInstance()`` is called at the feature start and must be
- modified to create an instance of TopoProcessingProvider and call its
- ``startup(TopoProcessingProvider topoProvider)`` function.
-
-- **TopoProcessingProvider** - in
- ``startup(TopoProcessingProvider topoProvider)`` function provides
- ModelAdapter registration to TopoProcessingProviderImpl.
-
-- **ModelAdapter** - provides creation of corresponding module specific
- classes.
-
-**Input part**
-
-This includes the creation of the classes responsible for input data
-processing. In this case, we had to create five classes implementing:
-
-- **TopologyRequestListener** and **TopologyRequestHandler** - when
- notified about a change in the configuration datastore, verify if the
- change contains a topology request (has correlations in it) and
- creates UnderlayTopologyListeners if needed. The implementation of
- these classes will differ according to the model in which are
- correlations saved (network-topology or i2rs). In the case of using
- network-topology, as the input model, you can use our classes
- IRTopologyRequestListener and IRTopologyRequestHandler.
-
-- **UnderlayTopologyListener** - registers underlay listeners according
- to input model. In our case (listening in the inventory model), we
- created listeners for the network-topology model and inventory model,
- and set the NotificationInterConnector as the first operator and set
- the IRRenderingOperator as the second operator (after
- NotificationInterConnector). Same as for
- TopologyRequestListener/Handler, if you are rendering from the
- inventory model, you can use our class IRUnderlayTopologyListener.
-
-- **InventoryListener** - a new implementation of this class is
- required only for inventory input model. This is because the
- InventoryListener from topoprocessing-impl requires pathIdentifier
- which is absent in the case of rendering.
-
-- **TopologyOperator** - replaces classic topoprocessing operator.
- While the classic operator provides specific operations on topology,
- the rendering operator just wraps each received UnderlayItem to
- OverlayItem and sends them to write.
-
-.. important::
-
- For purposes of topology rendering from inventory to
- network-topology, there are misused fields in UnderlayItem as
- follows:
-
- - item - contains node from network-topology part of inventory
-
- - leafItem - contains node from inventory
-
- In case of implementing UnderlayTopologyListener or
- InventoryListener you have to carefully adjust UnderlayItem creation
- to these terms.
-
-**Output part**
-
-The output part of topology rendering is responsible for translating
-received overlay items to normalized nodes. In the case of inventory
-rendering, this is where node information from inventory are combined
-with node information from network-topology. This combined information
-is stored in our inventory-rendering model normalized node and passed to
-the writer.
-
-The output part consists of two translators implementing the
-NodeTranslator and LinkTranslator interfaces.
-
-**NodeTranslator implementation** - The NodeTranslator interface has one
-``translate(OverlayItemWrapper wrapper)`` method. For our purposes,
-there is one important thing in wrapper - the list of OverlayItems which
-have one or more common UnderlayItems. Regardless of this list, in the
-case of rendering it will always contains only one OverlayItem. This
-item has list of UnderlayItems, but again in case of rendering there
-will be only one UnderlayItem item in this list. In NodeTranslator, the
-OverlayItem and corresponding UnderlayItem represent nodes from the
-translating model.
-
-The UnderlayItem has several attributes. How you will use these
-attributes in your rendering is up to you, as you create this item in
-your topology operator. For example, as mentioned above, in our
-inventory rendering example is an inventory node normalized node stored
-in the UnderlayItem leafNode attribute, and we also store node-id from
-network-topology model in UnderlayItem itemId attribute. You can now use
-these attributes to build a normalized node for your new model. How to
-read and create normalized nodes is out of scope of this document.
-
-**LinkTranslator implementation** - The LinkTranslator interface also
-has one ``translate(OverlayItemWrapper wrapper)`` method. In our
-inventory rendering this method returns ``null``, because the inventory
-model doesn’t have links. But if you also need links, this is the place
-where you should translate it into a normalized node for your model. In
-LinkTranslator, the OverlayItem and corresponding UnderlayItem represent
-links from the translating model. As in NodeTranslator, there will be
-only one OverlayItem and one UnderlayItem in the corresponding lists.
-
-Testing
-~~~~~~~
-
-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.
-
-| 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:
-
-+--------------------------------------+--------------------------------------+
-| Header | Value |
-+======================================+======================================+
-| Content-Type: | application/xml |
-+--------------------------------------+--------------------------------------+
-| Accept: | application/xml |
-+--------------------------------------+--------------------------------------+
-| username: | admin |
-+--------------------------------------+--------------------------------------+
-| password: | admin |
-+--------------------------------------+--------------------------------------+
-
-Firstly send topology request to
-http://localhost:8181/restconf/config/network-topology:network-topology/topology/render:1
-with method PUT. Example of simple rendering request:
-
-.. code:: xml
-
- <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <topology-id>render:1</topology-id>
- <correlations xmlns="urn:opendaylight:topology:correlation" >
- <output-model>inventory-rendering-model</output-model>
- <correlation>
- <correlation-id>1</correlation-id>
- <type>rendering-only</type>
- <correlation-item>node</correlation-item>
- <rendering>
- <underlay-topology>und-topo:1</underlay-topology>
- </rendering>
- </correlation>
- </correlations>
- </topology>
-
-This request says that we want create topology with name render:1 and
-this topology should be stored in the inventory-rendering-model and it
-should be created from topology flow:1 by node rendering.
-
-Next we send the network-topology part of topology flow:1. So to the URL
-http://localhost:8181/restconf/config/network-topology:network-topology/topology/und-topo:1
-we PUT:
-
-.. code:: xml
-
- <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology"
- xmlns:it="urn:opendaylight:model:topology:inventory"
- xmlns:i="urn:opendaylight:inventory">
- <topology-id>und-topo:1</topology-id>
- <node>
- <node-id>openflow:1</node-id>
- <it:inventory-node-ref>
- /i:nodes/i:node[i:id="openflow:1"]
- </it:inventory-node-ref>
- <termination-point>
- <tp-id>tp:1</tp-id>
- <it:inventory-node-connector-ref>
- /i:nodes/i:node[i:id="openflow:1"]/i:node-connector[i:id="openflow:1:1"]
- </it:inventory-node-connector-ref>
- </termination-point>
- </node>
- </topology>
-
-And the last input will be inventory part of topology. To the URL
-http://localhost:8181/restconf/config/opendaylight-inventory:nodes we
-PUT:
-
-.. code:: xml
-
- <nodes
- xmlns="urn:opendaylight:inventory">
- <node>
- <id>openflow:1</id>
- <node-connector>
- <id>openflow:1:1</id>
- <port-number
- xmlns="urn:opendaylight:flow:inventory">1
- </port-number>
- <current-speed
- xmlns="urn:opendaylight:flow:inventory">10000000
- </current-speed>
- <name
- xmlns="urn:opendaylight:flow:inventory">s1-eth1
- </name>
- <supported
- xmlns="urn:opendaylight:flow:inventory">
- </supported>
- <current-feature
- xmlns="urn:opendaylight:flow:inventory">copper ten-gb-fd
- </current-feature>
- <configuration
- xmlns="urn:opendaylight:flow:inventory">
- </configuration>
- <peer-features
- xmlns="urn:opendaylight:flow:inventory">
- </peer-features>
- <maximum-speed
- xmlns="urn:opendaylight:flow:inventory">0
- </maximum-speed>
- <advertised-features
- xmlns="urn:opendaylight:flow:inventory">
- </advertised-features>
- <hardware-address
- xmlns="urn:opendaylight:flow:inventory">0E:DC:8C:63:EC:D1
- </hardware-address>
- <state
- xmlns="urn:opendaylight:flow:inventory">
- <link-down>false</link-down>
- <blocked>false</blocked>
- <live>false</live>
- </state>
- <flow-capable-node-connector-statistics
- xmlns="urn:opendaylight:port:statistics">
- <receive-errors>0</receive-errors>
- <receive-frame-error>0</receive-frame-error>
- <receive-over-run-error>0</receive-over-run-error>
- <receive-crc-error>0</receive-crc-error>
- <bytes>
- <transmitted>595</transmitted>
- <received>378</received>
- </bytes>
- <receive-drops>0</receive-drops>
- <duration>
- <second>28</second>
- <nanosecond>410000000</nanosecond>
- </duration>
- <transmit-errors>0</transmit-errors>
- <collision-count>0</collision-count>
- <packets>
- <transmitted>7</transmitted>
- <received>5</received>
- </packets>
- <transmit-drops>0</transmit-drops>
- </flow-capable-node-connector-statistics>
- </node-connector>
- <node-connector>
- <id>openflow:1:LOCAL</id>
- <port-number
- xmlns="urn:opendaylight:flow:inventory">4294967294
- </port-number>
- <current-speed
- xmlns="urn:opendaylight:flow:inventory">0
- </current-speed>
- <name
- xmlns="urn:opendaylight:flow:inventory">s1
- </name>
- <supported
- xmlns="urn:opendaylight:flow:inventory">
- </supported>
- <current-feature
- xmlns="urn:opendaylight:flow:inventory">
- </current-feature>
- <configuration
- xmlns="urn:opendaylight:flow:inventory">
- </configuration>
- <peer-features
- xmlns="urn:opendaylight:flow:inventory">
- </peer-features>
- <maximum-speed
- xmlns="urn:opendaylight:flow:inventory">0
- </maximum-speed>
- <advertised-features
- xmlns="urn:opendaylight:flow:inventory">
- </advertised-features>
- <hardware-address
- xmlns="urn:opendaylight:flow:inventory">BA:63:87:0C:76:41
- </hardware-address>
- <state
- xmlns="urn:opendaylight:flow:inventory">
- <link-down>false</link-down>
- <blocked>false</blocked>
- <live>false</live>
- </state>
- <flow-capable-node-connector-statistics
- xmlns="urn:opendaylight:port:statistics">
- <receive-errors>0</receive-errors>
- <receive-frame-error>0</receive-frame-error>
- <receive-over-run-error>0</receive-over-run-error>
- <receive-crc-error>0</receive-crc-error>
- <bytes>
- <transmitted>576</transmitted>
- <received>468</received>
- </bytes>
- <receive-drops>0</receive-drops>
- <duration>
- <second>28</second>
- <nanosecond>426000000</nanosecond>
- </duration>
- <transmit-errors>0</transmit-errors>
- <collision-count>0</collision-count>
- <packets>
- <transmitted>6</transmitted>
- <received>6</received>
- </packets>
- <transmit-drops>0</transmit-drops>
- </flow-capable-node-connector-statistics>
- </node-connector>
- <serial-number
- xmlns="urn:opendaylight:flow:inventory">None
- </serial-number>
- <manufacturer
- xmlns="urn:opendaylight:flow:inventory">Nicira, Inc.
- </manufacturer>
- <hardware
- xmlns="urn:opendaylight:flow:inventory">Open vSwitch
- </hardware>
- <software
- xmlns="urn:opendaylight:flow:inventory">2.1.3
- </software>
- <description
- xmlns="urn:opendaylight:flow:inventory">None
- </description>
- <ip-address
- xmlns="urn:opendaylight:flow:inventory">10.20.30.40
- </ip-address>
- <meter-features
- xmlns="urn:opendaylight:meter:statistics">
- <max_bands>0</max_bands>
- <max_color>0</max_color>
- <max_meter>0</max_meter>
- </meter-features>
- <group-features
- xmlns="urn:opendaylight:group:statistics">
- <group-capabilities-supported
- xmlns:x="urn:opendaylight:group:types">x:chaining
- </group-capabilities-supported>
- <group-capabilities-supported
- xmlns:x="urn:opendaylight:group:types">x:select-weight
- </group-capabilities-supported>
- <group-capabilities-supported
- xmlns:x="urn:opendaylight:group:types">x:select-liveness
- </group-capabilities-supported>
- <max-groups>4294967040</max-groups>
- <actions>67082241</actions>
- <actions>0</actions>
- </group-features>
- </node>
- </nodes>
-
-After this, the expected result from a GET request to
-http://127.0.0.1:8181/restconf/operational/network-topology:network-topology
-is:
-
-.. code:: xml
-
- <network-topology
- xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <topology>
- <topology-id>render:1</topology-id>
- <node>
- <node-id>openflow:1</node-id>
- <node-augmentation
- xmlns="urn:opendaylight:topology:inventory:rendering">
- <ip-address>10.20.30.40</ip-address>
- <serial-number>None</serial-number>
- <manufacturer>Nicira, Inc.</manufacturer>
- <description>None</description>
- <hardware>Open vSwitch</hardware>
- <software>2.1.3</software>
- </node-augmentation>
- <termination-point>
- <tp-id>openflow:1:1</tp-id>
- <tp-augmentation
- xmlns="urn:opendaylight:topology:inventory:rendering">
- <hardware-address>0E:DC:8C:63:EC:D1</hardware-address>
- <current-speed>10000000</current-speed>
- <maximum-speed>0</maximum-speed>
- <name>s1-eth1</name>
- </tp-augmentation>
- </termination-point>
- <termination-point>
- <tp-id>openflow:1:LOCAL</tp-id>
- <tp-augmentation
- xmlns="urn:opendaylight:topology:inventory:rendering">
- <hardware-address>BA:63:87:0C:76:41</hardware-address>
- <current-speed>0</current-speed>
- <maximum-speed>0</maximum-speed>
- <name>s1</name>
- </tp-augmentation>
- </termination-point>
- </node>
- </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
------------------------
-
-The basic provider class is TopoProcessingProvider which provides
-startup and shutdown methods. Otherwise, the framework communicates via
-requests and outputs stored in the MD-SAL datastores.
-
-API Reference Documentation
----------------------------
-
-You can find API examples on `this wiki
-page <https://wiki.opendaylight.org/view/Topology_Processing_Framework:Developer_Guide:REST_API_Specification>`__.
+++ /dev/null
-.. _ttp_cli_tools_dev_guide:
-
-TTP CLI Tools Developer Guide
-=============================
-
-Overview
---------
-
-Table Type Patterns are a specification developed by the `Open
-Networking Foundation <https://www.opennetworking.org/>`__ to enable the
-description and negotiation of subsets of the OpenFlow protocol. This is
-particularly useful for hardware switches that support OpenFlow as it
-enables the to describe what features they do (and thus also what
-features they do not) support. More details can be found in the full
-specification listed on the `OpenFlow specifications
-page <https://www.opennetworking.org/sdn-resources/onf-specifications/openflow>`__.
-
-The TTP CLI Tools provide a way for people interested in TTPs to read
-in, validate, output, and manipulate TTPs as a self-contained,
-executable jar file.
-
-TTP CLI Tools Architecture
---------------------------
-
-The TTP CLI Tools use the TTP Model and the YANG Tools/RESTCONF codecs
-to translate between the Data Transfer Objects (DTOs) and JSON/XML.
-
-Command Line Options
---------------------
-
-This will cover the various options for the CLI Tools. For now, there
-are no options and it merely outputs fixed data using the codecs.
-
+++ /dev/null
-.. _ttp_model_dev_guide:
-
-TTP Model Developer Guide
-=========================
-
-Overview
---------
-
-Table Type Patterns are a specification developed by the `Open
-Networking Foundation <https://www.opennetworking.org/>`__ to enable the
-description and negotiation of subsets of the OpenFlow protocol. This is
-particularly useful for hardware switches that support OpenFlow as it
-enables the to describe what features they do (and thus also what
-features they do not) support. More details can be found in the full
-specification listed on the `OpenFlow specifications
-page <https://www.opennetworking.org/sdn-resources/onf-specifications/openflow>`__.
-
-TTP Model Architecture
-----------------------
-
-The TTP Model provides a YANG-modeled type for a TTP and allows them to
-be associated with a master list of known TTPs, as well as active and
-supported TTPs with nodes in the MD-SAL inventory model.
-
-Key APIs and Interfaces
------------------------
-
-The key API provided by the TTP Model feature is the ability to store a
-set of TTPs in the MD-SAL as well as associate zero or one active TTPs
-and zero or more supported TTPs along with a given node in the MD-SAL
-inventory model.
-
-API Reference Documentation
----------------------------
-
-RESTCONF
-~~~~~~~~
-
-See the generated RESTCONF API documentation at:
-http://localhost:8181/apidoc/explorer/index.html
-
-Look for the onf-ttp module to expand and see the various RESTCONF APIs.
-
-Java Bindings
-~~~~~~~~~~~~~
-
-As stated above there are 3 locations where a Table Type Pattern can be
-placed into the MD-SAL Data Store. They correspond to 3 different REST
-API URIs:
-
-1. ``restconf/config/onf-ttp:opendaylight-ttps/onf-ttp:table-type-patterns/``
-
-2. ``restconf/config/opendaylight-inventory:nodes/node/{id}/ttp-inventory-node:active_ttp/``
-
-3. ``restconf/config/opendaylight-inventory:nodes/node/{id}/ttp-inventory-node:supported_ttps/``
-
-.. note::
-
- Typically, these URIs are running on the machine the controller is
- on at port 8181. If you are on the same machine they can thus be
- accessed at ``http://localhost:8181/<uri>``
-
-Using the TTP Model RESTCONF APIs
----------------------------------
-
-Setting REST HTTP Headers
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Authentication
-^^^^^^^^^^^^^^
-
-The REST API calls require authentication by default. The default method
-is to use basic auth with a user name and password of ‘admin’.
-
-Content-Type and Accept
-^^^^^^^^^^^^^^^^^^^^^^^
-
-RESTCONF supports both xml and json. This example focuses on JSON, but
-xml can be used just as easily. When doing a PUT or POST be sure to
-specify the appropriate ``Conetnt-Type`` header: either
-``application/json`` or ``application/xml``.
-
-When doing a GET be sure to specify the appropriate ``Accept`` header:
-again, either ``application/json`` or ``application/xml``.
-
-Content
-~~~~~~~
-
-The contents of a PUT or POST should be a OpenDaylight Table Type
-Pattern. An example of one is provided below. The example can also be
-found at `parser/sample-TTP-from-tests.ttp in the TTP git
-repository <https://git.opendaylight.org/gerrit/gitweb?p=ttp.git;a=blob;f=parser/sample-TTP-from-tests.ttp;h=45130949b25c6f86b750959d27d04ec2208935fb;hb=HEAD>`__.
-
-**Sample Table Type Pattern (json).**
-
-::
-
- {
- "table-type-patterns": {
- "table-type-pattern": [
- {
- "security": {
- "doc": [
- "This TTP is not published for use by ONF. It is an example and for",
- "illustrative purposes only.",
- "If this TTP were published for use it would include",
- "guidance as to any security considerations in this doc member."
- ]
- },
- "NDM_metadata": {
- "authority": "org.opennetworking.fawg",
- "OF_protocol_version": "1.3.3",
- "version": "1.0.0",
- "type": "TTPv1",
- "doc": [
- "Example of a TTP supporting L2 (unicast, multicast, flooding), L3 (unicast only),",
- "and an ACL table."
- ],
- "name": "L2-L3-ACLs"
- },
- "identifiers": [
- {
- "doc": [
- "The VLAN ID of a locally attached L2 subnet on a Router."
- ],
- "var": "<subnet_VID>"
- },
- {
- "doc": [
- "An OpenFlow group identifier (integer) identifying a group table entry",
- "of the type indicated by the variable name"
- ],
- "var": "<<group_entry_types/name>>"
- }
- ],
- "features": [
- {
- "doc": [
- "Flow entry notification Extension – notification of changes in flow entries"
- ],
- "feature": "ext187"
- },
- {
- "doc": [
- "Group notifications Extension – notification of changes in group or meter entries"
- ],
- "feature": "ext235"
- }
- ],
- "meter_table": {
- "meter_types": [
- {
- "name": "ControllerMeterType",
- "bands": [
- {
- "type": "DROP",
- "rate": "1000..10000",
- "burst": "50..200"
- }
- ]
- },
- {
- "name": "TrafficMeter",
- "bands": [
- {
- "type": "DSCP_REMARK",
- "rate": "10000..500000",
- "burst": "50..500"
- },
- {
- "type": "DROP",
- "rate": "10000..500000",
- "burst": "50..500"
- }
- ]
- }
- ],
- "built_in_meters": [
- {
- "name": "ControllerMeter",
- "meter_id": 1,
- "type": "ControllerMeterType",
- "bands": [
- {
- "rate": 2000,
- "burst": 75
- }
- ]
- },
- {
- "name": "AllArpMeter",
- "meter_id": 2,
- "type": "ControllerMeterType",
- "bands": [
- {
- "rate": 1000,
- "burst": 50
- }
- ]
- }
- ]
- },
- "table_map": [
- {
- "name": "ControlFrame",
- "number": 0
- },
- {
- "name": "IngressVLAN",
- "number": 10
- },
- {
- "name": "MacLearning",
- "number": 20
- },
- {
- "name": "ACL",
- "number": 30
- },
- {
- "name": "L2",
- "number": 40
- },
- {
- "name": "ProtoFilter",
- "number": 50
- },
- {
- "name": "IPv4",
- "number": 60
- },
- {
- "name": "IPv6",
- "number": 80
- }
- ],
- "parameters": [
- {
- "doc": [
- "documentation"
- ],
- "name": "Showing-curt-how-this-works",
- "type": "type1"
- }
- ],
- "flow_tables": [
- {
- "doc": [
- "Filters L2 control reserved destination addresses and",
- "may forward control packets to the controller.",
- "Directs all other packets to the Ingress VLAN table."
- ],
- "name": "ControlFrame",
- "flow_mod_types": [
- {
- "doc": [
- "This match/action pair allows for flow_mods that match on either",
- "ETH_TYPE or ETH_DST (or both) and send the packet to the",
- "controller, subject to metering."
- ],
- "name": "Frame-To-Controller",
- "match_set": [
- {
- "field": "ETH_TYPE",
- "match_type": "all_or_exact"
- },
- {
- "field": "ETH_DST",
- "match_type": "exact"
- }
- ],
- "instruction_set": [
- {
- "doc": [
- "This meter may be used to limit the rate of PACKET_IN frames",
- "sent to the controller"
- ],
- "instruction": "METER",
- "meter_name": "ControllerMeter"
- },
- {
- "instruction": "APPLY_ACTIONS",
- "actions": [
- {
- "action": "OUTPUT",
- "port": "CONTROLLER"
- }
- ]
- }
- ]
- }
- ],
- "built_in_flow_mods": [
- {
- "doc": [
- "Mandatory filtering of control frames with C-VLAN Bridge reserved DA."
- ],
- "name": "Control-Frame-Filter",
- "priority": "1",
- "match_set": [
- {
- "field": "ETH_DST",
- "mask": "0xfffffffffff0",
- "value": "0x0180C2000000"
- }
- ]
- },
- {
- "doc": [
- "Mandatory miss flow_mod, sends packets to IngressVLAN table."
- ],
- "name": "Non-Control-Frame",
- "priority": "0",
- "instruction_set": [
- {
- "instruction": "GOTO_TABLE",
- "table": "IngressVLAN"
- }
- ]
- }
- ]
- }
- ],
- "group_entry_types": [
- {
- "doc": [
- "Output to a port, removing VLAN tag if needed.",
- "Entry per port, plus entry per untagged VID per port."
- ],
- "name": "EgressPort",
- "group_type": "INDIRECT",
- "bucket_types": [
- {
- "name": "OutputTagged",
- "action_set": [
- {
- "action": "OUTPUT",
- "port": "<port_no>"
- }
- ]
- },
- {
- "name": "OutputUntagged",
- "action_set": [
- {
- "action": "POP_VLAN"
- },
- {
- "action": "OUTPUT",
- "port": "<port_no>"
- }
- ]
- },
- {
- "opt_tag": "VID-X",
- "name": "OutputVIDTranslate",
- "action_set": [
- {
- "action": "SET_FIELD",
- "field": "VLAN_VID",
- "value": "<local_vid>"
- },
- {
- "action": "OUTPUT",
- "port": "<port_no>"
- }
- ]
- }
- ]
- }
- ],
- "flow_paths": [
- {
- "doc": [
- "This object contains just a few examples of flow paths, it is not",
- "a comprehensive list of the flow paths required for this TTP. It is",
- "intended that the flow paths array could include either a list of",
- "required flow paths or a list of specific flow paths that are not",
- "required (whichever is more concise or more useful."
- ],
- "name": "L2-2",
- "path": [
- "Non-Control-Frame",
- "IV-pass",
- "Known-MAC",
- "ACLskip",
- "L2-Unicast",
- "EgressPort"
- ]
- },
- {
- "name": "L2-3",
- "path": [
- "Non-Control-Frame",
- "IV-pass",
- "Known-MAC",
- "ACLskip",
- "L2-Multicast",
- "L2Mcast",
- "[EgressPort]"
- ]
- },
- {
- "name": "L2-4",
- "path": [
- "Non-Control-Frame",
- "IV-pass",
- "Known-MAC",
- "ACL-skip",
- "VID-flood",
- "VIDflood",
- "[EgressPort]"
- ]
- },
- {
- "name": "L2-5",
- "path": [
- "Non-Control-Frame",
- "IV-pass",
- "Known-MAC",
- "ACLskip",
- "L2-Drop"
- ]
- },
- {
- "name": "v4-1",
- "path": [
- "Non-Control-Frame",
- "IV-pass",
- "Known-MAC",
- "ACLskip",
- "L2-Router-MAC",
- "IPv4",
- "v4-Unicast",
- "NextHop",
- "EgressPort"
- ]
- },
- {
- "name": "v4-2",
- "path": [
- "Non-Control-Frame",
- "IV-pass",
- "Known-MAC",
- "ACLskip",
- "L2-Router-MAC",
- "IPv4",
- "v4-Unicast-ECMP",
- "L3ECMP",
- "NextHop",
- "EgressPort"
- ]
- }
- ]
- }
- ]
- }
- }
-
-Making a REST Call
-~~~~~~~~~~~~~~~~~~
-
-In this example we’ll do a PUT to install the sample TTP from above into
-OpenDaylight and then retrieve it both as json and as xml. We’ll use the
-`Postman - REST
-Client <https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm>`__
-for Chrome in the examples, but any method of accessing REST should
-work.
-
-First, we’ll fill in the basic information:
-
-.. figure:: ./images/ttp-screen1-basic-auth.png
- :alt: Filling in URL, content, Content-Type and basic auth
-
- Filling in URL, content, Content-Type and basic auth
-
-1. Set the URL to
- ``http://localhost:8181/restconf/config/onf-ttp:opendaylight-ttps/onf-ttp:table-type-patterns/``
-
-2. Set the action to ``PUT``
-
-3. Click Headers and
-
-4. Set a header for ``Content-Type`` to ``application/json``
-
-5. Make sure the content is set to raw and
-
-6. Copy the sample TTP from above into the content
-
-7. Click the Basic Auth tab and
-
-8. Set the username and password to admin
-
-9. Click Refresh headers
-
-.. figure:: ./images/ttp-screen2-applied-basic-auth.png
- :alt: Refreshing basic auth headers
-
- Refreshing basic auth headers
-
-After clicking Refresh headers, we can see that a new header
-(``Authorization``) has been created and this will allow us to
-authenticate to make the REST call.
-
-.. figure:: ./images/ttp-screen3-sent-put.png
- :alt: PUTting a TTP
-
- PUTting a TTP
-
-At this point, clicking send should result in a Status response of ``200
-OK`` indicating we’ve successfully PUT the TTP into OpenDaylight.
-
-.. figure:: ./images/ttp-screen4-get-json.png
- :alt: Retrieving the TTP as json via a GET
-
- Retrieving the TTP as json via a GET
-
-We can now retrieve the TTP by:
-
-1. Changing the action to ``GET``
-
-2. Setting an ``Accept`` header to ``application/json`` and
-
-3. Pressing send
-
-.. figure:: ./images/ttp-screen5-get-xml.png
- :alt: Retrieving the TTP as xml via a GET
-
- Retrieving the TTP as xml via a GET
-
-The same process can retrieve the content as xml by setting the
-``Accept`` header to ``application/xml``.
-
+++ /dev/null
-.. _unimgr-dev-guide:
-
-User Network Interface Manager Plug-in (Unimgr) Developer Guide
-===============================================================
-
-Overview
---------
-
-The User Network Interface (UNI) Manager project within OpenDaylight provides
-data models and APIs that enable software applications and service
-orchestrators to configure and provision connectivity services; in particular,
-Carrier Ethernet services as defined by MEF Forum, in physical and virtual
-network elements.
-
-Unimgr Architecture
--------------------
-
-Unimgr provides support for both service orchestration, via the Legato API, and
-network resource provisioning, via the Presto API. These APIs, and the
-interfaces they provide, are defined by YANG models developed within MEF in
-collaboration with ONF and IETF. An application/user can interact with Unimgr
-at either layer. Presto and Legato APIs are for LSO Architecture reference points
-defined in `MEF 55 specification <https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_55.pdf>`_.
-
-Presto layer
-````````````
-.. figure:: ./images/unimgr/architecture.png
- :scale: 65
- :alt: Presto layer Architecture
-
-In current version of Unimgr the recent version of Presto NRP is supported.
-This model is based on Transport API (TAPI) from ONF. This API allows for
-management of connectivity services and exposes abstract topology of the
-managed infrastracture. By its nature Presto NRP write and update operations
-are defined as set of RPC calls. All the reads operation can be either specific
-RPCs or via RESTCONF data tree.
-
-Presto layer architecture is depicted in figure above. There are two
-distinctive parts of Presto NRP business logic Activation Service and
-Activation Driver. Activation Service part of the framework is to encapsulate
-the common logic whereas Activation Driver is a way to encapsulate business
-logic to transform Presto Request into a given underlying technology. This way
-we are able to handle multi-vendor infrastructures and address various use
-cases as vendors specific code is encapsulated in drivers.
-
-Activation Service
-..................
-
-Activation service is responsible for handling the connectivity request. In
-case of service activation following steps are performed:
-
-1. Validation of a request (e.g. if all endpoints exists)
-
-2. Decomposition of a request into number of drivers sub-requests
-
-3. Activation of the request for selected drivers
-
-4. Update of the data model and creating ``ConnectivityService`` and ``Connection`` objects for the request
-
-Step 1. Implements only minimal functionality.
-
-Step 2. Allows for multi-vendor configuration as decomposition mechanisms
-defines all drivers required to satisfy given connectivity request. Currently
-only p2p connectivity services are supported in the decomposition mechanism.
-
-Both validation and decomposition mechanisms are plug-able thus users can
-support more sophisticated scenarios.
-
-
-Activation Driver
-.................
-
-.. figure:: ./images/unimgr/drivers.png
- :scale: 90
- :alt: Presto NRP topology and drivers
-
-Activation Driver has two main responsibilities:
-
-* to handle connectvitiy service requests
-
-* to contribute to Presto Topology with abstract nodes driver can handle
-
-In figure above example topology and drivers are shown. As you can see it is up
-to driver how to model infrastructure it manages. Thus, driver A has decided to
-model all devices as single virtual node, whereas driver C is exposing every
-single device as a node.
-
-The connectivity service is defined between ``ServiceInterfacePoint`` (SIP)
-which are mapped to ``NodeEdgePoint`` (NEP). A SIP can have UNI, ENNI or INNI
-role. Assigning a SIP to NEP can be done automatically by driver of with the
-use of Unimgr extension API. It is assumed that driver can connect eny number
-of SIPs related to NEPs for every ``Node`` it exposes.
-
-There is a contract for a given Karaf bundle to be recognized as a driver. The
-following must be fulfiled:
-
-* A driver have to expose an OSGI service that implements
- ``org.opendaylight.unimgr.mef.nrp.api.ActivationDriverBuilder``
-
-* Implement a component that is responsible for writing to topology (in general
- the requirement is to add at least a single node to topology with id
- ``org.opendaylight.unimgr.mef.nrp.api.TapiConstants#PRESTO_SYSTEM_TOPO``
-
-There are three drivers maintained as part of Unimgr project:
-
-:template-driver: Which is intended as a template for real drivers development.
- It is not connected to infrastructure.
-:ovs-driver: Which is a driver for OpenFlow infrasturcture.
-:cisco-xr-driver: A netconf driver for Cisco XR devices for MPLS inter-connectivity
-
-Key APIs and Interfaces
------------------------
-
-Legato YANG models:
-https://git.opendaylight.org/gerrit/gitweb?p=unimgr.git;a=tree;f=legato-api/src/main/yang;hb=refs/heads/stable/nitrogen
-
-Presto YANG models:
-https://git.opendaylight.org/gerrit/gitweb?p=unimgr.git;a=tree;f=presto-api/src/main/yang;hb=refs/heads/stable/nitrogen
-
-Legato API Tree
----------------
-
-module: mef-services
-
-::
-
- +--rw mef-services
- +--rw mef-service* [svc-id]
- +--rw evc
- | +--rw unis
- | | +--rw uni* [uni-id]
- | | +--rw evc-uni-ce-vlans
- | | | +--rw evc-uni-ce-vlan* [vid]
- | | | +--rw vid -> /mef-interfaces:mef-interfaces/unis/uni[mef-interfaces:uni-id = current()/../../../uni-id]/ce-vlans/ce-vlan/vid
- | | +--rw ingress-bwp-flows-per-cos!
- | | | +--rw coupling-enabled? boolean
- | | | +--rw bwp-flow-per-cos* [cos-name]
- | | | +--rw cos-name -> /mef-global:mef-global/profiles/cos-names/cos-name/name
- | | | +--rw bw-profile -> /mef-interfaces:mef-interfaces/unis/uni[mef-interfaces:uni-id = current()/../../../uni-id]/ingress-envelopes/envelope/env-id
- | | +--rw egress-bwp-flows-per-eec!
- | | | +--rw coupling-enabled? boolean
- | | | +--rw bwp-flow-per-eec* [eec-name]
- | | | +--rw eec-name -> /mef-global:mef-global/profiles/eec-names/eec-name/name
- | | | +--rw bw-profile -> /mef-interfaces:mef-interfaces/unis/uni[mef-interfaces:uni-id = current()/../../../uni-id]/egress-envelopes/envelope/env-id
- | | +--rw status
- | | | +--ro oper-state-enabled? boolean
- | | | +--ro available-status? mef-types:svc-endpoint-availability-type
- | | +--rw uni-id -> /mef-interfaces:mef-interfaces/unis/uni/uni-id
- | | +--rw role mef-types:evc-uni-role-type
- | | +--rw admin-state-enabled? boolean
- | | +--rw color-id? mef-types:cos-color-identifier-type
- | | +--rw data-svc-frm-cos? -> /mef-global:mef-global/profiles/cos/cos-profile/id
- | | +--rw l2cp-svc-frm-cos? -> /mef-global:mef-global/profiles/l2cp-cos/l2cp-profile/id
- | | +--rw soam-svc-frm-cos? -> /mef-global:mef-global/profiles/cos/cos-profile/id
- | | +--rw data-svc-frm-eec? -> /mef-global:mef-global/profiles/eec/eec-profile/id
- | | +--rw l2cp-svc-frm-eec? -> /mef-global:mef-global/profiles/l2cp-eec/l2cp-profile/id
- | | +--rw soam-svc-frm-eec? -> /mef-global:mef-global/profiles/eec/eec-profile/id
- | | +--rw ingress-bw-profile-per-evc? -> /mef-interfaces:mef-interfaces/unis/uni[mef-interfaces:uni-id = current()/../uni-id]/ingress-envelopes/envelope/env-id
- | | +--rw egress-bw-profile-per-evc? -> /mef-interfaces:mef-interfaces/unis/uni[mef-interfaces:uni-id = current()/../uni-id]/egress-envelopes/envelope/env-id
- | | +--rw src-mac-addr-limit-enabled? boolean
- | | +--rw src-mac-addr-limit? uint32
- | | +--rw src-mac-addr-limit-interval? yang:timeticks
- | | +--rw test-meg-enabled? boolean
- | | +--rw test-meg? mef-types:identifier45
- | | +--rw subscriber-meg-mip-enabled? boolean
- | | +--rw subscriber-meg-mip? mef-types:identifier45
- | +--rw status
- | | +--ro oper-state-enabled? boolean
- | | +--ro available-status? mef-types:virt-cx-availability-type
- | +--rw sls-inclusions-by-cos
- | | +--rw sls-inclusion-by-cos* [cos-name]
- | | +--rw cos-name -> /mef-global:mef-global/profiles/cos-names/cos-name/name
- | +--rw sls-uni-inclusions!
- | | +--rw sls-uni-inclusion-set* [pm-type pm-id uni-id1 uni-id2]
- | | +--rw pm-type -> /mef-global:mef-global/slss/sls[mef-global:sls-id = current()/../../../evc-performance-sls]/perf-objs/perf-obj/pm-type
- | | +--rw pm-id -> /mef-global:mef-global/slss/sls[mef-global:sls-id = current()/../../../evc-performance-sls]/perf-objs/perf-obj[mef-global:pm-type = current()/../pm-type]/pm-id
- | | +--rw uni-id1 -> ../../../unis/uni/uni-id
- | | +--rw uni-id2 -> ../../../unis/uni/uni-id
- | +--rw sls-uni-exclusions!
- | | +--rw sls-uni-exclusion-set* [pm-type pm-id uni-id1 uni-id2]
- | | +--rw pm-type -> /mef-global:mef-global/slss/sls[mef-global:sls-id = current()/../../../evc-performance-sls]/perf-objs/perf-obj/pm-type
- | | +--rw pm-id -> /mef-global:mef-global/slss/sls[mef-global:sls-id = current()/../../../evc-performance-sls]/perf-objs/perf-obj[mef-global:pm-type = current()/../pm-type]/pm-id
- | | +--rw uni-id1 -> ../../../unis/uni/uni-id
- | | +--rw uni-id2 -> ../../../unis/uni/uni-id
- | +--rw evc-id mef-types:evc-id-type
- | +--ro evc-status? mef-types:evc-status-type
- | +--rw evc-type mef-types:evc-type
- | +--rw admin-state-enabled? boolean
- | +--rw elastic-enabled? boolean
- | +--rw elastic-service? mef-types:identifier45
- | +--rw max-uni-count? uint32
- | +--rw preserve-ce-vlan-id? boolean
- | +--rw cos-preserve-ce-vlan-id? boolean
- | +--rw evc-performance-sls? -> /mef-global:mef-global/slss/sls/sls-id
- | +--rw unicast-svc-frm-delivery? mef-types:data-svc-frame-delivery-type
- | +--rw multicast-svc-frm-delivery? mef-types:data-svc-frame-delivery-type
- | +--rw broadcast-svc-frm-delivery? mef-types:data-svc-frame-delivery-type
- | +--rw evc-meg-id? mef-types:identifier45
- | +--rw max-svc-frame-size? mef-types:max-svc-frame-size-type
- +--rw svc-id mef-types:retail-svc-id-type
- +--rw sp-id? -> /mef-global:mef-global/svc-providers/svc-provider/sp-id
- +--rw svc-type? mef-types:mef-service-type
- +--rw user-label? mef-types:identifier45
- +--rw svc-entity? mef-types:service-entity-type
-
-module: mef-global
-
-::
-
- +--rw mef-global
- +--rw svc-providers!
- | +--rw svc-provider* [sp-id]
- | +--rw sp-id mef-types:svc-provider-type
- +--rw cens!
- | +--rw cen* [cen-id]
- | +--rw cen-id mef-types:cen-type
- | +--rw sp-id? -> /mef-global/svc-providers/svc-provider/sp-id
- +--rw slss!
- | +--rw sls* [sls-id]
- | +--rw perf-objs
- | | +--rw pm-time-interval uint64
- | | +--rw pm-time-interval-increment uint64
- | | +--rw unavail-flr-threshold-pp mef-types:simple-percent
- | | +--rw consecutive-small-time-intervals uint64
- | | +--rw perf-obj* [pm-type pm-id]
- | | +--rw pm-type mef-types:performance-metric-type
- | | +--rw pm-id mef-types:identifier45
- | | +--rw cos-name -> /mef-global/profiles/cos-names/cos-name/name
- | | +--rw fd-pp mef-types:simple-percent
- | | +--rw fd-range-pp mef-types:simple-percent
- | | +--rw fd-perf-obj uint64
- | | +--rw fd-range-perf-obj uint64
- | | +--rw fd-mean-perf-obj uint64
- | | +--rw ifdv-pp mef-types:simple-percent
- | | +--rw ifdv-pair-interval mef-types:simple-percent
- | | +--rw ifdv-perf-obj uint64
- | | +--rw flr-perf-obj uint64
- | | +--rw avail-pp mef-types:simple-percent
- | | +--rw hli-perf-obj uint64
- | | +--rw chli-consecutive-small-time-intervals uint64
- | | +--rw chli-perf-obj uint64
- | | +--rw min-uni-pairs-avail uint64
- | | +--rw gp-avail-pp mef-types:simple-percent
- | +--rw sls-id mef-types:cen-type
- | +--rw sp-id? -> /mef-global/svc-providers/svc-provider/sp-id
- +--rw subscribers!
- | +--rw subscriber* [sub-id]
- | +--rw sub-id mef-types:subscriber-type
- | +--rw sp-id? -> /mef-global/svc-providers/svc-provider/sp-id
- | +--rw cen-id? -> /mef-global/cens/cen/cen-id
- +--rw profiles!
- +--rw cos-names
- | +--rw cos-name* [name]
- | +--rw name mef-types:identifier45
- +--rw eec-names
- | +--rw eec-name* [name]
- | +--rw name mef-types:identifier45
- +--rw ingress-bwp-flows
- | +--rw bwp-flow* [bw-profile]
- | +--rw bw-profile mef-types:identifier45
- | +--rw user-label? mef-types:identifier45
- | +--rw cir? mef-types:bwp-cir-type
- | +--rw cir-max? mef-types:bwp-cir-type
- | +--rw cbs? mef-types:bwp-cbs-type
- | +--rw eir? mef-types:bwp-eir-type
- | +--rw eir-max? mef-types:bwp-eir-type
- | +--rw ebs? mef-types:bwp-ebs-type
- | +--rw coupling-enabled? boolean
- | +--rw color-mode? mef-types:bwp-color-mode-type
- | +--rw coupling-flag? mef-types:bwp-coupling-flag-type
- +--rw egress-bwp-flows
- | +--rw bwp-flow* [bw-profile]
- | +--rw bw-profile mef-types:identifier45
- | +--rw user-label? mef-types:identifier45
- | +--rw cir? mef-types:bwp-cir-type
- | +--rw cir-max? mef-types:bwp-cir-type
- | +--rw cbs? mef-types:bwp-cbs-type
- | +--rw eir? mef-types:bwp-eir-type
- | +--rw eir-max? mef-types:bwp-eir-type
- | +--rw ebs? mef-types:bwp-ebs-type
- | +--rw coupling-enabled? boolean
- | +--rw color-mode? mef-types:bwp-color-mode-type
- | +--rw coupling-flag? mef-types:bwp-coupling-flag-type
- +--rw l2cp-cos
- | +--rw l2cp-profile* [id]
- | +--rw l2cps
- | | +--rw l2cp* [dest-mac-addr peering-proto-name]
- | | +--rw dest-mac-addr yang:mac-address
- | | +--rw peering-proto-name mef-types:identifier45
- | | +--rw protocol? mef-types:l2cp-peering-protocol-type
- | | +--rw protocol-id? yang:hex-string
- | | +--rw cos-name? -> /mef-global/profiles/cos-names/cos-name/name
- | | +--rw handling? mef-types:l2cp-handling-type
- | | +--rw subtype* yang:hex-string
- | +--rw id mef-types:identifier45
- | +--rw user-label? mef-types:identifier45
- +--rw l2cp-eec
- | +--rw l2cp-profile* [id]
- | +--rw l2cps
- | | +--rw l2cp* [dest-mac-addr peering-proto-name]
- | | +--rw dest-mac-addr yang:mac-address
- | | +--rw peering-proto-name mef-types:identifier45
- | | +--rw protocol? mef-types:l2cp-peering-protocol-type
- | | +--rw protocol-id? yang:hex-string
- | | +--rw eec-name? -> /mef-global/profiles/eec-names/eec-name/name
- | | +--rw handling? mef-types:l2cp-handling-type
- | | +--rw subtype* yang:hex-string
- | +--rw id mef-types:identifier45
- | +--rw user-label? mef-types:identifier45
- +--rw l2cp-peering
- | +--rw l2cp-profile* [id]
- | +--rw l2cps
- | | +--rw l2cp* [dest-mac-addr peering-proto-name]
- | | +--rw dest-mac-addr yang:mac-address
- | | +--rw peering-proto-name mef-types:identifier45
- | | +--rw protocol? mef-types:l2cp-peering-protocol-type
- | | +--rw protocol-id? yang:hex-string
- | | +--rw subtype* yang:hex-string
- | +--rw id mef-types:identifier45
- | +--rw user-label? mef-types:identifier45
- +--rw elmi
- | +--rw elmi-profile* [id]
- | +--rw id mef-types:identifier45
- | +--rw user-label? mef-types:identifier45
- | +--rw polling-counter? mef-types:elmi-polling-counter-type
- | +--rw status-error-threshold? mef-types:elmi-status-error-threshold-type
- | +--rw polling-timer? mef-types:elmi-polling-timer-type
- | +--rw polling-verification-timer? mef-types:elmi-polling-verification-timer-type
- +--rw eec
- | +--rw eec-profile* [id]
- | +--rw id mef-types:identifier45
- | +--rw (eec-id)?
- | +--:(pcp)
- | | +--rw eec-pcp!
- | | +--rw default-pcp-eec-name? -> /mef-global/profiles/eec-names/eec-name/name
- | | +--rw default-pcp-color? mef-types:cos-color-type
- | | +--rw pcp* [pcp-value]
- | | +--rw pcp-value mef-types:ieee8021p-priority-type
- | | +--rw discard-value? boolean
- | | +--rw eec-name? -> /mef-global/profiles/eec-names/eec-name/name
- | | +--rw color? mef-types:cos-color-type
- | +--:(dscp)
- | +--rw eec-dscp!
- | +--rw default-ipv4-eec-name? -> /mef-global/profiles/eec-names/eec-name/name
- | +--rw default-ipv4-color? mef-types:cos-color-type
- | +--rw default-ipv6-eec-name? -> /mef-global/profiles/eec-names/eec-name/name
- | +--rw default-ipv6-color? mef-types:cos-color-type
- | +--rw ipv4-dscp* [dscp-value]
- | | +--rw dscp-value inet:dscp
- | | +--rw discard-value? boolean
- | | +--rw eec-name? -> /mef-global/profiles/eec-names/eec-name/name
- | | +--rw color? mef-types:cos-color-type
- | +--rw ipv6-dscp* [dscp-value]
- | +--rw dscp-value inet:dscp
- | +--rw discard-value? boolean
- | +--rw eec-name? -> /mef-global/profiles/eec-names/eec-name/name
- | +--rw color? mef-types:cos-color-type
- +--rw cos
- +--rw cos-profile* [id]
- +--rw id mef-types:identifier45
- +--rw (cos-id)?
- +--:(evc)
- | +--rw cos-evc!
- | +--rw default-evc-cos-name? -> /mef-global/profiles/cos-names/cos-name/name
- | +--rw default-evc-color? mef-types:cos-color-type
- +--:(pcp)
- | +--rw cos-pcp!
- | +--rw default-pcp-cos-name? -> /mef-global/profiles/cos-names/cos-name/name
- | +--rw default-pcp-color? mef-types:cos-color-type
- | +--rw pcp* [pcp-value]
- | +--rw pcp-value mef-types:ieee8021p-priority-type
- | +--rw discard-value? boolean
- | +--rw cos-name? -> /mef-global/profiles/cos-names/cos-name/name
- | +--rw color? mef-types:cos-color-type
- +--:(dscp)
- +--rw cos-dscp!
- +--rw default-ipv4-cos-name? -> /mef-global/profiles/cos-names/cos-name/name
- +--rw default-ipv4-color? mef-types:cos-color-type
- +--rw default-ipv6-cos-name? -> /mef-global/profiles/cos-names/cos-name/name
- +--rw default-ipv6-color? mef-types:cos-color-type
- +--rw ipv4-dscp* [dscp-value]
- | +--rw dscp-value inet:dscp
- | +--rw discard-value? boolean
- | +--rw cos-name? -> /mef-global/profiles/cos-names/cos-name/name
- | +--rw color? mef-types:cos-color-type
- +--rw ipv6-dscp* [dscp-value]
- +--rw dscp-value inet:dscp
- +--rw discard-value? boolean
- +--rw cos-name? -> /mef-global/profiles/cos-names/cos-name/name
- +--rw color? mef-types:cos-color-type
-
-Presto API Tree
----------------
-
-module: onf-core-network-module
-
-::
-
- +--rw forwarding-constructs
- +--rw forwarding-construct* [uuid]
- +--rw uuid string
- +--rw layerProtocolName? onf-cnt:LayerProtocolName
- +--rw lowerLevelFc* -> /forwarding-constructs/forwarding-construct/uuid
- +--rw fcRoute* [uuid]
- | +--rw uuid string
- | +--rw fc* -> /forwarding-constructs/forwarding-construct/uuid
- +--rw fcPort* [topology node tp]
- | +--rw topology nt:topology-ref
- | +--rw node nt:node-ref
- | +--rw tp nt:tp-ref
- | +--rw role? onf-cnt:PortRole
- | +--rw fcPortDirection? onf-cnt:PortDirection
- +--rw fcSpec
- | +--rw uuid? string
- | +--rw fcPortSpec* [uuid]
- | | +--rw uuid string
- | | +--rw ingressFcPortSet* [topology node tp]
- | | | +--rw topology nt:topology-ref
- | | | +--rw node nt:node-ref
- | | | +--rw tp nt:tp-ref
- | | +--rw egressFcPortSet* [topology node tp]
- | | | +--rw topology nt:topology-ref
- | | | +--rw node nt:node-ref
- | | | +--rw tp nt:tp-ref
- | | +--rw role? string
- | +--rw nrp:nrp-ce-fcspec-attrs
- | +--rw nrp:connectionType? nrp-types:NRP_ConnectionType
- | +--rw nrp:unicastFrameDelivery? nrp-types:NRP_ServiceFrameDelivery
- | +--rw nrp:multicastFrameDelivery? nrp-types:NRP_ServiceFrameDelivery
- | +--rw nrp:broadcastFrameDelivery? nrp-types:NRP_ServiceFrameDelivery
- | +--rw nrp:vcMaxServiceFrame? nrp-types:NRP_PositiveInteger
- | +--rw nrp:vcId? nrp-types:NRP_PositiveInteger
- +--rw forwardingDirection? onf-cnt:ForwardingDirection
-
-augment /nt:network-topology/nt:topology/nt:node/nt:termination-point:
-
-::
-
- +--rw ltp-attrs
- +--rw lpList* [uuid]
- | +--rw uuid string
- | +--rw layerProtocolName? onf-cnt:LayerProtocolName
- | +--rw lpSpec
- | | +--rw adapterSpec
- | | | +--rw nrp:nrp-conn-adapt-spec-attrs
- | | | | +--rw nrp:sourceMacAddressLimit
- | | | | | +--rw nrp:enabled? boolean
- | | | | | +--rw nrp:limit? NRP_NaturalNumber
- | | | | | +--rw nrp:timeInterval? NRP_NaturalNumber
- | | | | +--rw nrp:CeExternalInterface
- | | | | | +--rw nrp:physicalLayer? nrp-types:NRP_PhysicalLayer
- | | | | | +--rw nrp:syncMode* [linkId]
- | | | | | | +--rw nrp:linkId string
- | | | | | | +--rw nrp:syncModeEnabled? boolean
- | | | | | +--rw nrp:numberOfLinks? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:resiliency? nrp-types:NRP_InterfaceResiliency
- | | | | | +--rw nrp:portConvsIdToAggLinkMap
- | | | | | | +--rw nrp:conversationId? NRP_NaturalNumber
- | | | | | | +--rw nrp:linkId? NRP_NaturalNumber
- | | | | | +--rw nrp:maxFrameSize? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:linkOamEnabled? boolean
- | | | | | +--rw nrp:tokenShareEnabled? boolean
- | | | | | +--rw nrp:serviceProviderUniId? string
- | | | | +--rw nrp:coloridentifier
- | | | | | +--rw (identifier)?
- | | | | | +--:(sap-color-id)
- | | | | | | +--rw nrp:serviceAccessPointColorId
- | | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
- | | | | | +--:(pcp-color-id)
- | | | | | | +--rw nrp:pcpColorId
- | | | | | | +--rw nrp:vlanTag? nrp-types:NRP_VlanTag
- | | | | | | +--rw nrp:pcpValue* nrp-types:NRP_NaturalNumber
- | | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
- | | | | | +--:(dei-color-id)
- | | | | | | +--rw nrp:deiColorId
- | | | | | | +--rw nrp:vlanTag? nrp-types:NRP_VlanTag
- | | | | | | +--rw nrp:deiValue* nrp-types:NRP_NaturalNumber
- | | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
- | | | | | +--:(desp-color-id)
- | | | | | +--rw nrp:despColorId
- | | | | | +--rw nrp:ipVersion? nrp-types:NRP_IpVersion
- | | | | | +--rw nrp:dscpValue* nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
- | | | | +--rw nrp:ingressBwpFlow
- | | | | | +--rw nrp:bwpFlowIndex? nrp-types:NRP_PositiveInteger
- | | | | | +--rw nrp:cir? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:cirMax? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:cbs? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:eir? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:eirMax? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:ebs? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:couplingFlag? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:colorMode? nrp-types:NRP_ColorMode
- | | | | | +--rw nrp:rank? nrp-types:NRP_PositiveInteger
- | | | | | +--rw nrp:tokenRequestOffset? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:egressBwpFlow
- | | | | | +--rw nrp:bwpFlowIndex? nrp-types:NRP_PositiveInteger
- | | | | | +--rw nrp:cir? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:cirMax? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:cbs? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:eir? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:eirMax? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:ebs? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:couplingFlag? nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:colorMode? nrp-types:NRP_ColorMode
- | | | | | +--rw nrp:rank? nrp-types:NRP_PositiveInteger
- | | | | | +--rw nrp:tokenRequestOffset? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:l2cpAddressSet? nrp-types:NRP_L2cpAddressSet
- | | | | +--rw nrp:l2cpPeering* [linkId]
- | | | | +--rw nrp:destinationMacAddress? string
- | | | | +--rw nrp:protocolType? NRP_ProtocolFrameType
- | | | | +--rw nrp:linkId string
- | | | | +--rw nrp:protocolId? string
- | | | +--rw nrp:nrp-ivc-endpoint-conn-adapt-spec-attrs
- | | | | +--rw nrp:ivcEndPointId? string
- | | | | +--rw nrp:testMegEnabled? boolean
- | | | | +--rw nrp:ivcEndPointRole? nrp-types:NRP_EndPointRole
- | | | | +--rw nrp:ivcEndPointMap* [vlanId]
- | | | | | +--rw nrp:vlanId nrp-types:NRP_PositiveInteger
- | | | | | +--rw (endpoint-map-form)?
- | | | | | +--:(map-form-e)
- | | | | | | +--rw nrp:enni-svid* [vid]
- | | | | | | +--rw nrp:vid nrp-types:NRP_PositiveInteger
- | | | | | +--:(map-form-t)
- | | | | | | +--rw nrp:root-svid? nrp-types:NRP_PositiveInteger
- | | | | | | +--rw nrp:leaf-svid? nrp-types:NRP_PositiveInteger
- | | | | | +--:(map-form-v)
- | | | | | | +--rw nrp:vuni-vid? nrp-types:NRP_PositiveInteger
- | | | | | | +--rw nrp:enni-cevid* [vid]
- | | | | | | +--rw nrp:vid nrp-types:NRP_PositiveInteger
- | | | | | +--:(map-form-u)
- | | | | | +--rw nrp:cvid* [vid]
- | | | | | +--rw nrp:vid nrp-types:NRP_PositiveInteger
- | | | | +--rw nrp:subscriberMegMipEnabled? boolean
- | | | +--rw nrp:nrp-evc-endpoint-conn-adapt-spec-attrs
- | | | +--rw nrp:sourceMacAddressLimit
- | | | | +--rw nrp:enabled? boolean
- | | | | +--rw nrp:limit? NRP_NaturalNumber
- | | | | +--rw nrp:timeInterval? NRP_NaturalNumber
- | | | +--rw nrp:CeExternalInterface
- | | | | +--rw nrp:physicalLayer? nrp-types:NRP_PhysicalLayer
- | | | | +--rw nrp:syncMode* [linkId]
- | | | | | +--rw nrp:linkId string
- | | | | | +--rw nrp:syncModeEnabled? boolean
- | | | | +--rw nrp:numberOfLinks? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:resiliency? nrp-types:NRP_InterfaceResiliency
- | | | | +--rw nrp:portConvsIdToAggLinkMap
- | | | | | +--rw nrp:conversationId? NRP_NaturalNumber
- | | | | | +--rw nrp:linkId? NRP_NaturalNumber
- | | | | +--rw nrp:maxFrameSize? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:linkOamEnabled? boolean
- | | | | +--rw nrp:tokenShareEnabled? boolean
- | | | | +--rw nrp:serviceProviderUniId? string
- | | | +--rw nrp:coloridentifier
- | | | | +--rw (identifier)?
- | | | | +--:(sap-color-id)
- | | | | | +--rw nrp:serviceAccessPointColorId
- | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
- | | | | +--:(pcp-color-id)
- | | | | | +--rw nrp:pcpColorId
- | | | | | +--rw nrp:vlanTag? nrp-types:NRP_VlanTag
- | | | | | +--rw nrp:pcpValue* nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
- | | | | +--:(dei-color-id)
- | | | | | +--rw nrp:deiColorId
- | | | | | +--rw nrp:vlanTag? nrp-types:NRP_VlanTag
- | | | | | +--rw nrp:deiValue* nrp-types:NRP_NaturalNumber
- | | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
- | | | | +--:(desp-color-id)
- | | | | +--rw nrp:despColorId
- | | | | +--rw nrp:ipVersion? nrp-types:NRP_IpVersion
- | | | | +--rw nrp:dscpValue* nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:color? nrp-types:NRP_FrameColor
- | | | +--rw nrp:ingressBwpFlow
- | | | | +--rw nrp:bwpFlowIndex? nrp-types:NRP_PositiveInteger
- | | | | +--rw nrp:cir? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:cirMax? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:cbs? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:eir? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:eirMax? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:ebs? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:couplingFlag? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:colorMode? nrp-types:NRP_ColorMode
- | | | | +--rw nrp:rank? nrp-types:NRP_PositiveInteger
- | | | | +--rw nrp:tokenRequestOffset? nrp-types:NRP_NaturalNumber
- | | | +--rw nrp:egressBwpFlow
- | | | | +--rw nrp:bwpFlowIndex? nrp-types:NRP_PositiveInteger
- | | | | +--rw nrp:cir? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:cirMax? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:cbs? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:eir? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:eirMax? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:ebs? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:couplingFlag? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:colorMode? nrp-types:NRP_ColorMode
- | | | | +--rw nrp:rank? nrp-types:NRP_PositiveInteger
- | | | | +--rw nrp:tokenRequestOffset? nrp-types:NRP_NaturalNumber
- | | | +--rw nrp:l2cpAddressSet? nrp-types:NRP_L2cpAddressSet
- | | | +--rw nrp:l2cpPeering* [linkId]
- | | | | +--rw nrp:destinationMacAddress? string
- | | | | +--rw nrp:protocolType? NRP_ProtocolFrameType
- | | | | +--rw nrp:linkId string
- | | | | +--rw nrp:protocolId? string
- | | | +--rw nrp:evcEndPointId? nrp-types:NRP_PositiveInteger
- | | | +--rw nrp:testMegEnabled? boolean
- | | | +--rw nrp:evcEndPointRole? nrp-types:NRP_EvcEndPointRole
- | | | +--rw nrp:evcEndPointMap* [vid]
- | | | | +--rw nrp:vid nrp-types:NRP_PositiveInteger
- | | | +--rw nrp:subscriberMegMipEbabled? boolean
- | | +--rw terminationSpec
- | | | +--rw nrp:nrp-termination-spec-attrs
- | | | | +--rw nrp:physicalLayer? nrp-types:NRP_PhysicalLayer
- | | | | +--rw nrp:syncMode* [linkId]
- | | | | | +--rw nrp:linkId string
- | | | | | +--rw nrp:syncModeEnabled? boolean
- | | | | +--rw nrp:numberOfLinks? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:resiliency? nrp-types:NRP_InterfaceResiliency
- | | | | +--rw nrp:portConvsIdToAggLinkMap
- | | | | | +--rw nrp:conversationId? NRP_NaturalNumber
- | | | | | +--rw nrp:linkId? NRP_NaturalNumber
- | | | | +--rw nrp:maxFrameSize? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:linkOamEnabled? boolean
- | | | | +--rw nrp:tokenShareEnabled? boolean
- | | | | +--rw nrp:serviceProviderUniId? string
- | | | +--rw nrp:nrp-uni-termination-attrs
- | | | +--rw nrp:defaultCeVlanId? nrp-types:NRP_PositiveInteger
- | | | +--rw nrp:uniMegEnabled? boolean
- | | | +--rw nrp:elmiEnabled? boolean
- | | | +--rw nrp:serviceprovideruniprofile? string
- | | | +--rw nrp:operatoruniprofile? string
- | | | +--rw nrp:ingressBwpUni
- | | | | +--rw nrp:bwpFlowIndex? nrp-types:NRP_PositiveInteger
- | | | | +--rw nrp:cir? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:cirMax? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:cbs? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:eir? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:eirMax? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:ebs? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:couplingFlag? nrp-types:NRP_NaturalNumber
- | | | | +--rw nrp:colorMode? nrp-types:NRP_ColorMode
- | | | | +--rw nrp:rank? nrp-types:NRP_PositiveInteger
- | | | | +--rw nrp:tokenRequestOffset? nrp-types:NRP_NaturalNumber
- | | | +--rw nrp:egressBwpUni
- | | | +--rw nrp:bwpFlowIndex? nrp-types:NRP_PositiveInteger
- | | | +--rw nrp:cir? nrp-types:NRP_NaturalNumber
- | | | +--rw nrp:cirMax? nrp-types:NRP_NaturalNumber
- | | | +--rw nrp:cbs? nrp-types:NRP_NaturalNumber
- | | | +--rw nrp:eir? nrp-types:NRP_NaturalNumber
- | | | +--rw nrp:eirMax? nrp-types:NRP_NaturalNumber
- | | | +--rw nrp:ebs? nrp-types:NRP_NaturalNumber
- | | | +--rw nrp:couplingFlag? nrp-types:NRP_NaturalNumber
- | | | +--rw nrp:colorMode? nrp-types:NRP_ColorMode
- | | | +--rw nrp:rank? nrp-types:NRP_PositiveInteger
- | | | +--rw nrp:tokenRequestOffset? nrp-types:NRP_NaturalNumber
- | | +--rw adapterPropertySpecList* [uuid]
- | | | +--rw uuid string
- | | +--rw providerViewSpec
- | | +--rw serverSpecList* [uuid]
- | | +--rw uuid string
- | +--rw configuredClientCapacity? string
- | +--rw lpDirection? onf-cnt:TerminationDirection
- | +--rw terminationState? string
- +--rw ltpSpec
- +--rw ltpDirection? onf-cnt:TerminationDirection
- Name: view-channel
- URL:
- `http://${ipaddress}:8181/restconf/operations/usc-channel:view-channel <http://${ipaddress}:8181/restconf/operations/usc-channel:view-channel>`__
+ `http://localhost:8181/restconf/operations/usc-channel:view-channel
+ <http://localhost:8181/restconf/operations/usc-channel:view-channel>`_
- Description: Views the current state of the USC environment.
---------------------------
Go to
-`http://${ipaddress}:8181/apidoc/explorer/index.html <http://${ipaddress}:8181/apidoc/explorer/index.html>`__,
+`http://localhost:8181/apidoc/explorer/index.html <http://localhost:8181/apidoc/explorer/index.html>`_,
sign in, and expand the usc-channel panel. From there, users can execute
various API calls to test their USC deployment.
-
+++ /dev/null
-.. _vtn-dev-guide:
-
-Virtual Tenant Network (VTN)
-============================
-
-OpenDaylight Virtual Tenant Network (VTN) Overview
---------------------------------------------------
-
-OpenDaylight Virtual Tenant Network (VTN) is an application that
-provides multi-tenant virtual network on an SDN controller.
-
-Conventionally, huge investment in the network systems and operating
-expenses are needed because the network is configured as a silo for each
-department and system. Therefore various network appliances must be
-installed for each tenant and those boxes cannot be shared with others.
-It is a heavy work to design, implement and operate the entire complex
-network.
-
-The uniqueness of VTN is a logical abstraction plane. This enables the
-complete separation of logical plane from physical plane. Users can
-design and deploy any desired network without knowing the physical
-network topology or bandwidth restrictions.
-
-VTN allows the users to define the network with a look and feel of
-conventional L2/L3 network. Once the network is designed on VTN, it will
-automatically be mapped into underlying physical network, and then
-configured on the individual switch leverage SDN control protocol. The
-definition of logical plane makes it possible not only to hide the
-complexity of the underlying network but also to better manage network
-resources. It achieves reducing reconfiguration time of network services
-and minimizing network configuration errors. OpenDaylight Virtual Tenant
-Network (VTN) is an application that provides multi-tenant virtual
-network on an SDN controller. It provides API for creating a common
-virtual network irrespective of the physical network.
-
-.. figure:: ./images/vtn/vtn-overview.png
- :alt: VTN Architecture
-
- VTN Architecture
-
-It is implemented as two major components
-
-- :ref:`vtn-manager`
-
-- :ref:`vtn-coordinator`
-
-.. _vtn-manager:
-
-VTN Manager
-~~~~~~~~~~~
-
-An OpenDaylight Plugin that interacts with other modules to implement
-the components of the VTN model. It also provides a REST interface to
-configure VTN components in OpenDaylight. VTN Manager is implemented as
-one plugin to the OpenDaylight. This provides a REST interface to
-create/update/delete VTN components. The user command in VTN Coordinator
-is translated as REST API to VTN Manager by the OpenDaylight Driver
-component. In addition to the above mentioned role, it also provides an
-implementation to the OpenStack L2 Network Functions API.
-
-Function Outline
-^^^^^^^^^^^^^^^^
-
-The table identifies the functions and the interface used by VTN
-Components:
-
-+--------------------------+--------------------------+--------------------------+
-| Component | Interface | Purpose |
-+==========================+==========================+==========================+
-| VTN Manager | RESTful API | Configure VTN |
-| | | Virtualization model |
-| | | components in |
-| | | OpenDaylight |
-+--------------------------+--------------------------+--------------------------+
-| VTN Manager | Neutron API | Handle Networks API from |
-| | implementation | OpenStack (Neutron |
-| | | Interface) |
-+--------------------------+--------------------------+--------------------------+
-| VTN Coordinator | RESTful API | (1) Uses the RESTful |
-| | | interface of VTN |
-| | | Manager and configures |
-| | | VTN Virtualization |
-| | | model components in |
-| | | OpenDaylight. |
-| | | (2) Handles multiple |
-| | | OpenDaylight |
-| | | orchestration. |
-| | | (3) Provides API to |
-| | | read the physical |
-| | | network details. See |
-| | | `samples <https://wiki |
-| | | .OpenDaylight.org/view/O |
-| | | penDaylight_Virtual_Tena |
-| | | nt_Network_(VTN):VTN_Coo |
-| | | rdinator:RestApi:L2_Netw |
-| | | ork_Example_Using_VTN_Vi |
-| | | rtualization>`__ |
-| | | for usage. |
-+--------------------------+--------------------------+--------------------------+
-
-Feature Overview
-^^^^^^^^^^^^^^^^
-
-There are three features
-
-- **odl-vtn-manager** provides VTN Manager’s JAVA API.
-
-- **odl-vtn-manager-rest** provides VTN Manager’s REST API.
-
-- **odl-vtn-manager-neutron** provides the integration with Neutron
- interface.
-
-REST Conf documentation for VTN Manager, please refer to:
-https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/apidocs/index.html
-
-
-For VTN Java API documentation, please refer to:
-https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/apidocs/index.html
-
-.. _vtn-coordinator:
-
-VTN Coordinator
-~~~~~~~~~~~~~~~
-
-The VTN Coordinator is an external application that provides a REST
-interface for an user to use OpenDaylight VTN Virtualization. It
-interacts with the VTN Manager plugin to implement the user
-configuration. It is also capable of multiple OpenDaylight
-orchestration. It realizes VTN provisioning in OpenDaylight instances.
-In the OpenDaylight architecture VTN Coordinator is part of the network
-application, orchestration and services layer. VTN Coordinator will use
-the REST interface exposed by the VTN Manger to realize the virtual
-network using OpenDaylight. It uses OpenDaylight APIs (REST) to
-construct the virtual network in OpenDaylight instances. It provides
-REST APIs for northbound VTN applications and supports virtual networks
-spanning across multiple OpenDaylight by coordinating across
-OpenDaylight.
-
-VTN Coordinator Components:
-
-- Transaction Coordinator
-
-- Unified Provider Physical Layer (UPPL)
-
-- Unified Provider Logical LAyer (UPLL)
-
-- OpenDaylight Controller Diver (ODC Driver)
-
-OpenDaylight Virtual Tenant Network (VTN) API Overview
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The VTN API module is a sub component of the VTN Coordinator and
-provides the northbound REST API interface for VTN applications. It
-consists of two subcomponents:
-
-- Web Server
-
-- VTN service Java API Library
-
-.. figure:: ./images/vtn/vtn-coordinator-api-architecture.png
- :alt: VTN-Coordinator\_api-architechture
-
- VTN-Coordinator\_api-architechture
-
-Web Server
-''''''''''
-
-The Web Server module handles the REST APIs received from the VTN
-applications. It translates the REST APIs to the appropriate Java APIs.
-
-The main functions of this module are:
-
-- Starts via the startup script ``catalina.sh``.
-
-- VTN Application sends HTTP request to Web server in XML or JSON
- format.
-
-- Creates a session and acquire a read/write lock.
-
-- Invokes the VTN Service Java API Library corresponding to the
- specified URI.
-
-- Returns the response to the VTN Application.
-
-WebServer Class Details
-'''''''''''''''''''''''
-
-The list below shows the classes available for Web Server module and
-their descriptions:
-
-Init Manager
- It is a singleton class for executing the acquisition of
- configuration information from properties file, log initialization,
- initialization of VTN Service Java API Library. Executed by init()
- of VtnServiceWebAPIServlet.
-
-Configuration Manager
- Maintains the configuration information acquired from properties
- file.
-
-VtnServiceCommonUtil
- Utility class
-
-VtnServiceWebUtil
- Utility class
-
-VtnServiceWebAPIServlet
- Receives HTTP request from VTN Application and calls the method of
- corresponding VtnServiceWebAPIHandler. herits class HttpServlet, and
- overrides doGet(), doPut(), doDelete(), doPost().
-
-VtnServiceWebAPIHandler
- Creates JsonObject(com.google.gson) from HTTP request, and calls
- method of corresponding VtnServiceWebAPIController.
-
-VtnServiceWebAPIController
- Creates RestResource() class and calls UPLL API/UPPL API through
- Java API. the time of calling UPLL API/UPPL API, performs the
- creation/deletion of session, acquisition/release of configuration
- mode, acquisition/release of read lock by TC API through Java API.
-
-Data Converter
- Converts HTTP request to JsonObject and JsonXML to JSON.
-
-VTN Service Java API Library
-''''''''''''''''''''''''''''
-
-It provides the Java API library to communicate with the lower layer
-modules in the VTN Coordinator. The main functions of this library are:
-
-- Creates an IPC client session to the lower layer.
-
-- Converts the request to IPC framework format.
-
-- Invokes the lower layer API (i.e. UPPL API, UPLL API, TC API).
-
-- Returns the response from the lower layer to the web server
-
-- VTN Service Java API Library Class Details
-
-Feature Overview
-^^^^^^^^^^^^^^^^
-
-VTN Coordinator doesn’t have Karaf features.
-
-For VTN Coordinator REST API, please refer to:
-https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Coordinator:RestApi
-
-Usage Examples
-~~~~~~~~~~~~~~
-
-- `L2 Network using Single
- Controller <https://wiki.OpenDaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Coordinator:RestApi:How_to_configure_L2_Network_with_Single_Controller>`__
This section provides a quick primer for creating references
in OpenDaylight documentation. For more information, refer to
`Cross-referencing documents
-<http://www.sphinx-doc.org/en/stable/markup/inline.html#ref-role>`_.
+<https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html>`_.
Within a single document, you can reference another section simply by::
Supported Releases
==================
-Oxygen-SR3
-----------
+Fluorine-SR1
+------------
(Current Release)
+:Announcement: https://www.opendaylight.org/announcement/2018/09/13/linux-foundations-opendaylight-fluorine-release-brings-streamlined-support-for-cloud-edge-and-wan-solutions
+:Original Release Date: August 30, 2018
+:Service Release Date: November 20, 2018
+
+:Downloads:
+ * `OpenDaylight Fluorine SR1 Tar
+ <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/opendaylight/0.9.1/opendaylight-0.9.1.tar.gz>`_
+ * `OpenDaylight Fluorine SR1 Zip
+ <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/opendaylight/0.9.1/opendaylight-0.9.1.zip>`_
+ * `OpenDaylight Fluorine SR1 RPM
+ <http://cbs.centos.org/repos/nfv7-opendaylight-91-release/x86_64/os/Packages/opendaylight-9.1.0-2.el7.noarch.rpm>`_
+
+Oxygen-SR4
+----------
+
:Announcement: https://www.opendaylight.org/about/news/blogs/opendaylight-releases-oxygen-with-new-p4-and-container-support
:Original Release Date: March 22, 2018
-:Service Release Date: August 10, 2018
+:Service Release Date: Dec 12, 2018
:Downloads:
- * `OpenDaylight Oxygen SR3 Tar
- <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/karaf/0.8.3/karaf-0.8.3.tar.gz>`_
- * `OpenDaylight Oxygen SR3 Zip
- <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/karaf/0.8.3/karaf-0.8.3.zip>`_
- * `OpenDaylight Oxygen SR3 RPM
- <http://cbs.centos.org/repos/nfv7-opendaylight-83-release/x86_64/os/Packages/opendaylight-8.3.0-1.el7.noarch.rpm>`_
+ * `OpenDaylight Oxygen SR4 Tar
+ <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/karaf/0.8.4/karaf-0.8.4.tar.gz>`_
+ * `OpenDaylight Oxygen SR4 Zip
+ <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/karaf/0.8.4/karaf-0.8.4.zip>`_
+ * `OpenDaylight Oxygen SR4 RPM
+ <http://cbs.centos.org/repos/nfv7-opendaylight-84-release/x86_64/os/Packages/opendaylight-8.4.0-1.el7.noarch.rpm>`_
* `OpFlex
<https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/opflex/>`_
* `OpenDaylight (Carbon and earlier) <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/distribution-karaf/>`_
* `NeXt UI <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/next/next/>`_
* `VTN Coordinator <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/vtn/distribution.vtn-coordinator/>`_
+* `OpFlex <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/opflex/>`_
peers, follower details if the shard is a leader, and other
statistics/counters.
-The Integration team is maintaining a Python based `tool
-<https://github.com/opendaylight/integration-test/tree/master/tools/clustering/cluster-monitor>`_,
+The ODLTools team is maintaining a Python based `tool
+<https://github.com/opendaylight/odltools>`_,
that takes advantage of the above MBeans exposed via Jolokia.
.. _cluster_admin_api:
drivers to notify and communicate with one another.
* If you’re interacting with OpenDaylight through the REST APIs while
- using the the OpenDaylight interfaces, the microservices architecture allows
+ using the OpenDaylight interfaces, the microservices architecture allows
you to select available services, protocols, and REST APIs.
introduction
concepts_and_tools
installing_opendaylight
- project-specific-guides/index
clustering
persistence_and_backup
security_considerations
+++ /dev/null
-************************************
-Project-Specific Installation Guides
-************************************
-
-.. toctree::
- :maxdepth: 1
-
- opflex
- tsdr
+++ /dev/null
-.. _opflex-agent-ovs-install-guide:
-
-OpFlex agent-ovs Install Guide
-==============================
-
-Required Packages
------------------
-
-You'll need to install the following packages and their dependencies:
-
-* libuv
-* openvswitch
-* libopflex
-* libmodelgbp
-* agent-ovs
-
-Packages are available for Red Hat Enterprise Linux 7 and Ubuntu 14.04
-LTS. Some of the examples below are specific to RHEL7 but you can run
-the equivalent commands for upstart instead of systemd.
-
-Note that many of these steps may be performed automatically if you're
-deploying this along with a larger orchestration system.
-
-Host Networking Configuration
------------------------------
-
-You'll need to set up your VM host uplink interface. You should
-ensure that the MTU of the underlying network is sufficient to handle
-tunneled traffic. We will use an example of setting up *eth0* as your
-uplink interface with a vlan of 4093 used for the networking control
-infrastructure and tunnel data plane.
-
-We just need to set the MTU and disable IPv4 and IPv6
-autoconfiguration. The MTU needs to be large enough to allow both the
-VXLAN header and VLAN tags to pass through without fragmenting for
-best performance. We'll use 1600 bytes which should be sufficient
-assuming you are using a default 1500 byte MTU on your virtual machine
-traffic. If you already have any NetworkManager connections configured
-for your uplink interface find the connection name and proceed to the
-next step. Otherwise, create a connection with (be sure to update the
-variable UPLINK_IFACE as needed)::
-
- UPLINK_IFACE=eth0
- nmcli c add type ethernet ifname $UPLINK_IFACE
-
-Now, configure your interface as follows::
-
- CONNECTION_NAME="ethernet-$UPLINK_IFACE"
- nmcli connection mod "$CONNECTION_NAME" connection.autoconnect yes \
- ipv4.method link-local \
- ipv6.method ignore \
- 802-3-ethernet.mtu 9000 \
- ipv4.routes '224.0.0.0/4 0.0.0.0 2000'
-
-Then bring up the interface with::
-
- nmcli connection up "$CONNECTION_NAME"
-
-Next, create the infrastructure interface using the infrastructure
-VLAN (4093 by default). We'll need to create a vlan subinterface of
-your uplink interface, the configure DHCP on that interface. Run the
-following commands. Be sure to replace the variable values if needed. If
-you're not using NIC teaming, replace the variable team0 below::
-
- UPLINK_IFACE=team0
- INFRA_VLAN=4093
- nmcli connection add type vlan ifname $UPLINK_IFACE.$INFRA_VLAN dev $UPLINK_IFACE id $INFRA_VLAN
- nmcli connection mod vlan-$UPLINK_IFACE.$INFRA_VLAN \
- ethernet.mtu 1600 ipv4.routes '224.0.0.0/4 0.0.0.0 1000'
- sed "s/CLIENT_ID/01:$(ip link show $UPLINK_IFACE | awk '/ether/ {print $2}')/" \
- > /etc/dhcp/dhclient-$UPLINK_IFACE.$INFRA_VLAN.conf <<EOF
- send dhcp-client-identifier CLIENT_ID;
- request subnet-mask, domain-name, domain-name-servers, host-name;
- EOF
-
-Now bring up the new interface with::
-
- nmcli connection up vlan-$UPLINK_IFACE.$INFRA_VLAN
-
-If you were successful, you should be able to see an IP address when you run::
-
- ip addr show dev $UPLINK_IFACE.$INFRA_VLAN
-
-OVS Bridge Configuration
-------------------------
-
-We'll need to configure an OVS bridge which will handle the traffic
-for any virtual machines or containers that are hosted on the VM
-host. First, enable the openvswitch service and start it::
-
- # systemctl enable openvswitch
- ln -s '/usr/lib/systemd/system/openvswitch.service' '/etc/systemd/system/multi-user.target.wants/openvswitch.service'
- # systemctl start openvswitch
- # systemctl status openvswitch
- openvswitch.service - Open vSwitch
- Loaded: loaded (/usr/lib/systemd/system/openvswitch.service; enabled)
- Active: active (exited) since Fri 2014-12-12 17:20:13 PST; 3s ago
- Process: 3053 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
- Main PID: 3053 (code=exited, status=0/SUCCESS)
- Dec 12 17:20:13 ovs-server.cisco.com systemd[1]: Started Open vSwitch.
-
-Next, we can create an OVS bridge (you may wish to use a different
-bridge name)::
-
- # ovs-vsctl add-br br0
- # ovs-vsctl show
- 34aa83d7-b918-4e49-bcec-1b521acd1962
- Bridge "br0"
- Port "br0"
- Interface "br0"
- type: internal
- ovs_version: "2.3.90"
-
-Next, we configure a tunnel interface on our new bridge as follows::
-
- # ovs-vsctl add-port br0 br0_vxlan0 -- \
- set Interface br0_vxlan0 type=vxlan \
- options:remote_ip=flow options:key=flow options:dst_port=8472
- # ovs-vsctl show
- 34aa83d7-b918-4e49-bcec-1b521acd1962
- Bridge "br0"
- Port "br0_vxlan0"
- Interface "br0_vxlan0"
- type: vxlan
- options: {dst_port="8472", key=flow, remote_ip=flow}
- Port "br0"
- Interface "br0"
- type: internal
- ovs_version: "2.3.90"
-
-Open vSwitch is now configured and ready.
-
-Agent Configuration
--------------------
-
-Before enabling the agent, we'll need to edit its configuration file,
-which is located at "/etc/opflex-agent-ovs/opflex-agent-ovs.conf".
-
-First, we'll configure the Opflex protocol parameters. If you're using
-an ACI fabric, you'll need the OpFlex domain from the ACI
-configuration, which is the name of the VMM domain you mapped to the
-interface for this hypervisor. Set the "domain" field to this
-value. Next, set the "name" field to a hostname or other unique
-identifier for the VM host. Finally, set the "peers" list to contain
-the fixed static anycast peer address of 10.0.0.30 and port 8009. Here
-is an example of a completed section (bold text shows areas you'll
-need to modify)::
-
- "opflex": {
- // The globally unique policy domain for this agent.
- "domain": "[CHANGE ME]",
-
- // The unique name in the policy domain for this agent.
- "name": "[CHANGE ME]",
-
- // a list of peers to connect to, by hostname and port. One
- // peer, or an anycast pseudo-peer, is sufficient to bootstrap
- // the connection without needing an exhaustive list of all
- // peers.
- "peers": [
- {"hostname": "10.0.0.30", "port": 8009}
- ],
-
- "ssl": {
- // SSL mode. Possible values:
- // disabled: communicate without encryption
- // encrypted: encrypt but do not verify peers
- // secure: encrypt and verify peer certificates
- "mode": "encrypted",
-
- // The path to a directory containing trusted certificate
- // authority public certificates, or a file containing a
- // specific CA certificate.
- "ca-store": "/etc/ssl/certs/"
- }
- },
-
-Next, configure the appropriate policy renderer for the ACI
-fabric. You'll want to use a stitched-mode renderer. You'll need to
-configure the bridge name and the uplink interface name. The remote
-anycast IP address will need to be obtained from the ACI configuration
-console, but unless the configuration is unusual, it will be
-10.0.0.32::
-
- // Renderers enforce policy obtained via OpFlex.
- "renderers": {
- // Stitched-mode renderer for interoperating with a
- // hardware fabric such as ACI
- "stitched-mode": {
- "ovs-bridge-name": "br0",
-
- // Set encapsulation type. Must set either vxlan or vlan.
- "encap": {
- // Encapsulate traffic with VXLAN.
- "vxlan" : {
- // The name of the tunnel interface in OVS
- "encap-iface": "br0_vxlan0",
-
- // The name of the interface whose IP should be used
- // as the source IP in encapsulated traffic.
- "uplink-iface": "eth0.4093",
-
- // The vlan tag, if any, used on the uplink interface.
- // Set to zero or omit if the uplink is untagged.
- "uplink-vlan": 4093,
-
- // The IP address used for the destination IP in
- // the encapsulated traffic. This should be an
- // anycast IP address understood by the upstream
- // stitched-mode fabric.
- "remote-ip": "10.0.0.32"
- }
- },
- // Configure forwarding policy
- "forwarding": {
- // Configure the virtual distributed router
- "virtual-router": {
- // Enable virtual distributed router. Set to true
- // to enable or false to disable. Default true.
- "enabled": true,
-
- // Override MAC address for virtual router.
- // Default is "00:22:bd:f8:19:ff"
- "mac": "00:22:bd:f8:19:ff",
-
- // Configure IPv6-related settings for the virtual
- // router
- "ipv6" : {
- // Send router advertisement messages in
- // response to router solicitation requests as
- // well as unsolicited advertisements.
- "router-advertisement": true
- }
- },
-
- // Configure virtual distributed DHCP server
- "virtual-dhcp": {
- // Enable virtual distributed DHCP server. Set to
- // true to enable or false to disable. Default
- // true.
- "enabled": true,
-
- // Override MAC address for virtual dhcp server.
- // Default is "00:22:bd:f8:19:ff"
- "mac": "00:22:bd:f8:19:ff"
- }
- },
-
- // Location to store cached IDs for managing flow state
- "flowid-cache-dir": "DEFAULT_FLOWID_CACHE_DIR"
- }
- }
-
-Finally, enable the agent service::
-
- # systemctl enable agent-ovs
- ln -s '/usr/lib/systemd/system/agent-ovs.service' '/etc/systemd/system/multi-user.target.wants/agent-ovs.service'
- # systemctl start agent-ovs
- # systemctl status agent-ovs
- agent-ovs.service - Opflex OVS Agent
- Loaded: loaded (/usr/lib/systemd/system/agent-ovs.service; enabled)
- Active: active (running) since Mon 2014-12-15 10:03:42 PST; 5min ago
- Main PID: 6062 (agent_ovs)
- CGroup: /system.slice/agent-ovs.service
- └─6062 /usr/bin/agent_ovs
-
-The agent is now running and ready to enforce policy. You can add
-endpoints to the local VM hosts using the OpFlex Group-based policy
-plugin from OpenStack, or manually.
+++ /dev/null
-.. _tsdr-hbase-install-guide:
-
-TSDR HBase Data Store Installation Guide
-========================================
-
-This document is for the user to install the artifacts that are needed
-for using HBase Data Store in Time Series Data Repository, which is
-a new feature available in OpenDaylight Lithium release.
-
-Overview
---------
-
-The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a
-framework for collecting, storing, querying, and maintaining time series data
-in the OpenDaylight SDN controller. It contains the following services and
-components:
-
- Data Collection Service
- Data Storage Service
- TSDR Persistence Layer with data stores as plugins
- TSDR Data Stores
- Data Query Service
- Data Aggregation Service
- Data Purging Service
-
-Data Collection Service handles the collection of time series data into TSDR
-and hands it over to Data Storage Service. Data Storage Service stores the data
-into TSDR through TSDR Persistence Layer. TSDR Persistence Layer provides
-generic Service APIs allowing various data stores to be plugged in. Data
-Aggregation Service aggregates time series fine-grained raw data into
-course-grained roll-up data to control the size of the data. Data Purging
-Service periodically purges both fine-grained raw data and course-granined
-aggregated data according to user-defined schedules.
-
-
-In Lithium, we implemented Data Collection Service, Data Storage Service, TSDR
-Persistence Layer, TSDR HBase Data Store, and TSDR H2 Data Store. Among these
-services and components, time series data is communicated using a common TSDR
-data model, which is designed and implemented for the abstraction of the time
-series data commonalities. With these functions, TSDR will be able to collect
-the data from the data sources and store them into one of the TSDR data stores:
-either HBase Data Store or H2 Data Store. We also provided a simple query
-command from Karaf console for the user to retrieve TSDR data from the data
-stores.
-
-A future release will contain Data Aggregation service, Data Purging Service,
-and a full-fledged Data Query Service with Norghbound APIs.
-
-
-Prerequisites for Installing TSDR HBase Data Store
---------------------------------------------------
-
-The hardware requirements are the same as those for standard ODL controller
-installation.
-
-The software requirements for TSDR HBase Data Store are as follows:
-
- The supported operating system for TSDR HBase Data Store is Linux. We do not
- support TSDR HBase Data Store on Windows.
- Besides the software that ODL requires, we also require HBase database
- running on top of Hadoop single node.
-
-Preparing for Installation
---------------------------
-
-Download HBase (version number to be finalized) from the following website.
-
-http://archive.apache.org/dist/hbase/hbase-0.94.15/
-
-
-Installing TSDR HBase Data Store
---------------------------------
-
-Installing TSDR HBase Data Store contains two steps:
-
- Installing HBase server, and
- Installing TSDR HBase Data Store features from ODL Karaf console.
-
-This installation guide will only cover the first step. For installing TSDR
-HBase Data Store features, please refer to TSDR HBase Data Store User Guide.
-
-In Lithium, we only support HBase single node running together on the same
-machine as ODL controller. Therefore, follow the steps to download and install
-HBase server onto the same box as where ODL controller is running:
-
- Create a folder in Linux operating system for the HBase server.
-
-For example, create an hbase directory under /usr/lib:
-
- ::
-
- mkdir /usr/lib/hbase
-
-Unzip the downloaded HBase server tar file.
-
-Run the following command to unzip the installation package:
-
- ::
-
- tar xvf <hbase-installer-name> /usr/lib/hbase
-
-Make proper changes in hbase-site.xml
-
- .. Under <hbase-install-directory>/conf/, there is a hbase-site.xml.
- .. Although it is not recommended, an experience user with HBase canmodify
- .. the data directory for hbase server to store the data.
-
- .. Modify the value of the property with name "hbase.rootdir" in the file
- .. to reflect the desired file directory for storing hbase data.
-
-The following is an example of the file:
-
- ::
-
- <configuration>
- <property>
- <name>hbase.rootdir</name>
- <value>file:///usr/lib/hbase/data</value>
- </property>
- <property>
- <name>hbase.zookeeper.property.dataDir</name>
- <value>/usr/lib/hbase/zookeeper</value>
- </property>
- </configuration>
-
-Verifying your Installation
----------------------------
-
-After the HBase server is properly installed, start hbase server and hbase shell.
-
- ::
-
- start hbase server
- cd <hbase-installation-directory>
- ./start-hbase.sh
-
- start hbase shell
- cd <hbase-insatllation-directory>
- ./hbase shell
-
-Post Installation Configuration
--------------------------------
-
-Please refer to HBase Data Store User Guide.
-
-Upgrading From a Previous Release
----------------------------------
-
-Lithium is the first release of TSDR. Upgrading is not applicable for TSDR Lithium release.
-
-Uninstalling HBase Data Store
------------------------------
-
-To uninstall TSDR HBase Data Store,
-
-.. code-block:: bash
-
- stop hbase server
- cd <hbase-installation-directory>
- ./stop-hbase.sh
-
-To remove the file directory that contains the HBase server installation.
-
-.. code-block:: bash
-
- rm -r <hbase-installation-directory>
+++ /dev/null
-.. _tsdr-hsqldb-install-guide:
-
-TSDR HSQLDB Default Datastore Installation Guide
-================================================
-
-This document is for the user to install the artifacts that are needed
-for using Time Series Data Repository (TSDR) functionality in the ODL
-Controller by enabling the default HSQLDB Datastore. TSDR is new functionality
-added in OpenDaylight in Lithium Release.
-
-Overview
---------
-
-In Lithium Release the time series data records of OpenFlow statistics are
-collected periodically and stored in a persistent store. For non-production
-usage, the bundled default datastore (HSQLDB) is utilized based on odl-tsdr-all
-feature installation. The TSDR records get persisted in HSQLDB store in
-<install folder>/tsdr/ folder by default.
-
-Installing TSDR with default HSQLDB datastore
----------------------------------------------
-
-Once OpenDaylight distribution is up, from karaf console install the TSDR
-feature with default datastore (HSQLDB store used) can be installed by::
-
- feature:install odl-tsdr-all
-
-
-This will install all dependency features (and can take sometime) before
-returning control to the console.
-
-Verifying your Installation
----------------------------
-
-If the feature install was successful you should be able to see the following
-tsdr commands added::
-
- tsdr:list
-
-
-Troubleshooting
----------------
-
-Check the ../data/log/karaf.log for any exception related to TSDR or HSQLDB
-related features.
-
-Post Installation Configuration
--------------------------------
-
-The feature installation takes care of automated configuration of the
-datasource by installing a file in
-<install folder>/etc named org.ops4j.datasource-metric.cfg.
-This contains the default location of <install folder>/tsdr where the HSQLDB
-datastore files are stored. If you want to change the default location of the
-datastore files to some other location update the last portion of the url
-property in the org.ops4j.datasource-metric.cfg and then restart the karaf
-container
-
-Upgrading From a Previous Release
----------------------------------
-
-Lithium being the first release supporting TSDR functionality, only fresh
-installation is possible. However if you want to move to production usage by
-enabling the store HBase for TSDR usage, you can do it by uninstalling the TSDR
-with default HSQLDB datastore, restarting the Karaf container and then enabling
-the TSDR with HBase store as documented in tsdr-hbase-install.doc
-
-Uninstalling TSDR with default HSQLDB datastore
------------------------------------------------
-
-To uninstall the TSDR functionality with the default store, you need to do the
-following from karaf console
-
-.. code-block:: bash
-
- feature:uninstall odl-tsdr-all
- feature:uninstall odl-tsdr-core
- feature:uninstall odl-tsdr-HSQLDB-persistence
-
-
-It's recommended to restart the Karaf container after uninstallation of the TSDR
-functionality with the default store
+++ /dev/null
-.. _tsdr-install-guide:
-
-TSDR Installation Guide
-=======================
-
-This document is for the user to install the artifacts that are needed
-for using Time Series Data Repository (TSDR) functionality in the ODL
-Controller by enabling either an HSQLDB, HBase, or Cassandra Data Store.
-
-
-Overview
---------
-
-The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a
-framework for collecting, storing, querying, and maintaining time series data
-in the OpenDaylight SDN controller. Please refer to the User Guide for the
-detailed description of the functionality of the project and how to use the
-corresponding features provided in TSDR.
-
-Pre Requisites for Installing TSDR
-----------------------------------
-
-The software requirements for TSDR HBase Data Store are as follows:
-
-* In the case when the user chooses HBase or Cassandra data store, besides the
- software that ODL requires, we also require HBase and Cassandra database
- running in single node deployment scenario.
-
-No additional software is required for the HSQLDB Data Stores.
-
-Preparing for Installation
---------------------------
-
-* When using HBase data store, download HBase from the following website:
-
- http://archive.apache.org/dist/hbase/hbase-0.94.15/
-
-* When using Cassandra data store, download Cassandra from the following website:
-
- http://www.eu.apache.org/dist/cassandra/2.1.10/
-
-* No additional steps are required to install the TSDR HSQL Data Store.
-
-Installing TSDR Data Stores
----------------------------
-
-Installing HSQLDB Data Store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Once OpenDaylight distribution is up, from karaf console install the HSQLDB
-data store using the following command:
-
- ::
-
- feature:install odl-tsdr-hsqldb-all
-
-
-This will install hsqldb related dependency features (and can take sometime) as
-well as OpenFlow statistics collector before returning control to the console.
-
-
-Installing HBase Data Store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Installing TSDR HBase Data Store contains two steps:
-
-#. Installing HBase server, and
-#. Installing TSDR HBase Data Store features from ODL Karaf console.
-
-In this release, we only support HBase single node running together on the same
-machine as OpenDaylight. Therefore, follow the steps to download and install
-HBase server onto the same machine as where OpenDaylight is running:
-
-#. Create a folder in Linux operating system for the HBase server
-
- For example, create an hbase directory under ``/usr/lib``::
-
- mkdir /usr/lib/hbase
-
-
-#. Unzip the downloaded HBase server tar file
-
- Run the following command to unzip the installation package::
-
- tar xvf <hbase-installer-name> /usr/lib/hbase
-
-
-#. Make proper changes in hbase-site.xml
-
- #. Under <hbase-install-directory>/conf/, there is a ``hbase-site.xml``
-
- Although it is not recommended, an experienced user with HBase can modify
- the data directory for hbase server to store the data.
-
- #. Modify the value of the property with name "hbase.rootdir" in the file to
- reflect the desired file directory for storing hbase data.
-
- The following is an example of the file::
-
- <configuration>
- <property>
- <name>hbase.rootdir</name>
- <value>file:///usr/lib/hbase/data</value>
- </property>
- <property>
- <name>hbase.zookeeper.property.dataDir</name>
- <value>/usr/lib/hbase/zookeeper</value>
- </property>
- </configuration>
-
-
-#. Start hbase server
-
- .. code-block:: bash
-
- cd <hbase-installation-directory>
- ./start-hbase.sh
-
-#. Start hbase shell
-
- .. code-block:: bash
-
- cd <hbase-insatllation-directory>
- ./hbase shell
-
-#. Start Karaf console
-
-#. Install hbase data store feature from Karaf console:
-
- .. code-block:: bash
-
- feature:install odl-tsdr-hbase
-
-
-Installing Cassandra Data Store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Installing TSDR Cassandra Data Store contains two steps:
-
-#. Installing Cassandra server, and
-#. Installing TSDR Cassandra Data Store features from ODL Karaf console.
-
- In this release, we only support Cassadra single node running together on the
- same machine as OpenDaylight. Therefore, follow these steps to download and
- install Cassandra server onto the same machine as where OpenDaylight is
- running.
-
-#. Install Cassandra (latest stable version) by downloading the zip file and
- untar the tar ball to cassandra/ directory on the testing machine.
-
- .. code-block:: bash
-
- mkdir cassandra
- wget http://www.eu.apache.org/dist/cassandra/2.1.10/apache-cassandra-2.1.10-bin.tar.gz[2.1.10 is current stable version, it can vary]
- mv apache-cassandra-2.1.10-bin.tar.gz cassandra/
- cd cassandra
- tar -xvzf apache-cassandra-2.1.10-bin.tar.gz
-
-
-#. Start Cassandra from cassandra directory
-
- .. code-block:: bash
-
- ./apache-cassandra-2.1.10/bin/cassandra
-
-#. Start cassandra shell
-
- .. code-block:: bash
-
- ./apache-cassandra-2.1.10/bin/cqlsh
-
-#. Install Cassandra data store feature from Karaf console
-
- .. code-block:: bash
-
- feature:install odl-tsdr-cassandra
-
-Verifying your Installation
----------------------------
-
-After the TSDR data store is installed, no matter whether it is HBase data
-store, Cassandra data store, or HSQLDB data store, the user can verify the
-installation with the following steps.
-
-#. Verify if the following two TSDR commands are available from Karaf console:
-
- .. code-block:: bash
-
- tsdr:list
- tsdr:purgeAll
-
-
-#. Verify if OpenFlow statistics data can be received successfully:
-
- .. code-block:: bash
-
- feature:install odl-tsdr-openflow-statistics-collector
-
-#. Run mininet to connect to ODL controller. For example, use the following
- command to start a three node topology:
-
- .. code-block:: bash
-
- mn --topo single,3 --controller 'remote,ip=172.17.252.210,port=6653' --switch ovsk,protocols=OpenFlow13
-
-
-From Karaf console, the user should be able to retrieve the statistics data of
-OpenFlow statistics data from the console::
-
- tsdr:list FLOWSTATS
-
-Troubleshooting
-^^^^^^^^^^^^^^^
-
-Check the ``../data/log/karaf.log`` for any exception related to TSDR features.
-
-Post Installation Configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Post Installation Configuration for HSQLDB Data Store
-"""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-The feature installation takes care of automated configuration of the
-datasource by installing a file in <install folder>/etc named
-org.ops4j.datasource-metric.cfg. This contains the default location of
-<install folder>/tsdr where the HSQLDB datastore files are stored. If you want
-to change the default location of the datastore files to some other location
-update the last portion of the url property in the
-org.ops4j.datasource-metric.cfg and then restart the Karaf container.
-
-Post Installation Configuration for HBase Data Store
-""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-Please refer to HBase Data Store User Guide.
-
-Post Installation Configuration for Cassandra Data Store
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-There is no post configuration for TSDR Cassandra data store.
-
-Upgrading From a Previous Release
----------------------------------
-
-The HBase data store was supported in the previous release as well as in this
-release. However, we do not support data store upgrade for HBase data store.
-The user needs to reinstall TSDR and start to collect data in TSDR HBase
-datastore after the installation.
-
-HSQLDB and Cassandra are new data stores introduced in this release.
-Therefore, upgrading from previous release does not apply in these two data
-store scenarios.
-
-Uninstalling TSDR Data Stores
------------------------------
-
-To uninstall TSDR HSQLDB data store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To uninstall the TSDR functionality with the default store, you need to do the
-following from karaf console:
-
-.. code-block:: bash
-
- feature:uninstall odl-tsdr-hsqldb-all
- feature:uninstall odl-tsdr-core
- feature:uninstall odl-tsdr-hsqldb
- feature:uninstall odl-tsdr-openflow-statistics-collector
-
-It is recommended to restart the Karaf container after the uninstallation of
-the TSDR functionality with the default store.
-
-To uninstall TSDR HBase Data Store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To uninstall the TSDR functionality with the HBase data store,
-
-* Uninstall HBase data store related features from karaf console
-
- .. code-block:: bash
-
- feature:uninstall odl-tsdr-hbase
- feature:uninstall odl-tsdr-core
-
-* Stop hbase server
-
- .. code-block:: bash
-
- cd <hbase-installation-directory>
- ./stop-hbase.sh
-
-* Remove the file directory that contains the HBase server installation:
-
- .. code-block:: bash
-
- rm -r <hbase-installation-directory>
-
-
-It is recommended to restart the Karaf container after the uninstallation of
-the TSDR data store.
-
-To uninstall TSDR Cassandra Data Store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To uninstall the TSDR functionality with the Cassandra store,
-
-* uninstall cassandra data store related features following from karaf console:
-
- .. code-block:: bash
-
- feature:uninstall odl-tsdr-cassandra
- feature:uninstall odl-tsdr-core
-
-* stop cassandra database
-
- .. code-block:: bash
-
- ps auwx | grep cassandra
- sudo kill pid
-
-* remove the cassandra installation files
-
- .. code-block:: bash
-
- rm <cassandra-installation-directory>
-
-It is recommended to restart the Karaf container after uninstallation of the
-TSDR data store.
+++ /dev/null
-.. _tsdr-guide:
-
-TSDR Installation Guide
-=======================
-
-This document is for the user to install the artifacts that are needed
-for using Time Series Data Repository (TSDR) functionality in the ODL
-Controller by enabling either an HSQLDB, HBase, or Cassandra Data Store.
-
-
-Overview
---------
-
-The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a framework for collecting, storing, querying, and maintaining time series data in the OpenDaylight SDN controller. Please refer to the User Guide for the detailed description of the functionality of the project and how to use the corresponding features provided in TSDR.
-
-Pre Requisites for Installing TSDR
-----------------------------------
-
-The software requirements for TSDR HBase Data Store are as follows:
-
-* In the case when the user chooses HBase or Cassandra data store, besides the software that ODL requires, we also require HBase and Cassandra database running in single node deployment scenario.
-
-No additional software is required for the HSQLDB Data Stores.
-
-Preparing for Installation
---------------------------
-
-* When using HBase data store, download HBase from the following website:
-
- http://archive.apache.org/dist/hbase/hbase-0.94.15/
-
-* When using Cassandra data store, download Cassandra from the following website:
-
- http://www.eu.apache.org/dist/cassandra/2.1.10/
-
-* No additional steps are required to install the TSDR HSQL Data Store.
-
-Installing TSDR Data Stores
----------------------------
-
-Installing HSQLDB Data Store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Once OpenDaylight distribution is up, from karaf console install the HSQLDB data store using the following command::
-
- feature:install odl-tsdr-hsqldb-all
-
-This will install hsqldb related dependency features (and can take sometime) as well as OpenFlow statistics collector before returning control to the console.
-
-
-Installing HBase Data Store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Installing TSDR HBase Data Store contains two steps:
-
-#. Installing HBase server, and
-#. Installing TSDR HBase Data Store features from ODL Karaf console.
-
-In this release, we only support HBase single node running together on the same machine as OpenDaylight. Therefore, follow the steps to download and install HBase server onto the same machine as where OpenDaylight is running:
-
-#. Create a folder in Linux operating system for the HBase server. For example, create an hbase directory under ``/usr/lib``::
-
- mkdir /usr/lib/hbase
-
-#. Unzip the downloaded HBase server tar file.
-
- Run the following command to unzip the installation package::
-
- tar xvf <hbase-installer-name> /usr/lib/hbase
-
-#. Make proper changes in hbase-site.xml
-
- #. Under <hbase-install-directory>/conf/, there is a hbase-site.xml. Although it is not recommended, an experienced user with HBase can modify the data directory for hbase server to store the data.
-
- #. Modify the value of the property with name "hbase.rootdir" in the file to reflect the desired file directory for storing hbase data.
-
- The following is an example of the file::
-
- <configuration>
- <property>
- <name>hbase.rootdir</name>
- <value>file:///usr/lib/hbase/data</value>
- </property>
- <property>
- <name>hbase.zookeeper.property.dataDir</name>
- <value>/usr/lib/hbase/zookeeper</value>
- </property>
- </configuration>
-
-#. start hbase server::
-
- cd <hbase-installation-directory>
- ./start-hbase.sh
-
-#. start hbase shell::
-
- cd <hbase-insatllation-directory>
- ./hbase shell
-
-#. start Karaf console
-
-#. install hbase data store feature from Karaf console::
-
- feature:install odl-tsdr-hbase
-
-Installing Cassandra Data Store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Installing TSDR Cassandra Data Store contains two steps:
-
-#. Installing Cassandra server, and
-#. Installing TSDR Cassandra Data Store features from ODL Karaf console.
-
-In this release, we only support Cassadra single node running together on the same machine as OpenDaylight. Therefore, follow these steps to download and install Cassandra server onto the same machine as where OpenDaylight is running:
-
-#. Install Cassandra (latest stable version) by downloading the zip file and untar the tar ball to cassandra/ directory on the testing machine::
-
- mkdir cassandra
- wget http://www.eu.apache.org/dist/cassandra/2.1.10/apache-cassandra-2.1.10-bin.tar.gz[2.1.10 is current stable version, it can vary]
- mv apache-cassandra-2.1.10-bin.tar.gz cassandra/
- cd cassandra
- tar -xvzf apache-cassandra-2.1.10-bin.tar.gz
-
-#. Start Cassandra from cassandra directory by running::
-
- ./apache-cassandra-2.1.10/bin/cassandra
-
-#. Start cassandra shell by running::
-
- ./apache-cassandra-2.1.10/bin/cqlsh
-
-#. Start Karaf according to the instructions above.
-
-#. Install Cassandra data store feature from Karaf console::
-
- feature:install odl-tsdr-cassandra
-
-Verifying your Installation
----------------------------
-
-After the TSDR data store is installed, no matter whether it is HBase data store, Cassandra data store, or HSQLDB data store, the user can verify the installation with the following steps.
-
-#. Verify if the following two TSDR commands are available from Karaf console::
-
- tsdr:list
- tsdr:purgeAll
-
-#. Verify if OpenFlow statistics data can be received successfully:
-
- #. Run "feature:install odl-tsdr-openflow-statistics-collector" from Karaf.
-
- #. Run mininet to connect to ODL controller. For example, use the following command to start a three node topology::
-
- mn --topo single,3 --controller 'remote,ip=172.17.252.210,port=6653' --switch ovsk,protocols=OpenFlow13
-
- #. From Karaf console, the user should be able to retrieve the statistics data of OpenFlow statistics data from the console::
-
- tsdr:list FLOWSTATS
-
-Troubleshooting
-^^^^^^^^^^^^^^^
-
-Check the ``../data/log/karaf.log`` for any exception related to TSDR features.
-
-Post Installation Configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Post Installation Configuration for HSQLDB Data Store
-"""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-The feature installation takes care of automated configuration of the datasource by installing a file in <install folder>/etc named org.ops4j.datasource-metric.cfg. This contains the default location of <install folder>/tsdr where the HSQLDB datastore files are stored. If you want to change the default location of the datastore files to some other location update the last portion of the url property in the org.ops4j.datasource-metric.cfg and then restart the Karaf container.
-
-Post Installation Configuration for HBase Data Store
-""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-Please refer to HBase Data Store User Guide.
-
-Post Installation Configuration for Cassandra Data Store
-""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-
-There is no post configuration for TSDR Cassandra data store.
-
-Upgrading From a Previous Release
----------------------------------
-
-The HBase data store was supported in the previous release as well as in this release. However, we do not support data store upgrade for HBase data store.
-The user needs to reinstall TSDR and start to collect data in TSDR HBase datastore after the installation.
-
-HSQLDB and Cassandra are new data stores introduced in this release. Therefore, upgrading from previous release does not apply in these two data store scenarios.
-
-Uninstalling TSDR Data Stores
------------------------------
-
-To uninstall TSDR HSQLDB data store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To uninstall the TSDR functionality with the default store, you need to do the following from karaf console::
-
- feature:uninstall odl-tsdr-hsqldb-all
- feature:uninstall odl-tsdr-core
- feature:uninstall odl-tsdr-hsqldb
- feature:uninstall odl-tsdr-openflow-statistics-collector
-
-It is recommended to restart the Karaf container after the uninstallation of the TSDR functionality with the default store.
-
-To uninstall TSDR HBase Data Store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To uninstall the TSDR functionality with the HBase data store,
-
-* Uninstall HBase data store related features from karaf console::
-
- feature:uninstall odl-tsdr-hbase
- feature:uninstall odl-tsdr-core
-
-* stop hbase server::
-
- cd <hbase-installation-directory>
- ./stop-hbase.sh
-
-* remove the file directory that contains the HBase server installation::
-
- rm -r <hbase-installation-directory>
-
-It is recommended to restart the Karaf container after the uninstallation of the TSDR data store.
-
-To uninstall TSDR Cassandra Data Store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To uninstall the TSDR functionality with the Cassandra store,
-
-* uninstall cassandra data store related features following from karaf console::
-
- feature:uninstall odl-tsdr-cassandra
- feature:uninstall odl-tsdr-core
-
-* stop cassandra database::
-
- ps auwx | grep cassandra
- sudo kill pid
-
-* remove the cassandra installation files::
-
- rm <cassandra-installation-directory>
-
-It is recommended to restart the Karaf container after uninstallation of the TSDR data store.
-
-
-.. include:: ../../user-guide/tsdr-elastic-search.rst
-
-
-.. toctree::
- :maxdepth: 1
- :hidden:
-
- tsdr-install
- tsdr-hsqldb-install
- tsdr-hbase-install
implementing security for the Karaf container.
* For role-based JMX administration, refer to
- http://karaf.apache.org/manual/latest/users-guide/monitoring.html.
+ https://karaf.apache.org/manual/latest/#_monitoring
* For remote SSH access configuration, refer to
- http://karaf.apache.org/manual/latest/users-guide/remote.html.
+ https://karaf.apache.org/manual/latest/#_remote
* For WebConsole access, refer to
- http://karaf.apache.org/manual/latest/users-guide/webconsole.html.
+ https://karaf.apache.org/manual/latest/#_webconsole
* For Karaf security features, refer to
- http://karaf.apache.org/manual/latest/developers-guide/security-framework.html.
+ https://karaf.apache.org/manual/latest/#_security_framework
Disabling the remote shutdown port
----------------------------------
to documentation with examples of interesting OpenDaylight deployment
use cases in this section.
-* `OPNFV Installation instructions (Apex) <http://artifacts.opnfv.org/apex/docs/installation-instructions/>`_
+* `OPNFV Installation instructions (Apex)
+ <https://artifacts.opnfv.org/apex/docs/installation-instructions/index.html>`_
* `Apex Wiki <https://wiki.opnfv.org/display/apex/Apex>`_
Managed Projects
~~~~~~~~~~~~~~~~
-.. :doc:`AAA Documentation <aaa:index>`
-.. :doc:`Controller Documentation <controller:index>`
-.. :doc:`NETCONF Documentation <netconf:index>`
-.. :doc:`Neutron Documentation <neutron:index>`
-
-* :doc:`../project-indexes/bgpcep-index`
+* :doc:`AAA Documentation <aaa:index>`
+* :doc:`BGPCEP Documentation <bgpcep:index>`
* :doc:`COE Documentation <coe:index>`
-* :doc:`../project-indexes/daexim-index`
+* :doc:`Controller Documentation <controller:index>`
+* :doc:`DAEXIM Documentation <daexim:index>`
* :doc:`Genius Documentation <genius:index>`
* :doc:`Infrautils Documentation <infrautils:index>`
-* :doc:`../project-indexes/lispflowmapping-index`
+* :doc:`LISP Flow Mapping Documentation <lispflowmapping:index>`
* :doc:`MD-SAL Documentation <mdsal:index>`
+* :doc:`NetConf Documentation <netconf:index>`
* :doc:`NetVirt Documentation <netvirt:index>`
* :doc:`OpenFlowPlugin Documentation <openflowplugin:index>`
* :doc:`OVSDB Documentation <ovsdb:index>`
+.. :doc:`Neutron Documentation <neutron:index>`
+
Self-Managed Projects
~~~~~~~~~~~~~~~~~~~~~
-* :doc:`../project-indexes/sxp-index`
+* :doc:`OpFlex Documentation <opflex:index>`
+* :doc:`SXP Documentation <sxp:index>`
+* :doc:`UniMgr Documentation <unimgr:index>`
OpenDaylight Contributor Guides
* :doc:`Gerrit Guide <lfdocs:gerrit>`
* :ref:`Infrastructure Guide <odl-infra>`
* :doc:`Integration Testing Guide <odl-integration-test:index>`
-* :doc:`Integration Distribution Guide <odl-integration-distribution:index>`
+* :doc:`Integration Distribution Guide <integration-distribution:index>`
* :doc:`Integration Packaging Guide <odl-integration-packaging:index>`
+* :doc:`Release Process Guide <release-process/index>`
+* :doc:`Documentation Guide <documentation>`
+* :doc:`Javadocs <javadoc>`
-.. toctree::
- :maxdepth: 1
-
- documentation
- release-process/index
- javadoc
- developer-guide/index
.. Commenting the below out until we actually use it
.. Indices and tables
:maxdepth: 1
:hidden:
- developer-guide/index
-
- opendaylight-with-openstack/index
+ documentation
+ release-process/index
+ javadoc
release-notes/sample-release-notes
user-guide/index
- project-indexes/bgpcep-index
- project-indexes/daexim-index
- project-indexes/lispflowmapping-index
- project-indexes/sxp-index
+ developer-guide/index
* `openflowplugin <https://javadocs.opendaylight.org/openflowplugin/fluorine>`_
* `ovsdb <https://javadocs.opendaylight.org/ovsdb/fluorine>`_
* `p4plugin <https://javadocs.opendaylight.org/p4plugin/fluorine>`_
-* `sfc <https://javadocs.opendaylight.org/sfc/fluorine>`_
+++ /dev/null
-#################################
-OpenDaylight with Openstack Guide
-#################################
-
-********
-Overview
-********
-
-OpenStack_ is a popular open source Infrastructure
-as a service project, covering compute, storage and network management.
-OpenStack can use OpenDaylight as its network management provider through the
-Modular Layer 2 (ML2) north-bound plug-in. OpenDaylight manages the network
-flows for the OpenStack compute nodes via the OVSDB south-bound plug-in. This
-page describes how to set that up, and how to tell when everything is working.
-
-********************
-Installing OpenStack
-********************
-
-Installing OpenStack is out of scope for this document, but to get started, it
-is useful to have a minimal multi-node OpenStack deployment.
-
-The reference deployment we will use for this document is a 3 node cluster:
-
-* One control node containing all of the management services for OpenStack_
- (Nova, Neutron, Glance, Swift, Cinder, Keystone)
-* Two compute nodes running nova-compute
-* Neutron using the OVS back-end and vxlan for tunnels
-
-Once you have installed OpenStack_, verify that it is working by connecting
-to Horizon and performing a few operations. To check the Neutron
-configuration, create two instances on a private subnet bridging to your
-public network, and verify that you can connect to them, and that they can
-see each other.
-
-***********************
-Installing OpenDaylight
-***********************
-
-* :doc:`NetVirt Documentation <netvirt:index>`
-
-.. toctree::
- :maxdepth: 1
-
- openstack-with-gbp
- openstack-with-gbp-vpp
- openstack-with-vtn
-
-.. _OpenStack: https://www.openstack.org/
+++ /dev/null
-Using Groupbasedpolicy's Neutron VPP Mapper
-===========================================
-
-Overview
---------
-Neutron VPP Mapper implements features for support policy-based routing for OpenStack Neutron interface involving VPP devices.
-It allows using of policy-based schemes defined in GBP controller in a network consisting of OpenStack-provided nodes routed by a VPP node.
-
-Architecture
-------------
-Neutron VPP Mapper listens to Neutron data store change events, as well as being able to access directly the store.
-If the data changed match certain criteria (see `Processing Neutron Configuration`_),
-Neutron VPP Mapper converts Neutron data specifically required to render a VPP node configuration with a given End Point,
-e.g., the virtual host interface name assigned to a ``vhostuser`` socket.
-Then the mapped data is stored in the VPP info data store.
-
-Administering Neutron VPP Mapper
---------------------------------
-To use the Neutron VPP Mapper in Karaf, at least the following Karaf features must be installed:
-
-* odl-groupbasedpolicy-neutron-vpp-mapper
-* odl-vbd-ui
-
-Initial pre-requisites
-----------------------
-A topology should exist in config datastore, it is necessary to define a node with a particular ``node-id``.
-Later, ``node-id`` will be used as a physical location reference in VPP renderer's bridge domain::
-
- GET http://localhost:8181/restconf/config/network-topology:network-topology/
-
- {
- "network-topology":{
- "topology":[
- {
- "topology-id":"datacentre",
- "node":[
- {
- "node-id":"dut2",
- "vlan-tunnel:super-interface":"GigabitEthernet0/9/0",
- "termination-point":[
- {
- "tp-id":"GigabitEthernet0/9/0",
- "neutron-provider-topology:physical-interface":{
- "interface-name":"GigabitEthernet0/9/0"
- }
- }
- ]
- }
- ]
- }
- ]
- }
- }
-
-
-Processing Neutron Configuration
---------------------------------
-``NeutronListener`` listens to the changes in Neutron datatree in config datastore. It filters the changes, processing only ``network`` and ``port`` entities.
-
-For a ``network`` entity it is checked that it has ``physical-network`` parameter set (i.e., it is backed-up by a physical network),
-and that ``network-type`` is ``vlan-network`` or ``"flat"``, and if this check has passed, a related bridge domain is created
-in VPP Renderer config datastore
-(``http://{{controller}}:{{port}}/restconf/config/vpp-renderer:config``), referenced to network by ``vlan`` field.
-
-In case of ``"vlan-network"``, the ``vlan`` field contains the same value as ``neutron-provider-ext:segmentation-id`` of network created by Neutron.
-
-In case of ``"flat"``, the VLAN specific parameters are not filled out.
-
-.. note:: In case of VXLAN network (i.e. ``network-type`` is ``"vxlan-network"``), no information is actually written
- into VPP Renderer datastore, as VXLAN is used for tenant-network (so no packets are going outside). Instead, VPP Renderer looks up GBP flood domains corresponding to existing VPP bridge domains trying to establish a VXLAN tunnel between them.
-
-For a ``port`` entity it is checked that ``vif-type`` contains ``"vhostuser"`` substring, and that ``device-owner`` contains a specific substring, namely ``"compute"``, ``"router"`` or ``"dhcp"``.
-
-In case of ``"compute"`` substring, a ``vhost-user`` is written to VPP Renderer config datastore.
-
-In case of ``"dhcp"`` or ``"router"``, a ``tap`` is written to VPP Renderer config datastore.
-
-Input/output examples
----------------------
-
-OpenStack is creating network, and these data are being put into the data store::
-
- PUT http://{{controller}}:{{port}}/restconf/config/neutron:neutron/networks
-
- {
- "networks": {
- "network": [
- {
- "uuid": "43282482-a677-4102-87d6-90708f30a115",
- "tenant-id": "94836b88-0e56-4150-aaa7-60f1c2b67faa",
- "neutron-provider-ext:segmentation-id": "2016",
- "neutron-provider-ext:network-type": "neutron-networks:network-type-vlan",
- "neutron-provider-ext:physical-network": "datacentre",
- "neutron-L3-ext:external": true,
- "name": "drexternal",
- "shared": false,
- "admin-state-up": true,
- "status": "ACTIVE"
- }
- ]
- }
- }
-
-Checking bridge domain in VPP Renderer config data store.
-Note that ``physical-location-ref`` is referring to ``"dut2"``, paired by ``neutron-provider-ext:physical-network`` -> ``topology-id``::
-
- GET http://{{controller}}:{{port}}/restconf/config/vpp-renderer:config
-
- {
- "config": {
- "bridge-domain": [
- {
- "id": "43282482-a677-4102-87d6-90708f30a115",
- "type": "vpp-renderer:vlan-network",
- "description": "drexternal",
- "vlan": 2016,
- "physical-location-ref": [
- {
- "node-id": "dut2",
- "interface": [
- "GigabitEthernet0/9/0"
- ]
- }
- ]
- }
- ]
- }
- }
-
-Port (compute)::
-
- PUT http://{{controller}}:{{port}}/restconf/config/neutron:neutron/ports
-
- {
- "ports": {
- "port": [
- {
- "uuid": "3d5dff96-25f5-4d4b-aa11-dc03f7f8d8e0",
- "tenant-id": "94836b88-0e56-4150-aaa7-60f1c2b67faa",
- "device-id": "dhcp58155ae3-f2e7-51ca-9978-71c513ab02ee-a91437c0-8492-47e2-b9d0-25c44aef6cda",
- "neutron-binding:vif-details": [
- {
- "details-key": "somekey"
- }
- ],
- "neutron-binding:host-id": "devstack-control",
- "neutron-binding:vif-type": "vhostuser",
- "neutron-binding:vnic-type": "normal",
- "mac-address": "fa:16:3e:4a:9f:c0",
- "name": "",
- "network-id": "a91437c0-8492-47e2-b9d0-25c44aef6cda",
- "neutron-portsecurity:port-security-enabled": false,
- "device-owner": "network:compute",
- "fixed-ips": [
- {
- "subnet-id": "0a5834ed-ed31-4425-832d-e273cac26325",
- "ip-address": "10.1.1.3"
- }
- ],
- "admin-state-up": true
- }
- ]
- }
- }
-
- GET http://{{controller}}:{{port}}/restconf/config/vpp-renderer:config
-
- {
- "config": {
- "vpp-endpoint": [
- {
- "context-type": "l2-l3-forwarding:l2-bridge-domain",
- "context-id": "a91437c0-8492-47e2-b9d0-25c44aef6cda",
- "address-type": "l2-l3-forwarding:mac-address-type",
- "address": "fa:16:3e:4a:9f:c0",
- "vpp-node-path": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='topology-netconf']/network-topology:node[network-topology:node-id='devstack-control']",
- "vpp-interface-name": "neutron_port_3d5dff96-25f5-4d4b-aa11-dc03f7f8d8e0",
- "socket": "/tmp/socket_3d5dff96-25f5-4d4b-aa11-dc03f7f8d8e0",
- "description": "neutron port"
- }
- ]
- }
- }
-
-Port (dhcp)::
-
- PUT http://{{controller}}:{{port}}/restconf/config/neutron:neutron/ports
-
- {
- "ports": {
- "port": [
- {
- "uuid": "3d5dff96-25f5-4d4b-aa11-dc03f7f8d8e0",
- "tenant-id": "94836b88-0e56-4150-aaa7-60f1c2b67faa",
- "device-id": "dhcp58155ae3-f2e7-51ca-9978-71c513ab02ee-a91437c0-8492-47e2-b9d0-25c44aef6cda",
- "neutron-binding:vif-details": [
- {
- "details-key": "somekey"
- }
- ],
- "neutron-binding:host-id": "devstack-control",
- "neutron-binding:vif-type": "vhostuser",
- "neutron-binding:vnic-type": "normal",
- "mac-address": "fa:16:3e:4a:9f:c0",
- "name": "",
- "network-id": "a91437c0-8492-47e2-b9d0-25c44aef6cda",
- "neutron-portsecurity:port-security-enabled": false,
- "device-owner": "network:dhcp",
- "fixed-ips": [
- {
- "subnet-id": "0a5834ed-ed31-4425-832d-e273cac26325",
- "ip-address": "10.1.1.3"
- }
- ],
- "admin-state-up": true
- }
- ]
- }
- }
-
- GET http://{{controller}}:{{port}}/restconf/config/vpp-renderer:config
-
- {
- "config": {
- "vpp-endpoint": [
- {
- "context-type": "l2-l3-forwarding:l2-bridge-domain",
- "context-id": "a91437c0-8492-47e2-b9d0-25c44aef6cda",
- "address-type": "l2-l3-forwarding:mac-address-type",
- "address": "fa:16:3e:4a:9f:c0",
- "vpp-node-path": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='topology-netconf']/network-topology:node[network-topology:node-id='devstack-control']",
- "vpp-interface-name": "neutron_port_3d5dff96-25f5-4d4b-aa11-dc03f7f8d8e0",
- "physical-address": "fa:16:3e:4a:9f:c0",
- "name": "tap3d5dff96-25",
- "description": "neutron port"
- }
- ]
- }
- }
+++ /dev/null
-OpenStack with GroupBasedPolicy
-===============================
-
-This section is for Application Developers and Network Administrators
-who are looking to integrate Group Based Policy with OpenStack.
-
-To enable the **GBP** Neutron Mapper feature, at the karaf console:
-
-.. code-block:: bash
-
- feature:install odl-groupbasedpolicy-neutronmapper
-
-Neutron Mapper has the following dependencies that are automatically loaded:
-
-.. code-block:: bash
-
- odl-neutron-service
-
-Neutron Northbound implementing REST API used by OpenStack
-
-.. code-block:: bash
-
- odl-groupbasedpolicy-base
-
-Base **GBP** feature set, such as policy resolution, data model etc.
-
-.. code-block:: bash
-
- odl-groupbasedpolicy-ofoverlay
-
-For this release, **GBP** has one renderer, hence this is loaded by default.
-
-REST calls from OpenStack Neutron are by the Neutron NorthBound project.
-
-**GBP** provides the implementation of the `Neutron V2.0 API <neutron_v2api_>`_.
-
-Features
---------
-
-List of supported Neutron entities:
-
-* Port
-* Network
-
- * Standard Internal
- * External provider L2/L3 network
-
-* Subnet
-* Security-groups
-* Routers
-
- * Distributed functionality with local routing per compute
- * External gateway access per compute node (dedicated port required)
- * Multiple routers per tenant
-
-* FloatingIP NAT
-* IPv4/IPv6 support
-
-The mapping of Neutron entities to **GBP** entities is as follows:
-
-**Neutron Port**
-
-.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-port.png
-
- Neutron Port
-
-The Neutron port is mapped to an endpoint.
-
-The current implementation supports one IP address per Neutron port.
-
-An endpoint and L3-endpoint belong to multiple EndpointGroups if the Neutron
-port is in multiple Neutron Security Groups.
-
-The key for endpoint is L2-bridge-domain obtained as the parent of
-L2-flood-domain representing Neutron network. The MAC address is from the
-Neutron port.
-An L3-endpoint is created based on L3-context (the parent of the
-L2-bridge-domain) and IP address of Neutron Port.
-
-**Neutron Network**
-
-.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-network.png
-
- Neutron Network
-
-A Neutron network has the following characteristics:
-
-* defines a broadcast domain
-* defines a L2 transmission domain
-* defines a L2 name space.
-
-To represent this, a Neutron Network is mapped to multiple **GBP** entities.
-The first mapping is to an L2 flood-domain to reflect that the Neutron network
-is one flooding or broadcast domain.
-An L2-bridge-domain is then associated as the parent of L2 flood-domain. This
-reflects both the L2 transmission domain as well as the L2 addressing namespace.
-
-The third mapping is to L3-context, which represents the distinct L3 address space.
-The L3-context is the parent of L2-bridge-domain.
-
-**Neutron Subnet**
-
-
-.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-subnet.png
-
- Neutron Subnet
-
-Neutron subnet is associated with a Neutron network. The Neutron subnet is
-mapped to a *GBP* subnet where the parent of the subnet is L2-flood-domain
-representing the Neutron network.
-
-**Neutron Security Group**
-
-
-.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-securitygroup.png
-
- Neutron Security Group and Rules
-
-**GBP** entity representing Neutron security-group is EndpointGroup.
-
-**Infrastructure EndpointGroups**
-
-Neutron-mapper automatically creates EndpointGroups to manage key infrastructure
-items such as:
-
-* DHCP EndpointGroup - contains endpoints representing Neutron DHCP ports
-* Router EndpointGroup - contains endpoints representing Neutron router
- interfaces
-* External EndpointGroup - holds L3-endpoints representing Neutron router
- gateway ports, also associated with FloatingIP ports.
-
-**Neutron Security Group Rules**
-
-This mapping is most complicated among all others because Neutron
-security-group-rules are mapped to contracts with clauses,
-subjects, rules, action-refs, classifier-refs, etc.
-Contracts are used between endpoint groups representing Neutron Security Groups.
-For simplification it is important to note that Neutron security-group-rules are
-similar to a **GBP** rule containing:
-
-* classifier with direction
-* action of *allow*.
-
-
-**Neutron Routers**
-
-
-.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-router.png
-
- Neutron Router
-
-Neutron router is represented as a L3-context. This treats a router as a Layer3
-namespace, and hence every network attached to it a part
-of that Layer3 namespace.
-
-This allows for multiple routers per tenant with complete isolation.
-
-The mapping of the router to an endpoint represents the router's interface or
-gateway port.
-
-The mapping to an EndpointGroup represents the internal infrastructure
-EndpointGroups created by the **GBP** Neutron Mapper
-
-When a Neutron router interface is attached to a network/subnet, that
-network/subnet and its associated endpoints or Neutron Ports are seamlessly
-added to the namespace.
-
-**Neutron FloatingIP**
-
-When associated with a Neutron Port, this leverages the *GBP* OfOverlay
-renderer's NAT capabilities.
-
-A dedicated *external* interface on each Nova compute host allows for
-disitributed external access. Each Nova instance associated with a
-FloatingIP address can access the external network directly without having to
-route via the Neutron controller, or having to enable any form
-of Neutron distributed routing functionality.
-
-Assuming the gateway provisioned in the Neutron Subnet command for the external
-network is reachable, the combination of *GBP* Neutron Mapper and
-OfOverlay renderer will automatically ARP for this default gateway, requiring
-no user intervention.
-
-
-**Troubleshooting within GBP**
-
-Logging level for the mapping functionality can be set for package
-org.opendaylight.groupbasedpolicy.neutron.mapper. An example of enabling TRACE
-logging level on karaf console:
-
-.. code-block:: bash
-
- log:set TRACE org.opendaylight.groupbasedpolicy.neutron.mapper
-
-**Neutron mapping example**
-
-As an example for mapping can be used creation of Neutron network, subnet and
-port. When a Neutron network is created 3 **GBP** entities are created:
-l2-flood-domain, l2-bridge-domain, l3-context.
-
-.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-network-example.png
-
- Neutron network mapping
-
-After an subnet is created in the network mapping looks like this.
-
-.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-subnet-example.png
-
- Neutron subnet mapping
-
-If an Neutron port is created in the subnet an endpoint and l3-endpoint are
-created. The endpoint has key composed from l2-bridge-domain and MAC address
-from Neutron port. A key of l3-endpoint is compesed from l3-context and IP
-address. The network containment of endpoint and l3-endpoint points to the
-subnet.
-
-
-.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-port-example.png
-
- Neutron port mapping
-
-Configuring GBP Neutron
------------------------
-
-No intervention passed initial OpenStack setup is required by the user.
-
-More information about configuration can be found in our DevStack demo
-environment on the `GBP wiki <gbp_wiki_>`_.
-
-Administering or Managing GBP Neutron
--------------------------------------
-
-For consistencies sake, all provisioning should be performed via the Neutron API. (CLI or Horizon).
-
-The mapped policies can be augmented via the **GBP** UX,UX, to:
-
-* Enable Service Function Chaining
-* Add endpoints from outside of Neutron i.e. VMs/containers not provisioned in OpenStack
-* Augment policies/contracts derived from Security Group Rules
-* Overlay additional contracts or groupings
-
-Tutorials
----------
-
-A DevStack demo environment can be found on the
-`GBP wiki <gbp_wiki_>`_.
-
-.. _gbp_wiki: https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)
-.. _neutron_v2api: http://developer.openstack.org/api-ref-networking-v2.html
+++ /dev/null
-.. _vtn-openstack-dev-guide:
-
-OpenStack with Virtual Tenant Network
-=====================================
-
-This section describes using OpenDaylight with the VTN manager feature providing
-network service for OpenStack. VTN manager utilizes the OVSDB southbound service
-and Neutron for this implementation. The below diagram depicts the communication
-of OpenDaylight and two virtual networks connected by an OpenFlow switch using
-this implementation.
-
-.. figure:: images/vtn/OpenStackDeveloperGuide.png
-
- OpenStack Architecture
-
-Configure OpenStack to work with OpenDaylight(VTN Feature) using PackStack
---------------------------------------------------------------------------
-
-Prerequisites to install OpenStack using PackStack
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* Fresh CentOS 7.1 minimal install
-* Use the below commands to disable and remove Network Manager in CentOS 7.1,
-
-.. code-block:: bash
-
- systemctl stop NetworkManager
- systemctl disable NetworkManager
-
-* To make SELINUX as permissive, please open the file "/etc/sysconfig/selinux" and change it as "SELINUX=permissive".
-* After making selinux as permissive, please restart the CentOS 7.1 machine.
-
-Steps to install OpenStack PackStack in CentOS 7.1
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* To install OpenStack juno, use the following command,
-
-.. code-block:: bash
-
- yum update -y
- yum -y install https://repos.fedorapeople.org/repos/openstack/openstack-juno/rdo-release-juno-1.noarch.rpm
-
-
-* To install the packstack installer, please use the below command,
-
-.. code-block:: bash
-
- yum -y install openstack-packstack
-
-* To create all-in-one setup, please use the below command,
-
-.. code-block:: bash
-
- packstack --allinone --provision-demo=n --provision-all-in-one-ovs-bridge=n
-
-* This will end up with Horizon started successfully message.
-
-Steps to install and deploy OpenDaylight in CentOS 7.1
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* Download the latest Boron distribution code in the below link,
-
-.. code-block:: bash
-
- wget https://nexus.opendaylight.org/content/groups/public/org/opendaylight/integration/distribution-karaf/0.5.0-Boron/distribution-karaf-0.5.0-Boron.zip
-
-
-* Unzip the Boron distribution code by using the below command,
-
-.. code-block:: bash
-
- unzip distribution-karaf-0.5.0-Boron.zip
-
-* Please do the below steps in the OpenDaylight to change jetty port,
-
- * Change the jetty port from 8080 to something else as swift proxy of
- OpenStack is using it.
- * Open the file "etc/jetty.xml" and change the jetty port from 8080 to 8910
- (we have used 8910 as jetty port you can use any other number).
- * Start VTN Manager and install odl-vtn-manager-neutron in it.
- * Ensure all the required ports(6633/6653,6640 and 8910) are in the listen
- mode by using the command "netstat -tunpl" in OpenDaylight.
-
-Steps to reconfigure OpenStack in CentOS 7.1
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-* Steps to stop Open vSwitch Agent and clean up ovs
-
-.. code-block:: bash
-
- sudo systemctl stop neutron-openvswitch-agent
- sudo systemctl disable neutron-openvswitch-agent
- sudo systemctl stop openvswitch
- sudo rm -rf /var/log/openvswitch/*
- sudo rm -rf /etc/openvswitch/conf.db
- sudo systemctl start openvswitch
- sudo ovs-vsctl show
-
-
-* Stop Neutron Server
-
-.. code-block:: bash
-
- systemctl stop neutron-server
-
-
-* Verify that OpenDaylight's ML2 interface is working:
-
-.. code-block:: bash
-
- curl -v admin:admin http://{CONTROL_HOST}:{PORT}/controller/nb/v2/neutron/networks
-
- {
- "networks" : [ ]
- }
-
-If this does not work or gives an error, check Neutron's log file in
-*/var/log/neutron/server.log*. Error messages here should give
-some clue as to what the problem is in the connection with OpenDaylight
-
-* Configure Neutron to use OpenDaylight's ML2 driver:
-
-.. code-block:: bash
-
- sudo crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 mechanism_drivers opendaylight
- sudo crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 tenant_network_types local
- sudo crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 type_drivers local
- sudo crudini --set /etc/neutron/dhcp_agent.ini DEFAULT ovs_use_veth True
-
- cat <<EOT | sudo tee -a /etc/neutron/plugins/ml2/ml2_conf.ini > /dev/null
- [ml2_odl]
- password = admin
- username = admin
- url = http://{CONTROL_HOST}:{PORT}/controller/nb/v2/neutron
- EOT
-
-* Reset Neutron's ML2 database
-
-.. code-block:: bash
-
- sudo mysql -e "drop database if exists neutron_ml2;"
- sudo mysql -e "create database neutron_ml2 character set utf8;"
- sudo mysql -e "grant all on neutron_ml2.* to 'neutron'@'%';"
- sudo neutron-db-manage --config-file /usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini upgrade head
-
-* Start Neutron Server
-
-.. code-block:: bash
-
- sudo systemctl start neutron-server
-
-* Restart the Neutron DHCP service
-
-.. code-block:: bash
-
- system restart neutron-dhcp-agent.service
-
-* At this stage, your Open vSwitch configuration should be empty:
-
-.. code-block:: bash
-
- [root@dneary-odl-compute2 ~]# ovs-vsctl show
- 686989e8-7113-4991-a066-1431e7277e1f
- ovs_version: "2.3.1"
-
-
-* Set OpenDaylight as the manager on all nodes
-
-.. code-block:: bash
-
- ovs-vsctl set-manager tcp:127.0.0.1:6640
-
-
-* You should now see a section in your Open vSwitch configuration
- showing that you are connected to the OpenDaylight server, and OpenDaylight
- will automatically create a br-int bridge:
-
-.. code-block:: bash
-
- [root@dneary-odl-compute2 ~]# ovs-vsctl show
- 686989e8-7113-4991-a066-1431e7277e1f
- Manager "tcp:127.0.0.1:6640"
- is_connected: true
- Bridge br-int
- Controller "tcp:127.0.0.1:6633"
- is_connected: true
- fail_mode: secure
- Port "ens33"
- Interface "ens33"
- ovs_version: "2.3.1"
-
-* Add the default flow to OVS to forward packets to controller when there is a table-miss,
-
-.. code-block:: bash
-
- ovs-ofctl --protocols=OpenFlow13 add-flow br-int priority=0,actions=output:CONTROLLER
-
-* Please see the `VTN OpenStack PackStack support guide <VTN_OpenStack_PackStack_>`_
- on the wiki to create VM's from OpenStack Horizon GUI.
-
-Implementation details
-----------------------
-
-VTN Manager
-^^^^^^^^^^^
-Install **odl-vtn-manager-neutron** feature which provides the integration with
-Neutron interface.
-
-.. code-block:: bash
-
- feature:install odl-vtn-manager-neutron
-
-It subscribes to the events from Open vSwitch and also implements the Neutron
-requests received by OpenDaylight.
-
-Functional Behavior
-^^^^^^^^^^^^^^^^^^^
-
-**StartUp**
-
-* The ML2 implementation for OpenDaylight will ensure that when Open vSwitch is
- started, the ODL_IP_ADDRESS configured will be set as manager.
-* When OpenDaylight receives the update of the Open vSwitch on port 6640
- (manager port), VTN Manager handles the event and adds a bridge with required
- port mappings to the Open vSwitch at the OpenStack node.
-* When Neutron starts up, a new network create is POSTed to OpenDaylight, for
- which VTN Manager creates a Virtual Tenant Network.
-* *Network and Sub-Network Create:* Whenever a new sub network is created, VTN
- Manager will handle the same and create a vbridge under the VTN.
-* *VM Creation in OpenStack:* The interface mentioned as integration bridge in
- the configuration file will be added with more interfaces on creation of a
- new VM in OpenStack and the network is provisioned for it by the VTN Neutron
- feature. The addition of a new port is captured by the VTN Manager and it
- creates a vbridge interface with port mapping for the particular port. When
- the VM starts to communicate with other VMs, the VTN Manger will install flows
- in the Open vSwitch and other OpenFlow switches to facilitate communication
- between them.
-
-.. note::
-
- To use this feature, VTN feature should be installed
-
-Reference
----------
-
-https://wiki.opendaylight.org/images/5/5c/Integration_of_vtn_and_ovsdb_for_helium.pdf
-
-
-.. _VTN_OpenStack_PackStack: https://wiki.opendaylight.org/view/Release/Lithium/VTN/User_Guide/Openstack_Packstack_Support
+++ /dev/null
-.. BGP documentation master file, created by
- sphinx-quickstart on Monday Jun 25 10:29:30 2018.
- You can adapt this file completely to your liking, but it should at least
- contain the root `toctree` directive.
-
-BGPCEP Project Documentation
-============================
-This documentation provides critical information needed to help you write
-code for the BGPCEP project.
-
-
-Developer Guides
------------------
-
-.. toctree::
- :maxdepth: 1
-
- ../developer-guide/bgp-developer-guide
- ../developer-guide/bgp-monitoring-protocol-developer-guide
- ../developer-guide/pcep-developer-guide
-
-User Guides
------------
-
-.. toctree::
- :maxdepth: 1
-
- ../user-guide/bgpcep-guide/bgp/index
- ../user-guide/bgpcep-guide/bmp/index
- ../user-guide/bgpcep-guide/pcep/index
+++ /dev/null
-Data Export/Import Project Documentation
-========================================
-
-This page provides pointers to the existing documentation for the Data Export Import (daexim) project.
-
-Developer Guides
-----------------
-
-.. toctree::
- :maxdepth: 1
-
- ../developer-guide/daexim-developer-guide
-
-User Guides
------------
-
-.. toctree::
- :maxdepth: 1
-
- ../user-guide/daexim-user-guide
+++ /dev/null
-LISP Flow Mapping Project Documentation
-=======================================
-This page provides pointers to the existing documentation for the LISP
-Flow Mapping project.
-
-User Guides
------------
-
-.. toctree::
- :maxdepth: 1
-
- ../user-guide/lisp-flow-mapping-user-guide
+++ /dev/null
-SXP Project Documentation
-=========================
-This page provides pointers to the existing documentation for the SXP project.
-
-Developer Guides
-----------------
-
-.. toctree::
- :maxdepth: 1
-
- ../developer-guide/sxp-developer-guide
-
-User Guides
------------
-
-.. toctree::
- :maxdepth: 1
-
- ../user-guide/sxp-user-guide
Project-specific Release Notes
==============================
-.. toctree::
- :glob:
- :maxdepth: 1
+.. .. toctree::
+.. :glob:
+.. :maxdepth: 1
+..
+.. projects/*
+
+`odlparent`_
-.. projects/*
+.. _odlparent: https://git.opendaylight.org/gerrit/gitweb?p=odlparent.git;a=blob;f=NEWS.rst
.. Service Release Notes
.. =====================
The version bump patches can be merged more quickly by performing a local
build with ``mvn clean deploy -DskipTests`` to prime Nexus with the new
version updates.
+
+Documentation post branch tasks
+-------------------------------
+
+#. Git remove all files/directories from the docs/release-notes/* directory. **(Release Engineering Team)**
+
+ .. code-block:: bash
+
+ git checkout master
+ git rm -rf docs/release-notes/<project file and/or folder>
+ git commit -sm "Reset release notes for next dev cycle"
+ git review
--- /dev/null
+*******************************************************
+Identifying Managed Projects in an OpenDaylight Version
+*******************************************************
+
+What are Managed Projects?
+==========================
+
+Managed Projects are simply projects that take part in the :ref:`Managed
+Release Process <managed-release>`. Managed Projects are either core components
+of OpenDaylight or have demonstrated their maturity and ability to successfully
+take part in the Managed Release.
+
+For more information, see the full description of :ref:`Managed Projects
+<managed-projects>`.
+
+What is a Managed Distribution?
+===============================
+
+Managed Projects are aggregated together by a POM file that defines a Managed
+Distribution. The Managed Distribution is the focus of OpenDaylight
+development. It's continuously built, tested, packaged and released into
+Continuous Delivery pipelines. As prescribed by the Managed Release Process,
+Managed Distributions are eventually blessed as formal OpenDaylight releases.
+
+NB: OpenDaylight's Fluorine release actually included Managed and Self-Managed
+Projects, but the community is working towards the formal release being exactly
+the Managed Distribution, with an option for Self-Managed Projects to release
+independently on top of the Managed Distribution later.
+
+Finding the Managed Projects given a Managed Distribution
+=========================================================
+
+Given a Managed Distribution (tar.gz, .zip, RPM, Deb), the Managed Projects
+that constitute it can be found in the `taglist.log` file in the root of the
+archive.
+
+`taglist.log` files are of the format:
+
+.. code::
+
+ <Managed Project> <Git SHA of built commit> <Codename of release>
+
+Finding the Managed Projects Given a Branch
+===========================================
+
+To find the current set of Managed Projects in a given OpenDaylight branch,
+examine the `integration/distribution/features/repos/index/pom.xml`_ file that defines the Managed Distribution.
+
+.. _integration/distribution/features/repos/index/pom.xml: https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=features/repos/index/pom.xml
project-lifecycle
branch-cutting
simultaneous-release
+ super-committers
************************
Supporting Documentation
************************
+.. toctree::
+ :maxdepth: 1
+
+ identifying-managed-projects
+
The release management team maintains several documents in Google Drive to
track releases. These documents can be found at this link:
+.. _managed-release:
+
***************
Managed Release
***************
latitude to step in and help projects that are required for dependency reasons
but may not have a large set of active contributors.
+.. _managed-projects:
+
Managed Projects
================
.. code-block:: none
- This is a request for a project to move from Self-Managed to Managed. It
+ This is a request for a project to move from Managed to Self-Managed. It
should be submitted no later than the start of the release. The request
does not require any additional information, but it may be helpful for
the requesting project to provide some background and their reasoning.
In general there are two types of Self-Managed (SM) projects:
#. Self-Managed projects that want to participate in the formal (major or
- service) OpenDaylight release. This section includes the requirements
- and release process for these projects.
+ service) OpenDaylight release distribution. This section includes the
+ requirements and release process for these projects.
#. Self-Managed projects that want to manage their own release schedule
- and installation instructions. There are no specific requirements for
+ or provide their release distribution and installation instructions
+ by the time of the release. There are no specific requirements for
these projects.
-Requirements for SM projects participating in the formal release
-----------------------------------------------------------------
+Requirements for SM projects participating in the release distribution
+----------------------------------------------------------------------
Use of SNAPSHOT versions
++++++++++++++++++++++++
-Self-Managed Projects can consume whichever version of their upstream
-dependencies they want during most of the release cycle, but if they want to be
-included in the formal (major or service) release they must have their upstream
+Self-Managed Projects can consume whichever version of their upstream dependencies
+they want during most of the release cycle, but if they want to be included in the
+formal (major or service) release distribution they must have their upstream
versions bumped to SNAPSHOT and build successfully no later than one week before
the first Managed release candidate (RC) is created. Since bumping and integrating
with upstream takes time, it is strongly recommended Self-Managed projects start
-this work early enough. This is no later than the middle checkpoint if they want to
-be in the formal release, or by the previous release if they want to be in a
+this work early enough. This is no later than the middle checkpoint if they want
+to be in a major release, or by the previous release if they want to be in a
service release (e.g. by the major release date if they want to be in SR1).
.. note:: To help with the integration effort, the `Weather Page`_ includes API and
other important changes during the release cycle. After the formal release,
the release notes also include this information.
-Add to Final Distribution
-+++++++++++++++++++++++++
+Add to Common Distribution
+++++++++++++++++++++++++++
-In order to be included in the formal (major or service) release final distribution,
-Self-Managed Projects must be in the final distribution pom.xml file and the
+In order to be included in the formal (major or service) release distribution,
+Self-Managed Projects must be in the common distribution pom.xml file and the
distribution sanity test (see :ref:`add-proj-dist`) no later than one week before
the first Managed release candidate (RC) is created. Projects should only be added
to the final distribution pom.xml after they have succesfully published artifacts
.. note:: It is very important Self-Managed projects do not miss the deadlines for
upstream integration and final distribution check, otherwise there are
- high chances for missing the formal release. See
+ high chances for missing the formal release distribution. See
`Release the project artifacts`_.
+Cut Stable Branch
++++++++++++++++++
+
+Self-Managed projects wanting to use the existing release job to release their
+artifacts (see `Release the project artifacts`_) must have an stable branch in
+the major release (fluorine, neon, etc) they are targeting. It is highly recommended
+to cut the stable branch before the first Managed release candidate (RC) is created.
+
+After creating the stable branch Self-Managed projects should:
+
+* Bump master branch version to X.Y+1.0-SNAPSHOT, this way any new merge in master
+ will not interfere with the new created stable branch artifacts.
+
+* Update .gitreview for stable branch: change defaultbranch=master to stable branch.
+ This way folks running "git review" will get the right branch.
+
+* Update their jenkins jobs: current release should point to the new created stable
+ branch and next release should point to master branch. If you do not know how to
+ do this please open a ticket to opendaylight helpdesk.
+
Release the project artifacts
+++++++++++++++++++++++++++++
-Self-Managed Projects wanting to participate in a formal (major or service) release,
-must perform the following tasks in the week after the Managed release is published
-to nexus:
+Self-Managed projects wanting to participate in the formal (major or service) release
+distribution must release and publish their artifacts to nexus in the week after the
+Managed release is published to nexus.
+
+Self-Managed projects having an stable branch with latest upstream SNAPSHOT (see
+previous requirements) can use the release job in :doc:`project-release` to release
+their artifacts.
-#. Bump their upstream version to latest Managed release.
-#. Release the project and publish the artifacts to nexus. All projects have
- a job for this.
-#. Add their release artifact to the full distribution.
+After creating the release, Self-Managed projects should bump the stable branch
+version to X.Y.Z+1-SNAPSHOT, this way any new merge in the stable branch will not
+interfere with pre-release artifacts.
.. note:: Self-Managed Projects will not have any leeway for missing deadlines. If
projects are not in the final distribution in the allocated time (normally
one week) after the Managed projects release, they will not be included
- in the formal release.
+ in the release distribution.
Checkpoints
+++++++++++
This page documents the current rules to follow when adding and removing
a particular project to Simultaneous Release (SR).
-List of states
-==============
+List of states for projects in autorelease
+==========================================
The state names are short negative phrases describing what is missing to
progress to the following state.
a project is not left in an invalid state, for example distribution referencing
feature repositories, but without passing distribution-check job.
+.. note::
+
+ Projects can participate in Simultaneous Release even if they are not included in autorelease.
+ Nitrogen example: Odlparent.
+ FIXME: Clarify states for such projects (per version, if they released multiple times within the same cycle).
+
.. todo::
- Add links to documents concerning project lifecycle from TSC point of view.
Preparing your project for release
==================================
-A project can produce a staging repository by clicking "build" for their
-{project-name}-maven-release-{stream} job. This job performs the following
-duties:
+A project can produce a staging repository by using one of the following
+methods against the {project-name}-maven-stage-{stream} job:
+
+* Leave a comment ``stage-release`` against any patch for the stream to build
+* Click ``Build with Parameters`` in Jenkins Web UI for the job
+
+This job performs the following duties:
1. Removes -SNAPSHOT from all pom files
2. Produces a taglist.log, project.patch, and project.bundle files
1. Ask helpdesk to sign the artifacts in staging repo
2. Ask helpdesk to promote the staging repo
-3. Download taglist.log and project.bundle
+3. Download taglist.log and project.bundle files. They can be found in the
+ "patches" directory of the related jenkins release job logs.
4. Read taglist.log and checkout the commit hash listed
5. Merge the project.bundle patches
6. Git tag the release
7. Push release tag to Gerrit
Steps 4-7 as bash:
+You will need a working GPG config to sign the release Git tag ("-s" option)
.. code:: bash
Once complete the Git tag should be available in Gerrit and the Artifacts should
appear in the Nexus opendaylight.release repo.
+
+The following shell script will do this for you:
+
+.. code:: bash
+
+ #!/bin/sh
+
+ set -e
+
+ if [ $# != 3 ]; then
+ echo Usage: $0 project version log-URL
+ echo fetches a project release\'s logs from log-URL and tags the git repository
+ exit 1
+ fi
+
+ PROJECT=$1
+ VERSION=$2
+ PATCH_DIR=/tmp/patches
+
+ mkdir -p $PATCH_DIR
+ cd $PATCH_DIR
+ rm -f ${PROJECT}.bundle taglist.log{,.gz}
+ wget ${3}/patches/{${PROJECT}.bundle,taglist.log.gz}
+ gunzip taglist.log.gz
+ cd -
+ git checkout $(awk '{print $NF}' "$PATCH_DIR/taglist.log")
+ git fetch "$PATCH_DIR/$PROJECT.bundle"
+ git merge --ff-only FETCH_HEAD
+ git tag -asm "$PROJECT $VERSION" "v$VERSION"
+ git push origin "v$VERSION"
+
+You need to run it from a clone git repository of your project,
+and give it as arguments the project’s short name, the newly-
+released version, and the URL of the release build’s logs; for
+example:
+
+.. code:: bash
+
+ sign-odl-release odlparent 4.0.0 https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/odlparent-maven-release-master/11/
worked well to host these events in conjunction with other large, relevant
events like ONS.
-.. _Managed Release Process: https://git.opendaylight.org/gerrit/#/c/68382/
+.. _Managed Release Process: https://git.opendaylight.org/gerrit/68382/
--- /dev/null
+****************
+Super Committers
+****************
+
+Super committers are a group of TSC-approved individuals within the
+OpenDaylight community with the power to merge patches on behalf of projects
+during approved Release Activities.
+
+
+Super Committer Activities
+--------------------------
+
+Super committers are given super committer powers **ONLY** during TSC-approved
+activities and are not a power that is active on a regular basis. Once one of
+the TSC-approved activities are triggered, :doc:`helpdesk <lfdocs:helpdesk>`
+will enable the permissions listed for the respective activities for the
+duration of that activity.
+
+Code Freeze
+'''''''''''
+
+.. note::
+
+ This activity has been pre-approved by the TSC and does not require a TSC
+ vote. :doc:`Helpdesk <lfdocs:helpdesk>` should be notified to enable the
+ permissions and again to disable the permissions once activities are
+ complete.
+
+Super committers are granted powers to merge blocking patches for the duration
+code of freeze until a release is approved and code freeze is lifted. This
+permission is only granted for the specific branch that is frozen.
+
+The following powers are granted:
+
+* Submit button access
+
+During this time Super Committers can **ONLY** merge patches that have a +2
+Code-Review by a project committer approving the merge, and the patch passes
+Jenkins Verify check. If neither of these conditions are met then **DO NOT**
+merge the patch.
+
+Version bumping
+'''''''''''''''
+
+.. note::
+
+ This activity has been pre-approved by the TSC and does not require a TSC
+ vote. :doc:`Helpdesk <lfdocs:helpdesk>` should be notified to enable the
+ permissions and again to disable the permissions once activities are
+ complete.
+
+Super committers are granted powers to merge version bump related patches for
+the duration of version bumping activities.
+
+The following powers are granted:
+
+* Vote Code-Review +2
+* Vote Verified +1
+* Submit button access
+
+These permissions are granted to allow super committers to push through version
+bump patches with haste.
+
+Version bumping activities come in 2 forms.
+
+1. Post-release Autorelease version bumping
+2. MRI project version bumping
+
+Case 1, the TSC has approved an official OpenDaylight release and after the
+binaries are released to the world all Autorelease managed projects are version
+bumped appropriately to the next development release number.
+
+Case 2, During the Release Integrated Deadline of the release schedule MRI
+projects submit desired version updates. Once approved by the TSC Super
+Committers can merge these patches across the projects.
+
+Ideally the version bumping activities should not include code modifications,
+if they do +2 Code-Review vote should be complete by a committer on the project
+to indicate that they approve the code changes.
+
+Once version bump patches are merged these permissions are removed.
+
+Exceptional cases
+'''''''''''''''''
+
+Any activities not in the list above will fall under the exceptional case in
+which requires TSC approval before Super Committers can merge changes. These
+cases should be brought up to the TSC for voting.
+
+
+Super Committers
+----------------
+
+========================= =================== =================================
+Name IRC Email
+========================= =================== =================================
+Anil Belur abelur abelur@linuxfoundation.org
+Ariel Adams aadams aadam@redhat.com
+Daniel Farrell dfarrell07 dfarrell@redhat.com
+Jamo Luhrsen jamoluhrsen jluhrsen@gmail.com
+Luis Gomez LuisGomez ecelgp@gmail.com
+Michael Vorburger vorburger vorburger@redhat.com
+Sam Hague shague shague@redhat.com
+Stephen Kitt skitt skitt@redhat.com
+Robert Varga rovarga nite@hq.sk
+Thanh Ha zxiiro thanh.ha@linuxfoundation.org
+========================= =================== =================================
+++ /dev/null
-.. _alto-user-guide:
-
-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
-.. _aaa-user-guide:
-
-Authentication, Authorization and Accounting (AAA) Services
-===========================================================
-
-Overview
---------
-
-Authentication, Authorization and Accounting (AAA) is a term for a
-framework controlling access to resources, enforcing policies to use
-those resources and auditing their usage. These processes are the
-fundamental building blocks for effective network management and security.
-
-Authentication provides a way of identifying a user, typically by
-having the user enter a valid user name and valid password before access
-is granted. The process of authentication is based on each user having a unique
-set of criteria for gaining access. The AAA framework compares a user's
-authentication credentials with other user credentials stored in a database.
-If the credentials match, the user is granted access to the network.
-If the credentials don't match, authentication fails and access is denied.
-
-Authorization is the process of finding out what an authenticated user is
-allowed to do within the system, which tasks can do, which API can call, etc.
-The authorization process determines whether the user has the authority
-to perform such actions.
-
-Accounting is the process of logging the activity of an authenticated user,
-for example, the amount of data a user has sent and/or received during a
-session, which APIs called, etc.
-
-Terms And Definitions
-^^^^^^^^^^^^^^^^^^^^^
-
-AAA
- Authentication, Authorization and Accounting.
-
-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.
-
-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 user name 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.
-
-Grant
- It is the entity associating a user with his role and domain.
-
-IdP
- Identity Provider.
-
-TLS
- Transport Layer Security
-
-CLI
- Command Line Interface
-
-Security Framework for AAA services
------------------------------------
-
-Since Boron release, the OpenDaylight's AAA services are based on the
-`Apache Shiro <https://shiro.apache.org/>`_ Java Security Framework. The main
-configuration file for AAA is located at “etc/shiro.ini” relative to the
-OpenDaylight Karaf home directory.
-
-
-How to enable AAA
------------------
-
-AAA is enabled through installing the odl-aaa-shiro feature. The vast majority
-of OpenDaylight's northbound APIs (and all RESTCONF APIs) are protected by AAA
-by default when installing the +odl-restconf+ feature, since the odl-aaa-shiro
-is automatically installed as part of them. In the cases that APIs are *not*
-protected by AAA, this will be noted in the per-project release notes.
-
-How to disable AAA
-------------------
-
-Edit the “etc/shiro.ini” file and replace the following:
-
-::
-
- /** = authcBasic
-
-with
-
-::
-
- /** = anon
-
-Then restart the Karaf process.
-
-AAA Realms
-----------
-
-AAA plugin utilizes the Shiro 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
- capabilities.
-
-OpenDaylight contains five implementations:
-
-- TokenAuthRealm
-
- - An AuthorizingRealm built to bridge the Shiro-based AAA service
- with the 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. This is the realm configured by default.
-
-- 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
- OpenDaylight 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.
-
-- ODLActiveDirectoryRealm
-
- - Wraps the generic ActiveDirectoryRealm provided by Shiro. This allows for
- enhanced logging as well as isolation of all realms in a single package,
- which enables easier import by consuming servlets.
-
-- KeystoneAuthRealm
-
- - This realm authenticates OpenDaylight users against the OpenStack’s
- Keystone server.
-
- - Disabled out of the box.
-
-.. note::
-
- More than one Realm implementation can be specified. Realms are attempted
- in order until authentication succeeds or all realm sources are exhausted.
- Edit the **securityManager.realms = $tokenAuthRealm** property in shiro.ini
- and add all the realms needed separated by commas.
-
-TokenAuthRealm
-^^^^^^^^^^^^^^
-
-How it works
-~~~~~~~~~~~~
-
-The TokenAuthRealm is the default Authorization Realm deployed in OpenDaylight.
-TokenAuthRealm uses a direct authentication mechanism as shown in the following
-picture:
-
-.. figure:: ./images/aaa/direct-authentication.png
- :alt: TokenAuthRealm direct authentication mechanism
-
- TokenAuthRealm direct authentication mechanism
-
-A user presents some credentials (e.g., username/password) directly to the
-OpenDaylight controller token endpoint /oauth2/token and receives an access
-token, which then can be used to access protected resources on the controller.
-
-Configuring TokenAuthRealm
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The 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 tool
-
-- RESTful Web Service configuration
-
-**Idmtool**
-###########
-
-A utility script located at “etc/idmtool” is used to manipulate the
-TokenAuthRealm IdM policy. idmtool assumes a single domain, the default one
-(sdn), since multiple domains are not supported 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"
- }
- ]
- }
-
-**Configuration using the 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
- }
- ]
- }
-
-**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.
-
-ODLJndiLdapRealm
-^^^^^^^^^^^^^^^^
-
-How it works
-~~~~~~~~~~~~
-
-LDAP integration is provided in order to externalize identity
-management. This configuration allows federation with an external LDAP server.
-The user’s OpenDaylight 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 OpenDaylight role
-structures.
-
-Configuring ODLJndiLdapRealm
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-To configure LDAP parameters, modify "etc/shiro.ini"
-parameters to include the ODLJndiLdapRealm:
-
-::
-
- # OpenDaylight 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
-
-ODLJndiLdapRealmAuthNOnly
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-How it works
-~~~~~~~~~~~~
-
-This is useful for setups where all LDAP users are allowed equal access.
-
-Configuring ODLJndiLdapRealmAuthNOnly
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-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
-
-KeystoneAuthRealm
-^^^^^^^^^^^^^^^^^
-
-How it works
-~~~~~~~~~~~~
-
-This realm authenticates OpenDaylight users against the OpenStack's Keystone
-server. This realm uses the
-`Keystone's Identity API v3 <https://developer.openstack.org/api-ref/identity/v3/>`_
-or later.
-
-.. figure:: ./images/aaa/keystonerealm-authentication.png
- :alt: KeystoneAuthRealm authentication mechanism
-
- KeystoneAuthRealm authentication/authorization mechanism
-
-As can shown on the above diagram, once configured, all the RESTCONF APIs calls
-will require sending **user**, **password** and optionally **domain** (1). Those
-credentials are used to authenticate the call against the Keystone server (2) and,
-if the authentication succeeds, the call will proceed to the MDSAL (3). The
-credentials must be provisioned in advance within the Keystone Server. The user
-and password are mandatory, while the domain is optional, in case it is not
-provided within the REST call, the realm will default to (**Default**),
-which is hard-coded. The default domain can be also configured through the
-*shiro.ini* file (see the :doc:`AAA User Guide <../user-guide/authentication-and-authorization-services>`).
-
-The protocol between the Controller and the Keystone Server (2) can be either
-HTTPS or HTTP. In order to use HTTPS the Keystone Server's certificate
-must be exported and imported on the Controller (see the :ref:`Certificate Management <certificate-management>` section).
-
-Configuring KeystoneAuthRealm
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Edit the "etc/shiro.ini" file and modify the following:
-
-::
-
- # The KeystoneAuthRealm allows for authentication/authorization against an
- # OpenStack's Keystone server. It uses the Identity's API v3 or later.
- keystoneAuthRealm = org.opendaylight.aaa.shiro.realm.KeystoneAuthRealm
- # The URL where the Keystone server exposes the Identity's API v3 the URL
- # can be either HTTP or HTTPS and it is mandatory for this realm.
- keystoneAuthRealm.url = https://<host>:<port>
- # Optional parameter to make the realm verify the certificates in case of HTTPS
- #keystoneAuthRealm.sslVerification = true
- # Optional parameter to set up a default domain for requests using credentials
- # without domain, uncomment in case you want a different value from the hard-coded
- # one "Default"
- #keystoneAuthRealm.defaultDomain = Default
-
-Once configured the realm, the mandatory fields are the fully quallified name of
-the class implementing the realm *keystoneAuthRealm* and the endpoint where the
-Keystone Server is listening *keystoneAuthRealm.url*.
-
-The optional parameter *keystoneAuthRealm.sslVerification* specifies whether the
-realm has to verify the SSL certificate or not. The optional parameter
-*keystoneAuthRealm.defaultDomain* allows to use a different default domain from
-the hard-coded one *"Default"*.
-
-Authorization Configuration
----------------------------
-
-OpenDaylight supports two authorization engines at present, both of which are
-roughly similar in behavior:
-
-- Shiro-Based Authorization
-
-- MDSAL-Based Dynamic Authorization
-
-.. note::
-
- The preferred mechanism for configuring AAA Authentication is the
- MDSAL-Based Dynamic Authorization. Read the following section.
-
-Shiro-Based Static Authorization
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-OpenDaylight AAA has support for Role Based Access Control (RBAC) based
-on the Apache Shiro permissions system. Configuration of the authorization
-system is done off-line; authorization currently cannot be configured
-after the controller is started. The Authorization provided by this mechanism
-is aimed towards supporting coarse-grained security policies, the MDSAL-Based
-mechanism allows for a more robust configuration capabilities. `Shiro-based
-Authorization <http://shiro.apache.org/web.html#Web-%7B%7B%5Curls%5C%7D%7D>`_
-describes how to configure the Authentication feature in detail.
-
-.. note::
-
- The Shiro-Based Authorization that uses the *shiro.ini* URLs section to
- define roles requirements is **deprecated** and **discouraged** since the
- changes made to the file are only honored on a controller restart.
-
- Shiro-Based Authorization is not **cluster-aware**, so the changes made on
- the *shiro.ini* file have to be replicated on every controller instance
- belonging to the cluster.
-
- The URL patterns are matched relative to the Servlet context leaving room
- for ambiguity, since many endpoints may match (i.e., "/restconf/modules" and
- "/auth/modules" would both match a "/modules/\**" rule).
-
-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!
-
-MDSAL-Based Dynamic Authorization
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The MDSAL-Based Dynamic authorization uses the MDSALDynamicAuthorizationFilter
-engine to restrict access to particular URL endpoint patterns. Users may define
-a list of policies that are insertion-ordered. Order matters for that list of
-policies, since the first matching policy is applied. This choice was made to
-emulate behavior of the Shiro-Based Authorization mechanism.
-
-A **policy** is a key/value pair, where the key is a **resource**
-(i.e., a "URL pattern") and the value is a list of **permissions** for the
-resource. The following describes the various elements of a policy:
-
-- **Resource**: the resource is a string URL pattern as outlined by
- Apache Shiro. For more information, see http://shiro.apache.org/web.html.
-
-- **Description**: an optional description of the URL endpoint and why it is
- being secured.
-
-- **Permissions list**: a list of permissions for a particular policy. If more
- than one permission exists in the permissions list they are evaluated using
- logical "OR". A permission describes the prerequisites to perform HTTP
- operations on a particular endpoint. The following describes the various
- elements of a permission:
-
- + **Role**: the role required to access the target URL endpoint.
- + **Actions list**: a leaf-list of HTTP permissions that are allowed for a
- Subject possessing the required role.
-
-This an example on how to limit access to the modules endpoint:
-
-::
-
- HTTP Operation:
- put URL: /restconf/config/aaa:http-authorization/policies
-
- headers: Content-Type: application/json Accept: application/json
-
- body:
- { "aaa:policies":
- { "aaa:policies":
- [ { "aaa:resource": "/restconf/modules/**",
- "aaa:permissions": [ { "aaa:role": "admin",
- "aaa:actions": [ "get",
- "post",
- "put",
- "patch",
- "delete"
- ]
- }
- ]
- }
- ]
- }
- }
-
-The above example locks down access to the modules endpoint (and any URLS
-available past modules) to the "admin" role. Thus, an attempt from the OOB
-*admin* user will succeed with 2XX HTTP status code, while an attempt from the
-OOB *user* user will fail with HTTP status code 401, as the user *user* is not
-granted the "admin" role.
-
-Accounting Configuration
-------------------------
-
-Accounting is handled through the standard slf4j logging mechanisms used by the
-rest of OpenDaylight. Thus, one can control logging verbosity through
-manipulating the log levels for individual packages and classes directly through
-the Karaf console, JMX, or etc/org.ops4j.pax.logging.cfg. In normal operations,
-the default levels exposed do not provide much information about AAA services;
-this is due to the fact that logging can severely degrade performance.
-
-All AAA logging is output to the standard karaf.log file. For debugging purposes
-(i.e., to enable maximum verbosity), issue the following command:
-
-::
-
- log:set TRACE org.opendaylight.aaa
-
-Enable Successful/Unsuccessful Authentication Attempts Logging
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-By default, successful/unsuccessful authentication attempts are NOT logged. This
-is due to the fact that logging can severely decrease REST performance.
-To enable logging of successful/unsuccessful REST attempts, issue the following
-command in Karaf's console:
-
-::
-
- log:set DEBUG org.opendaylight.aaa.shiro.filters.AuthenticationListener
-
-It is possible to add custom AuthenticationListener(s) to the Shiro-based
-configuration, allowing different ways to listen for successful/unsuccessful
-authentication attempts. Custom AuthenticationListener(s) must implement
-the org.apache.shiro.authc.AuthenticationListener interface.
-
-.. _certificate-management:
-
-Certificate Management
-----------------------
-
-The **Certificate Management Service** is used to manage the keystores and
-certificates at the OpenDaylight distribution to easily provides the TLS
-communication.
-
-The Certificate Management Service managing two keystores:
-
-1. **OpenDaylight Keystore** which holds the OpenDaylight distribution
- certificate self sign certificate or signed certificate from a root CA based
- on generated certificate request.
-
-2. **Trust Keystore** which holds all the network nodes certificates that shall
- to communicate with the OpenDaylight distribution through TLS communication.
-
-The Certificate Management Service stores the keystores (OpenDaylight & Trust)
-as *.jks* files under configuration/ssl/ directory. Also the keystores
-could be stored at the MD-SAL datastore in case OpenDaylight distribution
-running at cluster environment. When the keystores are stored at MD-SAL,
-the Certificate Management Service rely on the **Encryption-Service** to encrypt
-the keystore data before storing it to MD-SAL and decrypted at runtime.
-
-How to use the Certificate Management Service to manage the TLS communication
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The following are the steps to configure the TLS communication:
-
-1. After starting the distribution, the *odl-aaa-cert* feature has to get
-installed. Use the following command at Karaf CLI to check.
-
-.. code-block:: bash
-
- opendaylight-user@root>feature:list -i | grep aaa-cert
- odl-aaa-cert | 0.5.0-SNAPSHOT | x | odl-aaa-0.5.0-SNAPSHOT | OpenDaylight :: AAA :: aaa certificate Service
-
-2. The initial configuration of the Certificate Manager Service exists under
-the distribution directory etc/opendaylight/datastore/initial/config/aaa-cert-config.xml.
-
-.. code-block:: xml
-
- <aaa-cert-service-config xmlns="urn:opendaylight:yang:aaa:cert">
- <use-config>false</use-config>
- <use-mdsal>false</use-mdsal>
- <bundle-name>opendaylight</bundle-name>
- <ctlKeystore>
- <name>ctl.jks</name>
- <alias>controller</alias>
- <store-password/>
- <dname>CN=ODL, OU=Dev, O=LinuxFoundation, L=QC Montreal, C=CA</dname>
- <validity>365</validity>
- <key-alg>RSA</key-alg>
- <sign-alg>SHA1WithRSAEncryption</sign-alg>
- <keysize>1024</keysize>
- <cipher-suites>
- <suite-name />
- </cipher-suites>
- </ctlKeystore>
- <trustKeystore>
- <name>truststore.jks</name>
- <store-password/>
- </trustKeystore>
- </aaa-cert-service-config>
-
-
-Now as it is explained above, the Certificate Manager Service support two mode
-of operations; cluster mode and single mode. To use the single mode change the
-use-config to true and it is recommended as long as there is no need for
-cluster environment. To use the cluster mode change the use-config and
-use-mdsal configurations to true and the keystores will be stored and shard
-across the cluster nodes within the MD-SAL datastore.
-
-The initial password become randomly generated when the *aaa-cert* feature is
-installed.
-
-The cipher suites can be restricted by changing the **<cipher-suites>**
-configuration, however, the JDK has to be upgraded by installing the `Java
-Cryptography Extension
-<http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html>`_
-policy.
-
-.. code-block:: xml
-
- <cipher-suites>
- <suite-name>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</suite-name>
- </cipher-suites>
- <cipher-suites>
- <suite-name>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384</suite-name>
- </cipher-suites>
- <cipher-suites>
- <suite-name>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</suite-name>
- </cipher-suites>
-
-3. The new configurations will take affect after restarting the distribution.
-
-4. Now to add or get certificate to the OpenDaylight and Trust keystores, the
-Certificate Manager Service provides the following RPCs.
-
-::
-
- a) Set the node certificate that will communicate with OpeDaylight through TLS
- connection.
- POST /operations/aaa-cert-rpc:setNodeCertifcate
- {
- "input": {
- "node-cert": "string",
- "node-alias": "string"
- }
- }
-
-::
-
- b) Get the node certificate based on node alias.
- POST /operations/aaa-cert-rpc:getNodeCertifcate
- {
- "input": {
- "node-alias": "string"
- }
- }
-
-::
-
- c) Get the OpeDaylight keystore certificate.
- POST /operations/aaa-cert-rpc:getODLCertificate
- {
- output {
- odl-cert "string"
- }
- }
-
-::
-
- d) Generate a certificate request from the OpeDaylight keystore to be signed
- by a CA.
- POST /operations/aaa-cert-rpc:getODLCertificateReq
- {
- output {
- odl-cert-req "string"
- }
- }
-
-::
-
- e) Set the OpeDaylight certificate, the certificate should be generated
- based on a certificate request generated from the ODL keystore otherwise the
- certificated will not be added.
- POST /operations/aaa-cert-rpc:setODLCertificate
- {
- "input": {
- "odl-cert-alias": "string",
- "odl-cert": "string"
- }
- }
-
-.. note::
-
- The Certificate Manager Service RPCs are allowed only to the Role Admin Users
- and it could be completely disabled through the shiro.ini config file. Check
- the URL section at the shiro.ini.
-
-Encryption Service
-------------------
-
-The **AAA Encryption Service** is used to encrypt the OpenDaylight's users'
-passwords and TLS communication certificates. This section shows how to use the
-AAA Encryption Service with an OpenDaylight distribution project to encrypt data.
-
-The following are the steps to configure the Encryption Service:
-
-1. After starting the distribution, the *aaa-encryption-service* feature has to
- get installed. Use the following command at Karaf CLI to check.
-
- .. code-block:: bash
-
- opendaylight-user@root>feature:list -i | grep aaa-encryption-service
- odl-aaa-encryption-service | 0.5.0-SNAPSHOT | x | odl-aaa-0.5.0-SNAPSHOT | OpenDaylight :: AAA :: Encryption Service
-
-2. The initial configuration of the Encryption Service exists under the
- distribution directory etc/opendaylight/datastore/initial/config/aaa-encrypt-service-config.xml
-
- .. code-block:: xml
-
- <aaa-encrypt-service-config xmlns="config:aaa:authn:encrypt:service:config">
- <encrypt-key/>
- <encrypt-salt/>
- <encrypt-method>PBKDF2WithHmacSHA1</encrypt-method>
- <encrypt-type>AES</encrypt-type>
- <encrypt-iteration-count>32768</encrypt-iteration-count>
- <encrypt-key-length>128</encrypt-key-length>
- <cipher-transforms>AES/CBC/PKCS5Padding</cipher-transforms>
- </aaa-encrypt-service-config>
-
- .. note::
-
- Both the initial encryption key and encryption salt become randomly generated
- when the *aaa-encryption-service* feature is installed.
-
-3. Finally the new configurations will take affect after restarting the
- distribution.
-
-Using the AAA Command Line Interface (CLI)
-------------------------------------------
-The AAA offers a CLI through the Karaf's console. This CLI allows the user to
-configure and use some of the functionalities provided by AAA.
-
-The AAA CLI exists under the **odl-aaa-cli** feature. This feature can be
-installed by executing the following command.
-
-::
-
- feature:install odl-aaa-cli
-
-To check that the installation of the feature succeeded type "aaa" and press
-*tab* to see the list of available commands under the *aaa* scope.
-
-::
-
- opendaylight-user@root>aaa:
- aaa:add-domain aaa:add-grant aaa:add-role aaa:add-user
- aaa:change-user-pwd aaa:export-keystores aaa:gen-cert-req aaa:get-cipher-suites
- aaa:get-domains aaa:get-node-cert aaa:get-odl-cert aaa:get-roles
- aaa:get-tls-protocols aaa:get-users aaa:import-keystores aaa:remove-domain
- aaa:remove-grant aaa:remove-role aaa:remove-user
-
-Add a User
-^^^^^^^^^^
-
-The *add-user* command allows for adding an OpenDaylight user. The following
-user parameters can be specified.
-
-::
-
- aaa:add-user --name <user name>
- --roleName <role>
- --userDescription <user description>
- --email <user email>
- --domainName <domain name>
-
-List available Users
-^^^^^^^^^^^^^^^^^^^^
-
-The *get-users* command list all the available users within the Controller.
-
-::
-
- aaa:get-users
-
- user
- admin
-
-Remove a User
-^^^^^^^^^^^^^
-
-The *remove-user* command allows for removing an OpenDaylight user. The command
-needs the user name as parameter.
-
-::
-
- aaa:remove-user --name <user name>
-
-Change the OpenDaylight user password
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The *change-user-pwd* command allows for changing the OpenDaylight user's
-password. It takes the user name as argument then will ask for the given user
-current password.
-
-::
-
- aaa:change-user-pwd -user admin
- Enter current password:
- Enter new password:
- admin's password has been changed
-
-Add a Role
-^^^^^^^^^^
-
-The *add-role* command allows for adding a role to the Controller.
-
-::
-
- aaa:add-role --name <role name>
- --desc <role description>
- --domainName <domain name>
-
-List available Roles
-^^^^^^^^^^^^^^^^^^^^
-
-The *get-roles* command list all the available roles within the controller.
-
-::
-
- aaa:get-roles
-
- user
- admin
-
-Remove a Role
-^^^^^^^^^^^^^
-
-The *remove-role* command allows for removing an OpenDaylight role. The command
-needs the role name as parameter. The role will be removed from those users who
-have it.
-
-::
-
- aaa:remove-role --name <role name>
-
-Add a Domain
-^^^^^^^^^^^^
-
-The *add-domain* command allows for adding a domain to the Controller.
-
-::
-
- aaa:add-domain --name <domain name>
- --desc <domain description>
-
-List available Domains
-^^^^^^^^^^^^^^^^^^^^^^
-
-The *get-domains* command list all the available domains within the controller.
-The system asks for the administrator credentials to execute this command.
-
-::
-
- aaa:get-domains
-
- sdn
-
-Remove a Domain
-^^^^^^^^^^^^^^^
-
-The *remove-domain* command allows for removing an OpenDaylight role. The command
-needs the domain name as parameter.
-
-::
-
- aaa:remove-domain --name <domain name>
-
-Add a Grant
-^^^^^^^^^^^
-
-The *add-grant* command allows for creating a grant for an existing user. The
-command returns a grant id for that user.
-
-::
-
- aaa:add-grant --userName <user name>
- --domainName <domain name>
- --roleName <role name>
-
-Remove a Grant
-^^^^^^^^^^^^^^
-
-The *remove-grant* command allows for removing an OpenDaylight grant. This command
-needs the user name, domain and and role as parameters.
-
-::
-
- aaa:remove-grant --userName <user name>
- --domainName <domain name>
- --roleName <role name>
-
-Generate Certificate Request
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Generate certificate request command will generate a certificate request based
-on the generated OpenDaylight keystore and print it on the Karaf CLI. The system
-asks for the keystore password.
-
-::
-
- aaa:gen-cert-req
-
- -----BEGIN CERTIFICATE REQUEST-----
- MIIBlzCCAQACAQAwWTELMAkGA1UEBhMCQ0ExFDASBgNVBAcMC1FDIE1vbnRyZWFsMRgwFgYDVQQKDA
- 9MaW51eEZvdW5kYXRpb24xDDAKBgNVBAsMA0RldjEMMAoGA1UEAwwDT0RMMIGfMA0GCSqGSIb3DQEB
- AQUAA4GNADCBiQKBgQCCmLW6j+JLYJM5yAMwscw/CHqPnp5elPa1YtQsHKEAvp1I+mLVtHKZeXeteA
- kyp6ORxw6KQ515fcDyQVrRJiSM15jUd27UaFq5ku0+qJeG+Qh2btx+cvNSE7/+cgUWWosKz4Aff5F5
- FqR62jLUTNzqCvoaTbZaOnLYVq+O2dYyZwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBADhDr4Jm7gVm/o
- p861/FShyw1ZZscxOEl2TprJZiTO6sn3sLptQZv8v52Z+Jm5dAgr7L46c97Xfa+0j6Y4LXNb0f88lL
- RG8PxGbk6Tqbjqc0WS+U1Ibc/rcPK4HEN/bcYCn+Na1gLBaFXUPg08ozG6MwqFNeS5Z0jz1W0D9/oiao
- -----END CERTIFICATE REQUEST-----
-
-Get OpenDaylight Certificate
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The *get-odl-certificate* command will print the OpenDaylight certificate at the
-Karaf CLI. The system asks for the keystore password.
-
-::
-
- aaa:get-odl-cert -storepass <store_password>
-
- -----BEGIN CERTIFICATE-----
- MIICKTCCAZKgAwIBAgIEI75RWDANBgkqhkiG9w0BAQUFADBZMQwwCgYDVQQDDANPREwxDDAKBgNVBA
- sMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVhbDELMAkG
- A1UEBhMCQ0EwHhcNMTYxMTMwMTYyNDE3WhcNMTcxMTMwMTYyNDE3WjBZMQwwCgYDVQQDDANPREwxDD
- AKBgNVBAsMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVh
- bDELMAkGA1UEBhMCQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAIKYtbqP4ktgkznIAzCxzD
- 8Ieo+enl6U9rVi1CwcoQC+nUj6YtW0cpl5d614CTKno5HHDopDnXl9wPJBWtEmJIzXmNR3btRoWrmS
- 7T6ol4b5CHZu3H5y81ITv/5yBRZaiwrPgB9/kXkWpHraMtRM3OoK+hpNtlo6cthWr47Z1jJnAgMBAA
- EwDQYJKoZIhvcNAQEFBQADgYEAL9DK/P/yEBre3Mg3bICAUAvSvZic+ydDmigWLsY4J3UzKdV2f1jI
- s+rQTEgtlHShBf/ed546D49cp3XEzYrcxgILhGXDziCrUK0K1TiYqPTp6FLijjdydGlPpwuMyyV5Y0
- iDiRclWuPz2fHbs8WQOWNs6VQ+WaREXtEsEC4qgSo=
- -----END CERTIFICATE-----
-
-Get Cipher Suites
-^^^^^^^^^^^^^^^^^
-
-The *get-cipher-suites* command shows the cipher suites supported by the
-JVM used by the OpenDaylight controller in TLS communication. For example, here
-are the `Default Ciphers Suites in JDK 8 <http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites>`_.
-
-::
-
- aaa:get-cipher-suites
-
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
-
-Get TLS Protocols
-^^^^^^^^^^^^^^^^^
-
-The *get-tls-protocols* command shows the TLS protocols supported by the
-JVM used by the OpenDaylight controller. For example, the JDK 8 supports the
-following TLS protocols: TLSv1.2 (default), TLSv1.1, TLSv1 and SSLv3.
-
-::
-
- aaa:get-tls-protocols
-
- TLS_KRB5_WITH_RC4_128_SHA
- TLS_KRB5_WITH_RC4_128_MD5
- TLS_KRB5_WITH_3DES_EDE_CBC_SHA
- TLS_KRB5_WITH_3DES_EDE_CBC_MD5
- TLS_KRB5_WITH_DES_CBC_SHA
-
-Get Node Certificate
-^^^^^^^^^^^^^^^^^^^^
-
-The *get-node-cert* command prints a certificate for a given network node alias.
-This command is useful to check if the network node certificate has been added
-properly to the truest keystore. It takes the certificate alias as arguments.
-
-::
-
- aaa:get-node-cert -alias ovs1
- -----BEGIN CERTIFICATE-----
- MIICKTCCAZKgAwIBAgIEI75RWDANBgkqhkiG9w0BAQUFADBZMQwwCgYDVQQDDANPREwxDDAKBgNVBA
- sMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVhbDELMAkG
- A1UEBhMCQ0EwHhcNMTYxMTMwMTYyNDE3WhcNMTcxMTMwMTYyNDE3WjBZMQwwCgYDVQQDDANPREwxDD
- AKBgNVBAsMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVh
- bDELMAkGA1UEBhMCQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAIKYtbqP4ktgkznIAzCxzD
- 8Ieo+enl6U9rVi1CwcoQC+nUj6YtW0cpl5d614CTKno5HHDopDnXl9wPJBWtEmJIzXmNR3btRoWrmS
- 7T6ol4b5CHZu3H5y81ITv/5yBRZaiwrPgB9/kXkWpHraMtRM3OoK+hpNtlo6cthWr47Z1jJnAgMBAA
- EwDQYJKoZIhvcNAQEFBQADgYEAL9DK/P/yEBre3Mg3bICAUAvSvZic+ydDmigWLsY4J3UzKdV2f1jI
- s+rQTEgtlHShBf/ed546D49cp3XEzYrcxgILhGXDziCrUK0K1TiYqPTp6FLijjdydGlPpwuMyyV5Y0
- iDiRclWuPz2fHbs8WQOWNs6VQ+WaREXtEsEC4qgSo=
- -----END CERTIFICATE-----
-
-Export Keystores
-^^^^^^^^^^^^^^^^
-
-The *export-keystores* command exports the default MD-SAL Keystores to .jks
-files in the default directory for keystores (configuration/ssl/).
-
-::
-
- aaa:export-keystores
-
- Default directory for keystores is configuration/ssl/
-
-Import Keystores
-^^^^^^^^^^^^^^^^
-
-The *import-keystores* command imports the default MD-SAL Keystores. The
-keystores (odl and trust) should exist under default SSL directory
-(configuration/ssl/).
-
-.. code-block:: bash
-
- aaa:import-keystores --trustKeystoreName <name of the trust keystore>
- --trustKeystorePwd <password for the trust keystore>
- --odlKeystoreName <name of the ODL keystore>
- --odlKeystorePwd <password for the ODL keystore>
- --odlKeystoreAlias <alias of the ODL keystore>
- --tlsProtocols <list of TLS protocols separated by ','>
- --cipherSuites <list of Cipher suites separated by ','>
-
-.. warning::
-
- It is strongly recommended to run the history clear command after you execute
- all the AAA CLI commands so Karaf logs stay clean from any adversary.
-
- ::
-
- history -c
+++ /dev/null
-.. _bgp-user-guide-additional-path-capability:
-
-Additional Path Capability
-==========================
-The ADD-PATH capability allows to advertise multiple paths for the same address prefix.
-It can help with optimal routing and routing convergence in a network by providing potential alternate or backup paths.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-This section shows a way to enable ADD-PATH capability in BGP speaker and peer configuration.
-
-.. note:: The capability is applicable for IP Unicast, IP Labeled Unicast and Flow Specification address families.
-
-BGP Speaker
-'''''''''''
-To enable ADD-PATH capability in BGP plugin, first configure BGP speaker instance:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 14
-
- <protocol xmlns="http://openconfig.net/yang/network-instance">
- <name>bgp-example</name>
- <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
- <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <global>
- <config>
- <router-id>192.0.2.2</router-id>
- <as>65000</as>
- </config>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
- <receive>true</receive>
- <send-max>2</send-max>
- </afi-safi>
- </afi-safis>
- </global>
- </bgp>
- </protocol>
-
-@line 14: Defines path selection strategy: *send-max* > 1 -> Advertise N Paths or *send-max* = 0 -> Advertise All Paths
-
-Here is an example for update a specific family with enable ADD-PATH capability
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/global/afi-safis/afi-safi/openconfig-bgp-types:IPV4%2DUNICAST``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <afi-safi xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
- <receive>true</receive>
- <send-max>0</send-max>
- </afi-safi>
-
-BGP Peer
-''''''''
-Here is an example for BGP peer configuration with enabled ADD-PATH capability.
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.1</neighbor-address>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-LABELLED-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
- <receive>true</receive>
- <send-max>0</send-max>
- </afi-safi>
- </afi-safis>
- </neighbor>
-
-.. note:: The path selection strategy is not configurable on per peer basis. The send-max presence indicates a willingness to send ADD-PATH NLRIs to the neighbor.
-
-Here is an example for update specific family BGP peer configuration with enabled ADD-PATH capability.
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors/neighbor/192.0.2.1/afi-safis/afi-safi/openconfig-bgp-types:IPV4%2DUNICAST``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <afi-safi xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
- <receive>true</receive>
- <send-max>0</send-max>
- </afi-safi>
-
-Usage
-^^^^^
-The IPv4 Unicast table with enabled ADD-PATH capability in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv4-route>
- <path-id>1</path-id>
- <prefix>193.0.2.1/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.0.0.1</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
- <ipv4-route>
- <path-id>2</path-id>
- <prefix>193.0.2.1/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.0.0.2</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
- </ipv4-routes>
-
-@line 3: The routes with the same destination are distinguished by *path-id* attribute.
-
-References
-^^^^^^^^^^
-* `Advertisement of Multiple Paths in BGP <https://tools.ietf.org/html/rfc7911>`_
-* `Best Practices for Advertisement of Multiple Paths in IBGP <https://tools.ietf.org/html/draft-ietf-idr-add-paths-guidelines-08>`_
+++ /dev/null
-.. _bgp-user-guide-bgp-application-peer:
-
-BGP Application Peer and programmable RIB
-=========================================
-The OpenDaylight BGP implementation also supports routes injection via *Application Peer*.
-Such peer has its own programmable RIB, which can be modified by user.
-This concept allows user to originate new routes and advertise them to all connected peers.
-
-Application Peer configuration
-''''''''''''''''''''''''''''''
-Following configuration sample show a way to configure the *Application Peer*:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,4
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>10.25.1.9</neighbor-address>
- <config>
- <peer-group>application-peers</peer-group>
- </config>
- </neighbor>
-
-@line 2: IP address is uniquely identifying *Application Peer* and its programmable RIB. Address is also used in local BGP speaker decision process.
-
-@line 4: Indicates that peer is associated with *application-peers* group. It serves to distinguish *Application Peer's* from regular neighbors.
-
------
-
-The *Application Peer* presence can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/peer/bgp:%2F%2F10.25.1.9``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,8
-
- <peer xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
- <peer-id>bgp://10.25.1.9</peer-id>
- <peer-role>internal</peer-role>
- <adj-rib-in>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet"></ipv4-routes>
- <attributes>
- <uptodate>false</uptodate>
- </attributes>
- </tables>
- </adj-rib-in>
- <effective-rib-in>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet"></ipv4-routes>
- <attributes></attributes>
- </tables>
- </effective-rib-in>
- </peer>
-
-@line 3: Peer role for *Application Peer* is *internal*.
-
-@line 8: Adj-RIB-In is empty, as no routes were originated yet.
-
-.. note:: There is no Adj-RIB-Out for *Application Peer*.
-
-Programmable RIB
-''''''''''''''''
-Next example shows how to inject a route into the programmable RIB.
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <ipv4-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <path-id>0</path-id>
- <prefix>10.0.0.11/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.11.1.1</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
-
------
-
-Now the injected route appears in *Application Peer's* RIBs and in local speaker's Loc-RIB:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/peer/bgp:%2F%2F10.25.1.9``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 9
-
- <peer xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
- <peer-id>bgp://10.25.1.9</peer-id>
- <peer-role>internal</peer-role>
- <adj-rib-in>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv4-route>
- <path-id>0</path-id>
- <prefix>10.0.0.11/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.11.1.1</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
- </ipv4-routes>
- <attributes>
- <uptodate>false</uptodate>
- </attributes>
- </tables>
- </adj-rib-in>
- <effective-rib-in>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv4-route>
- <path-id>0</path-id>
- <prefix>10.0.0.11/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.11.1.1</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
- </ipv4-routes>
- <attributes></attributes>
- </tables>
- </effective-rib-in>
- </peer>
-
-@line 9: Injected route is present in *Application Peer's* Adj-RIB-In and Effective-RIB-In.
-
------
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2
-
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv4-route>
- <path-id>0</path-id>
- <prefix>10.0.0.10/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.11.1.1</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
- <ipv4-route>
- <path-id>0</path-id>
- <prefix>10.0.0.10/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.10.1.1</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
- </ipv4-routes>
-
-@line 2: The injected route is now present in Loc-RIB along with a route (destination *10.0.0.10/32*) advertised by remote peer.
-
------
-
-This route is also advertised to the remote peer (*192.0.2.1*), hence route appears in its Adj-RIB-Out:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/peer/bgp:%2F%2F192.0.2.1/adj-rib-out/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <ipv4-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <path-id>0</path-id>
- <prefix>10.0.0.11/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.11.1.1</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
-
------
-
-The injected route can be modified (i.e. different path attribute):
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/ipv4-route/10.0.0.11%2F32/0``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <ipv4-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <path-id>0</path-id>
- <prefix>10.0.0.11/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>50</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.11.1.2</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
-
------
-
-The route can be removed from programmable RIB in a following way:
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/ipv4-route/10.0.0.11%2F32/0``
-
-**Method:** ``DELETE``
-
------
-
-Also it is possible to remove all routes from a particular table at once:
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/``
-
-**Method:** ``DELETE``
-
------
-
-Consequently, route disappears from programmable RIB, *Application Peer's* RIBs, Loc-RIB and peer's Adj-RIB-Out (UPDATE message with prefix withdrawal is send).
-
-.. note:: Routes stored in programmable RIB are persisted on OpendDaylight shutdown and restored after the re-start.
+++ /dev/null
-.. _bgp-user-guide-bgp-peering:
-
-BGP Peering
-===========
-To exchange routing information between two BGP systems (peers), it is required to configure a peering on both BGP speakers first.
-This mean that each BGP speaker has a white list of neighbors, representing remote peers, with which the peering is allowed.
-The TCP connection is established between two peers and they exchange messages to open and confirm the connection parameters followed by routes exchange.
-
-Here is a sample basic neighbor configuration:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,5,6,11,12,17,19
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.1</neighbor-address>
- <timers>
- <config>
- <hold-time>90</hold-time>
- <connect-retry>10</connect-retry>
- </config>
- </timers>
- <transport>
- <config>
- <remote-port>179</remote-port>
- <passive-mode>false</passive-mode>
- <!--<local-address>192.0.2.5</local-address>-->
- </config>
- </transport>
- <config>
- <peer-type>INTERNAL</peer-type>
- </config>
- <afi-safis>
- ...
- </afi-safis>
- </neighbor>
-
-@line 2: IP address of the remote BGP peer. Also serves as an unique identifier of a neighbor in a list of neighbors.
-
-@line 5: Proposed number of seconds for value of the Hold Timer. Default value is **90**.
-
-@line 6: Time interval in seconds between attempts to establish session with the peer. Effective in active mode only. Default value is **30**.
-
-@line 11: Remote port number to which the local BGP is connecting. Effective in active mode only. Default value **179**.
-
-@line 12: Wait for peers to issue requests to open a BGP session, rather than initiating sessions from the local router. Default value is **false**.
-
-@line 13: Optional Local IP (either IPv4 or IPv6) address used to establish connections to the remote peer. Effective in active mode only.
-
-@line 17: Explicitly designate the peer as internal or external. Default value is **INTERNAL**.
-
-@line 19: Enable families.
-
------
-
-Once the remote peer is connected and it advertised routes to local BGP system, routes are stored in peer's RIBs.
-The RIBs can be checked via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/peer/bgp:%2F%2F192.0.2.1``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 8,13,35,40,62,66
-
- <peer xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
- <peer-id>bgp://192.0.2.1</peer-id>
- <supported-tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- </supported-tables>
- <peer-role>ibgp</peer-role>
- <adj-rib-in>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv4-route>
- <path-id>0</path-id>
- <prefix>10.0.0.10/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.10.1.1</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
- </ipv4-routes>
- <attributes>
- <uptodate>true</uptodate>
- </attributes>
- </tables>
- </adj-rib-in>
- <effective-rib-in>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv4-route>
- <path-id>0</path-id>
- <prefix>10.0.0.10/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.10.1.1</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
- </ipv4-routes>
- <attributes>
- <uptodate>true</uptodate>
- </attributes>
- </tables>
- </effective-rib-in>
- <adj-rib-out>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet"></ipv4-routes>
- <attributes></attributes>
- </tables>
- </adj-rib-out>
- </peer>
-
-@line 8: **Adj-RIB-In** - Per-peer RIB, which contains unprocessed routes that has been advertised to local BGP speaker by the remote peer.
-
-@line 13: Here is the reported route with destination *10.0.0.10/32* in Adj-RIB-In.
-
-@line 35: **Effective-RIB-In** - Per-peer RIB, which contains processed routes as a result of applying inbound policy to Adj-RIB-In routes.
-
-@line 40: Here is the reported route with destination *10.0.0.10/32*, same as in Adj-RIB-In, as it was not touched by import policy.
-
-@line 62: **Adj-RIB-Out** - Per-peer RIB, which contains routes for advertisement to the peer by means of the local speaker's UPDATE message.
-
-@line 66: The peer's Adj-RIB-Out is empty as there are no routes to be advertise from local BGP speaker.
-
------
-
-Also the same route should appeared in Loc-RIB now:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 4,6,8,11,14
-
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv4-route>
- <path-id>0</path-id>
- <prefix>10.0.0.10/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.10.1.1</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
- </ipv4-routes>
-
-@line 4: **Destination** - IPv4 Prefix Address.
-
-@line 6: **AS_PATH** - mandatory attribute, contains a list of the autonomous system numbers through that routing information has traversed.
-
-@line 8: **ORIGIN** - mandatory attribute, indicates an origin of the route - **ibgp**, **egp**, **incomplete**.
-
-@line 11: **LOCAL_PREF** - indicates a degree of preference for external routes, higher value is preferred.
-
-@line 14: **NEXT_HOP** - mandatory attribute, defines IP address of the router that should be used as the next hop to the destination.
-
------
-
-There are much more attributes that may be carried along with the destination:
-
-**BGP-4 Path Attributes**
-
-* **MULTI_EXIT_DISC** (MED)
- Optional attribute, to be used to discriminate among multiple exit/entry points on external links, lower number is preferred.
-
- .. code-block:: xml
-
- <multi-exit-disc>
- <med>0</med>
- </multi-exit-disc>
-
-
-* **ATOMIC_AGGREGATE**
- Indicates whether AS_SET was excluded from AS_PATH due to routes aggregation.
-
- .. code-block:: xml
-
- <atomic-aggregate/>
-
-* **AGGREGATOR**
- Optional attribute, contains AS number and IP address of a BGP speaker which performed routes aggregation.
-
- .. code-block:: xml
-
- <aggregator>
- <as-number>65000</as-number>
- <network-address>192.0.2.2</network-address>
- </aggregator>
-
-* **Unrecognised**
- Optional attribute, used to store optional attributes, unrecognized by a local BGP speaker.
-
- .. code-block:: xml
-
- <unrecognized-attributes>
- <partial>true</partial>
- <transitive>true</transitive>
- <type>101</type>
- <value>0101010101010101</value>
- </unrecognized-attributes>
-
-**Route Reflector Attributes**
-
-* **ORIGINATOR_ID**
- Optional attribute, carries BGP Identifier of the originator of the route.
-
- .. code-block:: xml
-
- <originator-id>
- <originator>41.41.41.41</originator>
- </originator-id>
-
-* **CLUSTER_LIST**
- Optional attribute, contains a list of CLUSTER_ID values representing the path that the route has traversed.
-
- .. code-block:: xml
-
- <cluster-id>
- <cluster>40.40.40.40</cluster>
- </cluster-id>
-
-* **Communities**
- Optional attribute, may be used for policy routing.
-
- .. code-block:: xml
-
- <communities>
- <as-number>65000</as-number>
- <semantics>30740</semantics>
- </communities>
-
-**Extended Communities**
-
-* **Route Target**
- Identifies one or more routers that may receive a route.
-
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <route-target-ipv4>
- <global-administrator>192.0.2.2</global-administrator>
- <local-administrator>123</local-administrator>
- </route-target-ipv4>
- </extended-communities>
- <extended-communities>
- <transitive>true</transitive>
- <as-4-route-target-extended-community>
- <as-4-specific-common>
- <as-number>65000</as-number>
- <local-administrator>123</local-administrator>
- </as-4-specific-common>
- </as-4-route-target-extended-community>
- </extended-communities>
-
-
-* **Route Origin**
- Identifies one or more routers that injected a route.
-
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <route-origin-ipv4>
- <global-administrator>192.0.2.2</global-administrator>
- <local-administrator>123</local-administrator>
- </route-origin-ipv4>
- </extended-communities>
- <extended-communities>
- <transitive>true</transitive>
- <as-4-route-origin-extended-community>
- <as-4-specific-common>
- <as-number>65000</as-number>
- <local-administrator>123</local-administrator>
- </as-4-origin-common>
- </as-4-route-target-extended-community>
- </extended-communities>
-
-
-* **Link Bandwidth**
- Carries the cost to reach external neighbor.
-
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <link-bandwidth-extended-community>
- <bandwidth>BH9CQAA=</bandwidth>
- </link-bandwidth-extended-community>
- </extended-communities>
-
-* **AIGP**
- Optional attribute, carries accumulated IGP metric.
-
- .. code-block:: xml
-
- <aigp>
- <aigp-tlv>
- <metric>120</metric>
- </aigp-tlv>
- </aigp>
-
-
-.. note:: When the remote peer disconnects, it disappear from operational state of local speaker instance and advertised routes are removed too.
-
-External peering configuration
-''''''''''''''''''''''''''''''
-An example above provided configuration for internal peering only.
-Following configuration sample is intended for external peering:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 5
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.3</neighbor-address>
- <config>
- <peer-type>EXTERNAL</peer-type>
- <peer-as>64999</peer-as>
- </config>
- </neighbor>
-
-@line 5: AS number of the remote peer.
-
-Local AS
-''''''''
-
-.. figure:: ./images/local-as.png
- :alt: BGP eBGP with Local AS setup.
-
-The local-AS feature allows a router(eBGP) to appear to be a member of a second autonomous system (AS), in addition to its real AS.
-
-In above figure, R3 is eBGP router with configured local-as of 62, and peer-as of 63.
-
-In updates sent from R3 to R2, the AS_SEQUENCE in the AS_PATH attribute contains "62 63". And updates sent from R2 to R3, the AS_SEQUENCE in the AS_PATH attribute contains "62 65".
-
-AS 62 will be prepended to updates that are sent to and received from R3.
-
-Following configuration sample is intended for external peering with Local AS:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 5,6
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.3</neighbor-address>
- <config>
- <peer-type>EXTERNAL</peer-type>
- <peer-as>63</peer-as>
- <local-as>62</local-as>
- </config>
- </neighbor>
-
-@line 5: AS number of the remote peer.
-
-@line 6: Local AS number of the remote peer.
-
-Route reflector configuration
-'''''''''''''''''''''''''''''
-The local BGP speaker can be configured with a specific *cluster ID*.
-Following example adds the cluster ID to the existing speaker instance:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/global/config``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 4
-
- <config>
- <router-id>192.0.2.2</router-id>
- <as>65000</as>
- <route-reflector-cluster-id>192.0.2.1</route-reflector-cluster-id>
- </config>
-
-@line 4: Route-reflector cluster id to use when local router is configured as a route reflector.
- The *router-id* is used as a default value.
-
------
-
-Following configuration sample is intended for route reflector client peering:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 8
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.4</neighbor-address>
- <config>
- <peer-type>INTERNAL</peer-type>
- </config>
- <route-reflector>
- <config>
- <route-reflector-client>true</route-reflector-client>
- </config>
- </route-reflector>
- </neighbor>
-
-@line 8: Configure the neighbor as a route reflector client. Default value is *false*.
-
-Route reflector and Multiple Cluster IDs
-''''''''''''''''''''''''''''''''''''''''
-
-An optional non-transitive attribute called CLUSTER_LIST is modified when a route reflector reflects a prefix.
-For loop prevention the route reflector adds its own cluster ID to, and discards any update containing router's own cluster ID.
-Using multiple cluster IDs allows updates to propagate to nodes that reside in a different cluster.
-
-
-.. figure:: ./images/MultipleClustersIds.png
- :alt: BGP RR Multiple Cluster IDs setup.
-
-Following configuration sample is intended for route reflector client peering using specific cluster id:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 8,9
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.4</neighbor-address>
- <config>
- <peer-type>INTERNAL</peer-type>
- </config>
- <route-reflector>
- <config>
- <route-reflector-client>true</route-reflector-client>
- <route-reflector-cluster-id>192.0.2.4</route-reflector-cluster-id>
- </config>
- </route-reflector>
- </neighbor>
-
-@line 8: Configure the neighbor as a route reflector client. Default value is *false*.
-
-@line 9: Route-reflector cluster id to use for this specific neighbor when local router is configured as a route reflector.
-
-MD5 authentication configuration
-''''''''''''''''''''''''''''''''
-The OpenDaylight BGP implementation is supporting TCP MD5 for authentication.
-Sample configuration below shows how to set authentication password for a peer:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 4
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.5</neighbor-address>
- <config>
- <auth-password>topsecret</auth-password>
- </config>
- </neighbor>
-
-@line 4: Configures an MD5 authentication password for use with neighboring devices.
-
-BGP Peer Group
-''''''''''''''
-
-Allows the creation of a peer group configuration that applies to all peers configured as part of the group.
-
-A sample peer group configuration follows:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/peer-groups``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2
-
- <peer-group xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <peer-group-name>internal-neighbor</peer-group-name>
- <config>
- <peer-type>INTERNAL</peer-type>
- <peer-as>64496</peer-as>
- </config>
- <transport>
- <config>
- <remote-port>179</remote-port>
- <passive-mode>true</passive-mode>
- </config>
- </transport>
- <timers>
- <config>
- <hold-time>180</hold-time>
- <connect-retry>10</connect-retry>
- </config>
- </timers>
- <route-reflector>
- <config>
- <route-reflector-client>false</route-reflector-client>
- </config>
- </route-reflector>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
- <!--Advertise N Paths
- <receive>true</receive>
- <send-max>0</send-max>-->
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-LABELLED-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-LABELLED-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV4-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV6-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L2VPN-EVPN</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>LINKSTATE</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV4-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV6-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV4-L3VPN-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV6-L3VPN-FLOW</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </peer-group>
-
-@line 2: Peer Group Identifier.
-
------
-
-A sample basic neighbor configuration using a peer group follows:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 4
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.1</neighbor-address>
- <config>
- <peer-group>/bgp/neighbors/neighbor/bgp/peer-groups/peer-group[peer-group-name="internal-neighbor"]</peer-group>
- </config>
- </neighbor>
-
-@line 4: Peer group identifier.
-
-.. note:: Existing neighbor configuration can be reconfigured (change configuration parameters) anytime.
- As a result, established connection is dropped, peer instance is recreated with a new configuration settings and connection re-established.
-
-.. note:: The BGP configuration is persisted on OpendDaylight shutdown and restored after the re-start.
+++ /dev/null
-.. _bgp-user-guide-bgp-server:
-
-BGP Server
-==========
-
-BGP uses TCP as its transport protocol, by default listens on port 179. OpenDaylight BGP plugin is configured to listen on port *1790*, due to
-privileged ports restriction for non-root users.
-One of the workarounds is to use port redirection. In case other port is desired to be used instead, we can reconfigure it.
-
-Here is a sample of bgp port listening re-configuration:
-
-**URL:** ``/restconf/config/odl-bgp-peer-acceptor-config:bgp-peer-acceptor-config/default``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,4
-
- <bgp-peer-acceptor-config xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-peer-acceptor-config">
- <config-name>default</config-name>
- <binding-address>0.0.0.0</binding-address>
- <binding-port>1791</binding-port>
- </bgp-peer-acceptor-config>
-
-@line 3: Binding address: By default is 0.0.0.0, so it is not a mandatory field.
-
-@line 4: Binding Port: Port were BGP Server will listen.
+++ /dev/null
-.. _bgp-user-guide-config-concepts:
-
-Basic Configuration & Concepts
-==============================
-The following section shows how to configure BGP basics, how to verify functionality and presents essential components of the plugin.
-Next samples demonstrate the plugin's runtime configuration capability.
-It shows the way to configure the plugin via REST, using standardized OpenConfig BGP APIs.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-.. toctree::
- :maxdepth: 2
-
- bgp-user-guide-protocol-configuration
- bgp-user-guide-rib-config-policies
- bgp-user-guide-bgp-server
- bgp-user-guide-bgp-peering
- bgp-user-guide-bgp-application-peer
- bgp-user-guide-protocol-configuration-loader
-
-BGP RIB API
-^^^^^^^^^^^
-This tree illustrates the BGP RIBs organization in datastore.
-
-.. code-block:: console
-
- bgp-rib
- +--ro rib* [id]
- +--ro id rib-id
- +--ro peer* [peer-id]
- | +--ro peer-id peer-id
- | +--ro peer-role peer-role
- | +--ro simple-routing-policy? simple-routing-policy
- | +--ro supported-tables* [afi safi]
- | | +--ro afi identityref
- | | +--ro safi identityref
- | | +--ro send-receive? send-receive
- | +--ro adj-rib-in
- | | +--ro tables* [afi safi]
- | | +--ro afi identityref
- | | +--ro safi identityref
- | | +--ro attributes
- | | | +--ro uptodate? boolean
- | | +--ro (routes)?
- | +--ro effective-rib-in
- | | +--ro tables* [afi safi]
- | | +--ro afi identityref
- | | +--ro safi identityref
- | | +--ro attributes
- | | | +--ro uptodate? boolean
- | | +--ro (routes)?
- | +--ro adj-rib-out
- | +--ro tables* [afi safi]
- | +--ro afi identityref
- | +--ro safi identityref
- | +--ro attributes
- | | +--ro uptodate? boolean
- | +--ro (routes)?
- +--ro loc-rib
- +--ro tables* [afi safi]
- +--ro afi identityref
- +--ro safi identityref
- +--ro attributes
- | +--ro uptodate? boolean
- +--ro (routes)?
-
-BGP pipeline
-^^^^^^^^^^^^
-.. figure:: ./images/bgp-pipeline.png
- :alt: BGP pipeline.
-
- BGP pipeline - routes re-advertisement.
-
-.. figure:: ./images/bgp-app-pipeline.png
- :alt: BGP Application Peer pipeline.
-
- BGP applcaition peer pipeline - routes injection.
-
-References
-^^^^^^^^^^
-* `A Border Gateway Protocol 4 (BGP-4) <https://tools.ietf.org/html/rfc4271>`_
-* `BGP Route Reflection <https://tools.ietf.org/html/rfc4456>`_
-* `BGP Communities Attribute <https://tools.ietf.org/html/rfc1997>`_
-* `BGP Support for Four-Octet Autonomous System (AS) Number Space <https://tools.ietf.org/html/rfc6793>`_
-* `The Accumulated IGP Metric Attribute for BGP <https://tools.ietf.org/html/rfc7311>`_
-* `4-Octet AS Specific BGP Extended Community <https://tools.ietf.org/html/rfc5668>`_
-* `BGP Link Bandwidth Extended Community <https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-06>`_
-* `Use of BGP for Routing in Large-Scale Data Centers <https://tools.ietf.org/html/rfc7938>`_
+++ /dev/null
-.. _bgp-user-guide-evpn-family:
-
-EVPN Family
-===========
-The BGP MPLS-Based Ethernet VPN (BGP EVPN) Multiprotocol extension can be used to distribute Ethernet L2VPN service related routes in order to support a concept of MAC routing.
-A major use-case for BGP EVPN is data-center interconnection (DCI), where advantage of BGP EVPN are MAC/IP address advertising across MPLS network, Multihoming functionality including Fast Convergence, Split Horizon and Aliasing support, VM (MAC) Mobility, support Multicast and Broadcast traffic.
-In addition to MPLS, IP tunnelling encapsulation techniques like VXLAN, NVGRE, MPLSoGRE and others can be used for packet transportation.
-Also, Provider Backbone Bridging (PBB) can be combined with EVPN in order to reduce a number of MAC Advertisement routes.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-This section shows a way to enable EVPN family in BGP speaker and peer configuration.
-
-BGP Speaker
-'''''''''''
-To enable EVPN support in BGP plugin, first configure BGP speaker instance:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <protocol xmlns="http://openconfig.net/yang/network-instance">
- <name>bgp-example</name>
- <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
- <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <global>
- <config>
- <router-id>192.0.2.2</router-id>
- <as>65000</as>
- </config>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L2VPN-EVPN</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </global>
- </bgp>
- </protocol>
-
-BGP Peer
-''''''''
-Here is an example for BGP peer configuration with enabled EVPN family.
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.1</neighbor-address>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L2VPN-EVPN</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </neighbor>
-
-EVPN Route API
-^^^^^^^^^^^^^^
-Following tree illustrate the BGP EVPN route structure.
-
-.. code-block:: console
-
- :(evpn-routes-case)
- +--ro evpn-routes
- +--ro evpn-route* [route-key path-id]
- +--ro route-key string
- +--ro path-id path-id
- +--ro (evpn-choice)
- | +--:(ethernet-a-d-route-case)
- | | +--ro ethernet-a-d-route
- | | +--ro (esi)
- | | | +--:(arbitrary-case)
- | | | | +--ro arbitrary
- | | | | +--ro arbitrary binary
- | | | +--:(lacp-auto-generated-case)
- | | | | +--ro lacp-auto-generated
- | | | | +--ro ce-lacp-mac-address yang:mac-address
- | | | | +--ro ce-lacp-port-key uint16
- | | | +--:(lan-auto-generated-case)
- | | | | +--ro lan-auto-generated
- | | | | +--ro root-bridge-mac-address yang:mac-address
- | | | | +--ro root-bridge-priority uint16
- | | | +--:(mac-auto-generated-case)
- | | | | +--ro mac-auto-generated
- | | | | +--ro system-mac-address yang:mac-address
- | | | | +--ro local-discriminator uint24
- | | | +--:(router-id-generated-case)
- | | | | +--ro router-id-generated
- | | | | +--ro router-id inet:ipv4-address
- | | | | +--ro local-discriminator uint32
- | | | +--:(as-generated-case)
- | | | +--ro as-generated
- | | | +--ro as inet:as-number
- | | | +--ro local-discriminator uint32
- | | +--ro ethernet-tag-id
- | | | +--ro vlan-id uint32
- | | +--ro mpls-label netc:mpls-label
- | +--:(mac-ip-adv-route-case)
- | | +--ro mac-ip-adv-route
- | | +--ro (esi)
- | | | +--:(arbitrary-case)
- | | | | +--ro arbitrary
- | | | | +--ro arbitrary binary
- | | | +--:(lacp-auto-generated-case)
- | | | | +--ro lacp-auto-generated
- | | | | +--ro ce-lacp-mac-address yang:mac-address
- | | | | +--ro ce-lacp-port-key uint16
- | | | +--:(lan-auto-generated-case)
- | | | | +--ro lan-auto-generated
- | | | | +--ro root-bridge-mac-address yang:mac-address
- | | | | +--ro root-bridge-priority uint16
- | | | +--:(mac-auto-generated-case)
- | | | | +--ro mac-auto-generated
- | | | | +--ro system-mac-address yang:mac-address
- | | | | +--ro local-discriminator uint24
- | | | +--:(router-id-generated-case)
- | | | | +--ro router-id-generated
- | | | | +--ro router-id inet:ipv4-address
- | | | | +--ro local-discriminator uint32
- | | | +--:(as-generated-case)
- | | | +--ro as-generated
- | | | +--ro as inet:as-number
- | | | +--ro local-discriminator uint32
- | | +--ro ethernet-tag-id
- | | | +--ro vlan-id uint32
- | | +--ro mac-address yang:mac-address
- | | +--ro ip-address? inet:ip-address
- | | +--ro mpls-label1 netc:mpls-label
- | | +--ro mpls-label2? netc:mpls-label
- | +--:(inc-multi-ethernet-tag-res-case)
- | | +--ro inc-multi-ethernet-tag-res
- | | +--ro ethernet-tag-id
- | | | +--ro vlan-id uint32
- | | +--ro orig-route-ip? inet:ip-address
- | +--:(es-route-case)
- | +--ro es-route
- | +--ro (esi)
- | | +--:(arbitrary-case)
- | | | +--ro arbitrary
- | | | +--ro arbitrary binary
- | | +--:(lacp-auto-generated-case)
- | | | +--ro lacp-auto-generated
- | | | +--ro ce-lacp-mac-address yang:mac-address
- | | | +--ro ce-lacp-port-key uint16
- | | +--:(lan-auto-generated-case)
- | | | +--ro lan-auto-generated
- | | | +--ro root-bridge-mac-address yang:mac-address
- | | | +--ro root-bridge-priority uint16
- | | +--:(mac-auto-generated-case)
- | | | +--ro mac-auto-generated
- | | | +--ro system-mac-address yang:mac-address
- | | | +--ro local-discriminator uint24
- | | +--:(router-id-generated-case)
- | | | +--ro router-id-generated
- | | | +--ro router-id inet:ipv4-address
- | | | +--ro local-discriminator uint32
- | | +--:(as-generated-case)
- | | +--ro as-generated
- | | +--ro as inet:as-number
- | | +--ro local-discriminator uint32
- | +--ro orig-route-ip inet:ip-address
- +--ro route-distinguisher bgp-t:route-distinguisher
- +--ro attributes
- +--ro extended-communities*
- | +--ro transitive? boolean
- | +--ro (extended-community)?
- | +--:(encapsulation-case)
- | | +--ro encapsulation-extended-community
- | | +--ro tunnel-type encapsulation-tunnel-type
- | +--:(esi-label-extended-community-case)
- | | +--ro esi-label-extended-community
- | | +--ro single-active-mode? boolean
- | | +--ro esi-label netc:mpls-label
- | +--:(es-import-route-extended-community-case)
- | | +--ro es-import-route-extended-community
- | | +--ro es-import yang:mac-address
- | +--:(mac-mobility-extended-community-case)
- | | +--ro mac-mobility-extended-community
- | | +--ro static? boolean
- | | +--ro seq-number uint32
- | +--:(default-gateway-extended-community-case)
- | | +--ro default-gateway-extended-community!
- | +--:(layer-2-attributes-extended-community-case)
- | +--ro layer-2-attributes-extended-community
- | +--ro primary-pe? boolean
- | +--ro backup-pe? boolean
- | +--ro control-word? boolean
- | +--ro l2-mtu uint16
- +--ro pmsi-tunnel!
- +--ro leaf-information-required boolean
- +--ro mpls-label? netc:mpls-label
- +--ro (tunnel-identifier)?
- +--:(rsvp-te-p2mp-lsp)
- | +--ro rsvp-te-p2mp-lps
- | +--ro p2mp-id uint32
- | +--ro tunnel-id uint16
- | +--ro extended-tunnel-id inet:ip-address
- +--:(mldp-p2mp-lsp)
- | +--ro mldp-p2mp-lsp
- | +--ro address-family identityref
- | +--ro root-node-address inet:ip-address
- | +--ro opaque-value*
- | +--ro opaque-type uint8
- | +--ro opaque-extended-type? uint16
- | +--ro opaque yang:hex-string
- +--:(pim-ssm-tree)
- | +--ro pim-ssm-tree
- | +--ro p-address inet:ip-address
- | +--ro p-multicast-group inet:ip-address
- +--:(pim-sm-tree)
- | +--ro pim-sm-tree
- | +--ro p-address inet:ip-address
- | +--ro p-multicast-group inet:ip-address
- +--:(bidir-pim-tree)
- | +--ro bidir-pim-tree
- | +--ro p-address inet:ip-address
- | +--ro p-multicast-group inet:ip-address
- +--:(ingress-replication)
- | +--ro ingress-replication
- | +--ro receiving-endpoint-address? inet:ip-address
- +--:(mldp-mp2mp-lsp)
- +--ro mldp-mp2mp-lsp
- +--ro opaque-type uint8
- +--ro opaque-extended-type? uint16
- +--ro opaque
- ...
-
-Usage
-^^^^^
-The L2VPN EVPN table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/odl-bgp-evpn:l2vpn-address-family/odl-bgp-evpn:evpn-subsequent-address-family/evpn-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <evpn-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-evpn">
- <evpn-route>
- <route-key>AxEAAcCoZAED6AAAAQAgwKhkAQ==</route-key>
- <path-id>0</path-id>
- <route-distinguisher>192.168.100.1:1000</route-distinguisher>
- <inc-multi-ethernet-tag-res>
- <ethernet-tag-id>
- <vlan-id>256</vlan-id>
- </ethernet-tag-id>
- <orig-route-ip>192.168.100.1</orig-route-ip>
- </inc-multi-ethernet-tag-res>
- <attributes>
- <ipv4-next-hop>
- <global>172.23.29.104</global>
- </ipv4-next-hop>
- <as-path/>
- <origin>
- <value>igp</value>
- </origin>
- <extended-communities>
- <extended-communities>
- <transitive>true</transitive>
- <route-target-extended-community>
- <global-administrator>65504</global-administrator>
- <local-administrator>AAAD6A==</local-administrator>
- </route-target-extended-community>
- </extended-communities>
- </extended-communities>
- <pmsi-tunnel>
- <leaf-information-required>true</leaf-information-required>
- <mpls-label>20024</mpls-label>
- <ingress-replication>
- <receiving-endpoint-address>192.168.100.1</receiving-endpoint-address>
- </ingress-replication>
- </pmsi-tunnel>
- </attributes>
- </evpn-route>
- </evpn-routes>
-
-Programming
-^^^^^^^^^^^
-This examples show how to originate and remove EVPN routes via programmable RIB.
-There are four different types of EVPN routes, and several extended communities.
-Routes can be used for variety of use-cases supported by BGP/MPLS EVPN, PBB EVPN and NVO EVPN.
-Make sure the *Application Peer* is configured first.
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/odl-bgp-evpn:l2vpn-address-family/odl-bgp-evpn:evpn-subsequent-address-family/odl-bgp-evpn:evpn-routes``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 4,5,15
-
- <evpn-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-evpn">
- <route-key>evpn</route-key>
- <path-id>0</path-id>
- <route-distinguisher>172.12.123.3:200</route-distinguisher>
- ....
- <attributes>
- <ipv4-next-hop>
- <global>199.20.166.41</global>
- </ipv4-next-hop>
- <as-path/>
- <origin>
- <value>igp</value>
- </origin>
- <extended-communities>
- ....
- </extended-communities>
- </attributes>
- </evpn-route>
-
-@line 4: Route Distinguisher (RD) - set to RD of the MAC-VRF advertising the NLRI, recommended format *<IP>:<VLAN_ID>*
-
-@line 5: One of the EVPN route must be set here.
-
-@line 15: In some cases, specific extended community presence is required. The route may carry one or more Route Target attributes.
-
------
-
-EVPN Routes
-^^^^^^^^^^^
-
-* **Ethernet AD per ESI**
- .. code-block:: xml
-
- <ethernet-a-d-route>
- <mpls-label>0</mpls-label>
- <ethernet-tag-id>
- <vlan-id>4294967295</vlan-id>
- </ethernet-tag-id>
- <arbitrary>
- <arbitrary>AAAAAAAAAAAA</arbitrary>
- </arbitrary>
- </ethernet-a-d-route>
-
-* **Ethernet AD per EVI**
- .. code-block:: xml
-
- <ethernet-a-d-route>
- <mpls-label>24001</mpls-label>
- <ethernet-tag-id>
- <vlan-id>2200</vlan-id>
- </ethernet-tag-id>
- <arbitrary>
- <arbitrary>AAAAAAAAAAAA</arbitrary>
- </arbitrary>
- </ethernet-a-d-route>
-
-* **MAC/IP Advertisement**
- .. code-block:: xml
-
- <mac-ip-adv-route>
- <arbitrary>
- <arbitrary>AAAAAAAAAAAA</arbitrary>
- </arbitrary>
- <ethernet-tag-id>
- <vlan-id>2100</vlan-id>
- </ethernet-tag-id>
- <mac-address>f2:0c:dd:80:9f:f7</mac-address>
- <ip-address>10.0.1.12</ip-address>
- <mpls-label1>299776</mpls-label1>
- </mac-ip-adv-route>
-
-
-* **Inclusive Multicast Ethernet Tag**
- .. code-block:: xml
-
- <inc-multi-ethernet-tag-res>
- <ethernet-tag-id>
- <vlan-id>2100</vlan-id>
- </ethernet-tag-id>
- <orig-route-ip>43.43.43.43</orig-route-ip>
- </inc-multi-ethernet-tag-res>
-
-* **Ethernet Segment**
- .. code-block:: xml
-
- <es-route>
- <orig-route-ip>43.43.43.43</orig-route-ip>
- <arbitrary>
- <arbitrary>AAAAAAAAAAAA</arbitrary>
- </arbitrary>
- </es-route>
-
-**EVPN Ethernet Segment Identifier (ESI):**
-
-* **Type 0**
- Indicates an arbitrary 9-octet ESI.
-
- .. code-block:: xml
-
- <arbitrary>
- <arbitrary>AAAAAAAAAAAA</arbitrary>
- </arbitrary>
-
-* **Type 1**
- IEEE 802.1AX LACP is used.
-
- .. code-block:: xml
-
- <lacp-auto-generated>
- <ce-lacp-mac-address>f2:0c:dd:80:9f:f7</ce-lacp-mac-address>
- <ce-lacp-port-key>22</ce-lacp-port-key>
- </lacp-auto-generated>
-
-* **Type 2**
- Indirectly connected hosts via a bridged LAN.
-
- .. code-block:: xml
-
- <lan-auto-generated>
- <root-bridge-mac-address>f2:0c:dd:80:9f:f7</root-bridge-mac-address>
- <root-bridge-priority>20</root-bridge-priority>
- </lan-auto-generated>
-
-* **Type 3**
- MAC-based ESI.
-
- .. code-block:: xml
-
- <mac-auto-generated>
- <system-mac-address>f2:0c:dd:80:9f:f7</system-mac-address>
- <local-discriminator>2000</local-discriminator>
- </mac-auto-generated>
-
-* **Type 4**
- Router-ID ESI
-
- .. code-block:: xml
-
- <router-id-generated>
- <router-id>43.43.43.43</router-id>
- <local-discriminator>2000</local-discriminator>
- </router-id-generated>
-
-* **Type 5**
- AS-based ESI
-
- .. code-block:: xml
-
- <as-generated>
- <as>16843009</as>
- <local-discriminator>2000</local-discriminator>
- </as-generated>
-
-**Attributes:**
-
-.. include:: bgp-user-guide-pmsi-attribute.rst
-
-**Extended Communities:**
-
-* **ESI Label Extended Community**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <esi-label-extended-community>
- <single-active-mode>false</single-active-mode>
- <esi-label>24001</esi-label>
- </esi-label-extended-community>
- </extended-communities>
-
-* **ES-Import Route Target**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <es-import-route-extended-community>
- <es-import>f2:0c:dd:80:9f:f7</es-import>
- </es-import-route-extended-community>
- </extended-communities>
-
-* **MAC Mobility Extended Community**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <mac-mobility-extended-community>
- <static>true</static>
- <seq-number>200</seq-number>
- </mac-mobility-extended-community>
- </extended-communities>
-
-* **Default Gateway Extended Community**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <default-gateway-extended-community>
- </default-gateway-extended-community>
- </extended-communities>
-
-* **EVPN Layer 2 attributes extended community**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>false</transitive>
- <layer-2-attributes-extended-community>
- <primary-pe>true</primary-pe>
- <backup-pe>true</backup-pe>
- <control-word >true</control-word>
- <l2-mtu>200</l2-mtu>
- </layer-2-attributes-extended-community>
- </extended-communities>
-
-* **BGP Encapsulation extended community**
- .. code-block:: xml
- :linenos:
- :emphasize-lines: 4
-
- <extended-communities>
- <transitive>false</transitive>
- <encapsulation-extended-community>
- <tunnel-type>vxlan</tunnel-type>
- </encapsulation-extended-community>
- </extended-communities>
-
- @line 4: `full list of tunnel types <http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types>`_
-
------
-
-To remove the route added above, following request can be used:
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/odl-bgp-evpn:l2vpn-address-family/odl-bgp-evpn:evpn-subsequent-address-family/odl-bgp-evpn:evpn-routes/evpn-route/evpn/0``
-
-**Method:** ``DELETE``
-
------
-
-.. table:: EVPN Routes Usage.
-
- +--------------------------------------+-----------------------------------------------------+-------------------------------------------+
- | EVN Route Type | Extended Communities | Usage |
- +======================================+=====================================================+===========================================+
- | **Ethernet Auto-discovery** | ESI Label, BGP EncapsulationEVPN Layer 2 attributes | Fast Convergence, Split Horizon, Aliasing |
- +--------------------------------------+-----------------------------------------------------+-------------------------------------------+
- | **MAC/IP Advertisement** | BGP Encapsulation, MAC Mobility, Default Gateway | MAC address reachability |
- +--------------------------------------+-----------------------------------------------------+-------------------------------------------+
- | **Inclusive Multicast Ethernet Tag** | PMSI Tunnel, BGP Encapsulation | Handling of Multi-destination traffic |
- +--------------------------------------+-----------------------------------------------------+-------------------------------------------+
- | **Ethernet Segment** | BGP Encapsulation, ES-Import Route Target | Designated Forwarder Election |
- +--------------------------------------+-----------------------------------------------------+-------------------------------------------+
-
-References
-^^^^^^^^^^
-* `BGP MPLS-Based Ethernet VPN <https://tools.ietf.org/html/rfc7432>`_
-* `Provider Backbone Bridging Combined with Ethernet VPN <https://tools.ietf.org/html/rfc7623>`_
-* `VPWS support in EVPN <https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-07>`_
-* `A Network Virtualization Overlay Solution using EVPN <https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-04>`_
-* `Interconnect Solution for EVPN Overlay networks <https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-04>`_
-* `Usage and applicability of BGP MPLS based Ethernet VPN <https://tools.ietf.org/html/draft-ietf-bess-evpn-usage-03>`_
+++ /dev/null
-.. _bgp-user-guide-flowspec-family:
-
-Flow Specification Family
-=========================
-The BGP Flow Specification (BGP-FS) Multiprotocol extension can be used to distribute traffic flow specifications.
-For example, the BGP-FS can be used in a case of (distributed) denial-of-service (DDoS) attack mitigation procedures and traffic filtering (BGP/MPLS VPN service, DC).
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-This section shows a way to enable BGP-FS family in BGP speaker and peer configuration.
-
-BGP Speaker
-'''''''''''
-To enable BGP-FS support in BGP plugin, first configure BGP speaker instance:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <protocol xmlns="http://openconfig.net/yang/network-instance">
- <name>bgp-example</name>
- <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
- <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <global>
- <config>
- <router-id>192.0.2.2</router-id>
- <as>65000</as>
- </config>
- <afi-safis>
- <afi-safi>
- <afi-safi-name>IPV4-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV6-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV4-L3VPN-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV6-L3VPN-FLOW</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </global>
- </bgp>
- </protocol>
-
-BGP Peer
-''''''''
-Here is an example for BGP peer configuration with enabled BGP-FS family.
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.1</neighbor-address>
- <afi-safis>
- <afi-safi>
- <afi-safi-name>IPV4-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV6-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV4-L3VPN-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV6-L3VPN-FLOW</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </neighbor>
-
-Flow Specification API
-^^^^^^^^^^^^^^^^^^^^^^
-Following trees illustrate the BGP Flow Specification routes structure.
-
-IPv4 Flow Specification Route
-'''''''''''''''''''''''''''''
-.. code-block:: console
-
- :(flowspec-routes-case)
- +--ro flowspec-routes
- +--ro flowspec-route* [route-key path-id]
- +--ro route-key string
- +--ro flowspec*
- | +--ro (flowspec-type)?
- | +--:(port-case)
- | | +--ro ports*
- | | +--ro op? numeric-operand
- | | +--ro value? uint16
- | +--:(destination-port-case)
- | | +--ro destination-ports*
- | | +--ro op? numeric-operand
- | | +--ro value? uint16
- | +--:(source-port-case)
- | | +--ro source-ports*
- | | +--ro op? numeric-operand
- | | +--ro value? uint16
- | +--:(icmp-type-case)
- | | +--ro types*
- | | +--ro op? numeric-operand
- | | +--ro value? uint8
- | +--:(icmp-code-case)
- | | +--ro codes*
- | | +--ro op? numeric-operand
- | | +--ro value? uint8
- | +--:(tcp-flags-case)
- | | +--ro tcp-flags*
- | | +--ro op? bitmask-operand
- | | +--ro value? uint16
- | +--:(packet-length-case)
- | | +--ro packet-lengths*
- | | +--ro op? numeric-operand
- | | +--ro value? uint16
- | +--:(dscp-case)
- | | +--ro dscps*
- | | +--ro op? numeric-operand
- | | +--ro value? dscp
- | +--:(fragment-case)
- | | +--ro fragments*
- | | +--ro op? bitmask-operand
- | | +--ro value? fragment
- | +--:(destination-prefix-case)
- | | +--ro destination-prefix? inet:ipv4-prefix
- | +--:(source-prefix-case)
- | | +--ro source-prefix? inet:ipv4-prefix
- | +--:(protocol-ip-case)
- | +--ro protocol-ips*
- | +--ro op? numeric-operand
- | +--ro value? uint8
- +--ro path-id path-id
- +--ro attributes
- +--ro extended-communities*
- +--ro transitive? boolean
- +--ro (extended-community)?
- +--:(traffic-rate-extended-community-case)
- | +--ro traffic-rate-extended-community
- | +--ro informative-as? bgp-t:short-as-number
- | +--ro local-administrator? netc:bandwidth
- +--:(traffic-action-extended-community-case)
- | +--ro traffic-action-extended-community
- | +--ro sample? boolean
- | +--ro terminal-action? boolean
- +--:(redirect-extended-community-case)
- | +--ro redirect-extended-community
- | +--ro global-administrator? bgp-t:short-as-number
- | +--ro local-administrator? binary
- +--:(traffic-marking-extended-community-case)
- | +--ro traffic-marking-extended-community
- | +--ro global-administrator? dscp
- +--:(redirect-ipv4-extended-community-case)
- | +--ro redirect-ipv4
- | +--ro global-administrator? inet:ipv4-address
- | +--ro local-administrator? uint16
- +--:(redirect-as4-extended-community-case)
- | +--ro redirect-as4
- | +--ro global-administrator? inet:as-number
- | +--ro local-administrator? uint16
- +--:(redirect-ip-nh-extended-community-case)
- +--ro redirect-ip-nh-extended-community
- +--ro next-hop-address? inet:ip-address
- +--ro copy? boolean
-
-
-IPv6 Flow Specification Route
-'''''''''''''''''''''''''''''
-.. code-block:: console
-
- :(flowspec-ipv6-routes-case)
- +--ro flowspec-ipv6-routes
- +--ro flowspec-route* [route-key path-id]
- +--ro flowspec*
- | +--ro (flowspec-type)?
- | +--:(port-case)
- | | +--ro ports*
- | | +--ro op? numeric-operand
- | | +--ro value? uint16
- | +--:(destination-port-case)
- | | +--ro destination-ports*
- | | +--ro op? numeric-operand
- | | +--ro value? uint16
- | +--:(source-port-case)
- | | +--ro source-ports*
- | | +--ro op? numeric-operand
- | | +--ro value? uint16
- | +--:(icmp-type-case)
- | | +--ro types*
- | | +--ro op? numeric-operand
- | | +--ro value? uint8
- | +--:(icmp-code-case)
- | | +--ro codes*
- | | +--ro op? numeric-operand
- | | +--ro value? uint8
- | +--:(tcp-flags-case)
- | | +--ro tcp-flags*
- | | +--ro op? bitmask-operand
- | | +--ro value? uint16
- | +--:(packet-length-case)
- | | +--ro packet-lengths*
- | | +--ro op? numeric-operand
- | | +--ro value? uint16
- | +--:(dscp-case)
- | | +--ro dscps*
- | | +--ro op? numeric-operand
- | | +--ro value? dscp
- | +--:(fragment-case)
- | | +--ro fragments*
- | | +--ro op? bitmask-operand
- | | +--ro value? fragment
- | +--:(destination-ipv6-prefix-case)
- | | +--ro destination-prefix? inet:ipv6-prefix
- | +--:(source-ipv6-prefix-case)
- | | +--ro source-prefix? inet:ipv6-prefix
- | +--:(next-header-case)
- | | +--ro next-headers*
- | | +--ro op? numeric-operand
- | | +--ro value? uint8
- | +--:(flow-label-case)
- | +--ro flow-label*
- | +--ro op? numeric-operand
- | +--ro value? uint32
- +--ro path-id path-id
- +--ro attributes
- +--ro extended-communities*
- +--ro transitive? boolean
- +--ro (extended-community)?
- +--:(traffic-rate-extended-community-case)
- | +--ro traffic-rate-extended-community
- | +--ro informative-as? bgp-t:short-as-number
- | +--ro local-administrator? netc:bandwidth
- +--:(traffic-action-extended-community-case)
- | +--ro traffic-action-extended-community
- | +--ro sample? boolean
- | +--ro terminal-action? boolean
- +--:(redirect-extended-community-case)
- | +--ro redirect-extended-community
- | +--ro global-administrator? bgp-t:short-as-number
- | +--ro local-administrator? binary
- +--:(traffic-marking-extended-community-case)
- | +--ro traffic-marking-extended-community
- | +--ro global-administrator? dscp
- +--:(redirect-ipv6-extended-community-case)
- | +--ro redirect-ipv6
- | +--ro global-administrator? inet:ipv6-address
- | +--ro local-administrator? uint16
- +--:(redirect-as4-extended-community-case)
- | +--ro redirect-as4
- | +--ro global-administrator? inet:as-number
- | +--ro local-administrator? uint16
- +--:(redirect-ip-nh-extended-community-case)
- +--ro redirect-ip-nh-extended-community
- +--ro next-hop-address? inet:ip-address
- +--ro copy? boolean
-
-Usage
-^^^^^
-The flowspec route represents rules and an action, defined as an extended community.
-
-IPv4 Flow Specification
-'''''''''''''''''''''''
-The IPv4 Flowspec table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <flowspec-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
- <flowspec-route>
- <path-id>0</path-id>
- <route-key>all packets to 192.168.0.1/32 AND from 10.0.0.2/32 AND where IP protocol equals to 17 or equals to 6 AND where port equals to 80 or equals to 8080 AND where destination port is greater than 8080 and is less than 8088 or equals to 3128 AND where source port is greater than 1024 </route-key>
- <attributes>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <origin>
- <value>igp</value>
- </origin>
- <as-path></as-path>
- <extended-communities>
- <transitive>true</transitive>
- <redirect-extended-community>
- <local-administrator>AgMWLg==</local-administrator>
- <global-administrator>258</global-administrator>
- </redirect-extended-community>
- </extended-communities>
- </attributes>
- <flowspec>
- <destination-prefix>192.168.0.1/32</destination-prefix>
- </flowspec>
- <flowspec>
- <source-prefix>10.0.0.2/32</source-prefix>
- </flowspec>
- <flowspec>
- <protocol-ips>
- <op>equals</op>
- <value>17</value>
- </protocol-ips>
- <protocol-ips>
- <op>equals end-of-list</op>
- <value>6</value>
- </protocol-ips>
- </flowspec>
- <flowspec>
- <ports>
- <op>equals</op>
- <value>80</value>
- </ports>
- <ports>
- <op>equals end-of-list</op>
- <value>8080</value>
- </ports>
- </flowspec>
- <flowspec>
- <destination-ports>
- <op>greater-than</op>
- <value>8080</value>
- </destination-ports>
- <destination-ports>
- <op>less-than and-bit</op>
- <value>8088</value>
- </destination-ports>
- <destination-ports>
- <op>equals end-of-list</op>
- <value>3128</value>
- </destination-ports>
- </flowspec>
- <flowspec>
- <source-ports>
- <op>end-of-list greater-than</op>
- <value>1024</value>
- </source-ports>
- </flowspec>
- </flowspec-route>
- </flowspec-routes>
-
-IPv6 Flows Specification
-''''''''''''''''''''''''
-The IPv6 Flowspec table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <flowspec-ipv6-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
- <flowspec-route>
- <path-id>0</path-id>
- <route-key>all packets to 2001:db8:31::/64 AND from 2001:db8:30::/64 AND where next header equals to 17 AND where DSCP equals to 50 AND where flow label equals to 2013 </route-key>
- <attributes>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <origin>
- <value>igp</value>
- </origin>
- <as-path></as-path>
- <extended-communities>
- <transitive>true</transitive>
- <traffic-rate-extended-community>
- <informative-as>0</informative-as>
- <local-administrator>AAAAAA==</local-administrator>
- </traffic-rate-extended-community>
- </extended-communities>
- </attributes>
- <flowspec>
- <destination-prefix>2001:db8:31::/64</destination-prefix>
- </flowspec>
- <flowspec>
- <source-prefix>2001:db8:30::/64</source-prefix>
- </flowspec>
- <flowspec>
- <next-headers>
- <op>equals end-of-list</op>
- <value>17</value>
- </next-headers>
- </flowspec>
- <flowspec>
- <dscps>
- <op>equals end-of-list</op>
- <value>50</value>
- </dscps>
- </flowspec>
- <flowspec>
- <flow-label>
- <op>equals end-of-list</op>
- <value>2013</value>
- </flow-label>
- </flowspec>
- </flowspec-route>
- </flowspec-ipv6-routes>
-
-IPv4 L3VPN Flows Specification
-''''''''''''''''''''''''''''''
-The IPv4 L3VPN Flowspec table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-l3vpn-subsequent-address-family/bgp-flowspec:flowspec-l3vpn-ipv4-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <flowspec-l3vpn-ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
- <flowspec-l3vpn-route>
- <path-id>0</path-id>
- <route-key>[l3vpn with route-distinguisher 172.16.0.44:101] all packets from 10.0.0.3/32</route-key>
- <attributes>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>5.6.7.8</global>
- </ipv4-next-hop>
- <origin>
- <value>igp</value>
- </origin>
- <as-path></as-path>
- <extended-communities>
- <transitive>true</transitive>
- <redirect-ip-nh-extended-community>
- <copy>false</copy>
- <next-hop-address>0.0.0.0</next-hop-address>
- </redirect-ip-nh-extended-community>
- </extended-communities>
- </attributes>
- <route-distinguisher>172.16.0.44:101</route-distinguisher>
- <flowspec>
- <source-prefix>10.0.0.3/32</source-prefix>
- </flowspec>
- </flowspec-l3vpn-route>
- </flowspec-l3vpn-ipv4-routes>
-
-Programming
-^^^^^^^^^^^
-IPv4 Flow Specification
-'''''''''''''''''''''''
-This examples show how to originate and remove IPv4 fowspec route via programmable RIB.
-Make sure the *Application Peer* is configured first.
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <flowspec-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
- <route-key>flow1</route-key>
- <path-id>0</path-id>
- <flowspec>
- <destination-prefix>192.168.0.1/32</destination-prefix>
- </flowspec>
- <flowspec>
- <source-prefix>10.0.0.1/32</source-prefix>
- </flowspec>
- <flowspec>
- <protocol-ips>
- <op>equals end-of-list</op>
- <value>6</value>
- </protocol-ips>
- </flowspec>
- <flowspec>
- <ports>
- <op>equals end-of-list</op>
- <value>80</value>
- </ports>
- </flowspec>
- <flowspec>
- <destination-ports>
- <op>greater-than</op>
- <value>8080</value>
- </destination-ports>
- <destination-ports>
- <op>and-bit less-than end-of-list</op>
- <value>8088</value>
- </destination-ports>
- </flowspec>
- <flowspec>
- <source-ports>
- <op>greater-than end-of-list</op>
- <value>1024</value>
- </source-ports>
- </flowspec>
- <flowspec>
- <types>
- <op>equals end-of-list</op>
- <value>0</value>
- </types>
- </flowspec>
- <flowspec>
- <codes>
- <op>equals end-of-list</op>
- <value>0</value>
- </codes>
- </flowspec>
- <flowspec>
- <tcp-flags>
- <op>match end-of-list</op>
- <value>32</value>
- </tcp-flags>
- </flowspec>
- <flowspec>
- <packet-lengths>
- <op>greater-than</op>
- <value>400</value>
- </packet-lengths>
- <packet-lengths>
- <op>and-bit less-than end-of-list</op>
- <value>500</value>
- </packet-lengths>
- </flowspec>
- <flowspec>
- <dscps>
- <op>equals end-of-list</op>
- <value>20</value>
- </dscps>
- </flowspec>
- <flowspec>
- <fragments>
- <op>match end-of-list</op>
- <value>first</value>
- </fragments>
- </flowspec>
- <attributes>
- <origin>
- <value>igp</value>
- </origin>
- <as-path/>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <extended-communities>
- ....
- </extended-communities>
- </attributes>
- </flowspec-route>
-
------
-
-**Extended Communities**
-
-* **Traffic Rate**
- .. code-block:: xml
- :linenos:
- :emphasize-lines: 5
-
- <extended-communities>
- <transitive>true</transitive>
- <traffic-rate-extended-community>
- <informative-as>123</informative-as>
- <local-administrator>AAAAAA==</local-administrator>
- </traffic-rate-extended-community>
- </extended-communities>
-
- @line 5: A rate in bytes per second, *AAAAAA==* (0) means traffic discard.
-
-* **Traffic Action**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <traffic-action-extended-community>
- <sample>true</sample>
- <terminal-action>false</terminal-action>
- </traffic-action-extended-community>
- </extended-communities>
-
-
-* **Redirect to VRF AS 2byte format**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <redirect-extended-community>
- <global-administrator>123</global-administrator>
- <local-administrator>AAAAew==</local-administrator>
- </redirect-extended-community>
- </extended-communities>
-
-* **Redirect to VRF IPv4 format**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <redirect-ipv4>
- <global-administrator>192.168.0.1</global-administrator>
- <local-administrator>12345</local-administrator>
- </redirect-ipv4>
- </extended-communities>
-
-* **Redirect to VRF AS 4byte format**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <redirect-as4>
- <global-administrator>64495</global-administrator>
- <local-administrator>12345</local-administrator>
- </redirect-as4>
- </extended-communities>
-
-* **Redirect to IP**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <redirect-ip-nh-extended-community>
- <copy>false</false>
- </redirect-ip-nh-extended-community>
- </extended-communities>
-
-* **Traffic Marking**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <traffic-marking-extended-community>
- <global-administrator>20</global-administrator>
- </traffic-marking-extended-community>
- </extended-communities>
-
------
-
-To remove the route added above, following request can be used:
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes/bgp-flowspec:flowspec-route/flow1/0``
-
-**Method:** ``DELETE``
-
-IPv4 L3VPN Flow Specification
-'''''''''''''''''''''''''''''
-This examples show how to originate and remove IPv4 L3VPN fowspec route via programmable RIB.
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-l3vpn-subsequent-address-family/bgp-flowspec:flowspec-l3vpn-ipv4-routes``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <flowspec-l3vpn-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
- <path-id>0</path-id>
- <route-key>flow-l3vpn</route-key>
- <route-distinguisher>172.16.0.44:101</route-distinguisher>
- <flowspec>
- <source-prefix>10.0.0.3/32</source-prefix>
- </flowspec>
- <attributes>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <origin>
- <value>igp</value>
- </origin>
- <as-path></as-path>
- <extended-communities>
- <transitive>true</transitive>
- <redirect-ipv4>
- <global-administrator>172.16.0.44</global-administrator>
- <local-administrator>102</local-administrator>
- </redirect-ipv4>
- </extended-communities>
- </attributes>
- </flowspec-l3vpn-route>
-
------
-
-To remove the route added above, following request can be used:
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-l3vpn-subsequent-address-family/bgp-flowspec:flowspec-l3vpn-ipv4-routes/flowspec-l3vpn-route/flow-l3vpn/0``
-
-**Method:** ``DELETE``
-
-IPv6 Flow Specification
-'''''''''''''''''''''''
-This examples show how to originate and remove IPv6 fowspec route via programmable RIB.
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <flowspec-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
- <route-key>flow-v6</route-key>
- <path-id>0</path-id>
- <flowspec>
- <destination-prefix>2001:db8:30::3/128</destination-prefix>
- </flowspec>
- <flowspec>
- <source-prefix>2001:db8:31::3/128</source-prefix>
- </flowspec>
- <flowspec>
- <flow-label>
- <op>equals end-of-list</op>
- <value>1</value>
- </flow-label>
- </flowspec>
- <attributes>
- <extended-communities>
- <transitive>true</transitive>
- <redirect-ipv6>
- <global-administrator>2001:db8:1::6</global-administrator>
- <local-administrator>12345</local-administrator>
- </redirect-ipv6>
- </extended-communities>
- <origin>
- <value>igp</value>
- </origin>
- <as-path/>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- </attributes>
- </flowspec-route>
-
------
-
-To remove the route added above, following request can be used:
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes/bgp-flowspec:flowspec-route/flow-v6/0``
-
-**Method:** ``DELETE``
-
-References
-^^^^^^^^^^
-* `Dissemination of Flow Specification Rules <https://tools.ietf.org/html/rfc5575>`_
-* `Dissemination of Flow Specification Rules for IPv6 <https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-07>`_
-* `BGP Flow-Spec Extended Community for Traffic Redirect to IP Next Hop <https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-ip-00>`_
-* `Clarification of the Flowspec Redirect Extended Community <https://tools.ietf.org/html/rfc7674>`_
-* `Revised Validation Procedure for BGP Flow Specifications <https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-03>`_
+++ /dev/null
-.. _bgp-user-guide-high-availability:
-
-High Availability
-=================
-Running OpenDaylight BGP in clustered environment brings an advantage of the plugin's high availability (HA).
-This section illustrates a basic scenario for HA, also presents a configuration for clustered OpenDaylight BGP.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-Following example shows a configuration for running BGP in clustered environment.
-
-#. As the first step, configure (replicated *deafult* shard and *topology* shard if needed) and run OpenDaylight in clustered environment, install BGP and RESTCONF.
-
-#. On one node (OpenDaylight instance), configure BGP speaker instance and neighbor. In addition, configure BGP topology exporter if required. The configuration is shared across all interconnected cluster nodes, however BGP become active only on one node. Other nodes with configured BGP serves as stand-by backups.
-
-#. Remote peer should be configured to accept/initiate connection from/to all OpenDaylight cluster nodes with configured BGP plugin.
-
-#. Connect remote peer, let it advertise some routes. Verify routes presence in Loc-RIB and/or BGP topology exporter instance on all nodes of the OpenDaylight cluster.
-
-.. warning::
-
- Replicating RIBs across the cluster nodes is causing severe scalability issue and overall performance degradation. To avoid this problems, configure BGP RIB module as a separate shard without enabled replication. Change configuration on all nodes as following (`configuration/initial`):
-
- * In ``modules.conf`` add a new module:
- .. code-block:: console
-
- {
- name = "bgp_rib"
- namespace = "urn:opendaylight:params:xml:ns:yang:bgp-rib"
- shard-strategy = "module"
- }
-
- * In ``module-shards.conf`` define a new module shard:
- .. code-block:: console
-
- {
- name = "bgp_rib"
- shards = [
- {
- name="bgp_rib"
- replicas = [
- "member-1"
- ]
- }
- ]
- }
-
- **Note:** Use correct member name in module shard configuration.
-
-Failover scenario
-^^^^^^^^^^^^^^^^^
-Following section presents a basic BGP speaker failover scenario on 3-node OpenDaylight cluster setup.
-
-.. figure:: ./images/BGP_HA.png
- :alt: BGP HA setup.
-
- Once the OpenDaylight BGP is configured, the speaker become active on one of the cluster nodes. Remote peer can establish connection with this BGP instance.
- Routes advertised by remote peer are replicated, hence RIBs state on all nodes is the same.
-
------
-
-.. figure:: ./images/BGP_HA_failure.png
- :alt: Node went down.
-
- In a case a cluster node, where BGP instance is running, goes down (unexpected failure, restart), active BGP session is dropped.
-
------
-
-.. figure:: ./images/BGP_HA_recovery.png
- :alt: BGP recovery.
-
- Now, one of the stand-by BGP speaker instances become active. Remote peer establishes new connection and advertises routes again.
+++ /dev/null
-.. _bgp-user-guide-ip-unicast-family:
-
-IP Unicast Family
-=================
-The BGP-4 allows to carry IPv4 specific information only.
-The basic BGP Multiprotocol extension brings *Unicast* Subsequent Address Family (SAFI) - intended to be used for IP unicast forwarding.
-The combination of IPv4 and IPv6 Address Family (AF) and Unicast SAFI is essential for Internet routing.
-The IPv4 Unicast routes are interchangeable with BGP-4 routes, as they can carry the same type of routing information.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-This section shows a way to enable IPv4 and IPv6 Unicast family in BGP speaker and peer configuration.
-
-BGP Speaker
-'''''''''''
-To enable IPv4 and IPv6 Unicast support in BGP plugin, first configure BGP speaker instance:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <protocol xmlns="http://openconfig.net/yang/network-instance">
- <name>bgp-example</name>
- <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
- <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <global>
- <config>
- <router-id>192.0.2.2</router-id>
- <as>65000</as>
- </config>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-UNICAST</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </global>
- </bgp>
- </protocol>
-
-BGP Peer
-''''''''
-Here is an example for BGP peer configuration with enabled IPv4 and IPv6 Unicast family.
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.1</neighbor-address>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-UNICAST</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </neighbor>
-
-IP Unicast API
-^^^^^^^^^^^^^^
-Following trees illustrate the BGP IP Unicast routes structures.
-
-IPv4 Unicast Route
-''''''''''''''''''
-.. code-block:: console
-
- :(ipv4-routes-case)
- +--ro ipv4-routes
- +--ro ipv4-route* [route-key path-id]
- +--ro route-key string
- +--ro prefix inet:ipv4-prefix
- +--ro path-id path-id
- +--ro attributes
- +--ro origin
- | +--ro value bgp-t:bgp-origin
- +--ro as-path
- | +--ro segments*
- | +--ro as-sequence* inet:as-number
- | +--ro as-set* inet:as-number
- +--ro (c-next-hop)?
- | +--:(ipv4-next-hop-case)
- | | +--ro ipv4-next-hop
- | | +--ro global? inet:ipv4-address
- | +--:(ipv6-next-hop-case)
- | | +--ro ipv6-next-hop
- | | +--ro global? inet:ipv6-address
- | | +--ro link-local? inet:ipv6-address
- | +--:(empty-next-hop-case)
- | +--ro empty-next-hop? empty
- +--ro multi-exit-disc
- | +--ro med? uint32
- +--ro local-pref
- | +--ro pref? uint32
- +--ro atomic-aggregate!
- +--ro aggregator
- | +--ro as-number? inet:as-number
- | +--ro network-address? inet:ipv4-address
- +--ro communities*
- | +--ro as-number? inet:as-number
- | +--ro semantics? uint16
- +--ro extended-communities*
- | +--ro transitive? boolean
- | +--ro (extended-community)?
- | +--:(as-specific-extended-community-case)
- | | +--ro as-specific-extended-community
- | | +--ro global-administrator? short-as-number
- | | +--ro local-administrator? binary
- | +--:(inet4-specific-extended-community-case)
- | | +--ro inet4-specific-extended-community
- | | +--ro global-administrator? inet:ipv4-address
- | | +--ro local-administrator? binary
- | +--:(opaque-extended-community-case)
- | | +--ro opaque-extended-community
- | | +--ro value? binary
- | +--:(route-target-extended-community-case)
- | | +--ro route-target-extended-community
- | | +--ro global-administrator? short-as-number
- | | +--ro local-administrator? binary
- | +--:(route-origin-extended-community-case)
- | | +--ro route-origin-extended-community
- | | +--ro global-administrator? short-as-number
- | | +--ro local-administrator? binary
- | +--:(route-target-ipv4-case)
- | | +--ro route-target-ipv4
- | | +--ro global-administrator? inet:ipv4-address
- | | +--ro local-administrator? uint16
- | +--:(route-origin-ipv4-case)
- | | +--ro route-origin-ipv4
- | | +--ro global-administrator? inet:ipv4-address
- | | +--ro local-administrator? uint16
- | +--:(link-bandwidth-case)
- | | +--ro link-bandwidth-extended-community
- | | +--ro bandwidth netc:bandwidth
- | +--:(as-4-generic-spec-extended-community-case)
- | | +--ro as-4-generic-spec-extended-community
- | | +--ro as-4-specific-common
- | | +--ro as-number inet:as-number
- | | +--ro local-administrator uint16
- | +--:(as-4-route-target-extended-community-case)
- | | +--ro as-4-route-target-extended-community
- | | +--ro as-4-specific-common
- | | +--ro as-number inet:as-number
- | | +--ro local-administrator uint16
- | +--:(as-4-route-origin-extended-community-case)
- | | +--ro as-4-route-origin-extended-community
- | | +--ro as-4-specific-common
- | | +--ro as-number inet:as-number
- | | +--ro local-administrator uint16
- | +--:(encapsulation-case)
- | +--ro encapsulation-extended-community
- | +--ro tunnel-type encapsulation-tunnel-type
- +--ro originator-id
- | +--ro originator? inet:ipv4-address
- +--ro cluster-id
- | +--ro cluster* bgp-t:cluster-identifier
- +--ro aigp
- | +--ro aigp-tlv
- | +--ro metric? netc:accumulated-igp-metric
- +--ro unrecognized-attributes* [type]
- +--ro partial boolean
- +--ro transitive boolean
- +--ro type uint8
- +--ro value binary
-
-IPv6 Unicast Route
-''''''''''''''''''
-.. code-block:: console
-
- :(ipv6-routes-case)
- +--ro ipv6-routes
- +--ro ipv6-route* [route-key path-id]
- +--ro route-key string
- +--ro prefix inet:ipv6-prefix
- +--ro path-id path-id
- +--ro attributes
- ...
-
-Usage
-^^^^^
-IPv4 Unicast
-''''''''''''
-The IPv4 Unicast table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv4-route>
- <route-key>193.0.2.1/32</route-key>
- <path-id>0</path-id>
- <prefix>193.0.2.1/32</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.0.0.1</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
- </ipv4-routes>
-
-IPv6 Unicast
-''''''''''''
-The IPv6 Unicast table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv6-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <ipv6-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv6-route>
- <route-key>2a02:b80:0:1::/64</route-key>
- <path-id>0</path-id>
- <prefix>2a02:b80:0:1::/64</prefix>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>200</pref>
- </local-pref>
- <ipv6-next-hop>
- <global>2a02:b80:0:2::1</global>
- </ipv6-next-hop>
- </attributes>
- </ipv6-route>
- </ipv6-routes>
-
-.. note:: IPv4/6 routes mapping to topology nodes is supported by BGP Topology Provider.
-
-Programming
-^^^^^^^^^^^
-IPv4 Unicast
-''''''''''''
-This examples show how to originate and remove IPv4 route via programmable RIB.
-Make sure the *Application Peer* is configured first.
-
-.. note:: IPv4 Route Key must be equal to prefix.
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <ipv4-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <route-key>10.0.0.11/32</route-key>
- <prefix>10.0.0.11/32</prefix>
- <path-id>0</path-id>
- <attributes>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>10.11.1.1</global>
- </ipv4-next-hop>
- </attributes>
- </ipv4-route>
-
------
-
-To remove the route added above, following request can be used:
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/ipv4-route/10.0.0.11%2F32/0``
-
-**Method:** ``DELETE``
-
-IPv6 Unicast
-''''''''''''
-This examples show how to originate and remove IPv6 route via programmable RIB:
-
-.. note:: IPv6 Route Key must be equal to prefix.
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <ipv6-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <route-key>2001:db8:30::3/128</route-key>
- <prefix>2001:db8:30::3/128</prefix>
- <path-id>0</path-id>
- <attributes>
- <ipv6-next-hop>
- <global>2001:db8:1::6</global>
- </ipv6-next-hop>
- <as-path/>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- </attributes>
- </ipv6-route>
-
------
-
-To remove the route added above, following request can be used:
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes/ipv6-route/2001:db8:30::3%2F128/0``
-
-**Method:** ``DELETE``
-
-References
-^^^^^^^^^^
-* `Multiprotocol Extensions for BGP-4 <https://tools.ietf.org/html/rfc4760>`_
+++ /dev/null
-.. _ip-l3vpn-family:
-
-IP L3VPN Family
-===============
-The BGP/MPLS IP Virtual Private Networks (BGP L3VPN) Multiprotocol extension can be used to exchange particular VPN (customer) routes among the provider's routers attached to that VPN.
-Also, routes are distributed to specific VPN remote sites.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-This section shows a way to enable IPv4 and IPv6 L3VPN family in BGP speaker and peer configuration.
-
-BGP Speaker
-'''''''''''
-To enable IPv4 and IPv6 L3VPN support in BGP plugin, first configure BGP speaker instance:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <protocol xmlns="http://openconfig.net/yang/network-instance">
- <name>bgp-example</name>
- <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
- <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <global>
- <config>
- <router-id>192.0.2.2</router-id>
- <as>65000</as>
- </config>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV4-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV6-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV4-MULTICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV6-MULTICAST</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </global>
- </bgp>
- </protocol>
-
-BGP Peer
-''''''''
-Here is an example for BGP peer configuration with enabled IPv4 and IPv6 L3VPN family.
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.1</neighbor-address>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV4-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV6-UNICAST</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </neighbor>
-
-IP L3VPN API
-^^^^^^^^^^^^
-Following trees illustrate the BGP IP L3VPN routes structures.
-
-IPv4 L3VPN Unicast Route
-''''''''''''''''''''''''
-.. code-block:: console
-
- :(vpn-ipv4-routes-case)
- +--ro vpn-ipv4-routes
- +--ro vpn-route* [route-key path-id]
- +--ro route-key string
- +--ro path-id path-id
- +--ro label-stack*
- | +--ro label-value? netc:mpls-label
- +--ro prefix? inet:ip-prefix
- +--ro path-id? path-id
- +--ro route-distinguisher? bgp-t:route-distinguisher
- +--ro attributes
- ...
-
-IPv6 L3VPN Unicast Route
-''''''''''''''''''''''''
-.. code-block:: console
-
- :(vpn-ipv6-routes-case)
- +--ro vpn-ipv6-routes
- +--ro vpn-route* [route-key path-id]
- +--ro route-key string
- +--ro path-id path-id
- +--ro label-stack*
- | +--ro label-value? netc:mpls-label
- +--ro prefix? inet:ip-prefix
- +--ro path-id? path-id
- +--ro route-distinguisher? bgp-t:route-distinguisher
- +--ro attributes
- ...
-
-IPv4 L3VPN Multicast Route
-''''''''''''''''''''''''''
-.. code-block:: console
-
- :(l3vpn-mcast-routes-ipv4-case)
- +--ro l3vpn-mcast-routes-ipv4
- +--ro l3vpn-mcast-route* [route-key path-id]
- +--ro prefix? inet:ip-prefix
- +--ro route-distinguisher? bgp-t:route-distinguisher
-
-IPv6 L3VPN Multicast Route
-''''''''''''''''''''''''''
-.. code-block:: console
-
- :(l3vpn-mcast-routes-ipv6-case)
- +--ro l3vpn-mcast-routes-ipv6
- +--ro l3vpn-mcast-route* [route-key path-id]
- +--ro prefix? inet:ip-prefix
- +--ro route-distinguisher? bgp-t:route-distinguisher
-
-
-Usage
-^^^^^
-IPv4 L3VPN Unicast
-''''''''''''''''''
-The IPv4 L3VPN Unicast table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:mpls-labeled-vpn-subsequent-address-family/bgp-vpn-ipv4:vpn-ipv4-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <vpn-ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-vpn-ipv4">
- <vpn-route>
- <path-id>0</path-id>
- <route-key>cAXdYQABrBAALABlCgIi</route-key>
- <label-stack>
- <label-value>24022</label-value>
- </label-stack>
- <attributes>
- <extended-communities>
- <transitive>true</transitive>
- <route-target-extended-community>
- <global-administrator>65000</global-administrator>
- <local-administrator>AAAAZQ==</local-administrator>
- </route-target-extended-community>
- </extended-communities>
- <origin>
- <value>igp</value>
- </origin>
- <as-path></as-path>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>127.16.0.44</global>
- </ipv4-next-hop>
- </attributes>
- <route-distinguisher>172.16.0.44:101</route-distinguisher>
- <prefix>10.2.34.0/24</prefix>
- </vpn-route>
- </vpn-ipv4-routes>
-
-IPv6 L3VPN Unicast
-''''''''''''''''''
-The IPv6 L3VPN Unicast table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv6-address-family/bgp-types:mpls-labeled-vpn-subsequent-address-family/bgp-vpn-ipv6:vpn-ipv6-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <vpn-ipv6-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-vpn-ipv6">
- <vpn-route>
- <path-id>0</path-id>
- <route-key>mAXdcQABrBAALABlKgILgAAAAAE=</route-key>
- <label-stack>
- <label-value>24023</label-value>
- </label-stack>
- <attributes>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <extended-communities>
- <route-target-extended-community>
- <global-administrator>65000</global-administrator>
- <local-administrator>AAAAZQ==</local-administrator>
- </route-target-extended-community>
- <transitive>true</transitive>
- </extended-communities>
- <ipv6-next-hop>
- <global>2a02:b80:0:2::1</global>
- </ipv6-next-hop>
- <origin>
- <value>igp</value>
- </origin>
- <as-path></as-path>
- </attributes>
- <route-distinguisher>172.16.0.44:101</route-distinguisher>
- <prefix>2a02:b80:0:1::/64</prefix>
- </vpn-route>
- </vpn-ipv6-routes>
-
-IPv4 L3VPN Multicast
-''''''''''''''''''''
-The IPv4 L3VPN Multicast table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:mcast-mpls-labeled-vpn-subsequent-address-family/bgp-l3vpn-mcast:l3vpn-mcast-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <l3vpn-mcast-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp:l3vpn:mcast">
- <l3vpn-mcast-route>
- <path-id>0</path-id>
- <route-key>mAXdcQABrBAALABlKgILgAAAAAE=</route-key>
- <route-distinguisher>172.16.0.44:101</route-distinguisher>
- <prefix>10.2.34.0/24</prefix>
- <attributes>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <extended-communities>
- <transitive>true</transitive>
- <vrf-route-import-extended-community>
- <inet4-specific-extended-community-common>
- <global-administrator>10.0.0.1</global-administrator>
- <local-administrator>123=</local-administrator>
- </inet4-specific-extended-community-common>
- </vrf-route-import-extended-community>
- </extended-communities>
- <ipv4-next-hop>
- <global>127.16.0.44</global>
- </ipv4-next-hop>
- <origin>
- <value>igp</value>
- </origin>
- <as-path></as-path>
- </attributes>
- </l3vpn-mcast-route>
- </l3vpn-mcast-routes>
-
-IPv6 L3VPN Multicast
-''''''''''''''''''''
-The IPv4 L3VPN Multicast table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv6-address-family/bgp-types:mcast-mpls-labeled-vpn-subsequent-address-family/bgp-l3vpn-mcast:l3vpn-mcast-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <l3vpn-mcast-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp:l3vpn:mcast">
- <l3vpn-mcast-route>
- <path-id>0</path-id>
- <route-key>mAXdcQABrBAALABlKgILgAAAAAE=</route-key>
- <route-distinguisher>172.16.0.44:101</route-distinguisher>
- <prefix>2a02:b80:0:1::/64</prefix>
- <attributes>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <extended-communities>
- <transitive>true</transitive>
- <vrf-route-import-extended-community>
- <inet4-specific-extended-community-common>
- <global-administrator>10.0.0.1</global-administrator>
- <local-administrator>123=</local-administrator>
- </inet4-specific-extended-community-common>
- </vrf-route-import-extended-community>
- </extended-communities>
- <ipv6-next-hop>
- <global>2a02:b80:0:2::1</global>
- </ipv6-next-hop>
- <origin>
- <value>igp</value>
- </origin>
- <as-path></as-path>
- </attributes>
- </l3vpn-mcast-route>
- </l3vpn-mcast-routes>
-
-Programming
-^^^^^^^^^^^
-This examples show how to originate and remove IPv4 L3VPN Unicast route via programmable RIB.
-Make sure the *Application Peer* is configured first.
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:mpls-labeled-vpn-subsequent-address-family/bgp-vpn-ipv4:vpn-ipv4-routes``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <vpn-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-vpn-ipv4">
- <path-id>0</path-id>
- <route-key>vpn1</route-key>
- <label-stack>
- <label-value>123</label-value>
- </label-stack>
- <route-distinguisher>429496729:1</route-distinguisher>
- <prefix>2.2.2.2/32</prefix>
- <attributes>
- <ipv4-next-hop>
- <global>199.20.166.41</global>
- </ipv4-next-hop>
- <as-path/>
- <origin>
- <value>igp</value>
- </origin>
- <extended-communities>
- <route-target-extended-community>
- <global-administrator>65000</global-administrator>
- <local-administrator>AAAAZQ==</local-administrator>
- </route-target-extended-community>
- <transitive>true</transitive>
- </extended-communities>
- </attributes>
- </vpn-route>
-
------
-
-To remove the route added above, following request can be used:
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-types:mpls-labeled-vpn-subsequent-address-family/bgp-vpn-ipv4:vpn-ipv4-routes/vpn-route/vpn1/0``
-
-**Method:** ``DELETE``
-
-References
-^^^^^^^^^^
-* `BGP/MPLS IP Virtual Private Networks (VPNs) <https://tools.ietf.org/html/rfc4364>`_
-* `BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN <https://tools.ietf.org/html/rfc4659>`_
-* `BGP/MPLS VPN Virtual PE <https://tools.ietf.org/html/draft-ietf-bess-virtual-pe-00>`_
+++ /dev/null
-.. _bgp-user-guide-labeled-family:
-
-IP Labeled Unicast Family
-=========================
-The BGP Labeled Unicast (BGP-LU) Multiprotocol extension is used to distribute a MPLS label that is mapped to a particular route.
-It can be used to advertise a MPLS transport path between IGP regions and Autonomous Systems.
-Also, BGP-LU can help to solve the Inter-domain traffic-engineering problem and can be deployed in large-scale data centers along with MPLS and Spring.
-In addition, IPv6 Labeled Unicast can be used to interconnect IPv6 islands over IPv4/MPLS networks using 6PE.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-This section shows a way to enable IPv4 and IPv6 Labeled Unicast family in BGP speaker and peer configuration.
-
-BGP Speaker
-'''''''''''
-To enable IPv4 and IPv6 Labeled Unicast support in BGP plugin, first configure BGP speaker instance:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <protocol xmlns="http://openconfig.net/yang/network-instance">
- <name>bgp-example</name>
- <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
- <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <global>
- <config>
- <router-id>192.0.2.2</router-id>
- <as>65000</as>
- </config>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-LABELLED-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-LABELLED-UNICAST</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </global>
- </bgp>
- </protocol>
-
-BGP Peer
-''''''''
-Here is an example for BGP peer configuration with enabled IPv4 and IPv6 Labeled Unicast family.
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.1</neighbor-address>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-LABELLED-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-LABELLED-UNICAST</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </neighbor>
-
-IP Labeled Unicast API
-^^^^^^^^^^^^^^^^^^^^^^
-Following trees illustrate the BGP IP Labeled Unicast routes structures.
-
-IPv4 Labeled Unicast Route
-''''''''''''''''''''''''''
-.. code-block:: console
-
- :(labeled-unicast-routes-case)
- +--ro labeled-unicast-routes
- +--ro labeled-unicast-route* [route-key path-id]
- +--ro route-key string
- +--ro label-stack*
- | +--ro label-value? netc:mpls-label
- +--ro prefix? inet:ip-prefix
- +--ro path-id path-id
- +--ro attributes
- ...
-
-
-IPv6 Labeled Unicast Route
-''''''''''''''''''''''''''
-.. code-block:: console
-
- :(labeled-unicast-ipv6-routes-case)
- +--ro labeled-unicast-ipv6-routes
- +--ro labeled-unicast-route* [route-key path-id]
- +--ro route-key string
- +--ro label-stack*
- | +--ro label-value? netc:mpls-label
- +--ro prefix? inet:ip-prefix
- +--ro path-id path-id
- +--ro attributes
- ...
-
-Usage
-^^^^^
-The IPv4 Labeled Unicast table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <labeled-unicast-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
- <labeled-unicast-route>
- <path-id>0</path-id>
- <route-key>MAA+gRQAAA==</route-key>
- <attributes>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <ipv4-next-hop>
- <global>200.10.0.101</global>
- </ipv4-next-hop>
- <as-path></as-path>
- <origin>
- <value>igp</value>
- </origin>
- </attributes>
- <label-stack>
- <label-value>1000</label-value>
- </label-stack>
- <prefix>20.0.0.0/24</prefix>
- </labeled-unicast-route>
- </labeled-unicast-routes>
-
-Programming
-^^^^^^^^^^^
-IPv4 Labeled
-''''''''''''
-This examples show how to originate and remove IPv4 labeled route via programmable RIB.
-Make sure the *Application Peer* is configured first.
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <labeled-unicast-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
- <route-key>label1</route-key>
- <prefix>1.1.1.1/32</prefix>
- <path-id>0</path-id>
- <label-stack>
- <label-value>800322</label-value>
- </label-stack>
- <attributes>
- <ipv4-next-hop>
- <global>199.20.160.41</global>
- </ipv4-next-hop>
- <origin>
- <value>igp</value>
- </origin>
- <as-path/>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- </attributes>
- </labeled-unicast-route>
-
------
-
-In addition, BGP-LU Spring extension allows to attach BGP Prefix SID attribute to the route, in order to signal the BGP-Prefix-SID, where the SR is applied to MPLS dataplane.
-
-.. code-block:: xml
-
- <bgp-prefix-sid>
- <bgp-prefix-sid-tlvs>
- <label-index-tlv xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">322</label-index-tlv>
- </bgp-prefix-sid-tlvs>
- <bgp-prefix-sid-tlvs>
- <srgb-value xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
- <base>800000</base>
- <range>4095</range>
- </srgb-value>
- </bgp-prefix-sid-tlvs>
- </bgp-prefix-sid>
-
------
-
-To remove the route added above, following request can be used:
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes/bgp-labeled-unicast:labeled-unicast-route/label1/0``
-
-**Method:** ``DELETE``
-
-IPv6 Labeled
-''''''''''''
-This examples show how to originate and remove IPv6 labeled route via programmable RIB.
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-ipv6-routes``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <labeled-unicast-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
- <route-key>label1</route-key>
- <prefix>2001:db8:30::3/128</prefix>
- <path-id>0</path-id>
- <label-stack>
- <label-value>123</label-value>
- </label-stack>
- <attributes>
- <ipv6-next-hop>
- <global>2003:4:5:6::7</global>
- </ipv6-next-hop>
- <origin>
- <value>igp</value>
- </origin>
- <as-path/>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- </attributes>
- </labeled-unicast-route>
-
------
-
-To remove the route added above, following request can be used:
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-ipv6-routes/bgp-labeled-unicast:labeled-unicast-route/label1/0``
-
-**Method:** ``DELETE``
-
-References
-^^^^^^^^^^
-* `Carrying Label Information in BGP-4 <https://tools.ietf.org/html/rfc3107>`_
-* `Segment Routing Prefix SID extensions for BGP <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-03>`_
-* `Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) <https://tools.ietf.org/html/rfc4798>`_
-* `BGP-Prefix Segment in large-scale data centers <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-01>`_
-* `Egress Peer Engineering using BGP-LU <https://tools.ietf.org/html/draft-gredler-idr-bgplu-epe-06>`_
+++ /dev/null
-.. _bgp-user-guide-linkstate-family:
-
-Link-State Family
-=================
-The BGP Link-State (BGP-LS) Multiprotocol extension allows to distribute Link-State and Traffic Engineering (TE) information.
-This information is typically distributed by IGP routing protocols with in the network, limiting LSDB or TED visibility to the IGP area.
-The BGP-LS-enabled routers are capable to collect such information from networks (multiple IGP areas, inter-AS) and share with external components (i.e. OpenDaylight BGP).
-The information is applicable in ALTO servers and PCEs, as both need to gather information about topologies.
-In addition, link-state information is extended to carry segment information (Spring).
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-This section shows a way to enable IPv4 and IPv6 Labeled Unicast family in BGP speaker and peer configuration.
-
-BGP Speaker
-'''''''''''
-To enable BGP-LS support in BGP plugin, first configure BGP speaker instance:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <protocol xmlns="http://openconfig.net/yang/network-instance">
- <name>bgp-example</name>
- <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
- <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <global>
- <config>
- <router-id>192.0.2.2</router-id>
- <as>65000</as>
- </config>
- <afi-safis>
- <afi-safi>
- <afi-safi-name>LINKSTATE</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </global>
- </bgp>
- </protocol>
-
-Linkstate path attribute
-''''''''''''''''''''''''
-IANA allocation for BGP-LS path attribute is TYPE 29.
-Some older BGP-LS implementations might still require earliest asigned allocation TYPE 99.
-To use TYPE = 99, you need to set value bellow to false.
-
-**URL:** ``/restconf/config/bgp-linkstate-app-config:bgp-linkstate-app-config``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <bgp-linkstate-app-config xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:linkstate-app-config">
- <iana-linkstate-attribute-type>false</iana-linkstate-attribute-type>
- </bgp-linkstate-app-config>
-
-BGP Peer
-''''''''
-Here is an example for BGP peer configuration with enabled BGP-LS family.
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.1</neighbor-address>
- <afi-safis>
- <afi-safi>
- <afi-safi-name>LINKSTATE</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </neighbor>
-
-Link-State Route API
-^^^^^^^^^^^^^^^^^^^^
-Following tree illustrate the BGP Link-State route structure.
-
-.. code-block:: console
-
- :(linkstate-routes-case)
- +--ro linkstate-routes
- +--ro linkstate-route* [route-key path-id]
- +--ro route-key string
- +--ro path-id path-id
- +--ro protocol-id protocol-id
- +--ro identifier identifier
- +--ro (object-type)?
- | +--:(node-case)
- | | +--ro node-descriptors
- | | +--ro as-number? inet:as-number
- | | +--ro area-id? area-identifier
- | | +--ro domain-id? domain-identifier
- | | +--ro (c-router-identifier)?
- | | +--:(isis-node-case)
- | | | +--ro isis-node
- | | | +--ro iso-system-id netc:iso-system-identifier
- | | +--:(isis-pseudonode-case)
- | | | +--ro isis-pseudonode
- | | | +--ro is-is-router-identifier
- | | | | +--ro iso-system-id netc:iso-system-identifier
- | | | +--ro psn uint8
- | | +--:(ospf-node-case)
- | | | +--ro ospf-node
- | | | +--ro ospf-router-id uint32
- | | +--:(ospf-pseudonode-case)
- | | +--ro ospf-pseudonode
- | | +--ro ospf-router-id uint32
- | | +--ro lan-interface ospf-interface-identifier
- | +--:(link-case)
- | | +--ro local-node-descriptors
- | | | +--ro as-number? inet:as-number
- | | | +--ro area-id? area-identifier
- | | | +--ro domain-id? domain-identifier
- | | | +--ro (c-router-identifier)?
- | | | | +--:(isis-node-case)
- | | | | | +--ro isis-node
- | | | | | +--ro iso-system-id netc:iso-system-identifier
- | | | | +--:(isis-pseudonode-case)
- | | | | | +--ro isis-pseudonode
- | | | | | +--ro is-is-router-identifier
- | | | | | | +--ro iso-system-id netc:iso-system-identifier
- | | | | | +--ro psn uint8
- | | | | +--:(ospf-node-case)
- | | | | | +--ro ospf-node
- | | | | | +--ro ospf-router-id uint32
- | | | | +--:(ospf-pseudonode-case)
- | | | | +--ro ospf-pseudonode
- | | | | +--ro ospf-router-id uint32
- | | | | +--ro lan-interface ospf-interface-identifier
- | | | +--ro bgp-router-id? inet:ipv4-address
- | | | +--ro member-asn? inet:as-number
- | | +--ro remote-node-descriptors
- | | | +--ro as-number? inet:as-number
- | | | +--ro area-id? area-identifier
- | | | +--ro domain-id? domain-identifier
- | | | +--ro (c-router-identifier)?
- | | | | +--:(isis-node-case)
- | | | | | +--ro isis-node
- | | | | | +--ro iso-system-id netc:iso-system-identifier
- | | | | +--:(isis-pseudonode-case)
- | | | | | +--ro isis-pseudonode
- | | | | | +--ro is-is-router-identifier
- | | | | | | +--ro iso-system-id netc:iso-system-identifier
- | | | | | +--ro psn uint8
- | | | | +--:(ospf-node-case)
- | | | | | +--ro ospf-node
- | | | | | +--ro ospf-router-id uint32
- | | | | +--:(ospf-pseudonode-case)
- | | | | +--ro ospf-pseudonode
- | | | | +--ro ospf-router-id uint32
- | | | | +--ro lan-interface ospf-interface-identifier
- | | | +--ro bgp-router-id? inet:ipv4-address
- | | | +--ro member-asn? inet:as-number
- | | +--ro link-descriptors
- | | +--ro link-local-identifier? uint32
- | | +--ro link-remote-identifier? uint32
- | | +--ro ipv4-interface-address? ipv4-interface-identifier
- | | +--ro ipv6-interface-address? ipv6-interface-identifier
- | | +--ro ipv4-neighbor-address? ipv4-interface-identifier
- | | +--ro ipv6-neighbor-address? ipv6-interface-identifier
- | | +--ro multi-topology-id? topology-identifier
- | +--:(prefix-case)
- | | +--ro advertising-node-descriptors
- | | | +--ro as-number? inet:as-number
- | | | +--ro area-id? area-identifier
- | | | +--ro domain-id? domain-identifier
- | | | +--ro (c-router-identifier)?
- | | | +--:(isis-node-case)
- | | | | +--ro isis-node
- | | | | +--ro iso-system-id netc:iso-system-identifier
- | | | +--:(isis-pseudonode-case)
- | | | | +--ro isis-pseudonode
- | | | | +--ro is-is-router-identifier
- | | | | | +--ro iso-system-id netc:iso-system-identifier
- | | | | +--ro psn uint8
- | | | +--:(ospf-node-case)
- | | | | +--ro ospf-node
- | | | | +--ro ospf-router-id uint32
- | | | +--:(ospf-pseudonode-case)
- | | | +--ro ospf-pseudonode
- | | | +--ro ospf-router-id uint32
- | | | +--ro lan-interface ospf-interface-identifier
- | | +--ro prefix-descriptors
- | | +--ro multi-topology-id? topology-identifier
- | | +--ro ospf-route-type? ospf-route-type
- | | +--ro ip-reachability-information? inet:ip-prefix
- | +--:(te-lsp-case)
- | +--ro (address-family)?
- | | +--:(ipv4-case)
- | | | +--ro ipv4-tunnel-sender-address inet:ipv4-address
- | | | +--ro ipv4-tunnel-endpoint-address inet:ipv4-address
- | | +--:(ipv6-case)
- | | +--ro ipv6-tunnel-sender-address inet:ipv6-address
- | | +--ro ipv6-tunnel-endpoint-address inet:ipv6-address
- | +--ro tunnel-id? rsvp:tunnel-id
- | +--ro lsp-id? rsvp:lsp-id
- +--ro attributes
- +--ro (link-state-attribute)?
- +--:(node-attributes-case)
- | +--ro node-attributes
- | +--ro topology-identifier* topology-identifier
- | +--ro node-flags? node-flag-bits
- | +--ro isis-area-id* isis-area-identifier
- | +--ro dynamic-hostname? string
- | +--ro ipv4-router-id? ipv4-router-identifier
- | +--ro ipv6-router-id? ipv6-router-identifier
- | +--ro sr-capabilities
- | | +--ro mpls-ipv4? boolean
- | | +--ro mpls-ipv6? boolean
- | | +--ro sr-ipv6? boolean
- | | +--ro range-size? uint32
- | | +--ro (sid-label-index)?
- | | +--:(local-label-case)
- | | | +--ro local-label? netc:mpls-label
- | | +--:(ipv6-address-case)
- | | | +--ro ipv6-address? inet:ipv6-address
- | | +--:(sid-case)
- | | +--ro sid? uint32
- | +--ro sr-algorithm
- | +--ro algorithms* algorithm
- +--:(link-attributes-case)
- | +--ro link-attributes
- | +--ro local-ipv4-router-id? ipv4-router-identifier
- | +--ro local-ipv6-router-id? ipv6-router-identifier
- | +--ro remote-ipv4-router-id? ipv4-router-identifier
- | +--ro remote-ipv6-router-id? ipv6-router-identifier
- | +--ro mpls-protocol? mpls-protocol-mask
- | +--ro te-metric? netc:te-metric
- | +--ro metric? netc:metric
- | +--ro shared-risk-link-groups* rsvp:srlg-id
- | +--ro link-name? string
- | +--ro max-link-bandwidth? netc:bandwidth
- | +--ro max-reservable-bandwidth? netc:bandwidth
- | +--ro unreserved-bandwidth* [priority]
- | | +--ro priority uint8
- | | +--ro bandwidth? netc:bandwidth
- | +--ro link-protection? link-protection-type
- | +--ro admin-group? administrative-group
- | +--ro sr-adj-ids*
- | | +--ro (flags)?
- | | | +--:(ospf-adj-flags-case)
- | | | | +--ro backup? boolean
- | | | | +--ro set? boolean
- | | | +--:(isis-adj-flags-case)
- | | | +--ro backup? boolean
- | | | +--ro set? boolean
- | | | +--ro address-family? boolean
- | | +--ro weight? weight
- | | +--ro (sid-label-index)?
- | | +--:(local-label-case)
- | | | +--ro local-label? netc:mpls-label
- | | +--:(ipv6-address-case)
- | | | +--ro ipv6-address? inet:ipv6-address
- | | +--:(sid-case)
- | | +--ro sid? uint32
- | +--ro sr-lan-adj-ids*
- | | +--ro (flags)?
- | | | +--:(ospf-adj-flags-case)
- | | | | +--ro backup? boolean
- | | | | +--ro set? boolean
- | | | +--:(isis-adj-flags-case)
- | | | +--ro backup? boolean
- | | | +--ro set? boolean
- | | | +--ro address-family? boolean
- | | +--ro weight? weight
- | | +--ro iso-system-id? netc:iso-system-identifier
- | | +--ro neighbor-id? inet:ipv4-address
- | | +--ro (sid-label-index)?
- | | +--:(local-label-case)
- | | | +--ro local-label? netc:mpls-label
- | | +--:(ipv6-address-case)
- | | | +--ro ipv6-address? inet:ipv6-address
- | | +--:(sid-case)
- | | +--ro sid? uint32
- | +--ro peer-node-sid
- | | +--ro weight? weight
- | | +--ro (sid-label-index)?
- | | +--:(local-label-case)
- | | | +--ro local-label? netc:mpls-label
- | | +--:(ipv6-address-case)
- | | | +--ro ipv6-address? inet:ipv6-address
- | | +--:(sid-case)
- | | +--ro sid? uint32
- | +--ro peer-adj-sid
- | | +--ro weight? weight
- | | +--ro (sid-label-index)?
- | | +--:(local-label-case)
- | | | +--ro local-label? netc:mpls-label
- | | +--:(ipv6-address-case)
- | | | +--ro ipv6-address? inet:ipv6-address
- | | +--:(sid-case)
- | | +--ro sid? uint32
- | +--ro peer-set-sids*
- | +--ro weight? weight
- | +--ro (sid-label-index)?
- | +--:(local-label-case)
- | | +--ro local-label? netc:mpls-label
- | +--:(ipv6-address-case)
- | | +--ro ipv6-address? inet:ipv6-address
- | +--:(sid-case)
- | +--ro sid? uint32
- +--:(prefix-attributes-case)
- | +--ro prefix-attributes
- | +--ro igp-bits
- | | x--ro up-down? bits
- | | +--ro is-is-up-down? boolean
- | | +--ro ospf-no-unicast? boolean
- | | +--ro ospf-local-address? boolean
- | | +--ro ospf-propagate-nssa? boolean
- | +--ro route-tags* route-tag
- | +--ro extended-tags* extended-route-tag
- | +--ro prefix-metric? netc:igp-metric
- | +--ro ospf-forwarding-address? inet:ip-address
- | +--ro sr-prefix
- | | +--ro (flags)?
- | | | +--:(isis-prefix-flags-case)
- | | | | +--ro no-php? boolean
- | | | | +--ro explicit-null? boolean
- | | | | +--ro readvertisement? boolean
- | | | | +--ro node-sid? boolean
- | | | +--:(ospf-prefix-flags-case)
- | | | +--ro no-php? boolean
- | | | +--ro explicit-null? boolean
- | | | +--ro mapping-server? boolean
- | | +--ro algorithm? algorithm
- | | +--ro (sid-label-index)?
- | | +--:(local-label-case)
- | | | +--ro local-label? netc:mpls-label
- | | +--:(ipv6-address-case)
- | | | +--ro ipv6-address? inet:ipv6-address
- | | +--:(sid-case)
- | | +--ro sid? uint32
- | +--ro ipv6-sr-prefix
- | | +--ro algorithm? algorithm
- | +--ro sr-range
- | | +--ro inter-area? boolean
- | | +--ro range-size? uint16
- | | +--ro sub-tlvs*
- | | +--ro (range-sub-tlv)?
- | | +--:(binding-sid-tlv-case)
- | | | +--ro weight? weight
- | | | +--ro (flags)?
- | | | | +--:(isis-binding-flags-case)
- | | | | | +--ro address-family? boolean
- | | | | | +--ro mirror-context? boolean
- | | | | | +--ro spread-tlv? boolean
- | | | | | +--ro leaked-from-level-2? boolean
- | | | | | +--ro attached-flag? boolean
- | | | | +--:(ospf-binding-flags-case)
- | | | | +--ro mirroring? boolean
- | | | +--ro binding-sub-tlvs*
- | | | +--ro (binding-sub-tlv)?
- | | | +--:(prefix-sid-case)
- | | | | +--ro (flags)?
- | | | | | +--:(isis-prefix-flags-case)
- | | | | | | +--ro no-php? boolean
- | | | | | | +--ro explicit-null? boolean
- | | | | | | +--ro readvertisement? boolean
- | | | | | | +--ro node-sid? boolean
- | | | | | +--:(ospf-prefix-flags-case)
- | | | | | +--ro no-php? boolean
- | | | | | +--ro explicit-null? boolean
- | | | | | +--ro mapping-server? boolean
- | | | | +--ro algorithm? algorithm
- | | | | +--ro (sid-label-index)?
- | | | | +--:(local-label-case)
- | | | | | +--ro local-label? netc:mpls-label
- | | | | +--:(ipv6-address-case)
- | | | | | +--ro ipv6-address? inet:ipv6-address
- | | | | +--:(sid-case)
- | | | | +--ro sid? uint32
- | | | +--:(ipv6-prefix-sid-case)
- | | | | +--ro algorithm? algorithm
- | | | +--:(sid-label-case)
- | | | | +--ro (sid-label-index)?
- | | | | +--:(local-label-case)
- | | | | | +--ro local-label? netc:mpls-label
- | | | | +--:(ipv6-address-case)
- | | | | | +--ro ipv6-address? inet:ipv6-address
- | | | | +--:(sid-case)
- | | | | +--ro sid? uint32
- | | | +--:(ero-metric-case)
- | | | | +--ro ero-metric? netc:te-metric
- | | | +--:(ipv4-ero-case)
- | | | | +--ro loose? boolean
- | | | | +--ro address inet:ipv4-address
- | | | +--:(ipv6-ero-case)
- | | | | +--ro loose? boolean
- | | | | +--ro address inet:ipv6-address
- | | | +--:(unnumbered-interface-id-ero-case)
- | | | | +--ro loose? boolean
- | | | | +--ro router-id? uint32
- | | | | +--ro interface-id? uint32
- | | | +--:(ipv4-ero-backup-case)
- | | | | +--ro loose? boolean
- | | | | +--ro address inet:ipv4-address
- | | | +--:(ipv6-ero-backup-case)
- | | | | +--ro loose? boolean
- | | | | +--ro address inet:ipv6-address
- | | | +--:(unnumbered-interface-id-backup-ero-case)
- | | | +--ro loose? boolean
- | | | +--ro router-id? uint32
- | | | +--ro interface-id? uint32
- | | +--:(prefix-sid-tlv-case)
- | | | +--ro (flags)?
- | | | | +--:(isis-prefix-flags-case)
- | | | | | +--ro no-php? boolean
- | | | | | +--ro explicit-null? boolean
- | | | | | +--ro readvertisement? boolean
- | | | | | +--ro node-sid? boolean
- | | | | +--:(ospf-prefix-flags-case)
- | | | | +--ro no-php? boolean
- | | | | +--ro explicit-null? boolean
- | | | | +--ro mapping-server? boolean
- | | | +--ro algorithm? algorithm
- | | | +--ro (sid-label-index)?
- | | | +--:(local-label-case)
- | | | | +--ro local-label? netc:mpls-label
- | | | +--:(ipv6-address-case)
- | | | | +--ro ipv6-address? inet:ipv6-address
- | | | +--:(sid-case)
- | | | +--ro sid? uint32
- | | +--:(ipv6-prefix-sid-tlv-case)
- | | | +--ro algorithm? algorithm
- | | +--:(sid-label-tlv-case)
- | | +--ro (sid-label-index)?
- | | +--:(local-label-case)
- | | | +--ro local-label? netc:mpls-label
- | | +--:(ipv6-address-case)
- | | | +--ro ipv6-address? inet:ipv6-address
- | | +--:(sid-case)
- | | +--ro sid? uint32
- | +--ro sr-binding-sid-labels*
- | +--ro weight? weight
- | +--ro (flags)?
- | | +--:(isis-binding-flags-case)
- | | | +--ro address-family? boolean
- | | | +--ro mirror-context? boolean
- | | | +--ro spread-tlv? boolean
- | | | +--ro leaked-from-level-2? boolean
- | | | +--ro attached-flag? boolean
- | | +--:(ospf-binding-flags-case)
- | | +--ro mirroring? boolean
- | +--ro binding-sub-tlvs*
- | +--ro (binding-sub-tlv)?
- | +--:(prefix-sid-case)
- | | +--ro (flags)?
- | | | +--:(isis-prefix-flags-case)
- | | | | +--ro no-php? boolean
- | | | | +--ro explicit-null? boolean
- | | | | +--ro readvertisement? boolean
- | | | | +--ro node-sid? boolean
- | | | +--:(ospf-prefix-flags-case)
- | | | +--ro no-php? boolean
- | | | +--ro explicit-null? boolean
- | | | +--ro mapping-server? boolean
- | | +--ro algorithm? algorithm
- | | +--ro (sid-label-index)?
- | | +--:(local-label-case)
- | | | +--ro local-label? netc:mpls-label
- | | +--:(ipv6-address-case)
- | | | +--ro ipv6-address? inet:ipv6-address
- | | +--:(sid-case)
- | | +--ro sid? uint32
- | +--:(ipv6-prefix-sid-case)
- | | +--ro algorithm? algorithm
- | +--:(sid-label-case)
- | | +--ro (sid-label-index)?
- | | +--:(local-label-case)
- | | | +--ro local-label? netc:mpls-label
- | | +--:(ipv6-address-case)
- | | | +--ro ipv6-address? inet:ipv6-address
- | | +--:(sid-case)
- | | +--ro sid? uint32
- | +--:(ero-metric-case)
- | | +--ro ero-metric? netc:te-metric
- | +--:(ipv4-ero-case)
- | | +--ro loose? boolean
- | | +--ro address inet:ipv4-address
- | +--:(ipv6-ero-case)
- | | +--ro loose? boolean
- | | +--ro address inet:ipv6-address
- | +--:(unnumbered-interface-id-ero-case)
- | | +--ro loose? boolean
- | | +--ro router-id? uint32
- | | +--ro interface-id? uint32
- | +--:(ipv4-ero-backup-case)
- | | +--ro loose? boolean
- | | +--ro address inet:ipv4-address
- | +--:(ipv6-ero-backup-case)
- | | +--ro loose? boolean
- | | +--ro address inet:ipv6-address
- | +--:(unnumbered-interface-id-backup-ero-case)
- | +--ro loose? boolean
- | +--ro router-id? uint32
- | +--ro interface-id? uint32
- x--:(te-lsp-attributes-case)
- +--ro te-lsp-attributes
-
-
-Usage
-^^^^^
-The Link-State table in a instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-linkstate:linkstate-address-family/bgp-linkstate:linkstate-subsequent-address-family/linkstate-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <linkstate-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-linkstate">
- ...
- </linkstate-routes>
-
-.. note:: Link-State routes mapping to topology links/nodes/prefixes is supported by BGP Topology Provider.
-
-References
-^^^^^^^^^^
-* `North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP <https://tools.ietf.org/html/rfc7752>`_
-* `BGP Link-State extensions for Segment Routing <https://tools.ietf.org/html/draft-gredler-idr-bgp-ls-segment-routing-ext-03>`_
-* `Segment Routing BGP Egress Peer Engineering BGP-LS Extensions <https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-05>`_
-* `BGP Link-State Information Distribution Implementation Report <https://tools.ietf.org/html/draft-ietf-idr-ls-distribution-impl-04>`_
+++ /dev/null
-.. _bgp-user-guide-mvpn-family:
-
-MCAST-VPN Family
-================
-The BGP Multicast VPN(BGP MCAST-VPN) Multiprotocol extension can be used for MVPN auto-discovery, advertising MVPN to Inclusive P-Multicast Service
-Interface (I-PMSI) tunnel binding, advertising (C-S,C-G) to Selective PMSI (S-PMSI) tunnel binding, VPN customer multicast routing
-information exchange among Provider Edge routers (PEs), choosing a single forwarder PE, and for procedures in support of co-locating a
-Customer Rendezvous Point (C-RP) on a PE.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-This section shows a way to enable MCAST-VPN family in BGP speaker and peer configuration.
-
-BGP Speaker
-'''''''''''
-To enable MCAST-VPN support in BGP plugin, first configure BGP speaker instance:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <protocol xmlns="http://openconfig.net/yang/network-instance">
- <name>bgp-example</name>
- <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
- <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <global>
- <config>
- <router-id>192.0.2.2</router-id>
- <as>65000</as>
- </config>
- <afi-safis>
- <afi-safi>
- <afi-safi-name>IPV4-MCAST-VPN</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV6-MCAST-VPN</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </global>
- </bgp>
- </protocol>
-
-BGP Peer
-''''''''
-Here is an example for BGP peer configuration with enabled IPV4 MCAST-VPN family.
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.1</neighbor-address>
- <afi-safis>
- <afi-safi>
- <afi-safi-name>IPV4-MCAST-VPN</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </neighbor>
-
-Ipv4 MCAST-VPN Route API
-^^^^^^^^^^^^^^^^^^^^^^^^
-Following tree illustrates the BGP MCAST-VPN route structure.
-
-.. code-block:: console
-
- :(mvpn-routes-ipv4-case)
- +--ro mvpn-routes-ipv4
- +--ro mvpn-route* [route-key path-id]
- +--ro (mvpn-choice)
- +--:(intra-as-i-pmsi-a-d-case)
- | +--ro intra-as-i-pmsi-a-d
- +--:(inter-as-i-pmsi-a-d-case)
- | +--ro inter-as-i-pmsi-a-d
- | +--ro source-as inet:as-number
- +--:(s-pmsi-a-d-case)
- | +--ro s-pmsi-a-d
- | +--ro multicast-source inet:ip-address
- | +--ro (multicast-group)?
- | +--:(c-g-address-case)
- | | +--ro c-g-address? inet:ip-address
- | +--:(ldp-mp-opaque-value-case)
- | +--ro ldp-mp-opaque-value
- | +--ro opaque-type uint8
- | +--ro opaque-extended-type? uint16
- | +--ro opaque yang:hex-string
- +--:(leaf-a-d-case)
- | +--ro leaf-a-d
- | +--ro (leaf-a-d-route-key)
- | +--:(inter-as-i-pmsi-a-d-case)
- | | +--ro inter-as-i-pmsi-a-d
- | | +--ro source-as inet:as-number
- | +--:(s-pmsi-a-d-case)
- | +--ro s-pmsi-a-d
- | +--ro multicast-source inet:ip-address
- | +--ro (multicast-group)?
- | +--:(c-g-address-case)
- | | +--ro c-g-address? inet:ip-address
- | +--:(ldp-mp-opaque-value-case)
- | +--ro ldp-mp-opaque-value
- | +--ro opaque-type uint8
- | +--ro opaque-extended-type? uint16
- | +--ro opaque yang:hex-string
- +--:(source-active-a-d-case)
- | +--ro source-active-a-d
- | +--ro multicast-source inet:ip-address
- | +--ro multicast-group inet:ip-address
- +--:(shared-tree-join-case)
- | +--ro shared-tree-join
- | +--ro c-multicast
- | +--ro multicast-source inet:ip-address
- | +--ro source-as inet:as-number
- | +--ro (multicast-group)?
- | +--:(c-g-address-case)
- | | +--ro c-g-address? inet:ip-address
- | +--:(ldp-mp-opaque-value-case)
- | +--ro ldp-mp-opaque-value
- | +--ro opaque-type uint8
- | +--ro opaque-extended-type? uint16
- | +--ro opaque yang:hex-string
- +--:(source-tree-join-case)
- +--ro source-tree-join
- +--ro c-multicast
- +--ro multicast-source inet:ip-address
- +--ro source-as inet:as-number
- +--ro (multicast-group)?
- +--:(c-g-address-case)
- | +--ro c-g-address? inet:ip-address
- +--:(ldp-mp-opaque-value-case)
- +--ro ldp-mp-opaque-value
- +--ro opaque-type uint8
- +--ro opaque-extended-type? uint16
- +--ro opaque yang:hex-string
- ...
-
-Ipv6 MCAST-VPN Route API
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-Following tree illustrates the BGP MCAST-VPN route structure.
-
-.. code-block:: console
-
- :(mvpn-routes-ipv6-case)
- +--ro mvpn-routes-ipv6
- +--ro mvpn-route* [route-key path-id]
- +--ro (mvpn-choice)
- +--:(intra-as-i-pmsi-a-d-case)
- | +--ro intra-as-i-pmsi-a-d
- +--:(inter-as-i-pmsi-a-d-case)
- | +--ro inter-as-i-pmsi-a-d
- | +--ro source-as inet:as-number
- +--:(s-pmsi-a-d-case)
- | +--ro s-pmsi-a-d
- | +--ro multicast-source inet:ip-address
- | +--ro (multicast-group)?
- | +--:(c-g-address-case)
- | | +--ro c-g-address? inet:ip-address
- | +--:(ldp-mp-opaque-value-case)
- | +--ro ldp-mp-opaque-value
- | +--ro opaque-type uint8
- | +--ro opaque-extended-type? uint16
- | +--ro opaque yang:hex-string
- +--:(leaf-a-d-case)
- | +--ro leaf-a-d
- | +--ro (leaf-a-d-route-key)
- | +--:(inter-as-i-pmsi-a-d-case)
- | | +--ro inter-as-i-pmsi-a-d
- | | +--ro source-as inet:as-number
- | +--:(s-pmsi-a-d-case)
- | +--ro s-pmsi-a-d
- | +--ro multicast-source inet:ip-address
- | +--ro (multicast-group)?
- | +--:(c-g-address-case)
- | | +--ro c-g-address? inet:ip-address
- | +--:(ldp-mp-opaque-value-case)
- | +--ro ldp-mp-opaque-value
- | +--ro opaque-type uint8
- | +--ro opaque-extended-type? uint16
- | +--ro opaque yang:hex-string
- +--:(source-active-a-d-case)
- | +--ro source-active-a-d
- | +--ro multicast-source inet:ip-address
- | +--ro multicast-group inet:ip-address
- +--:(shared-tree-join-case)
- | +--ro shared-tree-join
- | +--ro c-multicast
- | +--ro multicast-source inet:ip-address
- | +--ro source-as inet:as-number
- | +--ro (multicast-group)?
- | +--:(c-g-address-case)
- | | +--ro c-g-address? inet:ip-address
- | +--:(ldp-mp-opaque-value-case)
- | +--ro ldp-mp-opaque-value
- | +--ro opaque-type uint8
- | +--ro opaque-extended-type? uint16
- | +--ro opaque yang:hex-string
- +--:(source-tree-join-case)
- +--ro source-tree-join
- +--ro c-multicast
- +--ro multicast-source inet:ip-address
- +--ro source-as inet:as-number
- +--ro (multicast-group)?
- +--:(c-g-address-case)
- | +--ro c-g-address? inet:ip-address
- +--:(ldp-mp-opaque-value-case)
- +--ro ldp-mp-opaque-value
- +--ro opaque-type uint8
- +--ro opaque-extended-type? uint16
- +--ro opaque yang:hex-string
- ...
-
-Usage
-^^^^^
-The Ipv4 Multicast VPN table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-mvpn:mcast-vpn-subsequent-address-family/bgp-mvpn-ipv4:mvpn-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <mvpn-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp:mvpn:ipv4">
- <mvpn-route>
- <route-key>flow1</route-key>
- <path-id>0</path-id>
- <intra-as-i-pmsi-a-d>
- <route-distinguisher>172.16.0.44:101</route-distinguisher>
- <orig-route-ip>192.168.100.1</orig-route-ip>
- </intra-as-i-pmsi-a-d>
- <attributes>
- <ipv4-next-hop>
- <global>199.20.166.41</global>
- </ipv4-next-hop>
- <as-path/>
- <origin>
- <value>igp</value>
- </origin>
- </attributes>
- </mvpn-route>
- </mvpn-routes>
-
-The Ipv6 Multicast VPN table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-mvpn:mcast-vpn-subsequent-address-family/bgp-mvpn-ipv6:mvpn-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <mvpn-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp:mvpn:ipv6">
- <mvpn-route>
- <route-key>flow1</route-key>
- <path-id>0</path-id>
- <intra-as-i-pmsi-a-d>
- <route-distinguisher>172.16.0.44:101</route-distinguisher>
- <orig-route-ip>192.168.100.1</orig-route-ip>
- </intra-as-i-pmsi-a-d>
- <attributes>
- <ipv6-next-hop>
- <global>2001:db8:1::6</global>
- </ipv6-next-hop>
- <as-path/>
- <origin>
- <value>igp</value>
- </origin>
- </attributes>
- </mvpn-route>
- </mvpn-routes>
-
-Programming
-^^^^^^^^^^^
-These examples show how to originate and remove MCAST-VPN routes via programmable RIB.
-There are seven different types of MCAST-VPN routes, and multiples extended communities.
-Routes can be used for variety of use-cases supported by BGP/MPLS MCAST-VPN.
-Make sure the *Application Peer* is configured first.
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-mvpn:mcast-vpn-subsequent-address-family/bgp-mvpn-ipv4:mvpn-routes``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 4,17
-
- <mvpn-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp:mvpn:ipv4">
- <route-key>mvpn</route-key>
- <path-id>0</path-id>
- <intra-as-i-pmsi-a-d>
- <route-distinguisher>172.16.0.44:101</route-distinguisher>
- <orig-route-ip>192.168.100.1</orig-route-ip>
- </intra-as-i-pmsi-a-d>
- ....
- <attributes>
- <ipv4-next-hop>
- <global>199.20.166.41</global>
- </ipv4-next-hop>
- <as-path/>
- <origin>
- <value>igp</value>
- </origin>
- <extended-communities>
- ....
- </extended-communities>
- </attributes>
- </mvpn-route>
-
-@line 4: One of the MCAST-VPN route must be set here.
-
-@line 15: In some cases, specific extended community presence is required.
-
------
-
-**MVPN Routes:**
-
-* **Intra-AS I-PMSI A-D**
- .. code-block:: xml
-
- <intra-as-i-pmsi-a-d>
- <route-distinguisher>0:5:3</route-distinguisher>
- <orig-route-ip>10.10.10.10</orig-route-ip>
- </intra-as-i-pmsi-a-d>
-
-* **Inter-AS I-PMSI A-D**
- .. code-block:: xml
-
- <inter-as-i-pmsi-a-d>
- <route-distinguisher>1.2.3.4:258</route-distinguisher>
- <source-as>64496</source-as>
- </inter-as-i-pmsi-a-d>
-
-* **S-PMSI A-D**
- .. code-block:: xml
-
- <s-pmsi-a-d>
- <route-distinguisher>1.2.3.4:258</route-distinguisher>
- <multicast-source>10.0.0.10</multicast-source>
- <c-g-address>12.0.0.12</c-g-address>
- <orig-route-ip>1.0.0.1</orig-route-ip>
- </s-pmsi-a-d>
-
- .. code-block:: xml
-
- <s-pmsi-a-d>
- <route-distinguisher>1.2.3.4:258</route-distinguisher>
- <multicast-source>10.0.0.10</multicast-source>
- <ldp-mp-opaque-value>
- <opaque-type>1</opaque-type>
- <opaque-extended-type>0</opaque-extended-type>
- <opaque>das75das48bvxc</opaque>
- </ldp-mp-opaque-value>
- <orig-route-ip>1.0.0.1</orig-route-ip>
- </s-pmsi-a-d>
-
-* **Leaf A-D**
- .. code-block:: xml
-
- <leaf-a-d>
- <inter-as-i-pmsi-a-d>
- <route-distinguisher>1.2.3.4:258</route-distinguisher>
- <source-as>1</source-as>
- </inter-as-i-pmsi-a-d>
- <orig-route-ip>1.0.0.1</orig-route-ip>
- </leaf-a-d>
-
- .. code-block:: xml
-
- <leaf-a-d>
- <s-pmsi-a-d>
- <route-distinguisher>1.2.3.4:258</route-distinguisher>
- <multicast-source>10.0.0.10</multicast-source>
- <ldp-mp-opaque-value>
- <opaque-type>1</opaque-type>
- <opaque-extended-type>0</opaque-extended-type>
- <opaque>das75das48bvxc</opaque>
- </ldp-mp-opaque-value>
- <orig-route-ip>1.0.0.1</orig-route-ip>
- </s-pmsi-a-d>
- <orig-route-ip>1.0.0.1</orig-route-ip>
- </leaf-a-d>
-
-* **Source Active A-D**
- .. code-block:: xml
-
- <source-active-a-d>
- <route-distinguisher>1.2.3.4:258</route-distinguisher>
- <multicast-source>1.0.0.1</multicast-source>
- <multicast-group>2.0.0.2</multicast-group>
- </source-active-a-d>
-
-* **Shared Tree Join**
- .. code-block:: xml
-
- <shared-tree-join>
- <c-multicast>
- <route-distinguisher>1.2.3.4:258</route-distinguisher>
- <source-as>64415</source-as>
- <multicast-source>1.0.0.1</multicast-source>
- <c-g-address>2.0.0.2</c-g-address>
- </c-multicast>
- </shared-tree-join>
-
- .. code-block:: xml
-
- <shared-tree-join>
- <c-multicast>
- <route-distinguisher>1.2.3.4:258</route-distinguisher>
- <source-as>64415</source-as>
- <multicast-source>1.0.0.1</multicast-source>
- <ldp-mp-opaque-value>
- <opaque-type>1</opaque-type>
- <opaque-extended-type>0</opaque-extended-type>
- <opaque>das75das48bvxc</opaque>
- </ldp-mp-opaque-value>
- </c-multicast>
- </shared-tree-join>
-
-* **Source Tree Join**
- .. code-block:: xml
-
- <source-tree-join>
- <c-multicast>
- <route-distinguisher>1.2.3.4:258</route-distinguisher>
- <source-as>64415</source-as>
- <multicast-source>1.0.0.1</multicast-source>
- <c-g-address>2.0.0.2</c-g-address>
- </c-multicast>
- </source-tree-join>
-
- .. code-block:: xml
-
- <source-tree-join>
- <c-multicast>
- <route-distinguisher>1.2.3.4:258</route-distinguisher>
- <source-as>64415</source-as>
- <multicast-source>1.0.0.1</multicast-source>
- <ldp-mp-opaque-value>
- <opaque-type>1</opaque-type>
- <opaque-extended-type>0</opaque-extended-type>
- <opaque>das75das48bvxc</opaque>
- </ldp-mp-opaque-value>
- </c-multicast>
- </source-tree-join>
-
-**Attributes:**
-
-.. include:: bgp-user-guide-pmsi-attribute.rst
-
-* **PE Distinguisher Labels Attribute**
- .. code-block:: xml
-
- <pe-distinguisher-labels-attribute>
- <pe-distinguisher-label-attribute>
- <pe-address>10.10.10.1</pe-address>
- <mpls-label>20024</mpls-label>
- </pe-distinguisher-label-attribute>
- <pe-distinguisher-label-attribute>
- <pe-address>10.10.20.2</pe-address>
- <mpls-label>20028</mpls-label>
- </pe-distinguisher-label-attribute>
- </pe-distinguisher-labels-attribute>
-
-**Extended Communities:**
-
-* **Source AS Extended Community**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <source-as-extended-community>
- <global-administrator>65</global-administrator>
- </source-as-extended-community>
- </extended-communities>
-
-* **Source AS 4 Octets Extended Community**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <source-as-4-extended-community>
- <global-administrator>65555</global-administrator>
- </source-as-4-extended-community>
- </extended-communities>
-
-* **ES-Import Route Target**
- .. code-block:: xml
-
- <extended-communities>
- <transitive>true</transitive>
- <vrf-route-import-extended-community>
- <inet4-specific-extended-community-common>
- <global-administrator>10.0.0.1</global-administrator>
- <local-administrator>123=</local-administrator>
- </inet4-specific-extended-community-common>
- </vrf-route-import-extended-community>
- </extended-communities>
-
------
-
-To remove the route added above, following request can be used:
-
-**URL:** ``/restconf/config/bgp-rib:application-rib/10.25.1.9/tables/bgp-types:ipv4-address-family/bgp-mvpn:mcast-vpn-subsequent-address-family/bgp-mvpn-ipv4:mvpn-routes/mvpn-route/mvpn/0``
-
-**Method:** ``DELETE``
-
-References
-^^^^^^^^^^
-* `Multicast in MPLS/BGP IP VPNs <https://tools.ietf.org/html/rfc6513>`_
-* `BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs <https://tools.ietf.org/html/rfc6514>`_
-* `IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN <https://tools.ietf.org/html/rfc6515>`_
+++ /dev/null
-.. _bgp-user-guide-operational-state:
-
-Operational State
-=================
-
-The OpenDaylight BGP implementation provides a set of APIs (described below), that give its operational state refreshed periodically, by default every 5 seconds.
-The following APIs describe what is available starting with how to change the default refresh rate.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Operational State Configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**URL:** ``/restconf/config/bgp-state-config:bgp-state-config``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <bgp-state-config xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <config-name xmlns="urn:opendaylight:params:xml:ns:yang:bgp-state-config">operationalState</config-name>
- <timer xmlns="urn:opendaylight:params:xml:ns:yang:bgp-state-config">1</timer>
- </bgp-state-config>
-
-@line 3: Time in seconds between operational state update.
-
-BGP RIB Operational State
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/global/state``
-
-**Method:** ``GET``
-
-**Content-Type:** ``application/xml``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
-
- <state xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <as>65000</as>
- <router-id>192.0.2.2</router-id>
- <total-paths>0</total-paths>
- <total-prefixes>0</total-prefixes>
- </state>
-
-@line 2: AS number of the remote peer.
-
-@line 3: The unique protocol instance identifier.
-
-@line 4: Total number of Paths installed on RIB (Loc-RIB)
-
-@line 5: Total number of Prefixes installed on RIB (Loc-RIB)
-
-BGP RIB Families Operational State
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/global/afi-safis``
-
-**Method:** ``GET``
-
-**Content-Type:** ``application/xml``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5,6
-
- <afi-safis xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
- <state>
- <total-paths>0</total-paths>
- <total-prefixes>0</total-prefixes>
- </state>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-UNICAST</afi-safi-name>
- <state>
- <total-paths>0</total-paths>
- <total-prefixes>0</total-prefixes>
- </state>
- </afi-safi>
- ....
- </afi-safis>
-
-@line 3: Family Identifier.
-
-@line 5: Total number of Paths installed on RIB (Loc-RIB) per specific family.
-
-@line 6: Total number of Prefixes installed on RIB (Loc-RIB) per specific family.
-
-BGP Neighbors Operational State
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``GET``
-
-**Content-Type:** ``application/xml``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <neighbors xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor>
- <neighbor-address>192.0.2.1</neighbor-address>
- .....
- </neighbor>
- <neighbor>
- <neighbor-address>192.0.2.2</neighbor-address>
- .....
- </neighbor>
- </neighbors>
-
-@line 3: IP address of the remote BGP peer. Also serves as an unique identifier of a neighbor in a list of neighbors.
-
-BGP Neighbor Operational State
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note:: Supported Capabilities only provided when session has been established.
-
-**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors/neighbor/127.0.0.2/state``
-
-**Method:** ``GET``
-
-**Content-Type:** ``application/xml``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,3,4,7,8,11,12
-
- <state xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <session-state>ESTABLISHED</session-state>
- <supported-capabilities xmlns:x="http://openconfig.net/yang/bgp-types">x:ASN32</supported-capabilities>
- <supported-capabilities xmlns:x="http://openconfig.net/yang/bgp-types">x:MPBGP</supported-capabilities>
- <messages>
- <sent>
- <UPDATE>0</UPDATE>
- <NOTIFICATION>0</NOTIFICATION>
- </sent>
- <received>
- <UPDATE>4</UPDATE>
- <NOTIFICATION>0</NOTIFICATION>
- </received>
- </messages>
- </state>
-
-@line 2: Session status
-
-@line 3-4: BGP capabilities supported ( ASN32 / MPBGP / ROUTE_REFRESH / GRACEFUL_RESTART / ADD_PATHS)
-
-@line 7: Total count of Update Messages sent
-
-@line 8: Total count of Notification Messages sent
-
-@line 11: Total count of Update Messages received
-
-@line 12: Total count of Notification Messages received
-
-BGP Neighbor Families Operational State
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note:: Graceful Restart not supported yet. Planned for Carbon.
-
-
-**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors/neighbor/192.0.2.1/afi-safis``
-
-**Method:** ``GET``
-
-**Content-Type:** ``application/xml``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5,7,9,10
-
- <afi-safis xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
- <state>
- <active>false</active>
- </state>
- <graceful-restart>
- <state>
- <received>false</received>
- <advertised>false</advertised>
- </state>
- </graceful-restart>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-UNICAST</afi-safi-name>
- <state>
- <active>false</active>
- </state>
- <graceful-restart>
- <state>
- <received>false</received>
- <advertised>false</advertised>
- </state>
- </graceful-restart>
- </afi-safi>
- </afi-safis>
-
-@line 3: Family Identifier.
-
-@line 5: True if family is advertized by peer.
-
-@line 7: Graceful Restart Operational State per specific family.
-
-@line 9: True if the peer supports graceful restart.
-
-@line 10: True if we support graceful restart.
-
-BGP Neighbor Family Operational State
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note:: Prefixes state is only provided once session is established.
-.. note:: Graceful Restart not supported yet. Planned to be implemented in Carbon.
-
-**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors/neighbor/192.0.2.1/afi-safis/afi-safi/openconfig-bgp-types:IPV4%2DUNICAST``
-
-**Method:** ``GET``
-
-**Content-Type:** ``application/xml``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,4,6,7,8
-
- <afi-safi xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
- <state>
- <active>true</active>
- <prefixes>
- <installed>3</installed>
- <sent>0</sent>
- <received>3</received>
- </prefixes>
- </state>
- <graceful-restart>
- <state>
- <received>false</received>
- <advertised>false</advertised>
- </state>
- </graceful-restart>
- </afi-safi>
-
-@line 2: Family Identifier.
-
-@line 4: True if family is advertized to and by peer.
-
-@line 6: Total count of prefixes advertized by peer and installed (effective-rib-in).
-
-@line 7: Total count of prefixes advertized to peer (adj-rib-out).
-
-@line 8: Total count of prefixes advertized by peer (adj-rib-in).
-
-BGP Neighbor Timers Operational State
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note:: State is only provided once session is established.
-
-**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors/neighbor/192.0.2.1/timers``
-
-**Method:** ``GET``
-
-**Content-Type:** ``application/xml``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,4
-
- <timers xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <state>
- <negotiated-hold-time>180</negotiated-hold-time>
- <uptime>1580676</uptime>
- </state>
- </timers>
-
-@line 3: The negotiated hold-time for the BGP session in seconds.
-
-@line 4: Session duration since establishment in milliseconds.
-
-BGP Neighbor Transport Operational State
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note:: State is only provided once session is established.
-
-**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors/neighbor/192.0.2.1/transport``
-
-**Method:** ``GET``
-
-**Content-Type:** ``application/xml``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,4,5
-
- <transport xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <state>
- <remote-address>127.0.0.2</remote-address>
- <remote-port>44718</remote-port>
- <local-port>1790</local-port>
- </state>
- </transport>
-
-@line 3: IP address of the remote BGP peer.
-
-@line 4: Port of the remote BGP peer.
-
-@line 5: Local port.
-
-BGP Neighbor Error Handling Operational State
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note:: State is only provided once session is established.
-.. note:: Error handling not supported yet. Planned for Carbon.
-
-**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors/neighbor/192.0.2.1/error-handling``
-
-**Method:** ``GET``
-
-**Content-Type:** ``application/xml``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <error-handling xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <state>
- <erroneous-update-messages>0</erroneous-update-messages>
- </state>
- </error-handling>
-
-@line 3: The number of BGP UPDATE messages for which the treat-as-withdraw mechanism has been applied based on
-erroneous message contents
-
-BGP Neighbor Graceful Restart Operational State
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note:: Graceful Restart not supported yet. Planned for Carbon.
-
-**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors/neighbor/192.0.2.1/graceful-restart``
-
-**Method:** ``GET``
-
-**Content-Type:** ``application/xml``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,4,5
-
- <graceful-restart xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <state>
- <peer-restart-time>0</peer-restart-time>
- <peer-restarting>false</peer-restarting>
- <local-restarting>false</local-restarting>
- </state>
- </graceful-restart>
-
-@line 3: The period of time (advertised by the peer) that the peer expects a restart of a BGP session to take.
-
-@line 4: This flag indicates whether the remote neighbor is currently in the process of restarting, and hence
-received routes are currently stale.
-
-@line 5: This flag indicates whether the local neighbor is currently restarting. The flag is unset after all NLRI
-have been advertised to the peer, and the End-of-RIB (EOR) marker has been unset.
-
-BGP Peer Groups Operational State
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/peer-groups``
-
-**Method:** ``GET``
-
-**Content-Type:** ``application/xml``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5,6
-
- <peer-groups>
- <peer-group>
- <peer-group-name>application-peers</peer-group-name>
- <state>
- <total-paths>0</total-paths>
- <total-prefixes>0</total-prefixes>
- </state>
- </peer-group>
- </peer-groups>
-
-@line 3: Peer Group Identifier.
-
-@line 5: At this moment the cost for count path under effect-rib-in is to high. Therefore the value is the same as total prefixes.
-
-@line 6: Total Prefixes installed under by peers pertaining to this peer group (effective-rib-in).
-This count doesn't differentiate repeated prefixes.
-
-CLI
----
-
-BGP Karaf Console (odl-bgpcep-bgp-cli) provides a CLI feature to read operational state per RIB, Neighbor and Peer Group.
-
-.. code-block:: bash
- :linenos:
-
- opendaylight-user@root> bgp:operational-state -rib example-bgp-rib
-
-.. code-block:: bash
- :linenos:
-
- opendaylight-user@root> bgp:operational-state -rib example-bgp-rib -neighbor 192.0.2.1
-
-.. code-block:: bash
- :linenos:
-
- opendaylight-user@root> bgp:operational-state -rib -peer-group application-peers
+++ /dev/null
-.. _bgp-user-guide-overview:
-
-Overview
-========
-This section provides high-level overview of the Border Gateway Protocol, OpenDaylight implementation and BGP usage in SDN era.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Border Gateway Protocol
-^^^^^^^^^^^^^^^^^^^^^^^
-The Border Gateway Protocol (BGP) is an inter-Autonomous System (AS) routing protocol.
-The primary role of the BGP is an exchange of routes among other BGP systems.
-The route is an unit of information which pairs destination (IP address prefix) with attributes to the path with the destination.
-One of the most interesting attributes is a list of ASes that the route traversed - essential when avoiding loop routing.
-Advertised routes are stored in the Routing Information Bases (RIBs). Routes are later used to forward packets, stored in Routing Table for this purpose.
-The main advantage of the BGP over other routing protocols is its scalability, thus it has become the standardized Internet routing protocol (Internet is a set of ASes).
-
-BGP in SDN
-^^^^^^^^^^
-However BGP evolved long time before SDN was born, it plays a significant role in many SDN use-cases.
-Also, continuous evolution of the protocol brings extensions that are very well suited for SDN.
-Nowadays, BGP can carry various types of routing information - L3VPN, L2VPN, IP multicast, linkstate, etc.
-Here is a brief list of software-based/legacy-network technologies where BGP-based SDN solution get into an action:
-
-* SDN WAN - WAN orchestration and optimization
-* SDN router - Turns switch into an Internet router
-* Virtual Route Reflector - High-performance server-based BGP Route Reflector
-* SDX - A Software Defined Internet Exchange controller
-* Large-Scale Data Centers - BGP Data Center Routing, MPLS/SR in DCs, DC interconnection
-* DDoS mitigation - Traffic Filtering distribution with BGP
-
-OpenDaylight BGP plugin
-^^^^^^^^^^^^^^^^^^^^^^^
-The OpenDaylight controller provides an implementation of BGP (RFC 4271) as a south-bound protocol plugin.
-The implementation renders all basic *BGP speaker capabilities*:
-
-* inter/intra-AS peering
-* routes advertising
-* routes originating
-* routes storage
-
-The plugin's **north-bound API** (``REST``/``Java``) provides to user:
-
-* fully dynamic runtime standardized BGP configuration
-* read-only access to all RIBs
-* read-write programmable RIBs
-* read-only reachability/linkstate topology view
-
-.. note:: The BGP plugin is NOT a virtual router - does not construct Routing Tables, nor forward traffic.
+++ /dev/null
-PSMI Attribute
-==============
-
-* **P-Multicast Service Interface Tunnel (PMSI) attribute:**
-
- - **RSVP-TE P2MP LSP**
-
- .. code-block:: xml
-
- <pmsi-tunnel>
- <leaf-information-required>true</leaf-information-required>
- <mpls-label>20024</mpls-label>
- <rsvp-te-p2mp-lsp>
- <p2mp-id>1111111111</p2mp-id>
- <tunnel-id>11111</tunnel-id>
- <extended-tunnel-id>10.10.10.10</extended-tunnel-id>
- </rsvp-te-p2mp-lsp>
- </pmsi-tunnel>
-
- - **mLDP P2MP LSP**
-
- .. code-block:: xml
-
- <pmsi-tunnel>
- <leaf-information-required>true</leaf-information-required>
- <mpls-label>20024</mpls-label>
- <mldp-p2mp-lsp>
- <address-family xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</address-family>
- <root-node-address>10.10.10.10</root-node-address>
- <opaque-value>
- <opaque-type>255</opaque-type>
- <opaque-extended-type>11111</opaque-extended-type>
- <opaque>aa:aa:aa</opaque>
- </opaque-value>
- </mldp-p2mp-lsp>
- </pmsi-tunnel>
-
- - **PIM-SSM Tree**
-
- .. code-block:: xml
-
- <pmsi-tunnel>
- <leaf-information-required>true</leaf-information-required>
- <mpls-label>20024</mpls-label>
- <pim-ssm-tree>
- <p-address>11.12.13.14</p-address>
- <p-multicast-group>10.10.10.10</p-multicast-group>
- </pim-ssm-tree>
- </pmsi-tunnel>
-
- - **PIM-SM Tree**
-
- .. code-block:: xml
-
- <pmsi-tunnel>
- <leaf-information-required>true</leaf-information-required>
- <mpls-label>20024</mpls-label>
- <pim-sm-tree>
- <p-address>1.0.0.1</p-address>
- <p-multicast-group>10.10.10.10</p-multicast-group>
- </pim-sm-tree>
- </pmsi-tunnel>
-
- - **BIDIR-PIM Tree**
-
- .. code-block:: xml
-
- <pmsi-tunnel>
- <leaf-information-required>true</leaf-information-required>
- <mpls-label>20024</mpls-label>
- <bidir-pim-tree>
- <p-address>1.0.0.1</p-address>
- <p-multicast-group>10.10.10.10</p-multicast-group>
- </bidir-pim-tree>
- </pmsi-tunnel>
-
- - **Ingress Replication**
-
- .. code-block:: xml
-
- <pmsi-tunnel>
- <leaf-information-required>true</leaf-information-required>
- <mpls-label>20024</mpls-label>
- <ingress-replication>
- <receiving-endpoint-address>172.12.123.3</receiving-endpoint-address>
- </ingress-replication>
- </pmsi-tunnel>
-
- - **mLDP MP2MP LSP**
-
- .. code-block:: xml
-
- <pmsi-tunnel>
- <leaf-information-required>true</leaf-information-required>
- <mpls-label>20024</mpls-label>
- <mldp-mp2mp-lsp>
- <opaque-type>255</opaque-type>
- <opaque-extended-type>11111</opaque-extended-type>
- <opaque>aa:aa</opaque>
- </mldp-mp2mp-lsp>
- </pmsi-tunnel>
+++ /dev/null
-.. _bgp-user-guide-protocol-configuration-loader:
-
-BGP Protocol Configuration Loader
-=================================
-
-BGP Protocol Configuration Loader allows the user to define the static initial
-configuration for a BGP protocol instance.
-This service will detect the creation of new configuration files following the
-pattern ``protocols-*.xml`` under the path "etc/opendaylight/bgpcep".
-Once the file is processed, the defined configuration will be available from
-the configuration Data Store.
-
-.. note:: If the BGP instance is already present, no update or configuration will be applied.
-
-**PATH:** ``etc/opendaylight/bgpcep/protocols-config.xml``
-
-.. code-block:: xml
-
- <protocols xmlns="http://openconfig.net/yang/network-instance">
- <protocol>
- <name>example-bgp-rib</name>
- <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
- <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <global>
- <config>
- <router-id>192.0.2.2</router-id>
- <as>64496</as>
- <!-- if cluster-id is not present, it's value is the same as bgp-id -->
- <!-- <route-reflector-cluster-id>192.0.2.3</route-reflector-cluster-id> -->
- <!-- <read-only-limit>120</read-only-limit>-->
- </config>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
- <!--Advertise N Paths
- <receive>true</receive>
- <send-max>2</send-max>-->
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-LABELLED-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-LABELLED-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV4-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV6-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L2VPN-EVPN</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>LINKSTATE</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV4-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV6-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV4-L3VPN-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV6-L3VPN-FLOW</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </global>
- <neighbors xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.1</neighbor-address>
- <config>
- <peer-type>INTERNAL</peer-type>
- <peer-as>64496</peer-as>
- </config>
- <transport>
- <config>
- <remote-port>179</remote-port>
- <passive-mode>true</passive-mode>
- </config>
- </transport>
- <timers>
- <config>
- <hold-time>180</hold-time>
- <connect-retry>10</connect-retry>
- </config>
- </timers>
- <route-reflector>
- <config>
- <route-reflector-client>false</route-reflector-client>
- </config>
- </route-reflector>
- <afi-safis>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name>
- <!--Advertise N Paths
- <receive>true</receive>
- <send-max>0</send-max>-->
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-LABELLED-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-LABELLED-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV4-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV6-UNICAST</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:L2VPN-EVPN</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>LINKSTATE</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV4-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV6-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV4-L3VPN-FLOW</afi-safi-name>
- </afi-safi>
- <afi-safi>
- <afi-safi-name>IPV6-L3VPN-FLOW</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </neighbor>
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.6</neighbor-address>
- <config>
- <peer-group>application-peers</peer-group>
- </config>
- </neighbor>
- </neighbors>
- </bgp>
- </protocol>
- </protocols>
-
-BGP Configuration Example
-'''''''''''''''''''''''''
-
-BGP provides a feature providing a BGP Protocol and Network Topology configuration file example.
-Once feature is installed defined configuration will be loaded and setup.
-
-.. code-block:: console
-
- feature:install odl-bgpcep-bgp-config-example
+++ /dev/null
-.. _bgp-user-guide-protocol-configuration:
-
-Protocol Configuration
-======================
-As a first step, a new protocol instance needs to be configured.
-It is a very basic configuration conforming with RFC4271.
-
-.. note:: RIB policy must already be configured and present before configuring the protocol.
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,7,8
-
- <protocol xmlns="http://openconfig.net/yang/network-instance">
- <name>bgp-example</name>
- <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
- <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <global>
- <config>
- <router-id>192.0.2.2</router-id>
- <as>65000</as>
- </config>
- <apply-policy>
- <config>
- <default-export-policy>REJECT-ROUTE</default-export-policy>
- <default-import-policy>REJECT-ROUTE</default-import-policy>
- <import-policy>default-odl-import-policy</import-policy>
- <export-policy>default-odl-export-policy</export-policy>
- </config>
- </apply-policy>
- </global>
- </bgp>
- </protocol>
-
-@line 2: The unique protocol instance identifier.
-
-@line 7: BGP Identifier of the speaker.
-
-@line 8: Local autonomous system number of the speaker. Note that, OpenDaylight BGP implementation supports four-octet AS numbers only.
-
-@line 14: Default ODL Import Policy.
-
-@line 15: Default ODL Export Policy.
-
------
-
-The new instance presence can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,4
-
- <rib xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
- <id>bgp-example</id>
- <loc-rib>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet"></ipv4-routes>
- <attributes>
- <uptodate>true</uptodate>
- </attributes>
- </tables>
- </loc-rib>
- </rib>
-
-@line 3: Loc-RIB - Per-protocol instance RIB, which contains the routes that have been selected by local BGP speaker's decision process.
-
-@line 4: The BGP-4 supports carrying IPv4 prefixes, such routes are stored in *ipv4-address-family*/*unicast-subsequent-address-family* table.
+++ /dev/null
-.. _bgp-user-guide-rib-config-policies:
-
-RIB Policy Configuration
-========================
-
-The OpenDaylight BGP implementation supports configurable RIB policies that allow the modification of import and export policies.
-
-.. note:: Default ODL BGP RIB Config Policy is provided. Any config policy to be used by Protocol must be configured and present before than Protocol configuration is added. If policy is reconfigured, protocol must be re configured again.
-
-
-**URL:** ``/restconf/config/openconfig-routing-policy:routing-policy``
-
-**Method:** ``GET``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,15
-
- <routing-policy xmlns="http://openconfig.net/yang/routing-policy">
- <defined-sets>
- <bgp-defined-sets xmlns="http://openconfig.net/yang/bgp-policy">
- <cluster-id-sets xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- ...
- </cluster-id-sets>
- <role-sets xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- ...
- </role-sets>
- <originator-id-sets xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- ...
- </originator-id-sets>
- </bgp-defined-sets>
- </defined-sets>
- <policy-definitions>
- <policy-definition>
- <name>default-odl-export-policy</name>
- <statements>
- <statement>
- <name>to-odl-internal</name>
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- ...
- </bgp-actions>
- </actions>
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- ...
- </bgp-conditions>
- </conditions>
- </statement>
- ...
- </statements>
- </policy-definition>
- <policy-definition>
- <name>default-odl-import-policy</name>
- ...
- </policy-definition>
- </policy-definitions>
- </routing-policy>
-
-@line 2: BGP defined sets.
-
-@line 15: Policy definitions.
-
-
-Policy Configuration
---------------------
-
-Conditions may include multiple match or comparison operations; similarly, actions may consist of a multitude of changes to route attributes or a final disposition regarding the acceptance or rejection of the route.
-
-**URL:** ``/restconf/config/openconfig-routing-policy:routing-policy/openconfig-routing-policy:policy-definitions/``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,5,7,10
-
- <policy-definition xmlns="http://openconfig.net/yang/routing-policy">
- <name>odl-policy-example</name>
- <statements>
- <statement>
- <name>reject-all-incoming-routes</name>
- <actions>
- <reject-route/>
- </actions>
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <match-role-set xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <from-role>
- <role-set>/rpol:routing-policy/rpol:defined-sets/bgppol:bgp-defined-sets/role-sets/role-set[role-set-name="all"]</role-set>
- </from-role>
- </match-role-set>
- </bgp-conditions>
- </conditions>
- </statement>
- </statements>
- </policy-definition>
-
-@line 2: The unique policy instance identifier.
-
-@line 5: Policy Statement Identifier.
-
-@line 7: Actions.
-
-@line 10: BGP Conditions.
-
------
-
-The new instance presence can be verified via REST:
-
-**URL:** ``/restconf/config/openconfig-routing-policy:routing-policy/openconfig-routing-policy:policy-definitions/policy-definition/odl-policy-example``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,5
-
- <policy-definition xmlns="http://openconfig.net/yang/routing-policy">
- <name>odl-policy-example</name>
- <statements>
- <statement>
- <name>reject-all-incoming-routes</name>
- <actions>
- <reject-route></reject-route>
- </actions>
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <match-role-set xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <from-role>
- <role-set>/rpol:routing-policy/rpol:defined-sets/bgppol:bgp-defined-sets/role-sets/role-set[role-set-name="all"]</role-set>
- <match-set-options>ANY</match-set-options>
- </from-role>
- </match-role-set>
- </bgp-conditions>
- </conditions>
- </statement>
- </statements>
- </policy-definition>
-
-@line 2: Policy definition Identifier.
-
-@line 5: Policy Statement Identifier.
-
-Actions
-```````
-ODL BGP by default provides support for a group of BGP Actions.
-
-Accept
-''''''
-Default policy to accept the route.
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2
-
- <actions>
- <accept-route/>
- </actions>
-
-Reject
-''''''
-Default policy to reject the route.
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2
-
- <actions>
- <reject-route/>
- </actions>
-
-As-path prepend
-'''''''''''''''
-Action to prepend local AS number to the AS-path
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-as-path-prepend/>
- </bgp-actions>
- </actions>
-
-Originator Id prepend
-'''''''''''''''''''''''''
-Action to prepend Originator Id. In case there is non Originator Id present, local Originator Id is prepend.
-
-* Local
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2
-
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-originator-id-prepend xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy"/>
- </bgp-actions>
-
-* By value
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2
-
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-originator-id-prepend xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <originator-id>192.0.2.1</originator-id>
- </set-originator-id-prepend>
- </bgp-actions>
-
-Cluster Id prepend
-''''''''''''''''''
-Action to prepend local Cluster Id to Cluster Id List.
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-cluster-id-prepend xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy"/>
- </bgp-actions>
- </actions>
-
-Set Route Origin
-''''''''''''''''
-Set the origin attribute to the specified value.
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-route-origin>IGP</set-route-origin>
- </bgp-actions>
- </actions>
-
-Set Local Preference
-''''''''''''''''''''
-Set the local pref attribute on the route update.
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-local-pref>100</set-local-pref>
- </bgp-actions>
- </actions>
-
-Set NextHop
-'''''''''''
-Set the next-hop attribute in the route update.
-
-* Local
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-next-hop>SELF</set-next-hop>
- </bgp-actions>
- </actions>
-
-
-* By value
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-next-hop>4.5.6.7</set-next-hop>
- </bgp-actions>
- </actions>
-
-Set MED
-'''''''
-Set the med metric attribute in the route update.
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-med>15</set-med>
- </bgp-actions>
- </actions>
-
-Community set prepend
-'''''''''''''''''''''
-Action to set the community attributes of the route, along with options to modify how the community is modified.
-
-* Inline
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-community>
- <communities>
- <as-number>65</as-number>
- <semantics>10</semantics>
- </communities>
- <communities>
- <as-number>66</as-number>
- <semantics>11</semantics>
- </communities>
- <options>ADD</options>
- </set-community>
- </bgp-actions>
- </actions>
-
-@line 3: Set Community.
-
-* By reference
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5,7
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-community>
- <community-set-ref>
- /rpol:routing-policy/rpol:defined-sets/rpol:community-sets/community-set[community-set-name="community-set-name-example"]
- </community-set-ref>
- <options>ADD</options>
- </set-community>
- </bgp-actions>
- </actions>
-
-@line 3: Set Community.
-
-@line 5: Community set reference.
-
-@line 7: Options are ADD, REMOVE, REPLACE.
-
------
-
-Defined set
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <defined-sets>
- <bgp-defined-sets xmlns="http://openconfig.net/yang/bgp-policy">
- <community-sets>
- <community-set>
- <community-set-name>community-set-name-test</community-set-name>
- <communities>
- <as-number>65</as-number>
- <semantics>10</semantics>
- </communities>
- <communities>
- <as-number>66</as-number>
- <semantics>11</semantics>
- </communities>
- </community-set>
- </community-sets>
- </bgp-defined-sets>
- </defined-sets>
-
-@line 3: Community set.
-
-Extended Community set action
-''''''''''''''''''''''''''''''
-Action to set the extended community attributes of the route, along with options to modify how the community is modified.
-
-* Inline
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-ext-community>
- <ext-community-member>
- <encapsulation-extended-community>
- <tunnel-type>vxlan</tunnel-type>
- </encapsulation-extended-community>
- </ext-community-member>
- <ext-community-member>
- <as-4-route-origin-extended-community>
- <as-4-specific-common>
- <as-number>65000</as-number>
- <local-administrator>123</local-administrator>
- </as-4-specific-common>
- </as-4-route-origin-extended-community>
- </ext-community-member>
- <options>ADD</options>
- </set-ext-community>
- </bgp-actions>
- </actions>
-
-@line 3: Set Extended Community.
-
-* By reference
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-ext-community>
- <ext-community-set-ref>
- /rpol:routing-policy/rpol:defined-sets/rpol:ext-community-sets/ext-community-set[ext-community-set-name="ext-community-set-name-example"]
- </ext-community-set-ref>
- <options>REMOVE</options>
- </set-ext-community>
- </bgp-actions>
- </actions>
-
-@line 3: Set Extended Community.
-
-@line 5: Extended Community set reference.
-
-@line 7: Options are ADD, REMOVE, REPLACE.
-
------
-
-Defined set
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <defined-sets>
- <bgp-defined-sets xmlns="http://openconfig.net/yang/bgp-policy">
- <ext-community-sets>
- <ext-community-set>
- <ext-community-set-name>ext-community-set-name-test</ext-community-set-name>
- <ext-community-member>
- <encapsulation-extended-community>
- <tunnel-type>vxlan</tunnel-type>
- </encapsulation-extended-community>
- </ext-community-member>
- <ext-community-member>
- <as-4-route-origin-extended-community>
- <as-4-specific-common>
- <as-number>65000</as-number>
- <local-administrator>123</local-administrator>
- </as-4-specific-common>
- </as-4-route-origin-extended-community>
- </ext-community-member>
- </ext-community-set>
- </ext-community-sets>
- </bgp-defined-sets>
- </defined-sets>
-
-@line 3: Extendend Community set.
-
-@line 5: Extendend Community set name.
-
-
-Filter Non transitive attributes
-''''''''''''''''''''''''''''''''
-Filters attributes, removing non transitive attributes.
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <non-transitive-attributes-filter xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy"/>
- </bgp-actions>
- </actions>
-
-Client Attribute Prepend
-''''''''''''''''''''''''
-Replace attributes per any VPN Route attributes from client Peer, if present.
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <client-attribute-prepend xmlns="urn:opendaylight:params:xml:ns:yang:bgp:route:target:constrain"/>
- </bgp-actions>
- </actions>
-
-Conditions
-``````````
-ODL BGP by default provides support for a group of BGP Conditions.
-
-Match BGP Neighbor Set
-''''''''''''''''''''''
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,4,5,6
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <match-bgp-neighbor-set xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <from-neighbor>
- <neighbor-set>/rpol:routing-policy/rpol:defined-sets/rpol:neighbor-sets/neighbor-set[neighbor-set-name="bgp-neighbor-set-example"]</neighbor-set>
- <match-set-options>INVERT</match-set-options>
- </from-neighbor>
- </match-bgp-neighbor-set>
- </bgp-conditions>
- </conditions>
-
-@line 3: Match BGP Neighbor Condition set.
-
-@line 4: Match BGP Neighbor from whom we receive the route.
-
-@line 5: Match BGP Neighbor Set reference.
-
-@line 6: Match Set Options (ANY, INVERT)
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,4,5,6
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <match-bgp-neighbor-set xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <to-neighbor>
- <neighbor-set>/rpol:routing-policy/rpol:defined-sets/rpol:neighbor-sets/neighbor-set[neighbor-set-name="bgp-neighbor-set-example"]</neighbor-set>
- <match-set-options>INVERT</match-set-options>
- </to-neighbor>
- </match-bgp-neighbor-set>
- </bgp-conditions>
- </conditions>
-
-@line 3: Match BGP Neighbor Condition set.
-
-@line 4: Match BGP Neighbor to whom we send the route.
-
-@line 5: Match BGP Neighbor Set reference.
-
-@line 6: Match Set Options (ANY, INVERT)
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,4,5,7,8,9
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <match-bgp-neighbor-set xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <from-neighbor>
- <neighbor-set>/rpol:routing-policy/rpol:defined-sets/rpol:neighbor-sets/neighbor-set[neighbor-set-name="bgp-neighbor-set-example"]</neighbor-set>
- </from-neighbor>
- <to-neighbor>
- <neighbor-set>/rpol:routing-policy/rpol:defined-sets/rpol:neighbor-sets/neighbor-set[neighbor-set-name="bgp-neighbor-set-example"]</neighbor-set>
- <match-set-options>INVERT</match-set-options>
- </to-neighbor>
- </match-bgp-neighbor-set>
- </bgp-conditions>
- </conditions>
-
-@line 3: Match BGP Neighbor Condition set.
-
-@line 4: Match BGP Neighbor from whom we receive the route.
-
-@line 5: Match BGP Neighbor Set reference.
-
-@line 7: Match BGP Neighbor to whom we send the route.
-
-@line 8: Match BGP Neighbor Set reference.
-
-@line 9: Match Set Options (ANY, INVERT)
-
------
-
-Defined set
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5
-
- <defined-sets>
- <neighbor-sets>
- <neighbor-set>
- <neighbor-set-name>bgp-neighbor-set-example</neighbor-set-name>
- <neighbor>
- <address>127.0.0.1</address>
- </neighbor>
- <neighbor>
- <address>127.0.0.2</address>
- </neighbor>
- </neighbor-set>
- </neighbor-sets>
- </defined-sets>
-
-@line 3: Originator Id Set.
-
-@line 5: Originator Id Set name.
-
-Match Originator Id Set
-'''''''''''''''''''''''
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5,7
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <match-originator-id-set-condition xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <originator-id-set>
- /rpol:routing-policy/rpol:defined-sets/bgppol:bgp-defined-sets/originator-id-sets/originator-id-set[originator-set-name="local-originator-id"]
- </originator-id-set>
- <match-set-options>INVERT</match-set-options>
- </match-originator-id-set-condition>
- </bgp-conditions>
- </conditions>
-
-@line 3: Match Originator Id Condition set.
-
-@line 5: Match Originator Id Set reference.
-
-@line 7: Match Set Options (ANY, INVERT)
-
------
-
-Defined set
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5
-
- <defined-sets>
- <bgp-defined-sets xmlns="http://openconfig.net/yang/bgp-policy">
- <originator-id-sets xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <originator-id-set>
- <originator-id-set-name>local-originator-id</originator-id-set-name>
- <local/>
- </originator-id-set>
- </originator-id-sets>
- </bgp-defined-sets>
- </defined-sets>
-
-@line 3: Originator Id Set.
-
-@line 5: Originator Id Set name.
-
-Match Cluster Id Set
-''''''''''''''''''''
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <match-cluster-id-set-condition xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <cluster-id-set>
- /rpol:routing-policy/rpol:defined-sets/bgppol:bgp-defined-sets/cluster-id-sets/cluster-id-set[cluster-set-name="local-cluster-id"]
- </cluster-id-set>
- <match-set-options>INVERT</match-set-options>
- </match-cluster-id-set-condition>
- </bgp-conditions>
- </conditions>
-
-@line 3: Match Cluster Id Condition set.
-
-@line 5: Match Cluster Id Set reference.
-
------
-
-Defined set
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5
-
- <defined-sets>
- <bgp-defined-sets xmlns="http://openconfig.net/yang/bgp-policy">
- <cluster-id-sets xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <cluster-id-set>
- <cluster-id-set-name>local-cluster-id</cluster-id-set-name>
- <local/>
- </cluster-id-set>
- </cluster-id-sets>
- </bgp-defined-sets>
- </defined-sets>
-
-@line 3: Cluster Id Set.
-
-@line 5: Cluster Id Set name.
-
-Match Peer Role Set
-'''''''''''''''''''
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5,6
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <match-role-set xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <from-role>
- <role-set>/rpol:routing-policy/rpol:defined-sets/bgppol:bgp-defined-sets/role-sets/role-set[role-set-name="only-ibgp"]</role-set>
- <match-set-options>INVERT</match-set-options>
- </from-role>
- <to-role>
- <role-set>/rpol:routing-policy/rpol:defined-sets/bgppol:bgp-defined-sets/role-sets/role-set[role-set-name="all"]</role-set>
- <to-role>
- </match-role-set>
- </bgp-conditions>
- </conditions>
-
-@line 3: Match Role Set.
-
-@line 5: Match Role Set reference.
-
-@line 6: Match Set Options (ANY, INVERT)
-
------
-
-Defined set
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,4,10,11
-
- <defined-sets>
- <bgp-defined-sets xmlns="http://openconfig.net/yang/bgp-policy">
- <role-set>
- <role-set-name>all</role-set-name>
- <role>ebgp</role>
- <role>ibgp</role>
- <role>rr-client</role>
- <role>internal</role>
- </role-set>
- <role-set>
- <role-set-name>only-ibgp</role-set-name>
- <role>ibgp</role>
- </role-set>
- </bgp-defined-sets>
- </defined-sets>
-
-@line 3: Role Set.
-
-@line 4: Role Set name.
-
-@line 10: Role Set.
-
-@line 11: Role Id Set name.
-
-Match AS Path Set
-'''''''''''''''''
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5,7
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <match-as-path-set>
- <as-path-set>
- /rpol:routing-policy/rpol:defined-sets/bgp-pol:bgp-defined-sets/bgp-pol:as-path-sets/bgp-pol:as-path-set/[as-path-set-name="as-path-set-example"]
- </as-path-set>
- <match-set-options>ANY</match-set-options>
- </match-as-path-set>
- </bgp-conditions>
- </conditions>
-
-@line 3: Match AS Path Set.
-
-@line 5: AS Path Set reference.
-
-@line 7: Match Set Option(ANY, ALL, INVERT).
-
------
-
-Defined set
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 4,5,6
-
- <defined-sets>
- <bgp-defined-sets xmlns="http://openconfig.net/yang/bgp-policy">
- <as-path-sets>
- <as-path-set>
- <as-path-set-name>as-path-set-example</as-path-set-name>
- <as-path-set-member>65</as-path-set-member>
- <as-path-set-member>64</as-path-set-member>
- <as-path-set-member>63</as-path-set-member>
- </as-path-set>
- </as-path-sets>
- </bgp-defined-sets>
- </defined-sets>
-
-@line 4: AS Path Set.
-
-@line 5: AS Path Set name.
-
-@line 6: AS Path set member
-
-Match Community Set
-'''''''''''''''''''
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <match-community-set>
- <community-set>
- /rpol:routing-policy/rpol:defined-sets/rpol:community-sets/community-set[community-set-name="community-set-name-example"]
- </community-set>
- <match-set-options>ANY</match-set-options>
- </match-community-set>
- </bgp-conditions>
- </conditions>
-
-@line 3: Match Community Set.
-
-@line 5: Match Community Set reference.
-
-@line 7: Match Set Option(ANY, ALL, INVERT).
-
------
-
-Defined set
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 4,5,6,10
-
- <defined-sets>
- <bgp-defined-sets xmlns="http://openconfig.net/yang/bgp-policy">
- <community-sets>
- <community-set>
- <community-set-name>community-set-name-example</community-set-name>
- <communities>
- <as-number>65</as-number>
- <semantics>10</semantics>
- </communities>
- <communities>
- <as-number>66</as-number>
- <semantics>11</semantics>
- </communities>
- </community-set>
- </community-sets>
- </bgp-defined-sets>
- </defined-sets>
-
-@line 4: Community Set.
-
-@line 5: Community Set name.
-
-@line 6: Communities.
-
-@line 10: Communities.
-
-Match Extended Community Set
-''''''''''''''''''''''''''''
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5,7
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <match-ext-community-set>
- <ext-community-set>
- /rpol:routing-policy/rpol:defined-sets/rpol:ext-community-sets/ext-community-set[ext-community-set-name="ext-community-set-name-test"]
- </ext-community-set>
- <match-set-options>ANY</match-set-options>
- </match-ext-community-set>
- </bgp-conditions>
- </conditions>
-
-@line 3: Match Extended Community Set.
-
-@line 5: Match Extended Community Set reference.
-
-@line 7: Match Set Option(ANY, ALL, INVERT).
-
------
-
-Defined set
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 4,5,6,11
-
- <defined-sets>
- <bgp-defined-sets xmlns="http://openconfig.net/yang/bgp-policy">
- <ext-community-sets>
- <ext-community-set>
- <ext-community-set-name>ext-community-set-name-test</ext-community-set-name>
- <ext-community-member>
- <encapsulation-extended-community>
- <tunnel-type>vxlan</tunnel-type>
- </encapsulation-extended-community>
- </ext-community-member>
- <ext-community-member>
- <as-4-route-origin-extended-community>
- <as-4-specific-common>
- <as-number>65000</as-number>
- <local-administrator>123</local-administrator>
- </as-4-specific-common>
- </as-4-route-origin-extended-community>
- </ext-community-member>
- </ext-community-set>
- </ext-community-sets>
- </bgp-defined-sets>
- </defined-sets>
-
-@line 4: Extended Community Set.
-
-@line 5: Extended Community Set name.
-
-@line 6: Extended Communities.
-
-@line 11: Extended Communities.
-
-Match in Afi Safi
-'''''''''''''''''
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <afi-safi-in xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-in>
- </bgp-conditions>
- </conditions>
-
-@line 3: Afi Safi match.
-
-Match not in Afi Safi
-'''''''''''''''''''''
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <afi-safi-not-in xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy"
- xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-not-in>
- <afi-safi-not-in xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy"
- xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV6-UNICAST</afi-safi-not-in>
- </bgp-conditions>
- </conditions>
-
-@line 3: Afi Safi not in match.
-
-Match As Path Length
-''''''''''''''''''''
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <as-path-length>
- <operator xmlns:x="http://openconfig.net/yang/policy-types">x:attribute-eq</operator>
- <value>2</value>
- </as-path-length>
- </bgp-conditions>
- </conditions>
-
-@line 3: As Path Length match.
-
-Match Local Pref
-''''''''''''''''
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <local-pref-eq>100</local-pref-eq>
- </bgp-conditions>
- </conditions>
-
-@line 3: Local Preference match.
-
-Match Origin
-''''''''''''
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <origin-eq>IGP</origin-eq>
- </bgp-conditions>
- </conditions>
-
-@line 3: Origin match.
-
-Match MED
-'''''''''
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <med-eq>100</med-eq>
- </bgp-conditions>
- </conditions>
-
-@line 3: MED match.
-
-Match Next Hop
-''''''''''''''
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <next-hop-in>192.168.2.2</next-hop-in>
- <next-hop-in>42.42.42.42</next-hop-in>
- </bgp-conditions>
- </conditions>
-
-@line 3: Next hop match.
-
-Match VPN Non member
-''''''''''''''''''''
-
-True if Route Targets attributes does not match with any Route Target Contrain advertized per Advertized peer.
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <vpn-non-member xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy"/>
- </bgp-conditions>
- </conditions>
-
-@line 3: VPN Non member match.
+++ /dev/null
-.. _bgp-user-guide-route-refresh-capability:
-
-Route Refresh
-=============
-The Route Refresh Capability allows to dynamically request a re-advertisement of the Adj-RIB-Out from a BGP peer.
-This is useful when the inbound routing policy for a peer changes and all prefixes from a peer must be reexamined against a new policy.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-The capability is enabled by default, no additional configuration is required.
-
-Usage
-^^^^^
-To send a Route Refresh request from OpenDaylight BGP speaker instance to its neighbor, invoke RPC:
-
-**URL:** ``/restconf/operations/bgp-peer-rpc:route-refresh-request``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <input xmlns="urn:opendaylight:params:xml:ns:yang:bgp-peer-rpc">
- <afi xmlns:types="urn:opendaylight:params:xml:ns:yang:bgp-types">types:ipv4-address-family</afi>
- <safi xmlns:types="urn:opendaylight:params:xml:ns:yang:bgp-types">types:unicast-subsequent-address-family</safi>
- <peer-ref xmlns:rib="urn:opendaylight:params:xml:ns:yang:bgp-rib">/rib:bgp-rib/rib:rib[rib:id="bgp-example"]/rib:peer[rib:peer-id="bgp://10.25.1.9"]</peer-ref>
- </input>
-
-References
-^^^^^^^^^^
-* `Route Refresh Capability for BGP-4 <https://tools.ietf.org/html/rfc2918>`_
-
-Peer Session Release
---------------------
-
-BGP provides a RPC feature to release a Neighbor session.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-The capability is enabled by default, no additional configuration is required.
-
-Usage
-^^^^^
-To release neighbor session, invoke RPC:
-
-**URL:** ``/restconf/operations/bgp-peer-rpc:reset-session``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <input xmlns="urn:opendaylight:params:xml:ns:yang:bgp-peer-rpc">
- <peer-ref xmlns:rib="urn:opendaylight:params:xml:ns:yang:bgp-rib">/rib:bgp-rib/rib:rib[rib:id="bgp-example"]/rib:peer[rib:peer-id="bgp://10.25.1.9"]</peer-ref>
- </input>
+++ /dev/null
-.. _bgp-user-guide-route-target-family:
-
-Route Target Constrain Family
-=============================
-The BGP Multicast Route Target (RT) Constrain Multiprotocol extension can be used to restrict advertisement of VPN NLRI to peers that have advertised
-their respective Route Targets, effectively building a route distribution graph.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-This section shows a way to enable ROUTE-TARGET-CONSTRAIN family in BGP speaker and peer configuration.
-
-BGP Speaker
-'''''''''''
-To enable ROUTE-TARGET-CONSTRAIN support in BGP plugin, first configure BGP speaker instance:
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <protocol xmlns="http://openconfig.net/yang/network-instance">
- <name>bgp-example</name>
- <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier>
- <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <global>
- <config>
- <router-id>192.0.2.2</router-id>
- <as>65000</as>
- </config>
- <afi-safis>
- <afi-safi>
- <afi-safi-name>ROUTE-TARGET-CONSTRAIN</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </global>
- </bgp>
- </protocol>
-
-BGP Peer
-''''''''
-Here is an example for BGP peer configuration with enabled ROUTE-TARGET-CONSTRAIN family.
-
-**URL:** ``/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">
- <neighbor-address>192.0.2.1</neighbor-address>
- <afi-safis>
- <afi-safi>
- <afi-safi-name>ROUTE-TARGET-CONSTRAIN</afi-safi-name>
- </afi-safi>
- </afi-safis>
- </neighbor>
-
-ROUTE-TARGET-CONSTRAIN Route API
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Following tree illustrates the BGP ROUTE-TARGET-CONSTRAIN route structure.
-
-.. code-block:: console
-
- :(route-target-constrain-routes-case)
- +--rw route-target-constrain-routes
- +--rw route-target-constrain-route* [route-key path-id]
- +--rw origin-as inet:as-number
- +--rw (route-target-constrain-choice)
- +--:(route-target-constrain-default-case)
- | +--rw route-target-constrain-default-route!
- +--:(route-target-constrain-route-case)
- | +--rw route-target-extended-community
- | +--rw global-administrator? short-as-number
- | +--rw local-administrator? binary
- +--:(route-target-constrain-ipv4-route-case)
- | +--rw route-target-ipv4
- | +--rw global-administrator? inet:ipv4-address
- | +--rw local-administrator? uint16
- +--:(route-target-constrain-as-4-extended-community-case)
- +--rw as-4-route-target-extended-community
- +--rw as-4-specific-common
- +--rw as-number inet:as-number
- +--rw local-administrator uint16
-
-Usage
-^^^^^
-The ROUTE TARGET CONSTRAIN table in an instance of the speaker's Loc-RIB can be verified via REST:
-
-**URL:** ``/restconf/operational/bgp-rib:bgp-rib/rib/bgp-example/loc-rib/tables/bgp-types:ipv4-address-family/bgp-route-target-constrain:route-target-constrain-subsequent-address-family/bgp-route-target-constrain:route-target-constrain-routes``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <route-target-constrain-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp:route:target:constrain">
- <route-target-constrain-route>
- <route-key>flow1</route-key>
- <path-id>0</path-id>
- <origin-as>64511</origin-as>
- <route-target-extended-community>
- <global-administrator>64511</global-administrator>
- <local-administrator>AAAAZQ==</local-administrator>
- </route-target-extended-community>
- <attributes>
- <ipv4-next-hop>
- <global>199.20.166.41</global>
- </ipv4-next-hop>
- <as-path/>
- <origin>
- <value>igp</value>
- </origin>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- </attributes>
- </route-target-constrain-route>
- </route-target-constrain-routes>
-
-Routing Policies
-^^^^^^^^^^^^^^^^
-
-.. code-block:: xml
-
- <policy-definition>
- <name>default-odl-export-policy</name>
- <statement>
- ...
- <statement>
- <name>from-external-to-external-RTC</name>
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <afi-safi-in xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">x:ROUTE-TARGET-CONSTRAIN</afi-safi-in>
- <match-role-set xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <from-role>
- <role-set>/rpol:routing-policy/rpol:defined-sets/bgppol:bgp-defined-sets/role-sets/role-set[role-set-name="only-ebgp"]</role-set>
- </from-role>
- <to-role>
- <role-set>/rpol:routing-policy/rpol:defined-sets/bgppol:bgp-defined-sets/role-sets/role-set[role-set-name="only-ebgp"]</role-set>
- </to-role>
- </match-role-set>
- </bgp-conditions>
- </conditions>
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <client-attribute-prepend xmlns="urn:opendaylight:params:xml:ns:yang:bgp:route:target:constrain"/>
- </bgp-actions>
- </actions>
- </statement>
- ...
- </statement>
- <statement>
- <name>from-internal-or-rr-client-to-route-reflector</name>
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <afi-safi-not-in xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions"
- xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">x:ROUTE-TARGET-CONSTRAIN
- </afi-safi-not-in>
- <match-role-set xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <from-role>
- <role-set>/rpol:routing-policy/rpol:defined-sets/bgppol:bgp-defined-sets/role-sets/role-set[role-set-name="ibgp-rr-client"]</role-set>
- </from-role>
- <to-role>
- <role-set>/rpol:routing-policy/rpol:defined-sets/bgppol:bgp-defined-sets/role-sets/role-set[role-set-name="only-rr-client"]</role-set>
- </to-role>
- </match-role-set>
- </bgp-conditions>
- </conditions>
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-cluster-id-prepend xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy"/>
- <set-originator-id-prepend xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy"/>
- </bgp-actions>
- </actions>
- </statement>
- <statement>
- <name>from-internal-or-rr-client-to-route-RTC</name>
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <afi-safi-in xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions">x:ROUTE-TARGET-CONSTRAIN</afi-safi-in>
- <match-role-set xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy">
- <from-role>
- <role-set>/rpol:routing-policy/rpol:defined-sets/bgppol:bgp-defined-sets/role-sets/role-set[role-set-name="ibgp-rr-client"]</role-set>
- </from-role>
- <to-role>
- <role-set>/rpol:routing-policy/rpol:defined-sets/bgppol:bgp-defined-sets/role-sets/role-set[role-set-name="only-rr-client"]</role-set>
- </to-role>
- </match-role-set>
- </bgp-conditions>
- </conditions>
- <actions>
- <bgp-actions xmlns="http://openconfig.net/yang/bgp-policy">
- <set-originator-id-prepend xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy"/>
- <set-next-hop>SELF</set-next-hop>
- </bgp-actions>
- </actions>
- </statement>
- <statement>
- <name>vpn-membership-RTC</name>
- <conditions>
- <bgp-conditions xmlns="http://openconfig.net/yang/bgp-policy">
- <afi-safi-in xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV4-UNICAST</afi-safi-in>
- <afi-safi-in xmlns:x="http://openconfig.net/yang/bgp-types">x:L3VPN-IPV6-UNICAST</afi-safi-in>
- <vpn-non-member xmlns="urn:opendaylight:params:xml:ns:yang:odl:bgp:default:policy"/>
- </bgp-conditions>
- </conditions>
- <actions>
- <reject-route/>
- </actions>
- </statement>
- ...
- ...
- </policy-definition>
-
-References
-^^^^^^^^^^
-* `Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) <https://tools.ietf.org/html/rfc4684>`_
+++ /dev/null
-.. _bgp-user-guide-running-bgp:
-
-Running BGP
-===========
-This section explains how to install BGP plugin.
-
-1. Install BGP feature - ``odl-bgpcep-bgp``.
- Also, for sake of this sample, it is required to install RESTCONF.
- In the Karaf console, type command:
-
- .. code-block:: console
-
- feature:install odl-restconf odl-bgpcep-bgp
-
-2. The BGP plugin contains a default configuration, which is applied after the feature starts up.
- One instance of BGP plugin is created (named *example-bgp-rib*), and its presence can be verified via REST:
-
- **URL:** ``/restconf/operational/bgp-rib:bgp-rib``
-
- **Method:** ``GET``
-
- **Response Body:**
-
- .. code-block:: xml
-
- <bgp-rib xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
- <rib>
- <id>example-bgp-rib</id>
- <loc-rib>
- ....
- </loc-rib>
- </rib>
- </bgp-rib>
+++ /dev/null
-.. _bgp-user-guide-supported-capabilities:
-
-List of supported capabilities
-==============================
-In addition to the base protocol implementation, the plugin provides many extensions to BGP, all based on IETF standards.
-
-* `RFC4271 <https://tools.ietf.org/html/rfc4271>`_ - A Border Gateway Protocol 4 (BGP-4)
-* `RFC4456 <https://tools.ietf.org/html/rfc4456>`_ - BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
-* `RFC1997 <https://tools.ietf.org/html/rfc1997>`_ - BGP Communities Attribute
-* `RFC4360 <https://tools.ietf.org/html/rfc4360>`_ - BGP Extended Communities Attribute
-* `RFC4486 <https://tools.ietf.org/html/rfc4486>`_ - Subcodes for BGP Cease Notification Message
-* `RFC5492 <https://tools.ietf.org/html/rfc5492>`_ - Capabilities Advertisement with BGP-4
-* `RFC5004 <https://tools.ietf.org/html/rfc5004>`_ - Avoid BGP Best Path Transitions from One External to Another
-* `RFC6286 <https://tools.ietf.org/html/rfc6286>`_ - Autonomous-System-Wide Unique BGP Identifier for BGP-4
-* `RFC6793 <https://tools.ietf.org/html/rfc6793>`_ - BGP Support for Four-Octet Autonomous System (AS) Number Space
-* `RFC7311 <https://tools.ietf.org/html/rfc7311>`_ - The Accumulated IGP Metric Attribute for BGP
-* `RFC5668 <https://tools.ietf.org/html/rfc5668>`_ - 4-Octet AS Specific BGP Extended Community
-* `draft-ietf-idr-link-bandwidth <https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-06>`_ - BGP Link Bandwidth Extended Community
-* `draft-ietf-idr-bgp-extended-messages <https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-13>`_ - Extended Message support for BGP
-* `RFC4760 <https://tools.ietf.org/html/rfc4760>`_ - Multiprotocol Extensions for BGP-4
- * `RFC7752 <https://tools.ietf.org/html/rfc7752>`_ - North-Bound Distribution of Link-State and TE Information using BGP
- * `draft-gredler-idr-bgp-ls-segment-routing-ext <https://tools.ietf.org/html/draft-gredler-idr-bgp-ls-segment-routing-ext-03>`_ - BGP Link-State extensions for Segment Routing
- * `draft-ietf-idr-bgpls-segment-routing-epe <https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-05>`_ - Segment Routing Egress Peer Engineering BGP-LS Extensions
- * `RFC5575 <https://tools.ietf.org/html/rfc5575>`_ - Dissemination of Flow Specification Rules
- * `RFC7674 <http://tools.ietf.org/html/rfc7674>`_ - Clarification of the Flowspec Redirect Extended Community
- * `draft-ietf-idr-flow-spec-v6 <https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-07>`_ - Dissemination of Flow Specification Rules for IPv6
- * `draft-ietf-idr-flowspec-redirect-ip <https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-ip-00>`_ - BGP Flow-Spec Redirect to IP Action
- * `RFC3107 <https://tools.ietf.org/html/rfc3107>`_ - Carrying Label Information in BGP-4
- * `draft-ietf-idr-bgp-prefix-sid <https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-03>`_ - Segment Routing Prefix SID extensions for BGP
- * `RFC4364 <https://tools.ietf.org/html/rfc4364>`_ - BGP/MPLS IP Virtual Private Networks (VPNs)
- * `RFC4659 <https://tools.ietf.org/html/rfc4659>`_ - BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
- * `RFC6513 <https://tools.ietf.org/html/rfc6513>`_ - Multicast in MPLS/BGP IP VPNs (VPNs)
- * `RFC6514 <https://tools.ietf.org/html/rfc6514>`_ - BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs
- * `RFC6515 <https://tools.ietf.org/html/rfc6515>`_ - IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN
- * `RFC4684 <https://tools.ietf.org/html/rfc4684>`_ - Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)
- * `RFC7432 <https://tools.ietf.org/html/rfc7432>`_ - BGP MPLS-Based Ethernet VPN
- * `draft-ietf-bess-evpn-overlay <https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-04>`_ - A Network Virtualization Overlay Solution using EVPN
- * `draft-ietf-bess-evpn-vpws <https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-07>`_ - VPWS support in EVPN
- * `draft-sajassi-bess-evpn-vpws-fxc-01 <https://tools.ietf.org/html/draft-sajassi-bess-evpn-vpws-fxc-01>`_ - EVPN VPWS Flexible Cross-Connect Service
-* `RFC7911 <https://tools.ietf.org/html/rfc7911>`_ - Advertisement of Multiple Paths in BGP
-* `RFC2918 <https://tools.ietf.org/html/rfc2918>`_ - Route Refresh Capability for BGP-4
+++ /dev/null
-.. _bgp-user-guide-test-tools:
-
-Test Tools
-==========
-BGP test tools serves to test basic BGP functionality, scalability and performance.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-BGP Test Tool
-^^^^^^^^^^^^^
-The BGP Test Tool is a stand-alone Java application purposed to simulate remote BGP peers, that are capable to advertise sample routes.
-This application is not part of the OpenDaylight Karaf distribution, however it can be downloaded from OpenDaylight's Nexus (use latest release version):
-
-``https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/bgpcep/bgp-testtool``
-
-Usage
-'''''
-The application can be run from command line:
-
-.. code-block:: console
-
- java -jar bgp-testtool-*-executable.jar
-
-
-with optional input parameters:
-
-.. code-block:: console
-
- -i <BOOLEAN>, --active <BOOLEAN>
- Active initialisation of the connection, by default false.
-
- -ho <N>, --holdtimer <N>
- In seconds, value of the desired holdtimer, by default 90.
-
- -sc <N>, --speakersCount <N>
- Number of simulated BGP speakers, when creating each speaker, uses incremented local-address for binding, by default 0.
-
- -ra <IP_ADDRESS:PORT,...>, --remote-address <IP_ADDRESS:PORT,...>
- A list of IP addresses of remote BGP peers, that the tool can accept or initiate connect to that address (based on the mode), by default 192.0.2.2:1790.
-
- -la <IP_ADDRESS:PORT>, --localAddress <IP_ADDRESS:PORT>
- IP address of BGP speakers which the tools simulates, by default 192.0.2.2:0.
-
- -pr <N>, --prefixes <N>
- Number of prefixes to be advertised by each simulated speaker
-
- -mp <BOOLEAN>, --multiPathSupport <BOOLEAN>
- Active ADD-PATH support, by default false.
-
- -as <N>, --as <N>
- Local AS Number, by default 64496.
-
- -ec <EXTENDED_COMMUNITIES>, --extended_communities <EXTENDED_COMMUNITIES>
- Extended communities to be send. Format: x,x,x where x is each extended community from bgp-types.yang, by default empty.
-
- -ll <LOG_LEVEL>, --log_level <LOG_LEVEL>
- Log level for console output, by default INFO.
-
-BGP Application Peer Benchmark
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-It is a simple OpenDaylight application which is capable to inject and remove specific amount of IPv4 routes.
-This application is part of the OpenDaylight Karaf distribution.
-
-Configuration
-'''''''''''''
-As a first step install BGP and RESTCONF, then configure *Application Peer*.
-Install ``odl-bgpcep-bgp-benchmark`` feature and reconfigure BGP Application Peer Benchmark application as per following:
-
-**URL:** ``/restconf/config/odl-bgp-app-peer-benchmark-config:config``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2
-
- <odl-bgp-app-peer-benchmark-config xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-app-peer-benchmark-config">
- <app-peer-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-app-peer-benchmark-config">10.25.1.9</app-peer-id>
- </odl-bgp-app-peer-benchmark-config>
-
-@line 2: The *Application Peer* identifier.
-
-Inject routes
-'''''''''''''
-Routes injection can be invoked via RPC:
-
-**URL:** ``/restconf/operations/odl-bgp-app-peer-benchmark:add-prefix``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,3,4,5
-
- <input xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-app-peer-benchmark">
- <prefix>1.1.1.1/32</prefix>
- <count>100000</count>
- <batchsize>2000</batchsize>
- <nexthop>192.0.2.2</nexthop>
- </input>
-
-@line 2: A initial IPv4 prefix carried in route. Value is incremented for following routes.
-
-@line 3: An amount of routes to be added to *Application Peer's* programmable RIB.
-
-@line 4: A size of the transaction batch.
-
-@line 5: A NEXT_HOP attribute value used in all injected routes.
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,4,5
-
- <output xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-app-peer-benchmark">
- <result>
- <duration>4301</duration>
- <rate>25000</rate>
- <count>100000</count>
- </result>
- </output>
-
-@line 3: Request duration in milliseconds.
-
-@line 4: Writes per second rate.
-
-@line 5: An amount of routes added to *Application Peer's* programmable RIB.
-
-Remove routes
-'''''''''''''
-Routes deletion can be invoked via RPC:
-
-**URL:** ``/restconf/operations/odl-bgp-app-peer-benchmark:delete-prefix``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,3,4
-
- <input xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-app-peer-benchmark">
- <prefix>1.1.1.1/32</prefix>
- <count>100000</count>
- <batchsize>2000</batchsize>
- </input>
-
-@line 2: A initial IPv4 prefix carried in route to be removed. Value is incremented for following routes.
-
-@line 3: An amount of routes to be removed from *Application Peer's* programmable RIB.
-
-@line 4: A size of the transaction batch.
-
-**Response Body:**
-
-.. code-block:: xml
-
- <output xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-app-peer-benchmark">
- <result>
- <duration>1837</duration>
- <rate>54500</rate>
- <count>100000</count>
- </result>
- </output>
+++ /dev/null
-.. _bgp-user-guide-topology-provider:
-
-Topology Provider
-=================
-This section provides an overview of the BGP topology provider service.
-It shows how to configure and use all available BGP topology providers.
-Providers are building topology view of BGP routes stored in local BGP speaker's Loc-RIB.
-Output topologies are rendered in a form of standardised IETF network topology model.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Inet Reachability Topology
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-Inet reachability topology exporter offers a mapping service from IPv4/6 routes to network topology nodes.
-
-Configuration
-'''''''''''''
-Following example shows how to create a new instance of IPv4 BGP topology exporter:
-
-**URL:** ``/restconf/config/network-topology:network-topology``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,4,6
-
- <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <topology-id>bgp-example-ipv4-topology</topology-id>
- <topology-types>
- <bgp-ipv4-reachability-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"></bgp-ipv4-reachability-topology>
- </topology-types>
- <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-config">bgp-example</rib-id>
- </topology>
-
-@line 2: An identifier for a topology.
-
-@line 4: Used to identify type of the topology. In this case BGP IPv4 reachability topology.
-
-@line 6: A name of the local BGP speaker instance.
-
------
-
-The topology exporter instance can be removed in a following way:
-
-**URL:** ``/restconf/config/network-topology:network-topology/topology/bgp-example-ipv4-topology``
-
-**Method:** ``DELETE``
-
------
-
-Following example shows how to create a new instance of IPv6 BGP topology exporter:
-
-**URL:** ``/restconf/config/network-topology:network-topology``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <topology-id>bgp-example-ipv6-topology</topology-id>
- <topology-types>
- <bgp-ipv6-reachability-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"></bgp-ipv6-reachability-topology>
- </topology-types>
- <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-config">bgp-example</rib-id>
- </topology>
-
-Usage
-'''''
-Operational state of the topology can be verified via REST:
-
-**URL:** ``/restconf/operational/network-topology:network-topology/topology/bgp-example-ipv4-topology``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 8,11
-
- <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <topology-id>bgp-example-ipv4-topology</topology-id>
- <server-provided>true</server-provided>
- <topology-types>
- <bgp-ipv4-reachability-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"></bgp-ipv4-reachability-topology>
- </topology-types>
- <node>
- <node-id>10.10.1.1</node-id>
- <igp-node-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology">
- <prefix>
- <prefix>10.0.0.10/32</prefix>
- </prefix>
- </igp-node-attributes>
- </node>
- </topology>
-
-@line 8: The identifier of a node in a topology. Its value is mapped from route's NEXT_HOP attribute.
-
-@line 11: The IP prefix attribute of the node. Its value is mapped from routes's destination IP prefix.
-
-BGP Linkstate Topology
-^^^^^^^^^^^^^^^^^^^^^^
-BGP linkstate topology exporter offers a mapping service from BGP-LS routes to network topology nodes and links.
-
-Configuration
-'''''''''''''
-Following example shows how to create a new instance of linkstate BGP topology exporter:
-
-**URL:** ``/restconf/config/network-topology:network-topology``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
-
- <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <topology-id>bgp-example-linkstate-topology</topology-id>
- <topology-types>
- <bgp-linkstate-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"></bgp-linkstate-topology>
- </topology-types>
- <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-config">bgp-example</rib-id>
- </topology>
-
-Usage
-'''''
-Operational state of the topology can be verified via REST.
-A sample output below represents a two node topology with two unidirectional links interconnecting those nodes.
-
-**URL:** ``/restconf/operational/network-topology:network-topology/topology/bgp-example-linkstate-topology``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
-
- <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <topology-id>bgp-example-linkstate-topology</topology-id>
- <server-provided>true</server-provided>
- <topology-types>
- <bgp-linkstate-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"></bgp-linkstate-topology>
- </topology-types>
- <node>
- <node-id>bgpls://IsisLevel2:1/type=node&as=65000&domain=673720360&router=0000.0000.0040</node-id>
- <termination-point>
- <tp-id>bgpls://IsisLevel2:1/type=tp&ipv4=203.20.160.40</tp-id>
- <igp-termination-point-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology"/>
- </termination-point>
- <igp-node-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology">
- <prefix>
- <prefix>40.40.40.40/32</prefix>
- <metric>10</metric>
- </prefix>
- <prefix>
- <prefix>203.20.160.0/24</prefix>
- <metric>10</metric>
- </prefix>
- <name>node1</name>
- <router-id>40.40.40.40</router-id>
- <isis-node-attributes xmlns="urn:TBD:params:xml:ns:yang:network:isis-topology">
- <ted>
- <te-router-id-ipv4>40.40.40.40</te-router-id-ipv4>
- </ted>
- <iso>
- <iso-system-id>MDAwMDAwMDAwMDY0</iso-system-id>
- </iso>
- </isis-node-attributes>
- </igp-node-attributes>
- </node>
- <node>
- <node-id>bgpls://IsisLevel2:1/type=node&as=65000&domain=673720360&router=0000.0000.0039</node-id>
- <termination-point>
- <tp-id>bgpls://IsisLevel2:1/type=tp&ipv4=203.20.160.39</tp-id>
- <igp-termination-point-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology"/>
- </termination-point>
- <igp-node-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology">
- <prefix>
- <prefix>39.39.39.39/32</prefix>
- <metric>10</metric>
- </prefix>
- <prefix>
- <prefix>203.20.160.0/24</prefix>
- <metric>10</metric>
- </prefix>
- <name>node2</name>
- <router-id>39.39.39.39</router-id>
- <isis-node-attributes xmlns="urn:TBD:params:xml:ns:yang:network:isis-topology">
- <ted>
- <te-router-id-ipv4>39.39.39.39</te-router-id-ipv4>
- </ted>
- <iso>
- <iso-system-id>MDAwMDAwMDAwMDg3</iso-system-id>
- </iso>
- </isis-node-attributes>
- </igp-node-attributes>
- </node>
- <link>
- <destination>
- <dest-node>bgpls://IsisLevel2:1/type=node&as=65000&domain=673720360&router=0000.0000.0039</dest-node>
- <dest-tp>bgpls://IsisLevel2:1/type=tp&ipv4=203.20.160.39</dest-tp>
- </destination>
- <link-id>bgpls://IsisLevel2:1/type=link&local-as=65000&local-domain=673720360&local-router=0000.0000.0040&remote-as=65000&remote-domain=673720360&remote-router=0000.0000.0039&ipv4-iface=203.20.160.40&ipv4-neigh=203.20.160.39</link-id>
- <source>
- <source-node>bgpls://IsisLevel2:1/type=node&as=65000&domain=673720360&router=0000.0000.0040</source-node>
- <source-tp>bgpls://IsisLevel2:1/type=tp&ipv4=203.20.160.40</source-tp>
- </source>
- <igp-link-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology">
- <metric>10</metric>
- <isis-link-attributes xmlns="urn:TBD:params:xml:ns:yang:network:isis-topology">
- <ted>
- <color>0</color>
- <max-link-bandwidth>1250000.0</max-link-bandwidth>
- <max-resv-link-bandwidth>12500.0</max-resv-link-bandwidth>
- <te-default-metric>0</te-default-metric>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>0</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>1</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>2</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>3</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>4</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>5</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>6</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>7</priority>
- </unreserved-bandwidth>
- </ted>
- </isis-link-attributes>
- </igp-link-attributes>
- </link>
- <link>
- <destination>
- <dest-node>bgpls://IsisLevel2:1/type=node&as=65000&domain=673720360&router=0000.0000.0040</dest-node>
- <dest-tp>bgpls://IsisLevel2:1/type=tp&ipv4=203.20.160.40</dest-tp>
- </destination>
- <link-id>bgpls://IsisLevel2:1/type=link&local-as=65000&local-domain=673720360&local-router=0000.0000.0039&remote-as=65000&remote-domain=673720360&remote-router=0000.0000.0040&ipv4-iface=203.20.160.39&ipv4-neigh=203.20.160.40</link-id>
- <source>
- <source-node>bgpls://IsisLevel2:1/type=node&as=65000&domain=673720360&router=0000.0000.0039</source-node>
- <source-tp>bgpls://IsisLevel2:1/type=tp&ipv4=203.20.160.39</source-tp>
- </source>
- <igp-link-attributes xmlns="urn:TBD:params:xml:ns:yang:nt:l3-unicast-igp-topology">
- <metric>10</metric>
- <isis-link-attributes xmlns="urn:TBD:params:xml:ns:yang:network:isis-topology">
- <ted>
- <color>0</color>
- <max-link-bandwidth>1250000.0</max-link-bandwidth>
- <max-resv-link-bandwidth>12500.0</max-resv-link-bandwidth>
- <te-default-metric>0</te-default-metric>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>0</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>1</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>2</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>3</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>4</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>5</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>6</priority>
- </unreserved-bandwidth>
- <unreserved-bandwidth>
- <bandwidth>12500.0</bandwidth>
- <priority>7</priority>
- </unreserved-bandwidth>
- </ted>
- </isis-link-attributes>
- </igp-link-attributes>
- </link>
- </topology>
-
-BGP Network Topology Configuration Loader
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-BGP Network Topology Configuration Loader allows user to define static initial
-configuration for a BGP protocol instance.
-This service will detect the creation of new configuration files following the
-pattern ``network-topology-*.xml`` under the path ``etc/opendaylight/bgpcep``.
-Once the file is processed, the defined configuration will be available from
-the configuration Data Store.
-
-.. note:: If the BGP topology instance is already present, no update or configuration will be applied.
-
-**PATH:** ``etc/opendaylight/bgpcep/network-topology-config.xml``
-
-.. code-block:: xml
-
- <network-topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <topology>
- <topology-id>example-ipv4-topology</topology-id>
- <topology-types>
- <bgp-ipv4-reachability-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"/>
- </topology-types>
- <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-config">example-bgp-rib</rib-id>
- </topology>
- <topology>
- <topology-id>example-ipv6-topology</topology-id>
- <topology-types>
- <bgp-ipv6-reachability-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"/>
- </topology-types>
- <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-config">example-bgp-rib</rib-id>
- </topology>
- <topology>
- <topology-id>example-linkstate-topology</topology-id>
- <topology-types>
- <bgp-linkstate-topology xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-types"/>
- </topology-types>
- <rib-id xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-topology-config">example-bgp-rib</rib-id>
- </topology>
- </network-topology>
+++ /dev/null
-.. _bgp-user-guide-troubleshooting:
-
-Troubleshooting
-===============
-This section offers advices in a case OpenDaylight BGP plugin is not working as expected.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-BGP is not working...
-^^^^^^^^^^^^^^^^^^^^^
-* First of all, ensure that all required features are installed, local and remote BGP configuration is correct.
-
-* Check OpenDaylight Karaf logs:
-
-From Karaf console:
-
-.. code-block:: console
-
- log:tail
-
-or open log file: ``data/log/karaf.log``
-
-Possibly, a reason/hint for a cause of the problem can be found there.
-
-* Try to minimise effect of other OpenDaylight features, when searching for a reason of the problem.
-
-* Try to set DEBUG severity level for BGP logger via Karaf console commands, in order to collect more information:
-
-.. code-block:: console
-
- log:set DEBUG org.opendaylight.protocol.bgp
-
-.. code-block:: console
-
- log:set DEBUG org.opendaylight.bgpcep.bgp
-
-Bug reporting
-^^^^^^^^^^^^^
-Before you report a bug, check `BGPCEP Jira <https://jira.opendaylight.org/browse/BGPCEP-756?jql=project%20%3D%20BGPCEP%20AND%20component%20%3D%20BGP>`_ to ensure same/similar bug is not already filed there.
-
-Write an e-mail to bgpcep-users@lists.opendaylight.org and provide following information:
-
-#. State OpenDaylight version
-
-#. Describe your use-case and provide as much details related to BGP as possible
-
-#. Steps to reproduce
-
-#. Attach Karaf log files, optionally packet captures, REST input/output
+++ /dev/null
-.. _bgp-user-guide:
-
-BGP User Guide
-==============
-This guide contains information on how to use OpenDaylight Border Gateway Protocol (BGP) plugin.
-The user should learn about BGP basic concepts, supported capabilities, configuration and usage.
-
-.. toctree::
- :maxdepth: 4
-
- bgp-user-guide-overview
- bgp-user-guide-supported-capabilities
- bgp-user-guide-running-bgp
- bgp-user-guide-config-concepts
- bgp-user-guide-ip-unicast-family
- bgp-user-guide-labeled-family
- bgp-user-guide-l3vpn-family
- bgp-user-guide-linkstate-family
- bgp-user-guide-flowspec-family
- bgp-user-guide-mvpn-family
- bgp-user-guide-evpn-family
- bgp-user-guide-route-target-family
- bgp-user-guide-additional-path-capability
- bgp-user-guide-route-refresh-capability
- bgp-user-guide-operational-state
- bgp-user-guide-high-availability
- bgp-user-guide-topology-provider
- bgp-user-guide-test-tools
- bgp-user-guide-pmsi-attribute
- bgp-user-guide-troubleshooting
+++ /dev/null
-.. _bgp-monitoring-protocol-user-guide-config-concepts:
-
-BMP Monitoring Station
-======================
-The following section shows how to configure BMP basics, how to verify functionality and presents essential components of the plugin. Next samples demonstrate the plugin’s runtime configuration capability.
-
-The monitoring station is responsible for received BMP PDUs processing and storage.
-The default BMP server is listening at port *12345*.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-This section shows the way to configure the BMP monitoring station via REST API.
-
-Monitoring station configuration
-''''''''''''''''''''''''''''''''
-In order to change default's BMP monitoring station configuration, use following request.
-
-**URL:** ``/restconf/config/odl-bmp-monitor-config:odl-bmp-monitors/bmp-monitor-config/example-bmp-monitor``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 4,5
-
- <bmp-monitor-config xmlns="urn:opendaylight:params:xml:ns:yang:bmp-monitor-config">
- <monitor-id>example-bmp-monitor</monitor-id>
- <server>
- <binding-port>12345</binding-port>
- <binding-address>0.0.0.0</binding-address>
- </server>
- </bmp-monitor-config>
-
-@line 4: **binding-port** - The BMP server listening port.
-
-@line 5: **binding-address** - The BMP server biding address.
-
-.. note:: User may create multiple BMP monitoring station instances at runtime.
-
-Active mode configuration
-'''''''''''''''''''''''''
-In order to enable active connection, use following request.
-
-**URL:** ``/restconf/config/odl-bmp-monitor-config:odl-bmp-monitors/bmp-monitor-config/example-bmp-monitor``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 8,9,10
-
- <bmp-monitor-config xmlns="urn:opendaylight:params:xml:ns:yang:bmp-monitor-config">
- <monitor-id>example-bmp-monitor</monitor-id>
- <server>
- <binding-port>12345</binding-port>
- <binding-address>0.0.0.0</binding-address>
- </server>
- <monitored-router>
- <address>192.0.2.2</address>
- <port>1234</port>
- <active>true</active>
- </monitored-router>
- </bmp-monitor-config>
-
-@line 8: **address** - The monitored router's IP address.
-
-@line 9: **port** - The monitored router's port.
-
-@line 10: **active** - Active mode set.
-
-.. note:: User may configure active session establishment for multiple monitored routers.
-
-MD5 authentication configuration
-''''''''''''''''''''''''''''''''
-In order to enable active connection, use following request.
-
-**URL:** ``/restconf/config/odl-bmp-monitor-config:odl-bmp-monitors/bmp-monitor-config/example-bmp-monitor``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 8,9
-
- <bmp-monitor-config xmlns="urn:opendaylight:params:xml:ns:yang:bmp-monitor-config">
- <monitor-id>example-bmp-monitor</monitor-id>
- <server>
- <binding-port>12345</binding-port>
- <binding-address>0.0.0.0</binding-address>
- </server>
- <monitored-router>
- <address>192.0.2.2</address>
- <password>changeme</password>
- </monitored-router>
- </bmp-monitor-config>
-
-@line 8: **address** - The monitored router's IP address.
-
-@line 9: **password** - The TCP MD5 signature.
-
-BMP Monitors Configuration Loader
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-BMP Monitors Configuration Loader allows user to define static initial
-configuration for a BMP protocol instance.
-This service will detect the creation of new configuration files following the
-pattern ``odl-bmp-monitors-*.xml`` under the path ``etc/opendaylight/bgpcep``.
-Once the file is processed, the defined configuration will be available from
-the configuration Data Store.
-
-.. note:: If the BMP Monitor instance is already present, no update or configuration will be applied.
-
-**PATH:** ``etc/opendaylight/bgpcep/odl-bmp-monitors-config.xml``
-
-.. code-block:: xml
-
- <odl-bmp-monitors xmlns="urn:opendaylight:params:xml:ns:yang:bmp-monitor-config">
- <bmp-monitor-config>
- <monitor-id>example-bmp-monitor</monitor-id>
- <server>
- <binding-port>12345</binding-port>
- <binding-address>0.0.0.0</binding-address>
- </server>
- </bmp-monitor-config>
- </odl-bmp-monitors>
-
-BMP Monitor Configuration Example
-'''''''''''''''''''''''''''''''''
-
-BGP provides a feature providing a BMP Monitor configuration file example.
-Once feature is installed defined configuration will be loaded and setup.
-
-.. code-block:: console
-
- feature:install odl-bgpcep-bmp-config-example
-
-Collector DB Tree
-^^^^^^^^^^^^^^^^^
-
-.. code-block:: console
-
- module: bmp-monitor
- +--rw bmp-monitor
- +--ro monitor* [monitor-id]
- +--ro monitor-id monitor-id
- +--ro router* [router-id]
- +--ro name? string
- +--ro description? string
- +--ro info? string
- +--ro router-id router-id
- +--ro status? status
- +--ro peer* [peer-id]
- +--ro peer-id rib:peer-id
- +--ro type peer-type
- x--ro distinguisher
- | +--ro distinguisher-type? distinguisher-type
- | +--ro distinguisher? string
- +--ro peer-distinguisher? union
- +--ro address inet:ip-address
- +--ro as inet:as-number
- +--ro bgp-id inet:ipv4-address
- +--ro router-distinguisher? string
- +--ro peer-session
- | +--ro local-address inet:ip-address
- | +--ro local-port inet:port-number
- | +--ro remote-port inet:port-number
- | +--ro sent-open
- | | +--ro version? protocol-version
- | | +--ro my-as-number? uint16
- | | +--ro hold-timer uint16
- | | +--ro bgp-identifier inet:ipv4-address
- | | +--ro bgp-parameters*
- | | +--ro optional-capabilities*
- | | +--ro c-parameters
- | | +--ro as4-bytes-capability
- | | | +--ro as-number? inet:as-number
- | | +--ro bgp-extended-message-capability!
- | | +--ro multiprotocol-capability
- | | | +--ro afi? identityref
- | | | +--ro safi? identityref
- | | +--ro graceful-restart-capability
- | | | +--ro restart-flags bits
- | | | +--ro restart-time uint16
- | | | +--ro tables* [afi safi]
- | | | +--ro afi identityref
- | | | +--ro safi identityref
- | | | +--ro afi-flags bits
- | | +--ro add-path-capability
- | | | +--ro address-families*
- | | | +--ro afi? identityref
- | | | +--ro safi? identityref
- | | | +--ro send-receive? send-receive
- | | +--ro route-refresh-capability!
- | +--ro received-open
- | | +--ro version? protocol-version
- | | +--ro my-as-number? uint16
- | | +--ro hold-timer uint16
- | | +--ro bgp-identifier inet:ipv4-address
- | | +--ro bgp-parameters*
- | | +--ro optional-capabilities*
- | | +--ro c-parameters
- | | +--ro as4-bytes-capability
- | | | +--ro as-number? inet:as-number
- | | +--ro bgp-extended-message-capability!
- | | +--ro multiprotocol-capability
- | | | +--ro afi? identityref
- | | | +--ro safi? identityref
- | | +--ro graceful-restart-capability
- | | | +--ro restart-flags bits
- | | | +--ro restart-time uint16
- | | | +--ro tables* [afi safi]
- | | | +--ro afi identityref
- | | | +--ro safi identityref
- | | | +--ro afi-flags bits
- | | +--ro add-path-capability
- | | | +--ro address-families*
- | | | +--ro afi? identityref
- | | | +--ro safi? identityref
- | | | +--ro send-receive? send-receive
- | | +--ro route-refresh-capability!
- | +--ro information
- | | +--ro string-information*
- | | +--ro string-tlv
- | | +--ro string-info? string
- | +--ro status? status
- | +--ro timestamp-sec? yang:timestamp
- | +--ro timestamp-micro? yang:timestamp
- +--ro stats
- | +--ro rejected-prefixes? yang:counter32
- | +--ro duplicate-prefix-advertisements? yang:counter32
- | +--ro duplicate-withdraws? yang:counter32
- | +--ro invalidated-cluster-list-loop? yang:counter32
- | +--ro invalidated-as-path-loop? yang:counter32
- | +--ro invalidated-originator-id? yang:counter32
- | +--ro invalidated-as-confed-loop? yang:counter32
- | +--ro adj-ribs-in-routes? yang:gauge64
- | +--ro loc-rib-routes? yang:gauge64
- | +--ro per-afi-safi-adj-rib-in-routes
- | | +--ro afi-safi* [afi safi]
- | | +--ro afi identityref
- | | +--ro safi identityref
- | | +--ro count? yang:gauge64
- | +--ro per-afi-safi-loc-rib-routes
- | | +--ro afi-safi* [afi safi]
- | | +--ro afi identityref
- | | +--ro safi identityref
- | | +--ro count? yang:gauge64
- | +--ro updates-treated-as-withdraw? yang:counter32
- | +--ro prefixes-treated-as-withdraw? yang:counter32
- | +--ro duplicate-updates? yang:counter32
- | +--ro timestamp-sec? yang:timestamp
- | +--ro timestamp-micro? yang:timestamp
- +--ro pre-policy-rib
- | +--ro tables* [afi safi]
- | +--ro afi identityref
- | +--ro safi identityref
- | +--ro attributes
- | | +--ro uptodate? boolean
- | +--ro (routes)?
- +--ro post-policy-rib
- | +--ro tables* [afi safi]
- | +--ro afi identityref
- | +--ro safi identityref
- | +--ro attributes
- | | +--ro uptodate? boolean
- | +--ro (routes)?
- +--ro mirrors
- +--ro information? bmp-msg:mirror-information-code
- +--ro timestamp-sec? yang:timestamp
- +--ro timestamp-micro? yang:timestamp
-
-
-Operations
-^^^^^^^^^^
-The BMP plugin offers view of collected routes and statistical information from monitored peers.
-To get top-level view of monitoring station:
-
-**URL:** ``/restconf/operational/bmp-monitor:bmp-monitor/monitor/example-bmp-monitor``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,5,11,12,13,14,15,17,20,21,22,27,33,50,53
-
- <bmp-monitor xmlns="urn:opendaylight:params:xml:ns:yang:bmp-monitor">
- <monitor>
- <monitor-id>example-bmp-monitor</monitor-id>
- <router>
- <router-id>10.10.10.10</router-id>
- <name>name</name>
- <description>monitored-router</description>
- <info>monitored router;</info>
- <status>up</status>
- <peer>
- <peer-id>20.20.20.20</peer-id>
- <address>20.20.20.20</address>
- <bgp-id>20.20.20.20</bgp-id>
- <as>65000</as>
- <type>global</type>
- <peer-session>
- <remote-port>1790</remote-port>
- <timestamp-sec>0</timestamp-sec>
- <status>up</status>
- <local-address>10.10.10.10</local-address>
- <local-port>2200</local-port>
- <received-open>
- <hold-timer>180</hold-timer>
- <my-as-number>65000</my-as-number>
- <bgp-identifier>20.20.20.20</bgp-identifier>
- </received-open>
- <sent-open>
- <hold-timer>180</hold-timer>
- <my-as-number>65000</my-as-number>
- <bgp-identifier>65000</bgp-identifier>
- </sent-open>
- </peer-session>
- <pre-policy-rib>
- <tables>
- <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
- <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
- <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv4-route>
- <prefix>10.10.10.0/24</prefix>
- <attributes>
- ...
- </attributes>
- </ipv4-route>
- </ipv4-routes>
- <attributes>
- <uptodate>true</uptodate>
- </attributes>
- </tables>
- </pre-policy-rib>
- <post-policy-rib>
- ...
- </post-policy-rib>
- <stats>
- <timestamp-sec>0</timestamp-sec>
- <invalidated-cluster-list-loop>0</invalidated-cluster-list-loop>
- <duplicate-prefix-advertisements>0</duplicate-prefix-advertisements>
- <loc-rib-routes>100</loc-rib-routes>
- <duplicate-withdraws>0</duplicate-withdraws>
- <invalidated-as-confed-loop>0</invalidated-as-confed-loop>
- <adj-ribs-in-routes>10</adj-ribs-in-routes>
- <invalidated-as-path-loop>0</invalidated-as-path-loop>
- <invalidated-originator-id>0</invalidated-originator-id>
- <rejected-prefixes>8</rejected-prefixes>
- </stats>
- </peer>
- </router>
- </monitor>
- </bmp-monitor>
-
-@line 3: **monitor-id** - The BMP monitoring station instance identifier.
-
-@line 5: **router-id** - The monitored router IP address, serves as an identifier.
-
-@line 11: **peer-id** - The monitored peer's BGP identifier, serves a an identifier.
-
-@line 12: **address** - The IP address of the peer, associated with the TCP session.
-
-@line 13: **bgp-id** - The BGP Identifier of the peer.
-
-@line 14: **as** - The Autonomous System number of the peer.
-
-@line 15: **type** - Identifies type of the peer - *Global Instance*, *RD Instance* or *Local Instance*
-
-@line 17: **remote-port** - The peer's port number associated with TCP session.
-
-@line 20: **local-address** - The IP address of the monitored router associated with the peering TCP session.
-
-@line 21: **local-port** - The port number of the monitored router associated with the peering TCP session.
-
-@line 22: **received-open** - The full OPEN message received by monitored router from the peer.
-
-@line 27: **sent-open** - The full OPEN message send by monitored router to the peer.
-
-@line 33: **pre-policy-rib** - The Adj-RIB-In that contains unprocessed routing information.
-
-@line 50: **post-policy-rib** - The Post-Policy Ad-RIB-In that contains routes filtered by inbound policy.
-
-@line 53: **stats** - Contains various statistics, periodically updated by the router.
-
------
-
-* To view collected information from particular monitored router:
- **URL:** ``/restconf/operational/bmp-monitor:bmp-monitor/monitor/example-bmp-monitor/router/10.10.10.10``
-
-* To view collected information from particular monitored peer:
- **URL:** ``/restconf/operational/bmp-monitor:bmp-monitor/monitor/example-bmp-monitor/router/10.10.10.10/peer/20.20.20.20``
+++ /dev/null
-.. _bgp-monitoring-protocol-user-guide-overview:
-
-Overview
-========
-This section provides high-level overview of the BMP plugin, OpenDaylight implementation and BMP usage for SDN.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-BGP Monitoring Protocol
-^^^^^^^^^^^^^^^^^^^^^^^
-The BGP Monitoring Protocol (BMP) serves to monitor BGP sessions.
-The BMP can be used to obtain route view instead of screen scraping.
-The BMP provides access to unprocessed routing information (Adj-RIB-In) and processed routes (applied inbound policy) of monitored router's peer.
-In addition, monitored router can provide periodic dump of statistics.
-
-The BMP runs over TCP.
-Both monitored router and monitoring station can be configured as active or passive party of the connection.
-The passive party listens at particular port.
-The router can be monitored by multiple monitoring stations.
-BMP messages are sent by monitored router only, monitoring station supposed to collect and process data received over BMP.
-
-.. figure:: ./images/bmp.png
- :align: center
- :alt: BMP
-
- The BMP overview - Monitoring Station, Monitored Router and Monitored Peers.
-
-
-BMP in SDN
-^^^^^^^^^^
-The main concept of BMP is to monitor BGP sessions - monitoring station is aware of monitored peer's status, collects statistics and analyzes them in order to provide valuable information for network operators.
-
-Moreover, BMP provides provides peer RIBs visibility, without need to establish BGP sessions.
-Unprocessed routes may serve as a source of information for software-driven routing optimization.
-In this case, SDN controller, a BMP monitoring station, collects routing information from monitored routers.
-The routes are used in subsequent optimization procedures.
-
-
-OpenDaylight BMP plugin
-^^^^^^^^^^^^^^^^^^^^^^^
-The OpenDaylight BMP plugin provides monitoring station implementation.
-The plugin can establish BMP session with one or more monitored routers in order to collect routing and statistical information.
-
-* Runtime configurable monitoring station
-* Read-only routes and statistics view
-* Supports various routing information types
-
-.. figure:: ./images/bmp-plugin.png
- :align: center
- :alt: BMP plugin
-
- OpenDaylight BMP plugin overview.
-
-.. important:: The BMP plugin is not storing historical data, it provides current snapshot only.
+++ /dev/null
-.. _bgp-monitoring-protocol-user-guide-running-bmp:
-
-Running BMP
-===========
-This section explains how to install BMP plugin.
-
-1. Install BMP feature - ``odl-bgpcep-bmp``.
- Also, for sake of this sample, it is required to install RESTCONF.
- In the Karaf console, type command:
-
- .. code-block:: console
-
- feature:install odl-restconf odl-bgpcep-bmp
-
-2. The BMP plugin contains a default configuration, which is applied after the feature starts up.
- One instance of BMP monitoring station is created (named *example-bmp-monitor*), and its presence can be verified via REST:
-
- **URL:** ``/restconf/config/odl-bmp-monitor-config:odl-bmp-monitors/bmp-monitor-config/example-bmp-monitor``
-
- **Method:** ``GET``
-
- **Response Body:**
-
- .. code-block:: xml
-
- <bmp-monitor-config xmlns="urn:opendaylight:params:xml:ns:yang:bmp-monitor-config">
- <monitor-id>example-bmp-monitor</monitor-id>
- <server>
- <binding-port>12345</binding-port>
- <binding-address>0.0.0.0</binding-address>
- </server>
- </bmp-monitor-config>
+++ /dev/null
-.. _bgp-monitoring-protocol-user-guide-supported-capabilities:
-
-List of supported capabilities
-==============================
-The BMP plugin implementation is based on Internet standards:
-
-* `RFC7854 <https://tools.ietf.org/html/rfc7854>`_ - BGP Monitoring Protocol (BMP)
-
-.. note:: The BMP plugin is capable to process various types of routing information (IP Unicast, EVPN, L3VPN, Link-State,...).
- Please, see complete list in BGP user guide.
+++ /dev/null
-.. _bgp-monitoring-protocol-user-guide-test-tools:
-
-Test tools
-==========
-BMP test tool serves to test basic BMP functionality, scalability and performance.
-
-BMP mock
-^^^^^^^^
-The BMP mock is a stand-alone Java application purposed to simulate a BMP-enabled router(s) and peers.
-The simulator is capable to report dummy routes and statistics.
-This application is not part of the OpenDaylight Karaf distribution, however it can be downloaded from OpenDaylight's Nexus (use latest release version):
-
-``https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/bgpcep/bgp-bmp-mock``
-
-Usage
-'''''
-The application can be run from command line:
-
-.. code-block:: console
-
- java -jar bgp-bmp-mock-*-executable.jar
-
-
-with optional input parameters:
-
-.. code-block:: console
-
- --local_address <address> (optional, default 127.0.0.1)
- The IPv4 address where BMP mock is bind to.
-
- -ra <IP_ADDRESS:PORT,...>, --remote_address <IP_ADDRESS:PORT,...>
- A list of IP addresses of BMP monitoring station, by default 127.0.0.1:12345.
-
- --passive (optional, not present by default)
- This flags enables passive mode for simulated routers.
-
- --routers_count <0..N> (optional, default 1)
- An amount of BMP routers to be connected to the BMP monitoring station.
-
- --peers_count <0..N> (optional, default 0)
- An amount of peers reported by each BMP router.
-
- --pre_policy_routes <0..N> (optional, default 0)
- An amount of "pre-policy" simple IPv4 routes reported by each peer.
-
- --post_policy_routes <0..N> (optional, default 0)
- An amount of "post-policy" simple IPv4 routes reported by each peer.
-
- --log_level <FATAL|ERROR|INFO|DEBUG|TRACE> (optional, default INFO)
- Set logging level for BMP mock.
+++ /dev/null
-.. _bgp-monitoring-protocol-user-guide-troubleshooting:
-
-Troubleshooting
-===============
-This section offers advices in a case OpenDaylight BMP plugin is not working as expected.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-BMP is not working...
-^^^^^^^^^^^^^^^^^^^^^
-* First of all, ensure that all required features are installed, local monitoring station and monitored router/peers configuration is correct.
-
- To list all installed features in OpenDaylight use the following command at the Karaf console:
-
- .. code-block:: console
-
- feature:list -i
-
-* Check OpenDaylight Karaf logs:
-
- From Karaf console:
-
- .. code-block:: console
-
- log:tail
-
- or open log file: ``data/log/karaf.log``
-
- Possibly, a reason/hint for a cause of the problem can be found there.
-
-* Try to minimize effect of other OpenDaylight features, when searching for a reason of the problem.
-
-* Try to set DEBUG severity level for BMP logger via Karaf console commands, in order to collect more information:
-
- .. code-block:: console
-
- log:set DEBUG org.opendaylight.protocol.bmp
-
-Bug reporting
-^^^^^^^^^^^^^
-Before you report a bug, check `BGPCEP Jira <https://jira.opendaylight.org/projects/BGPCEP/issues/BGPCEP-589?filter=allopenissues>`_ to ensure same/similar bug is not already filed there.
-
-Write an e-mail to bgpcep-users@lists.opendaylight.org and provide following information:
-
-#. State OpenDaylight version
-
-#. Describe your use-case and provide as much details related to BMP as possible
-
-#. Steps to reproduce
-
-#. Attach Karaf log files, optionally packet captures, REST input/output
+++ /dev/null
-.. _bgp-monitoring-protocol-user-guide:
-
-BGP Monitoring Protocol User Guide
-==================================
-This guide contains information on how to use the OpenDaylight BGP Monitoring Protocol (BMP) plugin.
-It covers BMP basic concepts, supported capabilities, configuration and operations.
-
-.. toctree::
- :maxdepth: 1
-
- bgp-monitoring-protocol-user-guide-overview
- bgp-monitoring-protocol-user-guide-supported-capabilities
- bgp-monitoring-protocol-user-guide-running-bmp
- bgp-monitoring-protocol-user-guide-config-concepts
- bgp-monitoring-protocol-user-guide-test-tools
- bgp-monitoring-protocol-user-guide-troubleshooting
+++ /dev/null
-.. _pcep-user-guide:
-
-PCEP User Guide
-===============
-This guide contains information on how to use the OpenDaylight Path Computation Element Configuration Protocol (PCEP) plugin.
-The user should learn about PCEP basic concepts, supported capabilities, configuration and operations.
-
-
-.. toctree::
- :maxdepth: 1
-
- pcep-user-guide-overview
- pcep-user-guide-supported-capabilities
- pcep-user-guide-running-pcep
- pcep-user-guide-active-stateful-pce
- pcep-user-guide-session-statistics
- pcep-user-guide-cli
- pcep-user-guide-test-tools
- pcep-user-guide-troubleshooting
+++ /dev/null
-.. _pcep-user-guide-active-stateful-pce:
-
-Active Stateful PCE
-===================
-The PCEP extension for Stateful PCE brings a visibility of active LSPs to PCE, in order to optimize path computation, while considering individual LSPs and their interactions.
-This requires state synchronization mechanism between PCE and PCC.
-Moreover, Active Stateful PCE is capable to address LSP parameter changes to the PCC.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Configuration
-^^^^^^^^^^^^^
-This capability is enabled by default. No additional configuration is required.
-
-Speaker Entity identifier
-'''''''''''''''''''''''''
-The Speaker Entity Identifier is an optional
-TLV that may be included in the OPEN Object when a PCEP speaker
-wishes to determine if state synchronization can be skipped when a
-PCEP session is restarted.
-
-**URL:** ``/restconf/config/network-topology:network-topology/topology/pcep-topology/node/43.43.43.43``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,4
-
-
- <node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <node-id>43.43.43.43</node-id>
- <session-config xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep:config">
- <speaker-entity-id-value xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep:sync:optimizations:config">AQIDBA==</speaker-entity-id-value>
- </session-config>
- </node>
-
-@line 2: **address** - A PCC IP address.
-
-@line 4: **Speaker Entity Identifier** - The Speaker Entity identifier assigned to PCEP Node.
-
-MD5 authentication configuration
-''''''''''''''''''''''''''''''''
-The OpenDaylight PCEP implementation supports TCP MD5 for authentication.
-The sample configuration below shows how to set authentication password for a particular PCC.
-
-**URL:** ``/restconf/config/network-topology:network-topology/topology/pcep-topology/node/43.43.43.43``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,4
-
-
- <node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <node-id>43.43.43.43</node-id>
- <session-config xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep:config">
- <password>topsecret</password>
- </session-config>
- </node>
-
-@line 2: **address** - A PCC IP address.
-
-@line 4: **password** - MD5 authentication phrase.
-
-LSP State Database
-^^^^^^^^^^^^^^^^^^
-The *LSP State Database* (LSP-DB) contains an information about all LSPs and their attributes.
-The LSP state is synchronized between the PCC and PCE.
-First, initial LSP state synchronization is performed once the session between PCC and PCE is established in order to learn PCC's LPSs.
-This step is a prerequisite to following LSPs manipulation operations.
-
-
-.. figure:: ./images/pcep-sync.png
- :align: center
- :alt: LSP State synchronization
-
- LSP State Synchronization.
-
-LSP-DB API
-''''''''''
-
-.. code-block:: console
-
- path-computation-client
- +--ro reported-lsp* [name]
- +--ro name string
- +--ro path* [lsp-id]
- | +--ro lsp-id rsvp:lsp-id
- | +--ro ero
- | | +--ro processing-rule? boolean
- | | +--ro ignore? boolean
- | | +--ro subobject*
- | | +--ro loose boolean
- | | +--ro (subobject-type)?
- | | +--:(as-number-case)
- | | | +--ro as-number
- | | | +--ro as-number inet:as-number
- | | +--:(ip-prefix-case)
- | | | +--ro ip-prefix
- | | | +--ro ip-prefix inet:ip-prefix
- | | +--:(label-case)
- | | | +--ro label
- | | | +--ro uni-directional boolean
- | | | +--ro (label-type)?
- | | | +--:(type1-label-case)
- | | | | +--ro type1-label
- | | | | +--ro type1-label uint32
- | | | +--:(generalized-label-case)
- | | | | +--ro generalized-label
- | | | | +--ro generalized-label binary
- | | | +--:(waveband-switching-label-case)
- | | | +--ro waveband-switching-label
- | | | +--ro end-label uint32
- | | | +--ro start-label uint32
- | | | +--ro waveband-id uint32
- | | +--:(srlg-case)
- | | | +--ro srlg
- | | | +--ro srlg-id srlg-id
- | | +--:(unnumbered-case)
- | | | +--ro unnumbered
- | | | +--ro router-id uint32
- | | | +--ro interface-id uint32
- | | +--:(exrs-case)
- | | | +--ro exrs
- | | | +--ro exrs*
- | | | +--ro mandatory? boolean
- | | | +--ro attribute enumeration
- | | | +--ro (subobject-type)?
- | | | +--:(as-number-case)
- | | | | +--ro as-number
- | | | | +--ro as-number inet:as-number
- | | | +--:(ip-prefix-case)
- | | | | +--ro ip-prefix
- | | | | +--ro ip-prefix inet:ip-prefix
- | | | +--:(label-case)
- | | | | +--ro label
- | | | | +--ro uni-directional boolean
- | | | | +--ro (label-type)?
- | | | | +--:(type1-label-case)
- | | | | | +--ro type1-label
- | | | | | +--ro type1-label uint32
- | | | | +--:(generalized-label-case)
- | | | | | +--ro generalized-label
- | | | | | +--ro generalized-label binary
- | | | | +--:(waveband-switching-label-case)
- | | | | +--ro waveband-switching-label
- | | | | +--ro end-label uint32
- | | | | +--ro start-label uint32
- | | | | +--ro waveband-id uint32
- | | | +--:(srlg-case)
- | | | | +--ro srlg
- | | | | +--ro srlg-id srlg-id
- | | | +--:(unnumbered-case)
- | | | +--ro unnumbered
- | | | +--ro router-id uint32
- | | | +--ro interface-id uint32
- | | +--:(path-key-case)
- | | +--ro path-key
- | | +--ro pce-id pce-id
- | | +--ro path-key path-key
- | +--ro lspa
- | | +--ro processing-rule? boolean
- | | +--ro ignore? boolean
- | | +--ro hold-priority? uint8
- | | +--ro setup-priority? uint8
- | | +--ro local-protection-desired? boolean
- | | +--ro label-recording-desired? boolean
- | | +--ro se-style-desired? boolean
- | | +--ro session-name? string
- | | +--ro include-any? attribute-filter
- | | +--ro exclude-any? attribute-filter
- | | +--ro include-all? attribute-filter
- | | +--ro tlvs
- | | +--ro vendor-information-tlv*
- | | +--ro enterprise-number? iana:enterprise-number
- | | +--ro (enterprise-specific-information)?
- | +--ro bandwidth
- | | +--ro processing-rule? boolean
- | | +--ro ignore? boolean
- | | +--ro bandwidth? netc:bandwidth
- | +--ro reoptimization-bandwidth
- | | +--ro processing-rule? boolean
- | | +--ro ignore? boolean
- | | +--ro bandwidth? netc:bandwidth
- | +--ro metrics*
- | | +--ro metric
- | | +--ro processing-rule? boolean
- | | +--ro ignore? boolean
- | | +--ro metric-type uint8
- | | +--ro bound? boolean
- | | +--ro computed? boolean
- | | +--ro value? ieee754:float32
- | +--ro iro
- | | +--ro processing-rule? boolean
- | | +--ro ignore? boolean
- | | +--ro subobject*
- | | +--ro loose boolean
- | | +--ro (subobject-type)?
- | | +--:(as-number-case)
- | | | +--ro as-number
- | | | +--ro as-number inet:as-number
- | | +--:(ip-prefix-case)
- | | | +--ro ip-prefix
- | | | +--ro ip-prefix inet:ip-prefix
- | | +--:(label-case)
- | | | +--ro label
- | | | +--ro uni-directional boolean
- | | | +--ro (label-type)?
- | | | +--:(type1-label-case)
- | | | | +--ro type1-label
- | | | | +--ro type1-label uint32
- | | | +--:(generalized-label-case)
- | | | | +--ro generalized-label
- | | | | +--ro generalized-label binary
- | | | +--:(waveband-switching-label-case)
- | | | +--ro waveband-switching-label
- | | | +--ro end-label uint32
- | | | +--ro start-label uint32
- | | | +--ro waveband-id uint32
- | | +--:(srlg-case)
- | | | +--ro srlg
- | | | +--ro srlg-id srlg-id
- | | +--:(unnumbered-case)
- | | | +--ro unnumbered
- | | | +--ro router-id uint32
- | | | +--ro interface-id uint32
- | | +--:(exrs-case)
- | | | +--ro exrs
- | | | +--ro exrs*
- | | | +--ro mandatory? boolean
- | | | +--ro attribute enumeration
- | | | +--ro (subobject-type)?
- | | | +--:(as-number-case)
- | | | | +--ro as-number
- | | | | +--ro as-number inet:as-number
- | | | +--:(ip-prefix-case)
- | | | | +--ro ip-prefix
- | | | | +--ro ip-prefix inet:ip-prefix
- | | | +--:(label-case)
- | | | | +--ro label
- | | | | +--ro uni-directional boolean
- | | | | +--ro (label-type)?
- | | | | +--:(type1-label-case)
- | | | | | +--ro type1-label
- | | | | | +--ro type1-label uint32
- | | | | +--:(generalized-label-case)
- | | | | | +--ro generalized-label
- | | | | | +--ro generalized-label binary
- | | | | +--:(waveband-switching-label-case)
- | | | | +--ro waveband-switching-label
- | | | | +--ro end-label uint32
- | | | | +--ro start-label uint32
- | | | | +--ro waveband-id uint32
- | | | +--:(srlg-case)
- | | | | +--ro srlg
- | | | | +--ro srlg-id srlg-id
- | | | +--:(unnumbered-case)
- | | | +--ro unnumbered
- | | | +--ro router-id uint32
- | | | +--ro interface-id uint32
- | | +--:(path-key-case)
- | | +--ro path-key
- | | +--ro pce-id pce-id
- | | +--ro path-key path-key
- | +--ro rro
- | | +--ro processing-rule? boolean
- | | +--ro ignore? boolean
- | | +--ro subobject*
- | | +--ro protection-available? boolean
- | | +--ro protection-in-use? boolean
- | | +--ro (subobject-type)?
- | | +--:(ip-prefix-case)
- | | | +--ro ip-prefix
- | | | +--ro ip-prefix inet:ip-prefix
- | | +--:(label-case)
- | | | +--ro label
- | | | +--ro uni-directional boolean
- | | | +--ro (label-type)?
- | | | | +--:(type1-label-case)
- | | | | | +--ro type1-label
- | | | | | +--ro type1-label uint32
- | | | | +--:(generalized-label-case)
- | | | | | +--ro generalized-label
- | | | | | +--ro generalized-label binary
- | | | | +--:(waveband-switching-label-case)
- | | | | +--ro waveband-switching-label
- | | | | +--ro end-label uint32
- | | | | +--ro start-label uint32
- | | | | +--ro waveband-id uint32
- | | | +--ro global? boolean
- | | +--:(unnumbered-case)
- | | | +--ro unnumbered
- | | | +--ro router-id uint32
- | | | +--ro interface-id uint32
- | | +--:(path-key-case)
- | | +--ro path-key
- | | +--ro pce-id pce-id
- | | +--ro path-key path-key
- | +--ro xro
- | | +--ro processing-rule? boolean
- | | +--ro ignore? boolean
- | | +--ro flags bits
- | | +--ro subobject*
- | | +--ro mandatory? boolean
- | | +--ro attribute enumeration
- | | +--ro (subobject-type)?
- | | +--:(as-number-case)
- | | | +--ro as-number
- | | | +--ro as-number inet:as-number
- | | +--:(ip-prefix-case)
- | | | +--ro ip-prefix
- | | | +--ro ip-prefix inet:ip-prefix
- | | +--:(label-case)
- | | | +--ro label
- | | | +--ro uni-directional boolean
- | | | +--ro (label-type)?
- | | | +--:(type1-label-case)
- | | | | +--ro type1-label
- | | | | +--ro type1-label uint32
- | | | +--:(generalized-label-case)
- | | | | +--ro generalized-label
- | | | | +--ro generalized-label binary
- | | | +--:(waveband-switching-label-case)
- | | | +--ro waveband-switching-label
- | | | +--ro end-label uint32
- | | | +--ro start-label uint32
- | | | +--ro waveband-id uint32
- | | +--:(srlg-case)
- | | | +--ro srlg
- | | | +--ro srlg-id srlg-id
- | | +--:(unnumbered-case)
- | | +--ro unnumbered
- | | +--ro router-id uint32
- | | +--ro interface-id uint32
- | +--ro of
- | | +--ro processing-rule? boolean
- | | +--ro ignore? boolean
- | | +--ro code of-id
- | | +--ro tlvs
- | | +--ro vendor-information-tlv*
- | | +--ro enterprise-number? iana:enterprise-number
- | | +--ro (enterprise-specific-information)?
- | +--ro class-type
- | +--ro processing-rule? boolean
- | +--ro ignore? boolean
- | +--ro class-type class-type
- +--ro metadata
- +--ro lsp
- | +--ro processing-rule? boolean
- | +--ro ignore? boolean
- | +--ro tlvs
- | | +--ro lsp-error-code
- | | | +--ro error-code? uint32
- | | +--ro lsp-identifiers
- | | | +--ro lsp-id? rsvp:lsp-id
- | | | +--ro tunnel-id? rsvp:tunnel-id
- | | | +--ro (address-family)?
- | | | +--:(ipv4-case)
- | | | | +--ro ipv4
- | | | | +--ro ipv4-tunnel-sender-address inet:ipv4-address
- | | | | +--ro ipv4-extended-tunnel-id rsvp:ipv4-extended-tunnel-id
- | | | | +--ro ipv4-tunnel-endpoint-address inet:ipv4-address
- | | | +--:(ipv6-case)
- | | | +--ro ipv6
- | | | +--ro ipv6-tunnel-sender-address inet:ipv6-address
- | | | +--ro ipv6-extended-tunnel-id rsvp:ipv6-extended-tunnel-id
- | | | +--ro ipv6-tunnel-endpoint-address inet:ipv6-address
- | | +--ro rsvp-error-spec
- | | | +--ro (error-type)?
- | | | +--:(rsvp-case)
- | | | | +--ro rsvp-error
- | | | +--:(user-case)
- | | | +--ro user-error
- | | +--ro symbolic-path-name
- | | | +--ro path-name? symbolic-path-name
- | | o--ro vs-tlv
- | | | +--ro enterprise-number? iana:enterprise-number
- | | | +--ro (vendor-payload)?
- | | +--ro vendor-information-tlv*
- | | | +--ro enterprise-number? iana:enterprise-number
- | | | +--ro (enterprise-specific-information)?
- | | +--ro path-binding
- | | x--ro binding-type? uint8
- | | x--ro binding-value? binary
- | | +--ro (binding-type-value)?
- | | +--:(mpls-label)
- | | | +--ro mpls-label? netc:mpls-label
- | | +--:(mpls-label-entry)
- | | +--ro label? netc:mpls-label
- | | +--ro traffic-class? uint8
- | | +--ro bottom-of-stack? boolean
- | | +--ro time-to-live? uint8
- | +--ro plsp-id? plsp-id
- | +--ro delegate? boolean
- | +--ro sync? boolean
- | +--ro remove? boolean
- | +--ro administrative? boolean
- | +--ro operational? operational-status
- +--ro path-setup-type
- +--ro pst? uint8
-
------
-
-The LSP-DB is accessible via RESTCONF.
-The PCC's LSPs are stored in the ``pcep-topology`` while the session is active.
-In a next example, there is one PCEP session with PCC identified by its IP address (*43.43.43.43*) and one reported LSP (*foo*).
-
-**URL:** ``/restconf/operational/network-topology:network-topology/topology/pcep-topology/node/pcc:%2F%2F43.43.43.43``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,4,5,8,12,14,15,16,17,18,20,24,25,26,28,29,32,36
-
- <node>
- <node-id>pcc://43.43.43.43</node-id>
- <path-computation-client>
- <ip-address>43.43.43.43</ip-address>
- <state-sync>synchronized</state-sync>
- <stateful-tlv>
- <stateful>
- <lsp-update-capability>true</lsp-update-capability>
- </stateful>
- </stateful-tlv>
- <reported-lsp>
- <name>foo</name>
- <lsp>
- <operational>up</operational>
- <sync>true</sync>
- <plsp-id>1</plsp-id>
- <create>false</create>
- <administrative>true</administrative>
- <remove>false</remove>
- <delegate>true</delegate>
- <tlvs>
- <lsp-identifiers>
- <ipv4>
- <ipv4-tunnel-sender-address>43.43.43.43</ipv4-tunnel-sender-address>
- <ipv4-tunnel-endpoint-address>39.39.39.39</ipv4-tunnel-endpoint-address>
- <ipv4-extended-tunnel-id>39.39.39.39</ipv4-extended-tunnel-id>
- </ipv4>
- <tunnel-id>1</tunnel-id>
- <lsp-id>1</lsp-id>
- </lsp-identifiers>
- <symbolic-path-name>
- <path-name>Zm9v</path-name>
- </symbolic-path-name>
- </tlvs>
- </lsp>
- <ero>
- <subobject>
- <loose>false</loose>
- <ip-prefix>
- <ip-prefix>201.20.160.40/32</ip-prefix>
- </ip-prefix>
- </subobject>
- <subobject>
- <loose>false</loose>
- <ip-prefix>
- <ip-prefix>195.20.160.39/32</ip-prefix>
- </ip-prefix>
- </subobject>
- <subobject>
- <loose>false</loose>
- <ip-prefix>
- <ip-prefix>39.39.39.39/32</ip-prefix>
- </ip-prefix>
- </subobject>
- </ero>
- </reported-lsp>
- </path-computation-client>
- </node>
-
-@line 2: **node-id** The PCC identifier.
-
-@line 4: **ip-address** IP address of the PCC.
-
-@line 5: **state-sync** Synchronization status of the PCC's LSPs. The *synchronized* indicates the State Synchronization is done.
-
-@line 8: **lsp-update-capability** - Indicates that PCC allows LSP modifications.
-
-@line 12: **name** - Textual representation of LPS's name.
-
-@line 14: **operational** - Represent operational status of the LSP:
-
- * *down* - not active.
- * *up* - signaled.
- * *active* - up and carrying traffic.
- * *going-down* - LSP is being torn down, resources are being released.
- * *going-up* - LSP is being signaled.
-
-@line 15: **sync** - The flag set by PCC during LSPs State Synchronization.
-
-@line 16: **plsp-id** - A PCEP-specific identifier for the LSP. It is assigned by PCC and it is constant for a lifetime of a PCEP session.
-
-@line 17: **create** - The *false* indicates that LSP is PCC-initiated.
-
-@line 18: **administrative** - The flag indicates target operational status of the LSP.
-
-@line 20: **delegate** - The delegate flag indicates that the PCC is delegating the LSP to the PCE.
-
-@line 24: **ipv4-tunnel-sender-address** - Contains the sender node's IP address.
-
-@line 25: **ipv4-tunnel-endpoint-address** - Contains the egress node's IP address.
-
-@line 26: **ipv4-extended-tunnel-id** - The *Extended Tunnel ID* identifier.
-
-@line 28: **tunnel-id** - The *Tunnel ID* identifier.
-
-@line 29: **lsp-id** - The *LSP ID* identifier.
-
-@line 32: **path-name** - The symbolic name for the LSP.
-
-@line 36: **ero** - The *Explicit Route Object* is encoding the path of the TE LSP through the network.
-
-LSP Delegation
-''''''''''''''
-The LSP control delegations is an mechanism, where PCC grants to a PCE the temporary right in order to modify LSP attributes.
-The PCC can revoke the delegation or the PCE may waive the delegation at any time.
-The LSP control is delegated to at most one PCE at the same time.
-
-.. figure:: ./images/pcep-delegation-return.png
- :align: center
- :alt: Returning a Delegation
-
- Returning a Delegation.
-
------
-
-Following RPC example illustrates a request for the LSP delegation give up:
-
-**URL:** ``/restconf/operations/network-topology-pcep:update-lsp``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,3,6,10
-
- <input>
- <node>pcc://43.43.43.43</node>
- <name>foo</name>
- <arguments>
- <lsp xmlns:stateful="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
- <delegate>false</delegate>
- <administrative>true</administrative>
- <tlvs>
- <symbolic-path-name>
- <path-name>Zm9v</path-name>
- </symbolic-path-name>
- </tlvs>
- </lsp>
- </arguments>
- <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
- </input>
-
-@line 2: **node** The PCC identifier.
-
-@line 3: **name** The name of the LSP.
-
-@line 6: **delegate** - Delegation flag set *false* in order to return the LSP delegation.
-
-@line 10: **path-name** - The Symbolic Path Name TLV must be present when sending a request to give up the delegation.
-
-LSP Update
-''''''''''
-The LSP Update Request is an operation where a PCE requests a PCC to update attributes of an LSP and to rebuild the LSP with updated attributes.
-In order to update LSP, the PCE must hold a LSP delegation.
-The LSP update is done in *make-before-break* fashion - first, new LSP is initiated and then the old LSP is torn down.
-
-.. figure:: ./images/pcep-update.png
- :align: center
- :alt: Active Stateful PCE LSP Update
-
- Active Stateful PCE LSP Update.
-
------
-
-Following RPC example shows a request for the LSP update:
-
-**URL:** ``/restconf/operations/network-topology-pcep:update-lsp``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,3,6,7,9
-
- <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
- <node>pcc://43.43.43.43</node>
- <name>foo</name>
- <arguments>
- <lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
- <delegate>true</delegate>
- <administrative>true</administrative>
- </lsp>
- <ero>
- <subobject>
- <loose>false</loose>
- <ip-prefix>
- <ip-prefix>200.20.160.41/32</ip-prefix>
- </ip-prefix>
- </subobject>
- <subobject>
- <loose>false</loose>
- <ip-prefix>
- <ip-prefix>196.20.160.39/32</ip-prefix>
- </ip-prefix>
- </subobject>
- <subobject>
- <loose>false</loose>
- <ip-prefix>
- <ip-prefix>39.39.39.39/32</ip-prefix>
- </ip-prefix>
- </subobject>
- </ero>
- </arguments>
- <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
- </input>
-
-@line 2: **node** The PCC identifier.
-
-@line 3: **name** The name of the LSP to be updated.
-
-@line 6: **delegate** - Delegation flag set *true* in order to keep the LSP control.
-
-@line 7: **administrative** - Desired administrative status of the LSP is active.
-
-@line 9: **ero** - This LSP attribute is changed.
-
-PCE-initiated LSP Setup
-^^^^^^^^^^^^^^^^^^^^^^^
-The PCEP Extension for PCE-initiated LSP Setup allows PCE to request a creation and deletion of LSPs.
-
-Configuration
-'''''''''''''
-This capability is enabled by default. No additional configuration is required.
-
-LSP Instantiation
-'''''''''''''''''
-The PCE can request LSP creation.
-The LSP instantiation is done by sending an LSP Initiate Message to PCC.
-The PCC assign delegation to PCE which triggered creation.
-PCE-initiated LSPs are identified by *Create* flag.
-
-.. figure:: ./images/pcep-initiate.png
- :align: center
- :alt: LSP instantiation
-
- LSP instantiation.
-
------
-
-Following RPC example shows a request for the LSP initiation:
-
-**URL:** ``/restconf/operations/network-topology-pcep:add-lsp``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,3,8,14
-
- <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
- <node>pcc://43.43.43.43</node>
- <name>update-tunel</name>
- <arguments>
- <lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
- <delegate>true</delegate>
- <administrative>true</administrative>
- </lsp>
- <endpoints-obj>
- <ipv4>
- <source-ipv4-address>43.43.43.43</source-ipv4-address>
- <destination-ipv4-address>39.39.39.39</destination-ipv4-address>
- </ipv4>
- </endpoints-obj>
- <ero>
- <subobject>
- <loose>false</loose>
- <ip-prefix>
- <ip-prefix>201.20.160.40/32</ip-prefix>
- </ip-prefix>
- </subobject>
- <subobject>
- <loose>false</loose>
- <ip-prefix>
- <ip-prefix>195.20.160.39/32</ip-prefix>
- </ip-prefix>
- </subobject>
- <subobject>
- <loose>false</loose>
- <ip-prefix>
- <ip-prefix>39.39.39.39/32</ip-prefix>
- </ip-prefix>
- </subobject>
- </ero>
- </arguments>
- <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
- </input>
-
-@line 2: **node** The PCC identifier.
-
-@line 3: **name** The name of the LSP to be created.
-
-@line 8: **endpoints-obj** - The *END-POINT* Object is mandatory for an instantiation request of an RSVP-signaled LSP. It contains source and destination addresses for provisioning the LSP.
-
-@line 14: **ero** - The *ERO* object is mandatory for LSP initiation request.
-
-LSP Deletion
-''''''''''''
-The PCE may request a deletion of PCE-initiated LSPs.
-The PCE must be delegation holder for this particular LSP.
-
-.. figure:: ./images/pcep-deletion.png
- :align: center
- :alt: LSP deletion.
-
- LSP deletion.
-
------
-
-Following RPC example shows a request for the LSP deletion:
-
-**URL:** ``/restconf/operations/network-topology-pcep:remove-lsp``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,3
-
- <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
- <node>pcc://43.43.43.43</node>
- <name>update-tunel</name>
- <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
- </input>
-
-@line 2: **node** The PCC identifier.
-
-@line 3: **name** The name of the LSP to be removed.
-
-PCE-initiated LSP Delegation
-''''''''''''''''''''''''''''
-The PCE-initiated LSP control is delegated to the PCE which requested the initiation.
-The PCC cannot revoke delegation of PCE-initiated LSP.
-When PCE returns delegation for such LSP or PCE fails, then the LSP become orphan and can be removed by a PCC after some time.
-The PCE may ask for a delegation of the orphan LSP.
-
-.. figure:: ./images/pcep-revoke-delegation.png
- :align: center
- :alt: LSP re-delegation
-
- Orphan PCE-initiated LSP - control taken by PCE.
-
------
-
-Following RPC example illustrates a request for the LSP delegation:
-
-**URL:** ``/restconf/operations/network-topology-pcep:update-lsp``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,3,6,10
-
- <input>
- <node>pcc://43.43.43.43</node>
- <name>update-tunel</name>
- <arguments>
- <lsp xmlns:stateful="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
- <delegate>true</delegate>
- <administrative>true</administrative>
- <tlvs>
- <symbolic-path-name>
- <path-name>dXBkYXRlLXR1bmVs</path-name>
- </symbolic-path-name>
- </tlvs>
- </lsp>
- </arguments>
- <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
- </input>
-
-@line 2: **node** The PCC identifier.
-
-@line 3: **name** The name of the LSP.
-
-@line 6: **delegate** - *Delegation* flag set *true* in order to take the LSP delegation.
-
-@line 10: **path-name** - The *Symbolic Path Name* TLV must be present when sending a request to take a delegation.
-
-Segment Routing
-^^^^^^^^^^^^^^^
-The PCEP Extensions for Segment Routing (SR) allow a stateful PCE to compute and initiate TE paths in SR networks.
-The SR path is defined as an order list of *segments*.
-Segment Routing architecture can be directly applied to the MPLS forwarding plane without changes.
-Segment Identifier (SID) is encoded as a MPLS label.
-
-Configuration
-'''''''''''''
-This capability is enabled by default. In order to disable it, a configuration should be changed as follows:
-
-**URL:** ``/restconf/config/pcep-segment-routing-app-config:pcep-segment-routing-app-config``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2
-
- <pcep-segment-routing-config xmlns="urn:opendaylight:params:xml:ns:yang:controller:pcep:segment-routing-app-config">
- <sr-capable>false</sr-capable>
- </pcep-segment-routing-config>
-
-@line 2: **sr-capable** - True if capability is supported.
-
-IANA code points
-''''''''''''''''
-
-In PCEP-SR draft version 6, SR Explicit Route Object/Record Route Object subobjects IANA code points change was proposed.
-In order to use the latest code points, a configuration should be changed as follows:
-
-**URL:** ``/restconf/config/pcep-segment-routing-app-config:pcep-segment-routing-config``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2
-
- <pcep-segment-routing-config xmlns="urn:opendaylight:params:xml:ns:yang:controller:pcep:segment-routing-app-config">
- <iana-sr-subobjects-type>true</iana-sr-subobjects-type>
- </pcep-segment-routing-config>
-
-@line 2: **iana-sr-subobjects-type** - True if IANA code points should be used.
-
-LSP Operations for PCEP SR
-''''''''''''''''''''''''''
-The PCEP SR extension defines new ERO subobject - *SR-ERO subobject* capable of carrying a SID.
-
-.. code-block:: console
-
- sr-ero-type
- +---- c-flag? boolean
- +---- m-flag? boolean
- +---- sid-type? sid-type
- +---- sid? uint32
- +---- (nai)?
- +--:(ip-node-id)
- | +---- ip-address inet:ip-address
- +--:(ip-adjacency)
- | +---- local-ip-address inet:ip-address
- | +---- remote-ip-address inet:ip-address
- +--:(unnumbered-adjacency)
- +---- local-node-id uint32
- +---- local-interface-id uint32
- +---- remote-node-id uint32
- +---- remote-interface-id uint32
-
------
-
-Following RPC example illustrates a request for the SR-TE LSP creation:
-
-**URL:** ``/restconf/operations/network-topology-pcep:add-lsp``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 16,21,22,23
-
- <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
- <node>pcc://43.43.43.43</node>
- <name>sr-path</name>
- <arguments>
- <lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
- <delegate>true</delegate>
- <administrative>true</administrative>
- </lsp>
- <endpoints-obj>
- <ipv4>
- <source-ipv4-address>43.43.43.43</source-ipv4-address>
- <destination-ipv4-address>39.39.39.39</destination-ipv4-address>
- </ipv4>
- </endpoints-obj>
- <path-setup-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
- <pst>1</pst>
- </path-setup-type>
- <ero>
- <subobject>
- <loose>false</loose>
- <sid-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">ipv4-node-id</sid-type>
- <m-flag xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">true</m-flag>
- <sid xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">24001</sid>
- <ip-address xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">39.39.39.39</ip-address>
- </subobject>
- </ero>
- </arguments>
- <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
- </input>
-
-@line 16: **path-setup-type** - Set *1* for SR-TE LSP
-
-@line 21: **ipv4-node-id** - The SR-ERO subobject represents *IPv4 Node ID* NAI.
-
-@line 22: **m-flag** - The SID value represents an MPLS label.
-
-@line 23: **sid** - The Segment Identifier.
-
------
-
-Following RPC example illustrates a request for the SR-TE LSP update including modified path:
-
-**URL:** ``/restconf/operations/network-topology-pcep:update-lsp``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
-
- <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
- <node>pcc://43.43.43.43</node>
- <name>update-tunnel</name>
- <arguments>
- <lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
- <delegate>true</delegate>
- <administrative>true</administrative>
- </lsp>
- <path-setup-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
- <pst>1</pst>
- </path-setup-type>
- <ero>
- <subobject>
- <loose>false</loose>
- <sid-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">ipv4-node-id</sid-type>
- <m-flag xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">true</m-flag>
- <sid xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">24002</sid>
- <ip-address xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">200.20.160.41</ip-address>
- </subobject>
- <subobject>
- <loose>false</loose>
- <sid-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">ipv4-node-id</sid-type>
- <m-flag xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">true</m-flag>
- <sid xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">24001</sid>
- <ip-address xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">39.39.39.39</ip-address>
- </subobject>
- </ero>
- </arguments>
- <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
- </input>
-
-LSP State Synchronization Optimization Procedures
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This extension bring optimizations for state synchronization:
-
-* State Synchronization Avoidance
-* Incremental State Synchronization
-* PCE-triggered Initial Synchronization
-* PCE-triggered Re-synchronization
-
-Configuration
-'''''''''''''
-This capability is enabled by default. No additional configuration is required.
-
-State Synchronization Avoidance
-'''''''''''''''''''''''''''''''
-The State Synchronization Avoidance procedure is intended to skip state synchronization if the state has survived and not changed during session restart.
-
-.. figure:: ./images/pcep-sync-skipped.png
- :align: center
- :alt: Sync skipped
-
- State Synchronization Skipped.
-
-Incremental State Synchronization
-'''''''''''''''''''''''''''''''''
-The Incremental State Synchronization procedure is intended to do incremental (delta) state synchronization when possible.
-
-.. figure:: ./images/pcep-sync-incremental.png
- :align: center
- :alt: Sync incremental
-
- Incremental Synchronization Procedure.
-
-PCE-triggered Initial Synchronization
-'''''''''''''''''''''''''''''''''''''
-The PCE-triggered Initial Synchronization procedure is intended to do let PCE control the timing of the initial state synchronization.
-
-.. figure:: ./images/pcep-sync-initial.png
- :align: center
- :alt: Initial Sync
-
- PCE-triggered Initial State Synchronization Procedure.
-
------
-
-Following RPC example illustrates a request for the initial synchronization:
-
-**URL:** ``/restconf/operations/network-topology-pcep:trigger-sync``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
-
- <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
- <node>pcc://43.43.43.43</node>
- <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
- </input>
-
-PCE-triggered Re-synchronization
-''''''''''''''''''''''''''''''''
-The PCE-triggered Re-synchronization: To let PCE re-synchronize the state for sanity check.
-
-.. figure:: ./images/pcep-re-sync.png
- :align: center
- :alt: Re-sync
-
- PCE-triggered Re-synchronization Procedure.
-
------
-
-Following RPC example illustrates a request for the LSP re-synchronization:
-
-**URL:** ``/restconf/operations/network-topology-pcep:trigger-sync``
-
-**Method:** ``POST``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3
-
- <input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
- <node>pcc://43.43.43.43</node>
- <name>update-lsp</name>
- <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
- </input>
-
-@line 3: **name** - The LSP name. If this parameter is omitted, re-synchronization is requested for all PCC's LSPs.
+++ /dev/null
-.. _pcep-user-guide-cli:
-
-CLI
-===
-PCEP Karaf Console (odl-bgpcep-pcep-cli) provides a CLI feature to read session statistics per node.
-
-.. code-block:: bash
- :linenos:
-
- opendaylight-user@root> pcep:node-state -topology-id pcep-topology -node-id pcc://43.43.43.43
+++ /dev/null
-.. _pcep-user-guide-overview:
-
-Overview
-========
-This section provides a high-level overview of the PCEP, SDN use-cases and OpenDaylight implementation.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-Path Computation Element Communication Protocol
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The Path Computation Element (PCE) Communication Protocol (PCEP) is used for communication between a Path Computation Client (PCC) and a PCE in context of MPLS and GMPLS Traffic Engineering (TE) Label Switched Paths (LSPs).
-This interaction include path computation requests and computation replies.
-The PCE operates on a network graph, built from the (Traffic Engineering Database) TED, in order to compute paths based on the path computation request issued by the PCC.
-The path computation request includes the source and destination of the path and set of constrains to be applied during the computation.
-The PCE response contains the computed path or the computation failure reason.
-The PCEP operates on top the TCP, which provides reliable communication.
-
-.. figure:: ./images/pcep.png
- :align: center
- :alt: PCEP
-
- PCE-based architecture.
-
-PCEP in SDN
-^^^^^^^^^^^
-The Path Computation Element perfectly fits into the centralized SDN controller architecture.
-The PCE's knowledge of the availability of network resources (i.e. TED) and active LSPs awareness (LSP-DB) allows to perform automated application-driven network operations:
-
-* LSP Re-optimization
-* Resource defragmentation
-* Link failure restoration
-* Auto-bandwidth adjustment
-* Bandwidth scheduling
-* Shared Risk Link Group (SRLG) diversity maintenance
-
-OpenDaylight PCEP plugin
-^^^^^^^^^^^^^^^^^^^^^^^^
-The OpenDaylight PCEP plugin provides all basic service units necessary to build-up a PCE-based controller.
-In addition, it offers LSP management functionality for Active Stateful PCE - the cornerstone for majority of PCE-enabled SDN solutions.
-It consists of the following components:
-
-* Protocol library
-* PCEP session handling
-* Stateful PCE LSP-DB
-* Active Stateful PCE LSP Operations
-
-.. figure:: ./images/pcep-plugin.png
- :align: center
- :alt: PCEP plugin
-
- OpenDaylight PCEP plugin overview.
-
-.. important:: The PCEP plugin does not provide path computational functionality and does not build TED.
+++ /dev/null
-.. _pcep-user-guide-running-pcep:
-
-Running PCEP
-============
-This section explains how to install PCEP plugin.
-
-1. Install PCEP feature - ``odl-bgpcep-pcep``.
- Also, for sake of this sample, it is required to install RESTCONF.
- In the Karaf console, type command:
-
- .. code-block:: console
-
- feature:install odl-restconf odl-bgpcep-pcep
-
-2. The PCEP plugin contains a default configuration, which is applied after the feature starts up.
- One instance of PCEP plugin is created (named *pcep-topology*), and its presence can be verified via REST:
-
- **URL:** ``restconf/operational/network-topology:network-topology/topology/pcep-topology``
-
- **Method:** ``GET``
-
- **Response Body:**
-
- .. code-block:: xml
-
- <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <topology-id>pcep-topology</topology-id>
- <topology-types>
- <topology-pcep xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep"></topology-pcep>
- </topology-types>
- </topology>
+++ /dev/null
-.. _pcep-user-guide-session-statistics:
-
-Session statistics
-==================
-The PCEP statistics provides information about PCE <-> PCC session and its stateful listener (topology-provider).
-
-Usage
-'''''
-
-**URL:** ``/restconf/operational/network-topology:network-topology/topology/pcep-topology/node/pcc:%2F%2F43.43.43.43/pcep-session-state``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 3,4,5,6,7,8,9,10,13,14,15,16,19,20,21,22,25,26,27,28,31,32,33,35,36,37
-
- <pcep-session-state xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep:stats">
- <messages>
- <last-received-rpt-msg-timestamp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:stateful:stats">1512640592</last-received-rpt-msg-timestamp>
- <sent-upd-msg-count xmlns="urn:opendaylight:params:xml:ns:yang:pcep:stateful:stats">0</sent-upd-msg-count>
- <received-rpt-msg-count xmlns="urn:opendaylight:params:xml:ns:yang:pcep:stateful:stats">2</received-rpt-msg-count>
- <sent-init-msg-count xmlns="urn:opendaylight:params:xml:ns:yang:pcep:stateful:stats">0</sent-init-msg-count>
- <sent-msg-count>0</sent-msg-count>
- <last-sent-msg-timestamp>0</last-sent-msg-timestamp>
- <unknown-msg-received>0</unknown-msg-received>
- <received-msg-count>2</received-msg-count>
- <error-messages>
- <last-sent-error></last-sent-error>
- <received-error-msg-count>0</received-error-msg-count>
- <sent-error-msg-count>0</sent-error-msg-count>
- <last-received-error></last-received-error>
- </error-messages>
- <reply-time>
- <average-time>0</average-time>
- <min-time>0</min-time>
- <max-time>0</max-time>
- </reply-time>
- </messages>
- <peer-pref>
- <keepalive>30</keepalive>
- <deadtimer>120</deadtimer>
- <ip-address>127.0.0.1</ip-address>
- <session-id>0</session-id>
- </peer-pref>
- <local-pref>
- <keepalive>30</keepalive>
- <deadtimer>120</deadtimer>
- <ip-address>127.0.0.1</ip-address>
- <session-id>0</session-id>
- </local-pref>
- <peer-capabilities>
- <stateful xmlns="urn:opendaylight:params:xml:ns:yang:pcep:stateful:stats">true</stateful>
- <instantiation xmlns="urn:opendaylight:params:xml:ns:yang:pcep:stateful:stats">true</instantiation>
- <active xmlns="urn:opendaylight:params:xml:ns:yang:pcep:stateful:stats">true</active>
- </peer-capabilities>
- <session-duration>0:00:00:18</session-duration>
- <delegated-lsps-count>1</delegated-lsps-count>
- <synchronized>true</synchronized>
- </pcep-session-state>
-
-@line 3: **last-received-rpt-msg-timestamp** - The timestamp of last received PCRpt message.
-
-@line 4: **sent-upd-msg-count** - The number of sent PCUpd messages.
-
-@line 5: **received-rpt-msg-count** - The number of received PcRpt messages.
-
-@line 6: **sent-init-msg-count** - The number of sent PCInitiate messages.
-
-@line 7: **sent-msg-count** - Total number of sent PCEP messages.
-
-@line 8: **last-sent-msg-timestamp** - The timestamp of last sent message.
-
-@line 9: **unknown-msg-received** - The number of received unknown messages.
-
-@line 10: **received-msg-count** - Total number of received PCEP messages.
-
-@line 13: **last-sent-error** - Type/value tuple of last sent error.
-
-@line 14: **received-error-msg-count** - Total number of received PCErr messages.
-
-@line 15: **sent-error-msg-count** - Total number of sent PCErr messages.
-
-@line 16: **last-received-error** - Type/value tuple of last sent error.
-
-@line 19: **keepalive** - Advertised keep-alive value.
-
-@line 20: **deadtimer** - Advertised deadtimer value.
-
-@line 21: **ip-address** - Peer's IP address.
-
-@line 22: **session-id** - Peer's session identifier.
-
-@line 25: **keepalive** - Advertised keep-alive value.
-
-@line 26: **deadtimer** - Advertised deadtimer value.
-
-@line 27: **ip-address** - Peer's IP address.
-
-@line 28: **session-id** - Peer's session identifier.
-
-@line 31: **stateful** - Represents peer's stateful/stateless capability.
-
-@line 32: **instantiation** - Represents peer's instantiation capability.
-
-@line 33: **active** - Represents peer's LSP update capability.
-
-@line 35: **session-duration** - Elapsed time (in d:H:m:s) from session-up until last statistic update.
-
-@line 36: **delegated-lsps-count** - The number of delegated LSPs (tunnels) from PCC.
-
-@line 37: **synchronized** - Represents synchronization status.
+++ /dev/null
-.. _pcep-user-guide-supported-capabilities:
-
-List of supported capabilities
-==============================
-
-* `RFC5440 <https://tools.ietf.org/html/rfc5440>`_ - Path Computation Element (PCE) Communication Protocol (PCEP)
-* `RFC5455 <https://tools.ietf.org/html/rfc5455>`_ - Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol
-* `RFC5520 <https://tools.ietf.org/html/rfc5520>`_ - Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism
-* `RFC5521 <https://tools.ietf.org/html/rfc5521>`_ - Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions
-* `RFC5541 <https://tools.ietf.org/html/rfc5541>`_ - Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)
-* `RFC5557 <https://tools.ietf.org/html/rfc5557>`_ - Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization
-* `RFC5886 <https://tools.ietf.org/html/rfc5886>`_ - A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture
-* `RFC7470 <https://tools.ietf.org/html/rfc7470>`_ - Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol
-* `RFC7896 <https://tools.ietf.org/html/rfc7896>`_ - Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP)
-* `draft-ietf-pce-stateful-pce <https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-16>`_ - PCEP Extensions for Stateful PCE
- * `draft-ietf-pce-pce-initiated-lsp <https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07>`_ - PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model
- * `draft-ietf-pce-segment-routing <https://tools.ietf.org/html/draft-ietf-pce-segment-routing-07>`_ - PCEP Extension for segment routing
- * `draft-ietf-pce-lsp-setup-type <https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-03>`_ - PCEP Extension for path setup type
- * `draft-ietf-pce-stateful-sync-optimizations <https://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations-05>`_ - Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE
- * `draft-sivabalan-pce-binding-label-sid <https://tools.ietf.org/html/draft-sivabalan-pce-binding-label-sid-01>`_ - Carrying Binding Label/Segment-ID in PCE-based Networks
-* `draft-ietf-pce-pceps <https://tools.ietf.org/html/draft-ietf-pce-pceps-10>`_ - Secure Transport for PCEP
+++ /dev/null
-.. _pcep-user-guide-test-tools:
-
-Test tools
-==========
-
-PCC Mock
-^^^^^^^^
-The PCC Mock is a stand-alone Java application purposed to simulate a PCC(s).
-The simulator is capable to report sample LSPs, respond to delegation, LSP management operations and synchronization optimization procedures.
-This application is not part of the OpenDaylight Karaf distribution, however it can be downloaded from OpenDaylight's Nexus (use latest release version):
-
-``https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/bgpcep/pcep-pcc-mock``
-
-Usage
-'''''
-The application can be run from command line:
-
-.. code-block:: console
-
- java -jar pcep-pcc-mock-*-executable.jar
-
-
-with optional input parameters:
-
-.. code-block:: console
-
- --local-address <Address:Port> (optional, default 127.0.0.1)
- The first PCC IP address. If more PCCs are required, the IP address will be incremented. Port number can be optionally specified.
-
- --remote-address <Address1:Port1,Address2:Port2,Address3:Port3,...> (optional, default 127.0.0.1:4189)
- The list of IP address for the PCE servers. Port number can be optionally specified, otherwise default port number 4189 is used.
-
- --pcc <N> (optional, default 1)
- Number of mocked PCC instances.
-
- --lsp <N> (optional, default 1)
- Number of tunnels (LSPs) reported per PCC, might be zero.
-
- --pcerr (optional flag)
- If the flag is present, response with PCErr, otherwise PCUpd.
-
- --log-level <LEVEL> (optional, default INFO)
- Set logging level for pcc-mock.
-
- -d, --deadtimer <0..255> (optional, default 120)
- DeadTimer value in seconds.
-
- -ka, --keepalive <0.255> (optional, default 30)
- KeepAlive timer value in seconds.
-
- --password <password> (optional)
- If the password is present, it is used in TCP MD5 signature, otherwise plain TCP is used.
-
- --reconnect <seconds> (optional)
- If the argument is present, the value in seconds, is used as a delay before each new reconnect (initial connect or connection re-establishment) attempt.
- The number of reconnect attempts is unlimited. If the argument is omitted, pcc-mock is not trying to reconnect.
-
- --redelegation-timeout <seconds> (optional, default 0)
- The timeout starts when LSP delegation is returned or PCE fails, stops when LSP is re-delegated to PCE.
- When timeout expires, LSP delegation is revoked and held by PCC.
-
- --state-timeout <seconds> (optional, default -1 (disabled))
- The timeout starts when LSP delegation is returned or PCE fails, stops when LSP is re-delegated to PCE.
- When timeout expires, PCE-initiated LSP is removed.
-
- --state-sync-avoidance <disconnect_after_x_seconds> <reconnect_after_x_seconds> <dbVersion>
- Synchronization avoidance capability enabled.
- - disconnect_after_x_seconds: seconds that will pass until disconnections is forced. If set to smaller number than 1, disconnection wont be performed.
- - reconnect_after_x_seconds: seconds that will pass between disconnection and new connection attempt. Only happens if disconnection has been performed.
- - dbVersion: dbVersion used in new Open and must be always equal or bigger than LSP. If equal than LSP skip synchronization will be performed,
- if not full synchronization will be performed taking in account new starting dbVersion desired.
- --incremental-sync-procedure <disconnect_after_x_seconds> <reconnect_after_x_seconds> <dbVersion>
- Incremental synchronization capability enabled.
- - dbVersion: dbVersion used in new Open and must be always bigger than LSP. Incremental synchronization will be performed taking in account new starting dbVersion desired.
-
- --triggered-initial-sync
- PCE-triggered synchronization capability enabled. Can be combined combined with state-sync-avoidance/incremental-sync-procedure.
-
- --triggered-re-sync
- PCE-triggered re-synchronization capability enabled.
-
-Data Change Counter Tool
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-Data Change Counter tool registers a Data Change Listener to a specified topology's subtree.
-This will allow us to know the quantity of changes produced under it, with each data change event counter will be incremented.
-
-Installation
-''''''''''''
-Installing data change counter tool
-
-.. code-block:: console
-
- feature:install odl-restconf odl-bgpcep-data-change-counter
-
-Configuration
-'''''''''''''
-Once we set the configuration, a new data change counter will be created and registers to example-linkstate-topology.
-
-.. important:: **Clustering** - Each Counter Identifier should be unique.
-
-**URL:** ``/restconf/config/odl-data-change-counter-config:data-change-counter-config/data-change-counter``
-
-**Method:** ``PUT``
-
-**Content-Type:** ``application/xml``
-
-**Request Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,3
-
- <data-change-counter-config xmlns="urn:opendaylight:params:xml:ns:yang:bgpcep:data-change-counter-config">
- <counter-id>data-change-counter</counter-id>
- <topology-name>example-linkstate-topology</topology-name>
- </data-change-counter-config>
-
-@line 2: **Counter Id** - Unique counter change identifier.
-
-@line 3: **Topology Name** - An identifier for a topology.
-
-Usage
-'''''
-
-Counter state for topology
-
-**URL:** ``/restconf/operational/data-change-counter:data-change-counter/counter/data-change-counter``
-
-**Method:** ``GET``
-
-**Response Body:**
-
-.. code-block:: xml
- :linenos:
- :emphasize-lines: 2,3
-
- <counter xmlns="urn:opendaylight:params:xml:ns:yang:bgp-data-change-counter">
- <id>data-change-counter</id>
- <count>0</count>
- </counter>
-
-@line 2: **Counter Id** - Unique counter change identifier.
-
-@line 3: **Count** - Number of changes under registered topology's subtree.
+++ /dev/null
-.. _pcep-user-guide-troubleshooting:
-
-Troubleshooting
-===============
-This section offers advices in a case OpenDaylight PCEP plugin is not working as expected.
-
-.. contents:: Contents
- :depth: 2
- :local:
-
-PCEP is not working...
-^^^^^^^^^^^^^^^^^^^^^^
-* First of all, ensure that all required features are installed, local PCE and remote PCC configuration is correct.
-
- To list all installed features in OpenDaylight use the following command at the Karaf console:
-
- .. code-block:: console
-
- feature:list -i
-
-* Check OpenDaylight Karaf logs:
-
- From Karaf console:
-
- .. code-block:: console
-
- log:tail
-
- or open log file: ``data/log/karaf.log``
-
- Possibly, a reason/hint for a cause of the problem can be found there.
-
-* Try to minimize effect of other OpenDaylight features, when searching for a reason of the problem.
-
-* Try to set DEBUG severity level for PCEP logger via Karaf console commands, in order to collect more information:
-
- .. code-block:: console
-
- log:set DEBUG org.opendaylight.protocol.pcep
-
- .. code-block:: console
-
- log:set DEBUG org.opendaylight.bgpcep.pcep
-
-Bug reporting
-^^^^^^^^^^^^^
-Before you report a bug, check `BGPCEP Jira <https://jira.opendaylight.org/projects/BGPCEP/issues/BGPCEP-589?filter=allopenissues>`_ to ensure same/similar bug is not already filed there.
-
-Write an e-mail to bgpcep-users@lists.opendaylight.org and provide following information:
-
-#. State OpenDaylight version
-
-#. Describe your use-case and provide as much details related to PCEP as possible
-
-#. Steps to reproduce
-
-#. Attach Karaf log files, optionally packet captures, REST input/output
-
-References
-----------
-* `A Path Computation Element (PCE)-Based Architecture <https://tools.ietf.org/html/rfc4655>`_
-* `Path Computation Element (PCE) Communication Protocol Generic Requirements <https://tools.ietf.org/html/rfc4657>`_
-* `Unanswered Questions in the Path Computation Element Architecture <https://tools.ietf.org/html/rfc7399>`_
-* `A PCE-Based Architecture for Application-Based Network Operations <https://tools.ietf.org/html/rfc7491>`_
-* `Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering <https://tools.ietf.org/html/rfc5623>`_
-* `Applicability of a Stateful Path Computation Element (PCE) <https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-app-07>`_
+++ /dev/null
-.. _bier-user-guide:
-
-BIER User Guide
-===============
-
-Overview
---------
-
-The technology of Bit Index Explicit Replication (BIER) specifies a new
-architecture for the forwarding of multicast data packets. It provides
-optimal forwarding of multicast data packets through a "multicast domain".
-However, it does not require the use of a protocol for explicitly building
-multicast distribution trees, and it does not require intermediate nodes
-to maintain any per-flow state. See specific in `draft-ietf-bier-architecture-05
-<https://datatracker.ietf.org/doc/draft-ietf-bier-architecture/>`_
-and related documents.
-
-The BIER project provides functionality about BIER/BIER-TE topo-mamagement and BIER/BIER-TE
-channel-mamagement, and invoking south-bound-interface for device driver.
-
-
-BIER User-Facing Features
--------------------------
-- **odl-bier-all**
-
- - This feature contains all other features/bundles of BIER project. If you
- install it, it provides all functions that the BIER project can support.
-
-- **odl-bier-models**
-
- - This feature contains all models of BIER project, such as ietf-bier,
- ietf-multicast-information and so on.
-
-- **odl-bier-bierman**
-
- - This feature generates BIER's topology from network topology, and configuration
- of BIER, BIER-TE, etc.
-
-- **odl-bier-channel**
-
- - This feature provides function about multicast flow information configuration
- and deployment in BIER domain.
-
-- **odl-bier-service**
-
- - This feature provides function which processing the result of BIER bierman and BIER
- channel, and invoking south-bound-interface for driver.
-
-- **odl-bier-adapter**
-
- - This feature provides adapter for different BIER south-bound NETCONF
- interfaces, so all BFRs in BIER domain with different NETCONF
- configuration interfaces and they can operate normally together.
-
-- **odl-bier-driver**
-
- - This feature is south-bound NETCONF interface for BIER, it has implemented standard interface
- (ietf-bier). If your BFR's NETCONF interface is Non-standard, you should add your own
- interface for driver.
-
-- **odl-te-pce**
-
- - This feature provides path computation function for BIER-TE.
-
-- **odl-bier-app**
-
- - This feature provides the interface of BIER management, which contain BIER/BIER-TE manager,
- channel manager, topology manager.
-
-
-How To Start
--------------
-
-Preparing for Installation
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-1. Forwarding devices must support the BGP-LS protocol, and already be
- configured so that OpenDaylight can discover those devices.
-
-2. Forwarding devices must support BIER configuration via NETCONF, which has a
- standard IETF YANG model.
-
-3. The feature *odl-bier-app* or third-party App provides the northbound interface
- of BIER management for BIER controller.
-
-
-Installation Feature
-~~~~~~~~~~~~~~~~~~~~
-
-Run OpenDaylight and install BIER Service *odl-bier-all* as below::
-
- feature:install odl-bier-all
-
-For a more detailed overview of the BIER, see the :ref:`bier-dev-guide`.
+++ /dev/null
-CAPWAP User Guide
-=================
-
-This document describes how to use the Control And Provisioning of
-Wireless Access Points (CAPWAP) feature in OpenDaylight. This document
-contains configuration, administration, and management sections for the
-feature.
-
-Overview
---------
-
-CAPWAP feature fills the gap OpenDaylight Controller has with respect to
-managing CAPWAP compliant wireless termination point (WTP) network
-devices present in enterprise networks. Intelligent applications (e.g.
-centralized firmware management, radio planning) can be developed by
-tapping into the WTP network device’s operational states via REST APIs.
-
-CAPWAP Architecture
--------------------
-
-The CAPWAP feature is implemented as an MD-SAL based provider module,
-which helps discover WTP devices and update their states in MD-SAL
-operational datastore.
-
-Scope of CAPWAP Project
------------------------
-
-In this release, CAPWAP project aims to only detect the WTPs and
-store their basic attributes in the operational data store, which is
-accessible via REST and JAVA APIs.
-
-Installing CAPWAP
------------------
-
-To install CAPWAP, download OpenDaylight and use the Karaf console to
-install the following feature:
-
-odl-capwap-ac-rest
-
-Configuring CAPWAP
-------------------
-
-As of this release, there are no configuration requirements.
-
-Administering or Managing CAPWAP
---------------------------------
-
-After installing the odl-capwap-ac-rest feature from the Karaf console,
-users can administer and manage CAPWAP from the APIDOCS explorer.
-
-Go to
-`http://${ipaddress}:8181/apidoc/explorer/index.html <http://${ipaddress}:8181/apidoc/explorer/index.html>`__,
-sign in, and expand the capwap-impl panel. From there, users can execute
-various API calls.
-
-Tutorials
----------
-
-Viewing Discovered WTPs
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-This tutorial can be used as a walk through to understand the steps for
-starting the CAPWAP feature, detecting CAPWAP WTPs, accessing the
-operational states of WTPs.
-
-Prerequisites
-^^^^^^^^^^^^^
-
-It is assumed that user has access to at least one hardware/software
-based CAPWAP compliant WTP. These devices should be configured with
-OpenDaylight controller IP address as a CAPWAP Access Controller (AC)
-address. It is also assumed that WTPs and OpenDaylight controller share
-the same ethernet broadcast domain.
-
-Instructions
-^^^^^^^^^^^^
-
-1. Run the OpenDaylight distribution and install odl-capwap-ac-rest from
- the Karaf console.
-
-2. Go to
- `http://${ipaddress}:8181/apidoc/explorer/index.html <http://${ipaddress}:8181/apidoc/explorer/index.html>`__
-
-3. Expand capwap-impl
-
-4. Click /operational/capwap-impl:capwap-ac-root/
-
-5. Click "Try it out"
-
-6. The above step should display list of WTPs discovered using ODL
- CAPWAP feature.
-
+++ /dev/null
-.. _cardinal-user-guide:
-
-Cardinal: OpenDaylight Monitoring as a Service
-==============================================
-
-This section describes how to use the Cardinal feature in OpenDaylight
-and contains configuration, administration, and management sections for
-the feature.
-
-Overview
---------
-
-Cardinal (OpenDaylight Monitoring as a Service) enables OpenDaylight and
-the underlying software defined network to be remotely monitored by
-deployed Network Management Systems (NMS) or Analytics suite. In the
-Boron release, Cardinal will add:
-
-1. OpenDaylight MIB.
-
-2. Enable ODL diagnostics/monitoring to be exposed across SNMP (v2c, v3)
- and REST north-bound.
-
-3. Extend ODL System health, Karaf parameter and feature info, ODL
- plugin scalability and network parameters.
-
-4. Support autonomous notifications (SNMP Traps).
-
-Cardinal Architecture
----------------------
-
-The Cardinal architecture can be found at the below link:
-
-https://wiki.opendaylight.org/images/8/89/Cardinal-ODL_Monitoring_as_a_Service_V2.pdf
-
-Configuring Cardinal feature
-----------------------------
-
-To start Cardinal feature, start karaf and type the following command:
-
-::
-
- feature:install odl-cardinal
-
-After this Cardinal should be up and working with SNMP daemon running on
-port 161.
-
-Tutorials
----------
-
-Below are tutorials for Cardinal.
-
-Using Cardinal
-~~~~~~~~~~~~~~
-
-These tutorials are intended for any user who wants to monitor three
-basic component in OpenDaylight
-
-1. System Info in which controller is running.
-
-2. Karaf Info
-
-3. Project Specific Information (Openflow and Netconf devices).
-
-Prerequisites
-^^^^^^^^^^^^^
-
-There is no as such specific prerequisite. Cardinal can work without
-installing any third party software. However If one wants to see the
-output of a snmpget/snmpwalk on the CLI prompt, than one can install the
-SNMP using the below link:
-
-https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-an-snmp-daemon-and-client-on-ubuntu-14-04
-
-Using the above command line utility one can get the same result as the
-cardinal APIs will give for the snmpget/snmpwalk request.
-
-Target Environment
-^^^^^^^^^^^^^^^^^^
-
-This tutorial is developed considering the following environment:
-
-controller-Linux(Ubuntu 14.02).
-
-Instructions
-^^^^^^^^^^^^
-
-Install Cardinal feature
-''''''''''''''''''''''''
-
-Open karaf and install the cardinal feature using the following command:
-
-::
-
- feature:install odl-cardinal
-
-Please verify that SNMP daemon is up on port 161 using the following
-command on the terminal window of Linux machine:
-
-::
-
- netstat -anp | grep "161"
- netstat -anp | grep "2001"
- netstat -anp | grep "2003"
-
-If the grep on the \`\`snmpd\`\` port is successful than SNMP daemon is
-up and working.
-
-APIs Reference
-''''''''''''''
-
-Please see Developer guide for usage of Cardinal APIs.
-
-CLI commands to do snmpget/walk
-'''''''''''''''''''''''''''''''
-
-One can do snmpget/walk on the ODL-CARDINAL-MIB. Open the linux terminal
-and type the below command:
-
-::
-
- snmpget -v2c -c public localhost Oid_Of_the_mib_variable
-
-Or
-
-::
-
- snmpget -v2c -c public localhost ODL-CARDINAL-MIB::mib_variable_name
-
-For snmpwalk use the below command:
-
-::
-
- snmpwalk -v2c -c public localhost SNMPv2-SMI::experimental
-
-For tabular data (netconf devices), snmpwalk use the
-below command:
-
-::
-
- snmpwalk -v2c -c public localhost:2001 SNMPv2-SMI::experimental
-
-For tabular data (openflow devices), snmpwalk use the
-below command:
-
-::
-
- snmpwalk -v2c -c public localhost:2003 SNMPv2-SMI::experimental
+++ /dev/null
-Centinel User Guide
-===================
-
-The Centinel project aims at providing a distributed, reliable framework
-for efficiently collecting, aggregating and sinking streaming data
-across Persistence DB and stream analyzers (example: Graylog, Elastic
-search, Spark, Hive etc.). This document contains configuration,
-administration, management, using sections for the feature.
-
-Overview
---------
-
-In this release of Centinel, this framework enables SDN
-applications/services to receive events from multiple streaming sources
-(e.g., Syslog, Thrift, Avro, AMQP, Log4j, HTTP/REST) and execute actions
-like network configuration/batch processing/real-time analytics. It also
-provides a Log Service to assist operators running SDN ecosystem by
-installing the feature odl-centinel-all.
-
-With the configurations development of "Log Service" and plug-in for log
-analyzer (e.g., Graylog) will take place. Log service will do processing
-of real time events coming from log analyzer. Additionally, stream
-collector (Flume and Sqoop based) that will collect logs from
-OpenDaylight and sink it to persistence service (integrated with TSDR).
-Also includes RESTCONF interface to inject events to north bound
-applications for real-time analytic/network configuration. Centinel User
-Interface (web interface) will be available to operators to enable
-rules/alerts/dashboard.
-
-Centinel core features
-----------------------
-
-The core features of the Centinel framework are:
-
-Stream collector
- Collecting, aggregating and sinking streaming data
-
-Log Service
- Listen log stream events coming from log analyzer
-
-Log Service
- Enables user to configure rules (e.g., alerts, diagnostic, health,
- dashboard)
-
-Log Service
- Performs event processing/analytics
-
-User Interface
- Enable set-rule, search, visualize, alert, diagnostic, dashboard
- etc.
-
-Adaptor
- Log analyzer plug-in to Graylog and a generic data-model to extend
- to other stream analyzers (e.g., Logstash)
-
-REST Service
- Northbound APIs for Log Service and Steam collector framework
-
-Leverages
- TSDR persistence service, data query, purging and elastic search
-
-Centinel Architecture
----------------------
-
-The following wiki pages capture the Centinel Model/Architecture
-
-a. https://wiki.opendaylight.org/view/Centinel:Main
-
-b. https://wiki.opendaylight.org/view/Project_Proposals:Centinel
-
-c. https://wiki.opendaylight.org/images/0/09/Centinel-08132015.pdf
-
-Administering or Managing Centinel with default configuration
--------------------------------------------------------------
-
-Prerequisites
-~~~~~~~~~~~~~
-
-1. Check whether Graylog is up and running and plugins deployed as
- mentioned in `installation
- guide <https://opendaylight.readthedocs.io/en/stable-boron/getting-started-guide/project-specific-guides/centinel.html>`__.
-
-2. Check whether HBase is up and respective tables and column families
- as mentioned in `installation
- guide <https://opendaylight.readthedocs.io/en/stable-boron/getting-started-guide/project-specific-guides/centinel.html>`__
- are created.
-
-3. Check if apache flume is up and running.
-
-4. Check if apache drill is up and running.
-
-Running Centinel
-~~~~~~~~~~~~~~~~
-
-The following steps should be followed to bring up the controller:
-
-1. Download the Centinel OpenDaylight distribution release from below
- link: http://www.opendaylight.org/software/downloads
-
-2. Run Karaf of the distribution from bin folder
-
- ::
-
- ./karaf
-
-3. Install the centinel features using below command:
-
- ::
-
- feature:install odl-centinel-all
-
-4. Give some time for the centinel to come up.
-
-User Actions
-~~~~~~~~~~~~
-
-1. **Log In:** User logs into the Centinel with required credentials
- using following URL: http://localhost:8181/index.html
-
-2. **Create Rule:**
-
- a. Select Centinel sub-tree present in left side and go to Rule tab.
-
- b. Create Rule with title and description.
-
- c. Configure flow rule on the stream to filter the logs accordingly
- for, e.g., ``bundle_name=org.opendaylight.openflow-plugin``
-
-3. **Set Alarm Condition:** Configure alarm condition, e.g.,
- message-count-rule such that if 10 messages comes on a stream (e.g.,
- The OpenFlow Plugin) in last 1 minute with an alert is generated.
-
-4. **Subscription:** User can subscribe to the rule and alarm condition
- by entering the http details or email-id in subscription textfield by
- clicking on the subscribe button.
-
-5. **Create Dashboard:** Configure dashboard for stream and alert
- widgets. Alarm and Stream count will be updated in corresponding
- widget in Dashboard.
-
-6. **Event Tab:** Intercepted Logs, Alarms and Raw Logs in Event Tab
- will be displayed by selecting the appropriate radio button. User can
- also filter the searched data using SQL query in the search box.
-
+++ /dev/null
-.. _daexim-user-guide:
-
-Data Export/Import User Guide
-=============================
-
-
-Overview
---------
-
-Data Export/Import is known as "daexim" (pronounced 'deck-sim') for
-short. The intended audience are administrators responsible for
-operations of OpenDaylight.
-
-Data Export/Import provides an API (via RPCs) to request the bulk
-transfer of OpenDaylight system data between its internal data stores
-and the local file system. This can be used for scheduling data exports,
-checking the status of data being exported, canceling data export jobs,
-importing data from files in the file systems, and checking the import
-status.
-
-Such export and import of data can be used during system upgrade,
-enabling the development of administrative procedures that make
-reconfigurations of the base system without concern of internal data
-loss.
-
-Data Export produces a models declaration file and one or more data
-files. The models declaration file records exactly which YANG models
-were loaded (by module name, revision date and namespace). The data
-file(s) contain data store data as per the draft-ietf-netmod-yang-json
-RFC.
-
-Data Import takes a models declaration file and zero or more data
-files. The models declaration file is used to check that the listed
-models are loaded before importing any data. Data is imported into each
-data store in turn with one transaction executed for each data store,
-irrespective of the number of files for that data store, as inter-module
-data dependencies may exist. Existing data store data may be cleared
-before importing.
-
-
-Data Export Import Architecture
--------------------------------
-
-The daexim feature is a single feature. This feature leverages the
-existing infrastructure provided by MD-SAL and yangtools.
-
-
-Installing the Feature
-----------------------
-
-To install the feature perform the following steps.
-
-.. code:: bash
-
- karaf > feature:install odl-daexim-all
-
-
-The interactions with this feature are via Restconf RPCs. The details
-are provided in the `Tutorials`.
-
-
-Tutorials
----------
-
-The following tutorials provide examples of REST API that are supported
-by the Data Export/Import feature. As for all ODL RESTCONF calls, the
-following are the common setting for REST calls:
-
-* **Headers:**
-
- * **Content-Type:** ``application/json``
-
- * **Accept:** ``application/json``
-
- * **Authentication:** ``admin:admin``
-
-* **Method:** ``HTTP POST``
-* <controller-ip>: Host (or IP) where OpenDaylight controller is
- running, e.g. localhost
-* <restconf-port>: TCP port where RESTCONF has been configured to
- listen, e.g. 8181 by default
-
-The files created by export are placed in a subdirectory called
-``daexim/`` in the installation directory of OpenDaylight. Similarly files
-to import must be placed in this ``daexim/`` subdirectory.
-
-
-
-Scheduling Export
-^^^^^^^^^^^^^^^^^
-
-The **schedule-export** RPC exports the data at a specific time in the
-future. The ``run-at`` time may be specified as an absolute UTC time or a
-relative offset from the server clock. Attempts to schedule an export in
-the past times are rejected. Each file has a JSON-encoded object that
-contains module data from the corresponding data store. Module data is
-not included in the object for any module identified in the exclusion
-list. Each file contains at least one empty JSON object. In a clustered
-environment, if *local-node-only* is provided with a value of *true*,
-the export operation is performed only on the node on which the RPC was
-received; otherwise, the export operation is performed on all nodes in
-the cluster.
-
-**URL:** ``http://<controller-ip>:<restconf-port>/restconf/operations/data-export-import:schedule-export``
-
-**Payload:**
-
-.. code:: json
-
- {
- "input": {
- "data-export-import:run-at": 500
- }
- }
-
-
-
-Checking Export Status
-^^^^^^^^^^^^^^^^^^^^^^
-
-The **status-export** RPC checks the status of the exported data. If the
-status has the value of ``initial``, an export has not been scheduled. If
-the status has the value of ``scheduled``, ``run-at`` indicates the time at
-which the next export runs. If the status has the value of
-``in-progress``, ``run-at`` indicates the time at which the running export
-was scheduled to start. A status of ``tasks`` indicates activities that
-are scheduled and currently being performed. The ``tasks`` status serves
-as an indicator of progress and success of the activity. If the status
-has any other value, ``run-at`` indicates the time at which the last
-export was scheduled to start; and ``tasks`` indicates the activities that
-were undertaken. If the status for any node has failed, the
-corresponding reason for failure is listed.
-
-**URL:** ``http://<controller-ip>:<restconf-port>/restconf/operations/data-export-import:status-export``
-
-**Payload:** No payload
-
-
-
-Canceling Scheduled Export
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The **cancel-export** RPC cancels an already scheduled data export
-job. To cancel the export, the server stops the tasks that are running
-(where possible, immediately), clears any scheduled export time value,
-and releases the associated resources. This RPC may be called at any
-time, whether an export is in progress, scheduled or not yet
-scheduled. The returned result is ``True`` when the server has
-successfully cleared tasks, the state, and resources. The status is
-``False`` on failure to do so. Note that if no export is scheduled or
-running, there is no tasks for the server to clear. Therefore, the
-return result is ``True`` because the server cannot fail.
-
-**URL:** ``http://<controller-ip>:<restconf-port>/restconf/operations/data-export-import:cancel-export``
-
-**Payload:** No payload
-
-
-Importing from a file
-^^^^^^^^^^^^^^^^^^^^^
-
-The **immediate-import** RPC imports data from files already present in
-the file system.
-
-**URL:** ``http://<controller-ip>:<restconf-port>/restconf/operations/data-export-import:immediate-import``
-
-**Payload:**
-
-.. code:: json
-
- {
- "input" : {
- "check-models" : true,
- "clear-stores" : "all"
- }
- }
-
-
-
-
-Status of Import
-^^^^^^^^^^^^^^^^
-
-The **status-import** RPC checks the last import status. If the status
-has the value of ``initial``, an import has not taken place. For all other
-values of status, ``imported-at`` indicates the time at which the
-restoration has taken place. List nodes hold status about the
-restoration for each node.
-
-**URL:** ``http://<controller-ip>:<restconf-port>/restconf/operations/data-export-import:status-import``
-
-**Payload:** No payload
-
-
-Importing from a file automatically on boot
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Any files placed inside the ``daexim/boot`` subdirectory are automatically
-imported on start-up. The import performed is the exact same as the one by
-explicit **immediate-import** RPC, which imports from files ``daexim/``, except
-it happens automatically.
-
-The import on boot happens after all other ODL OSGi bundles have successfully
-started. The INFO log and **status import** automatically reflect when the boot
-import is planned (via ``boot-import-scheduled``), when the boot import is
-ongoing (via ``boot-import-in-progress``), and when the boot import fails
-(via ``boot-import-failed``).
-
-Upon completion or failure of this boot import, the files inside the
-``daexim/boot`` directory are renamed to ``.imported`` in order to avoid
-another import on the next start.
+++ /dev/null
-.. _didm-user-guide:
-
-DIDM User Guide
-===============
-
-Overview
---------
-
-The Device Identification and Driver Management (DIDM) project addresses
-the need to provide device-specific functionality. Device-specific
-functionality is code that performs a feature, and the code is
-knowledgeable of the capability and limitations of the device. For
-example, configuring VLANs and adjusting FlowMods are features, and
-there may be different implementations for different device types.
-Device-specific functionality is implemented as Device Drivers. Device
-Drivers need to be associated with the devices they can be used with. To
-determine this association requires the ability to identify the device
-type.
-
-DIDM Architecture
------------------
-
-The DIDM project creates the infrastructure to support the following
-functions:
-
-- **Discovery** - Determination that a device exists in the controller
- management domain and connectivity to the device can be established.
- For devices that support the OpenFlow protocol, the existing
- discovery mechanism in OpenDaylight suffices. Devices that do not
- support OpenFlow will be discovered through manual means such as the
- operator entering device information via GUI or REST API.
-
-- **Identification** – Determination of the device type.
-
-- **Driver Registration** – Registration of Device Drivers as routed
- RPCs.
-
-- **Synchronization** – Collection of device information, device
- configuration, and link (connection) information.
-
-- **Data Models for Common Features** – Data models will be defined to
- perform common features such as VLAN configuration. For example,
- applications can configure a VLAN by writing the VLAN data to the
- data store as specified by the common data model.
-
-- **RPCs for Common Features** – Configuring VLANs and adjusting
- FlowMods are example of features. RPCs will be defined that specify
- the APIs for these features. Drivers implement features for specific
- devices and support the APIs defined by the RPCs. There may be
- different Driver implementations for different device types.
-
-Atrium Support
---------------
-
-The Atrium implements an open source router that speaks BGP to other
-routers, and forwards packets received on one port/vlan to another,
-based on the next-hop learnt via BGP peering. A BGP peering application
-for the Open Daylight Controller and a new model for flow objective
-drivers for switches integrated with the Open Daylight Atrium
-distribution was developed for this project. The implementation has the
-same level of feature partly that was introduced by the Atrium 2015/A
-distribution on the ONOS controller. An overview of the architecture is
-available at here
-(https://github.com/onfsdn/atrium-docs/wiki/ODL-Based-Atrium-Router-16A).
-
-Atrium stack is implemented in OpenDaylight using Atrium and DIDM
-project. Atrium project provides the application implementation for BGP
-peering and the DIDM project provides implementation for FlowObjectives.
-FlowObjective provides an abstraction layer and present the pipeline
-agnostic api to application to consume.
-
-FlowObjective
-~~~~~~~~~~~~~
-
-Flow Objectives describe an SDN application’s objective (or intention)
-behind a flow it is sending to a device.
-
-Application communicates the flow installation requirement using Flow
-Objectives. DIDM drivers translates the Flow Objectives to device
-specific flows as per the device pipeline.
-
-There are three FlowObjectives (already implemented in ONOS controller)
-:
-
-- Filtering Objective
-
-- Next Objective
-
-- Forwarding Objective
-
-Installing DIDM
----------------
-
-To install DIDM, download OpenDaylight and use the Karaf console to
-install the following features:
-
-- odl-openflowplugin-all
-
-- odl-didm-all
-
-odl-didm-all installs the following required features:
-
-- odl-didm-ovs-all
-
-- odl-didm-ovs-impl
-
-- odl-didm-util
-
-- odl-didm-identification
-
-- odl-didm-drivers
-
-- odl-didm-hp-all
-
-Configuring DIDM
-----------------
-
-This section shows an example configuration steps for installing a
-driver (HP 3800 OpenFlow switch driver).
-
-Install DIDM features:
-----------------------
-
-::
-
- feature:install odl-didm-identification-api
- feature:install odl-didm-drivers
-
-In order to identify the device, device driver needs to be installed
-first. Identification Manager will be notified when a new device
-connects to the controller.
-
-Install HP driver
------------------
-
-feature:install odl-didm-hp-all installs the following features
-
-- odl-didm-util
-
-- odl-didm-identification
-
-- odl-didm-drivers
-
-- odl-didm-hp-all
-
-- odl-didm-hp-impl
-
-Now at this point, the driver has written all of the identification
-information in to the MD-SAL datastore. The identification manager
-should have that information so that it can try to identify the HP 3800
-device when it connects to the controller.
-
-Configure the switch and connect it to the controller from the switch
-CLI.
-
-Run REST GET command to verify the device details:
---------------------------------------------------
-
-http://<CONTROLLER-IP:8181>/restconf/operational/opendaylight-inventory:nodes
-
-Run REST adjust-flow command to adjust flows and push to the device
--------------------------------------------------------------------
-
-**Flow mod driver for HP 3800 device**
-
-This driver adjusts the flows and push the same to the device. This API
-takes the flow to be adjusted as input and displays the adjusted flow as
-output in the REST output container. Here is the REST API to adjust and
-push flows to HP 3800 device:
-
-http://<CONTROLLER-IP:8181>/restconf/operations/openflow-feature:adjust-flow
-
-FlowObjectives API
-------------------
-
-FlowObjective presents the OpenFlow pipeline agnostic API to Application
-to consume. Application communicate their intent behind installation of
-flow to Drivers using the FlowObjective. Driver translates the
-FlowObjective in device specific flows and uses the OpenFlowPlugin to
-install the flows to the device.
-
-Filter Objective
-~~~~~~~~~~~~~~~~
-
-http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter
-
-Next Objective
-~~~~~~~~~~~~~~
-
-http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next
-
-Forward Objective
-~~~~~~~~~~~~~~~~~
-
-http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward
+++ /dev/null
-.. _eman-user-guide:
-
-eman User Guide
-===============
-
-Overview
---------
-
-The OpenDaylight Energy Management (eman) plugin implements an abstract
-Information Model that describes energy measurement and control features
-that may be supported by a variety of device types. The eman plugin may
-support a number of southbound interfaces to accommodate a set of
-protocols, including but not limited to SNMP, NETCONF, IPDR. The plugin
-presents a northbound REST API. This framework enables any number of
-applications to interoperate with any number of devices in order to
-measure and optimize energy usage. The Information Model will be
-inherited from the `SCTE 216 standard – Adaptive Power Systems Interface
-Specification (APSIS)
-<http://www.scte.org/SCTEDocs/Standards/ANSI_SCTE%20216%202015.pdf>`_,
-which in turn inherits definitions within the `IETF eman document set
-<https://datatracker.ietf.org/wg/eman/documents/>`_.
-
-This documentation is directed to those operating the features such as
-network administrator, cloud administrator, network engineer, or system
-administrators.
-
-eman is composed of 3 Karaf features:
- * ``eman`` incudes the YANG model and its implementation
- * ``eman-api`` adds support for REST
-
-Developers will typically interface with ``eman-api``.
-
-eman Architecture
------------------
-
-``eman`` defines a YANG model that represents the IETF energy management
-Information Model, and includes RPCs. The implementation of the model
-currently supports an SNMP 'binding' via interfacing with the
-OpenDaylight SNMP module. In the future, other Southbound protocols may
-be supported.
-
-Developers my use the ``eman-api`` feature to read and write energy
-related data and commands to devices that support the IETF eman MIBS.
-
-Besides a set of common controller features eman depends upon the
-OpenDaylight SNMP features to be installed.
-
-Configuring eman
-----------------
-
-eman relies upon the presence of SNMP agents.
-
-The following describes a way to install and configure an SNMP simulator
-on localhost.
-
-on macOS, open terminal
-
-1. Install snmpsim.::
-
- $ sudo easy_install -n snmpsim
-
-2. configure filesystem::
-
- mkdir ~/.snmpsim, then mkdir ~/.snmpsim/data/
-
-3. Install moak data. This file is used by pysnmp to provide mock data
- for an APSIS agent::
-
- copy eman/sample_code/data/energy-object.snmprec to ~/.snmpsim/data/.
-
-4. launch snmp simulator::
-
- $ sudo snmpsimd.py --agent-udpv4-endpoint=127.0.0.1:161
- —process-group=<your group> —process-user=<your user>
-
-5. VerifyOpen another terminal window and execute::
-
- $ snmpget -v2c -c energy-object localhost:161 1.3.6.1.2.1.229.0.1.0.
-
- The result should be ‘1’, as defined in your snmprec file
-
-.. note::
- group and user are settings within our local OS.
- For Mac users, look at settings/users and groups.
- If port 161 is not available, use another unprivileged port such as 1161.
-
-.. note::
- snmpget queries snmpsimd to return a value for the OID 1.3.6.1.2.1.229.0.1.0.
- According to the energy-object.snmprec file, the value for that OID is ‘1’.
- Try other OIDs, or edit the snmprec file to see your results
-
-Future release may include more flexible and robust means to simulate
-a network of energy aware SNMP agents.
-
-Typically, a process may periodically poll a device to acquire power
-measurements and repose them into MD-SAL. Subsequently, process may read a
-history of power measurements from MD-SAL via the eman operational API.
+++ /dev/null
-.. _faas_user_guide:
-
-Fabric As A Service
-===================
-
-This document describes, from a user’s or application’s perspective, how
-to use the Fabric As A Service (FaaS) feature in OpenDaylight. This
-document contains configuration, administration, and management sections
-for the FaaS feature.
-
-Overview
---------
-
-Currently network applications and network administrators mostly rely on
-lower level interfaces such as CLI, SNMP, OVSDB, NETCONF or OpenFlow to
-directly configure individual device for network service provisioning.
-In general, those interfaces are:
-
-- Technology oriented, not application oriented.
-
-- Vendor specific
-
-- Individual device oriented, not network oriented.
-
-- Not declarative, complicated and procedure oriented.
-
-To address the gap between application needs and network interface,
-there are a few application centric language proposed in OpenDaylight
-including Group Based Policy (GBP), Network Intent Composition (NIC),
-and NEtwork MOdeling (NEMO) trying to replace traditional southbound
-interface to application. Those languages are top-down abstractions and
-model application requirements in a more application-oriented way.
-
-After being involved with GBP development for a while, we feel the top
-down model still has a quite gap between the model and the underneath
-network since the existing interfaces to network devices lack of
-abstraction makes it very hard to map high level abstractions to the
-physical network. Often the applications built with these low level
-interfaces are coupled tightly with underneath technology and make the
-application’s architecture monolithic, error prone and hard to maintain.
-
-We think a bottom-up abstraction of network can simplify, reduce the
-gap, and make it easy to implement the application centric model.
-Moreover in some uses cases, an interface with network service oriented
-are still desired for example from network monitoring/troubleshooting
-perspective. That’s where the Fabric as a Service comes in.
-
-FaaS Architecture
------------------
-
-Fabric and its controller (Fabric Controller)
- The Fabric object provides an abstraction of a homogeneous network
- or portion of the network and also has a built in Fabric controller
- which provides management plane and control plane for the fabric.
- The fabric controller implements the services required in Fabric
- Service and monitor and control the fabric operation.
-
-Fabric Manager
- Fabric Manager manages all the fabric objects. also Fabric manager
- acts as a Unified Fabric Controller which provides inter-connect
- fabric control and configuration Also Fabric Manager is FaaS API
- service via Which FaaS user level logical network API (the top level
- API as mentioned previously) exposed and implemented.
-
-FaaS render for GBP (Group Based Policy)
- FaaS render for GBP is an application of FaaS and provides the
- rendering service between GBP model and logical network model
- provided by Fabric Manager.
-
-FaaS RESTCONF API
------------------
-
-FaaS Provides two layers API:
-
-- The top layer is a **user level logical network** API which defines
- CRUD services operating on the following abstracted constructs:
-
- - vcontainer - virtual container
-
- - logical Port - a input/out/access point of a logical device
-
- - logical link - connects ports
-
- - logical switch - a layer 2 forwarding device
-
- - logical router - a layer 3 forwarding device
-
- - Subnet
-
- - Rule/ACL
-
- - End Points Registration
-
- - End Points Attachment
-
-Through these constructs, a logical network can be described without
-users knowing too much details about the physical network device and
-technology, i.e. users' network services is decoupled from underneath
-physical infrastructure. This decoupling brought the benefit that the
-users defined service is not locked in with any specific technology or
-physical devices. FaaS maps the logical network to the physical network
-configuration automatically which in maximum eliminates the manual
-provisioning work. As a result, human error is avoided and OPEX for
-network operators is massively reduced. Moreover migration from one
-technology to another is much easier to do and transparent to users'
-services.
-
-- The second layer defines an abstraction layer called **Fabric** API.
- The idea is to abstract network into a topology formed by a
- collections of fabric objects other than varies of physical
- devices.Each Fabric object provides a collection of unified services.
- The top level API enables application developers or users to write
- applications to map high level model such as GBP, Intent etc… into a
- logical network model, while the lower level gives the application
- more control to individual fabric object level. More importantly the
- Fabric API is more like SPI (Service Provider API) a fabric provider
- or vendor can implement the SPI based on its own Fabric technique
- such as TRILL, SPB etc …
-
-This document is focused on the top layer API. For how to use second
-level API operation, please refer to FaaS developer guide for more
-details.
-
-.. note::
-
- that for any JSON data or link not described here, please go to
- `http://${ipaddress}:8181/apidoc/explorer/index.htm <http://${ipaddress}:8181/apidoc/explorer/index.htm>`__
- for details or clarification.
-
-Resource Management API
------------------------
-
-The FaaS Resource Management API provides services to allocate and
-reclaim the network resources provided by Fabric object. Those APIs can
-be accessed via RESTCONF rendered from YANG in MD-SAL.
-
-- Name: Create virtual container
-
- - virtual container is an collections of resources allocated to a
- tenant, for example, a list of physical ports, bandwidth or L2
- network or logical routers quantity. etc…
-
- - `http://${ipaddress}:8181/restconf/operations/vcontainer-topology:create-vcontainer <http://${ipaddress}:8181/restconf/operations/vcontainer-topology:create-vcontainer>`__
-
- - Description: create a given virtual container.
-
-- Name: assign or remove fabric resource to a virtual container
-
- - `http://${ipaddress}:8181/restconf/operations/vc-ld-node:add-vfabric-to-ld-node <http://${ipaddress}:8181/restconf/operations/vc-ld-node:add-vfabric-to-ld-node>`__
-
- - `http://${ipaddress}:8181/restconf/operations/vc-ld-node:rm-vfabric-to-ld-node <http://${ipaddress}:8181/restconf/operations/vc-ld-node:rm-vfabric-to-ld-node>`__
-
-- Name: assign or remove appliance to a virtual container
-
- - `http://${ipaddress}:8181/restconf/operations/vc-ld-node:add-appliance-to-ld-node <http://${ipaddress}:8181/restconf/operations/vc-ld-node:add-appliance-to-ld-node>`__
-
- - `http://${ipaddress}:8181/restconf/operations/vc-ld-node:rm-appliance-to-ld-node <http://${ipaddress}:8181/restconf/operations/vc-ld-node:rm-appliance-to-ld-node>`__
-
-- Name: create or remove a child container
-
- - `http://${ipaddress}:8181/restconf/operations/vc-ld-node:create-child-ld-node <http://${ipaddress}:8181/restconf/operations/vc-ld-node:create-child-ld-node>`__
-
- - `http://${ipaddress}:8181/restconf/operations/vc-ld-node:rm-child-ld-node <http://${ipaddress}:8181/restconf/operations/vc-ld-node:rm-child-ld-node>`__
-
-- RESTCONF path for Virtual Container Datastore query (note:
- vcontainer-id equals tenantID for now):
-
- - `http://${ipaddress}:8181/restconf/config/network-topology/topology/{vcontainer-id}/vc-topology-attributes/ <http://${ipaddress}:8181/restconf/config/network-topology/topology/{vcontainer-id}/vc-topology-attributes/>`__
-
- - `http://${ipaddress}:8181/restconf/config/network-topology/topology/{vcontainer-id}/node/{net-node-id}/vc-net-node-attributes <http://${ipaddress}:8181/restconf/config/network-topology/topology/{vcontainer-id}/node/{net-node-id}/vc-net-node-attributes>`__
-
- - `http://${ipaddress}:8181/restconf/config/network-topology/topology/{vcontainer-id}/node/{ld-node-id}/vc-ld-node-attributes <http://${ipaddress}:8181/restconf/config/network-topology/topology/{vcontainer-id}/node/{ld-node-id}/vc-ld-node-attributes>`__
-
-Installing Fabric As A Service
-------------------------------
-
-To install FaaS, download OpenDaylight and use the Karaf console to
-install the following feature: **odl-restconf** **odl-faas-all**
-**odl-groupbasedpolicy-faas** (if needs to use FaaS to render GBP)
-
-Configuring FaaS
-----------------
-
-This section gives details about the configuration settings for various
-components in FaaS.
-
-The FaaS configuration files for the Karaf distribution are located in
-distribution/karaf/target/assembly/etc/faas
-
-- akka.conf
-
- - This file contains configuration related to clustering. Potential
- configuration properties can be found on the akka website at
- http://doc.akka.io
-
-- fabric-factory.xml
-
-- vxlan-fabric.xml
-
-- vxlan-fabric-ovs-adapter.xml
-
- - Those 3 files are used to initialize fabric module and located
- under distribution/karaf/target/assembly/etc/opendaylight/karaf
-
-Managing FaaS
--------------
-
-Start opendaylight karaf distribution
-
-- *>bin/karaf* Then From karaf console,Install features in the
- following order:
-
-- *>feature:Install odl-restconf*
-
-- *>feature:install odl-faas-all*
-
-- *>feature install odl-groupbasedpolicy-faas*
-
-After installing features above, users can manage Fabric resource and
-FaaS logical network channels from the APIDOCS explorer via RESTCONF
-
-Go to
-`http://${ipaddress}:8181/apidoc/explorer/index.html <http://${ipaddress}:8181/apidoc/explorer/index.html>`__,
-sign in, and expand the FaaS panel. From there, users can execute
-various API calls to test their FaaS deployment such as create virtual
-container, create fabric, delete fabric, create/edit logical network
-elements.
-
-Tutorials
----------
-
-Below are tutorials for 4 major use cases.
-
-1. to create and provision a fabric
-
-2. to allocate resource from the fabric to a tenant
-
-3. to define a logical network for a tenant. Currently there are two
- ways to create a logical network
-
- a. Create a GBP (Group Based Policy) profile for a tenant and then
- convert it to a logical network via GBP FaaS render Or
-
- b. Manually create a logical network via RESTCONF APIs.
-
-4. to attach or detach an Endpoint to a logical switch or logical router
-
-Create a fabric
-~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-This tutorial walks users through the process of create a Fabric object
-
-Prerequisites
-^^^^^^^^^^^^^
-
-A set of virtual switches (OVS) have to be registered or discovered by
-ODL. Mininet is recommended to create a OVS network. After an OVS
-network is created, set up the controller IP pointing to ODL IP address
-in each of the OVS. From ODL, a physical topology can be viewed via
-RESTCONF API.
-
-Instructions
-^^^^^^^^^^^^
-
-- Run the OpenDaylight distribution and install odl-faas-all from the
- Karaf console.
-
-- Go to
- `http://${ipaddress}:8181/apidoc/explorer/index.html <http://${ipaddress}:8181/apidoc/explorer/index.html>`__
-
-- Get the network topology after OVS switches are registered in the
- controller
-
-- Determine the nodes and links to be included in the to-be-defined
- Fabric object.
-
-- Execute create-fabric RESTCONF API with the corresponding JSON data
- as required.
-
-Create virtual container for a tenant
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The purpose of this tutorial is to allocate network resources to a
-tenant
-
-Overview
-^^^^^^^^
-
-This tutorial walks users through the process of create a Fabric
-
-Prerequisites
-^^^^^^^^^^^^^
-
-1 or more fabric objects have been created.
-
-Instructions
-^^^^^^^^^^^^
-
-- Run the OpenDaylight karaf distribution and install odl-faas-all
- feature from the Karaf console. >feature:install odl-rest-conf
- odl-faas-all odl-mdsal-apidoc
-
-- Go to
- `http://${ipaddress}:8181/apidoc/explorer/index.html <http://${ipaddress}:8181/apidoc/explorer/index.html>`__
-
-- Execute create-vcontainer with the following restconf API with
- corresponding JSON data >
- `http://${ipaddress}:8181/restconf/operations/vcontainer-topology:create-vcontainer <http://${ipaddress}:8181/restconf/operations/vcontainer-topology:create-vcontainer>`__
-
-After a virtual container is created, fabric resource and appliance
-resource can be assigned to the container object via the following
-RESTConf API.
-
-- `http://${ipaddress}:8181/restconf/operations/vc-ld-node:add-vfabric-to-ld-node <http://${ipaddress}:8181/restconf/operations/vc-ld-node:add-vfabric-to-ld-node>`__
-
-- `http://${ipaddress}:8181/restconf/operations/vc-ld-node:add-appliance-to-ld-node <http://${ipaddress}:8181/restconf/operations/vc-ld-node:add-appliance-to-ld-node>`__
-
-Create a logical network
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-This tutorial walks users through the process of create a logical
-network for a tenant
-
-Prerequisites
-^^^^^^^^^^^^^
-
-a virtual container has been created and assigned to the tenant
-
-Instructions
-^^^^^^^^^^^^
-
-Currently there are two ways to create a logical network.
-
-- Option 1 is to use logical network RESTConf REST API and directly
- create individual network elements and connect them into a network
-
-- Option 2 is to define a GBP model and FaaS can map GBP model
- automatically into a logical network. Notes that for option 2, if the
- generated network requires some modification, we recommend modify the
- GBP model rather than change the network directly due to there is no
- synchronization from network back to GBP model in current release.
-
-Manual Provisioning
-^^^^^^^^^^^^^^^^^^^
-
-To create a logical switch
-
-- `http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:logical-switches:logical-switches <http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:logical-switches:logical-switches>`__
- To create a logical router
-
-- `http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:logical-routers:logical-routers <http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:logical-routers:logical-routers>`__
- To attach a logical switch to a router
-
- - Step 1: updating/adding a port A on the logical switch
- `http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:logical-switches:logical-switches <http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:logical-switches:logical-switches>`__
-
- - Step 2: updating/adding a port B on the logical router
- `http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:logical-routers:logical-routers <http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:logical-routers:logical-routers>`__
-
- - Step 3; create a link between the port A and B
- `http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:logical-edges:logical-edges <http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:logical-edges:logical-edges>`__
-
-- To add security policies (ACL or SFC) on a port
- `http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:faas-security-rules <http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:faas-security-rules>`__
-
-- To query the logical network just created
- `http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks <http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks>`__
-
-Provision via GBP FaaS Render
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Run the OpenDaylight distribution and install odl-faas-all and GBP
- faas render feature from the Karaf console.
-
-- Go to
- `http://${ipaddress}:8181/apidoc/explorer/index.html <http://${ipaddress}:8181/apidoc/explorer/index.html>`__
-
-- Execute "create GBP model" via GBP REST API. The GBP model then can
- be automatically mapped into a logical network.
-
-Attach/detach an end point to a logical device
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-This tutorial walks users through the process of registering an End
-Point to a logical device either logical switch or router. The purpose
-of this API is to inform the FaaS where an endpoint physically attach.
-The location information consists of the binding information between
-physical port identifier and logical port information. The logical port
-is indicated by the endpoint either Layer 2 attribute(MAC address) or
-Layer 3 attribute (IP address) and logical network ID (VLAN ID). The
-logical network ID is indirectly indicated the tenant ID since it is
-mutual exclusive resource allocated to a tenant.
-
-Prerequisites
-^^^^^^^^^^^^^
-
-The logical switch to which those end points are attached has to be
-created beforehand. and the identifier of the logical switch is required
-for the following RESTCONF calls.
-
-Instructions
-^^^^^^^^^^^^
-
-- Run the OpenDaylight distribution and install odl-faas-all from the
- Karaf console.
-
-- Go to
- `http://${ipaddress}:8181/apidoc/explorer/index.html <http://${ipaddress}:8181/apidoc/explorer/index.html>`__
-
-- Execute "attach end point " with the following RESTCONF API and
- corresponding JSON data:
- `http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:faas-endpoints-locations <http://${ipaddress}:8181/restconf/configuration/faas-logical-networks:tenant-logical-networks:faas-endpoints-locations>`__
-
+++ /dev/null
-.. _genius-user-guide:
-
-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 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 interface
-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
- }
- ]
- }
-
-.. _genius-user-guide-binding-services:
-
-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 interface depending upon the service priority.
-Service modules can specify openflow-rules to be applied on the packet
-belonging to the interface. 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.
+++ /dev/null
-.. _gbp-user-guide:
-
-Group Based Policy User Guide
-=============================
-
-Overview
---------
-
-OpenDaylight Group Based Policy allows users to express network
-configuration in a declarative versus imperative way.
-
-This is often described as asking for **"what you want"**, rather than
-**"how to do it"**.
-
-In order to achieve this Group Based Policy (herein referred to as
-**GBP**) is an implementation of an **Intent System**.
-
-An **Intent System**:
-
-- is a process around an intent driven data model
-
-- contains no domain specifics
-
-- is capable of addressing multiple semantic definitions of intent
-
-To this end, **GBP** Policy views an **Intent System** visually as:
-
-.. figure:: ./images/groupbasedpolicy/IntentSystemPolicySurfaces.png
- :alt: Intent System Process and Policy Surfaces
-
- Intent System Process and Policy Surfaces
-
-- **expressed intent** is the entry point into the system.
-
-- **operational constraints** provide policy for the usage of the
- system which modulates how the system is consumed. For instance *"All
- Financial applications must use a specific encryption standard"*.
-
-- **capabilities and state** are provided by *renderers*. *Renderers*
- dynamically provide their capabilities to the core model, allowing
- the core model to remain non-domain specific.
-
-- **governance** provides feedback on the delivery of the *expressed
- intent*. i.e. *"Did we do what you asked us?"*
-
-In summary **GBP is about the Automation of Intent**.
-
-By thinking of **Intent Systems** in this way, it enables:
-
-- **automation of intent**
-
- By focusing on **Model. Process. Automation**, a consistent policy
- resolution process enables for mapping between the **expressed
- intent** and renderers responsible for providing the capabilities of
- implementing that intent.
-
-- recursive/intent level-independent behaviour.
-
- Where *one person’s concrete is another’s abstract*, intent can be
- fulfilled through a hierarchical implementation of non-domain
- specific policy resolution. Domain specifics are provided by the
- *renderers*, and exposed via the API, at each policy resolution
- instance. For example:
-
- - To DNS: The name "www.foo.com" is *abstract*, and it’s IPv4
- address 10.0.0.10 is *concrete*,
-
- - To an IP stack: 10.0.0.10 is *abstract* and the MAC
- 08:05:04:03:02:01 is *concrete*,
-
- - To an Ethernet switch: The MAC 08:05:04:03:02:01 is *abstract*,
- the resolution to a port in it’s CAM table is *concrete*,
-
- - To an optical network: The port maybe *abstract*, yet the optical
- wavelength is *concrete*.
-
-.. note::
-
- *This is a very domain specific analogy, tied to something most
- readers will understand. It in no way implies the **GBP** should be
- implemented in an OSI type fashion. The premise is that by
- implementing a full **Intent System**, the user is freed from a lot
- of the constraints of how the expressed intent is realised.*
-
-It is important to show the overall philosophy of **GBP** as it sets the
-project’s direction.
-
-In this release of OpenDaylight, **GBP** focused on **expressed
-intent**, **refactoring of how renderers consume and publish Subject
-Feature Definitions for multi-renderer support**.
-
-GBP Base Architecture and Value Proposition
--------------------------------------------
-
-Terminology
-~~~~~~~~~~~
-
-In order to explain the fundamental value proposition of **GBP**, an
-illustrated example is given. In order to do that some terminology must
-be defined.
-
-The Access Model is the core of the **GBP** Intent System policy
-resolution process.
-
-.. figure:: ./images/groupbasedpolicy/GBPTerminology1.png
- :alt: GBP Access Model Terminology - Endpoints, EndpointGroups, Contract
-
- GBP Access Model Terminology - Endpoints, EndpointGroups, Contract
-
-.. figure:: ./images/groupbasedpolicy/GBPTerminology2.png
- :alt: GBP Access Model Terminology - Subject, Classifier, Action
-
- GBP Access Model Terminology - Subject, Classifier, Action
-
-.. figure:: ./images/groupbasedpolicy/GBPTerminology3.png
- :alt: GBP Forwarding Model Terminology - L3 Context, L2 Bridge Context, L2 Flood Context/Domain, Subnet
-
- GBP Forwarding Model Terminology - L3 Context, L2 Bridge Context, L2
- Flood Context/Domain, Subnet
-
-- Endpoints:
-
- Define concrete uniquely identifiable entities. In this release,
- examples could be a Docker container, or a Neutron port
-
-- EndpointGroups:
-
- EndpointGroups are sets of endpoints that share a common set of
- policies. EndpointGroups can participate in contracts that determine
- the kinds of communication that are allowed. EndpointGroups *consume*
- and *provide* contracts. They also expose both *requirements and
- capabilities*, which are labels that help to determine how contracts
- will be applied. An EndpointGroup can specify a parent EndpointGroup
- from which it inherits.
-
-- Contracts:
-
- Contracts determine which endpoints can communicate and in what way.
- Contracts between pairs of EndpointGroups are selected by the
- contract selectors defined by the EndpointGroup. Contracts expose
- qualities, which are labels that can help EndpointGroups to select
- contracts. Once the contract is selected, contracts have clauses that
- can match against requirements and capabilities exposed by
- EndpointGroups, as well as any conditions that may be set on
- endpoints, in order to activate subjects that can allow specific
- kinds of communication. A contract is allowed to specify a parent
- contract from which it inherits.
-
-- Subject
-
- Subjects describe some aspect of how two endpoints are allowed to
- communicate. Subjects define an ordered list of rules that will match
- against the traffic and perform any necessary actions on that
- traffic. No communication is allowed unless a subject allows that
- communication.
-
-- Clause
-
- Clauses are defined as part of a contract. Clauses determine how a
- contract should be applied to particular endpoints and
- EndpointGroups. Clauses can match against requirements and
- capabilities exposed by EndpointGroups, as well as any conditions
- that may be set on endpoints. Matching clauses define some set of
- subjects which can be applied to the communication between the pairs
- of endpoints.
-
-Architecture and Value Proposition
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**GBP** offers an intent based interface, accessed via the :ref:`UX <gbp-ux>`,
-via the `REST API <#REST>`__ or directly from a domain-specific-language
-such as :ref:`Neutron <gbp-neutron>` through a mapping interface.
-
-There are two models in **GBP**:
-
-- the access (or core) model
-
-- the forwarding model
-
-.. figure:: ./images/groupbasedpolicy/GBP_AccessModel_simple.png
- :alt: GBP Access (or Core) Model
-
- GBP Access (or Core) Model
-
-The *classifier* and *action* portions of the model can be thought of as
-hooks, with their definition provided by each *renderer* about its
-domain specific capabilities. In **GBP** for this release, there is one
-renderer, the :ref:`OpenFlow Overlay renderer (OfOverlay). <gbp-of-overlay>`
-
-These hooks are filled with *definitions* of the types of *features* the
-renderer can provide the *subject*, and are called
-**subject-feature-definitions**.
-
-This means an *expressed intent* can be fulfilled by, and across,
-multiple renderers simultaneously, without any specific provisioning
-from the consumer of **GBP**.
-
-Since **GBP** is implemented in OpenDaylight, which is an SDN
-controller, it also must address networking. This is done via the
-*forwarding model*, which is domain specific to networking, but could be
-applied to many different *types* of networking.
-
-.. figure:: ./images/groupbasedpolicy/GBP_ForwardingModel_simple.png
- :alt: GBP Forwarding Model
-
- GBP Forwarding Model
-
-Each endpoint is provisioned with a *network-containment*. This can be
-a:
-
-- subnet
-
- - normal IP stack behaviour, where ARP is performed in subnet, and
- for out of subnet, traffic is sent to default gateway.
-
- - a subnet can be a child of any of the below forwarding model
- contexts, but typically would be a child of a flood-domain
-
-- L2 flood-domain
-
- - allows flooding behaviour.
-
- - is a n:1 child of a bridge-domain
-
- - can have multiple children
-
-- L2 bridge-domain
-
- - is a layer2 namespace
-
- - is the realm where traffic can be sent at layer 2
-
- - is a n:1 child of a L3 context
-
- - can have multiple children
-
-- L3 context
-
- - is a layer3 namespace
-
- - is the realm where traffic is passed at layer 3
-
- - is a n:1 child of a tenant
-
- - can have multiple children
-
-A simple example of how the access and forwarding models work is as
-follows:
-
-.. figure:: ./images/groupbasedpolicy/GBP_Endpoint_EPG_Contract.png
- :alt: GBP Endpoints, EndpointGroups and Contracts
-
- GBP Endpoints, EndpointGroups and Contracts
-
-In this example, the **EPG:webservers** is *providing* the *web* and
-*ssh* contracts. The **EPG:client** is consuming those contracts.
-**EPG:client** is providing the *any* contract, which is consumed by
-**EPG:webservers**.
-
-The *direction* keyword is always from the perspective of the *provider*
-of the contract. In this case contract *web*, being *provided* by
-**EPG:webservers**, with the classifier to match TCP destination port
-80, means:
-
-- packets with a TCP destination port of 80
-
-- sent to (*in*) endpoints in the **EPG:webservers**
-
-- will be *allowed*.
-
-.. figure:: ./images/groupbasedpolicy/GBP_Endpoint_EPG_Forwarding.png
- :alt: GBP Endpoints and the Forwarding Model
-
- GBP Endpoints and the Forwarding Model
-
-When the forwarding model is considered in the figure above, it can be
-seen that even though all endpoints are communicating using a common set
-of contracts, their forwarding is *contained* by the forwarding model
-contexts or namespaces. In the example shown, the endpoints associated
-with a *network-containment* that has an ultimate parent of
-*L3Context:Sales* can only communicate with other endpoints within this
-L3Context. In this way L3VPN services can be implemented without any
-impact to the **Intent** of the contract.
-
-High-level implementation Architecture
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The overall architecture, including :ref:`Neutron <gbp-neutron>` domain
-specific mapping, and the :ref:`OpenFlow Overlay renderer <gbp-of-overlay>`
-looks as so:
-
-.. figure:: ./images/groupbasedpolicy/GBP_High-levelBerylliumArchitecture.png
- :alt: GBP High Level Architecture
-
- GBP High Level Architecture
-
-The major benefit of this architecture is that the mapping of the
-domain-specific-language is completely separate and independent of the
-underlying renderer implementation.
-
-For instance, using the :ref:`Neutron Mapper <gbp-neutron>`, which maps the
-Neutron API to the **GBP** core model, any contract automatically
-generated from this mapping can be augmented via the :ref:`UX <gbp-ux>` to use
-:ref:`Service Function Chaining <gbp-sfc>`, a capability not currently
-available in OpenStack Neutron.
-
-When another renderer is added, for instance, NetConf, the same policy
-can now be leveraged across NetConf devices simultaneously:
-
-.. figure:: ./images/groupbasedpolicy/GBP_High-levelExtraRenderer.png
- :alt: GBP High Level Architecture - adding a renderer
-
- GBP High Level Architecture - adding a renderer
-
-As other domain-specific mappings occur, they too can leverage the same
-renderers, as the renderers only need to implement the **GBP** access
-and forwarding models, and the domain-specific mapping need only manage
-mapping to the access and forwarding models. For instance:
-
-.. figure:: ./images/groupbasedpolicy/High-levelBerylliumArchitectureEvolution2.png
- :alt: GBP High Level Architecture - adding a renderer
-
- GBP High Level Architecture - adding a renderer
-
-In summary, the **GBP** architecture:
-
-- separates concerns: the Expressed Intent is kept completely separated
- from the underlying renderers.
-
-- is cohesive: each part does it’s part and it’s part only
-
-- is scalable: code can be optimised around model
- mapping/implementation, and functionality re-used
-
-Policy Resolution
-~~~~~~~~~~~~~~~~~
-
-Contract Selection
-^^^^^^^^^^^^^^^^^^
-
-The first step in policy resolution is to select the contracts that are
-in scope.
-
-EndpointGroups participate in contracts either as a *provider* or as a
-*consumer* of a contract. Each EndpointGroup can participate in many
-contracts at the same time, but for each contract it can be in only one
-role at a time. In addition, there are two ways for an EndpointGroup to
-select a contract: either with either a:
-
-- *named selector*
-
- Named selectors simply select a specific contract by its contract ID.
-
-- target selector.
-
- Target selectors allow for additional flexibility by matching against
- *qualities* of the contract’s *target.*
-
-Thus, there are a total of 4 kinds of contract selector:
-
-- provider named selector
-
- Select a contract by contract ID, and participate as a provider.
-
-- provider target selector
-
- Match against a contract’s target with a quality matcher, and
- participate as a provider.
-
-- consumer named selector
-
- Select a contract by contract ID, and participate as a consumer.
-
-- consumer target selector
-
- Match against a contract’s target with a quality matcher, and
- participate as a consumer.
-
-To determine which contracts are in scope, contracts are found where
-either the source EndpointGroup selects a contract as either a provider
-or consumer, while the destination EndpointGroup matches against the
-same contract in the corresponding role. So if endpoint *x* in
-EndpointGroup *X* is communicating with endpoint *y* in EndpointGroup
-*Y*, a contract *C* is in scope if either *X* selects *C* as a provider
-and *Y* selects *C* as a consumer, or vice versa.
-
-The details of how quality matchers work are described further in
-`Matchers <#Matchers>`__. Quality matchers provide a flexible mechanism
-for contract selection based on labels.
-
-The end result of the contract selection phase can be thought of as a
-set of tuples representing selected contract scopes. The fields of the
-tuple are:
-
-- Contract ID
-
-- The provider EndpointGroup ID
-
-- The name of the selector in the provider EndpointGroup that was used
- to select the contract, called the *matching provider selector.*
-
-- The consumer EndpointGroup ID
-
-- The name of the selector in the consumer EndpointGroup that was used
- to select the contract, called the *matching consumer selector.*
-
-The result is then stored in the datastore under **Resolved Policy**.
-
-Subject Selection
-^^^^^^^^^^^^^^^^^
-
-The second phase in policy resolution is to determine which subjects are
-in scope. The subjects define what kinds of communication are allowed
-between endpoints in the EndpointGroups. For each of the selected
-contract scopes from the contract selection phase, the subject selection
-procedure is applied.
-
-Labels called, capabilities, requirements and conditions are matched
-against to bring a Subject *into scope*. EndpointGroups have
-capabilities and requirements, while endpoints have conditions.
-
-Requirements and Capabilities
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-When acting as a *provider*, EndpointGroups expose *capabilities,* which
-are labels representing specific pieces of functionality that can be
-exposed to other EndpointGroups that may meet functional requirements of
-those EndpointGroups.
-
-When acting as a *consumer*, EndpointGroups expose *requirements*, which
-are labels that represent that the EndpointGroup requires some specific
-piece of functionality.
-
-As an example, we might create a capability called "user-database" which
-indicates that an EndpointGroup contains endpoints that implement a
-database of users.
-
-We might create a requirement also called "user-database" to indicate an
-EndpointGroup contains endpoints that will need to communicate with the
-endpoints that expose this service.
-
-Note that in this example the requirement and capability have the same
-name, but the user need not follow this convention.
-
-The matching provider selector (that was used by the provider
-EndpointGroup to select the contract) is examined to determine the
-capabilities exposed by the provider EndpointGroup for this contract
-scope.
-
-The provider selector will have a list of capabilities either directly
-included in the provider selector or inherited from a parent selector or
-parent EndpointGroup. (See `Inheritance <#Inheritance>`__).
-
-Similarly, the matching consumer selector will expose a set of
-requirements.
-
-Conditions
-^^^^^^^^^^
-
-Endpoints can have *conditions*, which are labels representing some
-relevant piece of operational state related to the endpoint.
-
-An example of a condition might be "malware-detected," or
-"authentication-succeeded." Conditions are used to affect how that
-particular endpoint can communicate.
-
-To continue with our example, the "malware-detected" condition might
-cause an endpoint’s connectivity to be cut off, while
-"authentication-succeeded" might open up communication with services
-that require an endpoint to be first authenticated and then forward its
-authentication credentials.
-
-Clauses
-^^^^^^^
-
-Clauses perform the actual selection of subjects. A clause has lists of
-matchers in two categories. In order for a clause to become active, all
-lists of matchers must match. A matching clause will select all the
-subjects referenced by the clause. Note that an empty list of matchers
-counts as a match.
-
-The first category is the consumer matchers, which match against the
-consumer EndpointGroup and endpoints. The consumer matchers are:
-
-- Group Idenfication Constraint: Requirement matchers
-
- Matches against requirements in the matching consumer selector.
-
-- Group Identification Constraint: GroupName
-
- Matches against the group name
-
-- Consumer condition matchers
-
- Matches against conditions on endpoints in the consumer EndpointGroup
-
-- Consumer Endpoint Identification Constraint
-
- Label based criteria for matching against endpoints. In this release
- this can be used to label endpoints based on IpPrefix.
-
-The second category is the provider matchers, which match against the
-provider EndpointGroup and endpoints. The provider matchers are:
-
-- Group Idenfication Constraint: Capability matchers
-
- Matches against capabilities in the matching provider selector.
-
-- Group Identification Constraint: GroupName
-
- Matches against the group name
-
-- Consumer condition matchers
-
- Matches against conditions on endpoints in the provider EndpointGroup
-
-- Consumer Endpoint Identification Constraint
-
- Label based criteria for matching against endpoints. In this release
- this can be used to label endpoints based on IpPrefix.
-
-Clauses have a list of subjects that apply when all the matchers in the
-clause match. The output of the subject selection phase logically is a
-set of subjects that are in scope for any particular pair of endpoints.
-
-Rule Application
-^^^^^^^^^^^^^^^^
-
-Now subjects have been selected that apply to the traffic between a
-particular set of endpoints, policy can be applied to allow endpoints to
-communicate. The applicable subjects from the previous step will each
-contain a set of rules.
-
-Rules consist of a set of *classifiers* and a set of *actions*.
-Classifiers match against traffic between two endpoints. An example of a
-classifier would be something that matches against all TCP traffic on
-port 80, or one that matches against HTTP traffic containing a
-particular cookie. Actions are specific actions that need to be taken on
-the traffic before it reaches its destination. Actions could include
-tagging or encapsulating the traffic in some way, redirecting the
-traffic, or applying a :ref:`service function chain <gbp-sfc>`.
-
-Rules, subjects, and actions have an *order* parameter, where a lower
-order value means that a particular item will be applied first. All
-rules from a particular subject will be applied before the rules of any
-other subject, and all actions from a particular rule will be applied
-before the actions from another rule. If more than item has the same
-order parameter, ties are broken with a lexicographic ordering of their
-names, with earlier names having logically lower order.
-
-Matchers
-''''''''
-
-Matchers specify a set of labels (which include requirements,
-capabilities, conditions, and qualities) to match against. There are
-several kinds of matchers that operate similarly:
-
-- Quality matchers
-
- used in target selectors during the contract selection phase. Quality
- matchers provide a more advanced and flexible way to select contracts
- compared to a named selector.
-
-- Requirement and capability matchers
-
- used in clauses during the subject selection phase to match against
- requirements and capabilities on EndpointGroups
-
-- Condition matchers
-
- used in clauses during the subject selection phase to match against
- conditions on endpoints
-
-A matcher is, at its heart, fairly simple. It will contain a list of
-label names, along with a *match type*. The match type can be either:
-
-- "all"
-
- which means the matcher matches when all of its labels match
-
-- "any"
-
- which means the matcher matches when any of its labels match,
-
-- "none"
-
- which means the matcher matches when none of its labels match.
-
-Note a *match all* matcher can be made by matching against an empty set
-of labels with a match type of "all."
-
-Additionally each label to match can optionally include a relevant name
-field. For quality matchers, this is a target name. For capability and
-requirement matchers, this is a selector name. If the name field is
-specified, then the matcher will only match against targets or selectors
-with that name, rather than any targets or selectors.
-
-Inheritance
-^^^^^^^^^^^
-
-Some objects in the system include references to parents, from which
-they will inherit definitions. The graph of parent references must be
-loop free. When resolving names, the resolution system must detect loops
-and raise an exception. Objects that are part of these loops may be
-considered as though they are not defined at all. Generally, inheritance
-works by simply importing the objects in the parent into the child
-object. When there are objects with the same name in the child object,
-then the child object will override the parent object according to rules
-which are specific to the type of object. We’ll next explore the
-detailed rules for inheritance for each type of object
-
-**EndpointGroups**
-
-EndpointGroups will inherit all their selectors from their parent
-EndpointGroups. Selectors with the same names as selectors in the parent
-EndpointGroups will inherit their behavior as defined below.
-
-**Selectors**
-
-Selectors include provider named selectors, provider target selectors,
-consumer named selectors, and consumer target selectors. Selectors
-cannot themselves have parent selectors, but when selectors have the
-same name as a selector of the same type in the parent EndpointGroup,
-then they will inherit from and override the behavior of the selector in
-the parent EndpointGroup.
-
-**Named Selectors**
-
-Named selectors will add to the set of contract IDs that are selected by
-the parent named selector.
-
-**Target Selectors**
-
-A target selector in the child EndpointGroup with the same name as a
-target selector in the parent EndpointGroup will inherit quality
-matchers from the parent. If a quality matcher in the child has the same
-name as a quality matcher in the parent, then it will inherit as
-described below under Matchers.
-
-**Contracts**
-
-Contracts will inherit all their targets, clauses and subjects from
-their parent contracts. When any of these objects have the same name as
-in the parent contract, then the behavior will be as defined below.
-
-**Targets**
-
-Targets cannot themselves have a parent target, but it may inherit from
-targets with the same name as the target in a parent contract. Qualities
-in the target will be inherited from the parent. If a quality with the
-same name is defined in the child, then this does not have any semantic
-effect except if the quality has its inclusion-rule parameter set to
-"exclude." In this case, then the label should be ignored for the
-purpose of matching against this target.
-
-**Subjects**
-
-Subjects cannot themselves have a parent subject, but it may inherit
-from a subject with the same name as the subject in a parent contract.
-The order parameter in the child subject, if present, will override the
-order parameter in the parent subject. The rules in the parent subject
-will be added to the rules in the child subject. However, the rules will
-not override rules of the same name. Instead, all rules in the parent
-subject will be considered to run with a higher order than all rules in
-the child; that is all rules in the child will run before any rules in
-the parent. This has the effect of overriding any rules in the parent
-without the potentially-problematic semantics of merging the ordering.
-
-**Clauses**
-
-Clauses cannot themselves have a parent clause, but it may inherit from
-a clause with the same name as the clause in a parent contract. The list
-of subject references in the parent clause will be added to the list of
-subject references in the child clause. This is just a union operation.
-A subject reference that refers to a subject name in the parent contract
-might have that name overridden in the child contract. Each of the
-matchers in the clause are also inherited by the child clause. Matchers
-in the child of the same name and type as a matcher from the parent will
-inherit from and override the parent matcher. See below under Matchers
-for more information.
-
-**Matchers**
-
-Matchers include quality matchers, condition matchers, requirement
-matchers, and capability matchers. Matchers cannot themselves have
-parent matchers, but when there is a matcher of the same name and type
-in the parent object, then the matcher in the child object will inherit
-and override the behavior of the matcher in the parent object. The match
-type, if specified in the child, overrides the value specified in the
-parent. Labels are also inherited from the parent object. If there is a
-label with the same name in the child object, this does not have any
-semantic effect except if the label has its inclusion-rule parameter set
-to "exclude." In this case, then the label should be ignored for the
-purpose of matching. Otherwise, the label with the same name will
-completely override the label from the parent.
-
-.. _gbp-ux:
-
-Using the GBP UX interface
---------------------------
-
-Overview
-~~~~~~~~
-
-These following components make up this application and are described in
-more detail in following sections:
-
-- Basic view
-
-- Governance view
-
-- Policy Expression view
-
-- Wizard view
-
-The **GBP** UX is access via:
-
-::
-
- http://<odl controller>:8181/index.html
-
-Basic view
-~~~~~~~~~~
-
-Basic view contains 5 navigation buttons which switch user to the
-desired section of application:
-
-- Governance – switch to the Governance view (middle of graphic has the
- same function)
-
-- Renderer configuration – switch to the Policy expression view with
- Renderers section expanded
-
-- Policy expression – switch to the Policy expression view with Policy
- section expanded
-
-- Operational constraints – placeholder for development in next release
-
-.. figure:: ./images/groupbasedpolicy/ui-1-basicview.png
- :alt: Basic view
-
- Basic view
-
-Governance view
-~~~~~~~~~~~~~~~
-
-Governance view consists from three columns.
-
-.. figure:: ./images/groupbasedpolicy/ui-2-governanceview.png
- :alt: Governance view
-
- Governance view
-
-**Governance view – Basic view – Left column**
-
-In the left column is Health section with Exception and Conflict buttons
-with no functionality yet. This is a placeholder for development in
-further releases.
-
-**Governance view – Basic view – Middle column**
-
-In the top half of this section is select box with list of tenants for
-select. Once the tenant is selected, all sub sections in application
-operate and display data with actual selected tenant.
-
-Below the select box are buttons which display Expressed or Delivered
-policy of Governance section. In the bottom half of this section is
-select box with list of renderers for select. There is currently only
-:ref:`OfOverlay <gbp-of-overlay>` renderer available.
-
-Below the select box is Renderer configuration button, which switch the
-app into the Policy expression view with Renderers section expanded for
-performing CRUD operations. Renderer state button display Renderer state
-view.
-
-**Governance view – Basic view – Right column**
-
-In the bottom part of the right section of Governance view is Home
-button which switch the app to the Basic view.
-
-In the top part is situated navigation menu with four main sections.
-
-Policy expression button expand/collapse sub menu with three main parts
-of Policy expression. By clicking on sub menu buttons, user will be
-switched into the Policy expressions view with appropriate section
-expanded for performing CRUD operations.
-
-Renderer configuration button switches user into the Policy expressions
-view.
-
-Governance button expand/collapse sub menu with four main parts of
-Governance section. Sub menu buttons of Governance section display
-appropriate section of Governance view.
-
-Operational constraints have no functionality yet, and is a placeholder
-for development in further releases.
-
-Below the menu is place for view info section which displays info about
-actual selected element from the topology (explained below).
-
-**Governance view – Expressed policy**
-
-In this view are displayed contracts with their consumed and provided
-EndpointGroups of actual selected tenant, which can be changed in select
-box in the upper left corner.
-
-By single-clicking on any contract or EPG, the data of actual selected
-element will be shown in the right column below the menu. A Manage
-button launches a display wizard window for managing configuration of
-items such as :ref:`Service Function Chaining <gbp-sfc>`.
-
-.. figure:: ./images/groupbasedpolicy/ui-3-governanceview-expressed.png
- :alt: Expressed policy
-
- Expressed policy
-
-**Governance view – Delivered policy** In this view are displayed
-subjects with their consumed and provided EndpointGroups of actual
-selected tenant, which can be changed in select box in the upper left
-corner.
-
-By single-clicking on any subject or EPG, the data of actual selected
-element will be shown in the right column below the menu.
-
-By double-click on subject the subject detail view will be displayed
-with subject’s rules of actual selected subject, which can be changed in
-select box in the upper left corner.
-
-By single-clicking on rule or subject, the data of actual selected
-element will be shown in the right column below the menu.
-
-By double-clicking on EPG in Delivered policy view, the EPG detail view
-will be displayed with EPG’s endpoints of actual selected EPG, which can
-be changed in select box in the upper left corner.
-
-By single-clicking on EPG or endpoint the data of actual selected
-element will be shown in the right column below the menu.
-
-.. figure:: ./images/groupbasedpolicy/ui-4-governanceview-delivered-0.png
- :alt: Delivered policy
-
- Delivered policy
-
-.. figure:: ./images/groupbasedpolicy/ui-4-governanceview-delivered-1-subject.png
- :alt: Subject detail
-
- Subject detail
-
-.. figure:: ./images/groupbasedpolicy/ui-4-governanceview-delivered-2-epg.png
- :alt: EPG detail
-
- EPG detail
-
-**Governance view – Renderer state**
-
-In this part are displayed Subject feature definition data with two main
-parts: Action definition and Classifier definition.
-
-By clicking on the down/right arrow in the circle is possible to
-expand/hide data of appropriate container or list. Next to the list node
-are displayed names of list’s elements where one is always selected and
-element’s data are shown (blue line under the name).
-
-By clicking on names of children nodes is possible to select desired
-node and node’s data will be displayed.
-
-.. figure:: ./images/groupbasedpolicy/ui-4-governanceview-renderer.png
- :alt: Renderer state
-
- Renderer state
-
-Policy expression view
-~~~~~~~~~~~~~~~~~~~~~~
-
-In the left part of this view is placed topology of actual selected
-elements with the buttons for switching between types of topology at the
-bottom.
-
-Right column of this view contains four parts. At the top of this column
-are displayed breadcrumbs with actual position in the application.
-
-Below the breadcrumbs is select box with list of tenants for select. In
-the middle part is situated navigation menu, which allows switch to the
-desired section for performing CRUD operations.
-
-At the bottom is quick navigation menu with Access Model Wizard button
-which display Wizard view, Home button which switch application to the
-Basic view and occasionally Back button, which switch application to the
-upper section.
-
-**Policy expression - Navigation menu**
-
-To open Policy expression, select Policy expression from the GBP Home
-screen.
-
-In the top of navigation box you can select the tenant from the tenants
-list to activate features addicted to selected tenant.
-
-In the right menu, by default, the Policy menu section is expanded.
-Subitems of this section are modules for CRUD (creating, reading,
-updating and deleting) of tenants, EndpointGroups, contracts, L2/L3
-objects.
-
-- Section Renderers contains CRUD forms for Classifiers and Actions.
-
-- Section Endpoints contains CRUD forms for Endpoint and L3 prefix
- endpoint.
-
-.. figure:: ./images/groupbasedpolicy/ui-5-expresssion-1.png
- :alt: Navigation menu
-
- Navigation menu
-
-.. figure:: ./images/groupbasedpolicy/ui-5-expresssion-2.png
- :alt: CRUD operations
-
- CRUD operations
-
-**Policy expression - Types of topology**
-
-There are three different types of topology:
-
-- Configured topology - EndpointGroups and contracts between them from
- CONFIG datastore
-
-- Operational topology - displays same information but is based on
- operational data.
-
-- L2/L3 - displays relationships between L3Contexts, L2 Bridge domains,
- L2 Flood domains and Subnets.
-
-.. figure:: ./images/groupbasedpolicy/ui-5-expresssion-3.png
- :alt: L2/L3 Topology
-
- L2/L3 Topology
-
-.. figure:: ./images/groupbasedpolicy/ui-5-expresssion-4.png
- :alt: Config Topology
-
- Config Topology
-
-**Policy expression - CRUD operations**
-
-In this part are described basic flows for viewing, adding, editing and
-deleting system elements like tenants, EndpointGroups etc.
-
-Tenants
-~~~~~~~
-
-To edit tenant objects click the Tenants button in the right menu. You
-can see the CRUD form containing tenants list and control buttons.
-
-To add new tenant, click the Add button This will display the form for
-adding a new tenant. After filling tenant attributes Name and
-Description click Save button. Saving of any object can be performed
-only if all the object attributes are filled correctly. If some
-attribute doesn’t have correct value, exclamation mark with mouse-over
-tooltip will be displayed next to the label for the attribute. After
-saving of tenant the form will be closed and the tenants list will be
-set to default value.
-
-To view an existing tenant, select the tenant from the select box
-Tenants list. The view form is read-only and can be closed by clicking
-cross mark in the top right of the form.
-
-To edit selected tenant, click the Edit button, which will display the
-edit form for selected tenant. After editing the Name and Description of
-selected tenant click the Save button to save selected tenant. After
-saving of tenant the edit form will be closed and the tenants list will
-be set to default value.
-
-To delete tenant select the tenant from the Tenants list and click
-Delete button.
-
-To return to the Policy expression click Back button on the bottom of
-window.
-
-**EndpointGroups**
-
-For managing EndpointGroups (EPG) the tenant from the top Tenants list
-must be selected.
-
-To add new EPG click Add button and after filling required attributes
-click Save button. After adding the EPG you can edit it and assign
-Consumer named selector or Provider named selector to it.
-
-To edit EPG click the Edit button after selecting the EPG from Group
-list.
-
-To add new Consumer named selector (CNS) click the Add button next to
-the Consumer named selectors list. While CNS editing you can set one or
-more contracts for current CNS pressing the Plus button and selecting
-the contract from the Contracts list. To remove the contract, click on
-the cross mark next to the contract. Added CNS can be viewed, edited or
-deleted by selecting from the Consumer named selectors list and clicking
-the Edit and Delete buttons like with the EPG or tenants.
-
-To add new Provider named selector (PNS) click the Add button next to
-the Provider named selectors list. While PNS editing you can set one or
-more contracts for current PNS pressing the Plus button and selecting
-the contract from the Contracts list. To remove the contract, click on
-the cross mark next to the contract. Added PNS can be viewed, edited or
-deleted by selecting from the Provider named selectors list and clicking
-the Edit and Delete buttons like with the EPG or tenants.
-
-To delete EPG, CNS or PNS select it in selectbox and click the Delete
-button next to the selectbox.
-
-**Contracts**
-
-For managing contracts the tenant from the top Tenants list must be
-selected.
-
-To add new Contract click Add button and after filling required fields
-click Save button.
-
-After adding the Contract user can edit it by selecting in the Contracts
-list and clicking Edit button.
-
-To add new Clause click Add button next to the Clause list while editing
-the contract. While editing the Clause after selecting clause from the
-Clause list user can assign clause subjects by clicking the Plus button
-next to the Clause subjects label. Adding and editing action must be
-submitted by pressing Save button. To manage Subjects you can use CRUD
-form like with the Clause list.
-
-**L2/L3**
-
-For managing L2/L3 the tenant from the top Tenants list must be
-selected.
-
-To add L3 Context click the Add button next to the L3 Context list
-,which will display the form for adding a new L3 Context. After filling
-L3 Context attributes click Save button. After saving of L3 Context,
-form will be closed and the L3 Context list will be set to default
-value.
-
-To view an existing L3 Context, select the L3 Context from the select
-box L3 Context list. The view form is read-only and can be closed by
-clicking cross mark in the top right of the form.
-
-If user wants to edit selected L3 Context, click the Edit button, which
-will display the edit form for selected L3 Context. After editing click
-the Save button to save selected L3 Context. After saving of L3 Context,
-the edit form will be closed and the L3 Context list will be set to
-default value.
-
-To delete L3 Context, select it from the L3 Context list and click
-Delete button.
-
-To add L2 Bridge Domain, click the Add button next to the L2 Bridge
-Domain list. This will display the form for adding a new L2 Bridge
-Domain. After filling L2 Bridge Domain attributes click Save button.
-After saving of L2 Bridge Domain, form will be closed and the L2 Bridge
-Domain list will be set to default value.
-
-To view an existing L2 Bridge Domain, select the L2 Bridge Domain from
-the select box L2 Bridge Domain list. The view form is read-only and can
-be closed by clicking cross mark in the top right of the form.
-
-If user wants to edit selected L2 Bridge Domain, click the Edit button,
-which will display the edit form for selected L2 Bridge Domain. After
-editing click the Save button to save selected L2 Bridge Domain. After
-saving of L2 Bridge Domain the edit form will be closed and the L2
-Bridge Domain list will be set to default value.
-
-To delete L2 Bridge Domain select it from the L2 Bridge Domain list and
-click Delete button.
-
-To add L3 Flood Domain, click the Add button next to the L3 Flood Domain
-list. This will display the form for adding a new L3 Flood Domain. After
-filling L3 Flood Domain attributes click Save button. After saving of L3
-Flood Domain, form will be closed and the L3 Flood Domain list will be
-set to default value.
-
-To view an existing L3 Flood Domain, select the L3 Flood Domain from the
-select box L3 Flood Domain list. The view form is read-only and can be
-closed by clicking cross mark in the top right of the form.
-
-If user wants to edit selected L3 Flood Domain, click the Edit button,
-which will display the edit form for selected L3 Flood Domain. After
-editing click the Save button to save selected L3 Flood Domain. After
-saving of L3 Flood Domain the edit form will be closed and the L3 Flood
-Domain list will be set to default value.
-
-To delete L3 Flood Domain select it from the L3 Flood Domain list and
-click Delete button.
-
-To add Subnet click the Add button next to the Subnet list. This will
-display the form for adding a new Subnet. After filling Subnet
-attributes click Save button. After saving of Subnet, form will be
-closed and the Subnet list will be set to default value.
-
-To view an existing Subnet, select the Subnet from the select box Subnet
-list. The view form is read-only and can be closed by clicking cross
-mark in the top right of the form.
-
-If user wants to edit selected Subnet, click the Edit button, which will
-display the edit form for selected Subnet. After editing click the Save
-button to save selected Subnet. After saving of Subnet the edit form
-will be closed and the Subnet list will be set to default value.
-
-To delete Subnet select it from the Subnet list and click Delete button.
-
-**Classifiers**
-
-To add Classifier, click the Add button next to the Classifier list.
-This will display the form for adding a new Classifier. After filling
-Classifier attributes click Save button. After saving of Classifier,
-form will be closed and the Classifier list will be set to default
-value.
-
-To view an existing Classifier, select the Classifier from the select
-box Classifier list. The view form is read-only and can be closed by
-clicking cross mark in the top right of the form.
-
-If you want to edit selected Classifier, click the Edit button, which
-will display the edit form for selected Classifier. After editing click
-the Save button to save selected Classifier. After saving of Classifier
-the edit form will be closed and the Classifier list will be set to
-default value.
-
-To delete Classifier select it from the Classifier list and click Delete
-button.
-
-**Actions**
-
-To add Action, click the Add button next to the Action list. This will
-display the form for adding a new Action. After filling Action
-attributes click Save button. After saving of Action, form will be
-closed and the Action list will be set to default value.
-
-To view an existing Action, select the Action from the select box Action
-list. The view form is read-only and can be closed by clicking cross
-mark in the top right of the form.
-
-If user wants to edit selected Action, click the Edit button, which will
-display the edit form for selected Action. After editing click the Save
-button to save selected Action. After saving of Action the edit form
-will be closed and the Action list will be set to default value.
-
-To delete Action select it from the Action list and click Delete button.
-
-**Endpoint**
-
-To add Endpoint, click the Add button next to the Endpoint list. This
-will display the form for adding a new Endpoint. To add EndpointGroup
-assignment click the Plus button next to the label EndpointGroups. To
-add Condition click Plus button next to the label Condition. To add L3
-Address click the Plus button next to the L3 Addresses label. After
-filling Endpoint attributes click Save button. After saving of Endpoint,
-form will be closed and the Endpoint list will be set to default value.
-
-To view an existing Endpoint just, the Endpoint from the select box
-Endpoint list. The view form is read-only and can be closed by clicking
-cross mark in the top right of the form.
-
-If you want to edit selected Endpoint, click the Edit button, which will
-display the edit form for selected Endpoint. After editing click the
-Save button to save selected Endpoint. After saving of Endpoint the edit
-form will be closed and the Endpoint list will be set to default value.
-
-To delete Endpoint select it from the Endpoint list and click Delete
-button.
-
-**L3 prefix endpoint**
-
-To add L3 prefix endpoint, click the Add button next to the L3 prefix
-endpoint list. This will display the form for adding a new Endpoint. To
-add EndpointGroup assignment, click the Plus button next to the label
-EndpointGroups. To add Condition, click Plus button next to the label
-Condition. To add L2 gateway click the Plus button next to the L2
-gateways label. To add L3 gateway, click the Plus button next to the L3
-gateways label. After filling L3 prefix endpoint attributes click Save
-button. After saving of L3 prefix endpoint, form will be closed and the
-Endpoint list will be set to default value.
-
-To view an existing L3 prefix endpoint, select the Endpoint from the
-select box L3 prefix endpoint list. The view form is read-only and can
-be closed by clicking cross mark in the top right of the form.
-
-If you want to edit selected L3 prefix endpoint, click the Edit button,
-which will display the edit form for selected L3 prefix endpoint. After
-editing click the Save button to save selected L3 prefix endpoint. After
-saving of Endpoint the edit form will be closed and the Endpoint list
-will be set to default value.
-
-To delete Endpoint select it from the L3 prefix endpoint list and click
-Delete button.
-
-Wizard
-~~~~~~
-
-Wizard provides quick method to send basic data to controller necessary
-for basic usage of GBP application. It is useful in the case that there
-aren’t any data in controller. In the first tab is form for create
-tenant. The second tab is for CRUD operations with contracts and their
-sub elements such as subjects, rules, clauses, action refs and
-classifier refs. The last tab is for CRUD operations with EndpointGroups
-and their CNS and PNS. Created structure of data is possible to send by
-clicking on Submit button.
-
-.. figure:: ./images/groupbasedpolicy/ui-6-wizard.png
- :alt: Wizard
-
- Wizard
-
-Using the GBP API
------------------
-
-Please see:
-
-- :ref:`gbp-of-overlay`
-
-- `Policy Resolution`_
-
-- `Forwarding Model <#forwarding>`__
-
-- `the **GBP** demo and development environments for tips <#demo>`__
-
-It is recommended to use:
-
-- `Neutron mapper <gbp-neutron>`
-
-.. _gbp-neutron:
-
-Using OpenStack with GBP
-------------------------
-
-Overview
-~~~~~~~~
-
-This section is for Application Developers and Network Administrators
-who are looking to integrate Group Based Policy with OpenStack.
-
-To enable the **GBP** Neutron Mapper feature, at the Karaf console:
-
-::
-
- feature:install odl-groupbasedpolicy-neutronmapper
-
-Neutron Mapper has the following dependencies that are automatically
-loaded:
-
-::
-
- odl-neutron-service
-
-Neutron Northbound implementing REST API used by OpenStack
-
-::
-
- odl-groupbasedpolicy-base
-
-Base **GBP** feature set, such as policy resolution, data model etc.
-
-::
-
- odl-groupbasedpolicy-ofoverlay
-
-REST calls from OpenStack Neutron are by the Neutron NorthBound project.
-
-**GBP** provides the implementation of the `Neutron V2.0
-API <http://developer.openstack.org/api-ref-networking-v2.html>`_.
-
-Features
-~~~~~~~~
-
-List of supported Neutron entities:
-
-- Port
-
-- Network
-
- - Standard Internal
-
- - External provider L2/L3 network
-
-- Subnet
-
-- Security-groups
-
-- Routers
-
- - Distributed functionality with local routing per compute
-
- - External gateway access per compute node (dedicated port required)
-
- - Multiple routers per tenant
-
-- FloatingIP NAT
-
-- IPv4/IPv6 support
-
-The mapping of Neutron entities to **GBP** entities is as follows:
-
-**Neutron Port**
-
-.. figure:: ./images/groupbasedpolicy/neutronmapper-gbp-mapping-port.png
- :alt: Neutron Port
-
- Neutron Port
-
-The Neutron port is mapped to an endpoint.
-
-The current implementation supports one IP address per Neutron port.
-
-An endpoint and L3-endpoint belong to multiple EndpointGroups if the
-Neutron port is in multiple Neutron Security Groups.
-
-The key for endpoint is L2-bridge-domain obtained as the parent of
-L2-flood-domain representing Neutron network. The MAC address is from
-the Neutron port. An L3-endpoint is created based on L3-context (the
-parent of the L2-bridge-domain) and IP address of Neutron Port.
-
-**Neutron Network**
-
-.. figure:: ./images/groupbasedpolicy/neutronmapper-gbp-mapping-network.png
- :alt: Neutron Network
-
- Neutron Network
-
-A Neutron network has the following characteristics:
-
-- defines a broadcast domain
-
-- defines a L2 transmission domain
-
-- defines a L2 name space.
-
-To represent this, a Neutron Network is mapped to multiple **GBP**
-entities. The first mapping is to an L2 flood-domain to reflect that the
-Neutron network is one flooding or broadcast domain. An L2-bridge-domain
-is then associated as the parent of L2 flood-domain. This reflects both
-the L2 transmission domain as well as the L2 addressing namespace.
-
-The third mapping is to L3-context, which represents the distinct L3
-address space. The L3-context is the parent of L2-bridge-domain.
-
-**Neutron Subnet**
-
-.. figure:: ./images/groupbasedpolicy/neutronmapper-gbp-mapping-subnet.png
- :alt: Neutron Subnet
-
- Neutron Subnet
-
-Neutron subnet is associated with a Neutron network. The Neutron subnet
-is mapped to a **GBP** subnet where the parent of the subnet is
-L2-flood-domain representing the Neutron network.
-
-**Neutron Security Group**
-
-.. figure:: ./images/groupbasedpolicy/neutronmapper-gbp-mapping-securitygroup.png
- :alt: Neutron Security Group and Rules
-
- Neutron Security Group and Rules
-
-**GBP** entity representing Neutron security-group is EndpointGroup.
-
-**Infrastructure EndpointGroups**
-
-Neutron-mapper automatically creates EndpointGroups to manage key
-infrastructure items such as:
-
-- DHCP EndpointGroup - contains endpoints representing Neutron DHCP
- ports
-
-- Router EndpointGroup - contains endpoints representing Neutron router
- interfaces
-
-- External EndpointGroup - holds L3-endpoints representing Neutron
- router gateway ports, also associated with FloatingIP ports.
-
-**Neutron Security Group Rules**
-
-This is the most involved amongst all the mappings because Neutron
-security-group-rules are mapped to contracts with clauses, subjects,
-rules, action-refs, classifier-refs, etc. Contracts are used between
-EndpointGroups representing Neutron Security Groups. For simplification
-it is important to note that Neutron security-group-rules are similar to
-a **GBP** rule containing:
-
-- classifier with direction
-
-- action of **allow**.
-
-**Neutron Routers**
-
-.. figure:: ./images/groupbasedpolicy/neutronmapper-gbp-mapping-router.png
- :alt: Neutron Router
-
- Neutron Router
-
-Neutron router is represented as a L3-context. This treats a router as a
-Layer3 namespace, and hence every network attached to it a part of that
-Layer3 namespace.
-
-This allows for multiple routers per tenant with complete isolation.
-
-The mapping of the router to an endpoint represents the router’s
-interface or gateway port.
-
-The mapping to an EndpointGroup represents the internal infrastructure
-EndpointGroups created by the **GBP** Neutron Mapper
-
-When a Neutron router interface is attached to a network/subnet, that
-network/subnet and its associated endpoints or Neutron Ports are
-seamlessly added to the namespace.
-
-**Neutron FloatingIP**
-
-When associated with a Neutron Port, this leverages the
-:ref:`OfOverlay <gbp-of-overlay>` renderer’s NAT capabilities.
-
-A dedicated *external* interface on each Nova compute host allows for
-disitributed external access. Each Nova instance associated with a
-FloatingIP address can access the external network directly without
-having to route via the Neutron controller, or having to enable any form
-of Neutron distributed routing functionality.
-
-Assuming the gateway provisioned in the Neutron Subnet command for the
-external network is reachable, the combination of **GBP** Neutron Mapper
-and :ref:`OfOverlay renderer <gbp-of-overlay>` will automatically ARP for this
-default gateway, requiring no user intervention.
-
-**Troubleshooting within GBP**
-
-Logging level for the mapping functionality can be set for package
-org.opendaylight.groupbasedpolicy.neutron.mapper. An example of enabling
-TRACE logging level on Karaf console:
-
-::
-
- log:set TRACE org.opendaylight.groupbasedpolicy.neutron.mapper
-
-**Neutron mapping example**
-
-As an example for mapping can be used creation of Neutron network,
-subnet and port. When a Neutron network is created 3 **GBP** entities
-are created: l2-flood-domain, l2-bridge-domain, l3-context.
-
-.. figure:: ./images/groupbasedpolicy/neutronmapper-gbp-mapping-network-example.png
- :alt: Neutron network mapping
-
- Neutron network mapping
-
-After an subnet is created in the network mapping looks like this.
-
-.. figure:: ./images/groupbasedpolicy/neutronmapper-gbp-mapping-subnet-example.png
- :alt: Neutron subnet mapping
-
- Neutron subnet mapping
-
-If an Neutron port is created in the subnet an endpoint and l3-endpoint
-are created. The endpoint has key composed from l2-bridge-domain and MAC
-address from Neutron port. A key of l3-endpoint is compesed from
-l3-context and IP address. The network containment of endpoint and
-l3-endpoint points to the subnet.
-
-.. figure:: ./images/groupbasedpolicy/neutronmapper-gbp-mapping-port-example.png
- :alt: Neutron port mapping
-
- Neutron port mapping
-
-Configuring GBP Neutron
-~~~~~~~~~~~~~~~~~~~~~~~
-
-No intervention passed initial OpenStack setup is required by the user.
-
-More information about configuration can be found in our DevStack demo
-environment on the `GBP
-wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`_.
-
-Administering or Managing GBP Neutron
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-For consistencies sake, all provisioning should be performed via the
-Neutron API. (CLI or Horizon).
-
-The mapped policies can be augmented via the **GBP** :ref:`UX <gbp-ux>`, to:
-
-- Enable :ref:`Service Function Chaining <gbp-sfc>`
-
-- Add endpoints from outside of Neutron i.e. VMs/containers not
- provisioned in OpenStack
-
-- Augment policies/contracts derived from Security Group Rules
-
-- Overlay additional contracts or groupings
-
-Tutorials
-~~~~~~~~~
-
-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.
-
-.. _gbp-of-overlay:
-
-Using the GBP OpenFlow Overlay (OfOverlay) renderer
----------------------------------------------------
-
-Overview
-~~~~~~~~
-
-The OpenFlow Overlay (OfOverlay) feature enables the OpenFlow Overlay
-renderer, which creates a network virtualization solution across nodes
-that host Open vSwitch software switches.
-
-Installing and Pre-requisites
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-From the Karaf console in OpenDaylight:
-
-::
-
- feature:install odl-groupbasedpolicy-ofoverlay
-
-This renderer is designed to work with OpenVSwitch (OVS) 2.1+ (although
-2.3 is strongly recommended) and OpenFlow 1.3.
-
-When used in conjunction with the :ref:`Neutron Mapper feature <gbp-neutron>`
-no extra OfOverlay specific setup is required.
-
-When this feature is loaded "standalone", the user is required to
-configure infrastructure, such as
-
-- instantiating OVS bridges,
-
-- attaching hosts to the bridges,
-
-- and creating the VXLAN/VXLAN-GPE tunnel ports on the bridges.
-
-.. _gbp-offset:
-
-The **GBP** OfOverlay renderer also supports a table offset option, to
-offset the pipeline post-table 0. The value of table offset is stored in
-the config datastore and it may be rewritten at runtime.
-
-::
-
- PUT http://{{controllerIp}}:8181/restconf/config/ofoverlay:of-overlay-config
- {
- "of-overlay-config": {
- "gbp-ofoverlay-table-offset": 6
- }
- }
-
-The default value is set by changing:
-<gbp-ofoverlay-table-offset>0</gbp-ofoverlay-table-offset>
-
-in file:
-distribution-karaf/target/assembly/etc/opendaylight/karaf/15-groupbasedpolicy-ofoverlay.xml
-
-To avoid overwriting runtime changes, the default value is used only
-when the OfOverlay renderer starts and no other value has been written
-before.
-
-OpenFlow Overlay Architecture
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-These are the primary components of **GBP**. The OfOverlay components
-are highlighted in red.
-
-.. figure:: ./images/groupbasedpolicy/ofoverlay-1-components.png
- :alt: OfOverlay within **GBP**
-
- OfOverlay within **GBP**
-
-In terms of the inner components of the **GBP** OfOverlay renderer:
-
-.. figure:: ./images/groupbasedpolicy/ofoverlay-2-components.png
- :alt: OfOverlay expanded view:
-
- OfOverlay expanded view:
-
-**OfOverlay Renderer**
-
-Launches components below:
-
-**Policy Resolver**
-
-Policy resolution is completely domain independent, and the OfOverlay
-leverages process policy information internally. See `Policy Resolution
-process <Policy Resolution>`_.
-
-It listens to inputs to the *Tenants* configuration datastore, validates
-tenant input, then writes this to the Tenants operational datastore.
-
-From there an internal notification is generated to the PolicyManager.
-
-In the next release, this will be moving to a non-renderer specific
-location.
-
-**Endpoint Manager**
-
-The endpoint repository operates in **orchestrated** mode. This means
-the user is responsible for the provisioning of endpoints via:
-
-- :ref:`UX/GUI <gbp-ux>`
-
-- REST API
-
-.. note::
-
- When using the :ref:`Neutron mapper <gbp-neutron>` feature, everything is
- managed transparently via Neutron.
-
-The Endpoint Manager is responsible for listening to Endpoint repository
-updates and notifying the Switch Manager when a valid Endpoint has been
-registered.
-
-It also supplies utility functions to the flow pipeline process.
-
-**Switch Manager**
-
-The Switch Manager is purely a state manager.
-
-Switches are in one of 3 states:
-
-- DISCONNECTED
-
-- PREPARING
-
-- READY
-
-**Ready** is denoted by a connected switch:
-
-- having a tunnel interface
-
-- having at least one endpoint connected.
-
-In this way **GBP** is not writing to switches it has no business to.
-
-**Preparing** simply means the switch has a controller connection but is
-missing one of the above *complete and necessary* conditions
-
-**Disconnected** means a previously connected switch is no longer
-present in the Inventory operational datastore.
-
-.. figure:: ./images/groupbasedpolicy/ofoverlay-3-flowpipeline.png
- :alt: OfOverlay Flow Pipeline
-
- OfOverlay Flow Pipeline
-
-The OfOverlay leverages Nicira registers as follows:
-
-- REG0 = Source EndpointGroup + Tenant ordinal
-
-- REG1 = Source Conditions + Tenant ordinal
-
-- REG2 = Destination EndpointGroup + Tenant ordinal
-
-- REG3 = Destination Conditions + Tenant ordinal
-
-- REG4 = Bridge Domain + Tenant ordinal
-
-- REG5 = Flood Domain + Tenant ordinal
-
-- REG6 = Layer 3 Context + Tenant ordinal
-
-**Port Security**
-
-Table 0 of the OpenFlow pipeline. Responsible for ensuring that only
-valid connections can send packets into the pipeline:
-
-::
-
- cookie=0x0, <snip> , priority=200,in_port=3 actions=goto_table:2
- cookie=0x0, <snip> , priority=200,in_port=1 actions=goto_table:1
- cookie=0x0, <snip> , priority=121,arp,in_port=5,dl_src=fa:16:3e:d5:b9:8d,arp_spa=10.1.1.3 actions=goto_table:2
- cookie=0x0, <snip> , priority=120,ip,in_port=5,dl_src=fa:16:3e:d5:b9:8d,nw_src=10.1.1.3 actions=goto_table:2
- cookie=0x0, <snip> , priority=115,ip,in_port=5,dl_src=fa:16:3e:d5:b9:8d,nw_dst=255.255.255.255 actions=goto_table:2
- cookie=0x0, <snip> , priority=112,ipv6 actions=drop
- cookie=0x0, <snip> , priority=111, ip actions=drop
- cookie=0x0, <snip> , priority=110,arp actions=drop
- cookie=0x0, <snip> ,in_port=5,dl_src=fa:16:3e:d5:b9:8d actions=goto_table:2
- cookie=0x0, <snip> , priority=1 actions=drop
-
-Ingress from tunnel interface, go to Table *Source Mapper*:
-
-::
-
- cookie=0x0, <snip> , priority=200,in_port=3 actions=goto_table:2
-
-Ingress from outside, goto Table *Ingress NAT Mapper*:
-
-::
-
- cookie=0x0, <snip> , priority=200,in_port=1 actions=goto_table:1
-
-ARP from Endpoint, go to Table *Source Mapper*:
-
-::
-
- cookie=0x0, <snip> , priority=121,arp,in_port=5,dl_src=fa:16:3e:d5:b9:8d,arp_spa=10.1.1.3 actions=goto_table:2
-
-IPv4 from Endpoint, go to Table *Source Mapper*:
-
-::
-
- cookie=0x0, <snip> , priority=120,ip,in_port=5,dl_src=fa:16:3e:d5:b9:8d,nw_src=10.1.1.3 actions=goto_table:2
-
-DHCP DORA from Endpoint, go to Table *Source Mapper*:
-
-::
-
- cookie=0x0, <snip> , priority=115,ip,in_port=5,dl_src=fa:16:3e:d5:b9:8d,nw_dst=255.255.255.255 actions=goto_table:2
-
-Series of DROP tables with priority set to capture any non-specific
-traffic that should have matched above:
-
-::
-
- cookie=0x0, <snip> , priority=112,ipv6 actions=drop
- cookie=0x0, <snip> , priority=111, ip actions=drop
- cookie=0x0, <snip> , priority=110,arp actions=drop
-
-"L2" catch all traffic not identified above:
-
-::
-
- cookie=0x0, <snip> ,in_port=5,dl_src=fa:16:3e:d5:b9:8d actions=goto_table:2
-
-Drop Flow:
-
-::
-
- cookie=0x0, <snip> , priority=1 actions=drop
-
-**Ingress NAT Mapper**
-
-Table :ref:`offset <gbp-offset>` +1.
-
-ARP responder for external NAT address:
-
-::
-
- cookie=0x0, <snip> , priority=150,arp,arp_tpa=192.168.111.51,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:fa:16:3e:58:c3:dd->eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],load:0xfa163e58c3dd->NXM_NX_ARP_SHA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xc0a86f33->NXM_OF_ARP_SPA[],IN_PORT
-
-Translate from Outside to Inside and perform same functions as
-SourceMapper.
-
-::
-
- cookie=0x0, <snip> , priority=100,ip,nw_dst=192.168.111.51 actions=set_field:10.1.1.2->ip_dst,set_field:fa:16:3e:58:c3:dd->eth_dst,load:0x2->NXM_NX_REG0[],load:0x1->NXM_NX_REG1[],load:0x4->NXM_NX_REG4[],load:0x5->NXM_NX_REG5[],load:0x7->NXM_NX_REG6[],load:0x3->NXM_NX_TUN_ID[0..31],goto_table:3
-
-**Source Mapper**
-
-Table :ref:`offset <gbp-offset>` +2.
-
-Determines based on characteristics from the ingress port, which:
-
-- EndpointGroup(s) it belongs to
-
-- Forwarding context
-
-- Tunnel VNID ordinal
-
-Establishes tunnels at valid destination switches for ingress.
-
-Ingress Tunnel established at remote node with VNID Ordinal that maps to
-Source EPG, Forwarding Context etc:
-
-::
-
- cookie=0x0, <snip>, priority=150,tun_id=0xd,in_port=3 actions=load:0xc->NXM_NX_REG0[],load:0xffffff->NXM_NX_REG1[],load:0x4->NXM_NX_REG4[],load:0x5->NXM_NX_REG5[],load:0x7->NXM_NX_REG6[],goto_table:3
-
-Maps endpoint to Source EPG, Forwarding Context based on ingress port,
-and MAC:
-
-::
-
- cookie=0x0, <snip> , priority=100,in_port=5,dl_src=fa:16:3e:b4:b4:b1 actions=load:0xc->NXM_NX_REG0[],load:0x1->NXM_NX_REG1[],load:0x4->NXM_NX_REG4[],load:0x5->NXM_NX_REG5[],load:0x7->NXM_NX_REG6[],load:0xd->NXM_NX_TUN_ID[0..31],goto_table:3
-
-Generic drop:
-
-::
-
- cookie=0x0, duration=197.622s, table=2, n_packets=0, n_bytes=0, priority=1 actions=drop
-
-**Destination Mapper**
-
-Table :ref:`offset <gbp-offset>` +3.
-
-Determines based on characteristics of the endpoint:
-
-- EndpointGroup(s) it belongs to
-
-- Forwarding context
-
-- Tunnel Destination value
-
-Manages routing based on valid ingress nodes ARP’ing for their default
-gateway, and matches on either gateway MAC or destination endpoint MAC.
-
-ARP for default gateway for the 10.1.1.0/24 subnet:
-
-::
-
- cookie=0x0, <snip> , priority=150,arp,reg6=0x7,arp_tpa=10.1.1.1,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:fa:16:3e:28:4c:82->eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],load:0xfa163e284c82->NXM_NX_ARP_SHA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xa010101->NXM_OF_ARP_SPA[],IN_PORT
-
-Broadcast traffic destined for GroupTable:
-
-::
-
- cookie=0x0, <snip> , priority=140,reg5=0x5,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=load:0x5->NXM_NX_TUN_ID[0..31],group:5
-
-Layer3 destination matching flows, where priority=100+masklength. Since
-**GBP** now support L3Prefix endpoint, we can set default routes etc:
-
-::
-
- cookie=0x0, <snip>, priority=132,ip,reg6=0x7,dl_dst=fa:16:3e:b4:b4:b1,nw_dst=10.1.1.3 actions=load:0xc->NXM_NX_REG2[],load:0x1->NXM_NX_REG3[],load:0x5->NXM_NX_REG7[],set_field:fa:16:3e:b4:b4:b1->eth_dst,dec_ttl,goto_table:4
-
-Layer2 destination matching flows, designed to be caught only after last
-IP flow (lowest priority IP flow is 100):
-
-::
-
- cookie=0x0, duration=323.203s, table=3, n_packets=4, n_bytes=168, priority=50,reg4=0x4,dl_dst=fa:16:3e:58:c3:dd actions=load:0x2->NXM_NX_REG2[],load:0x1->NXM_NX_REG3[],load:0x2->NXM_NX_REG7[],goto_table:4
-
-General drop flow: cookie=0x0, duration=323.207s, table=3, n\_packets=6,
-n\_bytes=588, priority=1 actions=drop
-
-**Policy Enforcer**
-
-Table :ref:`offset <gbp-offset>` +4.
-
-Once the Source and Destination EndpointGroups are assigned, policy is
-enforced based on resolved rules.
-
-In the case of :ref:`Service Function Chaining <gbp-sfc>`, the encapsulation
-and destination for traffic destined to a chain, is discovered and
-enforced.
-
-Policy flow, allowing IP traffic between EndpointGroups:
-
-::
-
- cookie=0x0, <snip> , priority=64998,ip,reg0=0x8,reg1=0x1,reg2=0xc,reg3=0x1 actions=goto_table:5
-
-**Egress NAT Mapper**
-
-Table :ref:`offset <gbp-offset>` +5.
-
-Performs NAT function before Egressing OVS instance to the underlay
-network.
-
-Inside to Outside NAT translation before sending to underlay:
-
-::
-
- cookie=0x0, <snip> , priority=100,ip,reg6=0x7,nw_src=10.1.1.2 actions=set_field:192.168.111.51->ip_src,goto_table:6
-
-**External Mapper**
-
-Table :ref:`offset <gbp-offset>` +6.
-
-Manages post-policy enforcement for endpoint specific destination
-effects. Specifically for :ref:`Service Function Chaining <gbp-sfc>`, which is
-why we can support both symmetric and asymmetric chains and distributed
-ingress/egress classification.
-
-Generic allow:
-
-::
-
- cookie=0x0, <snip>, priority=100 actions=output:NXM_NX_REG7[]
-
-Configuring OpenFlow Overlay via REST
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.. note::
-
- Please see the :ref:`UX <gbp-ux>` section on how to configure **GBP** via
- the GUI.
-
-**Endpoint**
-
-::
-
- POST http://{{controllerIp}}:8181/restconf/operations/endpoint:register-endpoint
- {
- "input": {
- "endpoint-group": "<epg0>",
- "endpoint-groups" : ["<epg1>","<epg2>"],
- "network-containment" : "<fowarding-model-context1>",
- "l2-context": "<bridge-domain1>",
- "mac-address": "<mac1>",
- "l3-address": [
- {
- "ip-address": "<ipaddress1>",
- "l3-context": "<l3_context1>"
- }
- ],
- "*ofoverlay:port-name*": "<ovs port name>",
- "tenant": "<tenant1>"
- }
- }
-
-.. note::
-
- The usage of "port-name" preceded by "ofoverlay". In OpenDaylight,
- base datastore objects can be *augmented*. In **GBP**, the base
- endpoint model has no renderer specifics, hence can be leveraged
- across multiple renderers.
-
-**OVS Augmentations to Inventory**
-
-::
-
- PUT http://{{controllerIp}}:8181/restconf/config/opendaylight-inventory:nodes/
- {
- "opendaylight-inventory:nodes": {
- "node": [
- {
- "id": "openflow:123456",
- "ofoverlay:tunnel": [
- {
- "tunnel-type": "overlay:tunnel-type-vxlan",
- "ip": "<ip_address_of_ovs>",
- "port": 4789,
- "node-connector-id": "openflow:123456:1"
- }
- ]
- },
- {
- "id": "openflow:654321",
- "ofoverlay:tunnel": [
- {
- "tunnel-type": "overlay:tunnel-type-vxlan",
- "ip": "<ip_address_of_ovs>",
- "port": 4789,
- "node-connector-id": "openflow:654321:1"
- }
- ]
- }
- ]
- }
- }
-
-**Tenants** see `Policy Resolution`_ and
-`Forwarding Model <#forwarding>`__ for details:
-
-::
-
- {
- "policy:tenant": {
- "contract": [
- {
- "clause": [
- {
- "name": "allow-http-clause",
- "subject-refs": [
- "allow-http-subject",
- "allow-icmp-subject"
- ]
- }
- ],
- "id": "<id>",
- "subject": [
- {
- "name": "allow-http-subject",
- "rule": [
- {
- "classifier-ref": [
- {
- "direction": "in",
- "name": "http-dest"
- },
- {
- "direction": "out",
- "name": "http-src"
- }
- ],
- "action-ref": [
- {
- "name": "allow1",
- "order": 0
- }
- ],
- "name": "allow-http-rule"
- }
- ]
- },
- {
- "name": "allow-icmp-subject",
- "rule": [
- {
- "classifier-ref": [
- {
- "name": "icmp"
- }
- ],
- "action-ref": [
- {
- "name": "allow1",
- "order": 0
- }
- ],
- "name": "allow-icmp-rule"
- }
- ]
- }
- ]
- }
- ],
- "endpoint-group": [
- {
- "consumer-named-selector": [
- {
- "contract": [
- "<id>"
- ],
- "name": "<name>"
- }
- ],
- "id": "<id>",
- "provider-named-selector": []
- },
- {
- "consumer-named-selector": [],
- "id": "<id>",
- "provider-named-selector": [
- {
- "contract": [
- "<id>"
- ],
- "name": "<name>"
- }
- ]
- }
- ],
- "id": "<id>",
- "l2-bridge-domain": [
- {
- "id": "<id>",
- "parent": "<id>"
- }
- ],
- "l2-flood-domain": [
- {
- "id": "<id>",
- "parent": "<id>"
- },
- {
- "id": "<id>",
- "parent": "<id>"
- }
- ],
- "l3-context": [
- {
- "id": "<id>"
- }
- ],
- "name": "GBPPOC",
- "subject-feature-instances": {
- "classifier-instance": [
- {
- "classifier-definition-id": "<id>",
- "name": "http-dest",
- "parameter-value": [
- {
- "int-value": "6",
- "name": "proto"
- },
- {
- "int-value": "80",
- "name": "destport"
- }
- ]
- },
- {
- "classifier-definition-id": "<id>",
- "name": "http-src",
- "parameter-value": [
- {
- "int-value": "6",
- "name": "proto"
- },
- {
- "int-value": "80",
- "name": "sourceport"
- }
- ]
- },
- {
- "classifier-definition-id": "<id>",
- "name": "icmp",
- "parameter-value": [
- {
- "int-value": "1",
- "name": "proto"
- }
- ]
- }
- ],
- "action-instance": [
- {
- "name": "allow1",
- "action-definition-id": "<id>"
- }
- ]
- },
- "subnet": [
- {
- "id": "<id>",
- "ip-prefix": "<ip_prefix>",
- "parent": "<id>",
- "virtual-router-ip": "<ip address>"
- },
- {
- "id": "<id>",
- "ip-prefix": "<ip prefix>",
- "parent": "<id>",
- "virtual-router-ip": "<ip address>"
- }
- ]
- }
- }
-
-Tutorials
-~~~~~~~~~
-
-Comprehensive tutorials, along with a demonstration environment
-leveraging Vagrant can be found on the `GBP
-wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`__
-
-Using the GBP eBPF IO Visor Agent renderer
-------------------------------------------
-
-Overview
-~~~~~~~~
-
-The IO Visor renderer feature enables container endpoints (e.g. Docker,
-LXC) to leverage GBP policies.
-
-The renderer interacts with a IO Visor module from the Linux Foundation
-IO Visor project.
-
-Installing and Pre-requisites
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-From the Karaf console in OpenDaylight:
-
-::
-
- feature:install odl-groupbasedpolicy-iovisor odl-restconf
-
-Installation details, usage, and other information for the IO Visor GBP
-module can be found here: `IO Visor github repo for IO
-Modules <https://github.com/iovisor/iomodules>`_
-
-Using the GBP FaaS renderer
----------------------------
-
-Overview
-~~~~~~~~
-
-The FaaS renderer feature enables leveraging the FaaS project as a GBP
-renderer.
-
-Installing and Pre-requisites
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-From the Karaf console in OpenDaylight:
-
-::
-
- feature:install odl-groupbasedpolicy-faas
-
-More information about FaaS can be found here:
-https://wiki.opendaylight.org/view/FaaS:GBPIntegration
-
-.. _gbp-sfc:
-
-Using Service Function Chaining (SFC) with GBP Neutron Mapper and OfOverlay
----------------------------------------------------------------------------
-
-Overview
-~~~~~~~~
-
-Please refer to the Service Function Chaining project for specifics on
-SFC provisioning and theory.
-
-**GBP** allows for the use of a chain, by name, in policy.
-
-This takes the form of an *action* in **GBP**.
-
-Using the `GBP demo and development environment <#demo>`__ as an
-example:
-
-.. figure:: ./images/groupbasedpolicy/sfc-1-topology.png
- :alt: GBP and SFC integration environment
-
- GBP and SFC integration environment
-
-In the topology above, a symmetrical chain between H35\_2 and H36\_3
-could take path:
-
-H35\_2 to sw1 to sff1 to sf1 to sff1 to sff2 to sf2 to sff2 to sw6 to
-H36\_3
-
-If symmetric chaining was desired, the return path is:
-
-.. figure:: ./images/groupbasedpolicy/sfc-2-symmetric.png
- :alt: GBP and SFC symmetric chain environment
-
- GBP and SFC symmetric chain environment
-
-If asymmetric chaining was desired, the return path could be direct, or
-an **entirely different chain**.
-
-.. figure:: ./images/groupbasedpolicy/sfc-3-asymmetric.png
- :alt: GBP and SFC assymmetric chain environment
-
- GBP and SFC assymmetric chain environment
-
-All these scenarios are supported by the integration.
-
-In the **Subject Feature Instance** section of the tenant config, we
-define the instances of the classifier definitions for ICMP and HTTP:
-
-::
-
- "subject-feature-instances": {
- "classifier-instance": [
- {
- "name": "icmp",
- "parameter-value": [
- {
- "name": "proto",
- "int-value": 1
- }
- ]
- },
- {
- "name": "http-dest",
- "parameter-value": [
- {
- "int-value": "6",
- "name": "proto"
- },
- {
- "int-value": "80",
- "name": "destport"
- }
- ]
- },
- {
- "name": "http-src",
- "parameter-value": [
- {
- "int-value": "6",
- "name": "proto"
- },
- {
- "int-value": "80",
- "name": "sourceport"
- }
- ]
- }
- ],
-
-Then the action instances to associate to traffic that matches
-classifiers are defined.
-
-Note the *SFC chain name* must exist in SFC, and is validated against
-the datastore once the tenant configuration is entered, before entering
-a valid tenant configuration into the operational datastore (which
-triggers policy resolution).
-
-::
-
- "action-instance": [
- {
- "name": "chain1",
- "parameter-value": [
- {
- "name": "sfc-chain-name",
- "string-value": "SFCGBP"
- }
- ]
- },
- {
- "name": "allow1",
- }
- ]
- },
-
-When ICMP is matched, allow the traffic:
-
-::
-
- "contract": [
- {
- "subject": [
- {
- "name": "icmp-subject",
- "rule": [
- {
- "name": "allow-icmp-rule",
- "order" : 0,
- "classifier-ref": [
- {
- "name": "icmp"
- }
- ],
- "action-ref": [
- {
- "name": "allow1",
- "order": 0
- }
- ]
- }
-
- ]
- },
-
-When HTTP is matched, **in** to the provider of the contract with a TCP
-destination port of 80 (HTTP) or the HTTP request. The chain action is
-triggered, and similarly **out** from the provider for traffic with TCP
-source port of 80 (HTTP), or the HTTP response.
-
-::
-
- {
- "name": "http-subject",
- "rule": [
- {
- "name": "http-chain-rule-in",
- "classifier-ref": [
- {
- "name": "http-dest",
- "direction": "in"
- }
- ],
- "action-ref": [
- {
- "name": "chain1",
- "order": 0
- }
- ]
- },
- {
- "name": "http-chain-rule-out",
- "classifier-ref": [
- {
- "name": "http-src",
- "direction": "out"
- }
- ],
- "action-ref": [
- {
- "name": "chain1",
- "order": 0
- }
- ]
- }
- ]
- }
-
-To enable asymmetrical chaining, for instance, the user desires that
-HTTP requests traverse the chain, but the HTTP response does not, the
-HTTP response is set to *allow* instead of chain:
-
-::
-
- {
- "name": "http-chain-rule-out",
- "classifier-ref": [
- {
- "name": "http-src",
- "direction": "out"
- }
- ],
- "action-ref": [
- {
- "name": "allow1",
- "order": 0
- }
- ]
- }
-
-Demo/Development environment
-----------------------------
-
-The **GBP** project for this release has two demo/development environments.
-
-- Docker based GBP and GBP+SFC integration Vagrant environment
-
-- DevStack based GBP+Neutron integration Vagrant environment
-
-`Demo @ GBP
-wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Consumability/Demo>`_
-
.. toctree::
:maxdepth: 1
- alto-user-guide
- authentication-and-authorization-services
- bgpcep-guide/bgp/index
- bgpcep-guide/bmp/index
- bier-user-guide
- capwap-user-guide
- cardinal_-opendaylight-monitoring-as-a-service
- centinel-user-guide
- daexim-user-guide
- didm-user-guide
distribution-version-user-guide
- eman-user-guide
- fabric-as-a-service
- genius-user-guide
- group-based-policy-user-guide
jsonrpc-user-guide
- l2switch-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
- network-intent-composition-(nic)-user-guide
- ocp-plugin-user-guide
- odl-sdni-user-guide
- of-config-user-guide
openflow-plugin-project-user-guide
- opflex-agent-ovs-user-guide
ovsdb-user-guide
p4plugin-user-guide
- packetcable-user-guide
- bgpcep-guide/pcep/index
service-function-chaining
- snmp-plugin-user-guide
snmp4sdn-user-guide
- sxp-user-guide
- tsdr-user-guide
- ttp-cli-tools-user-guide
- uni-manager-plug-in-project
unified-secure-channel
- virtual-tenant-network-(vtn)
+++ /dev/null
-.. _l2switch-user-guide:
-
-L2 Switch User Guide
-====================
-
-Overview
---------
-
-The L2 Switch project provides Layer2 switch functionality.
-
-L2 Switch Architecture
-----------------------
-
-- Packet Handler
-
- - Decodes the packets coming to the controller and dispatches them
- appropriately
-
-- Loop Remover
-
- - Removes loops in the network
-
-- Arp Handler
-
- - Handles the decoded ARP packets
-
-- Address Tracker
-
- - Learns the Addresses (MAC and IP) of entities in the network
-
-- Host Tracker
-
- - Tracks the locations of hosts in the network
-
-- L2 Switch Main
-
- - Installs flows on each switch based on network traffic
-
-Configurable parameters in L2 Switch
-------------------------------------
-
-The sections below give details about the configuration settings for
-the components that can be configured.
-
-The process to change the configuration has been changed with
-the introduction of Blueprint in the Boron release. Please
-refer to :ref:`l2switch-change-config` for an
-example illustrating how to change the configurations.
-
-Configurable parameters in Loop Remover
----------------------------------------
-
-- l2switch/loopremover/implementation/src/main/yang/loop-remover-config.yang
-
- - is-install-lldp-flow
-
- - "true" means a flow that sends all LLDP packets to the
- controller will be installed on each switch
-
- - "false" means this flow will not be installed
-
- - default value is true
-
- - lldp-flow-table-id
-
- - The LLDP flow will be installed on the specified flow table of
- each switch
-
- - This field is only relevant when "is-install-lldp-flow" is set
- to "true"
-
- - default value is 0
-
- - lldp-flow-priority
-
- - The LLDP flow will be installed with the specified priority
-
- - This field is only relevant when "is-install-lldp-flow" is set
- to "true"
-
- - default value is 100
-
- - lldp-flow-idle-timeout
-
- - The LLDP flow will timeout (removed from the switch) if the
- flow doesn’t forward a packet for *x* seconds
-
- - This field is only relevant when "is-install-lldp-flow" is set
- to "true"
-
- - default value is 0
-
- - lldp-flow-hard-timeout
-
- - The LLDP flow will timeout (removed from the switch) after *x*
- seconds, regardless of how many packets it is forwarding
-
- - This field is only relevant when "is-install-lldp-flow" is set
- to "true"
-
- - default value is 0
-
- - graph-refresh-delay
-
- - A graph of the network is maintained and gets updated as
- network elements go up/down (i.e. links go up/down and switches
- go up/down)
-
- - After a network element going up/down, it waits
- *graph-refresh-delay* seconds before recomputing the graph
-
- - A higher value has the advantage of doing less graph updates,
- at the potential cost of losing some packets because the graph
- didn’t update immediately.
-
- - A lower value has the advantage of handling network topology
- changes quicker, at the cost of doing more computation.
-
- - default value is 1000
-
-Configurable parameters in Arp Handler
---------------------------------------
-
-- l2switch/arphandler/src/main/yang/arp-handler-config.yang
-
- - is-proactive-flood-mode
-
- - "true" means that flood flows will be installed on each switch.
- With this flood flow, each switch will flood a packet that
- doesn’t match any other flows.
-
- - Advantage: Fewer packets are sent to the controller because
- those packets are flooded to the network.
-
- - Disadvantage: A lot of network traffic is generated.
-
- - "false" means the previously mentioned flood flows will not be
- installed. Instead an ARP flow will be installed on each switch
- that sends all ARP packets to the controller.
-
- - Advantage: Less network traffic is generated.
-
- - Disadvantage: The controller handles more packets (ARP
- requests & replies) and the ARP process takes longer than if
- there were flood flows.
-
- - default value is true
-
- - flood-flow-table-id
-
- - The flood flow will be installed on the specified flow table of
- each switch
-
- - This field is only relevant when "is-proactive-flood-mode" is
- set to "true"
-
- - default value is 0
-
- - flood-flow-priority
-
- - The flood flow will be installed with the specified priority
-
- - This field is only relevant when "is-proactive-flood-mode" is
- set to "true"
-
- - default value is 2
-
- - flood-flow-idle-timeout
-
- - The flood flow will timeout (removed from the switch) if the
- flow doesn’t forward a packet for *x* seconds
-
- - This field is only relevant when "is-proactive-flood-mode" is
- set to "true"
-
- - default value is 0
-
- - flood-flow-hard-timeout
-
- - The flood flow will timeout (removed from the switch) after *x*
- seconds, regardless of how many packets it is forwarding
-
- - This field is only relevant when "is-proactive-flood-mode" is
- set to "true"
-
- - default value is 0
-
- - arp-flow-table-id
-
- - The ARP flow will be installed on the specified flow table of
- each switch
-
- - This field is only relevant when "is-proactive-flood-mode" is
- set to "false"
-
- - default value is 0
-
- - arp-flow-priority
-
- - The ARP flow will be installed with the specified priority
-
- - This field is only relevant when "is-proactive-flood-mode" is
- set to "false"
-
- - default value is 1
-
- - arp-flow-idle-timeout
-
- - The ARP flow will timeout (removed from the switch) if the flow
- doesn’t forward a packet for *x* seconds
-
- - This field is only relevant when "is-proactive-flood-mode" is
- set to "false"
-
- - default value is 0
-
- - arp-flow-hard-timeout
-
- - The ARP flow will timeout (removed from the switch) after
- *arp-flow-hard-timeout* seconds, regardless of how many packets
- it is forwarding
-
- - This field is only relevant when "is-proactive-flood-mode" is
- set to "false"
-
- - default value is 0
-
-Configurable parameters in Address Tracker
-------------------------------------------
-
-- l2switch/addresstracker/implementation/src/main/yang/address-tracker-config.yang
-
- - timestamp-update-interval
-
- - A last-seen timestamp is associated with each address. This
- last-seen timestamp will only be updated after
- *timestamp-update-interval* milliseconds.
-
- - A higher value has the advantage of performing less writes to
- the database.
-
- - A lower value has the advantage of knowing how fresh an address
- is.
-
- - default value is 600000
-
- - observe-addresses-from
-
- - IP and MAC addresses can be observed/learned from ARP, IPv4,
- and IPv6 packets. Set which packets to make these observations
- from.
-
- - default value is arp
-
-Configurable parameters in L2 Switch Main
------------------------------------------
-
-- l2switch/l2switch-main/src/main/yang/l2switch-config.yang
-
- - is-install-dropall-flow
-
- - "true" means a drop-all flow will be installed on each switch,
- so the default action will be to drop a packet instead of
- sending it to the controller
-
- - "false" means this flow will not be installed
-
- - default value is true
-
- - dropall-flow-table-id
-
- - The dropall flow will be installed on the specified flow table
- of each switch
-
- - This field is only relevant when "is-install-dropall-flow" is
- set to "true"
-
- - default value is 0
-
- - dropall-flow-priority
-
- - The dropall flow will be installed with the specified priority
-
- - This field is only relevant when "is-install-dropall-flow" is
- set to "true"
-
- - default value is 0
-
- - dropall-flow-idle-timeout
-
- - The dropall flow will timeout (removed from the switch) if the
- flow doesn’t forward a packet for *x* seconds
-
- - This field is only relevant when "is-install-dropall-flow" is
- set to "true"
-
- - default value is 0
-
- - dropall-flow-hard-timeout
-
- - The dropall flow will timeout (removed from the switch) after
- *x* seconds, regardless of how many packets it is forwarding
-
- - This field is only relevant when "is-install-dropall-flow" is
- set to "true"
-
- - default value is 0
-
- - is-learning-only-mode
-
- - "true" means that the L2 Switch will only be learning addresses.
- No additional flows to optimize network traffic will be
- installed.
-
- - "false" means that the L2 Switch will react to network traffic
- and install flows on the switches to optimize traffic.
- Currently, MAC-to-MAC flows are installed.
-
- - default value is false
-
- - reactive-flow-table-id
-
- - The reactive flow will be installed on the specified flow table
- of each switch
-
- - This field is only relevant when "is-learning-only-mode" is set
- to "false"
-
- - default value is 0
-
- - reactive-flow-priority
-
- - The reactive flow will be installed with the specified priority
-
- - This field is only relevant when "is-learning-only-mode" is set
- to "false"
-
- - default value is 10
-
- - reactive-flow-idle-timeout
-
- - The reactive flow will timeout (removed from the switch) if the
- flow doesn’t forward a packet for *x* seconds
-
- - This field is only relevant when "is-learning-only-mode" is set
- to "false"
-
- - default value is 600
-
- - reactive-flow-hard-timeout
-
- - The reactive flow will timeout (removed from the switch) after
- *x* seconds, regardless of how many packets it is forwarding
-
- - This field is only relevant when "is-learning-only-mode" is set
- to "false"
-
- - default value is 300
-
-.. _l2switch-change-config:
-
-Change configuration in L2 Switch
----------------------------------
-
-.. note:: For more information on Blueprint in OpenDaylight, see `this wiki page <https://wiki.opendaylight.org/view/Using_Blueprint>`_.
-
-The following is an example on how to change the configurations of the L2 Switch components.
-
-**Use Case:** Change the L2 switch from proactive flood mode to reactive mode.
-
-**Option 1:** (external xml file)
-
-#. Navigate to etc folder under download distribution
-#. Create following directory structure::
-
- mkdir - p opendaylight/datastore/initial/config
-
-#. Create a new xml file corresponding to ``<yang module name>_<container name>.xml``::
-
- vi arp-handler-config_arp-handler-config.xml
-
-#. Add following contents to the created file::
-
- <?xml version="1.0" encoding="UTF-8"?>
- <arp-handler-config xmlns="urn:opendaylight:packet:arp-handler-config">
- <is-proactive-flood-mode>false</is-proactive-flood-mode>
- </arp-handler-config>
-
-#. Restart the controller which injects the configurations.
-
-**Option 2:** (REST URL)
-
-#. Make the following REST call
-
- * *URL:* ``http://{{LOCALIP}}:8181/restconf/config/arp-handler-config:arp-handler-config/``
- * *Content-Type:* application/json
- * *Body*::
-
- {
- "arp-handler-config":
- {
- "is-proactive-flood-mode":false
- }
- }
-
- * *Expected Result:* 201 Created
-
-#. Restart the controller to see updated configurations. With out a restart
- new configurations will be merged with old configurations which is not desirable.
-
-Running the L2 Switch
----------------------
-
-To run the L2 Switch inside the OpenDaylight distribution simply
-install the ``odl-l2switch-switch-ui`` feature;
-
-::
-
- feature:install odl-l2switch-switch-ui
-
-Create a network using mininet
-------------------------------
-
-::
-
- sudo mn --controller=remote,ip=<Controller IP> --topo=linear,3 --switch ovsk,protocols=OpenFlow13
- sudo mn --controller=remote,ip=127.0.0.1 --topo=linear,3 --switch ovsk,protocols=OpenFlow13
-
-The above command will create a virtual network consisting of 3
-switches. Each switch will connect to the controller located at the
-specified IP, i.e. 127.0.0.1
-
-::
-
- sudo mn --controller=remote,ip=127.0.0.1 --mac --topo=linear,3 --switch ovsk,protocols=OpenFlow13
-
-The above command has the "mac" option, which makes it easier to
-distinguish between Host MAC addresses and Switch MAC addresses.
-
-Generating network traffic using mininet
-----------------------------------------
-
-::
-
- h1 ping h2
-
-The above command will cause host1 (h1) to ping host2 (h2)
-
-::
-
- pingall
-
-*pingall* will cause each host to ping every other host.
-
-Checking Address Observations
------------------------------
-
-Address Observations are added to the Inventory data tree.
-
-The Address Observations on a Node Connector can be checked through a
-browser or a REST Client.
-
-::
-
- http://10.194.126.91:8080/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/node-connector/openflow:1:1
-
-.. figure:: ./images/l2switch-address-observations.png
- :alt: Address Observations
-
- Address Observations
-
-Checking Hosts
---------------
-
-Host information is added to the Topology data tree.
-
-- Host address
-
-- Attachment point (link) to a node/switch
-
-This host information and attachment point information can be checked
-through a browser or a REST Client.
-
-::
-
- http://10.194.126.91:8080/restconf/operational/network-topology:network-topology/topology/flow:1/
-
-.. figure:: ./images/l2switch-hosts.png
- :alt: Hosts
-
- Hosts
-
-Checking STP status of each link
---------------------------------
-
-STP Status information is added to the Inventory data tree.
-
-- A status of "forwarding" means the link is active and packets are
- flowing on it.
-
-- A status of "discarding" means the link is inactive and packets are
- not sent over it.
-
-The STP status of a link can be checked through a browser or a REST
-Client.
-
-::
-
- http://10.194.126.91:8080/restconf/operational/opendaylight-inventory:nodes/node/openflow:1/node-connector/openflow:1:2
-
-.. figure:: ./images/l2switch-stp-status.png
- :alt: STP status
-
- STP status
-
-Miscellaneous mininet commands
-------------------------------
-
-::
-
- link s1 s2 down
-
-This will bring the link between switch1 (s1) and switch2 (s2) down
-
-::
-
- link s1 s2 up
-
-This will bring the link between switch1 (s1) and switch2 (s2) up
-
-::
-
- link s1 h1 down
-
-This will bring the link between switch1 (s1) and host1 (h1) down
-
+++ /dev/null
-.. _lacp-user-guide:
-
-Link Aggregation Control Protocol User Guide
-============================================
-
-Overview
---------
-
-This section contains information about how to use the LACP plugin
-project with OpenDaylight, including configurations.
-
-Link Aggregation Control Protocol Architecture
-----------------------------------------------
-
-The LACP Project within OpenDaylight implements Link Aggregation Control
-Protocol (LACP) as an MD-SAL service module and will be used to
-auto-discover and aggregate multiple links between an OpenDaylight
-controlled network and LACP-enabled endpoints or switches. The result is
-the creation of a logical channel, which represents the aggregation of
-the links. Link aggregation provides link resiliency and bandwidth
-aggregation. This implementation adheres to IEEE Ethernet specification
-`802.3ad <http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf>`__.
-
-Configuring Link Aggregation Control Protocol
----------------------------------------------
-
-This feature can be enabled in the Karaf console of the OpenDaylight
-Karaf distribution by issuing the following command:
-
-::
-
- feature:install odl-lacp-ui
-
-.. note::
-
- 1. Ensure that legacy (non-OpenFlow) switches are configured with
- LACP mode active with a long timeout to allow for the LACP plugin
- in OpenDaylight to respond to its messages.
-
- 2. Flows that want to take advantage of LACP-configured Link
- Aggregation Groups (LAGs) must explicitly use a OpenFlow group
- table entry created by the LACP plugin. The plugin only creates
- group table entries, it does not program any flows on its own.
-
-Administering or Managing Link Aggregation Control Protocol
------------------------------------------------------------
-
-LACP-discovered network inventory and network statistics can be viewed
-using the following REST APIs.
-
-1. List of aggregators available for a node:
-
- ::
-
- http://<ControllerIP>:8181/restconf/operational/opendaylight-inventory:nodes/node/<node-id>
-
- Aggregator information will appear within the ``<lacp-aggregators>``
- XML tag.
-
-2. To view only the information of an aggregator:
-
- ::
-
- http://<ControllerIP>:8181/restconf/operational/opendaylight-inventory:nodes/node/<node-id>/lacp-aggregators/<agg-id>
-
- The group ID associated with the aggregator can be found inside the
- ``<lag-groupid>`` XML tag.
-
- The group table entry information for the ``<lag-groupid>`` added for
- the aggregator is also available in the ``opendaylight-inventory``
- node database.
-
-3. To view physical port information.
-
- ::
-
- http://<ControllerIP>:8181/restconf/operational/opendaylight-inventory:nodes/node/<node-id>/node-connector/<node-connector-id>
-
- Ports that are associated with an aggregator will have the tag
- ``<lacp-agg-ref>`` updated with valid aggregator information.
-
-Tutorials
----------
-
-The below tutorial demonstrates LACP LAG creation for a sample mininet
-topology.
-
-Sample LACP Topology creation on Mininet
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-::
-
- sudo mn --controller=remote,ip=<Controller IP> --topo=linear,1 --switch ovsk,protocols=OpenFlow13
-
-The above command will create a virtual network consisting of a switch
-and a host. The switch will be connected to the controller.
-
-Once the topology is discovered, verify the presence of a flow entry
-with "dl\_type" set to "0x8809" to handle LACP packets using the below
-ovs-ofctl command:
-
-::
-
- ovs-ofctl -O OpenFlow13 dump-flows s1
- OFPST_FLOW reply (OF1.3) (xid=0x2):
- cookie=0x300000000000001e, duration=60.067s, table=0, n_packets=0, n_bytes=0, priority=5,dl_dst=01:80:c2:00:00:02,dl_type=0x8809 actions=CONTROLLER:65535
-
-Configure an additional link between the switch (s1) and host (h1) using
-the below command on mininet shell to aggregate 2 links:
-
-::
-
- mininet> py net.addLink(s1, net.get('h1'))
- mininet> py s1.attach('s1-eth2')
-
-The LACP module will listen for LACP control packets that are generated
-from legacy switch (non-OpenFlow enabled). In our example, host (h1)
-will act as a LACP packet generator. In order to generate the LACP
-control packets, a bond interface has to be created on the host (h1)
-with mode type set to LACP with long-timeout. To configure bond
-interface, create a new file bonding.conf under the /etc/modprobe.d/
-directory and insert the below lines in this new file:
-
-::
-
- alias bond0 bonding
- options bonding mode=4
-
-Here mode=4 is referred to LACP and the default timeout is set to long.
-
-Enable bond interface and associate both physical interface h1-eth0 &
-h1-eth1 as members of the bond interface on host (h1) using the below
-commands on the mininet shell:
-
-::
-
- mininet> py net.get('h1').cmd('modprobe bonding')
- mininet> py net.get('h1').cmd('ip link add bond0 type bond')
- mininet> py net.get('h1').cmd('ip link set bond0 address <bond-mac-address>')
- mininet> py net.get('h1').cmd('ip link set h1-eth0 down')
- mininet> py net.get('h1').cmd('ip link set h1-eth0 master bond0')
- mininet> py net.get('h1').cmd('ip link set h1-eth1 down')
- mininet> py net.get('h1').cmd('ip link set h1-eth1 master bond0')
- mininet> py net.get('h1').cmd('ip link set bond0 up')
-
-Once the bond0 interface is up, the host (h1) will send LACP packets to
-the switch (s1). The LACP Module will then create a LAG through exchange
-of LACP packets between the host (h1) and switch (s1). To view the bond
-interface output on the host (h1) side:
-
-::
-
- mininet> py net.get('h1').cmd('cat /proc/net/bonding/bond0')
- Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
- Bonding Mode: IEEE 802.3ad Dynamic link aggregation
- Transmit Hash Policy: layer2 (0)
- MII Status: up
- MII Polling Interval (ms): 100
- Up Delay (ms): 0
- Down Delay (ms): 0
- 802.3ad info
- LACP rate: slow
- Min links: 0
- Aggregator selection policy (ad_select): stable
- Active Aggregator Info:
- Aggregator ID: 1
- Number of ports: 2
- Actor Key: 33
- Partner Key: 27
- Partner Mac Address: 00:00:00:00:01:01
-
-::
-
- Slave Interface: h1-eth0
- MII Status: up
- Speed: 10000 Mbps
- Duplex: full
- Link Failure Count: 0
- Permanent HW addr: 00:00:00:00:00:11
- Aggregator ID: 1
- Slave queue ID: 0
-
-::
-
- Slave Interface: h1-eth1
- MII Status: up
- Speed: 10000 Mbps
- Duplex: full
- Link Failure Count: 0
- Permanent HW addr: 00:00:00:00:00:12
- Aggregator ID: 1
- Slave queue ID: 0
-
-A corresponding group table entry would be created on the OpenFlow
-switch (s1) with "type" set to "select" to perform the LAG
-functionality. To view the group entries:
-
-::
-
- mininet>ovs-ofctl -O Openflow13 dump-groups s1
- OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):
- group_id=60169,type=select,bucket=weight:0,actions=output:1,output:2
-
-To apply the LAG functionality on the switches, the flows should be
-configured with action set to GroupId instead of output port. A sample
-add-flow configuration with output action set to GroupId:
-
-::
-
- sudo ovs-ofctl -O Openflow13 add-flow s1 dl_type=0x0806,dl_src=SRC_MAC,dl_dst=DST_MAC,actions=group:60169
-
+++ /dev/null
-.. _lispflowmapping-user-guide:
-
-LISP Flow Mapping User Guide
-============================
-
-Overview
---------
-
-Locator/ID Separation Protocol
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-`Locator/ID Separation Protocol
-(LISP) <http://tools.ietf.org/html/rfc6830>`__ is a technology that
-provides a flexible map-and-encap framework that can be used for overlay
-network applications such as data center network virtualization and
-Network Function Virtualization (NFV).
-
-LISP provides the following name spaces:
-
-- `Endpoint Identifiers
- (EIDs) <http://tools.ietf.org/html/rfc6830#page-6>`__
-
-- `Routing Locators
- (RLOCs) <http://tools.ietf.org/html/rfc6830#section-3>`__
-
-In a virtualization environment EIDs can be viewed as virtual address
-space and RLOCs can be viewed as physical network address space.
-
-The LISP framework decouples network control plane from the forwarding
-plane by providing:
-
-- A data plane that specifies how the virtualized network addresses are
- encapsulated in addresses from the underlying physical network.
-
-- A control plane that stores the mapping of the virtual-to-physical
- address spaces, the associated forwarding policies and serves this
- information to the data plane on demand.
-
-Network programmability is achieved by programming forwarding policies
-such as transparent mobility, service chaining, and traffic engineering
-in the mapping system; where the data plane elements can fetch these
-policies on demand as new flows arrive. This chapter describes the LISP
-Flow Mapping project in OpenDaylight and how it can be used to enable
-advanced SDN and NFV use cases.
-
-LISP data plane Tunnel Routers are available at
-`OpenOverlayRouter.org <http://www.openoverlayrouter.org/>`__ in the open source community on
-the following platforms:
-
-- Linux
-
-- Android
-
-- OpenWRT
-
-For more details and support for LISP data plane software please visit
-`the OOR web site <http://www.openoverlayrouter.org/>`__.
-
-LISP Flow Mapping Service
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The LISP Flow Mapping service provides LISP Mapping System services.
-This includes LISP Map-Server and LISP Map-Resolver services to store
-and serve mapping data to data plane nodes as well as to OpenDaylight
-applications. Mapping data can include mapping of virtual addresses to
-physical network address where the virtual nodes are reachable or hosted
-at. Mapping data can also include a variety of routing policies
-including traffic engineering and load balancing. To leverage this
-service, OpenDaylight applications and services can use the northbound
-REST API to define the mappings and policies in the LISP Mapping
-Service. Data plane devices capable of LISP control protocol can
-leverage this service through a southbound LISP plugin. LISP-enabled
-devices must be configured to use this OpenDaylight service as their Map
-Server and/or Map Resolver.
-
-The southbound LISP plugin supports the LISP control protocol
-(Map-Register, Map-Request, Map-Reply messages), and can also be used to
-register mappings in the OpenDaylight mapping service.
-
-LISP Flow Mapping Architecture
-------------------------------
-
-The following figure shows the various LISP Flow Mapping modules.
-
-.. figure:: ./images/ODL_lfm_Be_component.jpg
- :alt: LISP Mapping Service Internal Architecture
-
- LISP Mapping Service Internal Architecture
-
-A brief description of each module is as follows:
-
-- **DAO (Data Access Object):** This layer separates the LISP logic
- from the database, so that we can separate the map server and map
- resolver from the specific implementation of the mapping database.
- Currently we have an implementation of this layer with an in-memory
- HashMap, but it can be switched to any other key/value store and you
- only need to implement the ILispDAO interface.
-
-- **Map Server:** This module processes the adding or registration of
- authentication tokens (keys) and mappings. For a detailed
- specification of LISP Map Server, see
- `LISP <http://tools.ietf.org/search/rfc6830>`__.
-
-- **Map Resolver:** This module receives and processes the mapping
- lookup queries and provides the mappings to requester. For a detailed
- specification of LISP Map Server, see
- `LISP <http://tools.ietf.org/search/rfc6830>`__.
-
-- **RPC/RESTCONF:** This is the auto-generated RESTCONF-based
- northbound API. This module enables defining key-EID associations as
- well as adding mapping information through the Map Server. Key-EID
- associations and mappings can also be queried via this API.
-
-- **Neutron:** This module implements the OpenDaylight Neutron Service
- APIs. It provides integration between the LISP service and the
- OpenDaylight Neutron service, and thus OpenStack.
-
-- **Java API:** The API module exposes the Map Server and Map Resolver
- capabilities via a Java API.
-
-- **LISP Proto:** This module includes LISP protocol dependent data
- types and associated processing.
-
-- **In Memory DB:** This module includes the in memory database
- implementation of the mapping service.
-
-- **LISP Southbound Plugin:** This plugin enables data plane devices
- that support LISP control plane protocol (see
- `LISP <http://tools.ietf.org/search/rfc6830>`__) to register and
- query mappings to the LISP Flow Mapping via the LISP control plane
- protocol.
-
-.. _lfm_config:
-
-Configuring LISP Flow Mapping
------------------------------
-
-In order to use the LISP mapping service for registering EID to RLOC
-mappings from northbound or southbound, keys have to be defined for the
-EID prefixes first. Once a key is defined for an EID prefix, it can be
-used to add mappings for that EID prefix multiple times. If the service
-is going to be used to process Map-Register messages from the southbound
-LISP plugin, the same key must be used by the data plane device to
-create the authentication data in the Map-Register messages for the
-associated EID prefix.
-
-The ``etc/custom.properties`` file in the Karaf distribution allows
-configuration of several OpenDaylight parameters. The LISP service has
-the following properties that can be adjusted:
-
-**lisp.smr** (default: *true*)
- Enables/disables the `Solicit-Map-Request
- (SMR) <http://tools.ietf.org/html/rfc6830#section-6.6.2>`__
- functionality. SMR is a method to notify changes in an EID-to-RLOC
- mapping to "subscribers". The LISP service considers all
- Map-Request’s source RLOC as a subscriber to the requested EID
- prefix, and will send an SMR control message to that RLOC if the
- mapping changes.
-
-**lisp.elpPolicy** (default: *default*)
- Configures how to build a Map-Reply southbound message from a
- mapping containing an Explicit Locator Path (ELP) RLOC. It is used
- for compatibility with dataplane devices that don’t understand the
- ELP LCAF format. The *default* setting doesn’t alter the mapping,
- returning all RLOCs unmodified. The *both* setting adds a new RLOC
- to the mapping, with a lower priority than the ELP, that is the next
- hop in the service chain. To determine the next hop, it searches the
- source RLOC of the Map-Request in the ELP, and chooses the next hop,
- if it exists, otherwise it chooses the first hop. The *replace*
- setting adds a new RLOC using the same algorithm as the *both*
- setting, but using the origin priority of the ELP RLOC, which is
- removed from the mapping.
-
-**lisp.lookupPolicy** (default: *northboundFirst*)
- Configures the mapping lookup algorithm. When set to
- *northboundFirst* mappings programmed through the northbound API
- will take precedence. If no northbound programmed mappings exist,
- then the mapping service will return mappings registered through the
- southbound plugin, if any exists. When set to
- *northboundAndSouthbound* the mapping programmed by the northbound
- is returned, updated by the up/down status of these mappings as
- reported by the southbound (if existing).
-
-**lisp.mappingMerge** (default: *false*)
- Configures the merge policy on the southbound registrations through
- the LISP SB Plugin. When set to *false*, only the latest mapping
- registered through the SB plugin is valid in the southbound mapping
- database, independent of which device it came from. When set to
- *true*, mappings for the same EID registered by different devices
- are merged together and a union of the locators is maintained as the
- valid mapping for that EID.
-
-Textual Conventions for LISP Address Formats
---------------------------------------------
-
-In addition to the more common IPv4, IPv6 and MAC address data types,
-the LISP control plane supports arbitrary `Address Family
-Identifiers <http://www.iana.org/assignments/address-family-numbers>`__
-assigned by IANA, and in addition to those the `LISP Canoncal Address
-Format (LCAF) <https://tools.ietf.org/html/draft-ietf-lisp-lcaf>`__.
-
-The LISP Flow Mapping project in OpenDaylight implements support for
-many of these different address formats, the full list being summarized
-in the following table. While some of the address formats have well
-defined and widely used textual representation, many don’t. It became
-necessary to define a convention to use for text rendering of all
-implemented address types in logs, URLs, input fields, etc. The below
-table lists the supported formats, along with their AFI number and LCAF
-type, including the prefix used for disambiguation of potential overlap,
-and examples output.
-
-+------------------+----------+----------+----------+----------------------------------+
-| Name | AFI | LCAF | Prefix | Text Rendering |
-+==================+==========+==========+==========+==================================+
-| **No Address** | 0 | - | no: | No Address Present |
-+------------------+----------+----------+----------+----------------------------------+
-| **IPv4 Prefix** | 1 | - | ipv4: | 192.0.2.0/24 |
-+------------------+----------+----------+----------+----------------------------------+
-| **IPv6 Prefix** | 2 | - | ipv6: | 2001:db8::/32 |
-+------------------+----------+----------+----------+----------------------------------+
-| **MAC Address** | 16389 | - | mac: | 00:00:5E:00:53:00 |
-+------------------+----------+----------+----------+----------------------------------+
-| **Distinguished | 17 | - | dn: | stringAsIs |
-| Name** | | | | |
-+------------------+----------+----------+----------+----------------------------------+
-| **AS Number** | 18 | - | as: | AS64500 |
-+------------------+----------+----------+----------+----------------------------------+
-| **AFI List** | 16387 | 1 | list: | {192.0.2.1,192.0.2.2,2001:db8::1 |
-| | | | | } |
-+------------------+----------+----------+----------+----------------------------------+
-| **Instance ID** | 16387 | 2 | - | [223] 192.0.2.0/24 |
-+------------------+----------+----------+----------+----------------------------------+
-| **Application | 16387 | 4 | appdata: | 192.0.2.1!128!17!80-81!6667-7000 |
-| Data** | | | | |
-+------------------+----------+----------+----------+----------------------------------+
-| **Explicit | 16387 | 10 | elp: | {192.0.2.1→192.0.2.2\|lps→192.0. |
-| Locator Path** | | | | 2.3} |
-+------------------+----------+----------+----------+----------------------------------+
-| **Source/Destina | 16387 | 12 | srcdst: | 192.0.2.1/32\|192.0.2.2/32 |
-| tion | | | | |
-| Key** | | | | |
-+------------------+----------+----------+----------+----------------------------------+
-| **Key/Value | 16387 | 15 | kv: | 192.0.2.1⇒192.0.2.2 |
-| Address Pair** | | | | |
-+------------------+----------+----------+----------+----------------------------------+
-| **Service Path** | 16387 | N/A | sp: | 42(3) |
-+------------------+----------+----------+----------+----------------------------------+
-
-Table: LISP Address Formats
-
-Please note that the forward slash character ``/`` typically separating
-IPv4 and IPv6 addresses from the mask length is transformed into ``%2f``
-when used in a URL.
-
-Karaf commands
---------------
-
-In this section we will discuss two types of Karaf commands: built-in,
-and LISP specific. Some built-in commands are quite useful, and are
-needed for the tutorial, so they will be discussed here. A reference of
-all LISP specific commands, added by the LISP Flow Mapping project is
-also included. They are useful mostly for debugging.
-
-Useful built-in commands
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-``help``
- Lists all available command, with a short description of each.
-
-``help <command_name>``
- Show detailed help about a specific command.
-
-``feature:list [-i]``
- Show all locally available features in the Karaf container. The
- ``-i`` option lists only features that are currently installed. It
- is possible to use ``| grep`` to filter the output (for all
- commands, not just this one).
-
-``feature:install <feature_name>``
- Install feature ``feature_name``.
-
-``log:set <level> <class>``
- Set the log level for ``class`` to ``level``. The default log level
- for all classes is INFO. For debugging, or learning about LISP
- internals it is useful to run
- ``log:set TRACE org.opendaylight.lispflowmapping`` right after Karaf
- starts up.
-
-``log:display``
- Outputs the log file to the console, and returns control to the
- user.
-
-``log:tail``
- Continuously shows log output, requires ``Ctrl+C`` to return to the
- console.
-
-LISP specific commands
-~~~~~~~~~~~~~~~~~~~~~~
-
-The available lisp commands can always be obtained by
-``help mappingservice``. Currently they are:
-
-``mappingservice:addkey``
- Add the default password ``password`` for the IPv4 EID prefix
- 0.0.0.0/0 (all addresses). This is useful when experimenting with
- southbound devices, and using the REST interface would be combersome
- for whatever reason.
-
-``mappingservice:mappings``
- Show the list of all mappings stored in the internal non-persistent
- data store (the DAO), listing the full data structure. The output is
- not human friendly, but can be used for debugging.
-
-LISP Flow Mapping Karaf Features
---------------------------------
-
-LISP Flow Mapping has the following Karaf features that can be installed
-from the Karaf console:
-
-``odl-lispflowmapping-msmr``
- This includes the core features required to use the LISP Flow
- Mapping Service such as mapping service and the LISP southbound
- plugin.
-
-``odl-lispflowmapping-ui``
- This includes the GUI module for the LISP Mapping Service.
-
-``odl-lispflowmapping-neutron``
- This is the experimental Neutron provider module for LISP mapping
- service.
-
-Tutorials
----------
-
-This section provides a tutorial demonstrating various features in this
-service. We have included tutorials using two forwarding platforms:
-
-1. Using `Open Overlay Router (OOR) <https://github.com/OpenOverlayRouter/oor#overview>`__
-
-2. Using `FD.io <https://wiki.fd.io/view/ONE>`__
-
-Both have different approaches to create the overlay but ultimately do the
-same job. Details of both approaches have been explained below.
-
-Creating a LISP overlay with OOR
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This section provides instructions to set up a LISP network of three
-nodes (one "client" node and two "server" nodes) using OOR as data
-plane LISP nodes and the LISP Flow Mapping project from OpenDaylight as
-the LISP programmable mapping system for the LISP network.
-
-Overview
-^^^^^^^^
-
-The steps shown below will demonstrate setting up a LISP network between
-a client and two servers, then performing a failover between the two
-"server" nodes.
-
-Prerequisites
-^^^^^^^^^^^^^
-
-- `The OpenDaylight Karaf Distribution
- <https://www.opendaylight.org/downloads>`_
-
-.. _instructions:
-
-- **The Postman Chrome App**: the most convenient way to follow along
- this tutorial is to use the `Postman
- App <https://www.getpostman.com/apps>`__
- to edit and send the requests. The project git repository hosts a
- collection of the requests that are used in this tutorial in the
- ``resources/tutorial/OOR/Beryllium_Tutorial.json.postman_collection``
- file. You can import this file to Postman by clicking *Import* at the
- top, choosing *Download from link* and then entering the following
- URL:
- `<https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=blob_plain;f=resources/tutorial/OOR/Beryllium_Tutorial.json.postman_collection;hb=refs/heads/stable/fluorine>`__.
- Alternatively, you can save the file on your machine, or if you have
- the repository checked out, you can import from there. You will need
- to create a new Postman Environment and define some variables within:
- ``controllerHost`` set to the hostname or IP address of the machine
- running the OpenDaylight instance, and ``restconfPort`` to 8181, if you didn’t
- modify the default controller settings.
-
-- **OOR version 1.0 or later** The README.md lists the dependencies needed
- to build it from source.
-
-- **A virtualization platform**
-
-Target Environment
-^^^^^^^^^^^^^^^^^^
-
-The three LISP data plane nodes and the LISP mapping system are assumed
-to be running in Linux virtual machines, which have the ``eth0``
-interface in NAT mode to allow outside internet access and ``eth1``
-connected to a host-only network, with the following IP addresses
-(please adjust configuration files, JSON examples, etc. accordingly if
-you’re using another addressing scheme):
-
-+--------------------------+--------------------------+--------------------------+
-| Node | Node Type | IP Address |
-+==========================+==========================+==========================+
-| **controller** | OpenDaylight | 192.168.16.11 |
-+--------------------------+--------------------------+--------------------------+
-| **client** | OOR | 192.168.16.30 |
-+--------------------------+--------------------------+--------------------------+
-| **server1** | OOR | 192.168.16.31 |
-+--------------------------+--------------------------+--------------------------+
-| **server2** | OOR | 192.168.16.32 |
-+--------------------------+--------------------------+--------------------------+
-| **service-node** | OOR | 192.168.16.33 |
-+--------------------------+--------------------------+--------------------------+
-
-Table: Nodes in the tutorial
-
-The figure below gives a sketch of network topology that will be used in the tutorial.
-
-.. figure:: ./images/tutorial_architecture_diagram.png
- :alt: Network architecture of the tutorial
-
-In LISP terminology **client**, **server1** and **server2** are mobile nodes (MN in OOR),
-**controller** is a MS/MR and **service-node** is a RTR.
-
-Instructions
-^^^^^^^^^^^^
-
-The below steps use the command line tool cURL to talk to the LISP Flow
-Mapping RPC REST API. This is so that you can see the actual request
-URLs and body content on the page.
-
-1. Install and run the OpenDaylight distribution on the controller VM.
- Please follow the general OpenDaylight Installation Guide
- for this step. Once the OpenDaylight controller is running install
- the *odl-lispflowmapping-msmr* feature from the Karaf CLI:
-
- ::
-
- feature:install odl-lispflowmapping-msmr
-
- It takes quite a while to load and initialize all features and their
- dependencies. It’s worth running the command ``log:tail`` in the
- Karaf console to see when the log output is winding down, and
- continue with the tutorial after that.
-
-2. Install OOR on the **client**, **server1**, **server2**, and
- **service-node** VMs following the installation instructions `from
- the OOR README
- file <https://github.com/OpenOverlayRouter/oor#software-prerequisites>`__.
-
-3. Configure the OOR installations from the previous step. Take a look
- at the ``oor.conf.example`` to get a general idea of the structure
- of the conf file. First, check if the file ``/etc/oor.conf`` exists.
- If the file doesn't exist, create the file ``/etc/oor.conf``. Set the
- EID in ``/etc/oor.conf`` file from the IP address space selected
- for your virtual/LISP network. In this tutorial the EID of the
- **client** is set to 1.1.1.1/32, and that of **server1** and
- **server2** to 2.2.2.2/32.
-
-4. Set the RLOC interface to ``eth1`` in each ``oor.conf`` file. LISP
- will determine the RLOC (IP address of the corresponding VM) based
- on this interface.
-
-5. Set the Map-Resolver address to the IP address of the
- **controller**, and on the **client** the Map-Server too. On
- **server1** and **server2** remove the Map-Server configuration, so
- that it doesn’t interfere with the mappings on the controller, since
- we’re going to program them manually.
-
-6. Modify the "key" parameter in each ``oor.conf`` file to a
- key/password of your choice (*password* in this tutorial).
-
- .. note::
-
- The ``resources/tutorial/OOR`` directory in the project git repository
- has the files used in the tutorial `checked in
- <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial/OOR;hb=refs/heads/stable/fluorine>`_,
- so you can just copy the files to ``/etc/oor.conf`` on the respective
- VMs. You will also find the JSON files referenced below in the same
- directory.
-
-7. Define a key and EID prefix association in OpenDaylight using the
- RPC REST API for the **client** EID (1.1.1.1/32) to allow
- registration from the southbound. Since the mappings for the server
- EID will be configured from the REST API, no such association is
- necessary. Run the below command on the **controller** (or any
- machine that can reach **controller**, by replacing *localhost* with
- the IP address of **controller**).
-
- ::
-
- curl -u "admin":"admin" -H "Content-type: application/json" -X PUT \
- http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/authentication-key/ipv4:1.1.1.1%2f32/ \
- --data @add-key.json
-
- where the content of the *add-key.json* file is the following:
-
- .. code:: json
-
- {
- "authentication-key": {
- "eid-uri": "ipv4:1.1.1.1/32",
- "eid": {
- "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
- "ipv4-prefix": "1.1.1.1/32"
- },
- "mapping-authkey": {
- "key-string": "password",
- "key-type": 1
- }
- }
- }
-
-8. Verify that the key is added properly by requesting the following
- URL:
-
- ::
-
- curl -u "admin":"admin" -H "Content-type: application/json" -X GET \
- http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/authentication-key/ipv4:1.1.1.1%2f32/
-
- The output the above invocation should look like this:
-
- .. code:: json
-
- {
- "authentication-key":[
- {
- "eid-uri":"ipv4:1.1.1.1/32",
- "eid":{
- "ipv4-prefix":"1.1.1.1/32",
- "address-type":"ietf-lisp-address-types:ipv4-prefix-afi"
- },
- "mapping-authkey":{
- "key-string":"password"
- ,"key-type":1
- }
- }
- ]
- }
-
-9. Run the ``oor`` OOR daemon on all VMs:
-
- ::
-
- oor -f /etc/oor.conf
-
- For more information on accessing OOR logs, take a look at
- `OOR README <https://github.com/OpenOverlayRouter/oor#readme>`__
-10. The **client** OOR node should now register its EID-to-RLOC
- mapping in OpenDaylight. To verify you can lookup the corresponding
- EIDs via the REST API
-
- ::
-
- curl -u "admin":"admin" -H "Content-type: application/json" -X GET \
- http://localhost:8181/restconf/operational/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:1.1.1.1%2f32/southbound/
-
- An alternative way for retrieving mappings from OpenDaylight using the
- southbound interface is using the
- `lig <https://github.com/davidmeyer/lig>`__ open source tool.
-
-11. Register the EID-to-RLOC mapping of the server EID 2.2.2.2/32 to the
- controller, pointing to **server1** and **server2** with a higher
- priority for **server1**
-
- ::
-
- curl -u "admin":"admin" -H "Content-type: application/json" -X PUT \
- http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:2.2.2.2%2f32/northbound/ \
- --data @mapping.json
-
- where the *mapping.json* file looks like this:
-
- .. code:: json
-
- {
- "mapping": {
- "eid-uri": "ipv4:2.2.2.2/32",
- "origin": "northbound",
- "mapping-record": {
- "recordTtl": 1440,
- "action": "NoAction",
- "authoritative": true,
- "eid": {
- "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
- "ipv4-prefix": "2.2.2.2/32"
- },
- "LocatorRecord": [
- {
- "locator-id": "server1",
- "priority": 1,
- "weight": 1,
- "multicastPriority": 255,
- "multicastWeight": 0,
- "localLocator": true,
- "rlocProbed": false,
- "routed": true,
- "rloc": {
- "address-type": "ietf-lisp-address-types:ipv4-afi",
- "ipv4": "192.168.16.31"
- }
- },
- {
- "locator-id": "server2",
- "priority": 2,
- "weight": 1,
- "multicastPriority": 255,
- "multicastWeight": 0,
- "localLocator": true,
- "rlocProbed": false,
- "routed": true,
- "rloc": {
- "address-type": "ietf-lisp-address-types:ipv4-afi",
- "ipv4": "192.168.16.32"
- }
- }
- ]
- }
- }
- }
-
- Here the priority of the second RLOC (192.168.16.32 - **server2**)
- is 2, a higher numeric value than the priority of 192.168.16.31,
- which is 1. This policy is saying that **server1** is preferred to
- **server2** for reaching EID 2.2.2.2/32. Note that lower priority
- value has higher preference in LISP.
-
-12. Verify the correct registration of the 2.2.2.2/32 EID:
-
- ::
-
- curl -u "admin":"admin" -H "Content-type: application/json" -X GET \
- http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:2.2.2.2%2f32/northbound/
-
-13. Now the LISP network is up. To verify, log into the **client** VM
- and ping the server EID:
-
- ::
-
- ping 2.2.2.2
-
-14. Let’s test fail-over now. Suppose you had a service on **server1**
- which became unavailable, but **server1** itself is still reachable.
- LISP will not automatically fail over, even if the mapping for
- 2.2.2.2/32 has two locators, since both locators are still reachable
- and uses the one with the higher priority (lowest priority value).
- To force a failover, we need to set the priority of **server2** to a
- lower value. Using the file mapping.json above, swap the priority
- values between the two locators (lines 14 and 28 in *mapping.json*)
- and repeat the request from step 11. You can also repeat step 12 to
- see if the mapping is correctly registered. If you leave the ping
- on, and monitor the traffic using wireshark, you can see that the
- ping traffic to 2.2.2.2 will be diverted from the **server1** RLOC
- to the **server2** RLOC.
-
- With the default OpenDaylight configuration the failover should be
- near instantaneous (we observed 3 lost pings in the worst case),
- because of the LISP `Solicit-Map-Request (SMR)
- mechanism <http://tools.ietf.org/html/rfc6830#section-6.6.2>`__ that
- can ask a LISP data plane element to update its mapping for a
- certain EID (enabled by default). It is controlled by the
- ``lisp.smr`` variable in ``etc/custom.porperties``. When enabled,
- any mapping change from the RPC interface will trigger an SMR packet
- to all data plane elements that have requested the mapping in the
- last 24 hours (this value was chosen because it’s the default TTL of
- Cisco IOS xTR mapping registrations). If disabled, ITRs keep their
- mappings until the TTL specified in the Map-Reply expires.
-
-15. To add a service chain into the path from the client to the server,
- we can use an Explicit Locator Path, specifying the **service-node**
- as the first hop and **server1** (or **server2**) as the second hop.
- The following will achieve that:
-
- ::
-
- curl -u "admin":"admin" -H "Content-type: application/json" -X PUT \
- http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:2.2.2.2%2f32/northbound/ \
- --data @elp.json
-
- where the *elp.json* file is as follows:
-
- .. code:: json
-
- {
- "mapping": {
- "eid-uri": "ipv4:2.2.2.2/32",
- "origin": "northbound",
- "mapping-record": {
- "recordTtl": 1440,
- "action": "NoAction",
- "authoritative": true,
- "eid": {
- "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
- "ipv4-prefix": "2.2.2.2/32"
- },
- "LocatorRecord": [
- {
- "locator-id": "ELP",
- "priority": 1,
- "weight": 1,
- "multicastPriority": 255,
- "multicastWeight": 0,
- "localLocator": true,
- "rlocProbed": false,
- "routed": true,
- "rloc": {
- "address-type": "ietf-lisp-address-types:explicit-locator-path-lcaf",
- "explicit-locator-path": {
- "hop": [
- {
- "hop-id": "service-node",
- "address": "192.168.16.33",
- "lrs-bits": "strict"
- },
- {
- "hop-id": "server1",
- "address": "192.168.16.31",
- "lrs-bits": "strict"
- }
- ]
- }
- }
- }
- ]
- }
- }
- }
-
- After the mapping for 2.2.2.2/32 is updated with the above, the ICMP
- traffic from **client** to **server1** will flow through the
- **service-node**. You can confirm this in the OOR logs, or by
- sniffing the traffic on either the **service-node** or **server1**.
- Note that service chains are unidirectional, so unless another ELP
- mapping is added for the return traffic, packets will go from
- **server1** to **client** directly.
-
-16. Suppose the **service-node** is actually a firewall, and traffic is
- diverted there to support access control lists (ACLs). In this
- tutorial that can be emulated by using ``iptables`` firewall rules
- in the **service-node** VM. To deny traffic on the service chain
- defined above, the following rule can be added:
-
- ::
-
- iptables -A OUTPUT --dst 192.168.16.31 -j DROP
-
- The ping from the **client** should now have stopped.
-
- In this case the ACL is done on the destination RLOC. There is an
- effort underway in the OOR community to allow filtering on EIDs,
- which is the more logical place to apply ACLs.
-
-17. To delete the rule and restore connectivity on the service chain,
- delete the ACL by issuing the following command:
-
- ::
-
- iptables -D OUTPUT --dst 192.168.16.31 -j DROP
-
- which should restore connectivity.
-
-
-Creating a simple LISP overlay with FD.io
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-In this section, we use the Overlay Network Engine (ONE) project in FD.io
-to facilitate fully scripted setup and testing of a LISP/VXLAN-GPE network.
-Overlay Network Engine (ONE) is a `FD.io <https://fd.io/>`__ project that enables programmable
-dynamic software defined overlays. Details about this project can be
-found in `ONE wiki <https://wiki.fd.io/view/ONE>`__.
-
-The steps shown below will demonstrate setting up a LISP network between
-a client and a server using VPP. We demonstrate how to use VPP lite to
-build a IP4 LISP overlay on an Ubuntu host using namespaces and af_packet
-interfaces. All configuration files used in the tutorials can be found
-`here <https://gerrit.fd.io/r/gitweb?p=one.git;a=tree;f=tutorial>`__.
-
-Prerequisites
-^^^^^^^^^^^^^
-
-- `The OpenDaylight Karaf Distribution
- <https://www.opendaylight.org/downloads>`_
-
-- **The Postman Chrome App**: Please follow the instructions_ and import
- postman collection from the following URL: `<https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=blob;f=resources/tutorial/FD_io/lfm_vpp.postman_collection.json;hb=refs/heads/stable/fluorine>`__.
-
-- **Vagrant** (optional): Download it from `Vagrant website <https://www.vagrantup.com/downloads.html>`__
- and follow the setup instructions.
-
-Target Environment
-^^^^^^^^^^^^^^^^^^
-
-Unlike the case with OOR, we use network namespace functionality of Linux
-to create the overlay in this case. The following table contains ip addresses
-of nodes in the overlay topology used in the tutorial. Our objective will be to
-create this topology and be able to ping from client to server through an
-intermediary hop, **service node**, which is a ``rtr node`` providing the
-service of re-encapsulation. So, all the packets from client to server
-will be through this **service node**.
-
-+--------------------------+--------------------------+--------------------------+
-| Node | Node Type | IP Address |
-+==========================+==========================+==========================+
-| **controller** | OpenDaylight | 6.0.3.100 |
-+--------------------------+--------------------------+--------------------------+
-| **client** | VPP | 6.0.2.2 |
-+--------------------------+--------------------------+--------------------------+
-| **server** | VPP | 6.0.4.4 |
-+--------------------------+--------------------------+--------------------------+
-| **service node** | VPP | 6.0.3.3 |
-+--------------------------+--------------------------+--------------------------+
-
-Table: Nodes in the tutorial
-
-The figure below gives a sketch of network topology that will be used in the tutorial.
-
-.. figure:: ./images/one_ODL_architecture.png
- :alt: Network architecture of the tutorial for FD.io
-
-Instructions
-^^^^^^^^^^^^
-
-Follow the instructions below sequentially.
-
-1. Pull the VPP code anonymously using:
- ::
-
- git clone https://gerrit.fd.io/r/vpp
-
-2. Then, use the vagrant file from repository to build virtual machine
- with proper environment.
- ::
-
- cd vpp/build-root/vagrant/
- vagrant up
- vagrant ssh
-
-3. In case there is any error from ``vagrant up``, try ``vargant ssh``. if
- it works, no worries. If it still doesn't work, you can try any Ubuntu virtual
- machine. Or sometimes there is an issue with the Vagrant properly copying
- the VPP repo code from the host VM after the first installation. In that
- case ``/vpp`` doesn't exist. In both cases, follow the instructions
- from below.
-
- 1. Clone the code in ``/`` directory. So, the codes will be in ``/vpp``.
-
- 2. Run the following commands:
- ::
-
- cd /vpp/build-root
- make distclean
- ./bootstrap.sh
- make V=0 PLATFORM=vpp TAG=vpp install-deb
- sudo dpkg -i /vpp/build-root/*.deb
-
- Alternative and more detailed build instructions can be found in
- `VPP's wiki <https://wiki.fd.io/view/VPP/Build,_install,_and_test_images>`__
-4. By now, you should have a Ubuntu VM with VPP repository in ``/vpp``
- with ``sudo`` access. Now, we need VPP Lite build. The following commands
- builds VPP Lite.
- ::
-
- cd /vpp
- export PLATFORM=vpp_lite
- make build
-
- Successful build create the binary in ``/vpp/build-root/install-vpp_lite_debug-native/vpp/bin``
-
-5. Install bridge-utils and ethtool if needed by using following commands:
- ::
-
- sudo apt-get install bridge-utils ethtool
-
-6. Now, install and run OpenDaylight on the VM. Please follow the general
- OpenDaylight Installation Guide for this step from :ref:`install_odl`.
- Before running OpenDaylight, we need to change the configuration for RTR
- to work. Update ``etc/custom.properties`` with the ``lisp.elpPolicy`` to
- be replace.
- ::
-
- lisp.elpPolicy = replace
-
- Then, run OpenDaylight. For details regarding configuring LISP
- Flow Mapping, please take a look at :ref:`lfm_config`.
- Once the OpenDaylight controller is running install the *odl-lispflowmapping-msmr*
- feature from the Karaf CLI:
-
- ::
-
- feature:install odl-lispflowmapping-msmr
-
- It may take quite a while to load and initialize all features and their
- dependencies. It’s worth running the command ``log:tail`` in the
- Karaf console to see when the log output is winding down, and
- continue with the tutorial after that.
-
-7. For setting up VPP, get the files from ``resources/tutorial/FD_io``
- folder of the lispflowmapping repo. The files can also be found `here
- <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial/FD_io;hb=refs/heads/stable/fluorine>`__.
- Copy the ``vpp1.config``, ``vpp2.config`` and ``rtr.config`` files in
- ``/etc/vpp/lite/``.
-
-8. In this example, VPP doesn't make any southbound map registers to OpenDaylight.
- So, we add the mappings directly from northbound. For that, we need
- to add the mappings to OpenDaylight via RESTCONF API.
-
- Register EID-to-RLOC mapping of the Client EID 6.0.2.0/24.
- ::
-
- curl -u "admin":"admin" -H "Content-type: application/json" -X PUT \
- http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:6.0.2.0%2f24/northbound/ \
- --data @epl1.json
-
- Content of epl1.json:
-
- .. code:: json
-
- {
- "mapping": {
- "eid-uri": "ipv4:6.0.2.0/24",
- "origin": "northbound",
- "mapping-record": {
- "recordTtl": 1440,
- "action": "NoAction",
- "authoritative": true,
- "eid": {
- "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
- "ipv4-prefix": "6.0.2.0/24"
- },
- "LocatorRecord": [
- {
- "locator-id": "ELP",
- "priority": 1,
- "weight": 1,
- "multicastPriority": 255,
- "multicastWeight": 0,
- "localLocator": true,
- "rlocProbed": false,
- "routed": false,
- "rloc": {
- "address-type": "ietf-lisp-address-types:explicit-locator-path-lcaf",
- "explicit-locator-path": {
- "hop": [
- {
- "hop-id": "Hop 1",
- "address": "6.0.3.3",
- "lrs-bits": "lookup rloc-probe strict"
- },
- {
- "hop-id": "Hop 2",
- "address": "6.0.3.1",
- "lrs-bits": "lookup strict"
- }
- ]
- }
- }
- }
- ]
- }
- }
- }
-
-
- Similarly add EID-to-RLOC mapping of the Server EID 6.0.4.0/24.
- ::
-
- curl -u "admin":"admin" -H "Content-type: application/json" -X PUT \
- http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:6.0.4.0%2f24/northbound/ \
- --data @epl2.json
-
- Content of elp2.json:
-
- .. code:: json
-
- {
- "mapping": {
- "eid-uri": "ipv4:6.0.4.0/24",
- "origin": "northbound",
- "mapping-record": {
- "recordTtl": 1440,
- "action": "NoAction",
- "authoritative": true,
- "eid": {
- "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
- "ipv4-prefix": "6.0.4.0/24"
- },
- "LocatorRecord": [
- {
- "locator-id": "ELP",
- "priority": 1,
- "weight": 1,
- "multicastPriority": 255,
- "multicastWeight": 0,
- "localLocator": true,
- "rlocProbed": false,
- "routed": false,
- "rloc": {
- "address-type": "ietf-lisp-address-types:explicit-locator-path-lcaf",
- "explicit-locator-path": {
- "hop": [
- {
- "hop-id": "Hop 1",
- "address": "6.0.3.3",
- "lrs-bits": "lookup rloc-probe strict"
- },
- {
- "hop-id": "Hop 2",
- "address": "6.0.3.2",
- "lrs-bits": "lookup strict"
- }
- ]
- }
- }
- }
- ]
- }
- }
- }
-
- The JSON files regarding these can be found in `here
- <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial/FD_io;hb=refs/heads/stable/fluorine>`__.
- Even though there is no southbound registration for mapping to OpenDaylight, using
- northbound policy we can specify mappings, when Client requests for
- the Server eid, Client gets a reply from OpenDaylight.
-
-9. Assuming all files have been created and OpenDaylight has been configured as
- explained above, execute the host script you've created or the ``topology_setup.sh``
- script from `here <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial/FD_io;hb=refs/heads/stable/fluorine>`__.
-
-10. If all goes well, you can now test connectivity between the namespaces with:
- ::
-
- sudo ip netns exec vpp-ns1 ping 6.0.4.4
-
-11. Traffic and control plane message exchanges can be checked with a wireshark
- listening on the odl interface.
-12. .. important:: Delete the topology by running the ``topology_setup.sh`` with ``clean`` argument.
- ::
-
- sudo ./topology_setup.sh clean
-
-Creating a LISP overlay with Cisco IOS-XE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This section describes how to create a simple LISP overlay using the Cisco
-IOS-XE network operating system as the data plane software running on the
-`Cisco CSR 1000v Series Cloud Services Router
-<http://www.cisco.com/c/en/us/support/routers/cloud-services-router-1000v/model.html>`_.
-
-Prerequisites
-^^^^^^^^^^^^^
-
-- `The OpenDaylight Karaf Distribution**
- <https://www.opendaylight.org/downloads>`_
-
-- `CSR1Kv image with Cisco IOS-XE version 03.13.00.S or later
- <http://www.cisco.com/c/en/us/support/routers/cloud-services-router-1000v/model.html#~tab-downloads>`_;
- the instructions have been tested on version 03.15.00.S.
-
-- **A virtualization platform** supported by CSR1Kv images (VMware ESXi,
- Citrix XenServer, KVM, and Microsoft Hyper-V).
-
-Target Environment
-^^^^^^^^^^^^^^^^^^
-
-The CSR1Kv images are configured with one management interface
-(``GigabitEthernet1``), and another interface (``GigabitEthernet2``) connected
-to a host-only network on the virtualization platform, while the LISP mapping
-system is assumed to be running in a Linux virtual machine, which has the
-``eth0`` interface in NAT mode to allow outside internet access and ``eth1``
-connected to the host-only network, with the following IP addresses (please
-adjust configuration files, JSON examples, etc. accordingly if you’re using
-another addressing scheme):
-
-+--------------------------+--------------------------+--------------------------+
-| Node | Node Type | IP Address |
-+==========================+==========================+==========================+
-| **controller** | OpenDaylight | 192.168.16.11 |
-+--------------------------+--------------------------+--------------------------+
-| **client** | CSR1Kv | 192.168.16.30 |
-+--------------------------+--------------------------+--------------------------+
-| **server** | CSR1Kv | 192.168.16.31 |
-+--------------------------+--------------------------+--------------------------+
-
-Table: Nodes in the tutorial
-
-The scenario and EID allocation is the same as the OOR scenario, except that
-there is no **server2** and **service-node** (for now).
-
-Before this tutorial can be followed, basic connectivity between the Linux VM
-and the CSRs should work on the host-only network.
-
-Instructions
-^^^^^^^^^^^^
-
-The below steps use the command line tool cURL to talk to the LISP Flow
-Mapping RPC REST API. This is so that you can see the actual request
-URLs and body content on the page. The easy way is to just use Postman.
-
-1. Install and run the OpenDaylight distribution on the controller VM.
- Please follow the general OpenDaylight Installation Guide from
- :ref:`install_odl` for this step. Once the OpenDaylight controller is
- running install the *odl-lispflowmapping-msmr* feature from the Karaf CLI:
-
- ::
-
- feature:install odl-lispflowmapping-msmr
-
- It takes quite a while to load and initialize all features and their
- dependencies. It’s worth running the command ``log:tail`` in the
- Karaf console to see when the log output is winding down, and
- continue with the tutorial after that.
-
-2. Create the **client** and **server** VMs following the installation
- instructions from the `CSR1Kv Configuration Guide
- <http://www.cisco.com/c/en/us/td/docs/routers/csr1000/software/configuration/b_CSR1000v_Configuration_Guide.html>`_.
-
-3. Define a key and EID prefix association in OpenDaylight using the RPC REST
- API for the **client** and **server** EIDs (1.1.1.1/32 and 2.2.2.2/32
- respectively) to allow registration from the southbound. Run the below
- command on the **controller** (or any machine that can reach
- **controller**, by replacing *localhost* with the IP address of
- **controller**).
-
- ::
-
- curl -u "admin":"admin" -H "Content-type: application/json" -X PUT \
- http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/authentication-key/ipv4:1.1.1.1%2f32/ \
- --data @add-key.json
-
- where the content of the *add-key.json* file is the following:
-
- .. code:: json
-
- {
- "authentication-key": {
- "eid-uri": "ipv4:1.1.1.1/32",
- "eid": {
- "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
- "ipv4-prefix": "1.1.1.1/32"
- },
- "mapping-authkey": {
- "key-string": "password",
- "key-type": 1
- }
- }
- }
-
- The same should be done for 2.2.2.2/32 too.
-
-4. Verify that the key is added properly by requesting the following
- URL:
-
- ::
-
- curl -u "admin":"admin" -H "Content-type: application/json" -X GET \
- http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/authentication-key/ipv4:1.1.1.1%2f32/
-
- The output the above invocation should look like this:
-
- .. code:: json
-
- {
- "authentication-key":[
- {
- "eid-uri":"ipv4:1.1.1.1/32",
- "eid":{
- "ipv4-prefix":"1.1.1.1/32",
- "address-type":"ietf-lisp-address-types:ipv4-prefix-afi"
- },
- "mapping-authkey":{
- "key-string":"password"
- ,"key-type":1
- }
- }
- ]
- }
-
-5. Configure the CSR installations from the previous step. The EID needs to
- be configured on a loopback interface (except when the CSR is used as a
- router not a simple client like in this tutorial and the EID is assigned
- to a real interface).
-
- ::
-
- interface Loopback0
- ip address 1.1.1.1 255.255.255.255
-
-6. The LISP specific configuration goes to a ``router lisp`` section in the
- configuration. A ``locator-set`` defines the list of locators with their
- priorities and weights, either statically, or better yet, as an interface
- name:
-
- ::
-
- locator-set rloc-network
- IPv4-interface GigabitEthernet2 priority 1 weight 1
- exit
-
-7. To make sure a Map-Request is using the above defined ``rloc-network``
- locator set, the following configuration is used:
-
- ::
-
- map-request itr-rlocs rloc-network
-
-8. Each Instance ID needs its own configuration. For the default Instance ID
- of 0, the following configuration is needed for a besic setup:
-
- ::
-
- eid-table default instance-id 0
- database-mapping 1.1.1.1/32 locator-set rloc-network
- map-cache 0.0.0.0/0 map-request
- no ipv4 map-cache-persistent
- ipv4 itr map-resolver 192.168.16.11
- ipv4 itr
- ipv4 etr map-server 192.168.16.11 key password
- ipv4 etr
- exit
-
- ``database-mapping`` defines the EID prefix the router will register in
- the mapping system and which locator set it will use (``rloc-network`` in
- this case, which was defined in step 6).
-
- The next line creates a static map-cache entry for the whole IPv4 EID
- space, causing a Map-Request to be triggered for every destination (that
- is not directly connected on some interface).
-
- LISP routers save their map cache to a fie which is used to restore
- previous state on reboot. To avoid confusion due to state restored from a
- previous run, ``no ipv4 map-cache-persistent`` can be used to disable this
- behavior for non-production testing environments.
-
- A ``map-resolver`` is then defined, where Map-Requests will be directed to
- for mapping lookups, and then a ``map-server`` association with a shared
- secret key.
-
-9. Here's the full configuration that needs to be pasted into the
- configuration of the **client** to follow this tutorial:
-
- ::
-
- interface Loopback0
- ip address 1.1.1.1 255.255.255.255
- !
- router lisp
- locator-set rloc-network
- IPv4-interface GigabitEthernet2 priority 1 weight 1
- exit
- !
- map-request itr-rlocs rloc-network
- eid-table default instance-id 0
- database-mapping 1.1.1.1/32 locator-set rloc-network
- map-cache 0.0.0.0/0 map-request
- no ipv4 map-cache-persistent
- ipv4 itr map-resolver 192.168.16.11
- ipv4 itr
- ipv4 etr map-server 192.168.16.11 key password
- ipv4 etr
- exit
- !
- exit
-
- Configuring the **server** is done by replacing ``1.1.1.1`` with
- ``2.2.2.2`` in the above configuration snippet.
-
-10. The CSR nodes should now register their EID-to-RLOC mappings to
- OpenDaylight. To verify, the corresponding EIDs can be looked up via the
- REST API:
-
- ::
-
- curl -u "admin":"admin" -H "Content-type: application/json" -X GET \
- http://localhost:8181/restconf/operational/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:1.1.1.1%2f32/southbound/
-
- An alternative way for retrieving mappings from OpenDaylight using the
- southbound interface is using the
- `lig <https://github.com/davidmeyer/lig>`_ open source tool.
-
- Yet another different way is to use the OpenDaylight mappingservice CLI,
- and type the following at the Karaf prompt:
-
- ::
-
- mappingservice:mappings
-
- This needs the *odl-lispflowmapping-mappingservice-shell* feature to be
- loaded. The output is intended for debugging purposes and shows the full
- Java objects stored in the map-cache.
-
-
-11. Now the LISP network is up. It can be verified by pinging the **server**
- EID from the **client** CSR EID:
-
- ::
-
- ping 2.2.2.2 source 1.1.1.1
-
-LISP Flow Mapping Support
--------------------------
-
-For support the lispflowmapping project can be reached by emailing the
-developer mailing list: lispflowmapping-dev@lists.opendaylight.org or on
-the #opendaylight-lispflowmapping IRC channel on irc.freenode.net.
-
-Additional information is also available on the `Lisp Flow Mapping
-wiki <https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Main>`__
-
-Clustering in LISP Flow Mapping
--------------------------------
-
-Documentation regarding setting up a 3-node OpenDaylight cluster is
-described at following `odl wiki
-page <https://wiki.opendaylight.org/view/Running_and_testing_an_OpenDaylight_Cluster#Three-node_cluster>`__.
-
-To turn on clustering in LISP Flow Mapping it is necessary:
-
-- run script **deploy.py** script. This script is in
- `integration-test <https://git.opendaylight.org/gerrit/integration/test>`__
- project placed at *tools/clustering/cluster-deployer/deploy.py*. A
- whole deploy.py command can looks like:
-
-.. raw:: html
-
- <div class="informalexample">
-
-| {path\_to\_integration\_test\_project}/tools/clustering/cluster-deployer/**deploy.py**
-| --**distribution** {path\_to\_distribution\_in\_zip\_format}
-| --**rootdir** {dir\_at\_remote\_host\_where\_copy\_odl\_distribution}
-| --**hosts** {ip1},{ip2},{ip3}
-| --**clean**
-| --**template** lispflowmapping
-| --**rf** 3
-| --**user** {user\_name\_of\_remote\_hosts}
-| --**password** {password\_to\_remote\_hosts}
-
-.. raw:: html
-
- </div>
-
-| Running this script will cause that specified **distribution** to be
- deployed to remote **hosts** specified through their IP adresses with
- using credentials (**user** and **password**). The distribution will
- be copied to specified **rootdir**. As part of the deployment, a
- **template** which contains a set of controller files which are
- different from standard ones. In this case it is specified in
-| *{path\_to\_integration\_test\_project}/tools/clustering/cluster-deployer/lispflowmapping*
- directory.
-| Lispflowmapping templates are part of integration-test project. There
- are 5 template files:
-
-- akka.conf.template
-
-- jolokia.xml.template
-
-- module-shards.conf.template
-
-- modules.conf.template
-
-- org.apache.karaf.features.cfg.template
-
-After copying the distribution, it is unzipped and started on all of
-specified **hosts** in cluster aware manner.
-
-Remarks
-~~~~~~~
-
-It is necessary to have:
-
-- **unzip** program installed on all of the host
-
-- set all remote hosts /etc/sudoers files to not **requiretty** (should
- only matter on debian hosts)
+++ /dev/null
-.. _netconf-user-guide:
-
-NETCONF User Guide
-==================
-
-Overview
---------
-
-NETCONF is an XML-based protocol used for configuration and monitoring
-devices in the network. The base NETCONF protocol is described in
-`RFC-6241 <http://tools.ietf.org/html/rfc6241>`__.
-
-**NETCONF in OpenDaylight:.**
-
-OpenDaylight supports the NETCONF protocol as a northbound server as
-well as a southbound plugin. It also includes a set of test tools for
-simulating NETCONF devices and clients.
-
-Southbound (netconf-connector)
-------------------------------
-
-The NETCONF southbound plugin is capable of connecting to remote NETCONF
-devices and exposing their configuration/operational datastores, RPCs
-and notifications as MD-SAL mount points. These mount points allow
-applications and remote users (over RESTCONF) to interact with the
-mounted devices.
-
-In terms of RFCs, the connector supports:
-
-- `RFC-6241 <http://tools.ietf.org/html/rfc6241>`__
-
-- `RFC-5277 <https://tools.ietf.org/html/rfc5277>`__
-
-- `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
-the device.**
-
-.. tip::
-
- NETCONF southbound can be activated by installing
- ``odl-netconf-connector-all`` Karaf feature.
-
-Netconf-connector configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-There are 2 ways for configuring netconf-connector: NETCONF or RESTCONF.
-This guide focuses on using RESTCONF.
-
-Default configuration
-^^^^^^^^^^^^^^^^^^^^^
-
-The default configuration contains all the necessary dependencies (file:
-01-netconf.xml) and a single instance of netconf-connector (file:
-99-netconf-connector.xml) called **controller-config** which connects
-itself to the NETCONF northbound in OpenDaylight in a loopback fashion.
-The connector mounts the NETCONF server for config-subsystem in order to
-enable RESTCONF protocol for config-subsystem. This RESTCONF still goes
-via NETCONF, but using RESTCONF is much more user friendly than using
-NETCONF.
-
-Spawning additional netconf-connectors while the controller is running
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Preconditions:
-
-1. OpenDaylight is running
-
-2. In Karaf, you must have the netconf-connector installed (at the Karaf
- prompt, type: ``feature:install odl-netconf-connector-all``); the
- loopback NETCONF mountpoint will be automatically configured and
- activated
-
-3. Wait until log displays following entry:
- RemoteDevice{controller-config}: NETCONF connector initialized
- successfully
-
-To configure a new netconf-connector you need to send following request
-to RESTCONF:
-
-POST
-http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules
-
-Headers:
-
-- Accept application/xml
-
-- Content-Type application/xml
-
-::
-
- <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">prefix:sal-netconf-connector</type>
- <name>new-netconf-device</name>
- <address xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">127.0.0.1</address>
- <port xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">830</port>
- <username xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">admin</username>
- <password xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">admin</password>
- <tcp-only xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">false</tcp-only>
- <event-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:netty">prefix:netty-event-executor</type>
- <name>global-event-executor</name>
- </event-executor>
- <binding-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-broker-osgi-registry</type>
- <name>binding-osgi-broker</name>
- </binding-registry>
- <dom-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">prefix:dom-broker-osgi-registry</type>
- <name>dom-broker</name>
- </dom-registry>
- <client-dispatcher xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:config:netconf">prefix:netconf-client-dispatcher</type>
- <name>global-netconf-dispatcher</name>
- </client-dispatcher>
- <processing-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:threadpool</type>
- <name>global-netconf-processing-executor</name>
- </processing-executor>
- <keepalive-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:scheduled-threadpool</type>
- <name>global-netconf-ssh-scheduled-executor</name>
- </keepalive-executor>
- </module>
-
-This spawns a new netconf-connector which tries to connect to (or mount)
-a NETCONF device at 127.0.0.1 and port 830. You can check the
-configuration of config-subsystem’s configuration datastore. The new
-netconf-connector will now be present there. Just invoke:
-
-GET
-http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules
-
-The response will contain the module for new-netconf-device.
-
-Right after the new netconf-connector is created, it writes some useful
-metadata into the datastore of MD-SAL under the network-topology
-subtree. This metadata can be found at:
-
-GET
-http://localhost:8181/restconf/operational/network-topology:network-topology/
-
-Information about connection status, device capabilities, etc. can be
-found there.
-
-Connecting to a device not supporting NETCONF monitoring
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The netconf-connector in OpenDaylight relies on ietf-netconf-monitoring
-support when connecting to remote NETCONF device. The
-ietf-netconf-monitoring support allows netconf-connector to list and
-download all YANG schemas that are used by the device. NETCONF connector
-can only communicate with a device if it knows the set of used schemas
-(or at least a subset). However, some devices use YANG models internally
-but do not support NETCONF monitoring. Netconf-connector can also
-communicate with these devices, but you have to side load the necessary
-yang models into OpenDaylight’s YANG model cache for netconf-connector.
-In general there are 2 situations you might encounter:
-
-**1. NETCONF device does not support ietf-netconf-monitoring but it does
-list all its YANG models as capabilities in HELLO message**
-
-This could be a device that internally uses only ietf-inet-types YANG
-model with revision 2010-09-24. In the HELLO message that is sent from
-this device there is this capability reported:
-
-::
-
- urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2010-09-24
-
-**For such devices you only need to put the schema into folder
-cache/schema inside your Karaf distribution.**
-
-.. important::
-
- The file with YANG schema for ietf-inet-types has to be called
- ietf-inet-types@2010-09-24.yang. It is the required naming format of
- the cache.
-
-**2. NETCONF device does not support ietf-netconf-monitoring and it does
-NOT list its YANG models as capabilities in HELLO message**
-
-Compared to device that lists its YANG models in HELLO message, in this
-case there would be no capability with ietf-inet-types in the HELLO
-message. This type of device basically provides no information about the
-YANG schemas it uses so its up to the user of OpenDaylight to properly
-configure netconf-connector for this device.
-
-Netconf-connector has an optional configuration attribute called
-yang-module-capabilities and this attribute can contain a list of "YANG
-module based" capabilities. So by setting this configuration attribute,
-it is possible to override the "yang-module-based" capabilities reported
-in HELLO message of the device. To do this, we need to modify the
-configuration of netconf-connector by adding this XML (It needs to be
-added next to the address, port, username etc. configuration elements):
-
-::
-
- <yang-module-capabilities xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2010-09-24
- </capability>
- </yang-module-capabilities>
-
-**Remember to also put the YANG schemas into the cache folder.**
-
-.. note::
-
- For putting multiple capabilities, you just need to replicate the
- capability xml element inside yang-module-capability element.
- Capability element is modeled as a leaf-list. With this
- configuration, we would make the remote device report usage of
- ietf-inet-types in the eyes of netconf-connector.
-
-Reconfiguring Netconf-Connector While the Controller is Running
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-It is possible to change the configuration of a running module while the
-whole controller is running. This example will continue where the last
-left off and will change the configuration for the brand new
-netconf-connector after it was spawned. Using one RESTCONF request, we
-will change both username and password for the netconf-connector.
-
-To update an existing netconf-connector you need to send following
-request to RESTCONF:
-
-PUT
-http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-sal-netconf-connector-cfg:sal-netconf-connector/new-netconf-device
-
-::
-
- <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">prefix:sal-netconf-connector</type>
- <name>new-netconf-device</name>
- <username xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">bob</username>
- <password xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">passwd</password>
- <tcp-only xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">false</tcp-only>
- <event-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:netty">prefix:netty-event-executor</type>
- <name>global-event-executor</name>
- </event-executor>
- <binding-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">prefix:binding-broker-osgi-registry</type>
- <name>binding-osgi-broker</name>
- </binding-registry>
- <dom-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">prefix:dom-broker-osgi-registry</type>
- <name>dom-broker</name>
- </dom-registry>
- <client-dispatcher xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:config:netconf">prefix:netconf-client-dispatcher</type>
- <name>global-netconf-dispatcher</name>
- </client-dispatcher>
- <processing-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:threadpool</type>
- <name>global-netconf-processing-executor</name>
- </processing-executor>
- <keepalive-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:threadpool">prefix:scheduled-threadpool</type>
- <name>global-netconf-ssh-scheduled-executor</name>
- </keepalive-executor>
- </module>
-
-Since a PUT is a replace operation, the whole configuration must be
-specified along with the new values for username and password. This
-should result in a 2xx response and the instance of netconf-connector
-called new-netconf-device will be reconfigured to use username bob and
-password passwd. New configuration can be verified by executing:
-
-GET
-http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-sal-netconf-connector-cfg:sal-netconf-connector/new-netconf-device
-
-With new configuration, the old connection will be closed and a new one
-established.
-
-Destroying Netconf-Connector While the Controller is Running
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Using RESTCONF one can also destroy an instance of a module. In case of
-netconf-connector, the module will be destroyed, NETCONF connection
-dropped and all resources will be cleaned. To do this, simply issue a
-request to following URL:
-
-DELETE
-http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-sal-netconf-connector-cfg:sal-netconf-connector/new-netconf-device
-
-The last element of the URL is the name of the instance and its
-predecessor is the type of that module (In our case the type is
-**sal-netconf-connector** and name **new-netconf-device**). The type and
-name are actually the keys of the module list.
-
-Netconf-connector configuration with MD-SAL
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-It is also possible to configure new NETCONF connectors directly through
-MD-SAL with the usage of the network-topology model. You can configure
-new NETCONF connectors both through the NETCONF server for MD-SAL (port
-2830) or RESTCONF. This guide focuses on RESTCONF.
-
-.. tip::
-
- To enable NETCONF connector configuration through MD-SAL install
- either the ``odl-netconf-topology`` or
- ``odl-netconf-clustered-topology`` feature. We will explain the
- difference between these features later.
-
-Preconditions
-^^^^^^^^^^^^^
-
-1. OpenDaylight is running
-
-2. In Karaf, you must have the ``odl-netconf-topology`` or
- ``odl-netconf-clustered-topology`` feature installed.
-
-3. Feature ``odl-restconf`` must be installed
-
-4. Wait until log displays following entry:
-
- ::
-
- Successfully pushed configuration snapshot 02-netconf-topology.xml(odl-netconf-topology,odl-netconf-topology)
-
- or until
-
- ::
-
- GET http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/
-
- returns a non-empty response, for example:
-
- ::
-
- <topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <topology-id>topology-netconf</topology-id>
- </topology>
-
-Spawning new NETCONF connectors
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To create a new NETCONF connector you need to send the following request
-to RESTCONF:
-
-::
-
- PUT http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device
-
-Headers:
-
-- Accept: application/xml
-
-- Content-Type: application/xml
-
-Payload:
-
-::
-
- <node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
- <node-id>new-netconf-device</node-id>
- <host xmlns="urn:opendaylight:netconf-node-topology">127.0.0.1</host>
- <port xmlns="urn:opendaylight:netconf-node-topology">17830</port>
- <username xmlns="urn:opendaylight:netconf-node-topology">admin</username>
- <password xmlns="urn:opendaylight:netconf-node-topology">admin</password>
- <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
- <!-- non-mandatory fields with default values, you can safely remove these if you do not wish to override any of these values-->
- <reconnect-on-changed-schema xmlns="urn:opendaylight:netconf-node-topology">false</reconnect-on-changed-schema>
- <connection-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">20000</connection-timeout-millis>
- <max-connection-attempts xmlns="urn:opendaylight:netconf-node-topology">0</max-connection-attempts>
- <between-attempts-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">2000</between-attempts-timeout-millis>
- <sleep-factor xmlns="urn:opendaylight:netconf-node-topology">1.5</sleep-factor>
- <!-- keepalive-delay set to 0 turns off keepalives-->
- <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">120</keepalive-delay>
- </node>
-
-Note that the device name in <node-id> element must match the last
-element of the restconf URL.
-
-Reconfiguring an existing connector
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The steps to reconfigure an existing connector are exactly the same as
-when spawning a new connector. The old connection will be disconnected
-and a new connector with the new configuration will be created.
-
-Deleting an existing connector
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To remove an already configured NETCONF connector you need to send the
-following:
-
-::
-
- 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
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-To spawn NETCONF connectors that are cluster-aware you need to install
-the ``odl-netconf-clustered-topology`` karaf feature.
-
-.. warning::
-
- The ``odl-netconf-topology`` and ``odl-netconf-clustered-topology``
- features are considered **INCOMPATIBLE**. They both manage the same
- space in the datastore and would issue conflicting writes if
- installed together.
-
-Configuration of clustered NETCONF connectors works the same as the
-configuration through the topology model in the previous section.
-
-When a new clustered connector is configured the configuration gets
-distributed among the member nodes and a NETCONF connector is spawned on
-each node. From these nodes a master is chosen which handles the schema
-download from the device and all the communication with the device. You
-will be able to read/write to/from the device from all slave nodes due
-to the proxy data brokers implemented.
-
-You can use the ``odl-netconf-clustered-topology`` feature in a single
-node scenario as well but the code that uses akka will be used, so for a
-scenario where only a single node is used, ``odl-netconf-topology``
-might be preferred.
-
-Netconf-connector utilization
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Once the connector is up and running, users can utilize the new mount
-point instance. By using RESTCONF or from their application code. This
-chapter deals with using RESTCONF and more information for app
-developers can be found in the developers guide or in the official
-tutorial application **ncmount** that can be found in the coretutorials
-project:
-
-- https://github.com/opendaylight/coretutorials/tree/stable/beryllum/ncmount
-
-Reading data from the device
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Just invoke (no body needed):
-
-GET
-http://localhost:8080/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device/yang-ext:mount/
-
-This will return the entire content of operation datastore from the
-device. To view just the configuration datastore, change **operational**
-in this URL to **config**.
-
-Writing configuration data to the device
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-In general, you cannot simply write any data you want to the device. The
-data have to conform to the YANG models implemented by the device. In
-this example we are adding a new interface-configuration to the mounted
-device (assuming the device supports Cisco-IOS-XR-ifmgr-cfg YANG model).
-In fact this request comes from the tutorial dedicated to the
-**ncmount** tutorial app.
-
-POST
-http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device/yang-ext:mount/Cisco-IOS-XR-ifmgr-cfg:interface-configurations
-
-::
-
- <interface-configuration xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg">
- <active>act</active>
- <interface-name>mpls</interface-name>
- <description>Interface description</description>
- <bandwidth>32</bandwidth>
- <link-status></link-status>
- </interface-configuration>
-
-Should return 200 response code with no body.
-
-.. tip::
-
- This call is transformed into a couple of NETCONF RPCs. Resulting
- NETCONF RPCs that go directly to the device can be found in the
- OpenDaylight logs after invoking ``log:set TRACE
- org.opendaylight.controller.sal.connect.netconf`` in the Karaf
- shell. Seeing the NETCONF RPCs might help with debugging.
-
-This request is very similar to the one where we spawned a new netconf
-device. That’s because we used the loopback netconf-connector to write
-configuration data into config-subsystem datastore and config-subsystem
-picked it up from there.
-
-Invoking custom RPC
-^^^^^^^^^^^^^^^^^^^
-
-Devices can implement any additional RPC and as long as it provides YANG
-models for it, it can be invoked from OpenDaylight. Following example
-shows how to invoke the get-schema RPC (get-schema is quite common among
-netconf devices). Invoke:
-
-POST
-http://localhost:8181/restconf/operations/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device/yang-ext:mount/ietf-netconf-monitoring:get-schema
-
-::
-
- <input xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
- <identifier>ietf-yang-types</identifier>
- <version>2013-07-15</version>
- </input>
-
-This call should fetch the source for ietf-yang-types YANG model from
-the mounted device.
-
-Netconf-connector + Netopeer
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-`Netopeer <https://github.com/cesnet/netopeer>`__ (an open-source
-NETCONF server) can be used for testing/exploring NETCONF southbound in
-OpenDaylight.
-
-Netopeer installation
-^^^^^^^^^^^^^^^^^^^^^
-
-A `Docker <https://www.docker.com/>`__ container with netopeer will be
-used in this guide. To install Docker and start the `netopeer
-image <https://index.docker.io/u/dockeruser/netopeer/>`__ perform
-following steps:
-
-1. Install docker http://docs.docker.com/linux/step_one/
-
-2. Start the netopeer image:
-
- ::
-
- docker run -rm -t -p 1831:830 dockeruser/netopeer
-
-3. Verify netopeer is running by invoking (netopeer should send its
- HELLO message right away:
-
- ::
-
- ssh root@localhost -p 1831 -s netconf
- (password root)
-
-Mounting netopeer NETCONF server
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Preconditions:
-
-- OpenDaylight is started with features ``odl-restconf-all`` and
- ``odl-netconf-connector-all``.
-
-- Netopeer is up and running in docker
-
-Now just follow the chapter: `Spawning
-netconf-connector <#_spawning_additional_netconf_connectors_while_the_controller_is_running>`__.
-In the payload change the:
-
-- name, e.g., to netopeer
-
-- username/password to your system credentials
-
-- ip to localhost
-
-- port to 1831.
-
-After netopeer is mounted successfully, its configuration can be read
-using RESTCONF by invoking:
-
-GET
-http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/netopeer/yang-ext:mount/
-
-Northbound (NETCONF servers)
-----------------------------
-
-OpenDaylight provides 2 types of NETCONF servers:
-
-- **NETCONF server for config-subsystem (listening by default on port
- 1830)**
-
- - Serves as a default interface for config-subsystem and allows
- users to spawn/reconfigure/destroy modules (or applications) in
- OpenDaylight
-
-- **NETCONF server for MD-SAL (listening by default on port 2830)**
-
- - Serves as an alternative interface for MD-SAL (besides RESTCONF)
- and allows users to read/write data from MD-SAL’s datastore and to
- invoke its rpcs (NETCONF notifications are not available in the
- Boron release of OpenDaylight)
-
-.. note::
-
- The reason for having 2 NETCONF servers is that config-subsystem and
- MD-SAL are 2 different components of OpenDaylight and require
- different approach for NETCONF message handling and data
- translation. These 2 components will probably merge in the future.
-
-.. note::
-
- Since Nitrogen release, there is performance regression in NETCONF
- servers accepting SSH connections. While opening a connection takes
- less than 10 seconds on Carbon, on Nitrogen time can increase up to
- 60 seconds. Please see https://bugs.opendaylight.org/show_bug.cgi?id=9020
-
-NETCONF server for config-subsystem
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This NETCONF server is the primary interface for config-subsystem. It
-allows the users to interact with config-subsystem in a standardized
-NETCONF manner.
-
-In terms of RFCs, these are supported:
-
-- `RFC-6241 <http://tools.ietf.org/html/rfc6241>`__
-
-- `RFC-5277 <https://tools.ietf.org/html/rfc5277>`__
-
-- `RFC-6470 <https://tools.ietf.org/html/rfc6470>`__
-
- - (partially, only the schema-change notification is available in
- Boron release)
-
-- `RFC-6022 <https://tools.ietf.org/html/rfc6022>`__
-
-For regular users it is recommended to use RESTCONF + the
-controller-config loopback mountpoint instead of using pure NETCONF. How
-to do that is spesific for each component/module/application in
-OpenDaylight and can be found in their dedicated user guides.
-
-NETCONF server for MD-SAL
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This NETCONF server is just a generic interface to MD-SAL in
-OpenDaylight. It uses the stadard MD-SAL APIs and serves as an
-alternative to RESTCONF. It is fully model driven and supports any data
-and rpcs that are supported by MD-SAL.
-
-In terms of RFCs, these are supported:
-
-- `RFC-6241 <http://tools.ietf.org/html/rfc6241>`__
-
-- `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 Boron release.
-
-.. tip::
-
- Install NETCONF northbound for MD-SAL by installing feature:
- ``odl-netconf-mdsal`` in karaf. Default binding port is **2830**.
-
-Configuration
-^^^^^^^^^^^^^
-
-The default configuration can be found in file: *08-netconf-mdsal.xml*.
-The file contains the configuration for all necessary dependencies and a
-single SSH endpoint starting on port 2830. There is also a (by default
-disabled) TCP endpoint. It is possible to start multiple endpoints at
-the same time either in the initial configuration file or while
-OpenDaylight is running.
-
-The credentials for SSH endpoint can also be configured here, the
-defaults are admin/admin. Credentials in the SSH endpoint are not yet
-managed by the centralized AAA component and have to be configured
-separately.
-
-Verifying MD-SAL’s NETCONF server
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-After the NETCONF server is available it can be examined by a command
-line ssh tool:
-
-::
-
- ssh admin@localhost -p 2830 -s netconf
-
-The server will respond by sending its HELLO message and can be used as
-a regular NETCONF server from then on.
-
-Mounting the MD-SAL’s NETCONF server
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To perform this operation, just spawn a new netconf-connector as
-described in `Spawning
-netconf-connector <#_spawning_additional_netconf_connectors_while_the_controller_is_running>`__.
-Just change the ip to "127.0.0.1" port to "2830" and its name to
-"controller-mdsal".
-
-Now the MD-SAL’s datastore can be read over RESTCONF via NETCONF by
-invoking:
-
-GET
-http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/controller-mdsal/yang-ext:mount
-
-.. note::
-
- This might not seem very useful, since MD-SAL can be accessed
- directly from RESTCONF or from Application code, but the same method
- can be used to mount and control other OpenDaylight instances by the
- "master OpenDaylight".
-
-NETCONF testtool
-----------------
-
-**NETCONF testtool is a set of standalone runnable jars that can:**
-
-- Simulate NETCONF devices (suitable for scale testing)
-
-- Stress/Performance test NETCONF devices
-
-- Stress/Performance test RESTCONF devices
-
-These jars are part of OpenDaylight’s controller project and are built
-from the NETCONF codebase in OpenDaylight.
-
-.. tip::
-
- Download testtool from OpenDaylight Nexus at:
- https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.1.0-Boron/
-
-**Nexus contains 3 executable tools:**
-
-- executable.jar - device simulator
-
-- stress.client.tar.gz - NETCONF stress/performance measuring tool
-
-- perf-client.jar - RESTCONF stress/performance measuring tool
-
-.. tip::
-
- Each executable tool provides help. Just invoke ``java -jar
- <name-of-the-tool.jar> --help``
-
-NETCONF device simulator
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-NETCONF testtool (or NETCONF device simulator) is a tool that
-
-- Simulates 1 or more NETCONF devices
-
-- Is suitable for scale, performance or crud testing
-
-- Uses core implementation of NETCONF server from OpenDaylight
-
-- Generates configuration files for controller so that the OpenDaylight
- distribution (Karaf) can easily connect to all simulated devices
-
-- Provides broad configuration options
-
-- Can start a fully fledged MD-SAL datastore
-
-- Supports notifications
-
-Building testtool
-^^^^^^^^^^^^^^^^^
-
-1. Check out latest NETCONF repository from
- `git <https://git.opendaylight.org/gerrit/#/admin/projects/netconf>`__
-
-2. Move into the ``opendaylight/netconf/tools/netconf-testtool/`` folder
-
-3. Build testtool using the ``mvn clean install`` command
-
-Downloading testtool
-^^^^^^^^^^^^^^^^^^^^
-
-Netconf-testtool is now part of default maven build profile for
-controller and can be also downloaded from nexus. The executable jar for
-testtool can be found at:
-`nexus-artifacts <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.1.0-Boron/>`__
-
-Running testtool
-^^^^^^^^^^^^^^^^
-
-1. After successfully building or downloading, move into the
- ``opendaylight/netconf/tools/netconf-testtool/target/`` folder and
- there is file ``netconf-testtool-1.1.0-SNAPSHOT-executable.jar`` (or
- if downloaded from nexus just take that jar file)
-
-2. Execute this file using, e.g.:
-
- ::
-
- java -jar netconf-testtool-1.1.0-SNAPSHOT-executable.jar
-
- This execution runs the testtool with default for all parameters and
- you should see this log output from the testtool :
-
- ::
-
- 10:31:08.206 [main] INFO o.o.c.n.t.t.NetconfDeviceSimulator - Starting 1, SSH simulated devices starting on port 17830
- 10:31:08.675 [main] INFO o.o.c.n.t.t.NetconfDeviceSimulator - All simulated devices started successfully from port 17830 to 17830
-
-Default Parameters
-''''''''''''''''''
-
-The default parameters for testtool are:
-
-- Use SSH
-
-- Run 1 simulated device
-
-- Device port is 17830
-
-- YANG modules used by device are only: ietf-netconf-monitoring,
- ietf-yang-types, ietf-inet-types (these modules are required for
- device in order to support NETCONF monitoring and are included in the
- netconf-testtool)
-
-- Connection timeout is set to 30 minutes (quite high, but when testing
- with 10000 devices it might take some time for all of them to fully
- establish a connection)
-
-- Debug level is set to false
-
-- No distribution is modified to connect automatically to the NETCONF
- testtool
-
-Verifying testtool
-^^^^^^^^^^^^^^^^^^
-
-To verify that the simulated device is up and running, we can try to
-connect to it using command line ssh tool. Execute this command to
-connect to the device:
-
-::
-
- ssh admin@localhost -p 17830 -s netconf
-
-Just accept the server with yes (if required) and provide any password
-(testtool accepts all users with all passwords). You should see the
-hello message sent by simulated device.
-
-Testtool help
-^^^^^^^^^^^^^
-
-::
-
- usage: netconf testool [-h] [--device-count DEVICES-COUNT] [--devices-per-port DEVICES-PER-PORT] [--schemas-dir SCHEMAS-DIR] [--notification-file NOTIFICATION-FILE]
- [--initial-config-xml-file INITIAL-CONFIG-XML-FILE] [--starting-port STARTING-PORT] [--generate-config-connection-timeout GENERATE-CONFIG-CONNECTION-TIMEOUT]
- [--generate-config-address GENERATE-CONFIG-ADDRESS] [--generate-configs-batch-size GENERATE-CONFIGS-BATCH-SIZE] [--distribution-folder DISTRO-FOLDER] [--ssh SSH] [--exi EXI]
- [--debug DEBUG] [--md-sal MD-SAL]
-
- NETCONF device simulator. Detailed info can be found at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Netconf:Testtool#Building_testtool
-
- optional arguments:
- -h, --help show this help message and exit
- --device-count DEVICES-COUNT
- Number of simulated netconf devices to spin. This is the number of actual ports open for the devices.
- --devices-per-port DEVICES-PER-PORT
- Amount of config files generated per port to spoof more devices then are actually running
- --schemas-dir SCHEMAS-DIR
- Directory containing yang schemas to describe simulated devices. Some schemas e.g. netconf monitoring and inet types are included by default
- --notification-file NOTIFICATION-FILE
- Xml file containing notifications that should be sent to clients after create subscription is called
- --initial-config-xml-file INITIAL-CONFIG-XML-FILE
- Xml file containing initial simulatted configuration to be returned via get-config rpc
- --starting-port STARTING-PORT
- First port for simulated device. Each other device will have previous+1 port number
- --generate-config-connection-timeout GENERATE-CONFIG-CONNECTION-TIMEOUT
- Timeout to be generated in initial config files
- --generate-config-address GENERATE-CONFIG-ADDRESS
- Address to be placed in generated configs
- --generate-configs-batch-size GENERATE-CONFIGS-BATCH-SIZE
- Number of connector configs per generated file
- --distribution-folder DISTRO-FOLDER
- Directory where the karaf distribution for controller is located
- --ssh SSH Whether to use ssh for transport or just pure tcp
- --exi EXI Whether to use exi to transport xml content
- --debug DEBUG Whether to use debug log level instead of INFO
- --md-sal MD-SAL Whether to use md-sal datastore instead of default simulated datastore.
-
-Supported operations
-^^^^^^^^^^^^^^^^^^^^
-
-Testtool default simple datastore supported operations:
-
-get-schema
- returns YANG schemas loaded from user specified directory,
-
-edit-config
- always returns OK and stores the XML from the input in a local
- variable available for get-config and get RPC. Every edit-config
- replaces the previous data,
-
-commit
- always returns OK, but does not actually commit the data,
-
-get-config
- returns local XML stored by edit-config,
-
-get
- returns local XML stored by edit-config with netconf-state subtree,
- but also supports filtering.
-
-(un)lock
- returns always OK with no lock guarantee
-
-create-subscription
- returns always OK and after the operation is triggered, provided
- NETCONF notifications (if any) are fed to the client. No filtering
- or stream recognition is supported.
-
-Note: when operation="delete" is present in the payload for edit-config,
-it will wipe its local store to simulate the removal of data.
-
-When using the MD-SAL datastore testtool behaves more like normal
-NETCONF server and is suitable for crud testing. create-subscription is
-not supported when testtool is running with the MD-SAL datastore.
-
-Notification support
-^^^^^^^^^^^^^^^^^^^^
-
-Testtool supports notifications via the --notification-file switch. To
-trigger the notification feed, create-subscription operation has to be
-invoked. The XML file provided should look like this example file:
-
-::
-
- <?xml version='1.0' encoding='UTF-8' standalone='yes'?>
- <notifications>
-
- <!-- Notifications are processed in the order they are defined in XML -->
-
- <!-- Notification that is sent only once right after create-subscription is called -->
- <notification>
- <!-- Content of each notification entry must contain the entire notification with event time. Event time can be hardcoded, or generated by testtool if XXXX is set as eventtime in this XML -->
- <content><![CDATA[
- <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
- <eventTime>2011-01-04T12:30:46</eventTime>
- <random-notification xmlns="http://www.opendaylight.org/netconf/event:1.0">
- <random-content>single no delay</random-content>
- </random-notification>
- </notification>
- ]]></content>
- </notification>
-
- <!-- Repeated Notification that is sent 5 times with 2 second delay inbetween -->
- <notification>
- <!-- Delay in seconds from previous notification -->
- <delay>2</delay>
- <!-- Number of times this notification should be repeated -->
- <times>5</times>
- <content><![CDATA[
- <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
- <eventTime>XXXX</eventTime>
- <random-notification xmlns="http://www.opendaylight.org/netconf/event:1.0">
- <random-content>scheduled 5 times 10 seconds each</random-content>
- </random-notification>
- </notification>
- ]]></content>
- </notification>
-
- <!-- Single notification that is sent only once right after the previous notification -->
- <notification>
- <delay>2</delay>
- <content><![CDATA[
- <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
- <eventTime>XXXX</eventTime>
- <random-notification xmlns="http://www.opendaylight.org/netconf/event:1.0">
- <random-content>single with delay</random-content>
- </random-notification>
- </notification>
- ]]></content>
- </notification>
-
- </notifications>
-
-Connecting testtool with controller Karaf distribution
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Auto connect to OpenDaylight
-''''''''''''''''''''''''''''
-
-It is possible to make OpenDaylight auto connect to the simulated
-devices spawned by testtool (so user does not have to post a
-configuration for every NETCONF connector via RESTCONF). The testtool is
-able to modify the OpenDaylight distribution to auto connect to the
-simulated devices after feature ``odl-netconf-connector-all`` is
-installed. When running testtool, issue this command (just point the
-testool to the distribution:
-
-::
-
- java -jar netconf-testtool-1.1.0-SNAPSHOT-executable.jar --device-count 10 --distribution-folder ~/distribution-karaf-0.4.0-SNAPSHOT/ --debug true
-
-With the distribution-folder parameter, the testtool will modify the
-distribution to include configuration for netconf-connector to connect
-to all simulated devices. So there is no need to spawn
-netconf-connectors via RESTCONF.
-
-Running testtool and OpenDaylight on different machines
-'''''''''''''''''''''''''''''''''''''''''''''''''''''''
-
-The testtool binds by default to 0.0.0.0 so it should be accessible from
-remote machines. However you need to set the parameter
-"generate-config-address" (when using autoconnect) to the address of
-machine where testtool will be run so OpenDaylight can connect. The
-default value is localhost.
-
-Executing operations via RESTCONF on a mounted simulated device
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Simulated devices support basic RPCs for editing their config. This part
-shows how to edit data for simulated device via RESTCONF.
-
-Test YANG schema
-''''''''''''''''
-
-The controller and RESTCONF assume that the data that can be manipulated
-for mounted device is described by a YANG schema. For demonstration, we
-will define a simple YANG model:
-
-::
-
- module test {
- yang-version 1;
- namespace "urn:opendaylight:test";
- prefix "tt";
-
- revision "2014-10-17";
-
-
- container cont {
-
- leaf l {
- type string;
- }
- }
- }
-
-Save this schema in file called test@2014-10-17.yang and store it a
-directory called test-schemas/, e.g., your home folder.
-
-Editing data for simulated device
-'''''''''''''''''''''''''''''''''
-
-- Start the device with following command:
-
- ::
-
- java -jar netconf-testtool-1.1.0-SNAPSHOT-executable.jar --device-count 10 --distribution-folder ~/distribution-karaf-0.4.0-SNAPSHOT/ --debug true --schemas-dir ~/test-schemas/
-
-- Start OpenDaylight
-
-- Install odl-netconf-connector-all feature
-
-- Install odl-restconf feature
-
-- Check that you can see config data for simulated device by executing
- GET request to
-
- ::
-
- http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/17830-sim-device/yang-ext:mount/
-
-- The data should be just and empty data container
-
-- Now execute edit-config request by executing a POST request to:
-
- ::
-
- http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/17830-sim-device/yang-ext:mount
-
- with headers:
-
- ::
-
- Accept application/xml
- Content-Type application/xml
-
- and payload:
-
- ::
-
- <cont xmlns="urn:opendaylight:test">
- <l>Content</l>
- </cont>
-
-- Check that you can see modified config data for simulated device by
- executing GET request to
-
- ::
-
- http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/17830-sim-device/yang-ext:mount/
-
-- Check that you can see the same modified data in operational for
- simulated device by executing GET request to
-
- ::
-
- http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/17830-sim-device/yang-ext:mount/
-
-.. warning::
-
- Data will be mirrored in operational datastore only when using the
- default simple datastore.
-
-Known problems
-^^^^^^^^^^^^^^
-
-Slow creation of devices on virtual machines
-''''''''''''''''''''''''''''''''''''''''''''
-
-When testtool seems to take unusually long time to create the devices
-use this flag when running it:
-
-::
-
- -Dorg.apache.sshd.registerBouncyCastle=false
-
-Too many files open
-'''''''''''''''''''
-
-When testtool or OpenDaylight starts to fail with TooManyFilesOpen
-exception, you need to increase the limit of open files in your OS. To
-find out the limit in linux execute:
-
-::
-
- ulimit -a
-
-Example sufficient configuration in linux:
-
-::
-
- core file size (blocks, -c) 0
- data seg size (kbytes, -d) unlimited
- scheduling priority (-e) 0
- file size (blocks, -f) unlimited
- pending signals (-i) 63338
- max locked memory (kbytes, -l) 64
- max memory size (kbytes, -m) unlimited
- open files (-n) 500000
- pipe size (512 bytes, -p) 8
- POSIX message queues (bytes, -q) 819200
- real-time priority (-r) 0
- stack size (kbytes, -s) 8192
- cpu time (seconds, -t) unlimited
- max user processes (-u) 63338
- virtual memory (kbytes, -v) unlimited
- file locks (-x) unlimited
-
-To set these limits edit file: /etc/security/limits.conf, for example:
-
-::
-
- * hard nofile 500000
- * soft nofile 500000
- root hard nofile 500000
- root soft nofile 500000
-
-"Killed"
-''''''''
-
-The testtool might end unexpectedly with a simple message: "Killed".
-This means that the OS killed the tool due to too much memory consumed
-or too many threads spawned. To find out the reason on linux you can use
-following command:
-
-::
-
- dmesg | egrep -i -B100 'killed process'
-
-Also take a look at this file: /proc/sys/kernel/threads-max. It limits
-the number of threads spawned by a process. Sufficient (but probably
-much more than enough) value is, e.g., 126676
-
-NETCONF stress/performance measuring tool
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This is basically a NETCONF client that puts NETCONF servers under heavy
-load of NETCONF RPCs and measures the time until a configurable amount
-of them is processed.
-
-RESTCONF stress-performance measuring tool
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-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.
-
-NETCONF Call Home
------------------
-
-.. important::
-
- The call home feature is experimental and will change in a future
- release. In particular, the Yang models will change to those specified
- in the `RFC 8071 <https://tools.ietf.org/html/rfc8071>`__
-
-Call Home Installation
-~~~~~~~~~~~~~~~~~~~~~~
-
-ODL Call-Home server is installed in Karaf by installing karaf feature
-``odl-netconf-callhome-ssh``. RESTCONF feature is recommended for
-configuring Call Home & testing its functionality.
-
-::
-
- feature:install odl-netconf-callhome-ssh
-
-
-.. note::
-
- In order to test Call Home functionality we recommend Netopeer.
- See `Netopeer Call Home <https://github.com/CESNET/netopeer/wiki/CallHome>`__ to learn how to enable call-home on Netopeer.
-
-Northbound Call-Home API
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-The northbound Call Home API is used for administering the Call-Home Server. The
-following describes this configuration.
-
-Global Configuration
-^^^^^^^^^^^^^^^^^^^^
-
-Configuring global credentials
-''''''''''''''''''''''''''''''
-
-ODL Call-Home server allows user to configure global credentials, which
-will be used for devices which does not have device-specific credentials
-configured.
-
-This is done by creating
-``/odl-netconf-callhome-server:netconf-callhome-server/global/credentials``
-with username and passwords specified.
-
-*Configuring global username & passwords to try*
-
-.. code-block:: none
-
- PUT
- /restconf/config/odl-netconf-callhome-server:netconf-callhome-server/global/credentials HTTP/1.1
- Content-Type: application/json
- Accept: application/json
-
-.. code-block:: json
-
- {
- "credentials":
- {
- "username": "example",
- "passwords": [ "first-password-to-try", "second-password-to-try" ]
- }
- }
-
-Configuring to accept any ssh server key using global credentials
-'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
-
-By default Netconf Call-Home Server accepts only incoming connections
-from allowed devices
-``/odl-netconf-callhome-server:netconf-callhome-server/allowed-devices``,
-if user desire to allow all incoming connections, it is possible to set
-``accept-all-ssh-keys`` to ``true`` in
-``/odl-netconf-callhome-server:netconf-callhome-server/global``.
-
-The name of this devices in ``netconf-topology`` will be in format
-``ip-address:port``. For naming devices see Device-Specific
-Configuration.
-
-*Allowing unknown devices to connect*
-
-This is a debug feature and should not be used in production. Besides being an obvious
-security issue, this also causes the Call-Home Server to drastically increase its output
-to the log.
-
-.. code-block:: none
-
- POST
- /restconf/config/odl-netconf-callhome-server:netconf-callhome-server/global HTTP/1.1
- Content-Type: application/json
- Accept: application/json
-
-.. code-block:: json
-
- {
- "global": {
- "accept-all-ssh-keys": "true"
- }
- }
-
-Device-Specific Configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Allowing Device & Configuring Name
-''''''''''''''''''''''''''''''''''
-
-Netconf Call Home Server uses device provided SSH server key (host key)
-to identify device. The pairing of name and server key is configured in
-``/odl-netconf-callhome-server:netconf-callhome-server/allowed-devices``.
-This list is colloquially called a whitelist.
-
-If the Call-Home Server finds the SSH host key in the whitelist, it continues
-to negotiate a NETCONF connection over an SSH session. If the SSH host key is
-not found, the connection between the Call Home server and the device is dropped
-immediately. In either case, the device that connects to the Call home server
-leaves a record of its presence in the operational store.
-
-*Example of configuring device*
-
-.. code-block:: none
-
- PUT
- /restconf/config/odl-netconf-callhome-server:netconf-callhome-server/allowed-devices/device/example HTTP/1.1
- Content-Type: application/json
- Accept: application/json
-
-.. code-block:: json
-
- {
- "device": {
- "unique-id": "example",
- "ssh-host-key": "AAAAB3NzaC1yc2EAAAADAQABAAABAQDHoH1jMjltOJnCt999uaSfc48ySutaD3ISJ9fSECe1Spdq9o9mxj0kBTTTq+2V8hPspuW75DNgN+V/rgJeoUewWwCAasRx9X4eTcRrJrwOQKzb5Fk+UKgQmenZ5uhLAefi2qXX/agFCtZi99vw+jHXZStfHm9TZCAf2zi+HIBzoVksSNJD0VvPo66EAvLn5qKWQD4AdpQQbKqXRf5/W8diPySbYdvOP2/7HFhDukW8yV/7ZtcywFUIu3gdXsrzwMnTqnATSLPPuckoi0V2jd8dQvEcu1DY+rRqmqu0tEkFBurlRZDf1yhNzq5xWY3OXcjgDGN+RxwuWQK3cRimcosH"
- }
- }
-
-Configuring Device with Device-specific Credentials
-'''''''''''''''''''''''''''''''''''''''''''''''''''
-
-Call Home Server also allows to configure credentials per device basis,
-this is done by introducing ``credentials`` container into
-device-specific configuration. Format is same as in global credentials.
-
-*Configuring Device with Credentials*
-
-.. code-block:: none
-
- PUT
- /restconf/config/odl-netconf-callhome-server:netconf-callhome-server/allowed-devices/device/example HTTP/1.1
- Content-Type: application/json
- Accept: application/json
-
-.. code-block:: json
-
- {
- "device": {
- "unique-id": "example",
- "credentials": {
- "username": "example",
- "passwords": [ "password" ]
- },
- "ssh-host-key": "AAAAB3NzaC1yc2EAAAADAQABAAABAQDHoH1jMjltOJnCt999uaSfc48ySutaD3ISJ9fSECe1Spdq9o9mxj0kBTTTq+2V8hPspuW75DNgN+V/rgJeoUewWwCAasRx9X4eTcRrJrwOQKzb5Fk+UKgQmenZ5uhLAefi2qXX/agFCtZi99vw+jHXZStfHm9TZCAf2zi+HIBzoVksSNJD0VvPo66EAvLn5qKWQD4AdpQQbKqXRf5/W8diPySbYdvOP2/7HFhDukW8yV/7ZtcywFUIu3gdXsrzwMnTqnATSLPPuckoi0V2jd8dQvEcu1DY+rRqmqu0tEkFBurlRZDf1yhNzq5xWY3OXcjgDGN+RxwuWQK3cRimcosH"
- }
- }
-
-Operational Status
-^^^^^^^^^^^^^^^^^^
-
-Once an entry is made into the config side of "allowed-devices", the Call-Home Server will
-populate an corresponding operational device that is the same as the config device but
-has an additional status. By default, this status is *DISCONNECTED*. Once a device calls
-home, this status will change to one of:
-
-*CONNECTED* — The device is currently connected and the NETCONF mount is available for network
-management.
-
-*FAILED_AUTH_FAILURE* — The last attempted connection was unsuccessful because the Call-Home
-Server was unable to provide the acceptable credentials of the device. The device is also
-disconnected and not available for network management.
-
-*FAILED_NOT_ALLOWED* — The last attempted connection was unsuccessful because the device was
-not recognized as an acceptable device. The device is also disconnected and not available for
-network management.
-
-*FAILED* — The last attempted connection was unsuccessful for a reason other than not
-allowed to connect or incorrect client credentials. The device is also disconnected and not
-available for network management.
-
-*DISCONNECTED* — The device is currently disconnected.
-
-Rogue Devices
-'''''''''''''
-
-Devices which are not on the whitelist might try to connect to the Call-Home Server. In
-these cases, the server will keep a record by instantiating an operational device. There
-will be no corresponding config device for these rogues. They can be identified readily
-because their device id, rather than being user-supplied, will be of the form
-"address:port". Note that if a device calls back multiple times, there will only be
-a single operatinal entry (even if the port changes); these devices are recognized by
-their unique host key.
-
-Southbound Call-Home API
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-The Call-Home Server listens for incoming TCP connections and assumes that the other side of
-the connection is a device calling home via a NETCONF connection with SSH for
-management. The server uses port 6666 by default and this can be configured via a
-blueprint configuration file.
-
-The device **must** initiate the connection and the server will not try to re-establish the
-connection in case of a drop. By requirement, the server cannot assume it has connectivity
-to the device due to NAT or firewalls among others.
+++ /dev/null
-.. _netide-user-guide:
-
-NetIDE User Guide
-=================
-
-Overview
---------
-
-OpenDaylight’s NetIDE project allows users to run SDN applications
-written for different SDN controllers, e.g., Floodlight or Ryu, on top
-of OpenDaylight managed infrastructure. The NetIDE Network Engine
-integrates a client controller layer that executes the modules that
-compose a Network Application and interfaces with a server SDN
-controller layer that drives the underlying infrastructure. In addition,
-it provides a uniform interface to common tools that are intended to
-allow the inspection/debug of the control channel and the management of
-the network resources.
-
-The Network Engine provides a compatibility layer capable of translating
-calls of the network applications running on top of the client
-controllers, into calls for the server controller framework. The
-communication between the client and the server layers is achieved
-through the NetIDE intermediate protocol, which is an application-layer
-protocol on top of TCP that transmits the network control/management
-messages from the client to the server controller and vice-versa.
-Between client and server controller sits the Core Layer which also
-speaks the intermediate protocol.
-
-NetIDE API
-----------
-
-Architecture and Design
-~~~~~~~~~~~~~~~~~~~~~~~
-
-The NetIDE engine follows the ONF’s proposed Client/Server SDN
-Application architecture.
-
-.. figure:: ./images/netide/netidearch.jpg
- :alt: NetIDE Network Engine Architecture
-
- NetIDE Network Engine Architecture
-
-Core
-~~~~
-
-The NetIDE Core is a message-based system that allows for the exchange
-of messages between OpenDaylight and subscribed Client SDN Controllers
-
-Handling reply messages correctly
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When an application module sends a request to the network (e.g. flow
-statistics, features, etc.), the Network Engine must be able to
-correctly drive the corresponding reply to such a module. This is not a
-trivial task, as many modules may compose the network application
-running on top of the Network Engine, and there is no way for the Core
-to pair replies and requests. The transaction IDs (xid) in the OpenFlow
-header are unusable in this case, as it may happen that different
-modules use the same values.
-
-In the proposed approach, represented in the figure below, the task of
-pairing replies with requests is performed by the Shim Layer which
-replaces the original xid of the OpenFlow requests coming from the core
-with new unique xid values. The Shim also saves the original OpenFlow
-xid value and the module id it finds in the NetIDE header. As the
-network elements must use the same xid values in the replies, the Shim
-layer can easily pair a reply with the correct request as it is using
-unique xid values.
-
-The below figure shows how the Network Engine should handle the
-controller-to-switch OpenFlow messages. The diagram shows the case of a
-request message sent by an application module to a network element where
-the Backend inserts the module id of the module in the NetIDE header (X
-in the Figure). For other messages generated by the client controller
-platform (e.g. echo requests) or by the Backend, the module id of the
-Backend is used (Y in the Figure).
-
-.. figure:: ./images/netide/netide-flow.jpg
- :alt: NetIDE Communication Flow
-
- NetIDE Communication Flow
-
-Configuration
-~~~~~~~~~~~~~
-
-Below are the configuration items which can be edited, including their
-default values.
-
-- core-address: This is the ip address of the NetIDE Core, default is
- 127.0.0.1
-
-- core-port: The port of on which the NetIDE core is listening on
-
-- address: IP address where the controller listens for switch
- connections, default is 127.0.0.1
-
-- port: Port where controller listens for switch connections, default:
- 6644
-
-- transport-protocol: default is TCP
-
-- switch-idle-timeout: default is 15000ms
-
+++ /dev/null
-.. _nic-user-guide:
-
-Network Intent Composition (NIC) User Guide
-===========================================
-
-Overview
---------
-
-Network Intent Composition (NIC) is an interface that allows clients to
-express a desired state in an implementation-neutral form that will be
-enforced via modification of available resources under the control of
-the OpenDaylight system.
-
-This description is purposely abstract as an intent interface might
-encompass network services, virtual devices, storage, etc.
-
-The intent interface is meant to be a controller-agnostic interface so
-that "intents" are portable across implementations, such as OpenDaylight
-and ONOS. Thus an intent specification should not contain implementation
-or technology specifics.
-
-The intent specification will be implemented by decomposing the intent
-and augmenting it with implementation specifics that are driven by local
-implementation rules, policies, and/or settings.
-
-Network Intent Composition (NIC) Architecture
----------------------------------------------
-
-The core of the NIC architecture is the intent model, which specifies
-the details of the desired state. It is the responsibility of the NIC
-implementation transforms this desired state to the resources under the
-control of OpenDaylight. The component that transforms the intent to the
-implementation is typically referred to as a renderer.
-
-For the Boron release, multiple, simultaneous renderers will not be
-supported. Instead either the VTN or GBP renderer feature can be
-installed, but not both.
-
-For the Boron release, the only actions supported are "ALLOW" and
-"BLOCK". The "ALLOW" action indicates that traffic can flow between the
-source and destination end points, while "BLOCK" prevents that flow;
-although it is possible that an given implementation may augment the
-available actions with additional actions.
-
-Besides transforming a desired state to an actual state it is the
-responsibility of a renderer to update the operational state tree for
-the NIC data model in OpenDaylight to reflect the intent which the
-renderer implemented.
-
-Configuring Network Intent Composition (NIC)
---------------------------------------------
-
-For the Boron release there is no default implementation of a renderer,
-thus without an additional module installed the NIC will not function.
-
-Administering or Managing Network Intent Composition (NIC)
-----------------------------------------------------------
-
-There is no additional administration of management capabilities related
-to the Network Intent Composition features.
-
-Interactions
-------------
-
-A user can interact with the Network Intent Composition (NIC) either
-through the RESTful interface using standard RESTCONF operations and
-syntax or via the Karaf console CLI.
-
-REST
-~~~~
-
-Configuration
-^^^^^^^^^^^^^
-
-The Network Intent Composition (NIC) feature supports the following REST
-operations against the configuration data store.
-
-- POST - creates a new instance of an intent in the configuration
- store, which will trigger the realization of that intent. An ID
- *must* be specified as part of this request as an attribute of the
- intent.
-
-- GET - fetches a list of all configured intents or a specific
- configured intent.
-
-- DELETE - removes a configured intent from the configuration store,
- which triggers the removal of the intent from the network.
-
-Operational
-^^^^^^^^^^^
-
-The Network Intent Composition (NIC) feature supports the following REST
-operations against the operational data store.
-
-- GET - fetches a list of all operational intents or a specific
- operational intent.
-
-Karaf Console CLI
-~~~~~~~~~~~~~~~~~
-
-This feature provides karaf console CLI command to manipulate the intent
-data model. The CLI essentailly invokes the equivalent data operations.
-
-intent:add
-^^^^^^^^^^
-
-Creates a new intent in the configuration data tree
-
-::
-
- DESCRIPTION
- intent:add
-
- Adds an intent to the controller.
-
- Examples: --actions [ALLOW] --from <subject> --to <subject>
- --actions [BLOCK] --from <subject>
-
- SYNTAX
- intent:add [options]
-
- OPTIONS
- -a, --actions
- Action to be performed.
- -a / --actions BLOCK/ALLOW
- (defaults to [BLOCK])
- --help
- Display this help message
- -t, --to
- Second Subject.
- -t / --to <subject>
- (defaults to any)
- -f, --from
- First subject.
- -f / --from <subject>
- (defaults to any)
-
-intent:delete
-^^^^^^^^^^^^^
-
-Removes an existing intent from the system
-
-::
-
- DESCRIPTION
- intent:remove
-
- Removes an intent from the controller.
-
- SYNTAX
- intent:remove id
-
- ARGUMENTS
- id Intent Id
-
-intent:list
-^^^^^^^^^^^
-
-Lists all the intents in the system
-
-::
-
- DESCRIPTION
- intent:list
-
- Lists all intents in the controller.
-
- SYNTAX
- intent:list [options]
-
- OPTIONS
- -c, --config
- List Configuration Data (optional).
- -c / --config <ENTER>
- --help
- Display this help message
-
-intent:show
-^^^^^^^^^^^
-
-Displayes the details of a single intent
-
-::
-
- DESCRIPTION
- intent:show
-
- Shows detailed information about an intent.
-
- SYNTAX
- intent:show id
-
- ARGUMENTS
- id Intent Id
-
-intent:map
-^^^^^^^^^^
-
-List/Add/Delete current state from/to the mapping service.
-
-::
-
- DESCRIPTION
- intent:map
-
- List/Add/Delete current state from/to the mapping service.
-
- SYNTAX
- intent:map [options]
-
- Examples: --list, -l [ENTER], to retrieve all keys.
- --add-key <key> [ENTER], to add a new key with empty contents.
- --del-key <key> [ENTER], to remove a key with it's values."
- --add-key <key> --value [<value 1>, <value 2>, ...] [ENTER],
- to add a new key with some values (json format).
- OPTIONS
- --help
- Display this help message
- -l, --list
- List values associated with a particular key.
- -l / --filter <regular expression> [ENTER]
- --add-key
- Adds a new key to the mapping service.
- --add-key <key name> [ENTER]
- --value
- Specifies which value should be added/delete from the mapping service.
- --value "key=>value"... --value "key=>value" [ENTER]
- (defaults to [])
- --del-key
- Deletes a key from the mapping service.
- --del-key <key name> [ENTER]
-
-NIC Usage Examples
-------------------
-
-Default Requirements
-~~~~~~~~~~~~~~~~~~~~
-
-Start mininet, and create three switches (s1, s2, and s3) and four hosts
-(h1, h2, h3, and h4) in it.
-
-Replace <Controller IP> based on your environment.
-
-::
-
- $ sudo mn --mac --topo single,2 --controller=remote,ip=<Controller IP>
-
-::
-
- mininet> net
- h1 h1-eth0:s2-eth1
- h2 h2-eth0:s2-eth2
- h3 h3-eth0:s3-eth1
- h4 h4-eth0:s3-eth2
- s1 lo: s1-eth1:s2-eth3 s1-eth2:s3-eth3
- s2 lo: s2-eth1:h1-eth0 s2-eth2:h2-eth0 s2-eth3:s1-eth1
- s3 lo: s3-eth1:h3-eth0 s3-eth2:h4-eth0 s3-eth3:s1-eth2
-
-Downloading and deploy Karaf distribution
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- Get the Boron distribution.
-
-- Unzip the downloaded zip distribution.
-
-- To run the Karaf.
-
-::
-
- ./bin/karaf
-
-- Once the console is up, type as below to install feature.
-
-::
-
- feature:install odl-nic-core-mdsal odl-nic-console odl-nic-listeners
-
-Simple Mininet topology
------------------------
-
-.. code:: python
-
- !/usr/bin/python
-
- from mininet.topo import Topo
-
- class SimpleTopology( Topo ):
- "Simple topology example."
-
- def __init__( self ):
- "Create custom topo."
-
-
- Topo.__init__( self )
-
-
- Switch1 = self.addSwitch( 's1' )
- Switch2 = self.addSwitch( 's2' )
- Switch3 = self.addSwitch( 's3' )
- Switch4 = self.addSwitch( 's4' )
- Host11 = self.addHost( 'h1' )
- Host12 = self.addHost( 'h2' )
- Host21 = self.addHost( 'h3' )
- Host22 = self.addHost( 'h4' )
- Host23 = self.addHost( 'h5' )
- Service1 = self.addHost( 'srvc1' )
-
-
- self.addLink( Host11, Switch1 )
- self.addLink( Host12, Switch1 )
- self.addLink( Host21, Switch2 )
- self.addLink( Host22, Switch2 )
- self.addLink( Host23, Switch2 )
- self.addLink( Switch1, Switch2 )
- self.addLink( Switch2, Switch4 )
- self.addLink( Switch4, Switch3 )
- self.addLink( Switch3, Switch1 )
- self.addLink( Switch3, Service1 )
- self.addLink( Switch4, Service1 )
-
-
- topos = { 'simpletopology': ( lambda: SimpleTopology() ) }
-
-- Initialize topology
-
-- Add hosts and switches
-
-- Host used to represent the service
-
-- Add links
-
- Source: https://gist.github.com/vinothgithub15/315d0a427d5afc39f2d7
-
-How to configure VTN Renderer
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The section demonstrates allow or block packets of the traffic within a
-VTN Renderer, according to the specified flow conditions.
-
-The table below lists the actions to be applied when a packet matches
-the condition:
-
-+----------------+-----------------------------------------------------------+
-| Action | Function |
-+================+===========================================================+
-| Allow | Permits the packet to be forwarded normally. |
-+----------------+-----------------------------------------------------------+
-| Block | Discards the packet preventing it from being forwarded. |
-+----------------+-----------------------------------------------------------+
-
-Requirement
-^^^^^^^^^^^
-
-- Before execute the follow steps, please, use default requirements.
- See section `Default Requirements <#_default_requirements>`__.
-
-Configuration
-^^^^^^^^^^^^^
-
-Please execute the following curl commands to test network intent using
-mininet:
-
-Create Intent
-'''''''''''''
-
-To provision the network for the two hosts(h1 and h2) and demonstrates
-the action allow.
-
-::
-
- curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436034 -d '{ "intent:intent" : { "intent:id": "b9a13232-525e-4d8c-be21-cd65e3436034", "intent:actions" : [ { "order" : 2, "allow" : {} } ], "intent:subjects" : [ { "order":1 , "end-point-group" : {"name":"10.0.0.1"} }, { "order":2 , "end-point-group" : {"name":"10.0.0.2"}} ] } }'
-
-To provision the network for the two hosts(h2 and h3) and demonstrates
-the action allow.
-
-::
-
- curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436035 -d '{ "intent:intent" : { "intent:id": "b9a13232-525e-4d8c-be21-cd65e3436035", "intent:actions" : [ { "order" : 2, "allow" : {} } ], "intent:subjects" : [ { "order":1 , "end-point-group" : {"name":"10.0.0.2"} }, { "order":2 , "end-point-group" : {"name":"10.0.0.3"}} ] } }'
-
-Verification
-''''''''''''
-
-As we have applied action type allow now ping should happen between
-hosts (h1 and h2) and (h2 and h3).
-
-::
-
- mininet> pingall
- Ping: testing ping reachability
- h1 -> h2 X X
- h2 -> h1 h3 X
- h3 -> X h2 X
- h4 -> X X X
-
-Update the intent
-'''''''''''''''''
-
-To provision block action that indicates traffic is not allowed between
-h1 and h2.
-
-::
-
- curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436034 -d '{ "intent:intent" : { "intent:id": "b9a13232-525e-4d8c-be21-cd65e3436034", "intent:actions" : [ { "order" : 2, "block" : {} } ], "intent:subjects" : [ { "order":1 , "end-point-group" : {"name":"10.0.0.1"} }, { "order":2 , "end-point-group" : {"name":"10.0.0.2"}} ] } }'
-
-Verification
-''''''''''''
-
-As we have applied action type block now ping should not happen between
-hosts (h1 and h2).
-
-::
-
- mininet> pingall
- Ping: testing ping reachability
- h1 -> X X X
- h2 -> X h3 X
- h3 -> X h2 X
- h4 -> X X X
-
-.. note::
-
- Old actions and hosts are replaced by the new action and hosts.
-
-Delete the intent
-'''''''''''''''''
-
-Respective intent and the traffics will be deleted.
-
-::
-
- curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X DELETE http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436035
-
-Verification
-''''''''''''
-
-Deletion of intent and flow.
-
-::
-
- mininet> pingall
- Ping: testing ping reachability
- h1 -> X X X
- h2 -> X X X
- h3 -> X X X
- h4 -> X X X
-
-.. note::
-
- Ping between two hosts can also be done using MAC Address
-
-To provision the network for the two hosts(h1 MAC address and h2 MAC
-address).
-
-::
-
- curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436035 -d '{ "intent:intent" : { "intent:id": "b9a13232-525e-4d8c-be21-cd65e3436035", "intent:actions" : [ { "order" : 2, "allow" : {} } ], "intent:subjects" : [ { "order":1 , "end-point-group" : {"name":"6e:4f:f7:27:15:c9"} }, { "order":2 , "end-point-group" : {"name":"aa:7d:1f:4a:70:81"}} ] } }'
-
-How to configure Redirect Action
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The section explains the redirect action supported in NIC. The redirect
-functionality supports forwarding (to redirect) the traffic to a service
-configured in SFC before forwarding it to the destination.
-
-.. figure:: ./images/nic/Service_Chaining.png
- :alt: REDIRECT SERVICE
-
- REDIRECT SERVICE
-
-Following steps explain Redirect action function:
-
-- Configure the service in SFC using the SFC APIs.
-
-- Configure the intent with redirect action and the service information
- where the traffic needs to be redirected.
-
-- The flows are computed as below
-
- 1. First flow entry between the source host connected node and the
- ingress node of the configured service.
-
- 2. Second flow entry between the egress Node id the configured
- service and the ID and destination host connected host.
-
- 3. Third flow entry between the destination host node and the source
- host node.
-
-Requirement
-^^^^^^^^^^^
-
-- Save the mininet `Simple Mininet
- topology <#_simple_mininet_topology>`__ script as redirect\_test.py
-
-- Start mininet, and create switches in it.
-
-Replace <Controller IP> based on your environment.
-
-::
-
- sudo mn --controller=remote,ip=<Controller IP>--custom redirect_test.py --topo mytopo2
-
-::
-
- mininet> net
- h1 h1-eth0:s1-eth1
- h2 h2-eth0:s1-eth2
- h3 h3-eth0:s2-eth1
- h4 h4-eth0:s2-eth2
- h5 h5-eth0:s2-eth3
- srvc1 srvc1-eth0:s3-eth3 srvc1-eth1:s4-eth3
- s1 lo: s1-eth1:h1-eth0 s1-eth2:h2-eth0 s1-eth3:s2-eth4 s1-eth4:s3-eth2
- s2 lo: s2-eth1:h3-eth0 s2-eth2:h4-eth0 s2-eth3:h5-eth0 s2-eth4:s1-eth3 s2-eth5:s4-eth1
- s3 lo: s3-eth1:s4-eth2 s3-eth2:s1-eth4 s3-eth3:srvc1-eth0
- s4 lo: s4-eth1:s2-eth5 s4-eth2:s3-eth1 s4-eth3:srvc1-eth1
- c0
-
-Starting the Karaf
-^^^^^^^^^^^^^^^^^^
-
-- Before execute the following steps, please, use the default
- requirements. See section `Downloading and deploy Karaf
- distribution <#_default_requirements>`__.
-
-Configuration
-^^^^^^^^^^^^^
-
-Mininet
-'''''''
-
-.. figure:: ./images/nic/Redirect_flow.png
- :alt: CONFIGURATION THE NETWORK IN MININET
-
- CONFIGURATION THE NETWORK IN MININET
-
-- Configure srvc1 as service node in the mininet environment.
-
-Please execute the following commands in the mininet console (where
-mininet script is executed).
-
-::
-
- srvc1 ip addr del 10.0.0.6/8 dev srvc1-eth0
- srvc1 brctl addbr br0
- srvc1 brctl addif br0 srvc1-eth0
- srvc1 brctl addif br0 srvc1-eth1
- srvc1 ifconfig br0 up
- srvc1 tc qdisc add dev srvc1-eth1 root netem delay 200ms
-
-Configure service in SFC
-''''''''''''''''''''''''
-
-The service (srvc1) is configured using SFC REST API. As part of the
-configuration the ingress and egress node connected the service is
-configured.
-
-::
-
- curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{
- "service-functions": {
- "service-function": [
- {
- "name": "srvc1",
- "sf-data-plane-locator": [
- {
- "name": "Egress",
- "service-function-forwarder": "openflow:4"
- },
- {
- "name": "Ingress",
- "service-function-forwarder": "openflow:3"
- }
- ],
- "nsh-aware": false,
- "type": "delay"
- }
- ]
- }
- }' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function:service-functions/
-
-**SFF RESTCONF Request**
-
-Configuring switch and port information for the service functions.
-
-::
-
- curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{
- "service-function-forwarders": {
- "service-function-forwarder": [
- {
- "name": "openflow:3",
- "service-node": "OVSDB2",
- "sff-data-plane-locator": [
- {
- "name": "Ingress",
- "data-plane-locator":
- {
- "vlan-id": 100,
- "mac": "11:11:11:11:11:11",
- "transport": "service-locator:mac"
- },
- "service-function-forwarder-ofs:ofs-port":
- {
- "port-id" : "3"
- }
- }
- ],
- "service-function-dictionary": [
- {
- "name": "srvc1",
- "sff-sf-data-plane-locator":
- {
- "sf-dpl-name" : "openflow:3",
- "sff-dpl-name" : "Ingress"
- }
- }
- ]
- },
- {
- "name": "openflow:4",
- "service-node": "OVSDB3",
- "sff-data-plane-locator": [
- {
- "name": "Egress",
- "data-plane-locator":
- {
- "vlan-id": 200,
- "mac": "44:44:44:44:44:44",
- "transport": "service-locator:mac"
- },
- "service-function-forwarder-ofs:ofs-port":
- {
- "port-id" : "3"
- }
- }
- ],
- "service-function-dictionary": [
- {
- "name": "srvc1",
- "sff-sf-data-plane-locator":
- {
- "sf-dpl-name" : "openflow:4",
- "sff-dpl-name" : "Egress"
- }
- }
- ]
- }
- ]
- }
- }' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
-
-CLI Command
-'''''''''''
-
-To provision the network for the two hosts (h1 and h5).
-
-Demonstrates the redirect action with service name srvc1.
-
-::
-
- intent:add -f <SOURCE_MAC> -t <DESTINATION_MAC> -a REDIRECT -s <SERVICE_NAME>
-
-Example:
-
-::
-
- intent:add -f 32:bc:ec:65:a7:d1 -t c2:80:1f:77:41:ed -a REDIRECT -s srvc1
-
-Verification
-''''''''''''
-
-- As we have applied action type redirect now ping should happen
- between hosts h1 and h5.
-
-::
-
- mininet> h1 ping h5
- PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
- 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=201 ms
- 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=200 ms
- 64 bytes from 10.0.0.5: icmp_seq=4 ttl=64 time=200 ms
-
-The redirect functionality can be verified by the time taken by the ping
-operation (200ms). The service srvc1 configured using SFC introduces
-200ms delay. As the traffic from h1 to h5 is redirected via the srvc1,
-the time taken by the traffic from h1 to h5 will take about 200ms.
-
-- Flow entries added to nodes for the redirect action.
-
-::
-
- mininet> dpctl dump-flows
- *** s1 ------------------------------------------------------------------------
- NXST_FLOW reply (xid=0x4):
- cookie=0x0, duration=9.406s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=1,dl_src=32:bc:ec:65:a7:d1, dl_dst=c2:80:1f:77:41:ed actions=output:4
- cookie=0x0, duration=9.475s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=3,dl_src=c2:80:1f:77:41:ed, dl_dst=32:bc:ec:65:a7:d1 actions=output:1
- cookie=0x1, duration=362.315s, table=0, n_packets=144, n_bytes=12240, idle_age=4, priority=9500,dl_type=0x88cc actions=CONTROLLER:65535
- cookie=0x1, duration=362.324s, table=0, n_packets=4, n_bytes=168, idle_age=3, priority=10000,arp actions=CONTROLLER:65535,NORMAL
- *** s2 ------------------------------------------------------------------------
- NXST_FLOW reply (xid=0x4):
- cookie=0x0, duration=9.503s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=3,dl_src=c2:80:1f:77:41:ed, dl_dst=32:bc:ec:65:a7:d1 actions=output:4
- cookie=0x0, duration=9.437s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=5,dl_src=32:bc:ec:65:a7:d1, dl_dst=c2:80:1f:77:41:ed actions=output:3
- cookie=0x3, duration=362.317s, table=0, n_packets=144, n_bytes=12240, idle_age=4, priority=9500,dl_type=0x88cc actions=CONTROLLER:65535
- cookie=0x3, duration=362.32s, table=0, n_packets=4, n_bytes=168, idle_age=3, priority=10000,arp actions=CONTROLLER:65535,NORMAL
- *** s3 ------------------------------------------------------------------------
- NXST_FLOW reply (xid=0x4):
- cookie=0x0, duration=9.41s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=2,dl_src=32:bc:ec:65:a7:d1, dl_dst=c2:80:1f:77:41:ed actions=output:3
- *** s4 ------------------------------------------------------------------------
- NXST_FLOW reply (xid=0x4):
- cookie=0x0, duration=9.486s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=3,dl_src=32:bc:ec:65:a7:d1, dl_dst=c2:80:1f:77:41:ed actions=output:1
-
-How to configure QoS Attribute Mapping
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This section explains how to provision QoS attribute mapping constraint
-using NIC OF-Renderer.
-
-The QoS attribute mapping currently supports DiffServ. It uses a 6-bit
-differentiated services code point (DSCP) in the 8-bit differentiated
-services field (DS field) in the IP header.
-
-+----------------+-----------------------------------------------------------+
-| Action | Function |
-+================+===========================================================+
-| Allow | Permits the packet to be forwarded normally, but allows |
-| | for packet header fields, e.g., DSCP, to be modified. |
-+----------------+-----------------------------------------------------------+
-
-The following steps explain QoS Attribute Mapping function:
-
-- Initially configure the QoS profile which contains profile name and
- DSCP value.
-
-- When a packet is transferred from a source to destination, the flow
- builder evaluates whether the transferred packet matches the
- condition such as action, endpoints in the flow.
-
-- If the packet matches the endpoints, the flow builder applies the
- flow matching action and DSCP value.
-
-Requirement
-^^^^^^^^^^^
-
-- Before execute the following steps, please, use the default
- requirements. See section `Default
- Requirements <#_default_requirements>`__.
-
-Configuration
-^^^^^^^^^^^^^
-
-Please execute the following CLI commands to test network intent using
-mininet:
-
-- To apply the QoS constraint, configure the QoS profile.
-
-::
-
- intent:qosConfig -p <qos_profile_name> -d <valid_dscp_value>
-
-Example:
-
-::
-
- intent:qosConfig -p High_Quality -d 46
-
-.. note::
-
- Valid DSCP value ranges from 0-63.
-
-- To provision the network for the two hosts (h1 and h3), add intents
- that allows traffic in both directions by execute the following CLI
- command.
-
-Demonstrates the ALLOW action with constraint QoS and QoS profile name.
-
-::
-
- intent:add -a ALLOW -t <DESTINATION_MAC> -f <SOURCE_MAC> -q QOS -p <qos_profile_name>
-
-Example:
-
-::
-
- intent:add -a ALLOW -t 00:00:00:00:00:03 -f 00:00:00:00:00:01 -q QOS -p High_Quality
- intent:add -a ALLOW -t 00:00:00:00:00:01 -f 00:00:00:00:00:03 -q QOS -p High_Quality
-
-Verification
-''''''''''''
-
-- As we have applied action type ALLOW now ping should happen between
- hosts h1 and h3.
-
-::
-
- mininet> h1 ping h3
- PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
- 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.984 ms
- 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.110 ms
- 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.098 ms
-
-- Verification of the flow entry and ensuring the mod\_nw\_tos is part
- of actions.
-
-::
-
- mininet> dpctl dump-flows
- *** s1 ------------------------------------------------------------------------
- NXST_FLOW reply (xid=0x4):
- cookie=0x0, duration=21.873s, table=0, n_packets=3, n_bytes=294, idle_age=21, priority=9000,dl_src=00:00:00:00:00:03,dl_dst=00:00:00:00:00:01 actions=NORMAL,mod_nw_tos:184
- cookie=0x0, duration=41.252s, table=0, n_packets=3, n_bytes=294, idle_age=41, priority=9000,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:03 actions=NORMAL,mod_nw_tos:184
-
-Requirement
-~~~~~~~~~~~
-
-- Before execute the follow steps, please, use default requirements.
- See section `Default Requirements <#_default_requirements>`__.
-
-How to configure Log Action
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This section demonstrates log action in OF Renderer. This demonstration
-aims at enabling communication between two hosts and logging the flow
-statistics details of the particular traffic.
-
-Configuration
-^^^^^^^^^^^^^
-
-Please execute the following CLI commands to test network intent using
-mininet:
-
-- To provision the network for the two hosts (h1 and h3), add intents
- that allows traffic in both directions by execute the following CLI
- command.
-
-::
-
- intent:add –a ALLOW -t <DESTINATION_MAC> -f <SOURCE_MAC>
-
-Example:
-
-::
-
- intent:add -a ALLOW -t 00:00:00:00:00:03 -f 00:00:00:00:00:01
- intent:add -a ALLOW -t 00:00:00:00:00:01 -f 00:00:00:00:00:03
-
-- To log the flow statistics details of the particular traffic.
-
-::
-
- intent:add –a LOG -t <DESTINATION_MAC> -f <SOURCE_MAC>
-
-Example:
-
-::
-
- intent:add -a LOG -t 00:00:00:00:00:03 -f 00:00:00:00:00:01
-
-Verification
-''''''''''''
-
-- As we have applied action type ALLOW now ping should happen between
- hosts h1 and h3.
-
-::
-
- mininet> h1 ping h3
- PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
- 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.984 ms
- 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.110 ms
- 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.098 ms
-
-- To view the flow statistics log details such as, byte count, packet
- count and duration, check the karaf.log.
-
-::
-
- 2015-12-15 22:56:20,256 | INFO | lt-dispatcher-23 | IntentFlowManager | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Creating block intent for endpoints: source00:00:00:00:00:01 destination 00:00:00:00:00:03
- 2015-12-15 22:56:20,252 | INFO | lt-dispatcher-29 | FlowStatisticsListener | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Flow Statistics gathering for Byte Count:Counter64 [_value=238]
- 2015-12-15 22:56:20,252 | INFO | lt-dispatcher-29 | FlowStatisticsListener | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Flow Statistics gathering for Packet Count:Counter64 [_value=3]
- 2015-12-15 22:56:20,252 | INFO | lt-dispatcher-29 | FlowStatisticsListener | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Flow Statistics gathering for Duration in Nano second:Counter32 [_value=678000000]
- 2015-12-15 22:56:20,252 | INFO | lt-dispatcher-29 | FlowStatisticsListener | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Flow Statistics gathering for Duration in Second:Counter32 [_value=49]
-
+++ /dev/null
-.. _ocpplugin-user-guide:
-
-OCP Plugin User Guide
-=====================
-
-This document describes how to use the ORI Control & Management Protocol
-(OCP) feature in OpenDaylight. This document contains overview, scope,
-architecture and design, installation, configuration and tutorial
-sections for the feature.
-
-Overview
---------
-
-OCP is an ETSI standard protocol for control and management of Remote
-Radio Head (RRH) equipment. The OCP Project addresses the need for a
-southbound plugin that allows applications and controller services to
-interact with RRHs using OCP. The OCP southbound plugin will allow
-applications acting as a Radio Equipment Control (REC) to interact with
-RRHs that support an OCP agent.
-
-.. figure:: ./images/ocpplugin/ocp-sb-plugin.jpg
- :alt: OCP southbound plugin
-
- OCP southbound plugin
-
-It is foreseen that, in 5G, C-RAN will use the packet-based
-Transport-SDN (T-SDN) as the fronthaul network to transport both control
-plane and user plane data between RRHs and BBUs. As a result, the
-addition of the OCP plugin to OpenDaylight will make it possible to
-build an RRH controller on top of OpenDaylight to centrally manage
-deployed RRHs, as well as integrating the RRH controller with T-SDN on
-one single platform, achieving the joint RRH and fronthaul network
-provisioning in C-RAN.
-
-Scope
------
-
-The OCP Plugin project includes:
-
-- OCP v4.1.1 support
-
-- Integration of OCP protocol library
-
-- Simple API invoked as a RPC
-
-- Simple API that allows applications to perform elementary functions
- of the following categories:
-
- - Device management
-
- - Config management
-
- - Object lifecycle
-
- - Object state management
-
- - Fault management
-
- - Software management (not yet implemented)
-
-- Indication processing
-
-- Logging (not yet implemented)
-
-- AISG/Iuant interface message tunnelling (not yet implemented)
-
-- ALD connection management (not yet implemented)
-
-Architecture and Design
------------------------
-
-OCP is a vendor-neutral standard communications interface defined to
-enable control and management between RE and REC of an ORI architecture.
-The OCP Plugin supports the implementation of the OCP specification; it
-is based on the Model Driven Service Abstraction Layer (MD-SAL)
-architecture.
-
-OCP Plugin will support the following functionality:
-
-- Connection handling
-
-- Session management
-
-- State management
-
-- Error handling
-
-- Connection establishment will be handled by OCP library using
- opensource netty.io library
-
-- Message handling
-
-- Event/indication handling and propagation to upper layers
-
-**Activities in OCP plugin module**
-
-- Integration with OCP protocol library
-
-- Integration with corresponding MD-SAL infrastructure
-
-OCP protocol library is a component in OpenDaylight that mediates
-communication between OpenDaylight controller and RRHs supporting OCP
-protocol. Its primary goal is to provide the OCP Plugin with
-communication channel that can be used for managing RRHs.
-
-Key objectives:
-
-- Immutable transfer objects generation (transformation of OCP protocol
- library’s POJO objects into OpenDaylight DTO objects)
-
-- Scalable non-blocking implementation
-
-- Pipeline processing
-
-- Scatter buffer
-
-- TLS support
-
-OCP Service addresses the need for a northbound interface that allows
-applications and other controller services to interact with RRHs using
-OCP, by providing API for abstracting OCP operations.
-
-.. figure:: ./images/ocpplugin/plugin-design.jpg
- :alt: Overall architecture
-
- Overall architecture
-
-Message Flow
-------------
-
-.. figure:: ./images/ocpplugin/message_flow.jpg
- :alt: Message flow example
-
- Message flow example
-
-Installation
-------------
-
-The OCP Plugin project has two top level Karaf features,
-odl-ocpplugin-all and odl-ocpjava-all, which contain the following
-sub-features:
-
-- odl-ocpplugin-southbound
-
-- odl-ocpplugin-app-ocp-service
-
-- odl-ocpjava-protocol
-
-The OCP service (odl-ocpplugin-app-ocp-service), together with the OCP
-southbound (odl-ocpplugin-southbound) and OCP protocol library
-(odl-ocpjava-protocol), provides OpenDaylight with basic OCP v4.1.1
-functionality.
-
-You can interact with OCP service via RESTCONF, so you have to install
-the following features to enable RESTCONF.
-
-::
-
- karaf#>feature:install odl-restconf odl-l2switch-switch odl-mdsal-apidocs
-
-Then install the odl-ocpplugin-all feature which includes the
-odl-ocpplugin-southbound and odl-ocpplugin-app-ocp-service features.
-Note that the odl-ocpjava-all feature will be installed automatically as
-the odl-ocpplugin-southbound feature is dependent on the
-odl-ocpjava-protocol feature.
-
-::
-
- karaf#>feature:install odl-ocpplugin-all
-
-After all required features are installed, use following command from
-karaf console to check and make sure features are correctly installed
-and initialized.
-
-::
-
- karaf#>feature:list | grep ocp
-
-Configuration
--------------
-
-Configuring the OCP plugin can be done via its configuration file,
-62-ocpplugin.xml, which can be found in the
-<odl-install-dir>/etc/opendaylight/karaf/ directory.
-
-There are the following settings that are configurable:
-
-1. **port** specifies the port number on which the OCP plugin listens
- for connection requests
-
-2. **radioHead-idle-timeout** determines the time duration (unit:
- milliseconds) for which a radio head has been idle before the idle
- event is triggered to perform health check
-
-3. **ocp-version** specifies the OCP protocol version supported by the
- OCP plugin
-
-4. **rpc-requests-quota** sets the maximum number of concurrent rpc
- requests allowed
-
-5. **global-notification-quota** sets the maximum number of concurrent
- notifications allowed
-
-.. figure:: ./images/ocpplugin/plugin-config.jpg
- :alt: OCP plugin configuration
-
- OCP plugin configuration
-
-Test Environment
-----------------
-
-The OCP Plugin project contains a simple OCP agent for testing purposes;
-the agent has been designed specifically to act as a fake radio head
-device, giving you an idea of what it would look like during the OCP
-handshake taking place between the OCP agent and OpenDaylight (OCP
-plugin).
-
-To run the simple OCP agent, you have to first download its JAR file
-from OpenDaylight Nexus Repository.
-
-::
-
- wget https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/ocpplugin/simple-agent/${ocp-version}/simple-agent-${ocp-version}.jar
-
-Then run the agent with no arguments (assuming you already have JDK 1.8
-or above installed) and it should display the usage that lists the
-expected arguments.
-
-::
-
- java -classpath simple-agent-${ocp-version}.jar org.opendaylight.ocpplugin.OcpAgent
-
- Usage: java org.opendaylight.ocpplugin.OcpAgent <controller's ip address> <port number> <vendor id> <serial number>
-
-Here is an example:
-
-::
-
- java -classpath simple-agent-${ocp-version}.jar org.opendaylight.ocpplugin.OcpAgent 127.0.0.1 1033 XYZ 123
-
-Programmatic Interface
-----------------------
-
-The OCP Plugin project has implemented a complete set of the C&M
-operations (elementary functions) defined in the OCP specification, in
-the form of both northbound and southbound APIs, including:
-
-- health-check
-
-- set-time
-
-- re-reset
-
-- get-param
-
-- modify-param
-
-- create-obj
-
-- delete-obj
-
-- get-state
-
-- modify-state
-
-- get-fault
-
-The API is documented in the OCP Plugin Developer Guide under the
-section Southbound API and Northbound API, respectively.
+++ /dev/null
-.. _sdni-user-guide:
-
-ODL-SDNi User Guide
-===================
-
-Introduction
-------------
-
-This user guide will help to setup the ODL-SDNi application.
-
-Components
-----------
-
-SDNiAggregator, SDNi API, SDNiWrapper, and SDNiUI are the four
-components in ODL-SDNi App:
-
-- SDNiAggregator: Connects with switch, topology, hosttracker managers
- of controller to get the topology and other related data.
-
-- SDNi REST API: It is a part of controller northbound, which gives the
- required information by quering SDNiAggregator through RESTCONF.
-
-- SDNiWrapper: This component uses the SDNi REST API and gathers the
- information required to be shared among controllers.
-
-- SDNiUI:This component displays all the SDN controllers which are
- connected to each other.
-
-Troubleshooting
----------------
-
-To work with multiple controllers, change some of the configuration in
-config.ini file. For example change the listening port of one controller
-to 6653 and other controller to 6663 in
-/root/controller/opendaylight/distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini
-(i.e., of.listenPort=6653).
-
-**OpenFlow related system parameters.**
-
-TCP port on which the controller is listening (default 6633)
-of.listenPort=6653
+++ /dev/null
-.. _ofconfig-user-guide:
-
-OF-CONFIG User Guide
-====================
-
-Overview
---------
-
-OF-CONFIG defines an OpenFlow switch as an abstraction called an
-OpenFlow Logical Switch. The OF-CONFIG protocol enables configuration of
-essential artifacts of an OpenFlow Logical Switch so that an OpenFlow
-controller can communicate and control the OpenFlow Logical switch via
-the OpenFlow protocol. OF-CONFIG introduces an operating context for one
-or more OpenFlow data paths called an OpenFlow Capable Switch for one or
-more switches. An OpenFlow Capable Switch is intended to be equivalent
-to an actual physical or virtual network element (e.g. an Ethernet
-switch) which is hosting one or more OpenFlow data paths by partitioning
-a set of OpenFlow related resources such as ports and queues among the
-hosted OpenFlow data paths. The OF-CONFIG protocol enables dynamic
-association of the OpenFlow related resources of an OpenFlow Capable
-Switch with specific OpenFlow Logical Switches which are being hosted on
-the OpenFlow Capable Switch. OF-CONFIG does not specify or report how
-the partitioning of resources on an OpenFlow Capable Switch is achieved.
-OF-CONFIG assumes that resources such as ports and queues are
-partitioned amongst multiple OpenFlow Logical Switches such that each
-OpenFlow Logical Switch can assume full control over the resources that
-is assigned to it.
-
-How to start
-------------
-
-- start OF-CONFIG feature as below:
-
- ::
-
- feature:install odl-of-config-all
-
-Configuration on the OVS supporting OF-CONFIG
----------------------------------------------
-
-.. note::
-
- OVS is not supported by OF-CONFIG temporarily because the
- OpenDaylight version of OF-CONFIG is 1.2 while the OVS version of
- OF-CONFIG is not standard.
-
-The introduction of configuring the OVS can be referred to:
-
-*https://github.com/openvswitch/of-config.*
-
-Connection Establishment between the Capable/Logical Switch and OF-CONFIG
--------------------------------------------------------------------------
-
-The OF-CONFIG protocol is based on NETCONF. So the switches supporting
-OF-CONFIG can also access OpenDaylight using the functions provided by
-NETCONF. This is the preparation step before connecting to OF-CONFIG.
-How to access the switch to OpenDaylight using the NETCONF can be
-referred to the `NETCONF Southbound User
-Guide <#_southbound_netconf_connector>`__ or `NETCONF Southbound
-examples on the
-wiki <https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf>`__.
-
-Now the switches supporting OF-CONFIG and they have connected to the
-controller using NETCONF as described in preparation phase. OF-CONFIG
-can check whether the switch can support OF-CONFIG by reading the
-capability list in NETCONF.
-
-The OF-CONFIG will get the information of the capable switch and logical
-switch via the NETCONF connection, and creates separate topologies for
-the capable and logical switches in the OpenDaylight Topology module.
-
-The Connection between the capable/logical switches and OF-CONFIG is
-finished.
-
-Configuration On Capable Switch
--------------------------------
-
-Here is an example showing how to make the configuration to
-modify-controller-connection on the capable switch using OF-CONFIG.
-Other configurations can follow the same way of the example.
-
-- Example: modify-controller-connection
-
-.. note::
-
- this configuration can execute via the NETCONF, which can be
- referred to the `NETCONF Southbound User
- Guide <#_southbound_netconf_connector>`__ or `NETCONF Southbound
- examples on the
- wiki <https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf>`__.
-
At this point you should have two interfaces one which gives you NATed
access to the internet and another that gives you access between your
mac and the VMs. At least for me, the NATed interface gets a 10.0.2.x
-address and the the host-only interface gets a 192.168.56.x address.
+address and the host-only interface gets a 192.168.56.x address.
Your simplest choice: Use Vagrant
'''''''''''''''''''''''''''''''''
+++ /dev/null
-.. _opflex-agent-ovs-user-guide:
-
-OpFlex agent-ovs User Guide
-===========================
-
-Introduction
-------------
-
-agent-ovs is a policy agent that works with OVS to enforce a group-based
-policy networking model with locally attached virtual machines or
-containers. The policy agent is designed to work well with orchestration
-tools like OpenStack.
-
-Agent Configuration
--------------------
-
-The agent configuration is handled using its config file which is by
-default found at "/etc/opflex-agent-ovs/opflex-agent-ovs.conf"
-
-Here is an example configuration file that documents the available
-options:
-
-::
-
- {
- // Logging configuration
- // "log": {
- // // Set the log level.
- // // Possible values in descending order of verbosity:
- // // "debug7"-"debug0", "debug" (synonym for "debug0"),
- // // "info", "warning", "error", "fatal"
- // // Default: "info"
- // "level": "info"
- // },
-
- // Configuration related to the OpFlex protocol
- "opflex": {
- // The policy domain for this agent.
- "domain": "openstack",
-
- // The unique name in the policy domain for this agent.
- "name": "example-agent",
-
- // a list of peers to connect to, by hostname and port. One
- // peer, or an anycast pseudo-peer, is sufficient to bootstrap
- // the connection without needing an exhaustive list of all
- // peers.
- "peers": [
- // EXAMPLE:
- // {"hostname": "10.0.0.30", "port": 8009}
- ],
-
- "ssl": {
- // SSL mode. Possible values:
- // disabled: communicate without encryption (default)
- // encrypted: encrypt but do not verify peers
- // secure: encrypt and verify peer certificates
- "mode": "encrypted",
-
- // The path to a directory containing trusted certificate
- // authority public certificates, or a file containing a
- // specific CA certificate.
- // Default: "/etc/ssl/certs"
- "ca-store": "/etc/ssl/certs"
- },
-
- "inspector": {
- // Enable the MODB inspector service, which allows
- // inspecting the state of the managed object database.
- // Default: true
- "enabled": true,
-
- // Listen on the specified socket for the inspector
- // Default: "/var/run/opflex-agent-ovs-inspect.sock"
- "socket-name": "/var/run/opflex-agent-ovs-inspect.sock"
- },
-
- "notif": {
- // Enable the agent notification service, which sends
- // notifications to interested listeners over a UNIX
- // socket.
- // Default: true
- "enabled": true,
-
- // Listen on the specified socket for the inspector
- // Default: "/var/run/opflex-agent-ovs-notif.sock"
- "socket-name": "/var/run/opflex-agent-ovs-notif.sock",
-
- // Set the socket owner user after binding if the user
- // exists
- // Default: do not set the owner
- // "socket-owner": "root",
-
- // Set the socket group after binding if the group name
- // exists
- // Default: do not set the group
- "socket-group": "opflexep",
-
- // Set the socket permissions after binding to the
- // specified octal permissions mask
- // Default: do not set the permissions
- "socket-permissions": "770"
- }
- },
-
- // Endpoint sources provide metadata about local endpoints
- "endpoint-sources": {
- // Filesystem path to monitor for endpoint information
- // Default: no endpoint sources
- "filesystem": ["/var/lib/opflex-agent-ovs/endpoints"]
- },
-
- // Service sources provide metadata about services that can
- // provide functionality for local endpoints
- "service-sources": {
- // Filesystem path to monitor for service information
- // Default: no service sources
- "filesystem": ["/var/lib/opflex-agent-ovs/services"]
- },
-
- // Renderers enforce policy obtained via OpFlex.
- // Default: no renderers
- "renderers": {
- // Stitched-mode renderer for interoperating with a
- // hardware fabric such as ACI
- // EXAMPLE:
- "stitched-mode": {
- // "Integration" bridge used to enforce contracts and forward
- // packets
- "int-bridge-name": "br-int",
-
- // "Access" bridge used to enforce access control and enforce
- // security groups.
- "access-bridge-name": "br-access",
-
- // Set encapsulation type. Must set either vxlan or vlan.
- "encap": {
- // Encapsulate traffic with VXLAN.
- "vxlan" : {
- // The name of the tunnel interface in OVS
- "encap-iface": "br0_vxlan0",
-
- // The name of the interface whose IP should be used
- // as the source IP in encapsulated traffic.
- "uplink-iface": "team0.4093",
-
- // The vlan tag, if any, used on the uplink interface.
- // Set to zero or omit if the uplink is untagged.
- "uplink-vlan": 4093,
-
- // The IP address used for the destination IP in
- // the encapsulated traffic. This should be an
- // anycast IP address understood by the upstream
- // stiched-mode fabric.
- "remote-ip": "10.0.0.32",
-
- // UDP port number of the encapsulated traffic.
- "remote-port": 8472
- }
-
- // Encapsulate traffic with a locally-significant VLAN
- // tag
- // EXAMPLE:
- // "vlan" : {
- // // The name of the uplink interface in OVS
- // "encap-iface": "team0"
- // }
- },
-
- // Configure forwarding policy
- "forwarding": {
- // Configure the virtual distributed router
- "virtual-router": {
- // Enable virtual distributed router. Set to true
- // to enable or false to disable.
- // Default: true.
- "enabled": true,
-
- // Override MAC address for virtual router.
- // Default: "00:22:bd:f8:19:ff"
- "mac": "00:22:bd:f8:19:ff",
-
- // Configure IPv6-related settings for the virtual
- // router
- "ipv6" : {
- // Send router advertisement messages in
- // response to router solicitation requests as
- // well as unsolicited advertisements. This
- // is not required in stitched mode since the
- // hardware router will send them.
- "router-advertisement": false
- }
- },
-
- // Configure virtual distributed DHCP server
- "virtual-dhcp": {
- // Enable virtual distributed DHCP server. Set to
- // true to enable or false to disable.
- // Default: true
- "enabled": true,
-
- // Override MAC address for virtual dhcp server.
- // Default: "00:22:bd:f8:19:ff"
- "mac": "00:22:bd:f8:19:ff"
- },
-
- "endpoint-advertisements": {
- // Set mode for generation of periodic ARP/NDP
- // advertisements for endpoints. Possible values:
- // disabled: Do not send advertisements
- // gratuitous-unicast: Send gratuitous endpoint
- // advertisements as unicast packets to the router
- // mac.
- // gratuitous-broadcast: Send gratuitous endpoint
- // advertisements as broadcast packets.
- // router-request: Unicast a spoofed request/solicitation
- // for the subnet's gateway router.
- // Default: router-request.
- "mode": "gratuitous-broadcast"
- }
- },
-
- // Location to store cached IDs for managing flow state
- // Default: "/var/lib/opflex-agent-ovs/ids"
- "flowid-cache-dir": "/var/lib/opflex-agent-ovs/ids",
-
- // Location to write multicast groups for the mcast-daemon
- // Default: "/var/lib/opflex-agent-ovs/mcast/opflex-groups.json"
- "mcast-group-file": "/var/lib/opflex-agent-ovs/mcast/opflex-groups.json"
- }
- }
- }
-
-Endpoint Registration
----------------------
-
-The agent learns about endpoints using endpoint metadata files located
-by default in "/var/lib/opflex-agent-ovs/endpoints".
-
-These are JSON-format files such as the (unusually complex) example
-below:
-
-::
-
- {
- "uuid": "83f18f0b-80f7-46e2-b06c-4d9487b0c754",
- "policy-space-name": "test",
- "endpoint-group-name": "group1",
- "interface-name": "veth0",
- "ip": [
- "10.0.0.1", "fd8f:69d8:c12c:ca62::1"
- ],
- "dhcp4": {
- "ip": "10.200.44.2",
- "prefix-len": 24,
- "routers": ["10.200.44.1"],
- "dns-servers": ["8.8.8.8", "8.8.4.4"],
- "domain": "example.com",
- "static-routes": [
- {
- "dest": "169.254.169.0",
- "dest-prefix": 24,
- "next-hop": "10.0.0.1"
- }
- ]
- },
- "dhcp6": {
- "dns-servers": ["2001:4860:4860::8888", "2001:4860:4860::8844"],
- "search-list": ["test1.example.com", "example.com"]
- },
- "ip-address-mapping": [
- {
- "uuid": "91c5b217-d244-432c-922d-533c6c036ab4",
- "floating-ip": "5.5.5.1",
- "mapped-ip": "10.0.0.1",
- "policy-space-name": "common",
- "endpoint-group-name": "nat-epg"
- },
- {
- "uuid": "22bfdc01-a390-4b6f-9b10-624d4ccb957b",
- "floating-ip": "fdf1:9f86:d1af:6cc9::1",
- "mapped-ip": "fd8f:69d8:c12c:ca62::1",
- "policy-space-name": "common",
- "endpoint-group-name": "nat-epg"
- }
- ],
- "mac": "00:00:00:00:00:01",
- "promiscuous-mode": false
- }
-
-The possible parameters for these files are:
-
-**uuid**
- A globally unique ID for the endpoint
-
-**endpoint-group-name**
- The name of the endpoint group for the endpoint
-
-**policy-space-name**
- The name of the policy space for the endpoint group.
-
-**interface-name**
- The name of the OVS interface to which the endpoint is attached
-
-**ip**
- A list of strings contains either IPv4 or IPv6 addresses that the
- endpoint is allowed to use
-
-**mac**
- The MAC address for the endpoint’s interface.
-
-**promiscuous-mode**
- Allow traffic from this VM to bypass default port security
-
-**dhcp4**
- A distributed DHCPv4 configuration block (see below)
-
-**dhcp6**
- A distributed DHCPv6 configuration block (see below)
-
-**ip-address-mapping**
- A list of IP address mapping configuration blocks (see below)
-
-DHCPv4 configuration blocks can contain the following parameters:
-
-**ip**
- the IP address to return with DHCP. Must be one of the configured
- IPv4 addresses.
-
-**prefix**
- the subnet prefix length
-
-**routers**
- a list of default gateways for the endpoint
-
-**dns**
- a list of DNS server addresses
-
-**domain**
- The domain name parameter to send in the DHCP reply
-
-**static-routes**
- A list of static route configuration blocks, which contains a
- "dest", "dest-prefix", and "next-hop" parameters to send as static
- routes to the end host
-
-DHCPv6 configuration blocks can contain the following parameters:
-
-**dns**
- A list of DNS servers for the endpoint
-
-**search-patch**
- The DNS search path for the endpoint
-
-IP address mapping configuration blocks can contain the following
-parameters:
-
-**uuid**
- a globally unique ID for the virtual endpoint created by the
- mapping.
-
-**floating-ip**
- Map using DNAT to this floating IPv4 or IPv6 address
-
-**mapped-ip**
- the source IPv4 or IPv6 address; must be one of the IPs assigned to
- the endpoint.
-
-**endpoint-group-name**
- The name of the endpoint group for the NATed IP
-
-**policy-space-name**
- The name of the policy space for the NATed IP
-
-Inspector
----------
-
-The Opflex inspector is a useful command-line tool that will allow you
-to inspect the state of the managed object database for the agent for
-debugging and diagnosis purposes.
-
-The command is called "gbp\_inspect" and takes the following arguments:
-
-::
-
- # gbp_inspect -h
- Usage: gbp_inspect [options]
- Allowed options:
- -h [ --help ] Print this help message
- --log arg Log to the specified file (default
- standard out)
- --level arg (=warning) Use the specified log level (default
- warning)
- --syslog Log to syslog instead of file or
- standard out
- --socket arg (=/usr/var/run/opflex-agent-ovs-inspect.sock)
- Connect to the specified UNIX domain
- socket (default /usr/var/run/opfl
- ex-agent-ovs-inspect.sock)
- -q [ --query ] arg Query for a specific object with
- subjectname,uri or all objects of a
- specific type with subjectname
- -r [ --recursive ] Retrieve the whole subtree for each
- returned object
- -f [ --follow-refs ] Follow references in returned objects
- --load arg Load managed objects from the specified
- file into the MODB view
- -o [ --output ] arg Output the results to the specified
- file (default standard out)
- -t [ --type ] arg (=tree) Specify the output format: tree,
- asciitree, list, or dump (default tree)
- -p [ --props ] Include object properties in output
-
-Here are some examples of the ways to use this tool.
-
-You can get information about the running system using one or more
-queries, which consist of an object model class name and optionally the
-URI of a specific object. The simplest query is to get a single object,
-nonrecursively:
-
-::
-
- # gbp_inspect -q DmtreeRoot
- ───⦁ DmtreeRoot,/
- # gbp_inspect -q GbpEpGroup
- ───⦁ GbpEpGroup,/PolicyUniverse/PolicySpace/test/GbpEpGroup/group1/
- ───⦁ GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
- # gbp_inspect -q GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
- ───⦁ GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
-
-You can also display all the properties for each object:
-
-::
-
- # gbp_inspect -p -q GbpeL24Classifier
- ───⦁ GbpeL24Classifier,/PolicyUniverse/PolicySpace/test/GbpeL24Classifier/classifier4/
- {
- connectionTracking : 1 (reflexive)
- dFromPort : 80
- dToPort : 80
- etherT : 2048 (ipv4)
- name : classifier4
- prot : 6
- }
- ───⦁ GbpeL24Classifier,/PolicyUniverse/PolicySpace/test/GbpeL24Classifier/classifier3/
- {
- etherT : 34525 (ipv6)
- name : classifier3
- order : 100
- prot : 58
- }
- ───⦁ GbpeL24Classifier,/PolicyUniverse/PolicySpace/test/GbpeL24Classifier/classifier1/
- {
- etherT : 2054 (arp)
- name : classifier1
- order : 102
- }
- ───⦁ GbpeL24Classifier,/PolicyUniverse/PolicySpace/test/GbpeL24Classifier/classifier2/
- {
- etherT : 2048 (ipv4)
- name : classifier2
- order : 101
- prot : 1
- }
-
-You can also request to get the all the children of an object you query
-for:
-
-::
-
- # gbp_inspect -r -q GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
- ──┬⦁ GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
- ├──⦁ GbpeInstContext,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/GbpeInstContext/
- ╰──⦁ GbpEpGroupToNetworkRSrc,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/GbpEpGroupToNetworkRSrc/
-
-You can also follow references found in any object downloads:
-
-::
-
- # gbp_inspect -fr -q GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
- ──┬⦁ GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
- ├──⦁ GbpeInstContext,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/GbpeInstContext/
- ╰──⦁ GbpEpGroupToNetworkRSrc,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/GbpEpGroupToNetworkRSrc/
- ──┬⦁ GbpBridgeDomain,/PolicyUniverse/PolicySpace/common/GbpBridgeDomain/bd_ext/
- ╰──⦁ GbpBridgeDomainToNetworkRSrc,/PolicyUniverse/PolicySpace/common/GbpBridgeDomain/bd_ext/GbpBridgeDomainToNetworkRSrc/
- ──┬⦁ GbpFloodDomain,/PolicyUniverse/PolicySpace/common/GbpFloodDomain/fd_ext/
- ╰──⦁ GbpFloodDomainToNetworkRSrc,/PolicyUniverse/PolicySpace/common/GbpFloodDomain/fd_ext/GbpFloodDomainToNetworkRSrc/
- ──┬⦁ GbpRoutingDomain,/PolicyUniverse/PolicySpace/common/GbpRoutingDomain/rd_ext/
- ├──⦁ GbpRoutingDomainToIntSubnetsRSrc,/PolicyUniverse/PolicySpace/common/GbpRoutingDomain/rd_ext/GbpRoutingDomainToIntSubnetsRSrc/152/%2fPolicyUniverse%2fPolicySpace%2fcommon%2fGbpSubnets%2fsubnets_ext%2f/
- ╰──⦁ GbpForwardingBehavioralGroupToSubnetsRSrc,/PolicyUniverse/PolicySpace/common/GbpRoutingDomain/rd_ext/GbpForwardingBehavioralGroupToSubnetsRSrc/
- ──┬⦁ GbpSubnets,/PolicyUniverse/PolicySpace/common/GbpSubnets/subnets_ext/
- ├──⦁ GbpSubnet,/PolicyUniverse/PolicySpace/common/GbpSubnets/subnets_ext/GbpSubnet/subnet_ext4/
- ╰──⦁ GbpSubnet,/PolicyUniverse/PolicySpace/common/GbpSubnets/subnets_ext/GbpSubnet/subnet_ext6/
+++ /dev/null
-.. _packetcable-user-guide:
-
-PacketCable User Guide
-======================
-
-Overview
---------
-
-These components introduce a DOCSIS QoS Gates management using the PCMM
-protocol. The driver component is responsible for the PCMM/COPS/PDP
-functionality required to service requests from PacketCable Provider and
-FlowManager. Requests are transposed into PCMM Gate Control messages and
-transmitted via COPS to the CMTS. This plugin adheres to the
-PCMM/COPS/PDP functionality defined in the CableLabs specification.
-PacketCable solution is an MDSAL compliant component.
-
-PacketCable Components
-----------------------
-
-PacketCable is comprised of two OpenDaylight bundles:
-
-+--------------------------------------+--------------------------------------+
-| Bundle | Description |
-+======================================+======================================+
-| odl-packetcable-policy-server | Plugin that provides PCMM model |
-| | implementation based on CMTS |
-| | structure and COPS protocol. |
-+--------------------------------------+--------------------------------------+
-| odl-packetcable-policy-model | The Model provided provides a direct |
-| | mapping to the underlying QoS Gates |
-| | of CMTS. |
-+--------------------------------------+--------------------------------------+
-
-See the PacketCable `YANG
-Models <https://git.opendaylight.org/gerrit/gitweb?p=packetcable.git;a=tree;f=packetcable-policy-model/src/main/yang>`__.
-
-Installing PacketCable
-----------------------
-
-To install PacketCable, run the following ``feature:install`` command
-from the Karaf CLI
-
-::
-
- feature:install odl-packetcable-policy-server-all odl-restconf odl-mdsal-apidocs
-
-Explore and exercise the PacketCable REST API
----------------------------------------------
-
-To see the PacketCable APIs, browse to this URL:
-http://localhost:8181/apidoc/explorer/index.html
-
-Replace localhost with the IP address or hostname where OpenDaylight is
-running if you are not running OpenDaylight locally on your machine.
-
-.. note::
-
- Prior to setting any PCMM gates, a CCAP must first be added.
-
-Postman
--------
-
-`Install the Chrome
-extension <https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en>`__
-
-`Download and import sample packetcable
-collection <https://git.opendaylight.org/gerrit/gitweb?p=packetcable.git;a=tree;f=packetcable-policy-server/doc/restconf-samples>`__
-
-Postman Operations
-^^^^^^^^^^^^^^^^^^
-
-.. figure:: ./images/packetcable-postman.png
- :alt: Postman Operations
-
- Postman Operations
-
-
-
-PacketCable REST API Usage Examples
------------------------------------
-
-* CCAP "CONFIG" DATASTORE API STRUCTURE
-
- * Add and view CCAPConfigDatastore(add triggers also the CCAP COPS connection)::
-
- PUT http://localhost:8181/restconf/config/packetcable:ccaps/ccap/CMTS-1
-
- {"ccap":[
- {"ccapId":"CMTS-1",
- "amId": {
- "am-tag": 51930,
- "am-type": 1
- },
- "connection": {
- "ipAddress": "10.20.30.40",
- "port":3918
- },"subscriber-subnets": [
- "2001:4978:030d:1000:0:0:0:0/52",
- "44.137.0.0/16"
- ],"upstream-scns": [
- "SCNA",
- "extrm_up"
- ],"downstream-scns": [
- "extrm_dn",
- "ipvideo_dn",
- "SCNC"
- ]}
- ]}
-
- GET http://localhost:8181/restconf/config/packetcable:ccaps/ccap/CMTS-1
-
-
-* CCAP OPERATIONAL STATUS - GET CCAP (COPS) CONNECTION STATUS
-
- * Shows the Operational Datastorecontents for the CCAP COPS connection.
- * The status is updated when the COPS connection is initiated or after an RPC poll::
-
- GET http://localhost:8181/restconf/operational/packetcable:ccaps/ccap/CMTS-1/
- Response: 200 OK
-
- {
- "ccap": [
- {
- "ccapId": "CMTS-1",
- "connection": {
- "error": [
- "E6-CTO: CCAP client is connected"
- ],
- "timestamp": "2016-03-23T14:15:54.129-05:00",
- "connected": true
- }
- }
- ]
- }
-
-
-* CCAP OPERATIONAL STATUS - RPC CCAP POLL CONNECTION
-
- * A CCAP RPC poll returns the COPS connectivity status info and also triggers an Operational Datastore status update with the same data::
-
- POST http://localhost:8181/restconf/operations/packetcable:ccap-poll-connection
- {
- "input": {
- "ccapId": "/packetcable:ccaps/packetcable:ccap[packetcable:ccapId='CMTS-1']"
- }
- }
- Response: 200 OK
- {
- "output": {
- "response": "CMTS-1: CCAP poll complete",
- "timestamp": "2016-03-23T14:15:54.131-05:00",
- "ccap": {
- "ccapId": "CMTS-1",
- "connection": {
- "connection": {
- "error": [
- "CMTS-1: CCAP client is connected"
- ],
- "timestamp": "2016-03-23T14:15:54.129-05:00",
- "connected": true
- }
- }
- }
- }
- }
-
-* CCAP OPERATIONAL STATUS - RPC CCAP POLL CONNECTION (2) - CONNECTION DOWN::
-
- POST http://localhost:8181/restconf/operations/packetcable:ccap-poll-connection
- {
- "input": {
- "ccapId": "/packetcable:ccaps/packetcable:ccap[packetcable:ccapId='CMTS-1']"
- }
- }
- Response: 200 OK
- {
- "output": {
- "response": "CMTS-1: CCAP poll complete",
- "timestamp": "2016-03-23T14:15:54.131-05:00",
- "ccap": {
- "ccapId": "CMTS-1",
- "connection": {
- "error": [
- "CMTS-1: CCAP client is disconnected with error: null",
- "CMTS-1: CCAP Cops socket is closed"],
- "timestamp": "2016-03-23T14:15:54.129-05:00",
- "connected": false
- }
- }
- }
- }
-
-
-* CCAP OPERATIONAL STATUS - RPC CCAP SET CONNECTION
-
- * A CCAP RPC sets the CCAP COPS connection; possible values true or false meaning that the connection should be up or down.
- * RPC responds with the same info as RPC POLL CONNECTION, and also updates the Operational Datastore::
-
- POST http://localhost:8181/restconf/operations/packetcable:ccap-set-connection
- {
- "input": {
- "ccapId": "/packetcable:ccaps/packetcable:ccap[packetcable:ccapId='CMTS-1']",
- "connection": {
- "connected": true
- }
- }
- }
- Response: 200 OK
- {
- "output": {
-
- "response": "CMTS-1: CCAP set complete",
- "timestamp": "2016-03-23T17:47:29.446-05:00",
- "ccap": {
- "ccapId": "CMTS-1",
- "connection": {
- "error": [
- "CMTS-1: CCAP client is connected",
- "CMTS-1: CCAP COPS socket is already open"],
- "timestamp": "2016-03-23T17:47:29.436-05:00",
- "connected": true
- }
- }
- }
- }
-
-* CCAP OPERATIONAL STATUS - RPC CCAP SET CONNECTION (2) - SHUTDOWN COPS CONNECTION::
-
- POST http://localhost:8181/restconf/operations/packetcable:ccap-set-connection
- {
- "input": {
- "ccapId": "/packetcable:ccaps/packetcable:ccap[packetcable:ccapId='E6-CTO']",
- "connection": {
- "connected": false
- }
- }
- }
- Response: 200 OK
- {
- "output": {
- "response": "E6-CTO: CCAP set complete",
- "timestamp": "2016-03-23T17:47:29.446-05:00",
- "ccap": {
- "ccapId": "E6-CTO",
- "connection": {
- "error": [
- "E60CTO: CCAP client is disconnected with error: null"],
- "timestamp": "2016-03-23T17:47:29.436-05:00",
- "connected": false
- }
- }
- }
- }
-
-.. note::
- A "null" in the error information means that the CCAP connection has been disconnected as a result of a RPC SET.
-
-* GATES "CONFIG" DATASTORE API STRUCTURE CHANGED
-
- * A CCAP RPC poll returns the gate status info, and also triggers a Operational Datastorestatus update.
- * At a minimum the appIdneeds to be included in the input, subscriberIdand gateIdare optional.
- * A gate status response is only included if the RPC request is done for a specific gate (subscriberIdand gateIdincluded in input).
- * Add and retrieve gates to/from the Config Datastore::
-
- PUT http://localhost:8181/restconf/config/packetcable:qos/apps/app/cto-app/subscribers/subscriber/44.137.0.12/gates/gate/gate88/
-
- {
- "gate": [
- {
- "gateId": "gate88",
- "gate0spec": {
- "dscp-tos-overwrite": "0xa0",
- "dscp-tos-mask": "0xff"
- },
- "traffic-profile": {
- "service-class-name": "extrm_dn"
- },
- "classifiers": {
- "classifier-container": [
- {
- "classifier-id": "1",
- "classifier": {
- "srcIp": "44.137.0.0",
- "dstIp": "44.137.0.11",
- "protocol": "0",
- "srcPort": "1234",
- "dstPort": "4321",
- "tos-byte": "0xa0",
- "tos-mask": "0xe0"
- }
- }
- ]
- }
- }
- ]
- }
-
- GET http://localhost:8181/restconf/config/packetcable:qos/apps/app/cto-app/subscribers/subscriber/44.137.0.12/gates/gate/gate88/
-
-
-* GATES SUPPORT MULTIPLE (UP TO FOUR) CLASSIFIERS
-
- * Please note that there is a classifier container now that can have up to four classifiers::
-
- PUT http://localhost:8181/restconf/config/packetcable:qos/apps/app/cto-app/subscribers/subscriber/44.137.0.12/gates/gate/gate88/
- { "gate":{
- "gateId": "gate44",
- "gate-spec": {
- "dscp-tos-overwrite": "0xa0",
- "dscp-tos-mask": "0xff" },
- "traffic-profile": {
- "service-class-name": "extrm_dn"},
- "classifiers":
- { "classifier-container":[
- { "classifier-id": "1",
- "ipv6-classifier": {
- "srcIp6": "2001:4978:030d:1100:0:0:0:0/64",
- "dstIp6": "2001:4978:030d:1000:0:0:0:0/64",
- "flow-label": "102",
- "tc-low": "0xa0",
- "tc-high": "0xc0",
- "tc-mask": "0xe0",
- "next-hdr": "256",
- "srcPort-start": "4321",
- "srcPort-end": "4322",
- "dstPort-start": "1234",
- "dstPort-end": "1235"
- }},
- { "classifier-id": "2",
- "ext-classifier" : {
- "srcIp": "44.137.0.12",
- "srcIpMask": "255.255.255.255",
- "dstIp": "10.10.10.0",
- "dstIpMask": "255.255.255.0",
- "tos-byte": "0xa0",
- "tos-mask": "0xe0",
- "protocol": "0",
- "srcPort-start": "4321",
- "srcPort-end": "4322",
- "dstPort-start": "1234",
- "dstPort-end": "1235"
- }
- }]
- }
- }
- }
-
-
-* CCAP OPERATIONAL STATUS - GET GATE STATUS FROM OPERATIONAL DATASTORE
-
- * Shows the Operational Datastore contents for the gate.
- * The gate status is updated at the time when the gate is configured or during an RPC poll::
-
- GET http://localhost:8181/restconf/operational/packetcable:qos/apps/app/cto-app/subscribers/subscriber/44.137.0.12/gates/gate/gate88
-
- Response: 200
- {
- "gate":[{
- "gateId":"gate88",
- "cops-gate-usage-info": "0",
- "cops-gate-state": "Committed(4)/Other(-1)",
- "gatePath": "cto-app/44.137.0.12/gate88",
- "cops-gate-time-info": "0",
- "cops-gateId": "3e0800e9",
- "timestamp": "2016-03-24T10:30:18.763-05:00",
- "ccapId": "E6-CTO"
- }]
- }
-
-
-* CCAP OPERATIONAL STATUS - RPC GATE STATUS POLL
-
- * A CCAP RPC poll returns the gate status info and also triggers an Operational Datastore status update.
- * At a minimum, the appId needs to be included in the input; subscriberId and gateId are optional.
- * A gate status response is only included if the RPC request is done for a specific gate (subscriberId and gateId included in input)::
-
- POST http://localhost:8181/restconf/operations/packetcable:qos-poll-gates
- {
- "input": {
- "appId": "/packetcable:apps/packetcable:apps[packetcable:appId='cto-app]",
- "subscriberId": "44.137.0.11",
- "gateId": "gate44"
- }
- }
- Response: 200 OK
- {
- "output": {
- "gate": {
- "cops-gate-usage-info": "0",
- "cops-gate-state": "Committed(4)/Other(-1)",
- "gatePath": "ctoapp/44.137.0.12/gate88",
- "cops-gate-time-info": "0",
- "cops-gateId": "1ceb0001",
- "error": [""],
- "timestamp": "2016-03-24T13:22:59.900-05:00",
- "ccapId": "E6-CTO"
- },
- "response": "cto-app/44.137.0.12/gate88: gate poll complete",
- "timestamp": "2016-03-24T13:22:59.906-05:00"
- }
- }
-
- * When multiple gates are polled (only appId or appId and subscriberId are provided), a generic response is returned and the Operational Datastore is updated in the background::
-
- { "output": {
- "gate": {},
- "response": "cto-app/: gate subtree poll in progress",
- "timestamp": "2016-03-24T13:25:30.471-05:00"
- }
- }
creation of a Rendered Service Path (RSP) in the operational data store,
and once received it programs Service Function Forwarders (SFF) that
are hosted on OpenFlow capable switches to forward packets through the
-service chain.
+service chain. Currently the only tested OpenFlow capable switch is
+OVS 2.9.
Common acronyms used in the following sections:
Here are two example on SFF1: one where the RSP ingress tunnel is MPLS
assuming VLAN is used for the SFF-SF, and the other where the RSP
-ingress tunnel is NSH GRE (UDP port 4789):
+ingress tunnel is either Eth+NSH or just NSH with no ethernet.
+----------+-------------------------------------+--------------+
| Priority | Match | Action |
+----------+-------------------------------------+--------------+
| 256 | EtherType==0x8100 (VLAN) | Goto Table 2 |
+----------+-------------------------------------+--------------+
-| 256 | EtherType==0x0800,udp,tp\_dst==4789 | Goto Table 2 |
-| | (IP v4) | |
+| 250 | EtherType==0x894f (Eth+NSH) | Goto Table 2 |
++----------+-------------------------------------+--------------+
+| 250 | PacketType==0x894f (NSH no Eth) | Goto Table 2 |
+----------+-------------------------------------+--------------+
| 5 | Match Any | Drop |
+----------+-------------------------------------+--------------+
+
Table: Table Transport Ingress
Path Mapper Table detailed
+----------+--------------------------------+--------------------------------+
| 246 | RSP Path==1 | MacDst=SF1, Goto Table 10 |
+----------+--------------------------------+--------------------------------+
-| 256 | nsp=3,nsi=255 (SFF Ingress RSP | load:0xa000002→NXM\_NX\_TUN\_I |
-| | 3) | PV4\_DST[], |
-| | | Goto Table 10 |
+| 550 | dl_type=0x894f, | load:0xa000002→ |
+| | nsh_spi=3,nsh_si=255 | NXM\_NX\_TUN\_IPV4\_DST[], |
+| | (NSH, SFF Ingress RSP 3, hop 1)| Goto Table 10 |
+----------+--------------------------------+--------------------------------+
-| 256 | nsp=3,nsi=254 (SFF Ingress | load:0xa00000a→NXM\_NX\_TUN\_I |
-| | from SF, RSP 3) | PV4\_DST[], |
-| | | Goto Table 10 |
+| 550 | dl_type=0x894f | load:0xa00000a→ |
+| | nsh_spi=3,nsh_si=254 | NXM\_NX\_TUN\_IPV4\_DST[], |
+| | (NSH, SFF Ingress from SF, | Goto Table 10 |
+| | RSP 3, hop 2) | |
+----------+--------------------------------+--------------------------------+
-| 256 | nsp=4,nsi=254 (SFF1 Ingress | load:0xa00000a→NXM\_NX\_TUN\_I |
-| | from SFF2) | PV4\_DST[], |
-| | | Goto Table 10 |
+| 550 | dl_type=0x894f, | load:0xa00000a→ |
+| | nsh_spi=4,nsh_si=254 | NXM\_NX\_TUN\_IPV4\_DST[], |
+| | (NSH, SFF1 Ingress from SFF2) | Goto Table 10 |
+----------+--------------------------------+--------------------------------+
| 5 | Match Any | Drop |
+----------+--------------------------------+--------------------------------+
| 246 | RSP Path==2 | Push MPLS Label 100, |
| | | Port=Ingress |
+----------+--------------------------------+--------------------------------+
-| 256 | nsp=3,nsi=255 (SFF Ingress RSP | IN\_PORT |
-| | 3) | |
+| 256 | in_port=1,dl_type=0x894f | IN\_PORT |
+| | nsh_spi=0x3,nsh_si=255 | |
+| | (NSH, SFF Ingress RSP 3) | |
+----------+--------------------------------+--------------------------------+
-| 256 | nsp=3,nsi=254 (SFF Ingress | IN\_PORT |
-| | from SF, RSP 3) | |
-+----------+--------------------------------+--------------------------------+
-| 256 | nsp=4,nsi=254 (SFF1 Ingress | IN\_PORT |
-| | from SFF2) | |
-+----------+--------------------------------+--------------------------------+
-| 5 | Match Any | Drop |
+| 256 | in_port=1,dl_type=0x894f, | IN\_PORT |
+| | nsh_spi=0x3,nsh_si=254 | |
+| | (NSH,SFF Ingress from SF,RSP 3)| |
+----------+--------------------------------+--------------------------------+
+| 256 | in_port=1,dl_type=0x894f, | IN\_PORT |
+| | nsh_spi=0x4,nsh_si=254 | |
+| | (NSH, SFF1 Ingress from SFF2) | |
++---------+---------------------------------+--------------------------------+
+| 5 | Match Any | Drop |
++---------+---------------------------------+--------------------------------+
Table: Table Transport Egress
| **MPLS Service Function Path configuration**
The Service Function Path configuration can be sent with the following
-command:
+command. This will internally trigger the Rendered Service Paths to be
+created.
.. code-block:: bash
}
}
-| **MPLS Rendered Service Path creation**
-
-.. code-block:: bash
-
- curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache"
- --data '${JSON}' -X POST --user admin:admin
- http://localhost:8181/restconf/operations/rendered-service-path:create-rendered-path/
-
-| **MPLS Rendered Service Path Query**
-
-The following command can be used to query all of the created Rendered
-Service Paths:
+The following command can be used to query all of the Rendered Service
+Paths that were created when the Service Function Path was created:
.. code-block:: bash
+++ /dev/null
-.. _snmp-user-guide:
-
-SNMP Plugin User Guide
-======================
-
-Installing Feature
-------------------
-
-The SNMP Plugin can be installed using a single karaf feature:
-**odl-snmp-plugin**
-
-After starting Karaf:
-
-- Install the feature: **feature:install odl-snmp-plugin**
-
-- Expose the northbound API: **feature:install odl-restconf**
-
-Northbound APIs
----------------
-
-There are two exposed northbound APIs: snmp-get & snmp-set
-
-SNMP GET
-~~~~~~~~
-
-Default URL: http://localhost:8181/restconf/operations/snmp:snmp-get
-
-POST Input
-^^^^^^^^^^
-
-+----------------+----------------+----------------+----------------+----------------+
-| Field Name | Type | Description | Example | Required? |
-+================+================+================+================+================+
-| ip-address | Ipv4 Address | The IPv4 | 10.86.3.13 | Yes |
-| | | Address of the | | |
-| | | desired | | |
-| | | network node | | |
-+----------------+----------------+----------------+----------------+----------------+
-| oid | String | The Object | 1.3.6.1.2.1.1. | Yes |
-| | | Identifier of | 1 | |
-| | | the desired | | |
-| | | MIB | | |
-| | | table/object | | |
-+----------------+----------------+----------------+----------------+----------------+
-| get-type | ENUM (GET, | The type of | GET-BULK | Yes |
-| | GET-NEXT, | get request to | | |
-| | GET-BULK, | send | | |
-| | GET-WALK) | | | |
-+----------------+----------------+----------------+----------------+----------------+
-| community | String | The community | private | No. (Default: |
-| | | string to use | | public) |
-| | | for the SNMP | | |
-| | | request | | |
-+----------------+----------------+----------------+----------------+----------------+
-
-**Example.**
-
-::
-
- {
- "input": {
- "ip-address": "10.86.3.13",
- "oid" : "1.3.6.1.2.1.1.1",
- "get-type" : "GET-BULK",
- "community" : "private"
- }
- }
-
-POST Output
-^^^^^^^^^^^
-
-+--------------------------+--------------------------+--------------------------+
-| Field Name | Type | Description |
-+==========================+==========================+==========================+
-| results | List of { "value" : | The results of the SNMP |
-| | String } pairs | query |
-+--------------------------+--------------------------+--------------------------+
-
-**Example.**
-
-::
-
- {
- "snmp:results": [
- {
- "value": "Ethernet0/0/0",
- "oid": "1.3.6.1.2.1.2.2.1.2.1"
- },
- {
- "value": "FastEthernet0/0/0",
- "oid": "1.3.6.1.2.1.2.2.1.2.2"
- },
- {
- "value": "GigabitEthernet0/0/0",
- "oid": "1.3.6.1.2.1.2.2.1.2.3"
- }
- ]
- }
-
-SNMP SET
-~~~~~~~~
-
-Default URL: http://localhost:8181/restconf/operations/snmp:snmp-set
-
-POST Input
-^^^^^^^^^^
-
-+----------------+----------------+----------------+----------------+----------------+
-| Field Name | Type | Description | Example | Required? |
-+================+================+================+================+================+
-| ip-address | Ipv4 Address | The Ipv4 | 10.86.3.13 | Yes |
-| | | address of the | | |
-| | | desired | | |
-| | | network node | | |
-+----------------+----------------+----------------+----------------+----------------+
-| oid | String | The Object | 1.3.6.2.1.1.1 | Yes |
-| | | Identifier of | | |
-| | | the desired | | |
-| | | MIB object | | |
-+----------------+----------------+----------------+----------------+----------------+
-| value | String | The value to | "Hello World" | Yes |
-| | | set on the | | |
-| | | network device | | |
-+----------------+----------------+----------------+----------------+----------------+
-| community | String | The community | private | No. (Default: |
-| | | string to use | | public) |
-| | | for the SNMP | | |
-| | | request | | |
-+----------------+----------------+----------------+----------------+----------------+
-
-**Example.**
-
-::
-
- {
- "input": {
- "ip-address": "10.86.3.13",
- "oid" : "1.3.6.1.2.1.1.1.0",
- "value" : "Sample description",
- "community" : "private"
- }
- }
-
-POST Output
-^^^^^^^^^^^
-
-On a successful SNMP-SET, no output is presented, just a HTTP status of
-200.
-
-Errors
-^^^^^^
-
-If any errors happen in the set request, you will be presented with an
-error message in the output.
-
-For example, on a failed set request you may see an error like:
-
-::
-
- {
- "errors": {
- "error": [
- {
- "error-type": "application",
- "error-tag": "operation-failed",
- "error-message": "SnmpSET failed with error status: 17, error index: 1. StatusText: Not writable"
- }
- ]
- }
- }
-
-which corresponds to Error status 17 in the SNMPv2 RFC:
-https://tools.ietf.org/html/rfc1905.
-
+++ /dev/null
-.. _sxp-user-guide:
-
-SXP User Guide
-==============
-
-Overview
---------
-
-SXP (Scalable-Group Tag eXchange Protocol) project is an effort to enhance
-OpenDaylight platform with IP-SGT (IP Address to Source Group Tag)
-bindings that can be learned from connected SXP-aware network nodes. The
-current implementation supports SXP protocol version 4 according to the
-Smith, Kandula - SXP `IETF
-draft <https://tools.ietf.org/html/draft-smith-kandula-sxp-06>`__ and
-grouping of peers and creating filters based on ACL/Prefix-list syntax
-for filtering outbound and inbound IP-SGT bindings. All protocol legacy
-versions 1-3 are supported as well. Additionally, version 4 adds
-bidirectional connection type as an extension of a unidirectional one.
-
-SXP Architecture
-----------------
-
-The SXP Server manages all connected clients in separate threads and a
-common SXP protocol agreement is used between connected peers. Each SXP
-network peer is modelled with its pertaining class, e.g., SXP Server
-represents the SXP Speaker, SXP Listener the Client. The server program
-creates the ServerSocket object on a specified port and waits until a
-client starts up and requests connect on the IP address and port of the
-server. The client program opens a Socket that is connected to the
-server running on the specified host IP address and port.
-
-The SXP Listener maintains connection with its speaker peer. From an
-opened channel pipeline, all incoming SXP messages are processed by
-various handlers. Message must be decoded, parsed and validated.
-
-The SXP Speaker is a counterpart to the SXP Listener. It maintains a
-connection with its listener peer and sends composed messages.
-
-The SXP Binding Handler extracts the IP-SGT binding from a message and
-pulls it into the SXP-Database. If an error is detected during the
-IP-SGT extraction, an appropriate error code and sub-code is selected
-and an error message is sent back to the connected peer. All transitive
-messages are routed directly to the output queue of SXP Binding
-Dispatcher.
-
-The SXP Binding Dispatcher represents a selector that will decides how
-many data from the SXP-database will be sent and when. It is responsible
-for message content composition based on maximum message length.
-
-The SXP Binding Filters handles filtering of outgoing and incoming
-IP-SGT bindings according to BGP filtering using ACL and Prefix List
-syntax for specifying filter or based on Peer-sequence length.
-
-The SXP Domains feature provides isolation of SXP peers and bindings
-learned between them, also exchange of Bindings is possible across
-SXP-Domains by ACL, Prefix List or Peer-Sequence filters
-
-Configuring SXP
----------------
-
-SXP requires no manual configuration.
-
-Administering or Managing SXP
------------------------------
-
-By RPC (response is XML document containing requested data or operation
-status):
-
-- Get Connections POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:get-connections
-
-::
-
- <input xmlns:xsi="urn:opendaylight:sxp:controller">
- <domain-name>global</domain-name>
- <requested-node>0.0.0.100</requested-node>
- </input>
-
-- Add Connection POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:add-connection
-
-::
-
- <input xmlns:xsi="urn:opendaylight:sxp:controller">
- <requested-node>0.0.0.100</requested-node>
- <domain-name>global</domain-name>
- <connections>
- <connection>
- <peer-address>172.20.161.50</peer-address>
- <tcp-port>64999</tcp-port>
- <!-- Password setup: default | none leave empty -->
- <password>default</password>
- <!-- Mode: speaker/listener/both -->
- <mode>speaker</mode>
- <version>version4</version>
- <description>Connection to ASR1K</description>
- <!-- Timers setup: 0 to disable specific timer usability, the default value will be used -->
- <connection-timers>
- <!-- Speaker -->
- <hold-time-min-acceptable>45</hold-time-min-acceptable>
- <keep-alive-time>30</keep-alive-time>
- </connection-timers>
- </connection>
- <connection>
- <peer-address>172.20.161.178</peer-address>
- <tcp-port>64999</tcp-port>
- <!-- Password setup: default | none leave empty-->
- <password>default</password>
- <!-- Mode: speaker/listener/both -->
- <mode>listener</mode>
- <version>version4</version>
- <description>Connection to ISR</description>
- <!-- Timers setup: 0 to disable specific timer usability, the default value will be used -->
- <connection-timers>
- <!-- Listener -->
- <reconciliation-time>120</reconciliation-time>
- <hold-time>90</hold-time>
- <hold-time-min>90</hold-time-min>
- <hold-time-max>180</hold-time-max>
- </connection-timers>
- </connection>
- </connections>
- </input>
-
-- Delete Connection POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:delete-connection
-
-::
-
- <input xmlns:xsi="urn:opendaylight:sxp:controller">
- <requested-node>0.0.0.100</requested-node>
- <domain-name>global</domain-name>
- <peer-address>172.20.161.50</peer-address>
- </input>
-
-- Add/Update Bindings POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:add-bindings
-
-::
-
- <input xmlns="urn:opendaylight:sxp:controller">
- <node-id>0.0.0.100</node-id>
- <domain-name>global</domain-name>
- <origin>LOCAL</origin>
- <master-database>
- <binding>
- <sgt>50</sgt>
- <ip-prefix>192.168.2.1/32</ip-prefix>
- <ip-prefix>192.168.2.2/32</ip-prefix>
- </binding>
- <binding>
- <sgt>100</sgt>
- <ip-prefix>192.168.3.1/32</ip-prefix>
- <ip-prefix>192.168.3.2/32</ip-prefix>
- </binding>
- </master-database>
- </input>
-
-- Delete Bindings POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:delete-bindings
-
-::
-
- <input xmlns="urn:opendaylight:sxp:controller">
- <node-id>0.0.0.100</node-id>
- <domain-name>global</domain-name>
- <binding>
- <sgt>50</sgt>
- <ip-prefix>192.168.2.2/32</ip-prefix>
- </binding>
- <binding>
- <sgt>100</sgt>
- <ip-prefix>192.168.3.2/32</ip-prefix>
- </binding>
- </input>
-
-- Get Node Bindings
-
- This RPC gets particular device bindings. An SXP-aware node is
- identified with a unique Node-ID. If a user requests bindings for a
- Speaker 20.0.0.2, the RPC will search for an appropriate path, which
- contains 20.0.0.2 Node-ID, within locally learnt SXP data in the SXP
- database and replies with associated bindings. POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:get-node-bindings
-
-::
-
- <input xmlns:xsi="urn:opendaylight:sxp:controller">
- <requested-node>20.0.0.2</requested-node>
- <bindings-range>all</bindings-range>
- <domain-name>global</domain-name>
- </input>
-
-- Get Binding SGTs POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:get-binding-sgts
-
-::
-
- <input xmlns:xsi="urn:opendaylight:sxp:controller">
- <requested-node>0.0.0.100</requested-node>
- <domain-name>global</domain-name>
- <ip-prefix>192.168.12.2/32</ip-prefix>
- </input>
-
-- Add PeerGroup with or without filters to node. POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:add-peer-group
-
-::
-
- <input xmlns="urn:opendaylight:sxp:controller">
- <requested-node>127.0.0.1</requested-node>
- <sxp-peer-group>
- <name>TEST</name>
- <sxp-peers>
- </sxp-peers>
- <sxp-filter>
- <filter-type>outbound</filter-type>
- <acl-entry>
- <entry-type>deny</entry-type>
- <entry-seq>1</entry-seq>
- <sgt-start>1</sgt-start>
- <sgt-end>100</sgt-end>
- </acl-entry>
- <acl-entry>
- <entry-type>permit</entry-type>
- <entry-seq>45</entry-seq>
- <matches>1</matches>
- <matches>3</matches>
- <matches>5</matches>
- </acl-entry>
- </sxp-filter>
- </sxp-peer-group>
- </input>
-
-- Delete PeerGroup with peer-group-name from node request-node. POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:delete-peer-group
-
-::
-
- <input xmlns="urn:opendaylight:sxp:controller">
- <requested-node>127.0.0.1</requested-node>
- <peer-group-name>TEST</peer-group-name>
- </input>
-
-- Get PeerGroup with peer-group-name from node request-node. POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:get-peer-group
-
-::
-
- <input xmlns="urn:opendaylight:sxp:controller">
- <requested-node>127.0.0.1</requested-node>
- <peer-group-name>TEST</peer-group-name>
- </input>
-
-- Add Filter to peer group on node request-node. POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:add-filter
-
-::
-
- <input xmlns="urn:opendaylight:sxp:controller">
- <requested-node>127.0.0.1</requested-node>
- <peer-group-name>TEST</peer-group-name>
- <sxp-filter>
- <filter-type>outbound</filter-type>
- <acl-entry>
- <entry-type>deny</entry-type>
- <entry-seq>1</entry-seq>
- <sgt-start>1</sgt-start>
- <sgt-end>100</sgt-end>
- </acl-entry>
- <acl-entry>
- <entry-type>permit</entry-type>
- <entry-seq>45</entry-seq>
- <matches>1</matches>
- <matches>3</matches>
- <matches>5</matches>
- </acl-entry>
- </sxp-filter>
- </input>
-
-- Delete Filter from peer group on node request-node. POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:delete-filter
-
-::
-
- <input xmlns="urn:opendaylight:sxp:controller">
- <requested-node>127.0.0.1</requested-node>
- <peer-group-name>TEST</peer-group-name>
- <filter-type>outbound</filter-type>
- </input>
-
-- Update Filter of the same type in peer group on node request-node.
- POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:update-filter
-
-::
-
- <input xmlns="urn:opendaylight:sxp:controller">
- <requested-node>127.0.0.1</requested-node>
- <peer-group-name>TEST</peer-group-name>
- <sxp-filter>
- <filter-type>outbound</filter-type>
- <acl-entry>
- <entry-type>deny</entry-type>
- <entry-seq>1</entry-seq>
- <sgt-start>1</sgt-start>
- <sgt-end>100</sgt-end>
- </acl-entry>
- <acl-entry>
- <entry-type>permit</entry-type>
- <entry-seq>45</entry-seq>
- <matches>1</matches>
- <matches>3</matches>
- <matches>5</matches>
- </acl-entry>
- </sxp-filter>
- </input>
-
-- Add new SXP aware Node POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:add-node
-
-::
-
- <input xmlns="urn:opendaylight:sxp:controller">
- <node-id>1.1.1.1</node-id>
- <source-ip>0.0.0.0</source-ip>
- <timers>
- <retry-open-time>5</retry-open-time>
- <hold-time-min-acceptable>120</hold-time-min-acceptable>
- <delete-hold-down-time>120</delete-hold-down-time>
- <hold-time-min>90</hold-time-min>
- <reconciliation-time>120</reconciliation-time>
- <hold-time>90</hold-time>
- <hold-time-max>180</hold-time-max>
- <keep-alive-time>30</keep-alive-time>
- </timers>
- <mapping-expanded>150</mapping-expanded>
- <security>
- <password>password</password>
- </security>
- <tcp-port>64999</tcp-port>
- <version>version4</version>
- <description>ODL SXP Controller</description>
- </input>
-
-- Delete SXP aware node POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:delete-node
-
-::
-
- <input xmlns="urn:opendaylight:sxp:controller">
- <node-id>1.1.1.1</node-id>
- </input>
-
-- Add SXP Domain on node request-node. POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:add-domain
-
-::
-
- <input xmlns="urn:opendaylight:sxp:controller">
- <node-id>1.1.1.1</node-id>
- <domain-name>global</domain-name>
- </input>
-
-- Delete SXP Domain on node request-node. POST
- http://127.0.0.1:8181/restconf/operations/sxp-controller:delete-domain
-
-::
-
- <input xmlns="urn:opendaylight:sxp:controller">
- <node-id>1.1.1.1</node-id>
- <domain-name>global</domain-name>
- </input>
-
-- Add Route Adds route to leader Node. PUT
- http://127.0.0.1:8181/restconf/config/sxp-cluster-route:sxp-cluster-route/
-
-::
-
- <sxp-cluster-route xmlns="urn:opendaylight:sxp:cluster:route">
- <routing-definition>
- <ip-address>80.12.43.2</ip-address>
- <interface>eth1:0</interface>
- <netmask>255.255.255.0</netmask>
- </routing-definition>
- </sxp-cluster-route>
-
-Use cases for SXP
-~~~~~~~~~~~~~~~~~
-
-Cisco has a wide installed base of network devices supporting SXP. By
-including SXP in OpenDaylight, the binding of policy groups to IP
-addresses can be made available for possible further processing to a
-wide range of devices, and applications running on OpenDaylight. The
-range of applications that would be enabled is extensive. Here are just
-a few of them:
-
-OpenDaylight based applications can take advantage of the IP-SGT binding
-information. For example, access control can be defined by an operator
-in terms of policy groups, while OpenDaylight can configure access
-control lists on network elements using IP addresses, e.g., existing
-technology.
-
-Interoperability between different vendors. Vendors have different
-policy systems. Knowing the IP-SGT binding for Cisco makes it possible
-to maintain policy groups between Cisco and other vendors.
-
-OpenDaylight can aggregate the binding information from many devices and
-communicate it to a network element. For example, a firewall can use the
-IP-SGT binding information to know how to handle IPs based on the
-group-based ACLs it has set. But to do this with SXP alone, the firewall
-has to maintain a large number of network connections to get the binding
-information. This incurs heavy overhead costs to maintain all of the SXP
-peering and protocol information. OpenDaylight can aggregate the
-IP-group information so that the firewall need only connect to
-OpenDaylight. By moving the information flow outside of the network
-elements to a centralized position, we reduce the overhead of the CPU
-consumption on the enforcement element. This is a huge savings - it
-allows the enforcement point to only have to make one connection rather
-than thousands, so it can concentrate on its primary job of forwarding
-and enforcing.
-
-OpenDaylight can relay the binding information from one network element
-to others. Changes in group membership can be propagated more readily
-through a centralized model. For example, in a security application a
-particular host (e.g., user or IP Address) may be found to be acting
-suspiciously or violating established security policies. The defined
-response is to put the host into a different source group for
-remediation actions such as a lower quality of service, restricted
-access to critical servers, or special routing conditions to ensure
-deeper security enforcement (e.g., redirecting the host’s traffic
-through an IPS with very restrictive policies). Updated group membership
-for this host needs to be communicated to multiple network elements as
-soon as possible; a very efficient and effective method of propagation
-can be performed using OpenDaylight as a centralized point for relaying
-the information.
-
-OpenDaylight can create filters for exporting and receiving IP-SGT
-bindings used on specific peer groups, thus can provide more complex
-maintaining of policy groups.
-
-Although the IP-SGT binding is only one specific piece of information,
-and although SXP is implemented widely in a single vendor’s equipment,
-bringing the ability of OpenDaylight to process and distribute the
-bindings, is a very specific immediate useful implementation of policy
-groups. It would go a long way to develop both the usefulness of
-OpenDaylight and of policy groups.
+++ /dev/null
-ElasticSearch
--------------
-
-Setting Up the environment
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To setup and run the TSDR data store ElasticSearch feature, you need to have
-an ElasticSearch node (or a cluster of such nodes) running. You can use a
-customized ElasticSearch docker image for this purpose.
-
-Your ElasticSearch (ES) setup must have the "Delete By Query Plugin" installed.
-Without this, some of the ES functionality won't work properly.
-
-
-Creating a custom ElasticSearch docker image
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-(You can skip this section if you already have an instance of ElasticSearch running)
-
-Run the following set of commands:
-
-.. code-block:: bash
-
- cat << EOF > Dockerfile
- FROM elasticsearch:2
- RUN /usr/share/elasticsearch/bin/plugin install --batch delete-by-query
- EOF
-
-To build the image, run the following command in the directory where the
-Dockerfile was created:
-
-.. code-block:: bash
-
- docker build . -t elasticsearch-dd
-
-You can check whether the image was properly created by running:
-
-.. code-block:: bash
-
- docker images
-
-This should print all your container images including the elasticsearch-dd.
-
-Now we can create and run a container from our image by typing:
-
-.. code-block:: bash
-
- docker run -d -p 9200:9200 -p 9300:9300 --name elasticsearch-dd elasticsearch-dd
-
-To see whether the container is running, run the following command:
-
-.. code-block:: bash
-
- docker ps
-
-The output should include a row with elasticsearch-dd in the NAMES column.
-To check the std out of this container use
-
-.. code-block:: bash
-
- docker logs elasticsearch-dd
-
-Running the ElasticSearch feature
----------------------------------
-
-Once the features have been installed, you can change some of its properties. For
-example, to setup the URL where your ElasticSearch installation runs,
-change the *serverUrl* parameter in tsdr/persistence-elasticsearch/src/main/resources/configuration/initial/:
-
-.. code-block:: bash
-
- tsdr-persistence-elasticsearch.properties
-
-All the data are stored into the TSDR index under a type. The metric data are
-stored under the metric type and the log data are store under the log type.
-You can modify the files in tsdr/persistence-elasticsearch/src/main/resources/configuration/initial/:
-
-.. code-block:: bash
-
- tsdr-persistence-elasticsearch_metric_mapping.json
- tsdr-persistence-elasticsearch_log_mapping.json
-
-to change or tune the mapping for those types. The changes in those files will be promoted after
-the feature is reloaded or the distribution is restarted.
-
-Testing the setup
-^^^^^^^^^^^^^^^^^
-
-We can now test whether the setup is correct by downloading and installing mininet,
-which we use to send some data to the running ElasticSearch instance.
-
-Installing the necessary features:
-
-.. code-block:: bash
-
- start OpenDaylight
- feature:install odl-restconf odl-l2switch-switch odl-tsdr-core odl-tsdr-openflow-statistics-collector
- feature:install odl-tsdr-elasticsearch
-
-We can check whether the distribution is now listening on port 6653:
-
-.. code-block:: bash
-
- netstat -an | grep 6653
-
-Run mininet
-
-.. code-block:: bash
-
- sudo mn --topo single,3 --controller 'remote,ip=distro_ip,port=6653' --switch ovsk,protocols=OpenFlow13
-
-where the distro_ip is the IP address of the machine where the OpenDaylight distribution
-is running. This command will create three hosts connected to one OpenFlow capable
-switch.
-
-We can check if data was stored by ElasticSearch in TSDR by running the
-following command:
-
-.. code-block:: bash
-
- tsdr:list FLOWTABLESTATS
-
-The output should look similar to the following::
-
- [NID=openflow:1][DC=FLOWTABLESTATS][MN=ActiveFlows][RK=Node:openflow:1,Table:50][TS=1473427383598][3]
- [NID=openflow:1][DC=FLOWTABLESTATS][MN=PacketMatch][RK=Node:openflow:1,Table:50][TS=1473427383598][12]
- [NID=openflow:1][DC=FLOWTABLESTATS][MN=PacketLookup][RK=Node:openflow:1,Table:50][TS=1473427383598][12]
- [NID=openflow:1][DC=FLOWTABLESTATS][MN=ActiveFlows][RK=Node:openflow:1,Table:80][TS=1473427383598][3]
- [NID=openflow:1][DC=FLOWTABLESTATS][MN=PacketMatch][RK=Node:openflow:1,Table:80][TS=1473427383598][17]
- [NID=openflow:1][DC=FLOWTABLESTATS][MN=PacketMatch][RK=Node:openflow:1,Table:246][TS=1473427383598][19]
- ...
-
-Or you can query your ElasticSearch instance:
-
-.. code-block:: bash
-
- curl -XPOST "http://elasticseach_ip:9200/_search?pretty" -d'{ "from": 0, "size": 10000, "query": { "match_all": {} } }'
-
-The elasticseach_ip is the IP address of the server where the ElasticSearch is running.
-
-
-Web Activity Collector
-----------------------
-
-The Web Activity Collector records the meaningful REST requests made through the
-OpenDaylight RESTCONF interface.
-
-
-How to test the RESTCONF Collector
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Install some other feature that has a RESTCONF interface, for example. "odl-tsdr-syslog-collector"
-- Issue a RESTCONF command that uses either POST,PUT or DELETE.
- For example, you could call the register-filter RPC of tsdr-syslog-collector.
-- Look up data in TSDR database from Karaf.
-
- .. code-block:: bash
-
- tsdr:list RESTCONF
-
-- You should see the request that you have sent, along with its information
- (URL, HTTP method, requesting IP address and request body)
-- Try to send a GET request, then check again, your request should not be
- registered, because the collector does not register GET requests by default.
-- Open the file: "etc/tsdr.restconf.collector.cfg", and add GET to the list of
- METHODS_TO_LOG, so that it becomes:
-
- ::
-
- METHODS_TO_LOG=POST,PUT,DELETE,GET
-
- - Try again to issue your GET request, and check if it was recorded this time,
- it should be recorder.
- - Try manipulating the other properties (PATHS_TO_LOG (which URLs do we want
- to log from), REMOTE_ADDRESSES_TO_LOG (which requesting IP addresses do we
- want to log from) and CONTENT_TO_LOG (what should be in the request's body
- in order to log it)), and see if the requests are getting logged.
- - Try providing invalid properties (unknown methods for the METHODS_TO_LOG
- parameter, or the same method repeated multiple times, and invalid regular
- expressions for the other parameters), then check karaf's log using
- "log:display". It should tell you that the value is invalid, and that it
- will use the default value instead.
+++ /dev/null
-.. _tsdr-elasticsearch-user-guide:
-
-ElasticSearch
-=============
-
-Setting Up the environment
---------------------------
-
-To setup and run the TSDR data store ElasticSearch feature, you need to have
-an ElasticSearch node (or a cluster of such nodes) running. You can use a
-customized ElasticSearch docker image for this purpose.
-
-Your ElasticSearch (ES) setup must have the "Delete By Query Plugin" installed.
-Without this, some of the ES functionality won't work properly.
-
-
-Creating a custom ElasticSearch docker image
---------------------------------------------
-
-(You can skip this section if you already have an instance of ElasticSearch running)
-
-Run the following set of commands:
-
- ::
-
- cat << EOF > Dockerfile
- FROM elasticsearch:2
- RUN /usr/share/elasticsearch/bin/plugin install --batch delete-by-query
- EOF
-
-
-To build the image, run the following command in the directory where the
-Dockerfile was created:
-
- ::
-
- docker build . -t elasticsearch-dd
-
-
-You can check whether the image was properly created by running:
-
- ::
-
- docker images
-
-
-This should print all your container images including the elasticsearch-dd.
-
-Now we can create and run a container from our image by typing:
-
- ::
-
- docker run -d -p 9200:9200 -p 9300:9300 --name elasticsearch-dd elasticsearch-dd
-
-
-To see whether the container is running, run the following command:
-
- ::
-
- docker ps
-
-
-The output should include a row with elasticsearch-dd in the NAMES column.
-To check the std out of this container use
-
- ::
-
- docker logs elasticsearch-dd
-
-
-Running the ElasticSearch feature
----------------------------------
-
-Once the features have been installed, you can change some of its properties. For
-example, to setup the URL where your ElasticSearch installation runs,
-change the *serverUrl* parameter in tsdr/persistence-elasticsearch/src/main/resources/configuration/initial/:
-
- tsdr-persistence-elasticsearch.properties
-
-
-All the data are stored into the TSDR index under a type. The metric data are
-stored under the metric type and the log data are store under the log type.
-You can modify the files in tsdr/persistence-elasticsearch/src/main/resources/configuration/initial/:
-
- tsdr-persistence-elasticsearch_metric_mapping.json
- tsdr-persistence-elasticsearch_log_mapping.json
-
-to change or tune the mapping for those types. The changes in those files will be promoted after
-the feature is reloaded or the distribution is restarted.
-
-
-Testing the setup
-^^^^^^^^^^^^^^^^^
-
-We can now test whether the setup is correct by downloading and installing mininet,
-which we use to send some data to the running ElasticSearch instance.
-
-Installing the necessary features:
-
-Start OpenDaylight
-
- ::
-
- feature:install odl-restconf odl-l2switch-switch odl-tsdr-core odl-tsdr-openflow-statistics-collector
- feature:install odl-tsdr-elasticsearch
-
-We can check whether the distribution is now listening on port 6653:
-
- ::
-
- netstat -an | grep 6653
-
-Run mininet
-
- ::
-
- sudo mn --topo single,3 --controller 'remote,ip=distro_ip,port=6653' --switch ovsk,protocols=OpenFlow13
-
-
-where the distro_ip is the IP address of the machine where the OpenDaylight distribution
-is running. This command will create three hosts connected to one OpenFlow capable
-switch.
-
-We can check if data was stored by ElasticSearch in TSDR by running the
-following command:
-
- ::
-
- tsdr:list FLOWTABLESTATS
-
-The output should look similar to the following::
-
- [NID=openflow:1][DC=FLOWTABLESTATS][MN=ActiveFlows][RK=Node:openflow:1,Table:50][TS=1473427383598][3]
- [NID=openflow:1][DC=FLOWTABLESTATS][MN=PacketMatch][RK=Node:openflow:1,Table:50][TS=1473427383598][12]
- [NID=openflow:1][DC=FLOWTABLESTATS][MN=PacketLookup][RK=Node:openflow:1,Table:50][TS=1473427383598][12]
- [NID=openflow:1][DC=FLOWTABLESTATS][MN=ActiveFlows][RK=Node:openflow:1,Table:80][TS=1473427383598][3]
- [NID=openflow:1][DC=FLOWTABLESTATS][MN=PacketMatch][RK=Node:openflow:1,Table:80][TS=1473427383598][17]
- [NID=openflow:1][DC=FLOWTABLESTATS][MN=PacketMatch][RK=Node:openflow:1,Table:246][TS=1473427383598][19]
- ...
-
-Or you can query your ElasticSearch instance:
-
- ::
-
- curl -XPOST "http://elasticseach_ip:9200/_search?pretty" -d'{ "from": 0, "size": 10000, "query": { "match_all": {} } }'
-
-The elasticseach_ip is the IP address of the server where the ElasticSearch is running.
-
-
-Web Activity Collector
-======================
-
-The Web Activity Collector records the meaningful REST requests made through the
-OpenDaylight RESTCONF interface.
-
-
-How to test the RESTCONF Collector
-----------------------------------
-
-- Install some other feature that has a RESTCONF interface, for example. "odl-tsdr-syslog-collector"
-- Issue a RESTCONF command that uses either POST,PUT or DELETE.
- For example, you could call the register-filter RPC of tsdr-syslog-collector.
-- Look up data in TSDR database from Karaf.
-
- ::
-
- tsdr:list RESTCONF
-
-
-- You should see the request that you have sent, along with its information
- (URL, HTTP method, requesting IP address and request body)
-- Try to send a GET request, then check again, your request should not be
- registered, because the collector does not register GET requests by default.
-- Open the file: "etc/tsdr.restconf.collector.cfg", and add GET to the list of
- METHODS_TO_LOG, so that it becomes:
-
-
- METHODS_TO_LOG=POST,PUT,DELETE,GET
-
- - Try again to issue your GET request, and check if it was recorded this time,
- it should be recorder.
- - Try manipulating the other properties (PATHS_TO_LOG (which URLs do we want
- to log from), REMOTE_ADDRESSES_TO_LOG (which requesting IP addresses do we
- want to log from) and CONTENT_TO_LOG (what should be in the request's body
- in order to log it)), and see if the requests are getting logged.
- - Try providing invalid properties (unknown methods for the METHODS_TO_LOG
- parameter, or the same method repeated multiple times, and invalid regular
- expressions for the other parameters), then check karaf's log using
- "log:display". It should tell you that the value is invalid, and that it
- will use the default value instead.
-
+++ /dev/null
-.. _tsdr-hbase-user-guide:
-
-TSDR HBase Data Store User Guide
-================================
-
-This document describes how to use HBase to capture time series data
-using Time Series Data Repository (TSDR) feature in the OpenDaylight
-Lithium release. This document contains configuration, administration,
-management, usage, and troubleshooting sections for the feature.
-
-Overview
---------
-
-The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a framework for collecting, storing, querying, and maintaining time series data in then OpenDaylight SDN controller. TSDR provides the framework for plugging in proper data collectors to collect various time series data and store into TSDR data stores. With a common data model and generic TSDR data persistence APIs, the user could choose various data stores to be plugged into TSDR Persistence framework. In Lithium, two types of data stores are supported: HBase NoSQL database and H2 relational database.
-
-With the capabilities of data collection, storage, query, aggregation, and purging provided by TSDR, network administrators could leverage various data driven appliations built on top of TSDR for security risk detection, performance analysis, operational configuration optimization, traffic engineering, and network analytics with automated intelligence.
-
-TSDR with HBase Data Store Architecture
----------------------------------------
-
-TSDR contains the following services and components
-
-- Data Collection Service
-- Data Storage Service
-- TSDR Persistence Layer with data stores as plugins
-- TSDR Data Stores
-- Data Query Service
-- Data Aggregation Service
-- Data Purging Service
-
-Data Collection Service handles the collection of time series data into TSDR and hands it over to Data Storage Service. Data Storage Service stores the data into TSDR through TSDR Persistence Layer. TSDR Persistence Layer provides generic Service APIs allowing various data stores to be plugged in. Data Aggregation Service aggregates time series fine-grained raw data into course-grained roll-up data to control the size of the data. Data Purging Service periodically purges both fine-grained raw data and course-granined aggregated data according to user-defined schedules.
-
-
-In Lithium, we implemented Data Collection Service, Data Storage Service, TSDR Persistence Layer, TSDR HBase Data Store, and TSDR H2 Data Store. Among these services and components, time series data is communicated using a common TSDR data model, which is designed and implemented for the abstraction of time series data commonalities. With these functions, TSDR will be able to collect the data from the data sources and store them into one of the TSDR data stores: either HBase Data Store or H2 Data Store. We also provided a simple query command from Karaf console for the user to retrieve TSDR data from the data stores.
-
-
-A future release will contain Data Aggregation service, Data Purging Service, and a full-fledged Data Query Service with Norghbound APIs.
-
-Configuring TSDR with HBase Data Store
---------------------------------------
-
-After installing HBase Server on the same VM as the OpenDaylight Controller, if the user accepts the default configuration of the HBase Data Store, the user can directly proceed with the installation of HBase Data Store from Karaf console.
-
-Optionally, the user can configure TSDR HBase Data Store following HBase Data Store Configuration Procedure.
-
-HBase Data Store Configuration Steps
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- Open the file etc/tsdr-persistence-hbase.peroperties under karaf distribution directory.
-- Edit the following parameters
- - HBase server name
- - HBase server port
- - HBase client connection pool size
- - HBase client write buffer size
-
-After the configuration of HBase Data Store is complete, proceed with the installation of HBase Data Store from Karaf console.
-
-- HBase Data Store Installation Steps
- - Start Karaf Console
- - Run the following commands from Karaf Console:
-
- ::
-
- feature:install odl-tsdr-hbase
-
-
-Administering or Managing TSDR HBase Data Store
------------------------------------------------
-
-Using Karaf Command to retrieve data from HBase Data Store
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The user can retrieve the data from HBase data store using the following commands from Karaf console:
-
- ::
-
- tsdr:list
-
- ::
-
- tsdr:list <CategoryName> <StartTime> <EndTime>
-
-Typing tab will get the context prompt of the arguments when typeing the command in Karaf console.
-
-Troubleshooting issues with log files
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- Karaf logs
-
-Similar to other OpenDaylight components and features, TSDR HBase Data Store writes logging information to Karaf logs. All the information messages, warnings, error messages, and debug messages are written to Karaf logs.
-
-- HBase logs
-
-For HBase system level logs, the user can check standard HBase server logs, which is under <HBase-installation-directory>/logs.
-
-Tutorials
-=========
-
-How to use TSDR to collect, store, and view OpenFlow Interface Statistics
-
-Overview
---------
-
-This tutorial describes an example of using TSDR to collect, store, and view one type of time series data in OpenDaylight environment.
-
-
-Prerequisites
--------------
-
-You would need to have the following as prerequisits:
- - One or multiple OpenFlow enabled switches. Alternatively, you can use mininet to simulate such a switch.
- - Successfully installed OpenDaylight Controller.
- - Successfully installed HBase Data Store following TSDR HBase Data Store Installation Guide.
- - Connect the OpenFlow enabled switch(es) to OpenDaylight Controller.
-
-Target Environment
-------------------
-
-HBase data store is only supported in Linux operation system.
-
-Instructions
-------------
-
-- Start OpenDaylight controller.
-
-- Connect OpenFlow enabled switch(es) to the controller. If using mininet, run the following commands from mininet command line:
-
- ::
-
- mn --topo single,3 --controller 'remote,ip=172.17.252.210,port=6653' --switch ovsk,protocols=OpenFlow13
-
-- If using real switch(es), the OpenDaylight controller should be able to discover the network toplogy containing the switches.
-
-- Install tsdr hbase feature from Karaf:
-
- ::
-
- feature:install odl-tsdr-hbase
-
-- run the following command from Karaf console:
-
- ::
-
- tsdr:list InterfaceStats
-
-You should be able to see the interface statistics of the switch(es) from the HBase Data Store. If there are too many rows, you can use "tsdr:list InterfaceStats|more" to view it page by page.
-
-By tabbing after "tsdr:list", you will see all the supported data categories. For example, "tsdr:list FlowStats" will output the Flow statistics data collected from the switch(es).
-
+++ /dev/null
-.. _tsdr-hsqldb-user-guide:
-
-TSDR HSQLDB Datastore User Guide
-================================
-
-This document describes how to use the embedded datastore HSQLDB, which is the default datastore (recommended for non-production use case) introduced as part of OpenDaylight Time Series Data Respository (TSDR) project. This store captures the time series data. This document contains configuration, administration, management, using, and troubleshooting sections for the feature.
-
-Overview
---------
-
-In the Lithium Release of Time Series Data Repository (TSDR), time series metrics corresponding to the OpenFlow statistics are captured. For users trying out things on their laptop or non-production environment, TSDR functionality can be enabled with default datastore HSQLDB by installing the feature odl-tsdr-all.
-
-TSDR Architecture
------------------
-
-The following wiki pages capture the TSDR Model/Architecture
-
-a. https://wiki.opendaylight.org/view/TSDR_Data_Storage_Service_and_Persistence_with_HBase_Plugin
-b. https://wiki.opendaylight.org/view/TSDR_Data_Collection_Service
-
-Note in Lithium the DataCollection Service is implemented just for OpenFlow Statistics metrics.
-
-Administering or Managing TSDR with default datastore HSQLDB
-------------------------------------------------------------
-
-Once the TSDR default datastore feature (odl-tsdr-all) is enabled, the TSDR captured OpenFlow statistics metrics can be accessed from Karaf Console by executing the command
-
- ::
-
- tsdr:list <metric-category> <starttimestamp> <endtimestamp>
-
-wherein
-
- ::
-
- <metric-category> = any one of the following categories FlowGroupStats, FlowMeterStats, FlowStats, FlowTableStats, PortStats, QueueStats
- <starttimestamp> = to filter the list of metrics starting this timestamp
- <endtimestamp> = to filter the list of metrics ending this timestamp
-
-If either of <starttimestamp> or <endtimestamp> is not specified, this command displays the latest 1000 metrics captured.
-
+++ /dev/null
-.. _tsdr-user-guide:
-
-TSDR User Guide
-===============
-
-This document describes how to use HSQLDB, HBase, and Cassandra data
-stores to capture time series data using Time Series Data Repository
-(TSDR) features in OpenDaylight. This document contains configuration,
-administration, management, usage, and troubleshooting sections for these
-features.
-
-Overview
---------
-
-The Time Series Data Repository (TSDR) project in OpenDaylight (ODL)
-creates a framework for collecting, storing, querying, and maintaining
-time series data. TSDR provides the framework for plugging in
-data collectors to collect various time series data and store the data
-into TSDR Data Stores. With a common data model and generic TSDR data
-persistence APIs, the user can choose various data stores to be plugged
-into the TSDR persistence framework. Currently, three types of data
-stores are supported: HSQLDB relational database (default installed),
-HBase NoSQL database and Cassandra NoSQL database.
-
-With the capabilities of data collection, storage, query, aggregation,
-and purging provided by TSDR, network administrators can leverage
-various data driven applications built on top of TSDR for security risk
-detection, performance analysis, operational configuration optimization,
-traffic engineering and network analytics with automated intelligence.
-
-TSDR Architecture
------------------
-
-TSDR has the following major components:
-
-- Data Collection Service
-
-- Data Storage Service
-
-- TSDR Persistence Layer with data stores as plugins
-
-- TSDR Data Stores
-
-- Data Query Service
-
-- Grafana integration for time series data visualization
-
-- Data Aggregation Service
-
-- Data Purging Service
-
-The Data Collection Service handles the collection of time series data
-into TSDR and hands it over to the Data Storage Service. The Data
-Storage Service stores the data into TSDR through the TSDR Persistence
-Layer. The TSDR Persistence Layer provides generic Service APIs allowing
-various data stores to be plugged in. The Data Aggregation Service
-aggregates time series fine-grained raw data into course-grained roll-up
-data to control the size of the data. The Data Purging Service
-periodically purges both fine-grained raw data and course-grained
-aggregated data according to user-defined schedules.
-
-TSDR provides component-based services on a common data model. These
-services include the data collection service, data storage service and
-data query service. The TSDR data storage service supports HSQLDB
-(the default datastore), HBASE and Cassandra datastores. Between these
-services and components, time series data is communicated using a common
-TSDR data model. This data model is designed around the abstraction of
-time series data commonalities. With these services, TSDR is able
-to collect the data from the data sources and store them into one of
-the TSDR data stores; HSQLDB, HBase and Cassandra datastores. Data can
-be retrieved with the Data Query service using the default OpenDaylight
-RestConf interface or its ODL API interface. TSDR also has integrated
-support for ElasticSearch capabilities. TSDR data can also be viewed
-directly with Grafana for time series visualization or various chart formats.
-
-Configuring TSDR Data Stores
-----------------------------
-
-To Configure HSQLDB Data Store
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The HSQLDB based storage files get stored automatically in <karaf
-install folder>/tsdr/ directory. If you want to change the default
-storage location, the configuration file to change can be found in
-<karaf install folder>/etc directory. The filename is
-org.ops4j.datasource-metric.cfg. Change the last portion of the
-url=jdbc:hsqldb:./tsdr/metric to point to different directory.
-
-To Configure HBase Data Store
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-After installing HBase Server on the same machine as OpenDaylight, if
-the user accepts the default configuration of the HBase Data Store, the
-user can directly proceed with the installation of HBase Data Store from
-Karaf console.
-
-Optionally, the user can configure TSDR HBase Data Store following HBase
-Data Store Configuration Procedure.
-
-- HBase Data Store Configuration Steps
-
- - Open the file etc/tsdr-persistence-hbase.peroperties under karaf
- distribution directory.
-
- - Edit the following parameters:
-
- - HBase server name
-
- - HBase server port
-
- - HBase client connection pool size
-
- - HBase client write buffer size
-
-After the configuration of HBase Data Store is complete, proceed with
-the installation of HBase Data Store from Karaf console.
-
-- HBase Data Store Installation Steps
-
- - Start Karaf Console
-
- - Run the following commands from Karaf Console:
-
- ::
-
- feature:install odl-tsdr-hbase
-
-To Configure Cassandra Data Store
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Currently, there’s no configuration needed for Cassandra Data Store. The
-user can use Cassandra data store directly after installing the feature
-from Karaf console.
-
-Additionally separate commands have been implemented to install various
-data collectors.
-
-Administering or Managing TSDR Data Stores
-------------------------------------------
-
-To Administer HSQLDB Data Store
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Once the TSDR default datastore feature (odl-tsdr-hsqldb-all) is
-enabled, the TSDR captured OpenFlow statistics metrics can be accessed
-from Karaf Console by executing the command
-
- ::
-
- tsdr:list <metric-category> <starttimestamp> <endtimestamp>
-
-wherein
-
-- <metric-category> = any one of the following categories
- FlowGroupStats, FlowMeterStats, FlowStats, FlowTableStats, PortStats,
- QueueStats
-
-- <starttimestamp> = to filter the list of metrics starting this
- timestamp
-
-- <endtimestamp> = to filter the list of metrics ending this timestamp
-
-- <starttimestamp> and <endtimestamp> are optional.
-
-- Maximum 1000 records will be displayed.
-
-To Administer HBase Data Store
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Using Karaf Command to retrieve data from HBase Data Store
-
-The user first need to install hbase data store from karaf console:
-
- ::
-
- feature:install odl-tsdr-hbase
-
-The user can retrieve the data from HBase data store using the following
-commands from Karaf console:
-
- ::
-
- tsdr:list
-
- ::
-
- tsdr:list <CategoryName> <StartTime> <EndTime>
-
-Typing tab will get the context prompt of the arguments when typeing the
-command in Karaf console.
-
-To Administer Cassandra Data Store
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The user first needs to install Cassandra data store from Karaf console:
-
- ::
-
- feature:install odl-tsdr-cassandra
-
-Then the user can retrieve the data from Cassandra data store using the
-following commands from Karaf console:
-
- ::
-
- tsdr:list
-
- ::
-
- tsdr:list <CategoryName> <StartTime> <EndTime>
-
-Typing tab will get the context prompt of the arguments when typeing the
-command in Karaf console.
-
-Installing TSDR Data Collectors
--------------------------------
-
-When the user uses HSQLDB data store and installed "odl-tsdr-hsqldb-all"
-feature from Karaf console, besides the HSQLDB data store, OpenFlow data
-collector is also installed with this command. However, if the user
-needs to use other collectors, such as NetFlow Collector, Syslog
-Collector, SNMP Collector, and Controller Metrics Collector, the user
-needs to install them with separate commands. If the user uses HBase or
-Cassandra data store, no collectors will be installed when the data
-store is installed. Instead, the user needs to install each collector
-separately using feature install command from Karaf console.
-
-The following is the list of supported TSDR data collectors with the
-associated feature install commands:
-
-- OpenFlow Data Collector
-
- ::
-
- feature:install odl-tsdr-openflow-statistics-collector
-
-- NetFlow Data Collector
-
- ::
-
- feature:install odl-tsdr-netflow-statistics-collector
-
-- Syslog Data Collector
-
- ::
-
- feature:install odl-tsdr-syslog-collector
-
-- Controller Metrics Collector
-
- ::
-
- feature:install odl-tsdr-controller-metrics-collector
-
-- Web Activity Collector
-
- ::
-
- feature:install odl-tsdr-restconf-collector
-
-- sFlow Data Collector (experimental)
-
- ::
-
- feature:install odl-tsdr-sflow-statistics-colletor
-
-- SNMP Data Collector (experimental)
-
- ::
-
- feature:install odl-tsdr-snmp-data-collector
-
-
-In order to use controller metrics collector, the user needs to install
-Sigar library.
-
-The following is the instructions for installing Sigar library on
-Ubuntu:
-
-- Install back end library by "sudo apt-get install
- libhyperic-sigar-java"
-
-- Execute "export
- LD\_LIBRARY\_PATH=/usr/lib/jni/:/usr/lib:/usr/local/lib" to set the
- path of the JNI (you can add this to the ".bashrc" in your home
- directory)
-
-- Download the file "sigar-1.6.4.jar". It might be also in your ".m2"
- directory under "~/.m2/resources/org/fusesource/sigar/1.6.4"
-
-- Create the directory "org/fusesource/sigar/1.6.4" under the "system"
- directory in your controller home directory and place the
- "sigar-1.6.4.jar" there
-
-
-Querying TSDR from REST APIs
-----------------------------
-
-TSDR provides two REST APIs for querying data stored in TSDR data
-stores.
-
-- Query of TSDR Metrics
-
- - URL: http://localhost:8181/tsdr/metrics/query
-
- - Verb: GET
-
- - Parameters:
-
- - tsdrkey=[NID=][DC=][MN=][RK=]
-
- ::
-
- The TSDRKey format indicates the NodeID(NID), DataCategory(DC), MetricName(MN), and RecordKey(RK) of the monitored objects.
- For example, the following is a valid tsdrkey:
- [NID=openflow:1][DC=FLOWSTATS][MN=PacketCount][RK=Node:openflow:1,Table:0,Flow:3]
- The following is also a valid tsdrkey:
- tsdrkey=[NID=][DC=FLOWSTATS][MN=][RK=]
- In the case when the sections in the tsdrkey is empty, the query will return all the records in the TSDR data store that matches the filled tsdrkey. In the above example, the query will return all the data in FLOWSTATS data category.
- The query will return only the first 1000 records that match the query criteria.
-
- - from=<time\_in\_seconds>
-
- - until=<time\_in\_seconds>
-
-The following is an example curl command for querying metric data from
-TSDR data store:
-
- ::
-
- curl -G -v -H "Accept: application/json" -H "Content-Type:
- application/json" "http://localhost:8181/tsdr/metrics/query"
- --data-urlencode "tsdrkey=[NID=][DC=FLOWSTATS][MN=][RK=]"
- --data-urlencode "from=0" --data-urlencode "until=240000000000"\|more
-
-- Query of TSDR Log type of data
-
- - URL:http://localhost:8181/tsdr/logs/query
-
- - Verb: GET
-
- - Parameters:
-
- - tsdrkey=tsdrkey=[NID=][DC=][RK=]
-
- - The TSDRKey format indicates the NodeID(NID), DataCategory(DC), and RecordKey(RK) of the monitored objects.
- For example, the following is a valid tsdrkey:
- [NID=openflow:1][DC=NETFLOW][RK]
- The query will return only the first 1000 records that match the query criteria.
-
- - from=<time\_in\_seconds>
-
- - until=<time\_in\_seconds>
-
-The following is an example curl command for querying log type of data
-from TSDR data store:
-
- ::
-
- curl -G -v -H "Accept: application/json" -H "Content-Type: application/json" "http://localhost:8181/tsdr/logs/query"
- --data-urlencode "tsdrkey=[NID=][DC=NETFLOW][RK=]" --data-urlencode
- "from=0" --data-urlencode "until=240000000000"\|more
-
-Grafana integration with TSDR
------------------------------
-
-TSDR provides northbound integration with Grafana time series data
-visualization tool. All the metric type of data stored in TSDR data
-store can be visualized using Grafana.
-
-For the detailed instruction about how to install and configure Grafana
-to work with TSDR, please refer to the following link:
-
-https://wiki.opendaylight.org/view/Grafana_Integration_with_TSDR_Step-by-Step
-
-Configuring TSDR Data Collectors
---------------------------------
-
-SNMP Data Collector Device Credential Configuration (experimental)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-After installing SNMP Data Collector, a configuration file under etc/
-directory of ODL distribution is generated: etc/tsdr.snmp.cfg is
-created.
-
-The following is a sample tsdr.snmp.cfg file:
-
-credentials=[192.168.0.2,public],[192.168.0.3,public]
-
-The above credentials indicate that TSDR SNMP Collector is going to
-connect to two devices. The IPAddress and Read community string of these
-two devices are (192.168.0.2, public), and (192.168.0.3) respectively.
-
-The user can make changes to this configuration file any time during
-runtime. The configuration will be picked up by TSDR in the next cycle
-of data collection.
-
-Polling interval configuration for SNMP Collector and OpenFlow Stats Collector
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The default polling interval of SNMP Collector and OpenFlow Stats
-Collector is 30 seconds and 15 seconds respectively. The user can change
-the polling interval through restconf APIs at any time. The new polling
-interval will be picked up by TSDR in the next collection cycle.
-
-- Retrieve Polling Interval API for SNMP Collector
-
- - URL:
- http://localhost:8181/restconf/config/tsdr-snmp-data-collector:TSDRSnmpDataCollectorConfig
-
- - Verb: GET
-
-- Update Polling Interval API for SNMP Collector
-
- - URL:
- http://localhost:8181/restconf/operations/tsdr-snmp-data-collector:setPollingInterval
-
- - Verb: POST
-
- - Content Type: application/json
-
- - Input Payload:
-
- ::
-
- {
- "input": {
- "interval": "15000"
- }
- }
-
-- Retrieve Polling Interval API for OpenFlowStats Collector
-
- - URL:
- http://localhost:8181/restconf/config/tsdr-openflow-statistics-collector:TSDROSCConfig
-
- - Verb: GET
-
-- Update Polling Interval API for OpenFlowStats Collector
-
- - URL:
- http://localhost:8181/restconf/operations/tsdr-openflow-statistics-collector:setPollingInterval
-
- - Verb: POST
-
- - Content Type: application/json
-
- - Input Payload:
-
- ::
-
- {
- "input": {
- "interval": "15000"
- }
- }
-
-Purging Service configuration
------------------------------
-
-After the data stores are installed from Karaf console, the purging
-service will be installed as well. A configuration file called
-tsdr.data.purge.cfg will be generated under etc/ directory of ODL
-distribution.
-
-The following is the sample default content of the tsdr.data.purge.cfg
-file:
-
-host=127.0.0.1 data\_purge\_enabled=true data\_purge\_time=23:59:59
-data\_purge\_interval\_in\_minutes=1440 retention\_time\_in\_hours=168
-
-The host indicates the IPAddress of the data store. In the case when the
-data store is together with ODL controller, 127.0.0.1 should be the
-right value for the host IP. The other attributes are self-explained.
-The user can change those attributes at any time. The configuration
-change will be picked up right away by TSDR Purging service at runtime.
-
-How to use TSDR to collect, store, and view OpenFlow Interface Statistics
--------------------------------------------------------------------------
-
-Overview
-~~~~~~~~
-
-This tutorial describes an example of using TSDR to collect, store, and
-view one type of time series data in OpenDaylight environment.
-
-Prerequisites
-~~~~~~~~~~~~~
-
-You would need to have the following as prerequisits:
-
-- One or multiple OpenFlow enabled switches. Alternatively, you can use
- mininet to simulate such a switch.
-
-- Successfully installed OpenDaylight Controller.
-
-- Successfully installed HBase Data Store following TSDR HBase Data
- Store Installation Guide.
-
-- Connect the OpenFlow enabled switch(es) to OpenDaylight Controller.
-
-Target Environment
-~~~~~~~~~~~~~~~~~~
-
-HBase data store is only supported in Linux operation system.
-
-Instructions
-~~~~~~~~~~~~
-
-- Start OpenDaylight.
-
-- Connect OpenFlow enabled switch(es) to the controller.
-
- - If using mininet, run the following commands from mininet command
- line:
-
- ::
-
- mn --topo single,3 --controller *remote,ip=172.17.252.210,port=6653* --switch
- ovsk,protocols=OpenFlow13
-
-- Install TSDR hbase feature from Karaf:
-
- ::
-
- feature:install odl-tsdr-hbase
-
-- Install OpenFlow Statistics Collector from Karaf:
-
- ::
-
- feature:install odl-tsdr-openflow-statistics-collector
-
-- run the following command from Karaf console:
-
- ::
-
- tsdr:list PORTSTATS
-
-You should be able to see the interface statistics of the switch(es)
-from the HBase Data Store. If there are too many rows, you can use
-"tsdr:list InterfaceStats\|more" to view it page by page.
-
-By tabbing after "tsdr:list", you will see all the supported data
-categories. For example, "tsdr:list FlowStats" will output the Flow
-statistics data collected from the switch(es).
-
-
-Troubleshooting
----------------
-
-Karaf logs
-~~~~~~~~~~
-
-All TSDR features and components write logging information including
-information messages, warnings, errors and debug messages into
-karaf.log.
-
-HBase and Cassandra logs
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-For HBase and Cassandra data stores, the database level logs are written
-into HBase log and Cassandra logs.
-
-- HBase log
-
- - HBase log is under <HBase-installation-directory>/logs/.
-
-- Cassandra log
-
- - Cassandra log is under {cassandra.logdir}/system.log. The default
- {cassandra.logdir} is /var/log/cassandra/.
-
-Security
---------
-
-TSDR gets the data from a variety of sources, which can be secured in
-different ways.
-
-- OpenFlow Security
-
- - The OpenFlow data can be configured with Transport Layer Security
- (TLS) since the OpenFlow Plugin that TSDR depends on provides this
- security support.
-
-- NetFlow Security
-
- - NetFlow, which cannot be configured with security so we recommend
- making sure it flows only over a secured management network.
-
-- Syslog Security
-
- - Syslog, which cannot be configured with security so we recommend
- making sure it flows only over a secured management network.
-
-- SNMP Security
-
- - The SNMP version3 has security support. However, since ODL SNMP
- Plugin that TSDR depends on does not support version 3, we (TSDR)
- will not have security support at this moment.
-
-- sFlow Security
-
- - The sflow has security support.
-
-
-Support multiple data stores simultaneously at runtime
-------------------------------------------------------
-
-TSDR supports running multiple data stores simultaneously at runtim. For
-example, it is possible to configure TSDR to push log type of data into
-Cassandra data store, while pushing metrics type of data into HBase.
-
-When you install one TSDR data store from karaf console, such as using
-feature:install odl-tsdr-hsqldb, a properties file will be generated
-under <Karaf-distribution-directory>/etc/. For example, when you install
-hsqldb, a file called tsdr-persistence-hsqldb.properties is generated
-under that directory.
-
-By default, all the types of data are supported in the data store. For
-example, the default content of tsdr-persistence-hsqldb.properties is as
-follows:
-
- ::
-
- metric-persistency=true
- log-persistency=true
- binary-persistency=true
-
-When the user would like to use different data stores to support
-different types of data, he/she could enable or disable a particular
-type of data persistence in the data stores by configuring the
-properties file accordingly.
-
-For example, if the user would like to store the log type of data in
-HBase, and store the metric and binary type of data in Cassandra, he/she
-needs to install both hbase and cassandra data stores from Karaf
-console. Then the user needs to modify the properties file under
-<Karaf-distribution-directory>/etc as follows:
-
-- tsdr-persistence-hbase.properties
-
- ::
-
- metric-persistency=false
- log-persistency=true
- binary-persistency=true
-
-- tsdr-persistence-cassandra.properties
-
- ::
-
- metric-psersistency=true
- log-persistency=false
- binary-persistency=false
-
-.. toctree::
- :maxdepth: 1
- :hidden:
-
- tsdr-elastic-search
- tsdr-elasticsearch-user-guide
- tsdr-hbase-user-guide
- tsdr-hsqldb-user-guide
+++ /dev/null
-.. _ttp_cli_tools_user_guide:
-
-TTP CLI Tools User Guide
-========================
-
-Overview
---------
-
-Table Type Patterns are a specification developed by the `Open
-Networking Foundation <https://www.opennetworking.org/>`__ to enable the
-description and negotiation of subsets of the OpenFlow protocol. This is
-particularly useful for hardware switches that support OpenFlow as it
-enables the to describe what features they do (and thus also what
-features they do not) support. More details can be found in the full
-specification listed on the `OpenFlow specifications
-page <https://www.opennetworking.org/sdn-resources/onf-specifications/openflow>`__.
-
-TTP CLI Tools Architecture
---------------------------
-
-The TTP CLI Tools use the TTP Model and the YANG Tools/RESTCONF codecs
-to translate between the Data Transfer Objects (DTOs) and JSON/XML.
-
+++ /dev/null
-.. _unimgr-user-guide:
-
-User Network Interface Manager Plug-in (Unimgr) User Guide
-==========================================================
-
-Overview
---------
-
-The User Network Interface (UNI) Manager project within OpenDaylight provides
-data models and APIs that enable software applications and service
-orchestrators to configure and provision connectivity services; in particular,
-Carrier Ethernet services as defined by MEF Forum, in physical and virtual
-network elements.
-
-MEF has defined the Lifecycle Service Orchestration (LSO) Reference
-Architecture for the management and control of domains and entities that enable
-cooperative network services across one or more service provider networks. The
-architecture also identifies LSO Reference Points, which are the logical points
-of interaction between specific functional management components. These LSO
-Reference Points are further defined by interface profiles and instantiated by
-APIs.
-
-The LSO Reference Architecture is shown below. Note that this is a functional
-architecture that does not describe how the management components are
-implemented (e.g., single vs. multiple instances), but rather identifies
-management components that provide logical functionality as well as the points
-of interaction among them.
-
-.. figure:: ./images/unimgr-lso-arch.png
- :alt: MEF LSO Reference Architecture
-
- MEF LSO Reference Architecture
-
-Unimgr provides support for both the Legato as well as the Presto interfaces.
-These interfaces, and the APIs associated with them, are defined by YANG models
-developed within MEF in collaboration with ONF and IETF. For the Carbon release,
-these are as follows:
-
-Legato YANG modules:
-https://git.opendaylight.org/gerrit/gitweb?p=unimgr.git;a=tree;f=legato-api/src/main/yang;hb=refs/heads/stable/carbon
-
-Presto YANG modules:
-https://git.opendaylight.org/gerrit/gitweb?p=unimgr.git;a=tree;f=presto-api/src/main/yang;hb=refs/heads/stable/carbon
-
-An application/user can interact with Unimgr at either the service
-orchestration layer (Legato) or the network resource provisioning layer
-(Presto).
-
-Unimgr Architecture
--------------------
-
-Unimgr is comprised of the following OpenDaylight Karaf features:
-
-+--------------------------------------+--------------------------------------+
-| odl-unimgr-api | OpenDaylight :: UniMgr :: api |
-+--------------------------------------+--------------------------------------+
-| odl-unimgr | OpenDaylight :: UniMgr |
-+--------------------------------------+--------------------------------------+
-| odl-unimgr-console | OpenDaylight :: UniMgr :: CLI |
-+--------------------------------------+--------------------------------------+
-| odl-unimgr-rest | OpenDaylight :: UniMgr :: REST |
-+--------------------------------------+--------------------------------------+
-| odl-unimgr-ui | OpenDaylight :: UniMgr :: UI |
-+--------------------------------------+--------------------------------------+
-
-Configuring Unimgr
-------------------
-
-After launching OpenDaylight, install the feature for Unimgr. From the karaf
-command prompt execute the following command:
-
-::
-
- $ feature:install odl-unimgr-ui
-
-Explore and exercise the Unimgr REST API
-----------------------------------------
-
-To see the Unimgr API, browse to this URL:
-http://localhost:8181/apidoc/explorer/index.html
-
-Replace localhost with the IP address or hostname where OpenDaylight is
-running if you are not running OpenDaylight locally on your machine.
-
-See also the Unimgr Developer Guide for a full listing of the API.
-------------------------------------
After installing the odl-usc-channel-ui feature from the Karaf console,
-users can administer and manage USC channels from the the UI or APIDOCS
+users can administer and manage USC channels from the UI or APIDOCS
explorer.
Go to
+++ /dev/null
-.. _vtn-user-guide:
-
-Virtual Tenant Network (VTN)
-============================
-
-VTN Overview
-------------
-
-OpenDaylight Virtual Tenant Network (VTN) is an application that
-provides multi-tenant virtual network on an SDN controller.
-
-Conventionally, huge investment in the network systems and operating
-expenses are needed because the network is configured as a silo for each
-department and system. So, various network appliances must be installed
-for each tenant and those boxes cannot be shared with others. It is a
-heavy work to design, implement and operate the entire complex network.
-
-The uniqueness of VTN is a logical abstraction plane. This enables the
-complete separation of logical plane from physical plane. Users can
-design and deploy any desired network without knowing the physical
-network topology or bandwidth restrictions.
-
-VTN allows the users to define the network with a look and feel of
-conventional L2/L3 network. Once the network is designed on VTN, it will
-automatically be mapped into underlying physical network, and then
-configured on the individual switch leveraging SDN control protocol. The
-definition of logical plane makes it possible not only to hide the
-complexity of the underlying network but also to better manage network
-resources. It achieves reducing reconfiguration time of network services
-and minimizing network configuration errors.
-
-.. figure:: ./images/vtn/VTN_Overview.jpg
- :alt: VTN Overview
-
- VTN Overview
-
-It is implemented as two major components
-
-- `VTN Manager`
-
-- `VTN Coordinator`
-
-VTN Manager
-~~~~~~~~~~~
-
-An OpenDaylight Plugin that interacts with other modules to implement
-the components of the VTN model. It also provides a REST interface to
-configure VTN components in OpenDaylight. VTN Manager is implemented as
-one plugin to the OpenDaylight. This provides a REST interface to
-create/update/delete VTN components. The user command in VTN Coordinator
-is translated as REST API to VTN Manager by the OpenDaylight Driver
-component. In addition to the above mentioned role, it also provides an
-implementation to the OpenStack L2 Network Functions API.
-
-Features Overview
-^^^^^^^^^^^^^^^^^
-
-- **odl-vtn-manager** provides VTN Manager’s JAVA API.
-
-- **odl-vtn-manager-rest** provides VTN Manager’s REST API.
-
-- **odl-vtn-manager-neutron** provides the integration with Neutron
- interface.
-
-REST API
-^^^^^^^^
-
-VTN Manager provides REST API for virtual network functions.
-
-Here is an example of how to create a virtual tenant network.
-
-::
-
- curl --user "admin":"admin" -H "Accept: application/json" -H \
- "Content-type: application/json" -X POST \
- http://localhost:8181/restconf/operations/vtn:update-vtn \
- -d '{"input":{"tenant-name":"vtn1"}}'
-
-You can check the list of all tenants by executing the following
-command.
-
-::
-
- curl --user "admin":"admin" -H "Accept: application/json" -H \
- "Content-type: application/json" -X GET \
- http://localhost:8181/restconf/operational/vtn:vtns
-
-REST Conf documentation for VTN Manager, please refer to:
-https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/apidocs/index.html
-
-
-VTN Coordinator
-~~~~~~~~~~~~~~~
-
-The VTN Coordinator is an external application that provides a REST
-interface for an user to use OpenDaylight VTN Virtualization. It
-interacts with VTN Manager plugin to implement the user configuration.
-It is also capable of multiple OpenDaylight orchestration. It realizes
-Virtual Tenant Network (VTN) provisioning in OpenDaylight instances. In
-the OpenDaylight architecture VTN Coordinator is part of the network
-application, orchestration and services layer. VTN Coordinator will use
-the REST interface exposed by the VTN Manger to realize the virtual
-network using OpenDaylight. It uses OpenDaylight APIs (REST) to
-construct the virtual network in OpenDaylight instances. It provides
-REST APIs for northbound VTN applications and supports virtual networks
-spanning across multiple OpenDaylight by coordinating across
-OpenDaylight.
-
-For VTN Coordinator REST API, please refer to:
-https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Coordinator:RestApi
-
-Network Virtualization Function
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The user first defines a VTN. Then, the user maps the VTN to a physical
-network, which enables communication to take place according to the VTN
-definition. With the VTN definition, L2 and L3 transfer functions and
-flow-based traffic control functions (filtering and redirect) are
-possible.
-
-Virtual Network Construction
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The following table shows the elements which make up the VTN. In the
-VTN, a virtual network is constructed using virtual nodes (vBridge,
-vRouter) and virtual interfaces and links. It is possible to configure a
-network which has L2 and L3 transfer function, by connecting the virtual
-intrefaces made on virtual nodes via virtual links.
-
-+--------------------------------------+--------------------------------------+
-| vBridge | The logical representation of L2 |
-| | switch function. |
-+--------------------------------------+--------------------------------------+
-| vRouter | The logical representation of router |
-| | function. |
-+--------------------------------------+--------------------------------------+
-| vTep | The logical representation of Tunnel |
-| | End Point - TEP. |
-+--------------------------------------+--------------------------------------+
-| vTunnel | The logical representation of |
-| | Tunnel. |
-+--------------------------------------+--------------------------------------+
-| vBypass | The logical representation of |
-| | connectivity between controlled |
-| | networks. |
-+--------------------------------------+--------------------------------------+
-| Virtual interface | The representation of end point on |
-| | the virtual node. |
-+--------------------------------------+--------------------------------------+
-| Virtual Linkv(vLink) | The logical representation of L1 |
-| | connectivity between virtual |
-| | interfaces. |
-+--------------------------------------+--------------------------------------+
-
-The following figure shows an example of a constructed virtual network.
-VRT is defined as the vRouter, BR1 and BR2 are defined as vBridges.
-interfaces of the vRouter and vBridges are connected using vLinks.
-
-.. figure:: ./images/vtn/VTN_Construction.jpg
- :alt: VTN Construction
-
- VTN Construction
-
-Mapping of Physical Network Resources
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Map physical network resources to the constructed virtual network.
-Mapping identifies which virtual network each packet transmitted or
-received by an OpenFlow switch belongs to, as well as which interface in
-the OpenFlow switch transmits or receives that packet. There are two
-mapping methods. When a packet is received from the OFS, port mapping is
-first searched for the corresponding mapping definition, then VLAN
-mapping is searched, and the packet is mapped to the relevant vBridge
-according to the first matching mapping.
-
-+--------------------------------------+--------------------------------------+
-| Port mapping | Maps physical network resources to |
-| | an interface of vBridge using Switch |
-| | ID, Port ID and VLAN ID of the |
-| | incoming L2 frame. Untagged frame |
-| | mapping is also supported. |
-+--------------------------------------+--------------------------------------+
-| VLAN mapping | Maps physical network resources to a |
-| | vBridge using VLAN ID of the |
-| | incoming L2 frame.Maps physical |
-| | resources of a particular switch to |
-| | a vBridge using switch ID and VLAN |
-| | ID of the incoming L2 frame. |
-+--------------------------------------+--------------------------------------+
-| MAC mapping | Maps physical resources to an |
-| | interface of vBridge using MAC |
-| | address of the incoming L2 frame(The |
-| | initial contribution does not |
-| | include this method). |
-+--------------------------------------+--------------------------------------+
-
-VTN can learn the terminal information from a terminal that is connected
-to a switch which is mapped to VTN. Further, it is possible to refer
-that terminal information on the VTN.
-
-- Learning terminal information VTN learns the information of a
- terminal that belongs to VTN. It will store the MAC address and VLAN
- ID of the terminal in relation to the port of the switch.
-
-- Aging of terminal information Terminal information, learned by the
- VTN, will be maintained until the packets from terminal keep flowing
- in VTN. If the terminal gets disconnected from the VTN, then the
- aging timer will start clicking and the terminal information will be
- maintained till timeout.
-
-The following figure shows an example of mapping. An interface of BR1 is
-mapped to port GBE0/1 of OFS1 using port mapping. Packets received from
-GBE0/1 of OFS1 are regarded as those from the corresponding interface of
-BR1. BR2 is mapped to VLAN 200 using VLAN mapping. Packets with VLAN tag
-200 received from any ports of any OFSs are regarded as those from an
-interface of BR2.
-
-.. figure:: ./images/vtn/VTN_Mapping.jpg
- :alt: VTN Mapping
-
- VTN Mapping
-
-vBridge Functions
-~~~~~~~~~~~~~~~~~
-
-The vBridge provides the bridge function that transfers a packet to the
-intended virtual port according to the destination MAC address. The
-vBridge looks up the MAC address table and transmits the packet to the
-corresponding virtual interface when the destination MAC address has
-been learned. When the destination MAC address has not been learned, it
-transmits the packet to all virtual interfaces other than the receiving
-port (flooding). MAC addresses are learned as follows.
-
-- MAC address learning The vBridge learns the MAC address of the
- connected host. The source MAC address of each received frame is
- mapped to the receiving virtual interface, and this MAC address is
- stored in the MAC address table created on a per-vBridge basis.
-
-- MAC address aging The MAC address stored in the MAC address table is
- retained as long as the host returns the ARP reply. After the host is
- disconnected, the address is retained until the aging timer times
- out. To have the vBridge learn MAC addresses statically, you can
- register MAC addresses manually.
-
-vRouter Functions
-~~~~~~~~~~~~~~~~~
-
-The vRouter transfers IPv4 packets between vBridges. The vRouter
-supports routing, ARP learning, and ARP aging functions. The following
-outlines the functions.
-
-- Routing function When an IP address is registered with a virtual
- interface of the vRouter, the default routing information for that
- interface is registered. It is also possible to statically register
- routing information for a virtual interface.
-
-- ARP learning function The vRouter associates a destination IP
- address, MAC address and a virtual interface, based on an ARP request
- to its host or a reply packet for an ARP request, and maintains this
- information in an ARP table prepared for each routing domain. The
- registered ARP entry is retained until the aging timer, described
- later, times out. The vRouter transmits an ARP request on an
- individual aging timer basis and deletes the associated entry from
- the ARP table if no reply is returned. For static ARP learning, you
- can register ARP entry information manually.
-
-- DHCP relay agent function The vRouter also provides the DHCP relay
- agent function.
-
-Flow Filter Functions
-~~~~~~~~~~~~~~~~~~~~~
-
-Flow Filter function is similar to ACL. It is possible to allow or
-prohibit communication with only certain kind of packets that meet a
-particular condition. Also, it can perform a processing called
-Redirection - WayPoint routing, which is different from the existing
-ACL. Flow Filter can be applied to any interface of a vNode within VTN,
-and it is possible to the control the packets that pass interface. The
-match conditions that could be specified in Flow Filter are as follows.
-It is also possible to specify a combination of multiple conditions.
-
-- Source MAC address
-
-- Destination MAC address
-
-- MAC ether type
-
-- VLAN Priority
-
-- Source IP address
-
-- Destination IP address
-
-- DSCP
-
-- IP Protocol
-
-- TCP/UDP source port
-
-- TCP/UDP destination port
-
-- ICMP type
-
-- ICMP code
-
-The types of Action that can be applied on packets that match the Flow
-Filter conditions are given in the following table. It is possible to
-make only those packets, which match a particular condition, to pass
-through a particular server by specifying Redirection in Action. E.g.,
-path of flow can be changed for each packet sent from a particular
-terminal, depending upon the destination IP address. VLAN priority
-control and DSCP marking are also supported.
-
-+--------------------------------------+--------------------------------------+
-| Action | Function |
-+--------------------------------------+--------------------------------------+
-| Pass | Pass particular packets matching the |
-| | specified conditions. |
-+--------------------------------------+--------------------------------------+
-| Drop | Discards particular packets matching |
-| | the specified conditions. |
-+--------------------------------------+--------------------------------------+
-| Redirection | Redirects the packet to a desired |
-| | virtual interface. Both Transparent |
-| | Redirection (not changing MAC |
-| | address) and Router Redirection |
-| | (changing MAC address) are |
-| | supported. |
-+--------------------------------------+--------------------------------------+
-
-The following figure shows an example of how the flow filter function
-works.
-
-If there is any matching condition specified by flow filter when a
-packet being transferred within a virtual network goes through a virtual
-interface, the function evaluates the matching condition to see whether
-the packet matches it. If the packet matches the condition, the function
-applies the matching action specified by flow filter. In the example
-shown in the figure, the function evaluates the matching condition at
-BR1 and discards the packet if it matches the condition.
-
-.. figure:: ./images/vtn/VTN_Flow_Filter.jpg
- :alt: VTN FlowFilter
-
- VTN FlowFilter
-
-Multiple SDN Controller Coordination
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-With the network abstractions, VTN enables to configure virtual network
-across multiple SDN controllers. This provides highly scalable network
-system.
-
-VTN can be created on each SDN controller. If users would like to manage
-those multiple VTNs with one policy, those VTNs can be integrated to a
-single VTN.
-
-As a use case, this feature is deployed to multi data center
-environment. Even if those data centers are geographically separated and
-controlled with different controllers, a single policy virtual network
-can be realized with VTN.
-
-Also, one can easily add a new SDN Controller to an existing VTN or
-delete a particular SDN Controller from VTN.
-
-In addition to this, one can define a VTN which covers both OpenFlow
-network and Overlay network at the same time.
-
-Flow Filter, which is set on the VTN, will be automatically applied on
-the newly added SDN Controller.
-
-Coordination between OpenFlow Network and L2/L3 Network
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-It is possible to configure VTN on an environment where there is mix of
-L2/L3 switches as well. L2/L3 switch will be shown on VTN as vBypass.
-Flow Filter or policing cannot be configured for a vBypass. However, it
-is possible to treat it as a virtual node inside VTN.
-
-Virtual Tenant Network (VTN) API
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-VTN provides Web APIs. They are implemented by REST architecture and
-provide the access to resources within VTN that are identified by URI.
-User can perform the operations like GET/PUT/POST/DELETE against the
-virtual network resources (e.g. vBridge or vRouter) by sending a message
-to VTN through HTTPS communication in XML or JSON format.
-
-.. figure:: ./images/vtn/VTN_API.jpg
- :alt: VTN API
-
- VTN API
-
-Function Outline
-^^^^^^^^^^^^^^^^
-
-VTN provides following operations for various network resources.
-
-+----------------+----------------+----------------+----------------+----------------+
-| Resources | GET | POST | PUT | DELETE |
-+----------------+----------------+----------------+----------------+----------------+
-| VTN | Yes | Yes | Yes | Yes |
-+----------------+----------------+----------------+----------------+----------------+
-| vBridge | Yes | Yes | Yes | Yes |
-+----------------+----------------+----------------+----------------+----------------+
-| vRouter | Yes | Yes | Yes | Yes |
-+----------------+----------------+----------------+----------------+----------------+
-| vTep | Yes | Yes | Yes | Yes |
-+----------------+----------------+----------------+----------------+----------------+
-| vTunnel | Yes | Yes | Yes | Yes |
-+----------------+----------------+----------------+----------------+----------------+
-| vBypass | Yes | Yes | Yes | Yes |
-+----------------+----------------+----------------+----------------+----------------+
-| vLink | Yes | Yes | Yes | Yes |
-+----------------+----------------+----------------+----------------+----------------+
-| Interface | Yes | Yes | Yes | Yes |
-+----------------+----------------+----------------+----------------+----------------+
-| Port map | Yes | No | Yes | Yes |
-+----------------+----------------+----------------+----------------+----------------+
-| Vlan map | Yes | Yes | Yes | Yes |
-+----------------+----------------+----------------+----------------+----------------+
-| Flowfilter | Yes | Yes | Yes | Yes |
-| (ACL/redirect) | | | | |
-+----------------+----------------+----------------+----------------+----------------+
-| Controller | Yes | Yes | Yes | Yes |
-| information | | | | |
-+----------------+----------------+----------------+----------------+----------------+
-| Physical | Yes | No | No | No |
-| topology | | | | |
-| information | | | | |
-+----------------+----------------+----------------+----------------+----------------+
-| Alarm | Yes | No | No | No |
-| information | | | | |
-+----------------+----------------+----------------+----------------+----------------+
-
-Example usage
-^^^^^^^^^^^^^
-
-The following is an example of the usage to construct a virtual network.
-
-- Create VTN
-
-::
-
- curl --user admin:adminpass -X POST -H 'content-type: application/json' \
- -d '{"vtn":{"vtn_name":"VTN1"}}' http://172.1.0.1:8083/vtn-webapi/vtns.json
-
-- Create Controller Information
-
-::
-
- curl --user admin:adminpass -X POST -H 'content-type: application/json' \
- -d '{"controller": {"controller_id":"CONTROLLER1","ipaddr":"172.1.0.1","type":"odc","username":"admin", \
- "password":"admin","version":"1.0"}}' http://172.1.0.1:8083/vtn-webapi/controllers.json
-
-- Create vBridge under VTN
-
-::
-
- curl --user admin:adminpass -X POST -H 'content-type: application/json' \
- -d '{"vbridge":{"vbr_name":"VBR1","controller_id": "CONTROLLER1","domain_id": "(DEFAULT)"}}' \
- http://172.1.0.1:8083/vtn-webapi/vtns/VTN1/vbridges.json
-
-- Create the interface under vBridge
-
-::
-
- curl --user admin:adminpass -X POST -H 'content-type: application/json' \
- -d '{"interface":{"if_name":"IF1"}}' http://172.1.0.1:8083/vtn-webapi/vtns/VTN1/vbridges/VBR1/interfaces.json
-
-VTN OpenStack Configuration
----------------------------
-
-This guide describes how to set up OpenStack for integration with
-OpenDaylight Controller.
-
-While OpenDaylight Controller provides several ways to integrate with
-OpenStack, this guide focus on the way which uses VTN features available
-on OpenDaylight. In the integration, VTN Manager work as network service
-provider for OpenStack.
-
-VTN Manager features, enable OpenStack to work in pure OpenFlow
-environment in which all switches in data plane are OpenFlow switch.
-
-Requirements
-~~~~~~~~~~~~
-
-- OpenDaylight Controller. (VTN features must be installed)
-
-- OpenStack Control Node.
-
-- OpenStack Compute Node.
-
-- OpenFlow Switch like mininet(Not Mandatory).
-
-The VTN features support multiple OpenStack nodes. You can deploy
-multiple OpenStack Compute Nodes. In management plane, OpenDaylight
-Controller, OpenStack nodes and OpenFlow switches should communicate
-with each other. In data plane, Open vSwitches running in OpenStack
-nodes should communicate with each other through a physical or logical
-OpenFlow switches. The core OpenFlow switches are not mandatory.
-Therefore, you can directly connect to the Open vSwitch’s.
-
-.. figure:: ./images/vtn/OpenStack_Demo_Picture.png
- :alt: Openstack Overview
-
- Openstack Overview
-
-Sample Configuration
-~~~~~~~~~~~~~~~~~~~~
-
-Below steps depicts the configuration of single OpenStack Control node
-and OpenStack Compute node setup. Our test setup is as follows
-
-.. figure:: ./images/vtn/vtn_devstack_setup.png
- :alt: LAB Setup
-
- LAB Setup
-
-**Server Preparation**
-
-- Install Ubuntu 14.04 LTS in two servers (OpenStack Control node and
- Compute node respectively)
-
-- While installing, Ubuntu mandates creation of a User, we created the
- user "stack"(We will use the same user for running devstack)
-
-- Proceed with the below mentioned User Settings and Network Settings
- in both the Control and Compute nodes.
-
-**User Settings for devstack** - Login to both servers - Disable Ubuntu
-Firewall
-
-::
-
- sudo ufw disable
-
-- Install the below packages (optional, provides ifconfig and route
- coammnds, handy for debugging!!)
-
- ::
-
- sudo apt-get install net-tools
-
-- Edit sudo vim /etc/sudoers and add an entry as follows
-
- ::
-
- stack ALL=(ALL) NOPASSWD: ALL
-
-**Network Settings** - Checked the output of ifconfig -a, two interfaces
-were listed eth0 and eth1 as indicated in the image above. - We had
-connected eth0 interface to the Network where OpenDaylight is reachable.
-- eth1 interface in both servers were connected to a different network
-to act as data plane for the VM’s created using the OpenStack. -
-Manually edited the file : sudo vim /etc/network/interfaces and made
-entries as follows
-
-::
-
- stack@ubuntu-devstack:~/devstack$ cat /etc/network/interfaces
- # This file describes the network interfaces available on your system
- # and how to activate them. For more information, see interfaces(5).
- # The loop-back network interface
- auto lo
- iface lo inet loopback
- # The primary network interface
- auto eth0
- iface eth0 inet static
- address <IP_ADDRESS_TO_REACH_ODL>
- netmask <NET_MASK>
- broadcast <BROADCAST_IP_ADDRESS>
- gateway <GATEWAY_IP_ADDRESS>
- auto eth1
- iface eth1 inet static
- address <IP_ADDRESS_UNIQ>
- netmask <NETMASK>
-
-.. note::
-
- Please ensure that the eth0 interface is the default route and it is
- able to reach the ODL\_IP\_ADDRESS NOTE: The entries for eth1 are
- not mandatory, If not set, we may have to manually do "ifup eth1"
- after the stacking is complete to activate the interface
-
-**Finalize the user and network settings** - Please reboot both nodes
-after the user and network settings to have the network settings applied
-to the network - Login again and check the output of ifconfig to ensure
-that both interfaces are listed
-
-OpenDaylight Settings and Execution
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-VTN Configuration for OpenStack Integration:
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- VTN uses the configuration parameters from "90-vtn-neutron.xml" file
- for the OpenStack integration.
-
-- These values will be set for the OpenvSwitch, in all the
- participating OpenStack nodes.
-
-- A configuration file "90-vtn-neutron.xml" will be generated
- automatically by following the below steps,
-
-- Download the latest Boron karaf distribution from the below link,
-
- ::
-
- http://www.opendaylight.org/software/downloads
-
-- cd "distribution-karaf-0.5.0-Boron" and run karaf by using the
- following command "./bin/karaf".
-
-- Install the below feature to generate "90-vtn-neutron.xml"
-
-::
-
- feature:install odl-vtn-manager-neutron
-
-- Logout from the karaf console and Check "90-vtn-neutron.xml" file
- from the following path
- "distribution-karaf-0.5.0-Boron/etc/opendaylight/karaf/".
-
-- The contents of "90-vtn-neutron.xml" should be as follows:
-
-bridgename=br-int portname=eth1 protocols=OpenFlow13 failmode=secure
-
-- The values of the configuration parameters must be changed based on
- the user environment.
-
-- Especially, "portname" should be carefully configured, because if the
- value is wrong, OpenDaylight fails to forward packets.
-
-- Other parameters works fine as is for general use cases.
-
- - bridgename
-
- - The name of the bridge in Open vSwitch, that will be created by
- OpenDaylight Controller.
-
- - It must be "br-int".
-
- - portname
-
- - The name of the port that will be created in the vbridge in
- Open vSwitch.
-
- - This must be the same name of the interface of OpenStack Nodes
- which is used for interconnecting OpenStack Nodes in data
- plane.(in our case:eth1)
-
- - By default, if 90-vtn-neutron.xml is not created, VTN uses
- ens33 as portname.
-
- - protocols
-
- - OpenFlow protocol through which OpenFlow Switch and Controller
- communicate.
-
- - The values can be OpenFlow13 or OpenFlow10.
-
- - failmode
-
- - The value can be "standalone" or "secure".
-
- - Please use "secure" for general use cases.
-
-Start ODL Controller
-^^^^^^^^^^^^^^^^^^^^
-
-- Please refer to the Installation Pages to run ODL with VTN Feature
- enabled.
-
-- After running ODL Controller, please ensure ODL Controller listens to
- the ports:6633,6653, 6640 and 8080
-
-- Please allow the ports in firewall for the devstack to be able to
- communicate with ODL Controller.
-
-.. note::
-
- - 6633/6653 - OpenFlow Ports
-
- - 6640 - OVS Manager Port
-
- - 8080 - Port for REST API
-
-Devstack Setup
-~~~~~~~~~~~~~~
-
-Get Devstack (All nodes)
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Install git application using
-
- - sudo apt-get install git
-
-- Get devstack
-
- - git clone https://git.openstack.org/openstack-dev/devstack;
-
-- Switch to stable/Juno Version branch
-
- - cd devstack
-
- ::
-
- git checkout stable/juno
-
-.. note::
-
- If you want to use stable/kilo Version branch, Please execute the
- below command in devstack folder
-
-::
-
- git checkout stable/kilo
-
-.. note::
-
- If you want to use stable/liberty Version branch, Please execute the
- below command in devstack folder
-
-::
-
- git checkout stable/liberty
-
-Stack Control Node
-^^^^^^^^^^^^^^^^^^
-
-- local.conf:
-
-- cd devstack in the controller node
-
-- Copy the contents of local.conf for juno (devstack control node) from
- https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Scripts:devstack
- and save it as "local.conf" in the "devstack".
-
-- Copy the contents of local.conf for kilo and liberty (devstack
- control node) from
- https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Scripts:devstack_post_juno_versions
- and save it as "local.conf" in the "devstack".
-
-- Please modify the IP Address values as required.
-
-- Stack the node
-
- ::
-
- ./stack.sh
-
-Verify Control Node stacking
-''''''''''''''''''''''''''''
-
-- stack.sh prints out Horizon is now available at
- http://<CONTROL\_NODE\_IP\_ADDRESS>:8080/
-
-- Execute the command *sudo ovs-vsctl show* in the control node
- terminal and verify if the bridge *br-int* is created.
-
-- Typical output of the ovs-vsctl show is indicated below:
-
-::
-
- e232bbd5-096b-48a3-a28d-ce4a492d4b4f
- Manager "tcp:192.168.64.73:6640"
- is_connected: true
- Bridge br-int
- Controller "tcp:192.168.64.73:6633"
- is_connected: true
- fail_mode: secure
- Port "eth1"
- Interface "eth1"
- ovs_version: "2.0.2"
-
-Stack Compute Node
-^^^^^^^^^^^^^^^^^^
-
-- local.conf:
-
-- cd devstack in the controller node
-
-- Copy the contents of local.conf for juno (devstack compute node) from
- https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Scripts:devstack
- and save it as "local.conf" in the "devstack".
-
-- Copy the contents of local.conf file for kilo and liberty (devstack
- compute node) from
- https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Scripts:devstack_post_juno_versions
- and save it as "local.conf" in the "devstack".
-
-- Please modify the IP Address values as required.
-
-- Stack the node
-
- ::
-
- ./stack.sh
-
-Verify Compute Node Stacking
-''''''''''''''''''''''''''''
-
-- stack.sh prints out This is your host ip:
- <COMPUTE\_NODE\_IP\_ADDRESS>
-
-- Execute the command *sudo ovs-vsctl show* in the control node
- terminal and verify if the bridge *br-int* is created.
-
-- The output of the ovs-vsctl show will be similar to the one seen in
- control node.
-
-Additional Verifications
-^^^^^^^^^^^^^^^^^^^^^^^^
-::
-
- ifup <interface_name>
-
-- Please Accept Promiscuous mode in the networks involving the
- interconnect.
-
-Create VM from Devstack Horizon GUI
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Login to
- http://<CONTROL\_NODE\_IP>:8080/
- to check the horizon GUI.
-
-.. figure:: ./images/vtn/OpenStackGui.png
- :alt: Horizon GUI
-
- Horizon GUI
-
-Enter the value for User Name as admin and enter the value for Password
-as labstack.
-
-- We should first ensure both the hypervisors(control node and compute
- node) are mapped under hypervisors by clicking on Hpervisors tab.
-
-.. figure:: ./images/vtn/Hypervisors.png
- :alt: Hypervisors
-
- Hypervisors
-
-- Create a new Network from Horizon GUI.
-
-- Click on Networks Tab.
-
-- click on the Create Network button.
-
-.. figure:: ./images/vtn/Create_Network.png
- :alt: Create Network
-
- Create Network
-
-- A popup screen will appear.
-
-- Enter network name and click Next button.
-
-.. figure:: ./images/vtn/Creare_Network_Step_1.png
- :alt: Step 1
-
- Step 1
-
-- Create a sub network by giving Network Address and click Next button
- .
-
-.. figure:: ./images/vtn/Create_Network_Step_2.png
- :alt: Step 2
-
- Step 2
-
-- Specify the additional details for subnetwork (please refer the image
- for your reference).
-
-.. figure:: ./images/vtn/Create_Network_Step_3.png
- :alt: Step 3
-
- Step 3
-
-- Click Create button
-
-- Create VM Instance
-
-- Navigate to Instances tab in the GUI.
-
-.. figure:: ./images/vtn/Instance_Creation.png
- :alt: Instance Creation
-
- Instance Creation
-
-- Click on Launch Instances button.
-
-.. figure:: ./images/vtn/Launch_Instance.png
- :alt: Launch Instance
-
- Launch Instance
-
-- Click on Details tab to enter the VM details.For this demo we are
- creating Ten VM’s(instances).
-
-- In the Networking tab, we must select the network,for this we need to
- drag and drop the Available networks to Selected Networks (i.e.,)
- Drag vtn1 we created from Available networks to Selected Networks and
- click Launch to create the instances.
-
-.. figure:: ./images/vtn/Launch_Instance_network.png
- :alt: Launch Network
-
- Launch Network
-
-- Ten VM’s will be created.
-
-.. figure:: ./images/vtn/Load_All_Instances.png
- :alt: Load All Instances
-
- Load All Instances
-
-- Click on any VM displayed in the Instances tab and click the Console
- tab.
-
-.. figure:: ./images/vtn/Instance_Console.png
- :alt: Instance Console
-
- Instance Console
-
-- Login to the VM console and verify with a ping command.
-
-.. figure:: ./images/vtn/Instance_ping.png
- :alt: Ping
-
- Ping
-
-Verification of Control and Compute Node after VM creation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Every time a new VM is created, more interfaces are added to the
- br-int bridge in Open vSwitch.
-
-- Use *sudo ovs-vsctl show* to list the number of interfaces added.
-
-OpenStack PackStack Installation Steps
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- Please go through the below wiki page for OpenStack PackStack
- installation steps.
-
- - https://wiki.opendaylight.org/view/Release/Lithium/VTN/User_Guide/Openstack_Packstack_Support
-
-References
-~~~~~~~~~~
-
-- http://devstack.org/guides/multinode-lab.html
-
-- https://wiki.opendaylight.org/view/File:Vtn_demo_hackfest_2014_march.pdf
-
-VTN Manager Usage Examples
---------------------------
-
-How to provision virtual L2 Network
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-This page explains how to provision virtual L2 network using VTN
-Manager. This page targets Boron release, so the procedure described
-here does not work in other releases.
-
-.. figure:: ./images/vtn/How_to_provision_virtual_L2_network.png
- :alt: Virtual L2 network for host1 and host3
-
- Virtual L2 network for host1 and host3
-
-Requirements
-^^^^^^^^^^^^
-
-Mininet
-'''''''
-
-- To provision OpenFlow switches, this page uses Mininet. Mininet
- details and set-up can be referred at the following page:
- https://wiki.opendaylight.org/view/OpenDaylight_Controller:Installation#Using_Mininet
-
-- Start Mininet and create three switches(s1, s2, and s3) and four
- hosts(h1, h2, h3, and h4) in it.
-
-::
-
- mininet@mininet-vm:~$ sudo mn --controller=remote,ip=192.168.0.100 --topo tree,2
-
-.. note::
-
- Replace "192.168.0.100" with the IP address of OpenDaylight
- controller based on your environment.
-
-- you can check the topology that you have created by executing "net"
- command in the Mininet console.
-
-::
-
- mininet> net
- h1 h1-eth0:s2-eth1
- h2 h2-eth0:s2-eth2
- h3 h3-eth0:s3-eth1
- h4 h4-eth0:s3-eth2
- s1 lo: s1-eth1:s2-eth3 s1-eth2:s3-eth3
- s2 lo: s2-eth1:h1-eth0 s2-eth2:h2-eth0 s2-eth3:s1-eth1
- s3 lo: s3-eth1:h3-eth0 s3-eth2:h4-eth0 s3-eth3:s1-eth2
-
-- In this guide, you will provision the virtual L2 network to establish
- communication between h1 and h3.
-
-Configuration
-^^^^^^^^^^^^^
-
-To provision the virtual L2 network for the two hosts (h1 and h3),
-execute REST API provided by VTN Manager as follows. It uses curl
-command to call the REST API.
-
-- Create a virtual tenant named vtn1 by executing `the update-vtn
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn.html#update-vtn>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:update-vtn -d '{"input":{"tenant-name":"vtn1"}}'
-
-- Create a virtual bridge named vbr1 in the tenant vtn1 by executing
- `the update-vbridge
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vbridge.html#update-vbridge>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1"}}'
-
-- Create two interfaces into the virtual bridge by executing `the
- update-vinterface
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vinterface.html#update-vinterface>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if1"}}'
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if2"}}'
-
-- Configure two mappings on the created interfaces by executing `the
- set-port-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-port-map.html#set-port-map>`__.
-
- - The interface if1 of the virtual bridge will be mapped to the port
- "s2-eth1" of the switch "openflow:2" of the Mininet.
-
- - The h1 is connected to the port "s2-eth1".
-
- - The interface if2 of the virtual bridge will be mapped to the port
- "s3-eth1" of the switch "openflow:3" of the Mininet.
-
- - The h3 is connected to the port "s3-eth1".
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if1", "node":"openflow:2", "port-name":"s2-eth1"}}'
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if2", "node":"openflow:3", "port-name":"s3-eth1"}}'
-
-Verification
-^^^^^^^^^^^^
-
-- Please execute ping from h1 to h3 to verify if the virtual L2 network
- for h1 and h3 is provisioned successfully.
-
-::
-
- mininet> h1 ping h3
- PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
- 64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=243 ms
- 64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=0.341 ms
- 64 bytes from 10.0.0.3: icmp_seq=3 ttl=64 time=0.078 ms
- 64 bytes from 10.0.0.3: icmp_seq=4 ttl=64 time=0.079 ms
-
-- You can also verify the configuration by executing the following REST
- API. It shows all configuration in VTN Manager.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns/
-
-- The result of the command should be like this.
-
-::
-
- {
- "vtns": {
- "vtn": [
- {
- "name": "vtn1",
- "vtenant-config": {
- "idle-timeout": 300,
- "hard-timeout": 0
- },
- "vbridge": [
- {
- "name": "vbr1",
- "bridge-status": {
- "state": "UP",
- "path-faults": 0
- },
- "vbridge-config": {
- "age-interval": 600
- },
- "vinterface": [
- {
- "name": "if2",
- "vinterface-status": {
- "entity-state": "UP",
- "state": "UP",
- "mapped-port": "openflow:3:3"
- },
- "vinterface-config": {
- "enabled": true
- },
- "port-map-config": {
- "vlan-id": 0,
- "port-name": "s3-eth1",
- "node": "openflow:3"
- }
- },
- {
- "name": "if1",
- "vinterface-status": {
- "entity-state": "UP",
- "state": "UP",
- "mapped-port": "openflow:2:1"
- },
- "vinterface-config": {
- "enabled": true
- },
- "port-map-config": {
- "vlan-id": 0,
- "port-name": "s2-eth1",
- "node": "openflow:2"
- }
- }
- ]
- }
- ]
- }
- ]
- }
- }
-
-Cleaning Up
-^^^^^^^^^^^
-
-- You can delete the virtual tenant vtn1 by executing `the remove-vtn
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn.html#remove-vtn>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:remove-vtn -d '{"input":{"tenant-name":"vtn1"}}'
-
-How To Test Vlan-Map In Mininet Environment
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-This page explains how to test Vlan-map in a multi host scenario using
-mininet. This page targets Boron release, so the procedure described
-here does not work in other releases.
-
-.. figure:: ./images/vtn/vlanmap_using_mininet.png
- :alt: Example that demonstrates vlanmap testing in Mininet Environment
-
- Example that demonstrates vlanmap testing in Mininet Environment
-
-Requirements
-^^^^^^^^^^^^
-
-Save the mininet script given below as vlan\_vtn\_test.py and run the
-mininet script in the mininet environment where Mininet is installed.
-
-Mininet Script
-^^^^^^^^^^^^^^
-
-https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Scripts:Mininet#Network_with_hosts_in_different_vlan
-
-- Run the mininet script
-
-::
-
- sudo mn --controller=remote,ip=192.168.64.13 --custom vlan_vtn_test.py --topo mytopo
-
-.. note::
-
- Replace "192.168.64.13" with the IP address of OpenDaylight
- controller based on your environment.
-
-- You can check the topology that you have created by executing "net"
- command in the Mininet console.
-
-::
-
- mininet> net
- h1 h1-eth0.200:s1-eth1
- h2 h2-eth0.300:s2-eth2
- h3 h3-eth0.200:s2-eth3
- h4 h4-eth0.300:s2-eth4
- h5 h5-eth0.200:s3-eth2
- h6 h6-eth0.300:s3-eth3
- s1 lo: s1-eth1:h1-eth0.200 s1-eth2:s2-eth1 s1-eth3:s3-eth1
- s2 lo: s2-eth1:s1-eth2 s2-eth2:h2-eth0.300 s2-eth3:h3-eth0.200 s2-eth4:h4-eth0.300
- s3 lo: s3-eth1:s1-eth3 s3-eth2:h5-eth0.200 s3-eth3:h6-eth0.300
- c0
-
-Configuration
-^^^^^^^^^^^^^
-
-To test vlan-map, execute REST API provided by VTN Manager as follows.
-
-- Create a virtual tenant named vtn1 by executing `the update-vtn
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn.html#update-vtn>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:update-vtn -d '{"input":{"tenant-name":"vtn1"}}'
-
-- Create a virtual bridge named vbr1 in the tenant vtn1 by executing
- `the update-vbridge
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vbridge.html#update-vbridge>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1"}}'
-
-- Configure a vlan map with vlanid 200 for vBridge vbr1 by executing
- `the add-vlan-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vlan-map.html#add-vlan-map>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vlan-map:add-vlan-map -d '{"input":{"vlan-id":200,"tenant-name":"vtn1","bridge-name":"vbr1"}}'
-
-- Create a virtual bridge named vbr2 in the tenant vtn1 by executing
- `the update-vbridge
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vbridge.html#update-vbridge>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr2"}}'
-
-- Configure a vlan map with vlanid 300 for vBridge vbr2 by executing
- `the add-vlan-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vlan-map.html#add-vlan-map>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vlan-map:add-vlan-map -d '{"input":{"vlan-id":300,"tenant-name":"vtn1","bridge-name":"vbr2"}}'
-
-Verification
-^^^^^^^^^^^^
-
-- Please execute pingall in mininet environment to view the host
- reachability.
-
-::
-
- mininet> pingall
- Ping: testing ping reachability
- h1 -> X h3 X h5 X
- h2 -> X X h4 X h6
- h3 -> h1 X X h5 X
- h4 -> X h2 X X h6
- h5 -> h1 X h3 X X
- h6 -> X h2 X h4 X
-
-- You can also verify the configuration by executing the following REST
- API. It shows all configurations in VTN Manager.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns
-
-- The result of the command should be like this.
-
-::
-
- {
- "vtns": {
- "vtn": [
- {
- "name": "vtn1",
- "vtenant-config": {
- "hard-timeout": 0,
- "idle-timeout": 300,
- "description": "creating vtn"
- },
- "vbridge": [
- {
- "name": "vbr2",
- "vbridge-config": {
- "age-interval": 600,
- "description": "creating vbr2"
- },
- "bridge-status": {
- "state": "UP",
- "path-faults": 0
- },
- "vlan-map": [
- {
- "map-id": "ANY.300",
- "vlan-map-config": {
- "vlan-id": 300
- },
- "vlan-map-status": {
- "active": true
- }
- }
- ]
- },
- {
- "name": "vbr1",
- "vbridge-config": {
- "age-interval": 600,
- "description": "creating vbr1"
- },
- "bridge-status": {
- "state": "UP",
- "path-faults": 0
- },
- "vlan-map": [
- {
- "map-id": "ANY.200",
- "vlan-map-config": {
- "vlan-id": 200
- },
- "vlan-map-status": {
- "active": true
- }
- }
- ]
- }
- ]
- }
- ]
- }
- }
-
-Cleaning Up
-^^^^^^^^^^^
-
-- You can delete the virtual tenant vtn1 by executing `the remove-vtn
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn.html#remove-vtn>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:remove-vtn -d '{"input":{"tenant-name":"vtn1"}}'
-
-How To Configure Service Function Chaining using VTN Manager
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-This page explains how to configure VTN Manager for Service Chaining.
-This page targets Boron release, so the procedure described here
-does not work in other releases.
-
-.. figure:: ./images/vtn/Service_Chaining_With_One_Service.png
- :alt: Service Chaining With One Service
-
- Service Chaining With One Service
-
-Requirements
-^^^^^^^^^^^^
-
-- Please refer to the `Installation
- Pages <https://wiki.opendaylight.org/view/VTN:Boron:Installation_Guide>`__
- to run ODL with VTN Feature enabled.
-
-- Please ensure Bridge-Utils package is installed in mininet
- environment before running the mininet script.
-
-- To install Bridge-Utils package run sudo apt-get install bridge-utils
- (assuming Ubuntu is used to run mininet, If not then this is not
- required).
-
-- Save the mininet script given below as topo\_handson.py and run the
- mininet script in the mininet environment where Mininet is installed.
-
-Mininet Script
-^^^^^^^^^^^^^^
-
-- `Script for emulating network with multiple
- hosts <https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Scripts:Mininet>`__.
-
-- Before executing the mininet script, please confirm Controller is up
- and running.
-
-- Run the mininet script.
-
-- Replace <path> and <Controller IP> based on your environment
-
-::
-
- sudo mn --controller=remote,ip=<Controller IP> --custom <path>\topo_handson.py --topo mytopo2
-
-::
-
- mininet> net
- h11 h11-eth0:s1-eth1
- h12 h12-eth0:s1-eth2
- h21 h21-eth0:s2-eth1
- h22 h22-eth0:s2-eth2
- h23 h23-eth0:s2-eth3
- srvc1 srvc1-eth0:s3-eth3 srvc1-eth1:s4-eth3
- srvc2 srvc2-eth0:s3-eth4 srvc2-eth1:s4-eth4
- s1 lo: s1-eth1:h11-eth0 s1-eth2:h12-eth0 s1-eth3:s2-eth4 s1-eth4:s3-eth2
- s2 lo: s2-eth1:h21-eth0 s2-eth2:h22-eth0 s2-eth3:h23-eth0 s2-eth4:s1-eth3 s2-eth5:s4-eth1
- s3 lo: s3-eth1:s4-eth2 s3-eth2:s1-eth4 s3-eth3:srvc1-eth0 s3-eth4:srvc2-eth0
- s4 lo: s4-eth1:s2-eth5 s4-eth2:s3-eth1 s4-eth3:srvc1-eth1 s4-eth4:srvc2-eth1
-
-Configurations
-^^^^^^^^^^^^^^
-
-Mininet
-'''''''
-
-- Please follow the below steps to configure the network in mininet as
- in the below image:
-
-.. figure:: ./images/vtn/Mininet_Configuration.png
- :alt: Mininet Configuration
-
- Mininet Configuration
-
-Configure service nodes
-'''''''''''''''''''''''
-
-- Please execute the following commands in the mininet console where
- mininet script is executed.
-
-::
-
- mininet> srvc1 ip addr del 10.0.0.6/8 dev srvc1-eth0
- mininet> srvc1 brctl addbr br0
- mininet> srvc1 brctl addif br0 srvc1-eth0
- mininet> srvc1 brctl addif br0 srvc1-eth1
- mininet> srvc1 ifconfig br0 up
- mininet> srvc1 tc qdisc add dev srvc1-eth1 root netem delay 200ms
- mininet> srvc2 ip addr del 10.0.0.7/8 dev srvc2-eth0
- mininet> srvc2 brctl addbr br0
- mininet> srvc2 brctl addif br0 srvc2-eth0
- mininet> srvc2 brctl addif br0 srvc2-eth1
- mininet> srvc2 ifconfig br0 up
- mininet> srvc2 tc qdisc add dev srvc2-eth1 root netem delay 300ms
-
-Controller
-^^^^^^^^^^
-
-Multi-Tenancy
-'''''''''''''
-
-- Please execute the below commands to configure the network topology
- in the controller as in the below image:
-
-.. figure:: ./images/vtn/Tenant2.png
- :alt: Tenant2
-
- Tenant2
-
-Please execute the below commands in controller
-'''''''''''''''''''''''''''''''''''''''''''''''
-
-.. note::
-
- The below commands are for the difference in behavior of Manager in
- Boron topology. The Link below has the details for this bug:
- https://bugs.opendaylight.org/show_bug.cgi?id=3818.
-
-::
-
- curl --user admin:admin -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -X PUT http://localhost:8181/restconf/config/vtn-static-topology:vtn-static-topology/static-edge-ports -d '{"static-edge-ports": {"static-edge-port": [ {"port": "openflow:3:3"}, {"port": "openflow:3:4"}, {"port": "openflow:4:3"}, {"port": "openflow:4:4"}]}}'
-
-- Create a virtual tenant named vtn1 by executing `the update-vtn
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn.html#update-vtn>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:update-vtn -d '{"input":{"tenant-name":"vtn1","update-mode":"CREATE","operation":"SET","description":"creating vtn","idle-timeout":300,"hard-timeout":0}}'
-
-- Create a virtual bridge named vbr1 in the tenant vtn1 by executing
- `the update-vbridge
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vbridge.html#update-vbridge>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"creating vbr","tenant-name":"vtn1","bridge-name":"vbr1"}}'
-
-- Create interface if1 into the virtual bridge vbr1 by executing `the
- update-vinterface
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vinterface.html#update-vinterface>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vbrif1 interface","tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1"}}'
-
-- Configure port mapping on the interface by executing `the
- set-port-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-port-map.html#set-port-map>`__.
-
- - The interface if1 of the virtual bridge will be mapped to the port
- "s1-eth2" of the switch "openflow:1" of the Mininet.
-
- - The h12 is connected to the port "s1-eth2".
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"vlan-id":0,"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1","node":"openflow:1","port-name":"s1-eth2"}}'
-
-- Create interface if2 into the virtual bridge vbr1 by executing `the
- update-vinterface
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vinterface.html#update-vinterface>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vbrif2 interface","tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if2"}}'
-
-- Configure port mapping on the interface by executing `the
- set-port-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-port-map.html#set-port-map>`__.
-
- - The interface if2 of the virtual bridge will be mapped to the port
- "s2-eth2" of the switch "openflow:2" of the Mininet.
-
- - The h22 is connected to the port "s2-eth2".
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"vlan-id":0,"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if2","node":"openflow:2","port-name":"s2-eth2"}}'
-
-- Create interface if3 into the virtual bridge vbr1 by executing `the
- update-vinterface
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vinterface.html#update-vinterface>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vbrif3 interface","tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if3"}}'
-
-- Configure port mapping on the interfaces by executing `the
- set-port-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-port-map.html#set-port-map>`__.
-
- - The interface if3 of the virtual bridge will be mapped to the port
- "s2-eth3" of the switch "openflow:2" of the Mininet.
-
- - The h23 is connected to the port "s2-eth3".
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"vlan-id":0,"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if3","node":"openflow:2","port-name":"s2-eth3"}}'
-
-Traffic filtering
-^^^^^^^^^^^^^^^^^
-
-- Create flowcondition named cond\_1 by executing `the
- set-flow-condition
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-condition.html#set-flow-condition>`__.
-
- - For option source and destination-network, get inet address of
- host h12(src) and h22(dst) from mininet.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:set-flow-condition -d '{"input":{"operation":"SET","present":"false","name":"cond_1","vtn-flow-match":[{"index":1,"vtn-ether-match":{},"vtn-inet-match":{"source-network":"10.0.0.2/32","destination-network":"10.0.0.4/32"}}]}}'
-
-- Flow filter demonstration with DROP action-type. Create Flowfilter in
- VBR Interface if1 by executing `the set-flow-filter
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-filter.html#set-flow-filter>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input":{"output":"false","tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1","vtn-flow-filter":[{"condition":"cond_1","index":10,"vtn-drop-filter":{}}]}}'
-
-Service Chaining
-^^^^^^^^^^^^^^^^
-
-With One Service
-''''''''''''''''
-
-- Please execute the below commands to configure the network topology
- which sends some specific traffic via a single service(External
- device) in the controller as in the below image:
-
-.. figure:: ./images/vtn/Service_Chaining_With_One_Service_LLD.png
- :alt: Service Chaining With One Service LLD
-
- Service Chaining With One Service LLD
-
-- Create a virtual terminal named vt\_srvc1\_1 in the tenant vtn1 by
- executing `the update-vterminal
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vterminal.html#update-vterminal>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vterminal:update-vterminal -d '{"input":{"update-mode":"CREATE","operation":"SET","tenant-name":"vtn1","terminal-name":"vt_srvc1_1","description":"Creating vterminal"}}'
-
-- Create interface IF into the virtual terminal vt\_srvc1\_1 by
- executing `the update-vinterface
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vinterface.html#update-vinterface>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vterminal IF","enabled":"true","tenant-name":"vtn1","terminal-name":"vt_srvc1_1","interface-name":"IF"}}'
-
-- Configure port mapping on the interfaces by executing `the
- set-port-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-port-map.html#set-port-map>`__.
-
- - The interface IF of the virtual terminal will be mapped to the
- port "s3-eth3" of the switch "openflow:3" of the Mininet.
-
- - The h12 is connected to the port "s3-eth3".
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1","terminal-name":"vt_srvc1_1","interface-name":"IF","node":"openflow:3","port-name":"s3-eth3"}}'
-
-- Create a virtual terminal named vt\_srvc1\_2 in the tenant vtn1 by
- executing `the update-vterminal
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vterminal.html#update-vterminal>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vterminal:update-vterminal -d '{"input":{"update-mode":"CREATE","operation":"SET","tenant-name":"vtn1","terminal-name":"vt_srvc1_2","description":"Creating vterminal"}}'
-
-- Create interface IF into the virtual terminal vt\_srvc1\_2 by
- executing `the update-vinterface
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vinterface.html#update-vinterface>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vterminal IF","enabled":"true","tenant-name":"vtn1","terminal-name":"vt_srvc1_2","interface-name":"IF"}}'
-
-- Configure port mapping on the interfaces by executing `the
- set-port-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-port-map.html#set-port-map>`__.
-
- - The interface IF of the virtual terminal will be mapped to the
- port "s4-eth3" of the switch "openflow:4" of the Mininet.
-
- - The h22 is connected to the port "s4-eth3".
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1","terminal-name":"vt_srvc1_2","interface-name":"IF","node":"openflow:4","port-name":"s4-eth3"}}'
-
-- Create flowcondition named cond\_1 by executing `the
- set-flow-condition
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-condition.html#set-flow-condition>`__.
-
- - For option source and destination-network, get inet address of
- host h12(src) and h22(dst) from mininet.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:set-flow-condition -d '{"input":{"operation":"SET","present":"false","name":"cond_1","vtn-flow-match":[{"index":1,"vtn-ether-match":{},"vtn-inet-match":{"source-network":"10.0.0.2/32","destination-network":"10.0.0.4/32"}}]}}'
-
-- Create flowcondition named cond\_any by executing `the
- set-flow-condition
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-condition.html#set-flow-condition>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:set-flow-condition -d '{"input":{"operation":"SET","present":"false","name":"cond_any","vtn-flow-match":[{"index":1}]}}'
-
-- Flow filter demonstration with redirect action-type. Create
- Flowfilter in virtual terminal vt\_srvc1\_2 interface IF by executing
- `the set-flow-filter
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-filter.html#set-flow-filter>`__.
-
- - Flowfilter redirects vt\_srvc1\_2 to bridge1-IF2
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input":{"output":"false","tenant-name":"vtn1","terminal-name":"vt_srvc1_2","interface-name":"IF","vtn-flow-filter":[{"condition":"cond_any","index":10,"vtn-redirect-filter":{"redirect-destination":{"bridge-name":"vbr1","interface-name":"if2"},"output":"true"}}]}}'
-
-- Flow filter demonstration with redirect action-type. Create
- Flowfilter in vbridge vbr1 interface if1 by executing `the
- set-flow-filter
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-filter.html#set-flow-filter>`__.
-
- - Flow filter redirects Bridge1-IF1 to vt\_srvc1\_1
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input":{"output":"false","tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1","vtn-flow-filter":[{"condition":"cond_1","index":10,"vtn-redirect-filter":{"redirect-destination":{"terminal-name":"vt_srvc1_1","interface-name":"IF"},"output":"true"}}]}}'
-
-Verification
-^^^^^^^^^^^^
-
-.. figure:: ./images/vtn/Service_Chaining_With_One_Service_Verification.png
- :alt: Service Chaining With One Service
-
- Service Chaining With One Service
-
-- Ping host12 to host22 to view the host rechability, a delay of 200ms
- will be taken to reach host22 as below.
-
-::
-
- mininet> h12 ping h22
- PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
- 64 bytes from 10.0.0.4: icmp_seq=35 ttl=64 time=209 ms
- 64 bytes from 10.0.0.4: icmp_seq=36 ttl=64 time=201 ms
- 64 bytes from 10.0.0.4: icmp_seq=37 ttl=64 time=200 ms
- 64 bytes from 10.0.0.4: icmp_seq=38 ttl=64 time=200 ms
-
-With two services
-'''''''''''''''''
-
-- Please execute the below commands to configure the network topology
- which sends some specific traffic via two services(External device)
- in the controller as in the below image.
-
-.. figure:: ./images/vtn/Service_Chaining_With_Two_Services_LLD.png
- :alt: Service Chaining With Two Services LLD
-
- Service Chaining With Two Services LLD
-
-- Create a virtual terminal named vt\_srvc2\_1 in the tenant vtn1 by
- executing `the update-vterminal
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vterminal.html#update-vterminal>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vterminal:update-vterminal -d '{"input":{"update-mode":"CREATE","operation":"SET","tenant-name":"vtn1","terminal-name":"vt_srvc2_1","description":"Creating vterminal"}}'
-
-- Create interface IF into the virtual terminal vt\_srvc2\_1 by
- executing `the update-vinterface
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vinterface.html#update-vinterface>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vterminal IF","enabled":"true","tenant-name":"vtn1","terminal-name":"vt_srvc2_1","interface-name":"IF"}}'
-
-- Configure port mapping on the interfaces by executing `the
- set-port-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-port-map.html#set-port-map>`__.
-
- - The interface IF of the virtual terminal will be mapped to the
- port "s3-eth4" of the switch "openflow:3" of the Mininet.
-
- - The host h12 is connected to the port "s3-eth4".
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1","terminal-name":"vt_srvc2_1","interface-name":"IF","node":"openflow:3","port-name":"s3-eth4"}}'
-
-- Create a virtual terminal named vt\_srvc2\_2 in the tenant vtn1 by
- executing `the update-vterminal
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vterminal.html#update-vterminal>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vterminal:update-vterminal -d '{"input":{"update-mode":"CREATE","operation":"SET","tenant-name":"vtn1","terminal-name":"vt_srvc2_2","description":"Creating vterminal"}}'
-
-- Create interfaces IF into the virtual terminal vt\_srvc2\_2 by
- executing `the update-vinterface
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vinterface.html#update-vinterface>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vterminal IF","enabled":"true","tenant-name":"vtn1","terminal-name":"vt_srvc2_2","interface-name":"IF"}}'
-
-- Configure port mapping on the interfaces by executing `the
- set-port-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-port-map.html#set-port-map>`__.
-
- - The interface IF of the virtual terminal will be mapped to the
- port "s4-eth4" of the switch "openflow:4" of the mininet.
-
- - The host h22 is connected to the port "s4-eth4".
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1","terminal-name":"vt_srvc2_2","interface-name":"IF","node":"openflow:4","port-name":"s4-eth4"}}'
-
-- Flow filter demonstration with redirect action-type. Create
- Flowfilter in virtual terminal vt\_srvc2\_2 interface IF by executing
- `the set-flow-filter
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-filter.html#set-flow-filter>`__.
-
- - Flow filter redirects vt\_srvc2\_2 to Bridge1-IF2.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input":{"output":"false","tenant-name":"vtn1","terminal-name":"vt_srvc2_2","interface-name":"IF","vtn-flow-filter":[{"condition":"cond_any","index":10,"vtn-redirect-filter":{"redirect-destination":{"bridge-name":"vbr1","interface-name":"if2"},"output":"true"}}]}}'
-
-- Flow filter demonstration with redirect action-type. Create
- Flowfilter in virtual terminal vt\_srvc2\_2 interface IF by executing
- `the set-flow-filter
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-filter.html#set-flow-filter>`__.
-
- - Flow filter redirects vt\_srvc1\_2 to vt\_srvc2\_1.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input":{"output":"false","tenant-name":"vtn1","terminal-name":"vt_srvc1_2","interface-name":"IF","vtn-flow-filter":[{"condition":"cond_any","index":10,"vtn-redirect-filter":{"redirect-destination":{"terminal-name":"vt_srvc2_1","interface-name":"IF"},"output":"true"}}]}}'
-
-Verification
-^^^^^^^^^^^^
-
-.. figure:: ./images/vtn/Service_Chaining_With_Two_Services.png
- :alt: Service Chaining With Two Service
-
- Service Chaining With Two Service
-
-- Ping host12 to host22 to view the host rechability, a delay of 500ms
- will be taken to reach host22 as below.
-
-::
-
- mininet> h12 ping h22
- PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
- 64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=512 ms
- 64 bytes from 10.0.0.4: icmp_seq=2 ttl=64 time=501 ms
- 64 bytes from 10.0.0.4: icmp_seq=3 ttl=64 time=500 ms
- 64 bytes from 10.0.0.4: icmp_seq=4 ttl=64 time=500 ms
-
-- You can verify the configuration by executing the following REST API.
- It shows all configuration in VTN Manager.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns
-
-::
-
- {
- "vtn": [
- {
- "name": "vtn1",
- "vtenant-config": {
- "hard-timeout": 0,
- "idle-timeout": 300,
- "description": "creating vtn"
- },
- "vbridge": [
- {
- "name": "vbr1",
- "vbridge-config": {
- "age-interval": 600,
- "description": "creating vbr"
- },
- "bridge-status": {
- "state": "UP",
- "path-faults": 0
- },
- "vinterface": [
- {
- "name": "if1",
- "vinterface-status": {
- "mapped-port": "openflow:1:2",
- "state": "UP",
- "entity-state": "UP"
- },
- "port-map-config": {
- "vlan-id": 0,
- "node": "openflow:1",
- "port-name": "s1-eth2"
- },
- "vinterface-config": {
- "description": "Creating vbrif1 interface",
- "enabled": true
- },
- "vinterface-input-filter": {
- "vtn-flow-filter": [
- {
- "index": 10,
- "condition": "cond_1",
- "vtn-redirect-filter": {
- "output": true,
- "redirect-destination": {
- "terminal-name": "vt_srvc1_1",
- "interface-name": "IF"
- }
- }
- }
- ]
- }
- },
- {
- "name": "if2",
- "vinterface-status": {
- "mapped-port": "openflow:2:2",
- "state": "UP",
- "entity-state": "UP"
- },
- "port-map-config": {
- "vlan-id": 0,
- "node": "openflow:2",
- "port-name": "s2-eth2"
- },
- "vinterface-config": {
- "description": "Creating vbrif2 interface",
- "enabled": true
- }
- },
- {
- "name": "if3",
- "vinterface-status": {
- "mapped-port": "openflow:2:3",
- "state": "UP",
- "entity-state": "UP"
- },
- "port-map-config": {
- "vlan-id": 0,
- "node": "openflow:2",
- "port-name": "s2-eth3"
- },
- "vinterface-config": {
- "description": "Creating vbrif3 interface",
- "enabled": true
- }
- }
- ]
- }
- ],
- "vterminal": [
- {
- "name": "vt_srvc2_2",
- "bridge-status": {
- "state": "UP",
- "path-faults": 0
- },
- "vinterface": [
- {
- "name": "IF",
- "vinterface-status": {
- "mapped-port": "openflow:4:4",
- "state": "UP",
- "entity-state": "UP"
- },
- "port-map-config": {
- "vlan-id": 0,
- "node": "openflow:4",
- "port-name": "s4-eth4"
- },
- "vinterface-config": {
- "description": "Creating vterminal IF",
- "enabled": true
- },
- "vinterface-input-filter": {
- "vtn-flow-filter": [
- {
- "index": 10,
- "condition": "cond_any",
- "vtn-redirect-filter": {
- "output": true,
- "redirect-destination": {
- "bridge-name": "vbr1",
- "interface-name": "if2"
- }
- }
- }
- ]
- }
- }
- ],
- "vterminal-config": {
- "description": "Creating vterminal"
- }
- },
- {
- "name": "vt_srvc1_1",
- "bridge-status": {
- "state": "UP",
- "path-faults": 0
- },
- "vinterface": [
- {
- "name": "IF",
- "vinterface-status": {
- "mapped-port": "openflow:3:3",
- "state": "UP",
- "entity-state": "UP"
- },
- "port-map-config": {
- "vlan-id": 0,
- "node": "openflow:3",
- "port-name": "s3-eth3"
- },
- "vinterface-config": {
- "description": "Creating vterminal IF",
- "enabled": true
- }
- }
- ],
- "vterminal-config": {
- "description": "Creating vterminal"
- }
- },
- {
- "name": "vt_srvc1_2",
- "bridge-status": {
- "state": "UP",
- "path-faults": 0
- },
- "vinterface": [
- {
- "name": "IF",
- "vinterface-status": {
- "mapped-port": "openflow:4:3",
- "state": "UP",
- "entity-state": "UP"
- },
- "port-map-config": {
- "vlan-id": 0,
- "node": "openflow:4",
- "port-name": "s4-eth3"
- },
- "vinterface-config": {
- "description": "Creating vterminal IF",
- "enabled": true
- },
- "vinterface-input-filter": {
- "vtn-flow-filter": [
- {
- "index": 10,
- "condition": "cond_any",
- "vtn-redirect-filter": {
- "output": true,
- "redirect-destination": {
- "terminal-name": "vt_srvc2_1",
- "interface-name": "IF"
- }
- }
- }
- ]
- }
- }
- ],
- "vterminal-config": {
- "description": "Creating vterminal"
- }
- },
- {
- "name": "vt_srvc2_1",
- "bridge-status": {
- "state": "UP",
- "path-faults": 0
- },
- "vinterface": [
- {
- "name": "IF",
- "vinterface-status": {
- "mapped-port": "openflow:3:4",
- "state": "UP",
- "entity-state": "UP"
- },
- "port-map-config": {
- "vlan-id": 0,
- "node": "openflow:3",
- "port-name": "s3-eth4"
- },
- "vinterface-config": {
- "description": "Creating vterminal IF",
- "enabled": true
- }
- }
- ],
- "vterminal-config": {
- "description": "Creating vterminal"
- }
- }
- ]
- }
- ]
- }
-
-Cleaning Up
-^^^^^^^^^^^
-
-- To clean up both VTN and flowconditions.
-
-- You can delete the virtual tenant vtn1 by executing `the remove-vtn
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn.html#remove-vtn>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:remove-vtn -d '{"input":{"tenant-name":"vtn1"}}'
-
-- You can delete the flowcondition cond\_1 and cond\_any by executing
- `the remove-flow-condition
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-condition.html#remove-flow-condition>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:remove-flow-condition -d '{"input":{"name":"cond_1"}}'
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:remove-flow-condition -d '{"input":{"name":"cond_any"}}'
-
-How To View Dataflows
-~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-This page explains how to view Dataflows using VTN Manager. This page
-targets Boron release, so the procedure described here does not work
-in other releases.
-
-Dataflow feature enables retrieval and display of data flows in the
-OpenFlow network. The data flows can be retrieved based on an OpenFlow
-switch or a switch port or a L2 source host.
-
-The flow information provided by this feature are
-
-- Location of virtual node which maps the incoming packet and outgoing
- packets.
-
-- Location of physical switch port where incoming and outgoing packets
- is sent and received.
-
-- A sequence of physical route info which represents the packet route
- in the physical network.
-
-Configuration
-^^^^^^^^^^^^^
-
-- To view Dataflow information, configure with VLAN Mapping
- https://wiki.opendaylight.org/view/VTN:Mananger:How_to_test_Vlan-map_using_mininet.
-
-Verification
-^^^^^^^^^^^^
-
-After creating vlan mapping configuration from the above page, execute
-as below in mininet to get switch details.
-
-::
-
- mininet> net
- h1 h1-eth0.200:s1-eth1
- h2 h2-eth0.300:s2-eth2
- h3 h3-eth0.200:s2-eth3
- h4 h4-eth0.300:s2-eth4
- h5 h5-eth0.200:s3-eth2
- h6 h6-eth0.300:s3-eth3
- s1 lo: s1-eth1:h1-eth0.200 s1-eth2:s2-eth1 s1-eth3:s3-eth1
- s2 lo: s2-eth1:s1-eth2 s2-eth2:h2-eth0.300 s2-eth3:h3-eth0.200 s2-eth4:h4-eth0.300
- s3 lo: s3-eth1:s1-eth3 s3-eth2:h5-eth0.200 s3-eth3:h6-eth0.300
- c0
- mininet>
-
-Please execute ping from h1 to h3 to check hosts reachability.
-
-::
-
- mininet> h1 ping h3
- PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
- 64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=11.4 ms
- 64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=0.654 ms
- 64 bytes from 10.0.0.3: icmp_seq=3 ttl=64 time=0.093 ms
-
-Parallely execute below Restconf command to get data flow information of
-node "openflow:1" and its port "s1-eth1".
-
-- Get the Dataflows information by executing `the get-data-flow
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow.html#get-data-flow>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow:get-data-flow -d '{"input":{"tenant-name":"vtn1","mode":"DETAIL","node":"openflow:1","data-flow-port":{"port-id":"1","port-name":"s1-eth1"}}}'
-
-::
-
- {
- "output": {
- "data-flow-info": [
- {
- "averaged-data-flow-stats": {
- "packet-count": 1.1998800119988002,
- "start-time": 1455241209151,
- "end-time": 1455241219152,
- "byte-count": 117.58824117588242
- },
- "physical-route": [
- {
- "physical-ingress-port": {
- "port-name": "s2-eth3",
- "port-id": "3"
- },
- "physical-egress-port": {
- "port-name": "s2-eth1",
- "port-id": "1"
- },
- "node": "openflow:2",
- "order": 0
- },
- {
- "physical-ingress-port": {
- "port-name": "s1-eth2",
- "port-id": "2"
- },
- "physical-egress-port": {
- "port-name": "s1-eth1",
- "port-id": "1"
- },
- "node": "openflow:1",
- "order": 1
- }
- ],
- "data-egress-node": {
- "bridge-name": "vbr1",
- "tenant-name": "vtn1"
- },
- "hard-timeout": 0,
- "idle-timeout": 300,
- "data-flow-stats": {
- "duration": {
- "nanosecond": 640000000,
- "second": 362
- },
- "packet-count": 134,
- "byte-count": 12932
- },
- "data-egress-port": {
- "node": "openflow:1",
- "port-name": "s1-eth1",
- "port-id": "1"
- },
- "data-ingress-node": {
- "bridge-name": "vbr1",
- "tenant-name": "vtn1"
- },
- "data-ingress-port": {
- "node": "openflow:2",
- "port-name": "s2-eth3",
- "port-id": "3"
- },
- "creation-time": 1455240855753,
- "data-flow-match": {
- "vtn-ether-match": {
- "vlan-id": 200,
- "source-address": "6a:ff:e2:81:86:bb",
- "destination-address": "26:9f:82:70:ec:66"
- }
- },
- "virtual-route": [
- {
- "reason": "VLANMAPPED",
- "virtual-node-path": {
- "bridge-name": "vbr1",
- "tenant-name": "vtn1"
- },
- "order": 0
- },
- {
- "reason": "FORWARDED",
- "virtual-node-path": {
- "bridge-name": "vbr1",
- "tenant-name": "vtn1"
- },
- "order": 1
- }
- ],
- "flow-id": 16
- },
- {
- "averaged-data-flow-stats": {
- "packet-count": 1.1998800119988002,
- "start-time": 1455241209151,
- "end-time": 1455241219152,
- "byte-count": 117.58824117588242
- },
- "physical-route": [
- {
- "physical-ingress-port": {
- "port-name": "s1-eth1",
- "port-id": "1"
- },
- "physical-egress-port": {
- "port-name": "s1-eth2",
- "port-id": "2"
- },
- "node": "openflow:1",
- "order": 0
- },
- {
- "physical-ingress-port": {
- "port-name": "s2-eth1",
- "port-id": "1"
- },
- "physical-egress-port": {
- "port-name": "s2-eth3",
- "port-id": "3"
- },
- "node": "openflow:2",
- "order": 1
- }
- ],
- "data-egress-node": {
- "bridge-name": "vbr1",
- "tenant-name": "vtn1"
- },
- "hard-timeout": 0,
- "idle-timeout": 300,
- "data-flow-stats": {
- "duration": {
- "nanosecond": 587000000,
- "second": 362
- },
- "packet-count": 134,
- "byte-count": 12932
- },
- "data-egress-port": {
- "node": "openflow:2",
- "port-name": "s2-eth3",
- "port-id": "3"
- },
- "data-ingress-node": {
- "bridge-name": "vbr1",
- "tenant-name": "vtn1"
- },
- "data-ingress-port": {
- "node": "openflow:1",
- "port-name": "s1-eth1",
- "port-id": "1"
- },
- "creation-time": 1455240855747,
- "data-flow-match": {
- "vtn-ether-match": {
- "vlan-id": 200,
- "source-address": "26:9f:82:70:ec:66",
- "destination-address": "6a:ff:e2:81:86:bb"
- }
- },
- "virtual-route": [
- {
- "reason": "VLANMAPPED",
- "virtual-node-path": {
- "bridge-name": "vbr1",
- "tenant-name": "vtn1"
- },
- "order": 0
- },
- {
- "reason": "FORWARDED",
- "virtual-node-path": {
- "bridge-name": "vbr1",
- "tenant-name": "vtn1"
- },
- "order": 1
- }
- ],
- "flow-id": 15
- }
- ]
- }
- }
-
-How To Create Mac Map In VTN
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-- This page demonstrates Mac Mapping. This demonstration aims at
- enabling communication between two hosts and denying communication of
- particular host by associating a Vbridge to the hosts and configuring
- Mac Mapping (mac address) to the Vbridge.
-
-- This page targets Boron release, so the procedure described here
- does not work in other releases.
-
-.. figure:: ./images/vtn/Single_Controller_Mapping.png
- :alt: Single Controller Mapping
-
- Single Controller Mapping
-
-Requirement
-^^^^^^^^^^^
-
-Configure mininet and create a topology
-'''''''''''''''''''''''''''''''''''''''
-
-- `Script for emulating network with multiple
- hosts <https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Scripts:Mininet#Network_with_Multiple_Hosts_for_Service_Function_Chain>`__.
-
-- Before executing the mininet script, please confirm Controller is up
- and running.
-
-- Run the mininet script.
-
-- Replace <path> and <Controller IP> based on your environment.
-
-::
-
- sudo mn --controller=remote,ip=<Controller IP> --custom <path>\topo_handson.py --topo mytopo2
-
-::
-
- mininet> net
- h11 h11-eth0:s1-eth1
- h12 h12-eth0:s1-eth2
- h21 h21-eth0:s2-eth1
- h22 h22-eth0:s2-eth2
- h23 h23-eth0:s2-eth3
- srvc1 srvc1-eth0:s3-eth3 srvc1-eth1:s4-eth3
- srvc2 srvc2-eth0:s3-eth4 srvc2-eth1:s4-eth4
- s1 lo: s1-eth1:h11-eth0 s1-eth2:h12-eth0 s1-eth3:s2-eth4 s1-eth4:s3-eth2
- s2 lo: s2-eth1:h21-eth0 s2-eth2:h22-eth0 s2-eth3:h23-eth0 s2-eth4:s1-eth3 s2-eth5:s4-eth1
- s3 lo: s3-eth1:s4-eth2 s3-eth2:s1-eth4 s3-eth3:srvc1-eth0 s3-eth4:srvc2-eth0
- s4 lo: s4-eth1:s2-eth5 s4-eth2:s3-eth1 s4-eth3:srvc1-eth1 s4-eth4:srvc2-eth1
-
-Configuration
-^^^^^^^^^^^^^
-
-To create Mac Map in VTN, execute REST API provided by VTN Manager as
-follows. It uses curl command to call REST API.
-
-- Create a virtual tenant named Tenant1 by executing `the update-vtn
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn.html#update-vtn>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:update-vtn -d '{"input":{"tenant-name":"Tenant1"}}'
-
-- Create a virtual bridge named vBridge1 in the tenant Tenant1 by
- executing `the update-vbridge
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vbridge.html#update-vbridge>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"Tenant1","bridge-name":"vBridge1"}}'
-
-- Configuring Mac Mappings on the vBridge1 by giving the mac address of
- host h12 and host h22 as follows to allow the communication by
- executing `the set-mac-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-mac-map.html#set-mac-map>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-mac-map:set-mac-map -d '{"input":{"operation":"SET","allowed-hosts":["de:05:40:c4:96:76@0","62:c5:33:bc:d7:4e@0"],"tenant-name":"Tenant1","bridge-name":"vBridge1"}}'
-
-.. note::
-
- Mac Address of host h12 and host h22 can be obtained with the
- following command in mininet.
-
-::
-
- mininet> h12 ifconfig
- h12-eth0 Link encap:Ethernet HWaddr 62:c5:33:bc:d7:4e
- inet addr:10.0.0.2 Bcast:10.255.255.255 Mask:255.0.0.0
- inet6 addr: fe80::60c5:33ff:febc:d74e/64 Scope:Link
-
-::
-
- mininet> h22 ifconfig
- h22-eth0 Link encap:Ethernet HWaddr de:05:40:c4:96:76
- inet addr:10.0.0.4 Bcast:10.255.255.255 Mask:255.0.0.0
- inet6 addr: fe80::dc05:40ff:fec4:9676/64 Scope:Link
-
-- MAC Mapping will not be activated just by configuring it, a two end
- communication needs to be established to activate Mac Mapping.
-
-- Ping host h22 from host h12 in mininet, the ping will not happen
- between the hosts as only one way activation is enabled.
-
-::
-
- mininet> h12 ping h22
- PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
- From 10.0.0.2 icmp_seq=1 Destination Host Unreachable
- From 10.0.0.2 icmp_seq=2 Destination Host Unreachable
-
-- Ping host h12 from host h22 in mininet, now the ping communication
- will take place as the two end communication is enabled.
-
-::
-
- mininet> h22 ping h12
- PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
- 64 bytes from 10.0.0.2: icmp_req=1 ttl=64 time=91.8 ms
- 64 bytes from 10.0.0.2: icmp_req=2 ttl=64 time=0.510 ms
-
-- After two end communication enabled, now host h12 can ping host h22
-
-::
-
- mininet> h12 ping h22
- PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
- 64 bytes from 10.0.0.4: icmp_req=1 ttl=64 time=0.780 ms
- 64 bytes from 10.0.0.4: icmp_req=2 ttl=64 time=0.079 ms
-
-Verification
-^^^^^^^^^^^^
-
-- To view the configured Mac Map of allowed host execute the following
- command.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns/vtn/Tenant1/vbridge/vBridge1/mac-map
-
-::
-
- {
- "mac-map": {
- "mac-map-status": {
- "mapped-host": [
- {
- "mac-address": "c6:44:22:ba:3e:72",
- "vlan-id": 0,
- "port-id": "openflow:1:2"
- },
- {
- "mac-address": "f6:e0:43:b6:3a:b7",
- "vlan-id": 0,
- "port-id": "openflow:2:2"
- }
- ]
- },
- "mac-map-config": {
- "allowed-hosts": {
- "vlan-host-desc-list": [
- {
- "host": "c6:44:22:ba:3e:72@0"
- },
- {
- "host": "f6:e0:43:b6:3a:b7@0"
- }
- ]
- }
- }
- }
- }
-
-.. note::
-
- When Deny is configured a broadcast message is sent to all the hosts
- connected to the vBridge, so a two end communication need not be
- establihed like allow, the hosts can communicate directly without
- any two way communication enabled.
-
-1. To Deny host h23 communication from hosts connected on vBridge1, the
- following configuration can be applied.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-mac-map:set-mac-map -d '{"input":{"operation": "SET", "denied-hosts": ["0a:d3:ea:3d:8f:a5@0"],"tenant-name": "Tenant1","bridge-name": "vBridge1"}}'
-
-Cleaning Up
-^^^^^^^^^^^
-
-- You can delete the virtual tenant Tenant1 by executing `the
- remove-vtn
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn.html#remove-vtn>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:remove-vtn -d '{"input":{"tenant-name":"Tenant1"}}'
-
-How To Configure Flowfilters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-- This page explains how to provision flowfilter using VTN Manager.
- This page targets Boron release, so the procedure described here
- does not work in other releases.
-
-- The flow-filter function discards, permits, or redirects packets of
- the traffic within a VTN, according to specified flow conditions. The
- table below lists the actions to be applied when a packet matches the
- condition:
-
-+-----------------------+----------------------------------------------------+
-| Action | Function |
-+=======================+====================================================+
-| Pass | | Permits the packet to pass along the determined |
-| | path. |
-| | | As options, packet transfer priority (set |
-| | priority) and DSCP change (set ip-dscp) is |
-| | specified. |
-+-----------------------+----------------------------------------------------+
-| Drop | Discards the packet. |
-+-----------------------+----------------------------------------------------+
-| Redirect | | Redirects the packet to a desired virtual |
-| | interface. |
-| | | As an option, it is possible to change the MAC |
-| | address when the packet is transferred. |
-+-----------------------+----------------------------------------------------+
-
-.. figure:: ./images/vtn/flow_filter_example.png
- :alt: Flow Filter Example
-
- Flow Filter Example
-
-- Following steps explain flow-filter function:
-
- - when a packet is transferred to an interface within a virtual
- network, the flow-filter function evaluates whether the
- transferred packet matches the condition specifed in the
- flow-list.
-
- - If the packet matches the condition, the flow-filter applies the
- flow-list matching action specified in the flow-filter.
-
-Requirements
-^^^^^^^^^^^^
-
-To apply the packet filter, configure the following:
-
-- Create a flow condition.
-
-- Specify where to apply the flow-filter, for example VTN, vBridge, or
- interface of vBridge.
-
-To provision OpenFlow switches, this page uses Mininet. Mininet details
-and set-up can be referred at the below page:
-https://wiki.opendaylight.org/view/OpenDaylight_Controller:Installation#Using_Mininet
-
-Start Mininet, and create three switches (s1, s2, and s3) and four hosts
-(h1, h2, h3 and h4) in it.
-
-::
-
- sudo mn --controller=remote,ip=192.168.0.100 --topo tree,2
-
-.. note::
-
- Replace "192.168.0.100" with the IP address of OpenDaylight
- controller based on your environment.
-
-You can check the topology that you have created by executing "net"
-command in the Mininet console.
-
-::
-
- mininet> net
- h1 h1-eth0:s2-eth1
- h2 h2-eth0:s2-eth2
- h3 h3-eth0:s3-eth1
- h4 h4-eth0:s3-eth2
- s1 lo: s1-eth1:s2-eth3 s1-eth2:s3-eth3
- s2 lo: s2-eth1:h1-eth0 s2-eth2:h2-eth0 s2-eth3:s1-eth1
- s3 lo: s3-eth1:h3-eth0 s3-eth2:h4-eth0 s3-eth3:s1-eth2
-
-In this guide, you will provision flowfilters to establish communication
-between h1 and h3.
-
-Configuration
-^^^^^^^^^^^^^
-
-To provision the virtual L2 network for the two hosts (h1 and h3),
-execute REST API provided by VTN Manager as follows. It uses curl
-command to call the REST API.
-
-- Create a virtual tenant named vtn1 by executing `the update-vtn
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn.html#update-vtn>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:update-vtn -d '{"input":{"tenant-name":"vtn1"}}'
-
-- Create a virtual bridge named vbr1 in the tenant vtn1 by executing
- `the update-vbridge
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vbridge.html#update-vbridge>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1"}}'
-
-- Create two interfaces into the virtual bridge by executing `the
- update-vinterface
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vinterface.html#update-vinterface>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1"}}'
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if2"}}'
-
-- Configure two mappings on the interfaces by executing `the
- set-port-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-port-map.html#set-port-map>`__.
-
- - The interface if1 of the virtual bridge will be mapped to the port
- "s2-eth1" of the switch "openflow:2" of the Mininet.
-
- - The h1 is connected to the port "s2-eth1".
-
- - The interface if2 of the virtual bridge will be mapped to the port
- "s3-eth1" of the switch "openflow:3" of the Mininet.
-
- - The h3 is connected to the port "s3-eth1".
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if1", "node":"openflow:2", "port-name":"s2-eth1"}}'
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if2", "node":"openflow:3", "port-name":"s3-eth1"}}'
-
-- Create flowcondition named cond\_1 by executing `the
- set-flow-condition
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-condition.html#set-flow-condition>`__.
-
- - For option source and destination-network, get inet address of
- host h1 and h3 from mininet.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:set-flow-condition -d '{"input":{"name":"cond_1", "vtn-flow-match":[{"vtn-ether-match":{},"vtn-inet-match":{"source-network":"10.0.0.1/32","protocol":1,"destination-network":"10.0.0.3/32"},"index":"1"}]}}'
-
-- Flowfilter can be applied either in VTN, VBR or VBR Interfaces. Here
- in this page we provision flowfilter with VBR Interface and
- demonstrate with action type drop and then pass.
-
-- Flow filter demonstration with DROP action-type. Create Flowfilter in
- VBR Interface if1 by executing `the set-flow-filter
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-filter.html#set-flow-filter>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input": {"tenant-name": "vtn1", "bridge-name": "vbr1","interface-name":"if1","vtn-flow-filter":[{"condition":"cond_1","vtn-drop-filter":{},"vtn-flow-action":[{"order": "1","vtn-set-inet-src-action":{"ipv4-address":"10.0.0.1/32"}},{"order": "2","vtn-set-inet-dst-action":{"ipv4-address":"10.0.0.3/32"}}],"index": "1"}]}}'
-
-Verification of the drop filter
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Please execute ping from h1 to h3. As we have applied the action type
- "drop" , ping should fail with no packet flows between hosts h1 and
- h3 as below,
-
-::
-
- mininet> h1 ping h3
-
-Configuration for pass filter
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Update the flow filter to pass the packets by executing `the
- set-flow-filter
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-filter.html#set-flow-filter>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input": {"tenant-name": "vtn1", "bridge-name": "vbr1","interface-name":"if1","vtn-flow-filter":[{"condition":"cond_1","vtn-pass-filter":{},"vtn-flow-action":[{"order": "1","vtn-set-inet-src-action":{"ipv4-address":"10.0.0.1/32"}},{"order": "2","vtn-set-inet-dst-action":{"ipv4-address":"10.0.0.3/32"}}],"index": "1"}]}}'
-
-Verification For Packets Success
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- As we have applied action type PASS now ping should happen between
- hosts h1 and h3.
-
-::
-
- mininet> h1 ping h3
- PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
- 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.984 ms
- 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.110 ms
- 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.098 ms
-
-- You can also verify the configurations by executing the following
- REST API. It shows all configuration in VTN Manager.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns/vtn/vtn1
-
-::
-
- {
- "vtn": [
- {
- "name": "vtn1",
- "vtenant-config": {
- "hard-timeout": 0,
- "idle-timeout": 300,
- "description": "creating vtn"
- },
- "vbridge": [
- {
- "name": "vbr1",
- "vbridge-config": {
- "age-interval": 600,
- "description": "creating vBridge1"
- },
- "bridge-status": {
- "state": "UP",
- "path-faults": 0
- },
- "vinterface": [
- {
- "name": "if1",
- "vinterface-status": {
- "mapped-port": "openflow:2:1",
- "state": "UP",
- "entity-state": "UP"
- },
- "port-map-config": {
- "vlan-id": 0,
- "node": "openflow:2",
- "port-name": "s2-eth1"
- },
- "vinterface-config": {
- "description": "Creating if1 interface",
- "enabled": true
- },
- "vinterface-input-filter": {
- "vtn-flow-filter": [
- {
- "index": 1,
- "condition": "cond_1",
- "vtn-flow-action": [
- {
- "order": 1,
- "vtn-set-inet-src-action": {
- "ipv4-address": "10.0.0.1/32"
- }
- },
- {
- "order": 2,
- "vtn-set-inet-dst-action": {
- "ipv4-address": "10.0.0.3/32"
- }
- }
- ],
- "vtn-pass-filter": {}
- },
- {
- "index": 10,
- "condition": "cond_1",
- "vtn-drop-filter": {}
- }
- ]
- }
- },
- {
- "name": "if2",
- "vinterface-status": {
- "mapped-port": "openflow:3:1",
- "state": "UP",
- "entity-state": "UP"
- },
- "port-map-config": {
- "vlan-id": 0,
- "node": "openflow:3",
- "port-name": "s3-eth1"
- },
- "vinterface-config": {
- "description": "Creating if2 interface",
- "enabled": true
- }
- }
- ]
- }
- ]
- }
- ]
- }
-
-Cleaning Up
-^^^^^^^^^^^
-
-- To clean up both VTN and flowcondition.
-
-- You can delete the virtual tenant vtn1 by executing `the remove-vtn
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn.html#remove-vtn>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:remove-vtn -d '{"input":{"tenant-name":"vtn1"}}'
-
-- You can delete the flowcondition cond\_1 by executing `the
- remove-flow-condition
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-condition.html#remove-flow-condition>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:remove-flow-condition -d '{"input":{"name":"cond_1"}}'
-
-How to use VTN to change the path of the packet flow
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-- This page explains how to create specific VTN Pathmap using VTN
- Manager. This page targets Boron release, so the procedure
- described here does not work in other releases.
-
-.. figure:: ./images/vtn/Pathmap.png
- :alt: Pathmap
-
- Pathmap
-
-Requirement
-^^^^^^^^^^^
-
-- Save the mininet script given below as pathmap\_test.py and run the
- mininet script in the mininet environment where Mininet is installed.
-
-- Create topology using the below mininet script:
-
-::
-
- from mininet.topo import Topo
- class MyTopo( Topo ):
- "Simple topology example."
- def __init__( self ):
- "Create custom topo."
- # Initialize topology
- Topo.__init__( self )
- # Add hosts and switches
- leftHost = self.addHost( 'h1' )
- rightHost = self.addHost( 'h2' )
- leftSwitch = self.addSwitch( 's1' )
- middleSwitch = self.addSwitch( 's2' )
- middleSwitch2 = self.addSwitch( 's4' )
- rightSwitch = self.addSwitch( 's3' )
- # Add links
- self.addLink( leftHost, leftSwitch )
- self.addLink( leftSwitch, middleSwitch )
- self.addLink( leftSwitch, middleSwitch2 )
- self.addLink( middleSwitch, rightSwitch )
- self.addLink( middleSwitch2, rightSwitch )
- self.addLink( rightSwitch, rightHost )
- topos = { 'mytopo': ( lambda: MyTopo() ) }
-
-- After creating new file with the above script start the mininet as
- below,
-
-::
-
- sudo mn --controller=remote,ip=10.106.138.124 --custom pathmap_test.py --topo mytopo
-
-.. note::
-
- Replace "10.106.138.124" with the IP address of OpenDaylight
- controller based on your environment.
-
-::
-
- mininet> net
- h1 h1-eth0:s1-eth1
- h2 h2-eth0:s3-eth3
- s1 lo: s1-eth1:h1-eth0 s1-eth2:s2-eth1 s1-eth3:s4-eth1
- s2 lo: s2-eth1:s1-eth2 s2-eth2:s3-eth1
- s3 lo: s3-eth1:s2-eth2 s3-eth2:s4-eth2 s3-eth3:h2-eth0
- s4 lo: s4-eth1:s1-eth3 s4-eth2:s3-eth2
- c0
-
-- Generate traffic by pinging between host h1 and host h2 before
- creating the portmaps respectively.
-
-::
-
- mininet> h1 ping h2
- PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
- From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
- From 10.0.0.1 icmp_seq=2 Destination Host Unreachable
- From 10.0.0.1 icmp_seq=3 Destination Host Unreachable
- From 10.0.0.1 icmp_seq=4 Destination Host Unreachable
-
-Configuration
-^^^^^^^^^^^^^
-
-- To change the path of the packet flow, execute REST API provided by
- VTN Manager as follows. It uses curl command to call the REST API.
-
-- Create a virtual tenant named vtn1 by executing `the update-vtn
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn.html#update-vtn>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:update-vtn -d '{"input":{"tenant-name":"vtn1"}}'
-
-- Create a virtual bridge named vbr1 in the tenant vtn1 by executing
- `the update-vbridge
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vbridge.html#update-vbridge>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1"}}'
-
-- Create two interfaces into the virtual bridge by executing `the
- update-vinterface
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-vinterface.html#update-vinterface>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1"}}'
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if2"}}'
-
-- Configure two mappings on the interfaces by executing `the
- set-port-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-port-map.html#set-port-map>`__.
-
- - The interface if1 of the virtual bridge will be mapped to the port
- "s2-eth1" of the switch "openflow:1" of the Mininet.
-
- - The h1 is connected to the port "s1-eth1".
-
- - The interface if2 of the virtual bridge will be mapped to the port
- "s3-eth1" of the switch "openflow:3" of the Mininet.
-
- - The h3 is connected to the port "s3-eth3".
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if1", "node":"openflow:1", "port-name":"s1-eth1"}}'
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if2", "node":"openflow:3", "port-name":"s3-eth3"}}'
-
-- Genarate traffic by pinging between host h1 and host h2 after
- creating the portmaps respectively.
-
-::
-
- mininet> h1 ping h2
- PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
- 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.861 ms
- 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.101 ms
- 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.101 ms
-
-- Get the Dataflows information by executing `the get-data-flow
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow.html#get-data-flow>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow:get-data-flow -d '{"input":{"tenant-name":"vtn1","mode":"DETAIL","node":"openflow:1","data-flow-port":{"port-id":1,"port-name":"s1-eth1"}}}'
-
-- Create flowcondition named cond\_1 by executing `the
- set-flow-condition
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-condition.html#set-flow-condition>`__.
-
- - For option source and destination-network, get inet address of
- host h1 or host h2 from mininet
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:set-flow-condition -d '{"input":{"operation":"SET","present":"false","name":"cond_1", "vtn-flow-match":[{"vtn-ether-match":{},"vtn-inet-match":{"source-network":"10.0.0.1/32","protocol":1,"destination-network":"10.0.0.2/32"},"index":"1"}]}}'
-
-- Create pathmap with flowcondition cond\_1 by executing `the
- set-path-map
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-path-map.html#set-path-map>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-path-map:set-path-map -d '{"input":{"tenant-name":"vtn1","path-map-list":[{"condition":"cond_1","policy":"1","index": "1","idle-timeout":"300","hard-timeout":"0"}]}}'
-
-- Create pathpolicy by executing `the set-path-policy
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-path-policy.html#set-path-policy>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-path-policy:set-path-policy -d '{"input":{"operation":"SET","id": "1","default-cost": "10000","vtn-path-cost": [{"port-desc":"openflow:1,3,s1-eth3","cost":"1000"},{"port-desc":"openflow:4,2,s4-eth2","cost":"1000"},{"port-desc":"openflow:3,3,s3-eth3","cost":"100000"}]}}'
-
-Verification
-^^^^^^^^^^^^
-
-- Before applying Path policy get node information by executing get
- dataflow command.
-
-::
-
- "data-flow-info": [
- {
- "physical-route": [
- {
- "physical-ingress-port": {
- "port-name": "s3-eth3",
- "port-id": "3"
- },
- "physical-egress-port": {
- "port-name": "s3-eth1",
- "port-id": "1"
- },
- "node": "openflow:3",
- "order": 0
- },
- {
- "physical-ingress-port": {
- "port-name": "s2-eth2",
- "port-id": "2"
- },
- "physical-egress-port": {
- "port-name": "s2-eth1",
- "port-id": "1"
- },
- "node": "openflow:2",
- "order": 1
- },
- {
- "physical-ingress-port": {
- "port-name": "s1-eth2",
- "port-id": "2"
- },
- "physical-egress-port": {
- "port-name": "s1-eth1",
- "port-id": "1"
- },
- "node": "openflow:1",
- "order": 2
- }
- ],
- "data-egress-node": {
- "interface-name": "if1",
- "bridge-name": "vbr1",
- "tenant-name": "vtn1"
- },
- "data-egress-port": {
- "node": "openflow:1",
- "port-name": "s1-eth1",
- "port-id": "1"
- },
- "data-ingress-node": {
- "interface-name": "if2",
- "bridge-name": "vbr1",
- "tenant-name": "vtn1"
- },
- "data-ingress-port": {
- "node": "openflow:3",
- "port-name": "s3-eth3",
- "port-id": "3"
- },
- "flow-id": 32
- },
- }
-
-- After applying Path policy get node information by executing get
- dataflow command.
-
-::
-
- "data-flow-info": [
- {
- "physical-route": [
- {
- "physical-ingress-port": {
- "port-name": "s1-eth1",
- "port-id": "1"
- },
- "physical-egress-port": {
- "port-name": "s1-eth3",
- "port-id": "3"
- },
- "node": "openflow:1",
- "order": 0
- },
- {
- "physical-ingress-port": {
- "port-name": "s4-eth1",
- "port-id": "1"
- },
- "physical-egress-port": {
- "port-name": "s4-eth2",
- "port-id": "2"
- },
- "node": "openflow:4",
- "order": 1
- },
- {
- "physical-ingress-port": {
- "port-name": "s3-eth2",
- "port-id": "2"
- },
- "physical-egress-port": {
- "port-name": "s3-eth3",
- "port-id": "3"
- },
- "node": "openflow:3",
- "order": 2
- }
- ],
- "data-egress-node": {
- "interface-name": "if2",
- "bridge-name": "vbr1",
- "tenant-name": "vtn1"
- },
- "data-egress-port": {
- "node": "openflow:3",
- "port-name": "s3-eth3",
- "port-id": "3"
- },
- "data-ingress-node": {
- "interface-name": "if1",
- "bridge-name": "vbr1",
- "tenant-name": "vtn1"
- },
- "data-ingress-port": {
- "node": "openflow:1",
- "port-name": "s1-eth1",
- "port-id": "1"
- },
- }
-
-Cleaning Up
-^^^^^^^^^^^
-
-- To clean up both VTN and flowcondition.
-
-- You can delete the virtual tenant vtn1 by executing `the remove-vtn
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn.html#remove-vtn>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:remove-vtn -d '{"input":{"tenant-name":"vtn1"}}'
-
-- You can delete the flowcondition cond\_1 by executing `the
- remove-flow-condition
- RPC <https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/models/vtn-flow-condition.html#remove-flow-condition>`__.
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:remove-flow-condition -d '{"input":{"name":"cond_1"}}'
-
-VTN Coordinator Usage Examples
-------------------------------
-
-How to configure L2 Network with Single Controller
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-This example provides the procedure to demonstrate configuration of VTN
-Coordinator with L2 network using VTN Virtualization(single controller).
-Here is the Example for vBridge Interface Mapping with Single Controller
-using mininet. mininet details and set-up can be referred at below URL:
-https://wiki.opendaylight.org/view/OpenDaylight_Controller:Installation#Using_Mininet
-
-.. figure:: ./images/vtn/vtn-single-controller-topology-example.png
- :alt: EXAMPLE DEMONSTRATING SINGLE CONTROLLER
-
- EXAMPLE DEMONSTRATING SINGLE CONTROLLER
-
-Requirements
-^^^^^^^^^^^^
-
-- Configure mininet and create a topology:
-
-::
-
- mininet@mininet-vm:~$ sudo mn --controller=remote,ip=<controller-ip> --topo tree,2
-
-- mininet> net
-
-::
-
- s1 lo: s1-eth1:h1-eth0 s1-eth2:s2-eth1
- s2 lo: s2-eth1:s1-eth2 s2-eth2:h2-eth0
- h1 h1-eth0:s1-eth1
- h2 h2-eth0:s2-eth2
-
-Configuration
-^^^^^^^^^^^^^
-
-- Create a Controller named controllerone and mention its ip-address in
- the below create-controller command.
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"controller": {"controller_id": "controllerone", "ipaddr":"10.0.0.2", "type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8083/vtn-webapi/controllers.json
-
-- Create a VTN named vtn1 by executing the create-vtn command
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vtn" : {"vtn_name":"vtn1","description":"test VTN" }}' http://127.0.0.1:8083/vtn-webapi/vtns.json
-
-- Create a vBridge named vBridge1 in the vtn1 by executing the
- create-vbr command.
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vbridge" : {"vbr_name":"vBridge1","controller_id":"controllerone","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges.json
-
-- Create two Interfaces named if1 and if2 into the vBridge1
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if1","description": "if_desc1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces.json
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if2","description": "if_desc2"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces.json
-
-- Get the list of logical ports configured
-
-::
-
- Curl --user admin:adminpass -H 'content-type: application/json' -X GET http://127.0.0.1:8083/vtn-webapi/controllers/controllerone/domains/\(DEFAULT\)/logical_ports.json
-
-- Configure two mappings on each of the interfaces by executing the
- below command.
-
-The interface if1 of the virtual bridge will be mapped to the port
-"s2-eth1" of the switch "openflow:2" of the Mininet. The h1 is connected
-to the port "s2-eth1".
-
-The interface if2 of the virtual bridge will be mapped to the port
-"s3-eth1" of the switch "openflow:3" of the Mininet. The h3 is connected
-to the port "s3-eth1".
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:03-s3-eth1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces/if1/portmap.json
- curl --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:02-s2-eth1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces/if2/portmap.json
-
-Verification
-^^^^^^^^^^^^
-
-Please verify whether the Host1 and Host3 are pinging.
-
-- Send packets from Host1 to Host3
-
-::
-
- mininet> h1 ping h3
- PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
- 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.780 ms
- 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.079 ms
-
-How to configure L2 Network with Multiple Controllers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- This example provides the procedure to demonstrate configuration of
- VTN Coordinator with L2 network using VTN Virtualization Here is the
- Example for vBridge Interface Mapping with Multi-controller using
- mininet.
-
-.. figure:: ./images/vtn/MutiController_Example_diagram.png
- :alt: EXAMPLE DEMONSTRATING MULTIPLE CONTROLLERS
-
- EXAMPLE DEMONSTRATING MULTIPLE CONTROLLERS
-
-Requirements
-^^^^^^^^^^^^
-
-- Configure multiple controllers using the mininet script given below:
- https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:Scripts:Mininet#Network_with_multiple_switches_and_OpenFlow_controllers
-
-Configuration
-^^^^^^^^^^^^^
-
-- Create a VTN named vtn3 by executing the create-vtn command
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vtn" : {"vtn_name":"vtn3"}}' http://127.0.0.1:8083/vtn-webapi/vtns.json
-
-- Create two Controllers named odc1 and odc2 with its ip-address in the
- below create-controller command.
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"controller": {"controller_id": "odc1", "ipaddr":"10.100.9.52", "type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8083/vtn-webapi/controllers.json
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"controller": {"controller_id": "odc2", "ipaddr":"10.100.9.61", "type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8083/vtn-webapi/controllers.json
-
-- Create two vBridges in the VTN like, vBridge1 in Controller1 and
- vBridge2 in Controller2
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vbridge" : {"vbr_name":"vbr1","controller_id":"odc1","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn3/vbridges.json
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vbridge" : {"vbr_name":"vbr2","controller_id":"odc2","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn3/vbridges.json
-
-- Create two Interfaces if1, if2 for the two vBridges vbr1 and vbr2.
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn3/vbridges/vbr1/interfaces.json
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if2"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn3/vbridges/vbr1/interfaces.json
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn3/vbridges/vbr2/interfaces.json
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if2"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn3/vbridges/vbr2/interfaces.json
-
-- Get the list of logical ports configured
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X GET http://127.0.0.1:8083/vtn-webapi/controllers/odc1/domains/\(DEFAULT\)/logical_ports/detail.json
-
-- Create boundary and vLink for the two controllers
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"boundary": {"boundary_id": "b1", "link": {"controller1_id": "odc1", "domain1_id": "(DEFAULT)", "logical_port1_id": "PP-OF:00:00:00:00:00:00:00:01-s1-eth3", "controller2_id": "odc2", "domain2_id": "(DEFAULT)", "logical_port2_id": "PP-OF:00:00:00:00:00:00:00:04-s4-eth3"}}}' http://127.0.0.1:8083/vtn-webapi/boundaries.json
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vlink": {"vlk_name": "vlink1" , "vnode1_name": "vbr1", "if1_name":"if2", "vnode2_name": "vbr2", "if2_name": "if2", "boundary_map": {"boundary_id":"b1","vlan_id": "50"}}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn3/vlinks.json
-
-- Configure two mappings on each of the interfaces by executing the
- below command.
-
-The interface if1 of the vbr1 will be mapped to the port "s2-eth2" of
-the switch "openflow:2" of the Mininet. The h2 is connected to the port
-"s2-eth2".
-
-The interface if2 of the vbr2 will be mapped to the port "s5-eth2" of
-the switch "openflow:5" of the Mininet. The h6 is connected to the port
-"s5-eth2".
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:02-s2-eth2"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn3/vbridges/vbr1/interfaces/if1/portmap.json
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:05-s5-eth2"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn3/vbridges/vbr2/interfaces/if1/portmap.json
-
-Verification
-^^^^^^^^^^^^
-
-Please verify whether Host h2 and Host h6 are pinging.
-
-- Send packets from h2 to h6
-
-::
-
- mininet> h2 ping h6
-
-::
-
- PING 10.0.0.6 (10.0.0.3) 56(84) bytes of data.
- 64 bytes from 10.0.0.6: icmp_req=1 ttl=64 time=0.780 ms
- 64 bytes from 10.0.0.6: icmp_req=2 ttl=64 time=0.079 ms
-
-How To Test Vlan-Map In Mininet Environment
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-This example explains how to test vlan-map in a multi host scenario.
-
-.. figure:: ./images/vtn/vlanmap_using_mininet.png
- :alt: Example that demonstrates vlanmap testing in Mininet Environment
-
- Example that demonstrates vlanmap testing in Mininet Environment
-
-Requirements
-^^^^^^^^^^^^
-
-- Save the mininet script given below as vlan\_vtn\_test.py and run the
- mininet script in the mininet environment where Mininet is installed.
-
-Mininet Script
-^^^^^^^^^^^^^^
-
-https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Scripts:Mininet#Network_with_hosts_in_different_vlan
-
-- Run the mininet script
-
-::
-
- sudo mn --controller=remote,ip=192.168.64.13 --custom vlan_vtn_test.py --topo mytopo
-
-Configuration
-^^^^^^^^^^^^^
-
-Please follow the below steps to test a vlan map using mininet:
-
-- Create a Controller named controllerone and mention its ip-address in
- the below create-controller command.
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"controller": {"controller_id": "controllerone", "ipaddr":"10.0.0.2", "type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8083/vtn-webapi/controllers
-
-- Create a VTN named vtn1 by executing the create-vtn command
-
-::
-
- curl -X POST -H 'content-type: application/json' -H 'username: admin' -H 'password: adminpass' -d '{"vtn" : {"vtn_name":"vtn1","description":"test VTN" }}' http://127.0.0.1:8083/vtn-webapi/vtns.json
-
-- Create a vBridge named vBridge1 in the vtn1 by executing the
- create-vbr command.
-
-::
-
- curl -X POST -H 'content-type: application/json' -H 'username: admin' -H 'password: adminpass' -d '{"vbridge" : {"vbr_name":"vBridge1","controller_id":"controllerone","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges.json
-
-- Create a vlan map with vlanid 200 for vBridge vBridge1
-
-::
-
- curl -X POST -H 'content-type: application/json' -H 'username: admin' -H 'password: adminpass' -d '{"vlanmap" : {"vlan_id": 200 }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/vlanmaps.json
-
-- Create a vBridge named vBridge2 in the vtn1 by executing the
- create-vbr command.
-
-::
-
- curl -X POST -H 'content-type: application/json' -H 'username: admin' -H 'password: adminpass' -d '{"vbridge" : {"vbr_name":"vBridge2","controller_id":"controllerone","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges.json
-
-- Create a vlan map with vlanid 300 for vBridge vBridge2
-
-::
-
- curl -X POST -H 'content-type: application/json' -H 'username: admin' -H 'password: adminpass' -d '{"vlanmap" : {"vlan_id": 300 }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge2/vlanmaps.json
-
-Verification
-^^^^^^^^^^^^
-
-Ping all in mininet environment to view the host reachability.
-
-::
-
- mininet> pingall
- Ping: testing ping reachability
- h1 -> X h3 X h5 X
- h2 -> X X h4 X h6
- h3 -> h1 X X h5 X
- h4 -> X h2 X X h6
- h5 -> h1 X h3 X X
- h6 -> X h2 X h4 X
-
-How To View Specific VTN Station Information.
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This example demonstrates on how to view a specific VTN Station
-information.
-
-.. figure:: ./images/vtn/vtn_stations.png
- :alt: EXAMPLE DEMONSTRATING VTN STATIONS
-
- EXAMPLE DEMONSTRATING VTN STATIONS
-
-Requirement
-^^^^^^^^^^^
-
-- Configure mininet and create a topology:
-
-::
-
- $ sudo mn --custom /home/mininet/mininet/custom/topo-2sw-2host.py --controller=remote,ip=10.100.9.61 --topo mytopo
- mininet> net
-
- s1 lo: s1-eth1:h1-eth0 s1-eth2:s2-eth1
- s2 lo: s2-eth1:s1-eth2 s2-eth2:h2-eth0
- h1 h1-eth0:s1-eth1
- h2 h2-eth0:s2-eth2
-
-- Generate traffic by pinging between hosts h1 and h2 after configuring
- the portmaps respectively
-
-::
-
- mininet> h1 ping h2
- PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
- 64 bytes from 10.0.0.2: icmp_req=1 ttl=64 time=16.7 ms
- 64 bytes from 10.0.0.2: icmp_req=2 ttl=64 time=13.2 ms
-
-Configuration
-^^^^^^^^^^^^^
-
-- Create a Controller named controllerone and mention its ip-address in
- the below create-controller command
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"controller": {"controller_id": "controllerone", "ipaddr":"10.100.9.61", "type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8083/vtn-webapi/controllers.json
-
-- Create a VTN named vtn1 by executing the create-vtn command
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vtn" : {"vtn_name":"vtn1","description":"test VTN" }}' http://127.0.0.1:8083/vtn-webapi/vtns.json
-
-- Create a vBridge named vBridge1 in the vtn1 by executing the
- create-vbr command.
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vbridge" : {"vbr_name":"vBridge1","controller_id":"controllerone","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges.json
-
-- Create two Interfaces named if1 and if2 into the vBridge1
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if1","description": "if_desc1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces.json
- curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if2","description": "if_desc2"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces.json
-
-- Configure two mappings on each of the interfaces by executing the
- below command.
-
-The interface if1 of the virtual bridge will be mapped to the port
-"s1-eth1" of the switch "openflow:1" of the Mininet. The h1 is connected
-to the port "s1-eth1".
-
-The interface if2 of the virtual bridge will be mapped to the port
-"s1-eth2" of the switch "openflow:1" of the Mininet. The h2 is connected
-to the port "s1-eth2".
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:01-s1-eth1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces/if1/portmap.json
- curl -v --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:02-s2-eth2"}}' http://17.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces/if2/portmap.json
-
-- Get the VTN stations information
-
-::
-
- curl -X GET -H 'content-type: application/json' -H 'username: admin' -H 'password: adminpass' "http://127.0.0.1:8083/vtn-webapi/vtnstations?controller_id=controllerone&vtn_name=vtn1"
-
-Verification
-^^^^^^^^^^^^
-
-::
-
- curl -X GET -H 'content-type: application/json' -H 'username: admin' -H 'password: adminpass' "http://127.0.0.1:8083/vtn-webapi/vtnstations?controller_id=controllerone&vtn_name=vtn1"
- {
- "vtnstations": [
- {
- "domain_id": "(DEFAULT)",
- "interface": {},
- "ipaddrs": [
- "10.0.0.2"
- ],
- "macaddr": "b2c3.06b8.2dac",
- "no_vlan_id": "true",
- "port_name": "s2-eth2",
- "station_id": "178195618445172",
- "switch_id": "00:00:00:00:00:00:00:02",
- "vnode_name": "vBridge1",
- "vnode_type": "vbridge",
- "vtn_name": "vtn1"
- },
- {
- "domain_id": "(DEFAULT)",
- "interface": {},
- "ipaddrs": [
- "10.0.0.1"
- ],
- "macaddr": "ce82.1b08.90cf",
- "no_vlan_id": "true",
- "port_name": "s1-eth1",
- "station_id": "206130278144207",
- "switch_id": "00:00:00:00:00:00:00:01",
- "vnode_name": "vBridge1",
- "vnode_type": "vbridge",
- "vtn_name": "vtn1"
- }
- ]
- }
-
-How To View Dataflows in VTN
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This example demonstrates on how to view a specific VTN Dataflow
-information.
-
-Configuration
-^^^^^^^^^^^^^
-
-The same Configuration as Vlan Mapping
-Example(\ https://wiki.opendaylight.org/view/VTN:Coordinator:Beryllium:HowTos:How_To_test_vlanmap_using_mininet)
-
-Verification
-^^^^^^^^^^^^
-
-Get the VTN Dataflows information
-
-::
-
- curl -X GET -H 'content-type: application/json' --user 'admin:adminpass' "http://127.0.0.1:8083/vtn-webapi/dataflows?controller_id=controllerone&srcmacaddr=924c.e4a3.a743&vlan_id=300&switch_id=openflow:2&port_name=s2-eth1"
-
-::
-
- {
- "dataflows": [
- {
- "controller_dataflows": [
- {
- "controller_id": "controllerone",
- "controller_type": "odc",
- "egress_domain_id": "(DEFAULT)",
- "egress_port_name": "s3-eth3",
- "egress_station_id": "3",
- "egress_switch_id": "00:00:00:00:00:00:00:03",
- "flow_id": "29",
- "ingress_domain_id": "(DEFAULT)",
- "ingress_port_name": "s2-eth2",
- "ingress_station_id": "2",
- "ingress_switch_id": "00:00:00:00:00:00:00:02",
- "match": {
- "macdstaddr": [
- "4298.0959.0e0b"
- ],
- "macsrcaddr": [
- "924c.e4a3.a743"
- ],
- "vlan_id": [
- "300"
- ]
- },
- "pathinfos": [
- {
- "in_port_name": "s2-eth2",
- "out_port_name": "s2-eth1",
- "switch_id": "00:00:00:00:00:00:00:02"
- },
- {
- "in_port_name": "s1-eth2",
- "out_port_name": "s1-eth3",
- "switch_id": "00:00:00:00:00:00:00:01"
- },
- {
- "in_port_name": "s3-eth1",
- "out_port_name": "s3-eth3",
- "switch_id": "00:00:00:00:00:00:00:03"
- }
- ]
- }
- ],
- "reason": "success"
- }
- ]
- }
-
-How To Configure Flow Filters Using VTN
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-The flow-filter function discards, permits, or redirects packets of the
-traffic within a VTN, according to specified flow conditions The table
-below lists the actions to be applied when a packet matches the
-condition:
-
-+--------------------------------------+--------------------------------------+
-| Action | Function |
-+--------------------------------------+--------------------------------------+
-| Pass | Permits the packet to pass. As |
-| | options, packet transfer priority |
-| | (set priority) and DSCP change (se t |
-| | ip-dscp) is specified. |
-+--------------------------------------+--------------------------------------+
-| Drop | Discards the packet. |
-+--------------------------------------+--------------------------------------+
-| Redirect | Redirects the packet to a desired |
-| | virtual interface. As an option, it |
-| | is possible to change the MAC |
-| | address when the packet is |
-| | transferred. |
-+--------------------------------------+--------------------------------------+
-
-.. figure:: ./images/vtn/flow_filter_example.png
- :alt: Flow Filter
-
- Flow Filter
-
-Following steps explain flow-filter function:
-
-- When a packet is transferred to an interface within a virtual
- network, the flow-filter function evaluates whether the transferred
- packet matches the condition specified in the flow-list.
-
-- If the packet matches the condition, the flow-filter applies the
- flow-list matching action specified in the flow-filter.
-
-Requirements
-^^^^^^^^^^^^
-
-To apply the packet filter, configure the following:
-
-- Create a flow-list and flow-listentry.
-
-- Specify where to apply the flow-filter, for example VTN, vBridge, or
- interface of vBridge.
-
-Configure mininet and create a topology:
-
-::
-
- $ mininet@mininet-vm:~$ sudo mn --controller=remote,ip=<controller-ip> --topo tree
-
-Please generate the following topology
-
-::
-
- $ mininet@mininet-vm:~$ sudo mn --controller=remote,ip=<controller-ip> --topo tree,2
- mininet> net
- c0
- s1 lo: s1-eth1:s2-eth3 s1-eth2:s3-eth3
- s2 lo: s2-eth1:h1-eth0 s2-eth2:h2-eth0 s2-eth3:s1-eth1
- s3 lo: s3-eth1:h3-eth0 s3-eth2:h4-eth0 s3-eth3:s1-eth2
- h1 h1-eth0:s2-eth1
- h2 h2-eth0:s2-eth2
- h3 h3-eth0:s3-eth1
- h4 h4-eth0:s3-eth2
-
-Configuration
-^^^^^^^^^^^^^
-
-- Create a Controller named controller1 and mention its ip-address in
- the below create-controller command.
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"controller": {"controller_id": "controller1", "ipaddr":"10.100.9.61", "type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8083/vtn-webapi/controllers
-
-- Create a VTN named vtn\_one by executing the create-vtn command
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vtn" : {"vtn_name":"vtn_one","description":"test VTN" }}' http://127.0.0.1:8083/vtn-webapi/vtns.json
-
-- Create a vBridge named vbr\_two in the vtn1 by executing the
- create-vbr command.
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vbridge" : {"vbr_name":"vbr_one^C"controller_id":"controller1","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges.json
- curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vbridge" :
- {"vbr_name":"vbr_two","controller_id":"controller1","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges.json
-
-- Create two Interfaces named if1 and if2 into the vbr\_two
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if1","description": "if_desc1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces.json
- curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if1","description": "if_desc1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces.json
-
-- Get the list of logical ports configured
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X GET http://127.0.0.1:8083/vtn-webapi/controllers/controllerone/domains/\(DEFAULT\)/logical_ports.json
-
-- Configure two mappings on each of the interfaces by executing the
- below command.
-
-The interface if1 of the virtual bridge will be mapped to the port
-"s2-eth1" of the switch "openflow:2" of the Mininet. The h1 is connected
-to the port "s2-eth1".
-
-The interface if2 of the virtual bridge will be mapped to the port
-"s3-eth1" of the switch "openflow:3" of the Mininet. The h3 is connected
-to the port "s3-eth1".
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:03-s3-eth1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/portmap.json
- curl -v --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:02-s2-eth1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if2/portmap.json
-
-- Create Flowlist
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"flowlist": {"fl_name": "flowlist1", "ip_version":"IP"}}' http://127.0.0.1:8083/vtn-webapi/flowlists.json
-
-- Create Flowlistentry
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"flowlistentry": {"seqnum": "233","macethertype": "0x8000","ipdstaddr": "10.0.0.3","ipdstaddrprefix": "2","ipsrcaddr": "10.0.0.2","ipsrcaddrprefix": "2","ipproto": "17","ipdscp": "55","icmptypenum":"232","icmpcodenum": "232"}}' http://127.0.0.1:8083/vtn-webapi/flowlists/flowlist1/flowlistentries.json
-
-- Create vBridge Interface Flowfilter
-
-::
-
- curl --user admin:adminpass -X POST -H 'content-type: application/json' -d '{"flowfilter" : {"ff_type": "in"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/flowfilters.json
-
-Flow filter demonstration with DROP action-type
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-::
-
- curl --user admin:adminpass -X POST -H 'content-type: application/json' -d '{"flowfilterentry": {"seqnum": "233", "fl_name": "flowlist1", "action_type":"drop", "priority":"3", "dscp":"55" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/flowfilters/in/flowfilterentries.json
-
-Verification
-^^^^^^^^^^^^
-
-As we have applied the action type "drop" , ping should fail.
-
-::
-
- mininet> h1 ping h3
- PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
- From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
- From 10.0.0.1 icmp_seq=2 Destination Host Unreachable
-
-Flow filter demonstration with PASS action-type
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-::
-
- curl --user admin:adminpass -X PUT -H 'content-type: application/json' -d '{"flowfilterentry": {"seqnum": "233", "fl_name": "flowlist1", "action_type":"pass", "priority":"3", "dscp":"55" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/flowfilters/in/flowfilterentries/233.json
-
-Verification
-^^^^^^^^^^^^
-
-::
-
- mininet> h1 ping h3
- PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
- 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.984 ms
- 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.110 ms
- 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.098 ms
-
-How To Use VTN To Make Packets Take Different Paths
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This example demonstrates on how to create a specific VTN Path Map
-information.
-
-.. figure:: ./images/vtn/Pathmap.png
- :alt: PathMap
-
- PathMap
-
-Requirement
-^^^^^^^^^^^
-
-- Save the mininet script given below as pathmap\_test.py and run the
- mininet script in the mininet environment where Mininet is installed.
-
-- Create topology using the below mininet script:
-
-::
-
- from mininet.topo import Topo
- class MyTopo( Topo ):
- "Simple topology example."
- def __init__( self ):
- "Create custom topo."
- # Initialize topology
- Topo.__init__( self )
- # Add hosts and switches
- leftHost = self.addHost( 'h1' )
- rightHost = self.addHost( 'h2' )
- leftSwitch = self.addSwitch( 's1' )
- middleSwitch = self.addSwitch( 's2' )
- middleSwitch2 = self.addSwitch( 's4' )
- rightSwitch = self.addSwitch( 's3' )
- # Add links
- self.addLink( leftHost, leftSwitch )
- self.addLink( leftSwitch, middleSwitch )
- self.addLink( leftSwitch, middleSwitch2 )
- self.addLink( middleSwitch, rightSwitch )
- self.addLink( middleSwitch2, rightSwitch )
- self.addLink( rightSwitch, rightHost )
- topos = { 'mytopo': ( lambda: MyTopo() ) }
-
-::
-
- mininet> net
- c0
- s1 lo: s1-eth1:h1-eth0 s1-eth2:s2-eth1 s1-eth3:s4-eth1
- s2 lo: s2-eth1:s1-eth2 s2-eth2:s3-eth1
- s3 lo: s3-eth1:s2-eth2 s3-eth2:s4-eth2 s3-eth3:h2-eth0
- s4 lo: s4-eth1:s1-eth3 s4-eth2:s3-eth2
- h1 h1-eth0:s1-eth1
- h2 h2-eth0:s3-eth3
-
-- Generate traffic by pinging between hosts h1 and h2 before creating
- the portmaps respectively
-
-::
-
- mininet> h1 ping h2
- PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
- From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
- From 10.0.0.1 icmp_seq=2 Destination Host Unreachable
- From 10.0.0.1 icmp_seq=3 Destination Host Unreachable
- From 10.0.0.1 icmp_seq=4 Destination Host Unreachable
-
-Configuration
-^^^^^^^^^^^^^
-
-- Create a Controller named controller1 and mention its ip-address in
- the below create-controller command.
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"controller": {"controller_id": "odc", "ipaddr":"10.100.9.42", "type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8083/vtn-webapi/controllers.json
-
-- Create a VTN named vtn1 by executing the create-vtn command
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vtn" : {"vtn_name":"vtn1","description":"test VTN" }}' http://127.0.0.1:8083/vtn-webapi/vtns.json
-
-- Create a vBridge named vBridge1 in the vtn1 by executing the
- create-vbr command.
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vbridge" : {"vbr_name":"vBridge1","controller_id":"odc","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges.json
-
-- Create two Interfaces named if1 and if2 into the vBridge1
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if1","description": "if_desc1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces.json
- curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if2","description": "if_desc2"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces.json
-
-- Configure two mappings on each of the interfaces by executing the
- below command.
-
-The interface if1 of the virtual bridge will be mapped to the port
-"s1-eth1" of the switch "openflow:1" of the Mininet. The h1 is connected
-to the port "s1-eth1".
-
-The interface if2 of the virtual bridge will be mapped to the port
-"s3-eth3" of the switch "openflow:3" of the Mininet. The h2 is connected
-to the port "s3-eth3".
-
-::
-
- curl --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:01-s1-eth1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces/if1/portmap.json
- curl --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:03-s3-eth3"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces/if2/portmap.json
-
-- Generate traffic by pinging between hosts h1 and h2 after creating
- the portmaps respectively
-
-::
-
- mininet> h1 ping h2
- PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
- 64 bytes from 10.0.0.2: icmp_req=1 ttl=64 time=36.4 ms
- 64 bytes from 10.0.0.2: icmp_req=2 ttl=64 time=0.880 ms
- 64 bytes from 10.0.0.2: icmp_req=3 ttl=64 time=0.073 ms
- 64 bytes from 10.0.0.2: icmp_req=4 ttl=64 time=0.081 ms
-
-- Get the VTN Dataflows information
-
-::
-
- curl -X GET -H 'content-type: application/json' --user 'admin:adminpass' "http://127.0.0.1:8083/vtn-webapi/dataflows?&switch_id=00:00:00:00:00:00:00:01&port_name=s1-eth1&controller_id=odc&srcmacaddr=de3d.7dec.e4d2&no_vlan_id=true"
-
-- Create a Flowcondition in the VTN
-
-**(The flowconditions, pathmap and pathpolicy commands have to be
-executed in the controller).**
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:set-flow-condition -d '{"input":{"operation":"SET","present":"false","name":"cond_1", "vtn-flow-match":[{"vtn-ether-match":{},"vtn-inet-match":{"source-network":"10.0.0.1/32","protocol":1,"destination-network":"10.0.0.2/32"},"index":"1"}]}}'
-
-- Create a Pathmap in the VTN
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-path-map:set-path-map -d '{"input":{"tenant-name":"vtn1","path-map-list":[{"condition":"cond_1","policy":"1","index": "1","idle-timeout":"300","hard-timeout":"0"}]}}'
-
-- Get the Path policy information
-
-::
-
- curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-path-policy:set-path-policy -d '{"input":{"operation":"SET","id": "1","default-cost": "10000","vtn-path-cost": [{"port-desc":"openflow:1,3,s1-eth3","cost":"1000"},{"port-desc":"openflow:4,2,s4-eth2","cost":"100000"},{"port-desc":"openflow:3,3,s3-eth3","cost":"10000"}]}}'
-
-Verification
-^^^^^^^^^^^^
-
-- Before applying Path policy information in the VTN
-
-::
-
- {
- "pathinfos": [
- {
- "in_port_name": "s1-eth1",
- "out_port_name": "s1-eth3",
- "switch_id": "openflow:1"
- },
- {
- "in_port_name": "s4-eth1",
- "out_port_name": "s4-eth2",
- "switch_id": "openflow:4"
- },
- {
- "in_port_name": "s3-eth2",
- "out_port_name": "s3-eth3",
- "switch_id": "openflow:3"
- }
- ]
- }
-
-- After applying Path policy information in the VTN
-
-::
-
- {
- "pathinfos": [
- {
- "in_port_name": "s1-eth1",
- "out_port_name": "s1-eth2",
- "switch_id": "openflow:1"
- },
- {
- "in_port_name": "s2-eth1",
- "out_port_name": "s2-eth2",
- "switch_id": "openflow:2"
- },
- {
- "in_port_name": "s3-eth1",
- "out_port_name": "s3-eth3",
- "switch_id": "openflow:3"
- }
- ]
- }
-
-VTN Coordinator(Troubleshooting HowTo)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Overview
-^^^^^^^^
-
-This page demonstrates Installation troubleshooting steps of VTN
-Coordinator. OpenDaylight VTN provides multi-tenant virtual network
-functions on OpenDaylight controllers. OpenDaylight VTN consists of two
-parts:
-
-- VTN Coordinator.
-
-- VTN Manager.
-
-VTN Coordinator orchestrates multiple VTN Managers running in
-OpenDaylight Controllers, and provides VTN Applications with VTN API.
-VTN Manager is OSGi bundles running in OpenDaylight Controller. Current
-VTN Manager supports only OpenFlow switches. It handles PACKET\_IN
-messages, sends PACKET\_OUT messages, manages host information, and
-installs flow entries into OpenFlow switches to provide VTN Coordinator
-with virtual network functions. The requirements for installing these
-two are different.Therefore, we recommend that you install VTN Manager
-and VTN Coordinator in different machines.
-
-List of installation Troubleshooting How to’s
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Installation:VTN_Coordinator
-
-**After executing db\_setup, you have encountered the error "Failed to
-setup database"?**
-
-The error could be due to the below reasons
-
-- Access Restriction
-
-The user who owns /usr/local/vtn/ directory and installs VTN
-Coordinator, can only start db\_setup. Example :
-
-::
-
- The directory should appear as below (assuming the user as "vtn"):
- # ls -l /usr/local/
- drwxr-xr-x. 12 vtn vtn 4096 Mar 14 21:53 vtn
- If the user doesnot own /usr/local/vtn/ then, please run the below command (assuming the username as vtn),
- chown -R vtn:vtn /usr/local/vtn
-
-- Postgres not Present
-
-::
-
- 1. In case of Fedora/CentOS/RHEL, please check if /usr/pgsql/<version> directory is present and also ensure the commands initdb, createdb,pg_ctl,psql are working. If, not please re-install postgres packages
- 2. In case of Ubuntu, check if /usr/lib/postgres/<version> directory is present and check for the commands as in the previous step.
-
-- Not enough space to create tables
-
-::
-
- Please check df -k and ensure enough free space is available.
-
-- If the above steps do not solve the problem, please refer to the log
- file for the exact problem
-
-::
-
- /usr/local/vtn/var/dbm/unc_setup_db.log for the exact error.
-
-- list of VTN Coordinator processes
-
-- Run the below command ensure the Coordinator daemons are running.
-
-::
-
- Command: /usr/local/vtn/bin/unc_dmctl status
- Name Type IPC Channel PID
- ----------- ----------- -------------- ------
- drvodcd DRIVER drvodcd 15972
- lgcnwd LOGICAL lgcnwd 16010
- phynwd PHYSICAL phynwd 15996
-
-- Issue the curl command to fetch version and ensure the process is
- able to respond.
-
-**How to debug a startup failure?.**
-
-The following activities take place in order during startup
-
-- Database server is started after setting virtual memory to required
- value,Any database startup errors will be reflected in any of the
- below logs.
-
-::
-
- /usr/local/vtn/var/dbm/unc_db_script.log.
- /usr/local/vtn/var/db/pg_log/postgresql-*.log (the pattern will have the date)
-
-- uncd daemon is kicked off, The daemon in turn kicks off the rest of
- the daemons.
-
-::
-
- Any uncd startup failures will be reflected in /usr/local/vtn/var/uncd/uncd_start.err.
-
-After setting up the apache tomcat server, what are the aspects that should be checked.
-'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
-
-**Please check if catalina is running..**
-
-::
-
- The command ps -ef | grep catalina | grep -v grep should list a catalina process
-
-**If you encounter an erroneous situation where the REST API is always
-failing..**
-
-::
-
- Please ensure the firewall settings for port:8181 (Beryllium release) or port:8083 (Post Beryllium release) and enable the same.
-
-**How to debug a REST API returning a failure message?.**
-
-Please check the /usr/share/java/apache-tomcat-7.0.39/logs/core/core.log
-for failure details.
-
-**REST API for VTN configuration fails, how to debug?.**
-
-The default log level for all daemons is "INFO", to debug the situation
-TRACE or DEBUG logs may be needed. To increase the log level for
-individual daemons, please use the commands suggested below
-
-::
-
- /usr/local/vtn/bin/lgcnw_control loglevel trace -- upll daemon log
- /usr/local/vtn/bin/phynw_control loglevel trace -- uppl daemon log
- /usr/local/vtn/bin/unc_control loglevel trace -- uncd daemon log
- /usr/local/vtn/bin/drvodc_control loglevel trace -- Driver daemon log
-
-After setting the log levels, the operation can be repeated and the log
-files can be referred for debugging.
-
-**Problems while Installing PostgreSQL due to openssl.**
-
-Errors may occur when trying to install postgreSQL rpms. Recently
-PostgreSQL has upgraded all their binaries to use the latest openssl
-versions with fix for http://en.wikipedia.org/wiki/Heartbleed Please
-upgrade the openssl package to the latest version and re-install. For
-RHEL 6.1/6.4 : If you have subscription, Please use the same and update
-the rpms. The details are available in the following link
-https://access.redhat.com/site/solutions/781793 ACCESS-REDHAT
-
-::
-
- rpm -Uvh http://mirrors.kernel.org/centos/6/os/x86_64/Packages/openssl-1.0.1e-15.el6.x86_64.rpm
- rpm -ivh http://mirrors.kernel.org/centos/6/os/x86_64/Packages/openssl-devel-1.0.1e-15.el6.x86_64.rpm
-
-For other linux platforms, Please do yum update, the public respositroes
-will have the latest openssl, please install the same.
-
-Support for Microsoft SCVMM 2012 R2 with ODL VTN
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Introduction
-^^^^^^^^^^^^
-
-System Center Virtual Machine Manager (SCVMM) is Microsoft’s virtual
-machine support center for window’s based emulations. SCVMM is a
-management solution for the virtualized data center. You can use it to
-configure and manage your virtualization host, networking, and storage
-resources in order to create and deploy virtual machines and services to
-private clouds that you have created.
-
-The VSEM Provider is a plug-in to bridge between SCVMM and OpenDaylight.
-
-Microsoft Hyper-V is a server virtualization developed by Microsoft,
-which provides virtualization services through hypervisor-based
-emulations.
-
-.. figure:: ./images/vtn/setup_diagram_SCVMM.png
- :alt: Set-Up Diagram
-
- Set-Up Diagram
-
-**The topology used in this set-up is:**
-
-- A SCVMM with VSEM Provider installed and a running VTN Coordinator
- and OpenDaylight with VTN Feature installed.
-
-- PF1000 virtual switch extension has been installed in the two Hyper-V
- servers as it implements the OpenFlow capability in Hyper-V.
-
-- Three OpenFlow switches simulated using mininet and connected to
- Hyper-V.
-
-- Four VM’s hosted using SCVMM.
-
-**It is implemented as two major components:**
-
-- SCVMM
-
-- OpenDaylight (VTN Feature)
-
-- VTN Coordinator
-
-VTN Coordinator
-^^^^^^^^^^^^^^^
-
-OpenDaylight VTN as Network Service provider for SCVMM where VSEM
-provider is added in the Network Service which will handle all requests
-from SCVMM and communicate with the VTN Coordinator. It is used to
-manage the network virtualization provided by OpenDaylight.
-
-Installing HTTPS in VTN Coordinator
-'''''''''''''''''''''''''''''''''''
-
-- System Center Virtual Machine Manager (SCVMM) supports only https
- protocol.
-
-**Apache Portable Runtime (APR) Installation Steps**
-
-- Enter the command "yum install **apr**" in VTN Coordinator installed
- machine.
-
-- In /usr/bin, create a soft link as "ln –s /usr/bin/apr-1-config
- /usr/bin/apr-config".
-
-- Extract tomcat under "/usr/share/java" by using the below command
- "tar -xvf apache-tomcat-8.0.27.tar.gz –C /usr/share/java".
-
-.. note::
-
- Please go through the bleow link to download
- apache-tomcat-8.0.27.tar.gz file,
- https://archive.apache.org/dist/tomcat/tomcat-8/v8.0.27/bin/
-
-- Please go to the directory "cd
- /usr/share/java/apache-tomcat-8.0.27/bin and unzip tomcat-native.gz
- using this command "tar -xvf tomcat-native.gz".
-
-- Go to the directory "cd
- /usr/share/java/apache-tomcat-8.0.27/bin/tomcat-native-1.1.33-src/jni/native".
-
-- Enter the command "./configure --with-os-type=bin
- --with-apr=/usr/bin/apr-config".
-
-- Enter the command "make" and "make install".
-
-- Apr libraries are successfully installed in "/usr/local/apr/lib".
-
-**Enable HTTP/HTTPS in VTN Coordinator**
-
-Enter the command "firewall-cmd --zone=public --add-port=8083/tcp
---permanent" and "firewall-cmd --reload" to enable firewall settings in
-server.
-
-**Create a CA’s private key and a self-signed certificate in server**
-
-- Execute the following command "openssl req -x509 -days 365
- -extensions v3\_ca -newkey rsa:2048 –out /etc/pki/CA/cacert.pem
- –keyout /etc/pki/CA/private/cakey.pem" in a single line.
-
-+-----------------------+----------------------------------------------------+
-| Argument | Description |
-+=======================+====================================================+
-| Country Name | | Specify the country code. |
-| | | For example, JP |
-+-----------------------+----------------------------------------------------+
-| State or Province | | Specify the state or province. |
-| Name | | For example, Tokyo |
-+-----------------------+----------------------------------------------------+
-| Locality Name | | Locality Name |
-| | | For example, Chuo-Ku |
-+-----------------------+----------------------------------------------------+
-| Organization Name | Specify the company. |
-+-----------------------+----------------------------------------------------+
-| Organizational Unit | Specify the department, division, or the like. |
-| Name | |
-+-----------------------+----------------------------------------------------+
-| Common Name | Specify the host name. |
-+-----------------------+----------------------------------------------------+
-| Email Address | Specify the e-mail address. |
-+-----------------------+----------------------------------------------------+
-
-- Execute the following commands: "touch /etc/pki/CA/index.txt" and
- "echo 00 > /etc/pki/CA/serial" in server after setting your CA’s
- private key.
-
-**Create a private key and a CSR for web server**
-
-- Execute the following command "openssl req -new -newkey rsa:2048 -out
- csr.pem –keyout /usr/local/vtn/tomcat/conf/key.pem" in a single line.
-
-- Enter the PEM pass phrase: Same password you have given in CA’s
- private key PEM pass phrase.
-
-+-----------------------+----------------------------------------------------+
-| Argument | Description |
-+=======================+====================================================+
-| Country Name | | Specify the country code. |
-| | | For example, JP |
-+-----------------------+----------------------------------------------------+
-| State or Province | | Specify the state or province. |
-| Name | | For example, Tokyo |
-+-----------------------+----------------------------------------------------+
-| Locality Name | | Locality Name |
-| | | For example, Chuo-Ku |
-+-----------------------+----------------------------------------------------+
-| Organization Name | Specify the company. |
-+-----------------------+----------------------------------------------------+
-| Organizational Unit | Specify the department, division, or the like. |
-| Name | |
-+-----------------------+----------------------------------------------------+
-| Common Name | Specify the host name. |
-+-----------------------+----------------------------------------------------+
-| Email Address | Specify the e-mail address. |
-+-----------------------+----------------------------------------------------+
-| A challenge password | Specify the challenge password. |
-+-----------------------+----------------------------------------------------+
-| An optional company | Specify an optional company name. |
-| name | |
-+-----------------------+----------------------------------------------------+
-
-**Create a certificate for web server**
-
-- Execute the following command "openssl ca –in csr.pem –out
- /usr/local/vtn/tomcat/conf/cert.pem –days 365 –batch" in a single
- line.
-
-- Enter pass phrase for /etc/pki/CA/private/cakey.pem: Same password
- you have given in CA’s private key PEM pass phrase.
-
-- Open the tomcat file using "vim /usr/local/vtn/tomcat/bin/tomcat".
-
-- Include the line " TOMCAT\_PROPS="$TOMCAT\_PROPS
- -Djava.library.path=\\"/usr/local/apr/lib\\"" " in 131th line and
- save the file.
-
-**Edit server.xml file and restart the server**
-
-- Open the server.xml file using "vim
- /usr/local/vtn/tomcat/conf/server.xml" and add the below lines.
-
- ::
-
- <Connector port="${vtn.port}" protocol="HTTP/1.1" SSLEnabled="true"
- maxThreads="150" scheme="https" secure="true"
- SSLCertificateFile="/usr/local/vtn/tomcat/conf/cert.pem"
- SSLCertificateKeyFile="/usr/local/vtn/tomcat/conf/key.pem"
- SSLPassword=same password you have given in CA's private key PEM pass phrase
- connectionTimeout="20000" />
-
-- Save the file and restart the server.
-
-- To stop vtn use the following command.
-
- ::
-
- /usr/local/vtn/bin/vtn_stop
-
-- To start vtn use the following command.
-
- ::
-
- /usr/local/vtn/bin/vtn_start
-
-- Copy the created CA certificate from cacert.pem to cacert.crt by
- using the following command,
-
- ::
-
- openssl x509 –in /etc/pki/CA/cacert.pem –out cacert.crt
-
- **Checking the HTTP and HTTPS connection from client**
-
-- You can check the HTTP connection by using the following command:
-
- ::
-
- curl -X GET -H 'contenttype:application/json' -H 'username:admin' -H 'password:adminpass' http://<server IP address>:8083/vtn-webapi/api_version.json
-
-- You can check the HTTPS connection by using the following command:
-
- ::
-
- curl -X GET -H 'contenttype:application/json' -H 'username:admin' -H 'password:adminpass' https://<server IP address>:8083/vtn-webapi/api_version.json --cacert /etc/pki/CA/cacert.pem
-
-- The response should be like this for both HTTP and HTTPS:
-
- ::
-
- {"api_version":{"version":"V1.4"}}
-
-Prerequisites to create Network Service in SCVMM machine, Please follow the below steps
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-1. Please go through the below link to download VSEM Provider zip file,
- https://nexus.opendaylight.org/content/groups/public/org/opendaylight/vtn/application/vtnmanager-vsemprovider/1.2.0-Boron/vtnmanager-vsemprovider-1.2.0-Boron-bin.zip
-
-2. Unzip the vtnmanager-vsemprovider-1.2.0-Boron-bin.zip file
- anywhere in your SCVMM machine.
-
-3. Stop SCVMM service from **"service manager→tools→servers→select
- system center virtual machine manager"** and click stop.
-
-4. Go to **"C:/Program Files"** in your SCVMM machine. Inside
- **"C:/Program Files"**, create a folder named as **"ODLProvider"**.
-
-5. Inside **"C:/Program Files/ODLProvider"**, create a folder named as
- "Module" in your SCVMM machine.
-
-6. Inside "C:/Program Files/ODLProvider/Module", Create two folders
- named as **"Odl.VSEMProvider"** and **"VSEMOdlUI"** in your SCVMM
- machine.
-
-7. Copy the **"VSEMOdl.dll"** file from
- **"ODL\_SCVMM\_PROVIDER/ODL\_VSEM\_PROVIDER"** to **"C:/Program
- Files/ODLProvider/Module/Odl.VSEMProvider"** in your SCVMM machine.
-
-8. Copy the **"VSEMOdlProvider.psd1"** file from
- **"application/vsemprovider/VSEMOdlProvider/VSEMOdlProvider.psd1"**
- to **"C:/Program Files/ODLProvider/Module/Odl.VSEMProvider"** in
- your SCVMM machine.
-
-9. Copy the **"VSEMOdlUI.dll"** file from
- **"ODL\_SCVMM\_PROVIDER/ODL\_VSEM\_PROVIDER\_UI"** to **"C:/Program
- Files/ODLProvider/Module/VSEMOdlUI"** in your SCVMM machine.
-
-10. Copy the **"VSEMOdlUI.psd1"** file from
- **"application/vsemprovider/VSEMOdlUI"** to **"C:/Program
- Files/ODLProvider/Module/VSEMOdlUI"** in your SCVMM machine.
-
-11. Copy the **"reg\_entry.reg"** file from
- **"ODL\_SCVMM\_PROVIDER/Register\_settings"** to your SCVMM desktop
- and double click the **"reg\_entry.reg"** file to install registry
- entry in your SCVMM machine.
-
-12. Download **"PF1000.msi"** from this link,
- https://www.pf-info.com/License/en/index.php?url=index/index_non_buyer
- and place into **"C:/Program Files/Switch Extension Drivers"** in
- your SCVMM machine.
-
-13. Start SCVMM service from **"service manager→tools→servers→select
- system center virtual machine manager"** and click start.
-
-System Center Virtual Machine Manager (SCVMM)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-It supports two major features:
-
-- Failover Clustering
-
-- Live Migration
-
-Failover Clustering
-'''''''''''''''''''
-
-A single Hyper-V can host a number of virtual machines. If the host were
-to fail then all of the virtual machines that are running on it will
-also fail, thereby resulting in a major outage. Failover clustering
-treats individual virtual machines as clustered resources. If a host
-were to fail then clustered virtual machines are able to fail over to a
-different Hyper-V server where they can continue to run.
-
-Live Migration
-''''''''''''''
-
-Live Migration is used to migrate the running virtual machines from one
-Hyper-V server to another Hyper-V server without any interruptions.
-Please go through the below video for more details,
-
-- https://youtu.be/34YMOTzbNJM
-
-SCVMM User Guide
-^^^^^^^^^^^^^^^^
-
-- Please go through the below link for SCVMM user guide:
- https://wiki.opendaylight.org/images/c/ca/ODL_SCVMM_USER_GUIDE_final.pdf
-
-- Please go through the below links for more details
-
- - OpenDaylight SCVMM VTN Integration: https://youtu.be/iRt4dxtiz94
-
- - OpenDaylight Congestion Control with SCVMM VTN:
- https://youtu.be/34YMOTzbNJM
Code Review / docs.git / commitdiff
