+++ /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
-.. _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
-.. _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
- bier-developer-guide
- capwap-developer-guide
- cardinal_-opendaylight-monitoring-as-a-service
- 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
nemo-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
- packetcable-developer-guide
p4plugin-developer-guide
service-function-chaining
snmp4sdn-developer-guide
- topology-processing-framework-developer-guide
unified-secure-channel
yang-tools
+++ /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
-.. _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
-
+++ /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
-.. _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 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
-.. _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>`__.
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
+++ /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
-.. _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
-.. _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
-.. _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
-.. _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
- bier-user-guide
- capwap-user-guide
- cardinal_-opendaylight-monitoring-as-a-service
- centinel-user-guide
- didm-user-guide
distribution-version-user-guide
- eman-user-guide
- fabric-as-a-service
- group-based-policy-user-guide
jsonrpc-user-guide
- l2switch-user-guide
- link-aggregation-control-protocol-user-guide
nemo-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
service-function-chaining
- snmp-plugin-user-guide
snmp4sdn-user-guide
unified-secure-channel
+++ /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
-.. _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>`__.
-
+++ /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"
- }
- }
+++ /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.
-
Code Review / docs.git / commitdiff