--- /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
+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
+-----------------------
+
+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 <http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward>`__
+---
+
+Install the Filter Objective
+
+`http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter <http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter>`__
+---
+
+Install the Next Objective:
+
+`http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next <http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next>`__
+---
+
+Flow mod driver API
+~~~~~~~~~~~~~~~~~~~
+
+The Beryllium 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 <http://${controller-ip}:8181/apidoc/explorer/index.html>`__,
+and look under DIDM section to see all the available REST calls and
+tables
+
--- /dev/null
+DLUX
+====
+
+Setup and Run
+-------------
+
+Required Technology Stack
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- AngularJS (JavaScript client-side framework, http://www.angularjs.org
+ )
+
+Run DLUX
+~~~~~~~~
+
+To turn on the DLUX UI, install DLUX core feature via running following
+command on the Karaf console -
+
+::
+
+ feature:install odl-dlux-core
+
+The above command will install odl-restconf and DLUX topology
+application internally, along with core DLUX components. Once this
+feature is successfully installed, access the UI at
+http://localhost:8181/index.html. The default credentials for login are
+admin/admin.
+
+All the applications in DLUX are Karaf features. A user can install
+other dlux applications such as node and yang-ui from Karaf console
+using commands such as -
+
+::
+
+ $ feature:install odl-dlux-node
+
+ $ feature:install odl-dlux-yangui
+
+DLUX Modules
+------------
+
+DLUX modules are the individual features such as nodes and topology.
+Each module has a defined structure and you can find all existing
+modules at
+https://github.com/opendaylight/dlux/tree/stable/lithium/modules.
+
+Module Structure
+~~~~~~~~~~~~~~~~
+
+- module\_folder
+
+ - <module\_name>.module.js
+
+ - <module\_name>.controller.js
+
+ - <module\_name>.services.js
+
+ - <module\_name>.directives.js
+
+ - <module\_name>.filter.js
+
+ - index.tpl.html
+
+ - <a\_stylesheet>.css
+
+Create New Module
+~~~~~~~~~~~~~~~~~
+
+Define the module
+^^^^^^^^^^^^^^^^^
+
+1. Create an empty maven project and create your module folder under
+ src/main/resources.
+
+2. Create an empty file with pattern <module\_name>.module.js.
+
+3. Next, you need to surround the angular module with a define function.
+ This allows RequireJs to see our module.js files. The first argument
+ is an array which contains all the module’s dependencies. The second
+ argument is a callback function, whose body contain the AngularJS
+ code base. The function parameters correspond with the order of
+ dependencies. Each dependency is injected into a parameter, if it is
+ provided.
+
+4. Finally, you will return the angular module to be able to inject it
+ as a parameter in others modules.
+
+For each new module, you must have at least these two dependencies :
+
+- angularAMD : It’s a wrapper around AngularJS to provide an AMD
+ (Asynchronous Module Definition) support, which is used by RequireJs.
+ For more information see the `AMD
+ documentation <https://github.com/amdjs/amdjs-api/blob/master/AMD.md>`__.
+
+- app/core/core.services : This one is mandatory, if you want to add
+ content in the navigation menu, the left bar or the top bar.
+
+The following are not mandatory, but very often used.
+
+- angular-ui-router : A library to provide URL routing.
+
+- routingConfig : To set the level access to a page.
+
+Your module.js file might look like this:
+
+::
+
+ define(['angularAMD','app/routingConfig', 'angular-ui-router','app/core/core.services'], function(ng) {
+ var module = angular.module('app.a_module', ['ui.router.state', 'app.core']);
+ // module configuration
+ module.config(function() {
+ [...]
+ });
+ return module;
+ });
+
+Set the register function
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+AngularJS allows lazy registration of a module’s components such as
+controller, factory etc. Once you will install your application, DLUX
+will load your module javascript, but not your angular component during
+bootstrap phase. You have to register your angular components to make
+sure they are available at the runtime.
+
+Here is how to register your module’s component for lazy initialization
+-
+
+::
+
+ module.config(function($compileProvider, $controllerProvider, $provide) {
+ module.register = {
+ controller : $controllerProvider.register,
+ directive : $compileProvider.directive,
+ factory : $provide.factory,
+ service : $provide.service
+ };
+ });
+
+Set the route
+^^^^^^^^^^^^^
+
+The next step is to set up the route for your module. This part is also
+done in the configuration method of the module. We have to add
+**$stateProvider** as a parameter.
+
+::
+
+ module.config(function($stateProvider) {
+ var access = routingConfig.accessLevels;
+ $stateProvider.state('main.module', {
+ url: 'module',
+ views : {
+ 'content' : {
+ templateUrl: 'src/app/module/module.tpl.html',
+ controller: 'ModuleCtrl'
+ }
+ }
+ });
+ });
+
+Adding element to the navigation menu
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To be able to add item to the navigation menu, the module requires the
+**NavHelperProvider** parameter in the configuration method.
+**addToMenu** method in **NavMenuHelper** helper allows an item addition
+to the menu.
+
+::
+
+ var module = angular.module('app.a_module', ['app.core']);
+ module.config(function(NavMenuHelper) {
+ NavMenuHelper.addToMenu('myFirstModule', {
+ "link" : "#/module/index",
+ "active" : "module",
+ "title" : "My First Module",
+ "icon" : "icon-sitemap",
+ "page" : {
+ "title" : "My First Module",
+ "description" : "My first module"
+ }
+ });
+ });
+
+The first parameter is an ID that refers to the level of your menu and
+the second is a object. For now, The ID parameter supports two levels of
+depth. If your ID looks like *rootNode.childNode*, the helper will look
+for a node named *rootNode* and it will append the *childNode* to it. If
+the root node doesn’t exist, it will create it.
+
+Link the AngularJS module’s controller file
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To include the module’s controller file, you can use the
+NavHelperProvider. It contains a method that will load the given file.
+
+::
+
+ [...]
+ NavHelperProvider.addControllerUrl('<path_to_module_folder>/<module_name>.controller');
+
+This completes your module.js file.
+
+Create the controller, factory, directive, etc
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Creating the controller and other components is similar to the module.
+
+- First, add the define method.
+
+- Second, add the relative path to the module definition.
+
+- Last, create your methods as you usually do it with AngularJS.
+
+For example -
+
+::
+
+ define(['<relative_path_to_module>/<module_name>.module'], function(module) {
+ module.register.controller('ModuleCtrl', function($rootScope, $scope) {
+ });
+ });
+
+Add new application using DLUX modularity
+-----------------------------------------
+
+DLUX works as a Karaf based UI platform, where you can create a new
+Karaf feature of your UI component and install that UI applications in
+DLUX using blueprint. This page will help you to create and load a new
+application for DLUX. You don’t have to add new module in DLUX
+repository.
+
+Add a new OSGi blueprint bundle
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The OSGi Blueprint Container specification allows us to use dependency
+injection in our OSGi environment. Each DLUX application module
+registers itself via blueprint configuration. Each application will have
+its own blueprint.xml to place its configuration.
+
+1. Create a maven project to place blueprint configuration. For
+ reference, take a look at topology bundle, present at
+ https://github.com/opendaylight/dlux/tree/stable/lithium/bundles/topology.
+ All the existing DLUX modules' configurations are available under
+ bundles directory of DLUX code.
+
+2. In pom.xml, you have to add a maven plugin to unpack your module code
+ under generated-resources of this project. For reference, you can
+ check pom.xml of dlux/bundles/topology at
+ https://github.com/opendaylight/dlux/tree/stable/lithium/bundles/topology.
+ Your bundle will eventually get deployed in Karaf as feature, so your
+ bundle should contain all your module code. If you want to combine
+ module and bundle project, that should not be an issue either.
+
+3. Create a blueprint.xml configuration file under
+ src/main/resources/OSGI-INF/blueprint. Below is the content of the
+ blueprint.xml taken from topology bundles’s blueprint.xml. Any new
+ application should create a blueprint.xml in following format -
+
+::
+
+ <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
+ <reference id="httpService" availability="mandatory" activation="eager" interface="org.osgi.service.http.HttpService"/>
+ <reference id="loader" availability="mandatory" activation="eager" interface="org.opendaylight.dlux.loader.DluxModuleLoader"/>
+
+ <bean id="bundle" init-method="initialize" destroy-method="clean" class="org.opendaylight.dlux.loader.DluxModule">
+ <property name="httpService" ref="httpService"/>
+ <property name="loader" ref="loader"/>
+ <property name="moduleName" value="topology "/>
+ <property name="url" value="/src/app/topology"/>
+ <property name="directory" value="/topology"/>
+ <property name="requireJs" value="app/topology/topology.module"/>
+ <property name="angularJs" value="app.topology"/>
+ <property name="cssDependencies">
+ <list>
+ <value>http://yui.yahooapis.com/3.18.1/build/cssreset/cssreset-min.css</value>
+ <value>src/app/topology/topology-custom.css</value>
+ </list>
+ </property>
+ </bean>
+ </blueprint>
+
+In above configuration, there are two references with id httpService and
+loader. These two beans will already be initialized by dlux-core, so any
+new application can use them. Without these two bean references, a new
+application will not be able to register.
+
+Next is the initialization of your application bean, which will be an
+instance of class org.opendaylight.dlux.loader.DluxModule. There are 5
+properties that you should provide in this bean besides the references
+of httpService and loader. Lets talk about those bean properties in
+little more detail.
+
+**moduleName** : Name of your module. This name should be unique in
+DLUX.
+
+**url**: This is the url via which RequireJS in DLUX will try to load
+your module JS/HTML files. Also, this is the url that browser will use
+to load the static HTML, JS or CSS files. RequireJS in DLUX has a base
+path of **src**, so all the url should start with /src so RequireJS and
+the browser can correctly find the files.
+
+**directory**: In your bundle’s pom.xml, you unpack your module code.
+This is the directory where your actual static files will reside. The
+above mentioned url is registered with httpService, so when browser
+makes a call to that url, it will be redirected to the directory
+mentioned here. In the above example, all the topology files are present
+under /topology directory and the browser/RequireJS can access those
+files with uri /src/app/topology.
+
+**requireJS**: This is the path to your RequireJS module. If you notice
+closely, you will see the initial path of RequireJS app/topology in the
+above example matches with the last part of url. This path will be be
+used by RequireJS. As mentioned above, we have kept **src** as base path
+in RequireJS, that is the exact reason that url start with /src.
+
+**angularJS**: name of your AngularJS module.
+
+**cssDependencies**: If the application has any external/internal css
+dependencies, then those can be added here. If you create your own css
+files, just point to those css files here. Use the url path that you
+mentioned above, so the browser can find your css file.
+
+OSGi understands blueprint.xml, once you will deploy your bundle in
+karaf (or you can create a new feature for your application), karaf will
+read your blueprint.xml and it will try to register your application
+with dlux. Once successful, if you refresh your dlux UI, you will see
+your application in left hand navigation bar of dlux.
+
+Yang Utils
+----------
+
+Yang Utils are used by UI to perform all CRUD operations. All of these
+utilities are present in yangutils.services.js file. It has following
+AngularJS factories -
+
+- **arrayUtils** – defines functions for working with arrays.
+
+- **pathUtils** – defines functions for working with xpath (paths to
+ APIs and subAPIs). It divides xpath string to array of elements, so
+ this array can be later used for search functions.
+
+- **syncFact** – provides synchronization between requests to and from
+ OpenDaylight when it’s needed.
+
+- **custFunct** – it is linked with
+ apiConnector.createCustomFunctionalityApis in yangui controller in
+ yangui.controller.js. That function makes it possible to create some
+ custom function called by the click on button in index.tpl.html. All
+ custom functions are stored in array and linked to specific subAPI.
+ When particular subAPI is expanded and clicked, its inputs (linked
+ root node with its child nodes) are displayed in the bottom part of
+ the page and its buttons with custom functionality are displayed
+ also.
+
+- **reqBuilder** – Builds object in JSON format from input fields of
+ the UI page. **Show Preview** button on Yang UI use this builder.
+ This request is sent to OpenDaylight when button PUT or POST is
+ clicked.
+
+- **yinParser** – factory for reading .xml files of yang models and
+ creating object hierarchy. Every statement from yang is represented
+ by a node.
+
+- **nodeWrapper** – adds functions to objects in tree hierarchy created
+ with yinParser. These functions provide functionality for every type
+ of node.
+
+- **apiConnector** – the main functionality is filling the main
+ structures and linking them. Structure of APIs and subAPIs which is
+ two level array - first level is filled by main APIs, second level is
+ filled by others sub APIs. Second main structure is array of root
+ nodes, which are objects including root node and its children nodes.
+ Linking these two structures is creating links between every subAPI
+ (second level of APIs array) and its root node, which must be
+ displayed like inputs when subAPI is expanded.
+
+- **yangUtils** – some top level functions which are used by yangui
+ controller for creating the main structures.
+
--- /dev/null
+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 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
+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
+ feature:install odl-dlux-all odl-dlux-core odl-dlux-yangui odl-dlux-yangvisualizer
+
+2. Start mininet topology and verify in DLUX Topology page for the nodes
+ and link.
+
+ ::
+
+ 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 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
+Neutron Northbound
+==================
+
+How to add new API support
+--------------------------
+
+OpenStack Neutron is a moving target. It is continuously adding new
+features as new rest APIs. Here is a basic step to add new API support:
+
+In the Neutron Northbound project:
+
+- Add new YANG model for it under ``neutron/model/src/main/yang`` and
+ ``update neutron.yang``
+
+- Add northbound API for it, and neutron-spi
+
+ - Implement ``Neutron<New API>Request.java`` and
+ ``Neutron<New API>Norhtbound.java`` under
+ ``neutron/northbound-api/src/main/java/org/opendaylight/neutron/northbound/api/``
+
+ - Implement ``INeutron<New API>CRUD.java`` and new data structure if
+ any under
+ ``neutron/neutron-spi/src/main/java/org/opendaylight/neutron/spi/``
+
+ - update
+ ``neutron/neutron-spi/src/main/java/org/opendaylight/neutron/spi/NeutronCRUDInterfaces.java``
+ to wire new CRUD interface
+
+ - Add unit tests, ``Neutron<New structure>JAXBTest.java`` under
+ ``neutron/neutron-spi/src/test/java/org/opendaylight/neutron/spi/``
+
+- update
+ ``neutron/northbound-api/src/main/java/org/opendaylight/neutron/northbound/api/NeutronNorthboundRSApplication.java``
+ to wire new northbound api to ``RSApplication``
+
+- Add transcriber, ``Neutron<New API>Interface.java`` under
+ ``transcriber/src/main/java/org/opendaylight/neutron/transcriber/``
+
+- update
+ ``transcriber/src/main/java/org/opendaylight/neutron/transcriber/NeutronTranscriberProvider.java``
+ to wire a new transcriber
+
+ - Add integration tests ``Neutron<New API>Tests.java`` under
+ ``integration/test/src/test/java/org/opendaylight/neutron/e2etest/``
+
+ - update
+ ``integration/test/src/test/java/org/opendaylight/neutron/e2etest/ITNeutronE2E.java``
+ to run a newly added tests.
+
+In OpenStack networking-odl
+
+- Add new driver (or plugin) for new API with tests.
+
+In a southbound Neutron Provider
+
+- implement actual backend to realize those new API by listening
+ related YANG models.
+
+How to write transcriber
+------------------------
+
+For each Neutron data object, there is an ``Neutron*Interface`` defined
+within the transcriber artifact that will write that object to the
+MD-SAL configuration datastore.
+
+All ``Neutron*Interface`` extend ``AbstractNeutronInterface``, in which
+two methods are defined:
+
+- one takes the Neutron object as input, and will create a data object
+ from it.
+
+- one takes an uuid as input, and will create a data object containing
+ the uuid.
+
+::
+
+ protected abstract T toMd(S neutronObject);
+ protected abstract T toMd(String uuid);
+
+In addition the ``AbstractNeutronInterface`` class provides several
+other helper methods (``addMd``, ``updateMd``, ``removeMd``), which
+handle the actual writing to the configuration datastore.
+
+The semantics of the ``toMD()`` methods
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each of the Neutron YANG models defines structures containing data.
+Further each YANG-modeled structure has it own builder. A particular
+``toMD()`` method instantiates an instance of the correct builder, fills
+in the properties of the builder from the corresponding values of the
+Neutron object and then creates the YANG-modeled structures via the
+``build()`` method.
+
+As an example, one of the ``toMD`` code for Neutron Networks is
+presented below:
+
+::
+
+ protected Network toMd(NeutronNetwork network) {
+ NetworkBuilder networkBuilder = new NetworkBuilder();
+ networkBuilder.setAdminStateUp(network.getAdminStateUp());
+ if (network.getNetworkName() != null) {
+ networkBuilder.setName(network.getNetworkName());
+ }
+ if (network.getShared() != null) {
+ networkBuilder.setShared(network.getShared());
+ }
+ if (network.getStatus() != null) {
+ networkBuilder.setStatus(network.getStatus());
+ }
+ if (network.getSubnets() != null) {
+ List<Uuid> subnets = new ArrayList<Uuid>();
+ for( String subnet : network.getSubnets()) {
+ subnets.add(toUuid(subnet));
+ }
+ networkBuilder.setSubnets(subnets);
+ }
+ if (network.getTenantID() != null) {
+ networkBuilder.setTenantId(toUuid(network.getTenantID()));
+ }
+ if (network.getNetworkUUID() != null) {
+ networkBuilder.setUuid(toUuid(network.getNetworkUUID()));
+ } else {
+ logger.warn("Attempting to write neutron network without UUID");
+ }
+ return networkBuilder.build();
+ }
+
--- /dev/null
+Neutron Service Developer Guide
+===============================
+
+Overview
+--------
+
+This Karaf feature (``odl-neutron-service``) provides integration
+support for OpenStack Neutron via the OpenDaylight ML2 mechanism driver.
+The Neutron Service is only one of the components necessary for
+OpenStack integration. It defines YANG models for OpenStack Neutron data
+models and northbound API via REST API and YANG model RESTCONF.
+
+Those developers who want to add new provider for new OpenStack Neutron
+extensions/services (Neutron constantly adds new extensions/services and
+OpenDaylight will keep up with those new things) need to communicate
+with this Neutron Service or add models to Neutron Service. If you want
+to add new extensions/services themselves to the Neutron Service, new
+YANG data models need to be added, but that is out of scope of this
+document because this guide is for a developer who will be *using* the
+feature to build something separate, but *not* somebody who will be
+developing code for this feature itself.
+
+Neutron Service Architecture
+----------------------------
+
+.. figure:: ./images/neutron/odl-neutron-service-developer-architecture.png
+ :alt: Neutron Service Architecture
+
+ Neutron Service Architecture
+
+The Neutron Service defines YANG models for OpenStack Neutron
+integration. When OpenStack admins/users request changes
+(creation/update/deletion) of Neutron resources, e.g., Neutron network,
+Neutron subnet, Neutron port, the corresponding YANG model within
+OpenDaylight will be modified. The OpenDaylight OpenStack will subscribe
+the changes on those models and will be notified those modification
+through MD-SAL when changes are made. Then the provider will do the
+necessary tasks to realize OpenStack integration. How to realize it (or
+even not realize it) is up to each provider. The Neutron Service itself
+does not take care of it.
+
+How to Write a SB Neutron Consumer
+----------------------------------
+
+In Boron, there is only one options for SB Neutron Consumers:
+
+- Listening for changes via the Neutron YANG model
+
+Until Beryllium there was another way with the legacy I\*Aware
+interface. From Boron, the interface was eliminated. So all the SB
+Neutron Consumers have to use Neutron YANG model.
+
+Neutron YANG models
+-------------------
+
+Neutron service defines YANG models for Neutron. The details can be
+found at
+
+- https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=tree;f=model/src/main/yang;hb=refs/heads/stable/boron
+
+Basically those models are based on OpenStack Neutron API definitions.
+For exact definitions, OpenStack Neutron source code needs to be
+referred as the above documentation doesn’t always cover the necessary
+details. There is nothing special to utilize those Neutron YANG models.
+The basic procedure will be:
+
+1. subscribe for changes made to the the model
+
+2. respond on the data change notification for each models
+
+.. note::
+
+ Currently there is no way to refuse the request configuration at
+ this point. That is left to future work.
+
+.. code:: java
+
+ public class NeutronNetworkChangeListener implements DataChangeListener, AutoCloseable {
+ private ListenerRegistration<DataChangeListener> registration;
+ private DataBroker db;
+
+ public NeutronNetworkChangeListener(DataBroker db){
+ this.db = db;
+ // create identity path to register on service startup
+ InstanceIdentifier<Network> path = InstanceIdentifier
+ .create(Neutron.class)
+ .child(Networks.class)
+ .child(Network.class);
+ LOG.debug("Register listener for Neutron Network model data changes");
+ // register for Data Change Notification
+ registration =
+ this.db.registerDataChangeListener(LogicalDatastoreType.CONFIGURATION, path, this, DataChangeScope.ONE);
+
+ }
+
+ @Override
+ public void onDataChanged(
+ AsyncDataChangeEvent<InstanceIdentifier<?>, DataObject> changes) {
+ LOG.trace("Data changes : {}",changes);
+
+ // handle data change notification
+ Object[] subscribers = NeutronIAwareUtil.getInstances(INeutronNetworkAware.class, this);
+ createNetwork(changes, subscribers);
+ updateNetwork(changes, subscribers);
+ deleteNetwork(changes, subscribers);
+ }
+ }
+
+Neutron configuration
+---------------------
+
+From Boron, new models of configuration for OpenDaylight to tell
+OpenStack neutron/networking-odl its configuration/capability.
+
+hostconfig
+~~~~~~~~~~
+
+This is for OpenDaylight to tell per-node configuration to Neutron.
+Especially this is used by pseudo agent port binding heavily.
+
+The model definition can be found at
+
+- https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=model/src/main/yang/neutron-hostconfig.yang;hb=refs/heads/stable/boron
+
+How to populate this for pseudo agent port binding is documented at
+
+- http://git.openstack.org/cgit/openstack/networking-odl/tree/doc/source/devref/hostconfig.rst
+
+Neutron extension config
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+In Boron this is experimental. The model definition can be found at
+
+- https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=model/src/main/yang/neutron-extensions.yang;hb=refs/heads/stable/boron
+
+Each Neutron Service provider has its own feature set. Some support the
+full features of OpenStack, but others support only a subset. With same
+supported Neutron API, some functionality may or may not be supported.
+So there is a need for a way that OpenDaylight can tell networking-odl
+its capability. Thus networking-odl can initialize Neutron properly
+based on reported capability.
+
+Neutorn Logger
+--------------
+
+There is another small Karaf feature, ``odl-neutron-logger``, which logs
+changes of Neutron YANG models. which can be used for debug/audit.
+
+It would also help to understand how to listen the change.
+
+- https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=neutron-logger/src/main/java/org/opendaylight/neutron/logger/NeutronLogger.java;hb=refs/heads/stable/boron
+
+API Reference Documentation
+---------------------------
+
+The OpenStack Neutron API references
+
+- http://developer.openstack.org/api-ref-networking-v2.html
+
+- http://developer.openstack.org/api-ref-networking-v2-ext.html
+
--- /dev/null
+ODL Parent Developer Guide
+==========================
+
+Parent POMs
+-----------
+
+Overview
+~~~~~~~~
+
+The ODL Parent component for OpenDaylight provides a number of Maven
+parent POMs which allow Maven projects to be easily integrated in the
+OpenDaylight ecosystem. Technically, the aim of projects in OpenDaylight
+is to produce Karaf features, and these parent projects provide common
+support for the different types of projects involved.
+
+| These parent projects are:
+
+- ``odlparent-lite`` — the basic parent POM for Maven modules which
+ don’t produce artifacts (*e.g.* aggregator POMs)
+
+- ``odlparent`` — the common parent POM for Maven modules containing
+ Java code
+
+- ``bundle-parent`` — the parent POM for Maven modules producing OSGi
+ bundles
+
+- ``features-parent`` — the parent POM for Maven modules producing
+ Karaf features
+
+odlparent-lite
+~~~~~~~~~~~~~~
+
+| This is the base parent for all OpenDaylight Maven projects and
+ modules. It provides the following, notably to allow publishing
+ artifacts to Maven Central:
+
+- license information;
+
+- organization information;
+
+- issue management information (a link to our Bugzilla);
+
+- continuous integration information (a link to our Jenkins setup);
+
+- default Maven plugins (``maven-clean-plugin``,
+ ``maven-deploy-plugin``, ``maven-install-plugin``,
+ ``maven-javadoc-plugin`` with HelpMojo support,
+ ``maven-project-info-reports-plugin``, ``maven-site-plugin`` with
+ Asciidoc support, ``jdepend-maven-plugin``);
+
+- distribution management information.
+
+It also defines two profiles which help during development:
+
+- ``q`` (``-Pq``), the quick profile, which disables tests, code
+ coverage, Javadoc generation, code analysis, etc. — anything which
+ isn’t necessary to build the bundles and features (see `this blog
+ post <http://blog2.vorburger.ch/2016/06/improve-maven-build-speed-with-q.html>`__
+ for details);
+
+- ``addInstallRepositoryPath``
+ (``-DaddInstallRepositoryPath=…/karaf/system``) which can be used to
+ drop a bundle in the appropriate Karaf location, to enable
+ hot-reloading of bundles during development (see `this blog
+ post <http://blog2.vorburger.ch/2016/06/maven-install-into-additional.html>`__
+ for details).
+
+For modules which don’t produce any useful artifacts (*e.g.* aggregator
+POMs), you should add the following to avoid processing artifacts:
+
+::
+
+ <build>
+ <plugins>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-deploy-plugin</artifactId>
+ <configuration>
+ <skip>true</skip>
+ </configuration>
+ </plugin>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-install-plugin</artifactId>
+ <configuration>
+ <skip>true</skip>
+ </configuration>
+ </plugin>
+ </plugins>
+ </build>
+
+odlparent
+~~~~~~~~~
+
+This inherits from ``odlparent-lite`` and mainly provides dependency and
+plugin management for OpenDaylight projects.
+
+| If you use any of the following libraries, you should rely on
+ ``odlparent`` to provide the appropriate versions:
+
+- Akka (and Scala)
+
+- | Apache Commons:
+
+ - ``commons-codec``
+
+ - ``commons-fileupload``
+
+ - ``commons-io``
+
+ - ``commons-lang``
+
+ - ``commons-lang3``
+
+ - ``commons-net``
+
+- Apache Shiro
+
+- Guava
+
+- JAX-RS with Jersey
+
+- | JSON processing:
+
+ - GSON
+
+ - Jackson
+
+- | Logging:
+
+ - Logback
+
+ - SLF4J
+
+- Netty
+
+- | OSGi:
+
+ - Apache Felix
+
+ - core OSGi dependencies (``core``, ``compendium``\ …)
+
+- | Testing:
+
+ - Hamcrest
+
+ - JSON assert
+
+ - JUnit
+
+ - Mockito
+
+ - Pax Exam
+
+ - PowerMock
+
+- | XML/XSL:
+
+ - Xerces
+
+ - XML APIs
+
+.. note::
+
+ This list isn’t exhaustive. It’s also not cast in stone; if you’d
+ like to add a new dependency (or migrate a dependency), please
+ contact `the mailing
+ list <https://lists.opendaylight.org/mailman/listinfo/odlparent-dev>`__.
+
+``odlparent`` also enforces some Checkstyle verification rules. In
+particular, it enforces the common license header used in all
+OpenDaylight code:
+
+::
+
+ /*
+ * Copyright © ${year} ${holder} and others. All rights reserved.
+ *
+ * This program and the accompanying materials are made available under the
+ * terms of the Eclipse Public License v1.0 which accompanies this distribution,
+ * and is available at http://www.eclipse.org/legal/epl-v10.html
+ */
+
+where “\ ``${year}``\ ” is initially the first year of publication, then
+(after a year has passed) the first and latest years of publication,
+separated by commas (*e.g.* “2014, 2016”), and “\ ``${holder}``\ ” is
+the initial copyright holder (typically, the first author’s employer).
+“All rights reserved” is optional.
+
+If you need to disable this license check, *e.g.* for files imported
+under another license (EPL-compatible of course), you can override the
+``maven-checkstyle-plugin`` configuration. ``features-test`` does this
+for its ``CustomBundleUrlStreamHandlerFactory`` class, which is
+ASL-licensed:
+
+::
+
+ <plugin>
+ <artifactId>maven-checkstyle-plugin</artifactId>
+ <executions>
+ <execution>
+ <id>check-license</id>
+ <goals>
+ <goal>check</goal>
+ </goals>
+ <phase>process-sources</phase>
+ <configuration>
+ <configLocation>check-license.xml</configLocation>
+ <headerLocation>EPL-LICENSE.regexp.txt</headerLocation>
+ <includeResources>false</includeResources>
+ <includeTestResources>false</includeTestResources>
+ <sourceDirectory>${project.build.sourceDirectory}</sourceDirectory>
+ <excludes>
+ <!-- Skip Apache Licensed files -->
+ org/opendaylight/odlparent/featuretest/CustomBundleUrlStreamHandlerFactory.java
+ </excludes>
+ <failsOnError>false</failsOnError>
+ <consoleOutput>true</consoleOutput>
+ </configuration>
+ </execution>
+ </executions>
+ </plugin>
+
+bundle-parent
+~~~~~~~~~~~~~
+
+| This inherits from ``odlparent`` and enables functionality useful for
+ OSGi bundles:
+
+- ``maven-javadoc-plugin`` is activated, to build the Javadoc JAR;
+
+- ``maven-source-plugin`` is activated, to build the source JAR;
+
+- ``maven-bundle-plugin`` is activated (including extensions), to build
+ OSGi bundles (using the “bundle” packaging).
+
+In addition to this, JUnit is included as a default dependency in “test”
+scope.
+
+features-parent
+~~~~~~~~~~~~~~~
+
+| This inherits from ``odlparent`` and enables functionality useful for
+ Karaf features:
+
+- ``karaf-maven-plugin`` is activated, to build Karaf features — but
+ for OpenDaylight, projects need to use “jar” packaging (**not**
+ “kar”);
+
+- ``features.xml`` files are processed from templates stored in
+ ``src/main/features/features.xml``;
+
+- Karaf features are tested after build to ensure they can be activated
+ in a Karaf container.
+
+The ``features.xml`` processing allows versions to be ommitted from
+certain feature dependencies, and replaced with “\ ``{{version}}``\ ”.
+For example:
+
+::
+
+ <features name="odl-mdsal-${project.version}" xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.2.0 http://karaf.apache.org/xmlns/features/v1.2.0">
+
+ <repository>mvn:org.opendaylight.odlparent/features-odlparent/{{VERSION}}/xml/features</repository>
+
+ [...]
+ <feature name='odl-mdsal-broker-local' version='${project.version}' description="OpenDaylight :: MDSAL :: Broker">
+ <feature version='${yangtools.version}'>odl-yangtools-common</feature>
+ <feature version='${mdsal.version}'>odl-mdsal-binding-dom-adapter</feature>
+ <feature version='${mdsal.model.version}'>odl-mdsal-models</feature>
+ <feature version='${project.version}'>odl-mdsal-common</feature>
+ <feature version='${config.version}'>odl-config-startup</feature>
+ <feature version='${config.version}'>odl-config-netty</feature>
+ <feature version='[3.3.0,4.0.0)'>odl-lmax</feature>
+ [...]
+ <bundle>mvn:org.opendaylight.controller/sal-dom-broker-config/{{VERSION}}</bundle>
+ <bundle start-level="40">mvn:org.opendaylight.controller/blueprint/{{VERSION}}</bundle>
+ <configfile finalname="${config.configfile.directory}/${config.mdsal.configfile}">mvn:org.opendaylight.controller/md-sal-config/{{VERSION}}/xml/config</configfile>
+ </feature>
+
+As illustrated, versions can be ommitted in this way for repository
+dependencies, bundle dependencies and configuration files. They must be
+specified traditionally (either hard-coded, or using Maven properties)
+for feature dependencies.
+
+Features
+--------
+
+The ODL Parent component for OpenDaylight provides a number of Karaf
+features which can be used by other Karaf features to use certain
+third-party upstream dependencies.
+
+| These features are:
+
+- | Akka features (in the ``features-akka`` repository):
+
+ - ``odl-akka-all`` — all Akka bundles;
+
+ - ``odl-akka-scala`` — Scala runtime for OpenDaylight;
+
+ - ``odl-akka-system`` — Akka actor framework bundles;
+
+ - ``odl-akka-clustering`` — Akka clustering bundles and
+ dependencies;
+
+ - ``odl-akka-leveldb`` — LevelDB;
+
+ - ``odl-akka-persistence`` — Akka persistence;
+
+- general third-party features (in the ``features-odlparent``
+ repository):
+
+ - ``odl-netty`` — all Netty bundles;
+
+ - ``odl-guava`` — Guava;
+
+ - ``odl-lmax`` — LMAX Disruptor.
+
+To use these, you need to declare a dependency on the appropriate
+repository in your ``features.xml`` file:
+
+::
+
+ <repository>mvn:org.opendaylight.odlparent/features-odlparent/{{VERSION}}/xml/features</repository>
+
+and then include the feature, *e.g.*:
+
+::
+
+ <feature name='odl-mdsal-broker-local' version='${project.version}' description="OpenDaylight :: MDSAL :: Broker">
+ [...]
+ <feature version='[3.3.0,4.0.0)'>odl-lmax</feature>
+ [...]
+ </feature>
+
+You also need to depend on the features repository in your POM:
+
+::
+
+ <dependency>
+ <groupId>org.opendaylight.odlparent</groupId>
+ <artifactId>features-odlparent</artifactId>
+ <classifier>features</classifier>
+ <type>xml</type>
+ </dependency>
+
+assuming the appropriate dependency management:
+
+::
+
+ <dependencyManagement>
+ <dependencies>
+ <dependency>
+ <groupId>org.opendaylight.odlparent</groupId>
+ <artifactId>odlparent-artifacts</artifactId>
+ <version>1.7.0-SNAPSHOT</version>
+ <scope>import</scope>
+ <type>pom</type>
+ </dependency>
+ </dependencies>
+ </dependencyManagement>
+
+(the version number there is appropriate for Boron). For the time being
+you also need to depend separately on the individual JARs as
+compile-time dependencies to build your dependent code; the relevant
+dependencies are managed in ``odlparent``'s dependency management.
+
+| The suggested version ranges are as follows:
+
+- ``odl-netty``: ``[4.0.37,4.1.0)`` or ``[4.0.37,5.0.0)``;
+
+- ``odl-guava``: ``[18,19)`` (if your code is ready for it, ``[19,20)``
+ is also available, but the current default version of Guava in
+ OpenDaylight is 18);
+
+- ``odl-lmax``: ``[3.3.4,4.0.0)``
+
--- /dev/null
+OpFlex agent-ovs Developer Guide
+================================
+
+Overview
+--------
+
+agent-ovs is a policy agent that works with OVS to enforce a group-based
+policy networking model with locally attached virtual machines or
+containers. The policy agent is designed to work well with orchestration
+tools like OpenStack.
+
+agent-ovs Architecture
+----------------------
+
+agent-ovs uses libopflex to communicate with an OpFlex-based policy
+repository to enforce policy on network endpoints attached to OVS by an
+orchestration system.
+
+The key components are:
+
+- Agent - coordinates startup and configuration
+
+- Renderers - Renderers are responsible for rendering policy. This is a
+ very general mechanism but the currently-implemented renderer is the
+ stitched-mode renderer that can work along with with hardware fabrics
+ such as ACI that support policy enforcement.
+
+- EndpointManager - Keep track of network endpoints and declare them to
+ the endpoint repository
+
+- PolicyManager - Keep track of and index policies
+
+- FlowManager - render policies to OVS
+
+API Reference Documentation
+---------------------------
+
+Internal API documentation can be found here:
+https://jenkins.opendaylight.org/opflex/job/opflex-merge/ws/agent-ovs/doc/html/index.html
+
--- /dev/null
+OpFlex genie Developer Guide
+============================
+
+Overview
+--------
+
+Genie is a tool for code generation from a model. It supports generating
+C++ and Java code. C++ can be generated suitable for use with libopflex.
+C++ and Java can be generated as a plain set of objects.
+
+Group-based Policy Model
+------------------------
+
+The group-based policy model is included with the genie tool and can be
+found under the MODEL directory. By running mvn exec:java, libmodelgbp
+will be generated as a library project that, when built and installed,
+will work with libopflex. This model is used by the OVS agent.
+
+API Reference Documentation
+---------------------------
+
+Complete API documentation for the generated libmodelgbp can be found
+here:
+https://jenkins.opendaylight.org/opflex/job/opflex-merge/ws/libopflex/doc/html/index.html
+
--- /dev/null
+OpFlex libopflex Developer Guide
+================================
+
+Overview
+--------
+
+The OpFlex framework allows you to develop agents that can communicate
+using the OpFlex protocol and act as a policy element in an OpFlex-based
+distributed control system. The OpFlex architecture provides a
+distributed control system based on a declarative policy information
+model. The policies are defined at a logically centralized policy
+repository and enforced within a set of distributed policy elements. The
+policy repository communicates with the subordinate policy elements
+using the OpFlex control protocol. This protocol allows for
+bidirectional communication of policy, events, statistics, and faults.
+
+Rather than simply providing access to the OpFlex protocol, this
+framework allows you to directly manipulate a management information
+tree containing a hierarchy of managed objects. This tree is kept in
+sync as needed with other policy elements in the system, and you are
+automatically notified when important changes to the model occur.
+Additionally, we can ensure that only those managed objects that are
+important to the local policy element are synchronized locally.
+
+Object Model
+~~~~~~~~~~~~
+
+Interactions with the OpFlex framework happen through the management
+information tree. This is a tree of managed objects defined by an object
+model specific to your application. There are a few important major
+category of objects that can appear in the model.
+
+- First, there is the policy object. A policy object represents some
+ data related to a policy that describes a user intent for how the
+ system should behave. A policy object is stored in the policy
+ repository which is the source of "truth" for this object.
+
+- Second, there is an endpoint object. A endpoint represents an entity
+ in the system to which we want to apply policy, which could be a
+ network interface, a storage array, or other relevent policy
+ endpoint. Endpoints are discovered and reported by policy elements
+ locally, and are synchronized into the endpoint repository. The
+ originating policy element is the source of truth for the endpoints
+ it discovers. Policy elements can retrieve information about
+ endpoints discovered by other policy elements by resolving endpoints
+ from the endpoint repository.
+
+- Third, there is the observable object. An observable object
+ represents some state related to the operational status or health of
+ the policy element. Observable objects will be reported to the
+ observer.
+
+- Finally, there is the local-only object. This is the simplest object
+ because it exists only local to a particular policy element. These
+ objects can be used to store state specific to that policy element,
+ or as helpers to resolve other objects. Read on to learn more.
+
+You can use the genie tool that is included with the framework to
+produce your application model along with a set of generated accessor
+classes that can work with this framework library. You should refer to
+the documentation that accompanies the genie tool for information on how
+to use to to generate your object model. Later in this guide, we’ll go
+through examples of how to use the generated managed object accessor
+classes.
+
+Programming by Side Effect
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When developing software on the OpFlex framework, you’ll need to think
+in a slightly different way. Rather than calling an API function that
+would perform some specific action, you’ll need to write a managed
+object to the managed object database. Writing that object to the store
+will trigger the side effect of performing the action that you want.
+
+For example, a policy element will need to have a component responsible
+for discovering policy endpoints. When it discovers a policy endpoint,
+it would write an endpoint object into the managed object database. That
+endpoint object will contain a reference to policy that is relevant to
+the endpoint object. This will trigger a whole cascade of events. First,
+the framework will notice that an endpoint object has been created and
+it will write it to the endpoint repository. Second, the framework to
+will attempt to resolve the unresolved reference to the relevent policy
+object. There might be a whole chain of policy resolutions that will be
+automatically performed to download all the relevent policy until there
+are no longer any dangling references.
+
+As long as there is a locally-created object in the system with a
+reference to that policy, the framework will continually ensure that the
+policy and any transitive policies are kept up to date. The policy
+element can subscribe to updates to these policy classes that will be
+invoked either the first time the policy is resolved or any time the
+policy changes.
+
+A consequence of this design is that the managed object database can be
+temporarily in an inconsistent state with unresolved dangling
+references. Eventually, however, the inconsistency will be fully
+resolved. The policy element must be able to cleanly handle
+partially-resolved or inconsistent state and eventually reach the
+correct state as it receives these update notifications. Note that, in
+the OpFlex architecture, when there is no policy that specifically
+allows a particular action, that action must be prevented.
+
+Let’s cover one slightly more complex example. If a policy element needs
+to discover information about an endpoint that is not local to that
+policy element, it will need to retrieve that information from the
+endpoint repository. However, just as there is no API call to retrieve a
+policy object from the policy repository, there is no API call to
+retrieve an endpoint from the endpoint repository.
+
+To get this information, the policy element needs to create a local-only
+object that references the endpoint. Once it creates this local-only
+object, if the endpoint is not already resolved, the framework will
+notice the dangling reference and automatically resolve the endpoint
+from the endpoint respository. When the endpoint resolution completes,
+the framework deliver an update notification to the policy element. The
+policy element will continue to receive any updates related to that
+endpoint until the policy element remove the local-only reference to the
+object. Once this occurs, the framework can garbage-collect any
+unreferenced objects.
+
+Threading and Ownership
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The OpFlex framework uses a somewhat unique threading model. Each
+managed object in the system belongs to a particular owner. An owner
+would typically be a single thread that is reponsible for all updates to
+objects with that owner. Though anything can read the state of a managed
+object, only the owner of a managed object is permitted to write to it.
+Though this is not strictly required for correctness, the performance of
+the system wil be best if you ensure that only one thread at a time is
+writing to objects with a particular owner.
+
+Change notifications are delivered in a serialized fashion by a single
+thread. Blocking this thread from a notification callback will stall
+delivery of all notifications. It is therefore best practice to ensure
+that you do not block or perform long-running operations from a
+notification callback.
+
+Key APIs and Interfaces
+-----------------------
+
+Basic Usage and Initialization
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The primary interface point into the framework is
+opflex::ofcore::OFFramework. You can choose to instantiate your own copy
+of the framework, or you can use the static default instance.
+
+Before you can use the framework, you must initialize it by installing
+your model metadata. The model metadata is accessible through the
+generated model library. In this case, it assumes your model is called
+"mymodel":
+
+.. code:: cpp
+
+ #include <opflex/ofcore/OFFramework.h>
+ #include <mymodel/metadata/metadata.hpp>
+ // ...
+ using opflex::ofcore::OFFramework;
+ OFFramework::defaultInstance().setModel(mymodel::getMetadata());
+
+The other critical piece of information required for initialization is
+the OpFlex identity information. The identity information is required in
+order to successfully connect to OpFlex peers. In OpFlex, each component
+has a unique name within its policy domain, and each policy domain is
+identified by a globally unique domain name. You can set this identity
+information by calling:
+
+.. code:: cpp
+
+ OFFramework::defaultInstance()
+ .setOpflexIdentity("[component name]", "[unique domain]");
+
+You can then start the framework simply by calling:
+
+.. code:: cpp
+
+ OFFramework::defaultInstance().start();
+
+Finally, you can add peers after the framework is started by calling the
+``opflex::ofcore::OFFramework::addPeer`` method:
+
+.. code:: cpp
+
+ OFFramework::defaultInstance().addPeer("192.168.1.5", 1234);
+
+When connecting to the peer, that peer may provide an additional list of
+peers to connect to, which will be automatically added as peers. If the
+peer does not include itself in the list, then the framework will
+disconnect from that peer and add the peers in the list. In this way, it
+is possible to automatically bootstrap the correct set of peers using a
+known hostname or IP address or a known, fixed anycast IP address.
+
+To cleanly shut down, you can call:
+
+.. code:: cpp
+
+ OFFramework::defaultInstance().stop();
+
+Working with Data in the Tree
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Reading from the Tree
+^^^^^^^^^^^^^^^^^^^^^
+
+You can access data in the managed tree using the generated accessor
+classes. The details of exactly which classes you’ll use will depend on
+the model you’re using, but let’s assume that we have a simple model
+called "simple" with the following classes:
+
+- root - The root node. The URI for the root node is "/"
+
+- foo - A policy object, and a child of root, with a scalar string
+ property called "bar", and a unsigned 64-bit integer property called
+ baz. The bar property is the naming property for foo. The URI for a
+ foo object would be "/foo/[value of bar]/"
+
+- fooref - A local-only child of root, with a reference to a foo, and a
+ scalar string property called "bar". The bar property is the naming
+ property for foo. The URI for a fooref object would be
+ "/fooref/[value of bar]/"
+
+In this example, we’ll have a generated class for each of the objects.
+There are two main ways to get access to an object in the tree.
+
+First, we can get instantiate an accessor class to any node in the tree
+by calling one of its static resolve functions. The resolve functions
+can take either an already-built URI that represents the object, or you
+can call the version that will locate the object by its naming
+properties.
+
+Second, we can access the object also from its parent object using the
+appropriate child resolver member functions.
+
+However we read it, the object we get back is an immutable view into the
+object it references. The properties set locally on that object will not
+change even though the underlying object may have been updated in the
+store. Note, however, that its children can change between when you
+first retrieve the object and when you resolve any children.
+
+Another thing that is critical to note again is that when you attempt to
+resolve an object, you can get back nothing, even if the object actually
+does exist on another OpFlex node. You must ensure that some object in
+the managed object database references the remote managed object you
+want before it will be visible to you.
+
+To get access to the root node using the default framework instance, we
+can simply call:
+
+.. code:: cpp
+
+ using boost::shared_ptr;
+ using boost::optional;
+ optional<shared_ptr<simple::root> > r(simple::root::resolve());
+
+Note that whenever we can a resolve function, we get back our data in
+the form of an optional shared pointer to the object instance. If the
+node does not exist, then the optional will be set to boost::none. Note
+that if you dereference an optional that has not been set, you’ll
+trigger an assert, so you must check the return as follows:
+
+.. code:: cpp
+
+ if (!r) {
+ // handle missing object
+ }
+
+Now let’s get a child node of the root in three different ways:
+
+.. code:: cpp
+
+ // Get foo1 by constructing its URI from the root
+ optional<shared_ptr<simple::foo> > foo1(simple::foo::resolve("test"));
+ // get foo1 by constructing its URI relative to its parent
+ foo1 = r.get()->resolveFoo("test");
+ // get foo1 by manually building its URI
+ foo1 = simple::foo::resolve(opflex::modb::URIBuilder()
+ .addElement("foo")
+ .addElement("test")
+ .build());
+
+All three of these calls will give us the same object, which is the
+"foo" object located at "/foo/test/".
+
+The foo class has a single string property called "bar". We can easily
+access it as follows:
+
+.. code:: cpp
+
+ const std::string& barv = foo1.getBar();
+
+Writing to the Tree
+^^^^^^^^^^^^^^^^^^^
+
+Writing to the tree is nearly as easy as reading from it. The key
+concept to understand is the mutator object. If you want to make changes
+to the tree, you must allocate a mutator object. The mutator will
+register itself in some thread-local storage in the framework instance
+you’re using. The mutator is specific to a single "owner" for the data,
+so you can only make changes to data associated with that owner.
+
+Whenever you modify one of the accessor classes, the change is actually
+forwarded to the currently-active mutator. You won’t see any of the
+changes you make until you call the commit member function on the
+mutator. When you do that, all the changes you made are written into the
+store.
+
+Once the changes are written into the store, you will need to call the
+appropriate resolve function again to see the changes.
+
+Allocating a mutator is simple. To create a mutator for the default
+framework instance associated with the owner "owner1", just allocate the
+mutator on the stack. Be sure to call commit() before it goes out of
+scope or you’ll lose your changes.
+
+.. code:: cpp
+
+ {
+ opflex::modb::Mutator mutator("owner1");
+ // make changes here
+ mutator.commit();
+ }
+
+Note that if an exception is thrown while making changes but before
+committing, the mutator will go out of scope and the changes will be
+discarded.
+
+To create a new node, you must call the appropriate add[Child] member
+function on its parent. This function takes parameters for each of the
+naming properties for the object:
+
+.. code:: cpp
+
+ shared_ptr<simple::foo> newfoo(root->addFoo("test"));
+
+This will return a shared pointer to a new foo object that has been
+registered in the active mutator but not yet committed. The "bar" naming
+property will be set automatically, but if you want to set the "baz"
+property now, you can do so by calling:
+
+.. code:: cpp
+
+ newfoo->setBaz(42);
+
+Note that creating the root node requires a call to the special static
+class method createRootElement:
+
+.. code:: cpp
+
+ shared_ptr<simple::root> newroot(simple::root::createRootElement());
+
+Here’s a complete example that ties this all together:
+
+.. code:: cpp
+
+ {
+ opflex::modb::Mutator mutator("owner1");
+ shared_ptr<simple::root> newroot(simple::root::createRootElement());
+ shared_ptr<simple::root> newfoo(newroot->addFoo("test"));
+ newfoo->setBaz(42);
+
+ mutator.commit();
+ }
+
+Update Notifications
+~~~~~~~~~~~~~~~~~~~~
+
+When using the OpFlex framework, you’re likely to find that most of your
+time is spend responding to changes in the managed object database. To
+get these notifications, you’re going to need to register some number of
+listeners.
+
+You can register an object listener to see all changes related to a
+particular class by calling a static function for that class. You’ll
+then get notifications whenever any object in that class is added,
+updated, or deleted. The listener should queue a task to read the new
+state and perform appropriate processing. If this function blocks or
+peforms a long-running operation, then the dispatching of update
+notifications will be stalled, but there will not be any other
+deleterious effects.
+
+If multiple changes happen to the same URI, then at least one
+notification will be delivered but some events may be consolidated.
+
+The update you get will tell you the URI and the Class ID of the changed
+object. The class ID is a unique ID for each class. When you get the
+update, you’ll need to call the appropriate resolve function to retrieve
+the new value.
+
+You’ll need to create your own object listener derived from
+opflex::modb::ObjectListener:
+
+.. code:: cpp
+
+ class MyListener : public ObjectListener {
+ public:
+ MyListener() { }
+ virtual void objectUpdated(class_id_t class_id, const URI& uri) {
+ // Your handler here
+ }
+ };
+
+To register your listener with the default framework instance, just call
+the appropriate class static method:
+
+.. code:: cpp
+
+ MyListener listener;
+ simple::foo::registerListener(&listener);
+ // main loop
+ simple::foo::unregisterListener(&listener);
+
+The listener will now recieve notifications whenever any foo or any
+children of any foo object changes.
+
+Note that you must ensure that you unregister your listeners before
+deallocating them.
+
+API Reference Documentation
+---------------------------
+
+Complete API documentation can be found through doxygen here:
+https://jenkins.opendaylight.org/opflex/job/opflex-merge/ws/libopflex/doc/html/index.html
+
--- /dev/null
+SNMP4SDN Developer Guide
+========================
+
+Overview
+--------
+
+We propose a southbound plugin that can control the off-the-shelf
+commodity Ethernet switches for the purpose of building SDN using
+Ethernet switches. For Ethernet switches, forwarding table, VLAN table,
+and ACL are where one can install flow configuration on, and this is
+done via SNMP and CLI in the proposed plugin. In addition, some settings
+required for Ethernet switches in SDN, e.g., disabling STP and flooding,
+are proposed.
+
+.. figure:: ./images/snmp4sdn_in_odl_architecture.jpg
+ :alt: SNMP4SDN as an OpenDaylight southbound plugin
+
+ SNMP4SDN as an OpenDaylight southbound plugin
+
+Architecture
+------------
+
+The modules in the plugin are depicted as the following figure.
+
+.. figure:: ./images/snmp4sdn_modules.jpg
+ :alt: Modules in the SNMP4SDN Plugin
+
+ Modules in the SNMP4SDN Plugin
+
+- AclService: add/remove ACL profile and rule on the switches.
+
+- FdbService: add/modify/remove FDB table entry on the switches.
+
+- VlanService: add/modify/remove VLAN table entry on the switches.
+
+- TopologyService: query and acquire the subnet topology.
+
+- InventoryService: acquire the switches and their ports.
+
+- DiscoveryService: probe and resolve the underlying switches as well
+ as the port pairs connecting the switches. The probing is realized by
+ SNMP queries. The updates from discovery will also be reflected to
+ the TopologyService.
+
+- MiscConfigService: do kinds of settings on switches
+
+ - Supported STP and ARP settings such as enable/disable STP, get
+ port’s STP state, get ARP table, set ARP entry, and others
+
+- VendorSpecificHandler: to assist the flow configuration services to
+ call the switch-talking modules with correct parameters value and
+ order.
+
+- Switch-talking modules
+
+ - For the services above, when they need to read or configure the
+ underlying switches via SNMP or CLI, these queries are dealt with
+ the modules SNMPHandler and CLIHandler which directly talk with
+ the switches. The SNMPListener is to listen to snmp trap such as
+ link up/down event or switch on/off event.
+
+Design
+------
+
+In terms of the architecture of the SNMP4SDN Plugin’s features, the
+features include flow configuration, topology discovery, and
+multi-vendor support. Their architectures please refer to Wiki
+(`Developer Guide -
+Design <https://wiki.opendaylight.org/view/SNMP4SDN:Developer_Guide#Design>`__).
+
+Installation and Configuration Guide
+------------------------------------
+
+- Please refer to the *Getting Started Guide* in
+ https://www.opendaylight.org/downloads, find the SNMP4SDN section.
+
+- For the latest full guide, please refer to Wiki (`Installation
+ Guide <https://wiki.opendaylight.org/view/SNMP4SDN:Installation_Guide>`__,
+ `User Guide -
+ Configuration <https://wiki.opendaylight.org/view/SNMP4SDN:User_Guide#Configuration>`__).
+
+Tutorial
+--------
+
+- For the latest full guide, please refer to Wiki (`User Guide -
+ Tutorial <https://wiki.opendaylight.org/view/SNMP4SDN:User_Guide#Tutorial_.2F_How-To>`__).
+
+Programmatic Interface(s)
+-------------------------
+
+SNMP4SDN Plugin exposes APIs via MD-SAL with YANG model. The methods
+(RPC call) and data structures for them are listed below.
+
+TopologyService
+~~~~~~~~~~~~~~~
+
+- RPC call
+
+ - get-edge-list
+
+ - get-node-list
+
+ - get-node-connector-list
+
+ - set-discovery-interval (given interval time in seconds)
+
+ - rediscover
+
+- Data structure
+
+ - node: composed of node-id, node-type
+
+ - node-connector: composed of node-connector-id,
+ node-connector-type, node
+
+ - topo-edge: composed of head-node-connector-id,
+ head-node-connector-type, head-node-id, head-node-type,
+ tail-node-connector-id, tail-node-connector-type, tail-node-id,
+ tail-node-type
+
+VlanService
+~~~~~~~~~~~
+
+- RPC call
+
+ - add-vlan (given node ID, VLAN ID, VLAN name)
+
+ - add-vlan-and-set-ports (given node ID, VLAN ID, VLAN name, tagged
+ ports, untagged ports)
+
+ - set-vlan-ports (given node ID, VLAN ID, tagged ports, untagged
+ ports)
+
+ - delete-vlan (given node ID, VLAN ID)
+
+ - get-vlan-table (given node ID)
+
+AclService
+~~~~~~~~~~
+
+- RPC call
+
+ - create-acl-profile (given node ID, acl-profile-index, acl-profile)
+
+ - del-acl-profile (given node ID, acl-profile-index)
+
+ - set-acl-rule (given node ID, acl-index, acl-rule)
+
+ - del-acl-rule (given node ID, acl-index)
+
+ - clear-acl-table (given node ID)
+
+- Data structure
+
+ - acl-profile-index: composed of profile-id, profile name
+
+ - acl-profile: composed of acl-layer, vlan-mask, src-ip-mask,
+ dst-ip-mask
+
+ - acl-layer: IP or ETHERNET
+
+ - acl-index: composed of acl-profile-index, acl-rule-index
+
+ - acl-rule-index: composed of rule-id, rule-name
+
+ - acl-rule: composed of port-list, acl-layer, acl-field, acl-action
+
+ - acl-field: composed of vlan-id, src-ip, dst-ip
+
+ - acl-action: PERMIT or DENY
+
+FdbService
+~~~~~~~~~~
+
+- RPC call
+
+ - set-fdb-entry (given fdb-entry)
+
+ - del-fdb-entry (given node-id, vlan-id, dest-mac-adddr)
+
+ - get-fdb-entry (given node-id, vlan-id, dest-mac-adddr)
+
+ - get-fdb-table (given node-id)
+
+- Data structure
+
+ - fdb-entry: composed of node-id, vlan-id, dest-mac-addr, port,
+ fdb-entry-type
+
+ - fdb-entry-type: OTHER/INVALID/LEARNED/SELF/MGMT
+
+MiscConfigService
+~~~~~~~~~~~~~~~~~
+
+- RPC call
+
+ - set-stp-port-state (given node-id, port, is\_nable)
+
+ - get-stp-port-state (given node-id, port)
+
+ - get-stp-port-root (given node-id, port)
+
+ - enable-stp (given node-id)
+
+ - disable-stp (given node-id)
+
+ - delete-arp-entry (given node-id, ip-address)
+
+ - set-arp-entry (given node-id, arp-entry)
+
+ - get-arp-entry (given node-id, ip-address)
+
+ - get-arp-table (given node-id)
+
+- Data structure
+
+ - stp-port-state:
+ DISABLE/BLOCKING/LISTENING/LEARNING/FORWARDING/BROKEN
+
+ - arp-entry: composed of ip-address and mac-address
+
+SwitchDbService
+~~~~~~~~~~~~~~~
+
+- RPC call
+
+ - reload-db (The following 4 RPC implemention is TBD)
+
+ - add-switch-entry
+
+ - delete-switch-entry
+
+ - clear-db
+
+ - update-db
+
+- Data structure
+
+ - switch-info: compose of node-ip, node-mac, community,
+ cli-user-name, cli-password, model
+
+Help
+----
+
+- `SNMP4SDN Wiki <https://wiki.opendaylight.org/view/SNMP4SDN:Main>`__
+
+- SNMP4SDN Mailing List
+ (`user <https://lists.opendaylight.org/mailman/listinfo/snmp4sdn-users>`__,
+ `developer <https://lists.opendaylight.org/mailman/listinfo/snmp4sdn-dev>`__)
+
+- `Latest troubleshooting in
+ Wiki <https://wiki.opendaylight.org/view/SNMP4SDN:User_Guide#Troubleshooting>`__
+
--- /dev/null
+SXP Developer Guide
+===================
+
+Overview
+--------
+
+SXP (Source-Group Tag eXchange Protocol) project is an effort to enhance
+OpenDaylight platform with IP-SGT (IP Address to Source Group Tag)
+bindings that can be learned from connected SXP-aware network nodes. The
+current implementation supports SXP protocol version 4 according to the
+Smith, Kandula - SXP `IETF
+draft <https://tools.ietf.org/html/draft-smith-kandula-sxp-04>`__ and
+grouping of peers and creating filters based on ACL/Prefix-list syntax
+for filtering outbound and inbound IP-SGT bindings. All protocol legacy
+versions 1-3 are supported as well. Additionally, version 4 adds
+bidirectional connection type as an extension of a unidirectional one.
+
+SXP Architecture
+----------------
+
+The SXP Server manages all connected clients in separate threads and a
+common SXP protocol agreement is used between connected peers. Each SXP
+network peer is modelled with its pertaining class, e.g., SXP Server
+represents the SXP Speaker, SXP Listener the Client. The server program
+creates the ServerSocket object on a specified port and waits until a
+client starts up and requests connect on the IP address and port of the
+server. The client program opens a Socket that is connected to the
+server running on the specified host IP address and port.
+
+The SXP Listener maintains connection with its speaker peer. From an
+opened channel pipeline, all incoming SXP messages are processed by
+various handlers. Message must be decoded, parsed and validated.
+
+The SXP Speaker is a counterpart to the SXP Listener. It maintains a
+connection with its listener peer and sends composed messages.
+
+The SXP Binding Handler extracts the IP-SGT binding from a message and
+pulls it into the SXP-Database. If an error is detected during the
+IP-SGT extraction, an appropriate error code and sub-code is selected
+and an error message is sent back to the connected peer. All transitive
+messages are routed directly to the output queue of SXP Binding
+Dispatcher.
+
+The SXP Binding Dispatcher represents a selector that will decides how
+many data from the SXP-database will be sent and when. It is responsible
+for message content composition based on maximum message length.
+
+The SXP Binding Filters handles filtering of outgoing and incoming
+IP-SGT bindings according to BGP filtering using ACL and Prefix List
+syntax for specifying filter or based on Peer-sequence length.
+
+The SXP Domains feature provides isolation of SXP peers and bindings
+learned between them, also exchange of Bindings is possible across
+SXP-Domains by ACL, Prefix List or Peer-Sequence filters
+
+Key APIs and Interfaces
+-----------------------
+
+As this project is fairly small, it provides only few features that
+install and provide all APIs and implementations for this project.
+
+- sxp-controller
+
+- sxp-api
+
+- spx-core
+
+sxp-controller
+~~~~~~~~~~~~~~
+
+RPC request handling
+
+sxp-api
+~~~~~~~
+
+Contains data holders and entities
+
+spx-core
+~~~~~~~~
+
+Main logic and core features
+
+API Reference Documentation
+---------------------------
+
+`RESTCONF Interface and Dynamic
+Tree <https://wiki.opendaylight.org/images/9/91/SXP_Restconf_Interface_and_Dynamic_Tree.pdf>`__
+`Specification and
+Architecture <https://wiki.opendaylight.org/images/6/6e/SXP_Specification_and_Architecture_v03.pdf>`__
+
--- /dev/null
+TTP CLI Tools Developer Guide
+=============================
+
+Overview
+--------
+
+Table Type Patterns are a specification developed by the `Open
+Networking Foundation <https://www.opennetworking.org/>`__ to enable the
+description and negotiation of subsets of the OpenFlow protocol. This is
+particularly useful for hardware switches that support OpenFlow as it
+enables the to describe what features they do (and thus also what
+features they do not) support. More details can be found in the full
+specification listed on the `OpenFlow specifications
+page <https://www.opennetworking.org/sdn-resources/onf-specifications/openflow>`__.
+
+The TTP CLI Tools provide a way for people interested in TTPs to read
+in, validate, output, and manipulate TTPs as a self-contained,
+executable jar file.
+
+TTP CLI Tools Architecture
+--------------------------
+
+The TTP CLI Tools use the TTP Model and the YANG Tools/RESTCONF codecs
+to translate between the Data Transfer Objects (DTOs) and JSON/XML.
+
+Command Line Options
+--------------------
+
+This will cover the various options for the CLI Tools. For now, there
+are no options and it merely outputs fixed data using the codecs.
+
--- /dev/null
+TTP Model Developer Guide
+=========================
+
+Overview
+--------
+
+Table Type Patterns are a specification developed by the `Open
+Networking Foundation <https://www.opennetworking.org/>`__ to enable the
+description and negotiation of subsets of the OpenFlow protocol. This is
+particularly useful for hardware switches that support OpenFlow as it
+enables the to describe what features they do (and thus also what
+features they do not) support. More details can be found in the full
+specification listed on the `OpenFlow specifications
+page <https://www.opennetworking.org/sdn-resources/onf-specifications/openflow>`__.
+
+TTP Model Architecture
+----------------------
+
+The TTP Model provides a YANG-modeled type for a TTP and allows them to
+be associated with a master list of known TTPs, as well as active and
+supported TTPs with nodes in the MD-SAL inventory model.
+
+Key APIs and Interfaces
+-----------------------
+
+The key API provided by the TTP Model feature is the ability to store a
+set of TTPs in the MD-SAL as well as associate zero or one active TTPs
+and zero or more supported TTPs along with a given node in the MD-SAL
+inventory model.
+
+API Reference Documentation
+---------------------------
+
+RESTCONF
+~~~~~~~~
+
+See the generated RESTCONF API documentation at:
+http://localhost:8181/apidoc/explorer/index.html
+
+Look for the onf-ttp module to expand and see the various RESTCONF APIs.
+
+Java Bindings
+~~~~~~~~~~~~~
+
+As stated above there are 3 locations where a Table Type Pattern can be
+placed into the MD-SAL Data Store. They correspond to 3 different REST
+API URIs:
+
+1. ``restconf/config/onf-ttp:opendaylight-ttps/onf-ttp:table-type-patterns/``
+
+2. ``restconf/config/opendaylight-inventory:nodes/node/{id}/ttp-inventory-node:active_ttp/``
+
+3. ``restconf/config/opendaylight-inventory:nodes/node/{id}/ttp-inventory-node:supported_ttps/``
+
+.. note::
+
+ Typically, these URIs are running on the machine the controller is
+ on at port 8181. If you are on the same machine they can thus be
+ accessed at ``http://localhost:8181/<uri>``
+
+Using the TTP Model RESTCONF APIs
+---------------------------------
+
+Setting REST HTTP Headers
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Authentication
+^^^^^^^^^^^^^^
+
+The REST API calls require authentication by default. The default method
+is to use basic auth with a user name and password of ‘admin’.
+
+Content-Type and Accept
+^^^^^^^^^^^^^^^^^^^^^^^
+
+RESTCONF supports both xml and json. This example focuses on JSON, but
+xml can be used just as easily. When doing a PUT or POST be sure to
+specify the appropriate ``Conetnt-Type`` header: either
+``application/json`` or ``application/xml``.
+
+When doing a GET be sure to specify the appropriate ``Accept`` header:
+again, either ``application/json`` or ``application/xml``.
+
+Content
+~~~~~~~
+
+The contents of a PUT or POST should be a OpenDaylight Table Type
+Pattern. An example of one is provided below. The example can also be
+found at ```parser/sample-TTP-from-tests.ttp`` in the TTP git
+repository <https://git.opendaylight.org/gerrit/gitweb?p=ttp.git;a=blob;f=parser/sample-TTP-from-tests.ttp;h=45130949b25c6f86b750959d27d04ec2208935fb;hb=HEAD>`__.
+
+**Sample Table Type Pattern (json).**
+
+::
+
+ {
+ "table-type-patterns": {
+ "table-type-pattern": [
+ {
+ "security": {
+ "doc": [
+ "This TTP is not published for use by ONF. It is an example and for",
+ "illustrative purposes only.",
+ "If this TTP were published for use it would include",
+ "guidance as to any security considerations in this doc member."
+ ]
+ },
+ "NDM_metadata": {
+ "authority": "org.opennetworking.fawg",
+ "OF_protocol_version": "1.3.3",
+ "version": "1.0.0",
+ "type": "TTPv1",
+ "doc": [
+ "Example of a TTP supporting L2 (unicast, multicast, flooding), L3 (unicast only),",
+ "and an ACL table."
+ ],
+ "name": "L2-L3-ACLs"
+ },
+ "identifiers": [
+ {
+ "doc": [
+ "The VLAN ID of a locally attached L2 subnet on a Router."
+ ],
+ "var": "<subnet_VID>"
+ },
+ {
+ "doc": [
+ "An OpenFlow group identifier (integer) identifying a group table entry",
+ "of the type indicated by the variable name"
+ ],
+ "var": "<<group_entry_types/name>>"
+ }
+ ],
+ "features": [
+ {
+ "doc": [
+ "Flow entry notification Extension – notification of changes in flow entries"
+ ],
+ "feature": "ext187"
+ },
+ {
+ "doc": [
+ "Group notifications Extension – notification of changes in group or meter entries"
+ ],
+ "feature": "ext235"
+ }
+ ],
+ "meter_table": {
+ "meter_types": [
+ {
+ "name": "ControllerMeterType",
+ "bands": [
+ {
+ "type": "DROP",
+ "rate": "1000..10000",
+ "burst": "50..200"
+ }
+ ]
+ },
+ {
+ "name": "TrafficMeter",
+ "bands": [
+ {
+ "type": "DSCP_REMARK",
+ "rate": "10000..500000",
+ "burst": "50..500"
+ },
+ {
+ "type": "DROP",
+ "rate": "10000..500000",
+ "burst": "50..500"
+ }
+ ]
+ }
+ ],
+ "built_in_meters": [
+ {
+ "name": "ControllerMeter",
+ "meter_id": 1,
+ "type": "ControllerMeterType",
+ "bands": [
+ {
+ "rate": 2000,
+ "burst": 75
+ }
+ ]
+ },
+ {
+ "name": "AllArpMeter",
+ "meter_id": 2,
+ "type": "ControllerMeterType",
+ "bands": [
+ {
+ "rate": 1000,
+ "burst": 50
+ }
+ ]
+ }
+ ]
+ },
+ "table_map": [
+ {
+ "name": "ControlFrame",
+ "number": 0
+ },
+ {
+ "name": "IngressVLAN",
+ "number": 10
+ },
+ {
+ "name": "MacLearning",
+ "number": 20
+ },
+ {
+ "name": "ACL",
+ "number": 30
+ },
+ {
+ "name": "L2",
+ "number": 40
+ },
+ {
+ "name": "ProtoFilter",
+ "number": 50
+ },
+ {
+ "name": "IPv4",
+ "number": 60
+ },
+ {
+ "name": "IPv6",
+ "number": 80
+ }
+ ],
+ "parameters": [
+ {
+ "doc": [
+ "documentation"
+ ],
+ "name": "Showing-curt-how-this-works",
+ "type": "type1"
+ }
+ ],
+ "flow_tables": [
+ {
+ "doc": [
+ "Filters L2 control reserved destination addresses and",
+ "may forward control packets to the controller.",
+ "Directs all other packets to the Ingress VLAN table."
+ ],
+ "name": "ControlFrame",
+ "flow_mod_types": [
+ {
+ "doc": [
+ "This match/action pair allows for flow_mods that match on either",
+ "ETH_TYPE or ETH_DST (or both) and send the packet to the",
+ "controller, subject to metering."
+ ],
+ "name": "Frame-To-Controller",
+ "match_set": [
+ {
+ "field": "ETH_TYPE",
+ "match_type": "all_or_exact"
+ },
+ {
+ "field": "ETH_DST",
+ "match_type": "exact"
+ }
+ ],
+ "instruction_set": [
+ {
+ "doc": [
+ "This meter may be used to limit the rate of PACKET_IN frames",
+ "sent to the controller"
+ ],
+ "instruction": "METER",
+ "meter_name": "ControllerMeter"
+ },
+ {
+ "instruction": "APPLY_ACTIONS",
+ "actions": [
+ {
+ "action": "OUTPUT",
+ "port": "CONTROLLER"
+ }
+ ]
+ }
+ ]
+ }
+ ],
+ "built_in_flow_mods": [
+ {
+ "doc": [
+ "Mandatory filtering of control frames with C-VLAN Bridge reserved DA."
+ ],
+ "name": "Control-Frame-Filter",
+ "priority": "1",
+ "match_set": [
+ {
+ "field": "ETH_DST",
+ "mask": "0xfffffffffff0",
+ "value": "0x0180C2000000"
+ }
+ ]
+ },
+ {
+ "doc": [
+ "Mandatory miss flow_mod, sends packets to IngressVLAN table."
+ ],
+ "name": "Non-Control-Frame",
+ "priority": "0",
+ "instruction_set": [
+ {
+ "instruction": "GOTO_TABLE",
+ "table": "IngressVLAN"
+ }
+ ]
+ }
+ ]
+ }
+ ],
+ "group_entry_types": [
+ {
+ "doc": [
+ "Output to a port, removing VLAN tag if needed.",
+ "Entry per port, plus entry per untagged VID per port."
+ ],
+ "name": "EgressPort",
+ "group_type": "INDIRECT",
+ "bucket_types": [
+ {
+ "name": "OutputTagged",
+ "action_set": [
+ {
+ "action": "OUTPUT",
+ "port": "<port_no>"
+ }
+ ]
+ },
+ {
+ "name": "OutputUntagged",
+ "action_set": [
+ {
+ "action": "POP_VLAN"
+ },
+ {
+ "action": "OUTPUT",
+ "port": "<port_no>"
+ }
+ ]
+ },
+ {
+ "opt_tag": "VID-X",
+ "name": "OutputVIDTranslate",
+ "action_set": [
+ {
+ "action": "SET_FIELD",
+ "field": "VLAN_VID",
+ "value": "<local_vid>"
+ },
+ {
+ "action": "OUTPUT",
+ "port": "<port_no>"
+ }
+ ]
+ }
+ ]
+ }
+ ],
+ "flow_paths": [
+ {
+ "doc": [
+ "This object contains just a few examples of flow paths, it is not",
+ "a comprehensive list of the flow paths required for this TTP. It is",
+ "intended that the flow paths array could include either a list of",
+ "required flow paths or a list of specific flow paths that are not",
+ "required (whichever is more concise or more useful."
+ ],
+ "name": "L2-2",
+ "path": [
+ "Non-Control-Frame",
+ "IV-pass",
+ "Known-MAC",
+ "ACLskip",
+ "L2-Unicast",
+ "EgressPort"
+ ]
+ },
+ {
+ "name": "L2-3",
+ "path": [
+ "Non-Control-Frame",
+ "IV-pass",
+ "Known-MAC",
+ "ACLskip",
+ "L2-Multicast",
+ "L2Mcast",
+ "[EgressPort]"
+ ]
+ },
+ {
+ "name": "L2-4",
+ "path": [
+ "Non-Control-Frame",
+ "IV-pass",
+ "Known-MAC",
+ "ACL-skip",
+ "VID-flood",
+ "VIDflood",
+ "[EgressPort]"
+ ]
+ },
+ {
+ "name": "L2-5",
+ "path": [
+ "Non-Control-Frame",
+ "IV-pass",
+ "Known-MAC",
+ "ACLskip",
+ "L2-Drop"
+ ]
+ },
+ {
+ "name": "v4-1",
+ "path": [
+ "Non-Control-Frame",
+ "IV-pass",
+ "Known-MAC",
+ "ACLskip",
+ "L2-Router-MAC",
+ "IPv4",
+ "v4-Unicast",
+ "NextHop",
+ "EgressPort"
+ ]
+ },
+ {
+ "name": "v4-2",
+ "path": [
+ "Non-Control-Frame",
+ "IV-pass",
+ "Known-MAC",
+ "ACLskip",
+ "L2-Router-MAC",
+ "IPv4",
+ "v4-Unicast-ECMP",
+ "L3ECMP",
+ "NextHop",
+ "EgressPort"
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ }
+
+Making a REST Call
+~~~~~~~~~~~~~~~~~~
+
+In this example we’ll do a PUT to install the sample TTP from above into
+OpenDaylight and then retrieve it both as json and as xml. We’ll use the
+`Postman - REST
+Client <https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm>`__
+for Chrome in the examples, but any method of accessing REST should
+work.
+
+First, we’ll fill in the basic information:
+
+.. figure:: ./images/ttp-screen1-basic-auth.png
+ :alt: Filling in URL, content, Content-Type and basic auth
+
+ Filling in URL, content, Content-Type and basic auth
+
+1. Set the URL to
+ ``http://localhost:8181/restconf/config/onf-ttp:opendaylight-ttps/onf-ttp:table-type-patterns/``
+
+2. Set the action to ``PUT``
+
+3. Click Headers and
+
+4. Set a header for ``Content-Type`` to ``application/json``
+
+5. Make sure the content is set to raw and
+
+6. Copy the sample TTP from above into the content
+
+7. Click the Basic Auth tab and
+
+8. Set the username and password to admin
+
+9. Click Refresh headers
+
+.. figure:: ./images/ttp-screen2-applied-basic-auth.png
+ :alt: Refreshing basic auth headers
+
+ Refreshing basic auth headers
+
+After clicking Refresh headers, we can see that a new header
+(``Authorization``) has been created and this will allow us to
+authenticate to make the REST call.
+
+.. figure:: ./images/ttp-screen3-sent-put.png
+ :alt: PUTting a TTP
+
+ PUTting a TTP
+
+At this point, clicking send should result in a Status response of ``200
+OK`` indicating we’ve successfully PUT the TTP into OpenDaylight.
+
+.. figure:: ./images/ttp-screen4-get-json.png
+ :alt: Retrieving the TTP as json via a GET
+
+ Retrieving the TTP as json via a GET
+
+We can now retrieve the TTP by:
+
+1. Changing the action to ``GET``
+
+2. Setting an ``Accept`` header to ``application/json`` and
+
+3. Pressing send
+
+.. figure:: ./images/ttp-screen5-get-xml.png
+ :alt: Retrieving the TTP as xml via a GET
+
+ Retrieving the TTP as xml via a GET
+
+The same process can retrieve the content as xml by setting the
+``Accept`` header to ``application/xml``.
+
--- /dev/null
+Virtual Tenant Network (VTN)
+============================
+
+OpenDaylight Virtual Tenant Network (VTN) Overview
+--------------------------------------------------
+
+OpenDaylight Virtual Tenant Network (VTN) is an application that
+provides multi-tenant virtual network on an SDN controller.
+
+Conventionally, huge investment in the network systems and operating
+expenses are needed because the network is configured as a silo for each
+department and system. Therefore various network appliances must be
+installed for each tenant and those boxes cannot be shared with others.
+It is a heavy work to design, implement and operate the entire complex
+network.
+
+The uniqueness of VTN is a logical abstraction plane. This enables the
+complete separation of logical plane from physical plane. Users can
+design and deploy any desired network without knowing the physical
+network topology or bandwidth restrictions.
+
+VTN allows the users to define the network with a look and feel of
+conventional L2/L3 network. Once the network is designed on VTN, it will
+automatically be mapped into underlying physical network, and then
+configured on the individual switch leverage SDN control protocol. The
+definition of logical plane makes it possible not only to hide the
+complexity of the underlying network but also to better manage network
+resources. It achieves reducing reconfiguration time of network services
+and minimizing network configuration errors. OpenDaylight Virtual Tenant
+Network (VTN) is an application that provides multi-tenant virtual
+network on an SDN controller. It provides API for creating a common
+virtual network irrespective of the physical network.
+
+.. figure:: ./images/vtn/vtn-overview.png
+ :alt: VTN Architecture
+
+ VTN Architecture
+
+It is implemented as two major components
+
+- `VTN Manager <#_vtn_manager>`__
+
+- `VTN Coordinator <#_vtn_coordinator>`__
+
+VTN Manager
+~~~~~~~~~~~
+
+An OpenDaylight Plugin that interacts with other modules to implement
+the components of the VTN model. It also provides a REST interface to
+configure VTN components in OpenDaylight. VTN Manager is implemented as
+one plugin to the OpenDaylight. This provides a REST interface to
+create/update/delete VTN components. The user command in VTN Coordinator
+is translated as REST API to VTN Manager by the OpenDaylight Driver
+component. In addition to the above mentioned role, it also provides an
+implementation to the OpenStack L2 Network Functions API.
+
+Function Outline
+^^^^^^^^^^^^^^^^
+
+The table identifies the functions and the interface used by VTN
+Components:
+
++--------------------------+--------------------------+--------------------------+
+| Component | Interface | Purpose |
++==========================+==========================+==========================+
+| VTN Manager | RESTful API | Configure VTN |
+| | | Virtualization model |
+| | | components in |
+| | | OpenDaylight |
++--------------------------+--------------------------+--------------------------+
+| VTN Manager | Neutron API | Handle Networks API from |
+| | implementation | OpenStack (Neutron |
+| | | Interface) |
++--------------------------+--------------------------+--------------------------+
+| VTN Coordinator | RESTful API | (1) Uses the RESTful |
+| | | interface of VTN |
+| | | Manager and configures |
+| | | VTN Virtualization |
+| | | model components in |
+| | | OpenDaylight. |
+| | | (2) Handles multiple |
+| | | OpenDaylight |
+| | | orchestration. |
+| | | (3) Provides API to |
+| | | read the physical |
+| | | network details. See |
+| | | `samples <https://wiki |
+| | | .OpenDaylight.org/view/O |
+| | | penDaylight_Virtual_Tena |
+| | | nt_Network_(VTN):VTN_Coo |
+| | | rdinator:RestApi:L2_Netw |
+| | | ork_Example_Using_VTN_Vi |
+| | | rtualization>`__ |
+| | | for usage. |
++--------------------------+--------------------------+--------------------------+
+
+Feature Overview
+^^^^^^^^^^^^^^^^
+
+There are three features
+
+- **odl-vtn-manager** provides VTN Manager’s JAVA API.
+
+- **odl-vtn-manager-rest** provides VTN Manager’s REST API.
+
+- **odl-vtn-manager-neutron** provides the integration with Neutron
+ interface.
+
+REST API documentation for VTN Manager, please refer to:
+https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/
+
+For VTN Java API documentation, please refer to:
+https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/target/apidocs/index.html
+
+Once the Karaf distribution is up, install dlux and apidocs.
+
+::
+
+ feature:install odl-dlux-all odl-mdsal-apidocs
+
+Logging In
+''''''''''
+
+To Log in to DLUX, after installing the application:
+
+- Open a browser and enter the login URL as
+ `http://<OpenDaylight-IP>:8181/index.html <http://<OpenDaylight-IP>:8181/index.html>`__.
+
+.. note::
+
+ Replace "<OpenDaylight-IP>" with the IP address of OpenDaylight
+ based on your environment.
+
+- Login to the application with user ID and password credentials as
+ admin.
+
+.. note::
+
+ admin is the only default user available for DLUX in this release.
+
+- In the right hand side frame, click "Yang UI".
+
+YANG documentation for VTN Manager, please refer to:
+https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/
+
+VTN Coordinator
+~~~~~~~~~~~~~~~
+
+The VTN Coordinator is an external application that provides a REST
+interface for an user to use OpenDaylight VTN Virtualization. It
+interacts with the VTN Manager plugin to implement the user
+configuration. It is also capable of multiple OpenDaylight
+orchestration. It realizes VTN provisioning in OpenDaylight instances.
+In the OpenDaylight architecture VTN Coordinator is part of the network
+application, orchestration and services layer. VTN Coordinator will use
+the REST interface exposed by the VTN Manger to realize the virtual
+network using OpenDaylight. It uses OpenDaylight APIs (REST) to
+construct the virtual network in OpenDaylight instances. It provides
+REST APIs for northbound VTN applications and supports virtual networks
+spanning across multiple OpenDaylight by coordinating across
+OpenDaylight.
+
+VTN Coordinator Components:
+
+- Transaction Coordinator
+
+- Unified Provider Physical Layer (UPPL)
+
+- Unified Provider Logical LAyer (UPLL)
+
+- OpenDaylight Controller Diver (ODC Driver)
+
+OpenDaylight Virtual Tenant Network (VTN) API Overview
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The VTN API module is a sub component of the VTN Coordinator and
+provides the northbound REST API interface for VTN applications. It
+consists of two subcomponents:
+
+- Web Server
+
+- VTN service Java API Library
+
+.. figure:: ./images/vtn/vtn-coordinator-api-architecture.png
+ :alt: VTN-Coordinator\_api-architechture
+
+ VTN-Coordinator\_api-architechture
+
+Web Server
+''''''''''
+
+The Web Server module handles the REST APIs received from the VTN
+applications. It translates the REST APIs to the appropriate Java APIs.
+
+The main functions of this module are:
+
+- Starts via the startup script ``catalina.sh``.
+
+- VTN Application sends HTTP request to Web server in XML or JSON
+ format.
+
+- Creates a session and acquire a read/write lock.
+
+- Invokes the VTN Service Java API Library corresponding to the
+ specified URI.
+
+- Returns the response to the VTN Application.
+
+WebServer Class Details
+'''''''''''''''''''''''
+
+The list below shows the classes available for Web Server module and
+their descriptions:
+
+Init Manager
+ It is a singleton class for executing the acquisition of
+ configuration information from properties file, log initialization,
+ initialization of VTN Service Java API Library. Executed by init()
+ of VtnServiceWebAPIServlet.
+
+Configuration Manager
+ Maintains the configuration information acquired from properties
+ file.
+
+VtnServiceCommonUtil
+ Utility class
+
+VtnServiceWebUtil
+ Utility class
+
+VtnServiceWebAPIServlet
+ Receives HTTP request from VTN Application and calls the method of
+ corresponding VtnServiceWebAPIHandler. herits class HttpServlet, and
+ overrides doGet(), doPut(), doDelete(), doPost().
+
+VtnServiceWebAPIHandler
+ Creates JsonObject(com.google.gson) from HTTP request, and calls
+ method of corresponding VtnServiceWebAPIController.
+
+VtnServiceWebAPIController
+ Creates RestResource() class and calls UPLL API/UPPL API through
+ Java API. the time of calling UPLL API/UPPL API, performs the
+ creation/deletion of session, acquisition/release of configuration
+ mode, acquisition/release of read lock by TC API through Java API.
+
+Data Converter
+ Converts HTTP request to JsonObject and JsonXML to JSON.
+
+VTN Service Java API Library
+''''''''''''''''''''''''''''
+
+It provides the Java API library to communicate with the lower layer
+modules in the VTN Coordinator. The main functions of this library are:
+
+- Creates an IPC client session to the lower layer.
+
+- Converts the request to IPC framework format.
+
+- Invokes the lower layer API (i.e. UPPL API, UPLL API, TC API).
+
+- Returns the response from the lower layer to the web server
+
+- VTN Service Java API Library Class Details
+
+Feature Overview
+^^^^^^^^^^^^^^^^
+
+VTN Coordinator doesn’t have Karaf features.
+
+For VTN Coordinator REST API, please refer to:
+https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Coordinator:RestApi
+
+Usage Examples
+~~~~~~~~~~~~~~
+
+- `L2 Network using Single
+ Controller <https://wiki.OpenDaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Coordinator:RestApi:How_to_configure_L2_Network_with_Single_Controller>`__
+
--- /dev/null
+############
+Gerrit Guide
+############
+
+How to push to Gerrit
+=====================
+
+It is highly recommended to use ssh to push to Gerrit to push code to Gerrit.
+In the event that you cannot use ssh such as corporate firewall blocking you
+then falling back to pushing via https should work.
+
+Using ssh to push to Gerrit
+---------------------------
+
+# TODO
+
+Using https to push to Gerrit
+-----------------------------
+
+Gerrit does not allow you to use your regular account credentials when pushing
+via https. Instead it requires you to first generate a http password via the
+Web U and use that as the password when pushing via https.
+
+.. figure:: images/gerrit-https-password-setup.png
+
+ Setting up an https password to push using https instead of ssh.
+
+To do this:
+
+1. navigate to https://git.opendaylight.org/gerrit/#/settings/http-password
+ (Steps 1, 2 and 3 in the image above.)
+2. click the **Generate Password** button.
+
+Gerrit will then generate a random password which you will need to use as your
+password when using git to push code to Gerrit via https.
+
+Signing Gerrit Commits
+======================
+
+1. Generate your GPG key.
+
+ The following instructions work on a Mac, but the general approach
+ should be the same on other OSes.
+
+ .. code-block:: bash
+
+ brew install gpg2 # if you don't have homebrew, get that here: http://brew.sh/
+ gpg2 --gen-key
+ # pick 1 for "RSA and RSA"
+ # enter 4096 to creat a 4096-bit key
+ # enter an expiration time, I picked 2y for 2 years
+ # enter y to accept the expiration time
+ # pick O or Q to accept your name/email/comment
+ # enter a pass phrase twice. it seems like backspace doesn't work, so type carefully
+ gpg2 --fingerprint
+ # you'll get something like this:
+ # spectre:~ ckd$ gpg2 --fingerprint
+ # /Users/ckd/.gnupg/pubring.gpg
+ # -----------------------------
+ # pub 4096R/F566C9B1 2015-04-06 [expires: 2017-04-05]
+ # Key fingerprint = 7C37 02AC D651 1FA7 9209 48D3 5DD5 0C4B F566 C9B1
+ # uid [ultimate] Colin Dixon <colin at colindixon.com>
+ # sub 4096R/DC1497E1 2015-04-06 [expires: 2017-04-05]
+ # you're looking for the part after 4096R, which is your key ID
+ gpg2 --send-keys <key-id>
+ # in the above example, the key-id would be F566C9B1
+ # you should see output like this:
+ # gpg: sending key F566C9B1 to hkp server keys.gnupg.net
+
+ If you're trying to participate in an OpenDaylight keysigning, then
+ send the output of ``gpg2 --fingerprint <key-id>`` to
+ keysigning@opendaylight.org
+
+ .. code-block:: bash
+
+ gpg2 --fingerprint <key-id>
+ # in the above example, the key-id would be F566C9B1
+ # in my case, the output was:
+ # pub 4096R/F566C9B1 2015-04-06 [expires: 2017-04-05]
+ # Key fingerprint = 7C37 02AC D651 1FA7 9209 48D3 5DD5 0C4B F566 C9B1
+ # uid [ultimate] Colin Dixon <colin at colindixon.com>
+ # sub 4096R/DC1497E1 2015-04-06 [expires: 2017-04-05]
+
+2. Install gpg, instead of or addition to gpg2. It appears as though
+ gpg2 has annoying things that it does when asking for your
+ passphrase, which I haven't debugged yet.
+
+ .. note:: you can tell git to use gpg by doing:
+ ``git config --global gpg.program gpg2``
+ but that then will seem to struggle asking for your
+ passphrase unless you have your gpg-agent set up right.
+
+3. Add you GPG to Gerrit
+
+ a. Run the following at the CLI:
+
+ .. code-block:: bash
+
+ gpg --export -a <fingerprint>
+ # e.g., gpg --export -a F566C9B1
+ # in my case the output looked like:
+ # -----BEGIN PGP PUBLIC KEY BLOCK-----
+ # Version: GnuPG v2
+ #
+ # mQINBFUisGABEAC/DkcjNUhxQkRLdfbfdlq9NlfDusWri0cXLVz4YN1cTUTF5HiW
+ # ...
+ # gJT+FwDvCGgaE+JGlmXgjv0WSd4f9cNXkgYqfb6mpji0F3TF2HXXiVPqbwJ1V3I2
+ # NA+l+/koCW0aMReK
+ # =A/ql
+ # -----END PGP PUBLIC KEY BLOCK-----
+
+ b. Browse to https://git.opendaylight.org/gerrit/#/settings/gpg-keys
+ c. Click Add Key...
+ d. Copy the output from the above command, paste it into the box,
+ and click Add
+
+3. Set up your git to sign commits and push signatures
+
+ .. code-block:: bash
+
+ git config commit.gpgsign true
+ git config push.gpgsign true
+ git config user.signingkey <fingerprint>
+ # e.g., git config user.signingkey F566C9B1
+
+ .. note:: you can do this instead with ``git commit -S``
+ You can use ``git commit -S`` and ``git push --signed``
+ on the CLI instead of configuring it in config if you
+ want to control which commits use your signature.
+
+4. Commit and push a change
+
+ a. change a file
+ b. ``git commit -asm "test commit"``
+
+ .. note:: this should result in git asking you for your passphrase
+
+ c. ``git review``
+
+ .. note:: this should result in git asking you for your passphrase
+
+ .. note:: annoyingly, the presence of a gpgp signature or pushing
+ of a gpg signature isn't recognized as a "change" by
+ Gerrit, so if you forget to do either, you need to change
+ something about the commit to get Gerrit to accept the
+ patch again. Slightly tweaking the commit message is a
+ good way.
+
+ .. note:: this assumes you have git review set up and push.gpgsign
+ set to true. Otherwise:
+
+ ``git push --signed gerrit HEAD:refs/for/master``
+
+ .. note:: this assumes you have your gerrit remote set up, if
+ not it's something like:
+ ``ssh://ckd@git.opendaylight.org:29418/<repo>.git``
+ where repo is something like docs or controller
+
+5. Verify that your commit is signed by going to the change in Gerrit
+ and checking for a green check (instead of a blue ?) next to your
+ name.
+
+
+Setting up gpg-agent on a Mac
+-----------------------------
+
+#. Install ``gpg-agent`` and ``pinentry-mac`` using ``brew``::
+
+ brew install gpg-agent pinentry-mac
+
+#. Edit your ``~/.gnupg/gpg.conf`` contain the line::
+
+ use-agent
+
+#. Edit your ``~/.gnupg/gpg-agent.conf`` to something like::
+
+ use-standard-socket
+ enable-ssh-support
+ default-cache-ttl 600
+ max-cache-ttl 7200
+ pinentry-program /usr/local/bin/pinentry-mac
+
+#. Edit your ``.bash_profile`` or equivalent file to contain the
+ following:
+
+ .. code-block:: bash
+
+ [ -f ~/.gpg-agent-info ] && source ~/.gpg-agent-info
+ if [ -S "${GPG_AGENT_INFO%%:*}" ]; then
+ export GPG_AGENT_INFO
+ else
+ eval $( gpg-agent --daemon --write-env-file ~/.gpg-agent-info )
+ fi
+
+#. Kill any stray ``gpg-agent`` daemons running::
+
+ sudo killall gpg-agent
+
+#. Restart your terminal (or log in and out) to reload the your
+ ``.bash_profile`` or equivalent file
+
+#. The next time a git operation makes a call to gpg, it should use
+ your gpg-agent to run a GUI window to ask for your passphrase and
+ give you an option to save your passphrase in the keychain.
+
+ .. image:: images/pinentry-mac.png
:maxdepth: 1
getting-started-guide/index
+ user-guide/index
opendaylight-with-openstack/index
.. toctree::
:maxdepth: 1
+ gerrit
submodules/releng/builder/docs/index
submodules/integration/test/docs/index
documentation
-Subproject commit b8410b1299b7ee1e1b843850a558e68609575fa1
+Subproject commit ed4e7da6063fbc492aaa62738343a75d98107ae3
-Subproject commit 3a464941f84541fb3193c92cff6b8c5fcf80808f
+Subproject commit 0cfec26d58c8865d3ff5bc1f07f996ec60861a41
-Subproject commit e714b02ea6f1ab2adc04140dfe8d5a6a75462268
+Subproject commit 0c3d83c27a9de0177536d70dd0aeecbf2d0c701c
-Subproject commit 8fb9f39b806b94c392c4bb5b7c23826198000498
+Subproject commit d025b89521d1c4e3673704a3fa9d7f7847c48bd3
--- /dev/null
+Atrium User Guide
+=================
+
+Overview
+--------
+
+Project Atrium is an open source SDN distribution - a vertically
+integrated set of open source components which together form a complete
+SDN stack. It’s goals are threefold:
+
+- Close the large integration-gap of the elements that are needed to
+ build an SDN stack - while there are multiple choices at each layer,
+ there are missing pieces with poor or no integration.
+
+- Overcome a massive gap in interoperability - This exists both at the
+ switch level, where existing products from different vendors have
+ limited compatibility, making it difficult to connect an arbitrary
+ switch and controller and at an API level, where its difficult to
+ write a portable application across multiple controller platforms.
+
+- Work closely with network operators on deployable use-cases, so that
+ they could download near production quality code from one location,
+ and get started with functioning software defined networks on real
+ hardware.
+
+Architecture
+------------
+
+The key components of Atrium BGP Peering Router Application are as
+follows:
+
+- Data Plane Switch - Data plane switch is the entity that uses flow
+ table entries installed by BGP Routing Application through SDN
+ controller. In the simplest form data plane switch with the installed
+ flows act like a BGP Router.
+
+- OpenDaylight Controller - OpenDaylight SDN controller has many
+ utility applications or plugins which are leveraged by the BGP Router
+ application to manage the control plane information.
+
+- BGP Routing Application - An application running within the
+ OpenDaylight runtime environment to handle I-BGP updates.
+
+- `DIDM <#_didm_user_guide>`__ - DIDM manages the drivers specific to
+ each data plane switch connected to the controller. The drivers are
+ created primarily to hide the underlying complexity of the devices
+ and to expose a uniform API to applications.
+
+- Flow Objectives API - The driver implementation provides a pipeline
+ abstraction and exposes Flow Objectives API. This means applications
+ need to be aware of only the Flow Objectives API without worrying
+ about the Table IDs or the pipelines.
+
+- Control Plane Switch - This component is primarily used to connect
+ the OpenDaylight SDN controller with the Quagga Soft-Router and
+ establish a path for forwarding E-BGP packets to and from Quagga.
+
+- Quagga soft router - An open source routing software that handles
+ E-BGP updates.
+
+Running Atrium
+--------------
+
+- To run the Atrium BGP Routing Application in OpenDaylight
+ distribution, simply install the ``odl-atrium-all`` feature.
+
+ ::
+
+ feature:install odl-atrium-all
+
--- /dev/null
+OpenDaylight User Guide
+=======================
+
+Overview
+--------
+
+This first part of the user guide covers the basic user operations of
+the OpenDaylight Release using the generic base functionality.
+
+.. toctree::
+ :maxdepth: 1
+
+ opendaylight-controller-overview
+ using-the-opendaylight-user-interface-(dlux)
+ running-xsql-console-commands-and-queries
+ ../getting-started-guide/common-features/clustering.rst
+
+Project-specific User Guides
+----------------------------
+
+.. toctree::
+ :maxdepth: 1
+
+ alto-user-guide
+ authentication-and-authorization-services
+ atrium-user-guide
+ bgp-user-guide
+ bgp-monitoring-protocol-user-guide
+ capwap-user-guide
+ cardinal_-opendaylight-monitoring-as-a-service
+ centinel-user-guide
+ didm-user-guide
+ group-based-policy-user-guide
+ l2switch-user-guide
+ l3vpn-service_-user-guide
+ link-aggregation-control-protocol-user-guide
+ lisp-flow-mapping-user-guide
+ network-modeling-(nemo)
+ netconf-user-guide
+ netide-user-guide
+ neutron-service-user-guide
+ network-intent-composition-(nic)-user-guide
+ ocp-plugin-user-guide
+ odl-sdni-user-guide
+ of-config-user-guide
+ openflow-plugin-project-user-guide
+ opflex-agent-ovs-user-guide
+ ovsdb-netvirt
+ pcep-user-guide
+ packetcable-user-guide
+ service-function-chaining
+ snmp-plugin-user-guide
+ snmp4sdn-user-guide
+ sxp-user-guide
+ tsdr-user-guide
+ ttp-cli-tools-user-guide
+ uni-manager-plug-in-project
+ unified-secure-channel
+ virtual-tenant-network-(vtn)
+ yang-ide-user-guide
+ yang-push
--- /dev/null
+L2Switch User 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
+
+Configuring L2Switch
+--------------------
+
+This sections below give details about the configuration settings for
+the components that can be configured.
+
+Configuring Loop Remover
+------------------------
+
+- 52-loopremover.xml
+
+ - 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
+
+ - 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"
+
+ - 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"
+
+ - 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"
+
+ - 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"
+
+ - 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.
+
+Configuring Arp Handler
+-----------------------
+
+- 54-arphandler.xml
+
+ - 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
+
+ - This field is only relevant when "is-proactive-flood-mode" is
+ set to "true"
+
+ - 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"
+
+ - 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"
+
+ - 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"
+
+ - 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"
+
+ - 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"
+
+ - 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"
+
+ - 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"
+
+Configuring Address Tracker
+---------------------------
+
+- 56-addresstracker.xml
+
+ - 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.
+
+Configuring L2Switch Main
+-------------------------
+
+- 58-l2switchmain.xml
+
+ - 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"
+
+Running the L2Switch project
+----------------------------
+
+To run the L2 Switch inside the Lithium 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
+L3VPN Service: User Guide
+=========================
+
+Overview
+--------
+
+L3VPN Service in OpenDaylight provides a framework to create L3VPN based
+on BGP-MP. It also helps to create Network Virtualization for DC Cloud
+environment.
+
+Modules & Interfaces
+--------------------
+
+L3VPN service can be realized using the following modules -
+
+VPN Service Modules
+~~~~~~~~~~~~~~~~~~~
+
+1. **VPN Manager** : Creates and manages VPNs and VPN Interfaces
+
+2. **BGP Manager** : Configures BGP routing stack and provides interface
+ to routing services
+
+3. **FIB Manager** : Provides interface to FIB, creates and manages
+ forwarding rules in Dataplane
+
+4. **Nexthop Manager** : Creates and manages nexthop egress pointer,
+ creates egress rules in Dataplane
+
+5. **Interface Manager** : Creates and manages different type of network
+ interfaces, e.g., VLAN, l3tunnel etc.,
+
+6. **Id Manager** : Provides cluster-wide unique ID for a given key.
+ Used by different modules to get unique IDs for different entities.
+
+7. **MD-SAL Util** : Provides interface to MD-SAL. Used by service
+ modules to access MD-SAL Datastore and services.
+
+All the above modules can function independently and can be utilized by
+other services as well.
+
+Configuration Interfaces
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following modules expose configuration interfaces through which user
+can configure L3VPN Service.
+
+1. BGP Manager
+
+2. VPN Manager
+
+3. Interface Manager
+
+4. FIB Manager
+
+Configuration Interface Details
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+1. Data Node Path : */config/bgp:bgp-router/*
+
+ a. Fields :
+
+ i. local-as-identifier
+
+ ii. local-as-number
+
+ b. REST Methods : GET, PUT, DELETE, POST
+
+2. Data Node Path : */config/bgp:bgp-neighbors/*
+
+ a. Fields :
+
+ i. List of bgp-neighbor
+
+ b. REST Methods : GET, PUT, DELETE, POST
+
+3. Data Node Path :
+ */config/bgp:bgp-neighbors/bgp-neighbor/``{as-number}``/*
+
+ a. Fields :
+
+ i. as-number
+
+ ii. ip-address
+
+ b. REST Methods : GET, PUT, DELETE, POST
+
+1. Data Node Path : */config/l3vpn:vpn-instances/*
+
+ a. Fields :
+
+ i. List of vpn-instance
+
+ b. REST Methods : GET, PUT, DELETE, POST
+
+2. Data Node Path : */config/l3vpn:vpn-interfaces/vpn-instance*
+
+ a. Fields :
+
+ i. name
+
+ ii. route-distinguisher
+
+ iii. import-route-policy
+
+ iv. export-route-policy
+
+ b. REST Methods : GET, PUT, DELETE, POST
+
+3. Data Node Path : */config/l3vpn:vpn-interfaces/*
+
+ a. Fields :
+
+ i. List of vpn-interface
+
+ b. REST Methods : GET, PUT, DELETE, POST
+
+4. Data Node Path : */config/l3vpn:vpn-interfaces/vpn-interface*
+
+ a. Fields :
+
+ i. name
+
+ ii. vpn-instance-name
+
+ b. REST Methods : GET, PUT, DELETE, POST
+
+5. Data Node Path :
+ */config/l3vpn:vpn-interfaces/vpn-interface/``{name}``/adjacency*
+
+ a. Fields :
+
+ i. ip-address
+
+ ii. mac-address
+
+ b. REST Methods : GET, PUT, DELETE, POST
+
+1. Data Node Path : */config/if:interfaces/interface*
+
+ a. Fields :
+
+ i. name
+
+ ii. type
+
+ iii. enabled
+
+ iv. of-port-id
+
+ v. tenant-id
+
+ vi. base-interface
+
+ b. type specific fields
+
+ i. when type = *l2vlan*
+
+ A. vlan-id
+
+ ii. when type = *stacked\_vlan*
+
+ A. stacked-vlan-id
+
+ iii. when type = *l3tunnel*
+
+ A. tunnel-type
+
+ B. local-ip
+
+ C. remote-ip
+
+ D. gateway-ip
+
+ iv. when type = *mpls*
+
+ A. list labelStack
+
+ B. num-labels
+
+ c. REST Methods : GET, PUT, DELETE, POST
+
+1. Data Node Path : */config/odl-fib:fibEntries/vrfTables*
+
+ a. Fields :
+
+ i. List of vrfTables
+
+ b. REST Methods : GET, PUT, DELETE, POST
+
+2. Data Node Path :
+ */config/odl-fib:fibEntries/vrfTables/``{routeDistinguisher}``/*
+
+ a. Fields :
+
+ i. route-distinguisher
+
+ ii. list vrfEntries
+
+ A. destPrefix
+
+ B. label
+
+ C. nexthopAddress
+
+ b. REST Methods : GET, PUT, DELETE, POST
+
+3. Data Node Path : */config/odl-fib:fibEntries/ipv4Table*
+
+ a. Fields :
+
+ i. list ipv4Entry
+
+ A. destPrefix
+
+ B. nexthopAddress
+
+ b. REST Methods : GET, PUT, DELETE, POST
+
+Provisioning Sequence & Sample Configurations
+---------------------------------------------
+
+Installation
+~~~~~~~~~~~~
+
+1. Edit *etc/custom.properties* and set the following property:
+ *vpnservice.bgpspeaker.host.name = <bgpserver-ip>* *<bgpserver-ip>*
+ here refers to the IP address of the host where BGP is running.
+
+2. Run ODL and install VPN Service *feature:install odl-vpnservice-core*
+
+Use REST interface to configure L3VPN service
+
+Pre-requisites:
+~~~~~~~~~~~~~~~
+
+1. BGP stack with VRF support needs to installed and configured
+
+ a. *Configure BGP as specified in Step 1 below.*
+
+2. Create pairs of GRE/VxLAN Tunnels (using ovsdb/ovs-vsctl) between
+ each switch and between each switch to the Gateway node
+
+ a. *Create *l3tunnel* interfaces corresponding to each tunnel in
+ interfaces DS as specified in Step 2 below.*
+
+Step 1 : Configure BGP
+~~~~~~~~~~~~~~~~~~~~~~
+
+1. Configure BGP Router
+^^^^^^^^^^^^^^^^^^^^^^^
+
+**REST API** : *PUT /config/bgp:bgp-router/*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "bgp-router": {
+ "local-as-identifier": "10.10.10.10",
+ "local-as-number": 108
+ }
+ }
+
+2. Configure BGP Neighbors
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+**REST API** : *PUT /config/bgp:bgp-neighbors/*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "bgp-neighbor" : [
+ {
+ "as-number": 105,
+ "ip-address": "169.144.42.168"
+ }
+ ]
+ }
+
+Step 2 : Create Tunnel Interfaces
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Create l3tunnel interfaces corresponding to all GRE/VxLAN tunnels
+created with ovsdb (`refer Prerequisites <#prer>`__). Use following REST
+Interface -
+
+**REST API** : *PUT /config/if:interfaces/if:interfacce*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "interface": [
+ {
+ "name" : "GRE_192.168.57.101_192.168.57.102",
+ "type" : "odl-interface:l3tunnel",
+ "odl-interface:tunnel-type": "odl-interface:tunnel-type-gre",
+ "odl-interface:local-ip" : "192.168.57.101",
+ "odl-interface:remote-ip" : "192.168.57.102",
+ "odl-interface:portId" : "openflow:1:3",
+ "enabled" : "true"
+ }
+ ]
+ }
+
+Following is expected as a result of these configurations
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+1. Unique If-index is generated
+
+2. *Interface-state* operational DS is updated
+
+3. Corresponding Nexthop Group Entry is created
+
+Step 3 : OS Create Neutron Ports and attach VMs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+At this step user creates VMs.
+
+Step 4 : Create VM Interfaces
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Create l2vlan interfaces corresponding to VM created in step 3
+
+**REST API** : *PUT /config/if:interfaces/if:interface*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "interface": [
+ {
+ "name" : "dpn1-dp1.2",
+ "type" : "l2vlan",
+ "odl-interface:of-port-id" : "openflow:1:2",
+ "odl-interface:vlan-id" : "1",
+ "enabled" : "true"
+ }
+ ]
+ }
+
+Step 5: Create VPN Instance
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**REST API** : *PUT /config/l3vpn:vpn-instances/l3vpn:vpn-instance/*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "vpn-instance": [
+ {
+ "description": "Test VPN Instance 1",
+ "vpn-instance-name": "testVpn1",
+ "ipv4-family": {
+ "route-distinguisher": "4000:1",
+ "export-route-policy": "4000:1,5000:1",
+ "import-route-policy": "4000:1,5000:1",
+ }
+ }
+ ]
+ }
+
+Following is expected as a result of these configurations
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+1. VPN ID is allocated and updated in data-store
+
+2. Corresponding VRF is created in BGP
+
+3. If there are vpn-interface configurations for this VPN, corresponding
+ action is taken as defined in step 5
+
+Step 5 : Create VPN-Interface and Local Adjacency
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*this can be done in two steps as well*
+
+1. Create vpn-interface
+^^^^^^^^^^^^^^^^^^^^^^^
+
+**REST API** : *PUT /config/l3vpn:vpn-interfaces/l3vpn:vpn-interface/*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "vpn-interface": [
+ {
+ "vpn-instance-name": "testVpn1",
+ "name": "dpn1-dp1.2",
+ }
+ ]
+ }
+
+.. note::
+
+ name here is the name of VM interface created in step 3, 4
+
+2. Add Adjacencies on vpn-interafce
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+**REST API** : *PUT
+/config/l3vpn:vpn-interfaces/l3vpn:vpn-interface/dpn1-dp1.3/adjacency*
+
+**Sample JSON Data**
+
+.. code:: json
+
+ {
+ "adjacency" : [
+ {
+ "ip-address" : "169.144.42.168",
+ "mac-address" : "11:22:33:44:55:66"
+ }
+ ]
+ }
+
+ its a list, user can define more than one adjacency on a
+ vpn\_interface
+
+Above steps can be carried out in a single step as following
+
+.. code:: json
+
+ {
+ "vpn-interface": [
+ {
+ "vpn-instance-name": "testVpn1",
+ "name": "dpn1-dp1.3",
+ "odl-l3vpn:adjacency": [
+ {
+ "odl-l3vpn:mac_address": "11:22:33:44:55:66",
+ "odl-l3vpn:ip_address": "11.11.11.2",
+ }
+ ]
+ }
+ ]
+ }
+
+Following is expected as a result of these configurations
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+1. Prefix label is generated and stored in DS
+
+2. Ingress table is programmed with flow corresponding to interface
+
+3. Local Egress Group is created
+
+4. Prefix is added to BGP for advertisement
+
+5. BGP pushes route update to FIB YANG Interface
+
+6. FIB Entry flow is added to FIB Table in OF pipeline
+
--- /dev/null
+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 Beryllium 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
+Neutron Service User Guide
+==========================
+
+Overview
+--------
+
+This Karaf feature (``odl-neutron-service``) provides integration
+support for OpenStack Neutron via the OpenDaylight ML2 mechanism driver.
+The Neutron Service is only one of the components necessary for
+OpenStack integration. For those related components please refer to
+documentations of each component:
+
+- https://wiki.openstack.org/wiki/Neutron
+
+- https://launchpad.net/networking-odl
+
+- http://git.openstack.org/cgit/openstack/networking-odl/
+
+- https://wiki.opendaylight.org/view/NeutronNorthbound:Main
+
+Use cases and who will use the feature
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you want OpenStack integration with OpenDaylight, you will need this
+feature with an OpenDaylight provider feature like ovsdb/netvirt, group
+based policy, VTN, and lisp mapper. For provider configuration, please
+refer to each individual provider’s documentation. Since the Neutron
+service only provides the northbound API for the OpenStack Neutron ML2
+mechanism driver. Without those provider features, the Neutron service
+itself isn’t useful.
+
+Neutron Service feature Architecture
+------------------------------------
+
+The Neutron service provides northbound API for OpenStack Neutron via
+RESTCONF and also its dedicated REST API. It communicates through its
+YANG model with providers.
+
+.. figure:: ./images/neutron/odl-neutron-service-architecture.png
+ :alt: Neutron Service Architecture
+
+ Neutron Service Architecture
+
+Configuring Neutron Service feature
+-----------------------------------
+
+As the Karaf feature includes everything necessary for communicating
+northbound, no special configuration is needed. Usually this feature is
+used with an OpenDaylight southbound plugin that implements actual
+network virtualization functionality and OpenStack Neutron. The user
+wants to setup those configurations. Refer to each related
+documentations for each configurations.
+
+Administering or Managing ``odl-neutron-service``
+-------------------------------------------------
+
+There is no specific configuration regarding to Neutron service itself.
+For related configuration, please refer to OpenStack Neutron
+configuration and OpenDaylight related services which are providers for
+OpenStack.
+
+installing ``odl-neutron-service`` while the controller running
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+1. While OpenDaylight is running, in Karaf prompt, type:
+ ``feature:install odl-neutron-service``.
+
+2. Wait a while until the initialization is done and the controller
+ stabilizes.
+
+``odl-neutron-service`` provides only a unified interface for OpenStack
+Neutron. It doesn’t provide actual functionality for network
+virtualization. Refer to each OpenDaylight project documentation for
+actual configuration with OpenStack Neutron.
+
+Neutron Logger
+--------------
+
+Another service, the Neutron Logger, is provided for debugging/logging
+purposes. It logs changes on Neutron YANG models.
+
+::
+
+ feature:install odl-neutron-logger
+
--- /dev/null
+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
+OpenDaylight Controller Overview
+================================
+
+The OpenDaylight controller is JVM software and can be run from any
+operating system and hardware as long as it supports Java. The
+controller is an implementation of the Software Defined Network (SDN)
+concept and makes use of the following tools:
+
+- **Maven**: OpenDaylight uses Maven for easier build automation. Maven
+ uses pom.xml (Project Object Model) to script the dependencies
+ between bundle and also to describe what bundles to load and start.
+
+- **OSGi**: This framework is the back-end of OpenDaylight as it allows
+ dynamically loading bundles and packages JAR files, and binding
+ bundles together for exchanging information.
+
+- **JAVA interfaces**: Java interfaces are used for event listening,
+ specifications, and forming patterns. This is the main way in which
+ specific bundles implement call-back functions for events and also to
+ indicate awareness of specific state.
+
+- **REST APIs**: These are northbound APIs such as topology manager,
+ host tracker, flow programmer, static routing, and so on.
+
+The controller exposes open northbound APIs which are used by
+applications. The OSGi framework and bidirectional REST are supported
+for the northbound APIs. The OSGi framework is used for applications
+that run in the same address space as the controller while the REST
+(web-based) API is used for applications that do not run in the same
+address space (or even the same system) as the controller. The business
+logic and algorithms reside in the applications. These applications use
+the controller to gather network intelligence, run its algorithm to do
+analytics, and then orchestrate the new rules throughout the network. On
+the southbound, multiple protocols are supported as plugins, e.g.
+OpenFlow 1.0, OpenFlow 1.3, BGP-LS, and so on. The OpenDaylight
+controller starts with an OpenFlow 1.0 southbound plugin. Other
+OpenDaylight contributors begin adding to the controller code. These
+modules are linked dynamically into a **Service Abstraction Layer**
+(SAL).
+
+The SAL exposes services to which the modules north of it are written.
+The SAL figures out how to fulfill the requested service irrespective of
+the underlying protocol used between the controller and the network
+devices. This provides investment protection to the applications as
+OpenFlow and other protocols evolve over time. For the controller to
+control devices in its domain, it needs to know about the devices, their
+capabilities, reachability, and so on. This information is stored and
+managed by the **Topology Manager**. The other components like ARP
+handler, Host Tracker, Device Manager, and Switch Manager help in
+generating the topology database for the Topology Manager.
+
+For a more detailed overview of the OpenDaylight controller, see the
+*OpenDaylight Developer Guide*.
+
--- /dev/null
+OpFlex agent-ovs User Guide
+===========================
+
+Introduction
+------------
+
+agent-ovs is a policy agent that works with OVS to enforce a group-based
+policy networking model with locally attached virtual machines or
+containers. The policy agent is designed to work well with orchestration
+tools like OpenStack.
+
+Agent Configuration
+-------------------
+
+The agent configuration is handled using its config file which is by
+default found at "/etc/opflex-agent-ovs/opflex-agent-ovs.conf"
+
+Here is an example configuration file that documents the available
+options:
+
+::
+
+ {
+ // Logging configuration
+ // "log": {
+ // "level": "info"
+ // },
+
+ // Configuration related to the OpFlex protocol
+ "opflex": {
+ // The policy domain for this agent.
+ "domain": "openstack",
+
+ // The unique name in the policy domain for this agent.
+ "name": "example-agent",
+
+ // a list of peers to connect to, by hostname and port. One
+ // peer, or an anycast pseudo-peer, is sufficient to bootstrap
+ // the connection without needing an exhaustive list of all
+ // peers.
+ "peers": [
+ // EXAMPLE:
+ {"hostname": "10.0.0.30", "port": 8009}
+ ],
+
+ "ssl": {
+ // SSL mode. Possible values:
+ // disabled: communicate without encryption
+ // encrypted: encrypt but do not verify peers
+ // secure: encrypt and verify peer certificates
+ "mode": "disabled",
+
+ // The path to a directory containing trusted certificate
+ // authority public certificates, or a file containing a
+ // specific CA certificate.
+ "ca-store": "/etc/ssl/certs/"
+ },
+
+ "inspector": {
+ // Enable the MODB inspector service, which allows
+ // inspecting the state of the managed object database.
+ // Default: enabled
+ "enabled": true,
+
+ // Listen on the specified socket for the inspector
+ // Default /var/run/opflex-agent-ovs-inspect.sock
+ "socket-name": "/var/run/opflex-agent-ovs-inspect.sock"
+ }
+ },
+
+ // Endpoint sources provide metadata about local endpoints
+ "endpoint-sources": {
+ // Filesystem path to monitor for endpoint information
+ "filesystem": ["/var/lib/opflex-agent-ovs/endpoints"]
+ },
+
+ // Renderers enforce policy obtained via OpFlex.
+ "renderers": {
+ // Stitched-mode renderer for interoperating with a
+ // hardware fabric such as ACI
+ // EXAMPLE:
+ "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
+ // stiched-mode fabric.
+ "remote-ip": "10.0.0.32",
+
+ // UDP port number of the encapsulated traffic.
+ "remote-port": 8472
+ }
+
+ // Encapsulate traffic with a locally-significant VLAN
+ // tag
+ // EXAMPLE:
+ // "vlan" : {
+ // // The name of the uplink interface in OVS
+ // "encap-iface": "team0"
+ // }
+ },
+
+ // Configure forwarding policy
+ "forwarding": {
+ // Configure the virtual distributed router
+ "virtual-router": {
+ // Enable virtual distributed router. Set to true
+ // to enable or false to disable. Default true.
+ "enabled": true,
+
+ // Override MAC address for virtual router.
+ // Default 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. This
+ // is not required in stitched mode since the
+ // hardware router will send them.
+ "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"
+ },
+
+ "endpoint-advertisements": {
+ // Enable generation of periodic ARP/NDP
+ // advertisements for endpoints. Default true.
+ "enabled": "true"
+ }
+ },
+
+ // Location to store cached IDs for managing flow state
+ "flowid-cache-dir": "/var/lib/opflex-agent-ovs/ids"
+ }
+ }
+ }
+
+Endpoint Registration
+---------------------
+
+The agent learns about endpoints using endpoint metadata files located
+by default in "/var/lib/opflex-agent-ovs/endpoints".
+
+These are JSON-format files such as the (unusually complex) example
+below:
+
+::
+
+ {
+ "uuid": "83f18f0b-80f7-46e2-b06c-4d9487b0c754",
+ "policy-space-name": "test",
+ "endpoint-group-name": "group1",
+ "interface-name": "veth0",
+ "ip": [
+ "10.0.0.1", "fd8f:69d8:c12c:ca62::1"
+ ],
+ "dhcp4": {
+ "ip": "10.200.44.2",
+ "prefix-len": 24,
+ "routers": ["10.200.44.1"],
+ "dns-servers": ["8.8.8.8", "8.8.4.4"],
+ "domain": "example.com",
+ "static-routes": [
+ {
+ "dest": "169.254.169.0",
+ "dest-prefix": 24,
+ "next-hop": "10.0.0.1"
+ }
+ ]
+ },
+ "dhcp6": {
+ "dns-servers": ["2001:4860:4860::8888", "2001:4860:4860::8844"],
+ "search-list": ["test1.example.com", "example.com"]
+ },
+ "ip-address-mapping": [
+ {
+ "uuid": "91c5b217-d244-432c-922d-533c6c036ab4",
+ "floating-ip": "5.5.5.1",
+ "mapped-ip": "10.0.0.1",
+ "policy-space-name": "common",
+ "endpoint-group-name": "nat-epg"
+ },
+ {
+ "uuid": "22bfdc01-a390-4b6f-9b10-624d4ccb957b",
+ "floating-ip": "fdf1:9f86:d1af:6cc9::1",
+ "mapped-ip": "fd8f:69d8:c12c:ca62::1",
+ "policy-space-name": "common",
+ "endpoint-group-name": "nat-epg"
+ }
+ ],
+ "mac": "00:00:00:00:00:01",
+ "promiscuous-mode": false
+ }
+
+The possible parameters for these files are:
+
+**uuid**
+ A globally unique ID for the endpoint
+
+**endpoint-group-name**
+ The name of the endpoint group for the endpoint
+
+**policy-space-name**
+ The name of the policy space for the endpoint group.
+
+**interface-name**
+ The name of the OVS interface to which the endpoint is attached
+
+**ip**
+ A list of strings contains either IPv4 or IPv6 addresses that the
+ endpoint is allowed to use
+
+**mac**
+ The MAC address for the endpoint’s interface.
+
+**promiscuous-mode**
+ Allow traffic from this VM to bypass default port security
+
+**dhcp4**
+ A distributed DHCPv4 configuration block (see below)
+
+**dhcp6**
+ A distributed DHCPv6 configuration block (see below)
+
+**ip-address-mapping**
+ A list of IP address mapping configuration blocks (see below)
+
+DHCPv4 configuration blocks can contain the following parameters:
+
+**ip**
+ the IP address to return with DHCP. Must be one of the configured
+ IPv4 addresses.
+
+**prefix**
+ the subnet prefix length
+
+**routers**
+ a list of default gateways for the endpoint
+
+**dns**
+ a list of DNS server addresses
+
+**domain**
+ The domain name parameter to send in the DHCP reply
+
+**static-routes**
+ A list of static route configuration blocks, which contains a
+ "dest", "dest-prefix", and "next-hop" parameters to send as static
+ routes to the end host
+
+DHCPv6 configuration blocks can contain the following parameters:
+
+**dns**
+ A list of DNS servers for the endpoint
+
+**search-patch**
+ The DNS search path for the endpoint
+
+IP address mapping configuration blocks can contain the following
+parameters:
+
+**uuid**
+ a globally unique ID for the virtual endpoint created by the
+ mapping.
+
+**floating-ip**
+ Map using DNAT to this floating IPv4 or IPv6 address
+
+**mapped-ip**
+ the source IPv4 or IPv6 address; must be one of the IPs assigned to
+ the endpoint.
+
+**endpoint-group-name**
+ The name of the endpoint group for the NATed IP
+
+**policy-space-name**
+ The name of the policy space for the NATed IP
+
+Inspector
+---------
+
+The Opflex inspector is a useful command-line tool that will allow you
+to inspect the state of the managed object database for the agent for
+debugging and diagnosis purposes.
+
+The command is called "gbp\_inspect" and takes the following arguments:
+
+::
+
+ # gbp_inspect -h
+ Usage: ./gbp_inspect [options]
+ Allowed options:
+ -h [ --help ] Print this help message
+ --log arg Log to the specified file (default
+ standard out)
+ --level arg (=warning) Use the specified log level (default
+ info)
+ --syslog Log to syslog instead of file or
+ standard out
+ --socket arg (=/usr/local/var/run/opflex-agent-ovs-inspect.sock)
+ Connect to the specified UNIX domain
+ socket (default /usr/local/var/run/opfl
+ ex-agent-ovs-inspect.sock)
+ -q [ --query ] arg Query for a specific object with
+ subjectname,uri or all objects of a
+ specific type with subjectname
+ -r [ --recursive ] Retrieve the whole subtree for each
+ returned object
+ -f [ --follow-refs ] Follow references in returned objects
+ --load arg Load managed objects from the specified
+ file into the MODB view
+ -o [ --output ] arg Output the results to the specified
+ file (default standard out)
+ -t [ --type ] arg (=tree) Specify the output format: tree, list,
+ or dump (default tree)
+ -p [ --props ] Include object properties in output
+
+Here are some examples of the ways to use this tool.
+
+You can get information about the running system using one or more
+queries, which consist of an object model class name and optionally the
+URI of a specific object. The simplest query is to get a single object,
+nonrecursively:
+
+::
+
+ # gbp_inspect -q DmtreeRoot
+ --* DmtreeRoot,/
+ # gbp_inspect -q GbpEpGroup
+ --* GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
+ --* GbpEpGroup,/PolicyUniverse/PolicySpace/test/GbpEpGroup/group1/
+ # gbp_inspect -q GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
+ --* GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
+
+You can also display all the properties for each object:
+
+::
+
+ # gbp_inspect -p -q GbpeL24Classifier
+ --* GbpeL24Classifier,/PolicyUniverse/PolicySpace/test/GbpeL24Classifier/classifier4/
+ {
+ connectionTracking : 1 (reflexive)
+ dFromPort : 80
+ dToPort : 80
+ etherT : 2048 (ipv4)
+ name : classifier4
+ prot : 6
+ }
+ --* GbpeL24Classifier,/PolicyUniverse/PolicySpace/test/GbpeL24Classifier/classifier3/
+ {
+ etherT : 34525 (ipv6)
+ name : classifier3
+ order : 100
+ prot : 58
+ }
+ --* GbpeL24Classifier,/PolicyUniverse/PolicySpace/test/GbpeL24Classifier/classifier2/
+ {
+ etherT : 2048 (ipv4)
+ name : classifier2
+ order : 101
+ prot : 1
+ }
+
+You can also request to get the all the children of an object you query
+for:
+
+::
+
+ # gbp_inspect -r -q GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
+ --* GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
+ |-* GbpeInstContext,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/GbpeInstContext/
+ `-* GbpEpGroupToNetworkRSrc,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/GbpEpGroupToNetworkRSrc/
+
+You can also follow references found in any object downloads:
+
+::
+
+ # gbp_inspect -fr -q GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
+ --* GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
+ |-* GbpeInstContext,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/GbpeInstContext/
+ `-* GbpEpGroupToNetworkRSrc,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/GbpEpGroupToNetworkRSrc/
+ --* GbpFloodDomain,/PolicyUniverse/PolicySpace/common/GbpFloodDomain/fd_ext/
+ `-* GbpFloodDomainToNetworkRSrc,/PolicyUniverse/PolicySpace/common/GbpFloodDomain/fd_ext/GbpFloodDomainToNetworkRSrc/
+ --* GbpBridgeDomain,/PolicyUniverse/PolicySpace/common/GbpBridgeDomain/bd_ext/
+ `-* GbpBridgeDomainToNetworkRSrc,/PolicyUniverse/PolicySpace/common/GbpBridgeDomain/bd_ext/GbpBridgeDomainToNetworkRSrc/
+ --* GbpRoutingDomain,/PolicyUniverse/PolicySpace/common/GbpRoutingDomain/rd_ext/
+ |-* GbpRoutingDomainToIntSubnetsRSrc,/PolicyUniverse/PolicySpace/common/GbpRoutingDomain/rd_ext/GbpRoutingDomainToIntSubnetsRSrc/122/%2fPolicyUniverse%2fPolicySpace%2fcommon%2fGbpSubnets%2fsubnets_ext%2f/
+ `-* GbpForwardingBehavioralGroupToSubnetsRSrc,/PolicyUniverse/PolicySpace/common/GbpRoutingDomain/rd_ext/GbpForwardingBehavioralGroupToSubnetsRSrc/
+ --* GbpSubnets,/PolicyUniverse/PolicySpace/common/GbpSubnets/subnets_ext/
+ |-* GbpSubnet,/PolicyUniverse/PolicySpace/common/GbpSubnets/subnets_ext/GbpSubnet/subnet_ext4/
+ `-* GbpSubnet,/PolicyUniverse/PolicySpace/common/GbpSubnets/subnets_ext/GbpSubnet/subnet_ext6/
+
--- /dev/null
+Running XSQL Console Commands and Queries
+=========================================
+
+XSQL Overview
+-------------
+
+XSQL is an XML-based query language that describes simple stored
+procedures which parse XML data, query or update database tables, and
+compose XML output. XSQL allows you to query tree models like a
+sequential database. For example, you could run a query that lists all
+of the ports configured on a particular module and their attributes.
+
+The following sections cover the XSQL installation process, supported
+XSQL commands, and the way to structure queries.
+
+Installing XSQL
+---------------
+
+To run commands from the XSQL console, you must first install XSQL on
+your system:
+
+1. Navigate to the directory in which you unzipped OpenDaylight
+
+2. Start Karaf:
+
+ ::
+
+ ./bin/karaf
+
+3. Install XSQL:
+
+ ::
+
+ feature:install odl-mdsal-xsql
+
+XSQL Console Commands
+---------------------
+
+To enter a command in the XSQL console, structure the command as
+follows: **odl:xsql** *<XSQL command>*
+
+The following table describes the commands supported in this
+OpenDaylight release.
+
++-----------------------+----------------------------------------------------+
+| **Command** | **Description** |
++-----------------------+----------------------------------------------------+
+| **r** | Repeats the last command you executed. |
++-----------------------+----------------------------------------------------+
+| **list vtables** | Lists the schema node containers that are |
+| | currently installed. Whenever an OpenDaylight |
+| | module is installed, its YANG model is placed in |
+| | the schema context. At that point, the XSQL |
+| | receives a notification, confirms that the |
+| | module’s YANG model resides in the schema context |
+| | and then maps the model to XSQL by setting up the |
+| | necessary vtables and vfields. This command is |
+| | useful when you need to determine vtable |
+| | information for a query. |
++-----------------------+----------------------------------------------------+
+| **list vfields** | Lists the vfields present in a specific vtable. |
+| *<vtable name>* | This command is useful when you need to determine |
+| | vfields information for a query. |
++-----------------------+----------------------------------------------------+
+| **jdbc** *<ip | When the ODL server is behind a firewall, and the |
+| address>* | JDBC client cannot connect to the JDBC server, run |
+| | this command to start the client as a server and |
+| | establish a connection. |
++-----------------------+----------------------------------------------------+
+| **exit** | Closes the console. |
++-----------------------+----------------------------------------------------+
+| **tocsv** | Enables or disables the forwarding of query output |
+| | as a .csv file. |
++-----------------------+----------------------------------------------------+
+| **filename** | Specifies the .tocsv file to which the query data |
+| *<filename>* | is exported. If you do not specify a value for |
+| | this option when the toccsv option is enabled, the |
+| | filename for the query data file is generated |
+| | automatically. |
++-----------------------+----------------------------------------------------+
+
+Table: Supported XSQL Console Commands
+
+XSQL Queries
+------------
+
+You can run a query to extract information that meets the criteria you
+specify using the information provided by the **list vtables** and
+**list vfields** *<vtable name>* commands. Any query you run should be
+structured as follows:
+
+**select** *<vfields you want to search for, separated by a comma and a
+space>* **from** *<vtables you want to search in, separated by a comma
+and a space>* **where** *<criteria>* ***\*\ *<criteria operator>****;\*
+
+For example, if you want to search the nodes/node ID field in the
+nodes/node-connector table and find every instance of the
+Hardware-Address object that contains *BA* in its text string, enter the
+following query:
+
+::
+
+ select nodes/node.ID from nodes/node-connector where Hardware-Address like '%BA%';
+
+The following criteria operators are supported:
+
++----------------+-----------------------------------------------------------+
+| **Criteria | **Description** |
+| Operators** | |
++----------------+-----------------------------------------------------------+
+| **=** | Lists results that equal the value you specify. |
++----------------+-----------------------------------------------------------+
+| **!=** | Lists results that do not equal the value you specify. |
++----------------+-----------------------------------------------------------+
+| **like** | Lists results that contain the substring you specify. For |
+| | example, if you specify **like %BC%**, every string that |
+| | contains that particular substring is displayed. |
++----------------+-----------------------------------------------------------+
+| **<** | Lists results that are less than the value you specify. |
++----------------+-----------------------------------------------------------+
+| **>** | Lists results that are more than the value you specify. |
++----------------+-----------------------------------------------------------+
+| **and** | Lists results that match both values you specify. |
++----------------+-----------------------------------------------------------+
+| **or** | Lists results that match either of the two values you |
+| | specify. |
++----------------+-----------------------------------------------------------+
+| **>=** | Lists results that are more than or equal to the value |
+| | you specify. |
++----------------+-----------------------------------------------------------+
+| **⇐** | Lists results that are less than or equal to the value |
+| | you specify. |
++----------------+-----------------------------------------------------------+
+| **is null** | Lists results for which no value is assigned. |
++----------------+-----------------------------------------------------------+
+| **not null** | Lists results for which any value is assigned. |
++----------------+-----------------------------------------------------------+
+| **skip** | Use this operator to list matching results from a child |
+| | node, even if its parent node does not meet the specified |
+| | criteria. See the following example for more information. |
++----------------+-----------------------------------------------------------+
+
+Table: Supported XSQL Query Criteria Operators
+
+Example: Skip Criteria Operator
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you are looking at the following structure and want to determine all
+of the ports that belong to a YY type module:
+
+- Network Element 1
+
+ - Module 1, Type XX
+
+ - Module 1.1, Type YY
+
+ - Port 1
+
+ - Port 2
+
+ - Module 2, Type YY
+
+ - Port 1
+
+ - Port 2
+
+If you specify **Module.Type=\ *YY*** in your query criteria, the ports
+associated with module 1.1 will not be returned since its parent module
+is type XX. Instead, enter **Module.Type=\ *YY* or skip
+Module!=\ *YY***. This tells XSQL to disregard any parent module data
+that does not meet the type YY criteria and collect results for any
+matching child modules. In this example, you are instructing the query
+to skip module 1 and collect the relevant data from module 1.1.
+
--- /dev/null
+TTP CLI Tools User Guide
+========================
+
+Overview
+--------
+
+Table Type Patterns are a specification developed by the `Open
+Networking Foundation <https://www.opennetworking.org/>`__ to enable the
+description and negotiation of subsets of the OpenFlow protocol. This is
+particularly useful for hardware switches that support OpenFlow as it
+enables the to describe what features they do (and thus also what
+features they do not) support. More details can be found in the full
+specification listed on the `OpenFlow specifications
+page <https://www.opennetworking.org/sdn-resources/onf-specifications/openflow>`__.
+
+TTP CLI Tools Architecture
+--------------------------
+
+The TTP CLI Tools use the TTP Model and the YANG Tools/RESTCONF codecs
+to translate between the Data Transfer Objects (DTOs) and JSON/XML.
+
--- /dev/null
+Using the OpenDaylight User Interface (DLUX)
+============================================
+
+This section introduces you to the OpenDaylight User Experience (DLUX)
+application.
+
+Getting Started with DLUX
+-------------------------
+
+DLUX provides a number of different Karaf features, which you can enable
+and disable separately. In Beryllum they are: . odl-dlux-core .
+odl-dlux-node . odl-dlux-yangui . odl-dlux-yangvisualizer
+
+Logging In
+----------
+
+To log in to DLUX, after installing the application:
+
+1. Open a browser and enter the login URL
+ `http://<your-karaf-ip>:8181/index.html <http://<your-karaf-ip>:8181/index.html>`__
+ in your browser (Chrome is recommended).
+
+2. Login to the application with your username and password credentials.
+
+.. note::
+
+ OpenDaylight’s default credentials are *admin* for both the username
+ and password.
+
+Working with DLUX
+-----------------
+
+After you login to DLUX, if you enable only odl-dlux-core feature, you
+will see only topology application available in the left pane.
+
+.. note::
+
+ To make sure topology displays all the details, enable the
+ odl-l2switch-switch feature in Karaf.
+
+DLUX has other applications such as node, yang UI and those apps won’t
+show up, until you enable their features odl-dlux-node and
+odl-dlux-yangui respectively in the Karaf distribution.
+
+.. figure:: ./images/dlux-login.png
+ :alt: DLUX Modules
+
+ DLUX Modules
+
+.. note::
+
+ If you install your application in dlux, they will also show up on
+ the left hand navigation after browser page refresh.
+
+Viewing Network Statistics
+--------------------------
+
+The **Nodes** module on the left pane enables you to view the network
+statistics and port information for the switches in the network.
+
+To use the **Nodes** module:
+
+1. Select **Nodes** on the left pane. The right pane displays atable
+ that lists all the nodes, node connectors and the statistics.
+
+2. Enter a node ID in the **Search Nodes** tab to search by node
+ connectors.
+
+3. Click on the **Node Connector** number to view details such as port
+ ID, port name, number of ports per switch, MAC Address, and so on.
+
+4. Click **Flows** in the Statistics column to view Flow Table
+ Statistics for the particular node like table ID, packet match,
+ active flows and so on.
+
+5. Click **Node Connectors** to view Node Connector Statistics for the
+ particular node ID.
+
+Viewing Network Topology
+------------------------
+
+The Topology tab displays a graphical representation of network topology
+created.
+
+.. note::
+
+ DLUX does not allow for editing or adding topology information. The
+ topology is generated and edited in other modules, e.g., the
+ OpenFlow plugin. OpenDaylight stores this information in the MD-SAL
+ datastore where DLUX can read and display it.
+
+To view network topology:
+
+1. Select **Topology** on the left pane. You will view the graphical
+ representation on the right pane. In the diagram blue boxes represent
+ the switches, the black represents the hosts available, and lines
+ represents how the switches and hosts are connected.
+
+2. Hover your mouse on hosts, links, or switches to view source and
+ destination ports.
+
+3. Zoom in and zoom out using mouse scroll to verify topology for larger
+ topologies.
+
+.. figure:: ./images/dlux-topology.png
+ :alt: Topology Module
+
+ Topology Module
+
+Interacting with the YANG-based MD-SAL datastore
+------------------------------------------------
+
+The **Yang UI** module enables you to interact with the YANG-based
+MD-SAL datastore. For more information about YANG and how it interacts
+with the MD-SAL datastore, see the *Controller* and *YANG Tools* section
+of the *OpenDaylight Developer Guide*.
+
+.. figure:: ./images/dlux-yang-ui-screen.png
+ :alt: Yang UI
+
+ Yang UI
+
+To use Yang UI:
+
+1. Select **Yang UI** on the left pane. The right pane is divided in two
+ parts.
+
+2. The top part displays a tree of APIs, subAPIs, and buttons to call
+ possible functions (GET, POST, PUT, and DELETE).
+
+ .. note::
+
+ every subAPI can call every function. For example, subAPIs in
+ the *operational* store have GET functionality only.
+
+ Inputs can be filled from OpenDaylight when existing data from
+ OpenDaylight is displayed or can be filled by user on the page and
+ sent to OpenDaylight.
+
+ Buttons under the API tree are variable. It depends on subAPI
+ specifications. Common buttons are:
+
+ - GET to get data from OpenDaylight,
+
+ - PUT and POST for sending data to OpenDaylight for saving
+
+ - DELETE for sending data to OpenDaylight for deleting.
+
+ You must specify the xpath for all these operations. This path is
+ displayed in the same row before buttons and it may include text
+ inputs for specific path element identifiers.
+
+ .. figure:: ./images/dlux-yang-api-specification.png
+ :alt: Yang API Specification
+
+ Yang API Specification
+
+3. The bottom part of the right pane displays inputs according to the
+ chosen subAPI.
+
+ - Lists are handled as a special case. For example, a device can
+ store multiple flows. In this case "flow" is name of the list and
+ every list element is identified by a unique key value. Elements
+ of a list can, in turn, contain other lists.
+
+ - In Yang UI, each list element is rendered with the name of the
+ list it belongs to, its key, its value, and a button for removing
+ it from the list.
+
+ .. figure:: ./images/dlux-yang-sub-api-screen.png
+ :alt: Yang UI API Specification
+
+ Yang UI API Specification
+
+4. After filling in the relevant inputs, click the **Show Preview**
+ button under the API tree to display request that will be sent to
+ OpenDaylight. A pane is displayed on the right side with text of
+ request when some input is filled.
+
+Displaying Topology on the **Yang UI**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To display topology:
+
+1. Select subAPI network-topology <topology revision number> == >
+ operational == > network-topology.
+
+2. Get data from OpenDaylight by clicking on the "GET" button.
+
+3. Click **Display Topology**.
+
+.. figure:: ./images/dlux-yang-topology.png
+ :alt: DLUX Yang Topology
+
+ DLUX Yang Topology
+
+Configuring List Elements on the **Yang UI**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Lists in Yang UI are displayed as trees. To expand or collapse a list,
+click the arrow before name of the list. To configure list elements in
+Yang UI:
+
+1. To add a new list element with empty inputs use the plus icon-button
+ **+** that is provided after list name.
+
+2. To remove several list elements, use the **X** button that is
+ provided after every list element.
+
+ .. figure:: ./images/dlux-yang-list-elements.png
+ :alt: DLUX List Elements
+
+ DLUX List Elements
+
+3. In the YANG-based data store all elements of a list must have a
+ unique key. If you try to assign two or more elements the same key, a
+ warning icon **!** is displayed near their name buttons.
+
+ .. figure:: ./images/dlux-yang-list-warning.png
+ :alt: DLUX List Warnings
+
+ DLUX List Warnings
+
+4. When the list contains at least one list element, after the **+**
+ icon, there are buttons to select each individual list element. You
+ can choose one of them by clicking on it. In addition, to the right
+ of the list name, there is a button which will display a vertically
+ scrollable pane with all the list elements.
+
+ .. figure:: ./images/dlux-yang-list-button1.png
+ :alt: DLUX List Button1
+
+ DLUX List Button1
+
--- /dev/null
+YANG IDE User Guide
+===================
+
+Overview
+--------
+
+The YANG IDE project provides an Eclipse plugin that is used to create,
+view, and edit Yang model files. It currently supports version 1.0 of
+the Yang specification.
+
+The YANG IDE project uses components from the OpenDaylight project for
+parsing and verifying Yang model files. The "yangtools" parser in
+OpenDaylight is generally used for generating Java code associated with
+Yang models. If you are just using the YANG IDE to view and edit Yang
+models, you do not need to know any more about this.
+
+Although the YANG IDE plugin is used in Eclipse, it is not necessary to
+be familiar with the Java programming language to use it effectively.
+
+The YANG IDE also uses the Maven build tool, but you do not have to be a
+Maven expert to use it, or even know that much about it. Very little
+configuration of Maven files will have to be done by you. In fact, about
+the only thing you will likely ever need to change can be done entirely
+in the Eclipse GUI forms, without even seeing the internal structure of
+the Maven POM file (Project Object Model).
+
+The YANG IDE plugin provides features that are similar to other
+programming language plugins in the Eclipse ecosystem.
+
+For instance, you will find support for the following:
+
+- Immediate "as-you-type" display of syntactic and semantic errors
+
+- Intelligent completion of language tokens, limited to only choices
+ valid in the current scope and namespace
+
+- Consistent (and customizable) color-coding of syntactic and semantic
+ symbols
+
+- Provides access to remote Yang models by specifying dependency on
+ Maven artifact containing models (or by manual inclusion in project)
+
+- One-click navigation to referenced symbols in external files
+
+- Mouse hovers display descriptions of referenced components
+
+- Tools for refactoring or renaming components respect namespaces
+
+- Code templates can be entered for common conventions
+
+Forthcoming sections of this manual will step through how to utilize
+these features.
+
+Creating a Yang Project
+-----------------------
+
+After the plugin is installed, the next thing you have to do is create a
+Yang Project. This is done from the "File" menu, selecting "New", and
+navigating to the "Yang" section and selecting "YANG Project", and then
+clicking "Next" for more items to configure.
+
+Some shortcuts for these steps are the following:
+
+- Typically, the key sequence "Ctrl+n" (press "n" while holding down
+ one of the "ctrl" keys) is bound to the "new" function
+
+- In the "New" wizard dialog, the initial focus is in the filter field,
+ where you can enter "yang" to limit the choices to only the functions
+ provided by the YANG IDE plugin
+
+- On the "New" wizard dialog, instead of clicking the "Next" button
+ with your mouse, you can press "Alt+n" (you will see a hint for this
+ with the "N" being underlined)
+
+First Yang Project Wizard Page
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After the "Next" button is pressed, it goes to the first wizard page
+that is specific to creating Yang projects. you will see a subtitle on
+this page of "YANG Tools Configuration". In almost all cases, you should
+be able to click "Next" again on this page to go to the next wizard
+page.
+
+However, some information about the fields on this page would be
+helpful.
+
+You will see the following labeled fields and sections:
+
+Yang Files Root Directory
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This defaults to "src/main/yang". Except when creating your first Yang
+file, you, you do not even have to know this, as Eclipse presents the
+same interface to view your Yang files no matter what you set this to.
+
+Source Code Generators
+^^^^^^^^^^^^^^^^^^^^^^
+
+If you do not know what this is, you do not need to know about it. The
+"yangtools" Yang parser from OpenDaylight uses a "code generator"
+component to generate specific kinds of Java classes from the Yang
+models. Again, if you do not need to work with the generated Java code,
+you do not need to change this.
+
+Create Example YANG File
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+This is likely the only field you will ever have any reason to change.
+If this checkbox is set, when the YANG IDE creates the Yang project, it
+will create a sample "acme-system.yang" file which you can view and edit
+to demonstrate the features of the tool to yourself. If you do not need
+this file, then either delete it from the project or uncheck the
+checkbox to prevent its creation.
+
+When done with the fields on this page, click the "Next" button to go to
+the next wizard page.
+
+Second Yang Project Wizard Page
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This page has a subtitle of "New Maven project". There are several
+fields on this page, but you will only ever have to see and change the
+setting of the first field, the "Create a simple project" checkbox. You
+should always set this ON to avoid the selection of a Maven archetype,
+which is something you do not need to do for creating a Yang project.
+
+Click "Next" at the bottom of the page to move to the next wizard page.
+
+Third Yang Project Wizard Page
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This also has a subtitle of "New Maven project", but with different
+fields to set. You will likely only ever set the first two fields, and
+completely ignore everything else.
+
+The first field is labeled "Group id" in the "Artifact" section. It
+really does not matter what you set this to, but it does have to be set
+to something. For consistency, you might set this to the name or
+nickname of your organization. Otherwise, there are no constraints on
+the value of this field.
+
+The second field is labeled "Artifact id". The value of this field will
+be used as the name of the project you create, so you will have to think
+about what you want the project to be called. Also note that this name
+has to be unique in the Eclipse workspace. You cannot have two projects
+with the same name.
+
+After you have set this field, you will notice that the "Next" button is
+insensitive, but now the "Finish" button is sensitive. You can click
+"Finish" now (or use the keyboard shortcut of "Alt+f"), and the Yang IDE
+will finally create your project.
+
+Creating a Yang File
+--------------------
+
+Now that you have created your project, it is time to create your first
+Yang file.
+
+When you created the Yang project, you might have noticed the other
+option next to "YANG Project", which was "YANG File". That is what you
+will select now. Click "Next" to go to the first wizard page.
+
+First Yang File Wizard Page
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This wizard page lets you specify where the new file will be located,
+and its name.
+
+You have to select the particular project you want the file to go into,
+and it needs to go into the "src/main/yang" folder (or a different
+location if you changed that field when creating the project).
+
+You then enter the desired name of the file in the "File name". The file
+name should have no spaces or "special characters" in it. You can
+specify a ".yang" extent if you want. If you do not specify an extent,
+the YANG IDE will create it with the ".yang" extent.
+
+Click "Next" to go to the next wizard page.
+
+Second Yang File Wizard Page
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+On this wizard page, you set some metadata about the module that is used
+to initialize the contents of the Yang file.
+
+It has the following fields:
+
+Module Name
+^^^^^^^^^^^
+
+This will default to the "base name" of the file name you created. For
+instance, if the file name you created was "network-setup.yang", this
+field will default to "network-setup". You should leave this value as
+is. There is no good reason to define a model with a name different from
+the file name.
+
+Namespace
+^^^^^^^^^
+
+This defaults to "urn:opendaylight:xxx", where "xxx" is the "base name"
+of the file name you created. You should put a lot of thought into
+designing a namespace naming scheme that is used throughout your
+organization. It is quite common for this namespace value to look like a
+"http" URL, but note that that is just a convention, and will not
+necessarily imply that there is a web page residing at that HTTP
+address.
+
+Prefix
+^^^^^^
+
+This defaults to the "base name" of the file name you created. It mostly
+does not technically matter what you set this to, as long as it is not
+empty. Conventionally, it should be a "nickname" that is used to refer
+to the given namespace in an abbreviated form, when referenced in an
+"import" statement in another Yang model file.
+
+Revision
+^^^^^^^^
+
+This has to be a date value in the form of "yyyy-mm-dd", representing
+the last modified date of this Yang model. The value will default to the
+current date.
+
+Revision Description
+^^^^^^^^^^^^^^^^^^^^
+
+This is just human-readable text, which will go into the "description"
+field underneath the Yang "revision" field, which will describe what
+went into this revision.
+
+When all the fields have the content you want, click the "Finish" button
+to set the YANG IDE create the file in the specified location. It will
+then present the new file in the editor view for additional
+modifications.
+
+Accessing Artifacts for Yang Model Imports
+------------------------------------------
+
+You might be working on Yang models that are "abstract" or are intended
+to be imported by other Yang models. You might also, and more likely, be
+working on Yang models that import other "abstract" Yang models.
+
+Assuming you are in that latter more common group, you need to consider
+for yourself, and for your organization, how you are going to get access
+to those models that you import.
+
+You could use a very simple and primitive approach of somehow obtaining
+those models from some source as plain files and just copying them into
+the "src/main/yang" folder of your project. For a simple demo or a
+"one-off" very short project, that might be sufficient.
+
+A more robust and maintainable approach would be to reference
+"coordinates" of the artifacts containing Yang models to import. When
+you specify unique coordinates associated with that artifact, the Yang
+IDE can retrieve the artifact in the background and make it available
+for your "import" statements.
+
+Those "coordinates" that I speak of refer to the Maven concepts of
+"group id", "artifact id", and "version". you may remember "group id"
+and "artifact id" from the wizard page for creating a Yang project. It
+is the same idea. If you ever produce Yang model artifacts that other
+people are going to import, you will want to think more about what you
+set those values to when you created the project.
+
+For example, the OpenDaylight project produces several importable
+artifacts that you can specify to get access to common Yang models.
+
+Turning on Indexing for Maven Repositories
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Before we talk about how to add dependencies to Maven artifacts with
+Yang models for import, I need to explain how to make it easier to find
+those artifacts.
+
+In the Yang project that you have created, the "pom.xml" file (also
+called a "POM file") is the file that Maven uses to specify
+dependencies. We will talk about that in a minute, but first we need to
+talk about "repositories". These are where artifacts are stored.
+
+We are going to have Eclipse show us the "Maven Repositories" view. In
+the main menu, select "Window" and then "Show View", and then "Other".
+Like in the "New" dialog, you can enter "maven" in the filter field to
+limit the list to views with "maven" in the name. Click on the "Maven
+Repositories" entry and click OK.
+
+This will usually create the view in the bottom panel of the window.
+
+The view presents an outline view of four principal elements:
+
+- Local Repositories
+
+- Global Repositories
+
+- Project Repositories
+
+- Custom Repositories
+
+For this purpose, the only section you care about is "Project
+Repositories", being the repositories that are only specified in the POM
+for the project. There should be a "right-pointing arrow" icon on the
+line. Click that to expand the entry.
+
+You should see two entries there:
+
+- opendaylight-release
+
+- opendaylight-snapshot
+
+You will also see internet URLs associated with each of those
+repositories.
+
+For this purpose, you only care about the first one. Right-click on that
+entry and select "Full Index Enabled". The first time you do this on the
+first project you create, it will spend several minutes walking the
+entire tree of artifacts available at that repository and "indexing" all
+of those components. When this is done, searching for available
+artifacts in that repository will go very quickly.
+
+Adding Dependencies Containing Yang Models
+------------------------------------------
+
+Double-click the "pom.xml" file in your project. Instead of just
+bringing up the view of an XML file (although you can see that if you
+like), it presents a GUI form editor with a handful of tabs.
+
+The first tab, "Overview", shows things like the "Group Id", "Artifact
+Id", and "Version", which represents the "Maven coordinate" of your
+project, which I have mentioned before.
+
+Now click on the "Dependencies" tab. You will now see two list
+components, labeled "Dependencies" and "Dependency Management". You only
+care about the "Dependencies" section.
+
+In the "Dependencies" section, you should see one dependency for an
+artifact called "yang-binding". This artifact is part of OpenDaylight,
+but you do not need to know anything about it.
+
+Now click the "Add" button.
+
+This brings up a dialog titled "Select Dependency". It has three fields
+at the top labeled "Group Id", "Artifact Id", and "Version", with a
+"Scope" dropdown. You will never have a need to change the "Scope"
+dropdown, so ignore it. Despite the fact that you will need to get
+values into these fields, in general usage, you will never have to
+manually enter values into them, but you will see values being inserted
+into these fields by the next steps I describe.
+
+Below those fields is a field labeled "Enter groupId, artifactId …".
+This is effectively a "filter field", like on the "New" dialog, but
+instead of limiting the list from a short list of choices, the value you
+enter there will be matched against all of the artifacts that were
+indexed in the "opendaylight-release" repository (and others). It will
+match the string you enter as a substring of any groupId or artifactId.
+
+For all of the entries that match that substring, it will list an entry
+showing the groupId and artifactId, with an expansion arrow. If you open
+it by clicking on the arrow, you will see individual entries
+corresponding to each available version of that artifact, along with
+some metadata about the artifacts between square brackets, mostly
+indicating what "type" of artifact is.
+
+For your purposes, you only ever want to use "bundle" or "jar"
+artifacts.
+
+Let us consider an example that many people will probably be using.
+
+In the filter field, enter "ietf-yang-types". Depending on what versions
+are available, you should see a small handful of "groupId, artifactId"
+entries there. One of them should be groupId
+"org.opendaylight.mdsal.model" and artifactId "ietf-yang-types". Click
+on the expansion arrow to open that.
+
+What you will see at this point depends on what versions are available.
+You will likely want to select the newest one (most likely top of the
+list) that is also either a "bundle" or "jar" type artifact.
+
+If you click on that resulting version entry, you should notice at this
+point that the "Group Id", "Artifact Id", and "Version" fields at the
+top of the dialog are now filled in with the values corresponding to
+this artifact and version.
+
+If this is the version that you want, click OK and this artifact will be
+added to the dependencies in the POM.
+
+This will now make the Yang models found in that artifact available in
+"import" statements in Yang models, not to mention the completion
+choices for that "import" statement.
+
== 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/
-* Description: Displays list of discovered WTPs and their basic attributes
-
-=== API Reference Documentation
-Go to 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.
-
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/capwap-developer-guide.html
== 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
-
-==== 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
-
-The Beryllium 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
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/didm-developer-guide.html
== DLUX
-=== Setup and Run
-==== Required Technology Stack
-* AngularJS (JavaScript client-side framework, http://www.angularjs.org )
-
-
-==== Run DLUX
-
-To turn on the DLUX UI, install DLUX core feature via running following command on the Karaf console -
-
- feature:install odl-dlux-core
-
-The above command will install odl-restconf and DLUX topology application internally, along with core DLUX components.
-Once this feature is successfully installed, access the UI at http://localhost:8181/index.html.
-The default credentials for login are admin/admin.
-
-All the applications in DLUX are Karaf features. A user can install other dlux applications such as node and yang-ui from Karaf
-console using commands such as -
-
-----
-$ feature:install odl-dlux-node
-
-$ feature:install odl-dlux-yangui
-----
-
-=== DLUX Modules
-
-DLUX modules are the individual features such as nodes and topology. Each module has a defined structure and you can find
-all existing modules at https://github.com/opendaylight/dlux/tree/stable/lithium/modules.
-
-==== Module Structure
-
- * module_folder
- ** <module_name>.module.js
- ** <module_name>.controller.js
- ** <module_name>.services.js
- ** <module_name>.directives.js
- ** <module_name>.filter.js
- ** index.tpl.html
- ** <a_stylesheet>.css
-
-==== Create New Module
-===== Define the module
-
-. Create an empty maven project and create your module folder under src/main/resources.
-. Create an empty file with pattern <module_name>.module.js.
-. Next, you need to surround the angular module with a define function. This allows RequireJs to see our module.js files.
- The first argument is an array which contains all the module's dependencies. The second argument is a callback function,
- whose body contain the AngularJS code base. The function parameters correspond with the order of dependencies. Each dependency is injected into a parameter, if it is provided.
-. Finally, you will return the angular module to be able to inject it as a parameter in others modules.
-
-For each new module, you must have at least these two dependencies :
-
-* angularAMD : It's a wrapper around AngularJS to provide an AMD (Asynchronous Module Definition) support, which is used by RequireJs. For more information see the https://github.com/amdjs/amdjs-api/blob/master/AMD.md[AMD documentation].
-* app/core/core.services : This one is mandatory, if you want to add content in the navigation menu, the left bar or the top bar.
-
-The following are not mandatory, but very often used.
-
-* angular-ui-router : A library to provide URL routing.
-* routingConfig : To set the level access to a page.
-
-Your module.js file might look like this:
-
- define(['angularAMD','app/routingConfig', 'angular-ui-router','app/core/core.services'], function(ng) {
- var module = angular.module('app.a_module', ['ui.router.state', 'app.core']);
- // module configuration
- module.config(function() {
- [...]
- });
- return module;
- });
-
-===== Set the register function
-AngularJS allows lazy registration of a module's components such as controller, factory etc. Once you will install your application,
-DLUX will load your module javascript, but not your angular component during bootstrap phase. You have to register your angular components
-to make sure they are available at the runtime.
-
-Here is how to register your module's component for lazy initialization -
-
- module.config(function($compileProvider, $controllerProvider, $provide) {
- module.register = {
- controller : $controllerProvider.register,
- directive : $compileProvider.directive,
- factory : $provide.factory,
- service : $provide.service
- };
- });
-
-===== Set the route
-The next step is to set up the route for your module. This part is also done in the configuration method of the module. We have to add *$stateProvider* as a parameter.
-
- module.config(function($stateProvider) {
- var access = routingConfig.accessLevels;
- $stateProvider.state('main.module', {
- url: 'module',
- views : {
- 'content' : {
- templateUrl: 'src/app/module/module.tpl.html',
- controller: 'ModuleCtrl'
- }
- }
- });
- });
-
-===== Adding element to the navigation menu
-To be able to add item to the navigation menu, the module requires the *NavHelperProvider* parameter in the configuration method.
-*addToMenu* method in *NavMenuHelper* helper allows an item addition to the menu.
-
- var module = angular.module('app.a_module', ['app.core']);
- module.config(function(NavMenuHelper) {
- NavMenuHelper.addToMenu('myFirstModule', {
- "link" : "#/module/index",
- "active" : "module",
- "title" : "My First Module",
- "icon" : "icon-sitemap",
- "page" : {
- "title" : "My First Module",
- "description" : "My first module"
- }
- });
- });
-
-The first parameter is an ID that refers to the level of your menu and the second is a object. For now, The ID parameter supports two levels of depth.
-If your ID looks like 'rootNode.childNode', the helper will look for a node named 'rootNode' and it will append the 'childNode' to it. If the root node doesn't exist, it will create it.
-
-
-===== Link the AngularJS module's controller file
-
-To include the module's controller file, you can use the NavHelperProvider. It contains a method that will load the given file.
-
- [...]
- NavHelperProvider.addControllerUrl('<path_to_module_folder>/<module_name>.controller');
-
-This completes your module.js file.
-
-
-==== Create the controller, factory, directive, etc
-
-Creating the controller and other components is similar to the module.
-
-* First, add the define method.
-* Second, add the relative path to the module definition.
-* Last, create your methods as you usually do it with AngularJS.
-
-For example -
-
- define(['<relative_path_to_module>/<module_name>.module'], function(module) {
- module.register.controller('ModuleCtrl', function($rootScope, $scope) {
- });
- });
-
-=== Add new application using DLUX modularity
-DLUX works as a Karaf based UI platform, where you can create a new Karaf feature of your UI component and install that UI applications in DLUX using blueprint.
-This page will help you to create and load a new application for DLUX. You don't have to add new module in DLUX repository.
-
-==== Add a new OSGi blueprint bundle
-The OSGi Blueprint Container specification allows us to use dependency injection in our OSGi environment. Each DLUX application module registers itself via blueprint configuration. Each application will have its own blueprint.xml to place its configuration.
-
-1. Create a maven project to place blueprint configuration. For reference, take a look at topology bundle, present at https://github.com/opendaylight/dlux/tree/stable/lithium/bundles/topology. All the existing DLUX modules' configurations are available under bundles directory of DLUX code.
-
-2. In pom.xml, you have to add a maven plugin to unpack your module code under generated-resources of this project. For reference, you can check pom.xml of dlux/bundles/topology at https://github.com/opendaylight/dlux/tree/stable/lithium/bundles/topology. Your bundle will eventually get deployed in Karaf as feature, so your bundle should contain all your module code. If you want to combine module and bundle project, that should not be an issue either.
-
-3. Create a blueprint.xml configuration file under src/main/resources/OSGI-INF/blueprint. Below is the content of the blueprint.xml taken from topology bundles's blueprint.xml. Any new application should create a blueprint.xml in following format -
-
-----
-<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
- <reference id="httpService" availability="mandatory" activation="eager" interface="org.osgi.service.http.HttpService"/>
- <reference id="loader" availability="mandatory" activation="eager" interface="org.opendaylight.dlux.loader.DluxModuleLoader"/>
-
- <bean id="bundle" init-method="initialize" destroy-method="clean" class="org.opendaylight.dlux.loader.DluxModule">
- <property name="httpService" ref="httpService"/>
- <property name="loader" ref="loader"/>
- <property name="moduleName" value="topology "/>
- <property name="url" value="/src/app/topology"/>
- <property name="directory" value="/topology"/>
- <property name="requireJs" value="app/topology/topology.module"/>
- <property name="angularJs" value="app.topology"/>
- <property name="cssDependencies">
- <list>
- <value>http://yui.yahooapis.com/3.18.1/build/cssreset/cssreset-min.css</value>
- <value>src/app/topology/topology-custom.css</value>
- </list>
- </property>
- </bean>
-</blueprint>
-----
-
-In above configuration, there are two references with id httpService and loader. These two beans will already be initialized by dlux-core, so any new application can use them. Without these two bean references, a new application will not be able to register.
-
-Next is the initialization of your application bean, which will be an instance of class org.opendaylight.dlux.loader.DluxModule. There are 5 properties that you should provide in this bean besides the references of httpService and loader. Lets talk about those bean properties in little more detail.
-
-*moduleName* : Name of your module. This name should be unique in DLUX.
-
-*url*: This is the url via which RequireJS in DLUX will try to load your module JS/HTML files. Also, this is the url that browser will use to load the static HTML, JS or CSS files. RequireJS in DLUX has a base path of *src*, so all the url should start with /src so RequireJS and the browser can correctly find the files.
-
-*directory*: In your bundle's pom.xml, you unpack your module code. This is the directory where your actual static files will reside. The above mentioned url is registered with httpService, so when browser makes a call to that url, it will be redirected to the directory mentioned here. In the above example, all the topology files are present under /topology directory and the browser/RequireJS can access those files with uri /src/app/topology.
-
-*requireJS*: This is the path to your RequireJS module. If you notice closely, you will see the initial path of RequireJS app/topology in the above example matches with the last part of url. This path will be be used by RequireJS. As mentioned above, we have kept *src* as base path in RequireJS, that is the exact reason that url start with /src.
-
-*angularJS*: name of your AngularJS module.
-
-*cssDependencies*: If the application has any external/internal css dependencies, then those can be added here. If you create your own css files, just point to those css files here. Use the url path that you mentioned above, so the browser can find your css file.
-
-OSGi understands blueprint.xml, once you will deploy your bundle in karaf (or you can create a new feature for your application), karaf will read your blueprint.xml and it will try to register your application with dlux. Once successful, if you refresh your dlux UI, you will see your application in left hand navigation bar of dlux.
-
-
-=== Yang Utils
-Yang Utils are used by UI to perform all CRUD operations. All of these utilities are present in yangutils.services.js file. It has following AngularJS factories -
-
-.Factories
-* *arrayUtils* – defines functions for working with arrays.
-* *pathUtils* – defines functions for working with xpath (paths to APIs and subAPIs). It divides xpath string to array of elements, so this array can be later used for search functions.
-* *syncFact* – provides synchronization between requests to and from OpenDaylight when it’s needed.
-* *custFunct* – it is linked with apiConnector.createCustomFunctionalityApis in yangui controller in yangui.controller.js. That function makes it possible to create some custom function called by the click on button in index.tpl.html. All custom functions are stored in array and linked to specific subAPI. When particular subAPI is expanded and clicked, its inputs (linked root node with its child nodes) are displayed in the bottom part of the page and its buttons with custom functionality are displayed also.
-* *reqBuilder* – Builds object in JSON format from input fields of the UI page. *Show Preview* button on Yang UI use this builder. This request is sent to OpenDaylight when button PUT or POST is clicked.
-* *yinParser* – factory for reading .xml files of yang models and creating object hierarchy. Every statement from yang is represented by a node.
-* *nodeWrapper* – adds functions to objects in tree hierarchy created with yinParser. These functions provide functionality for every type of node.
-* *apiConnector* – the main functionality is filling the main structures and linking them. Structure of APIs and subAPIs which is two level array - first level is filled by main APIs, second level is filled by others sub APIs. Second main structure is array of root nodes, which are objects including root node and its children nodes. Linking these two structures is creating links between every subAPI (second level of APIs array) and its root node, which must be displayed like inputs when subAPI is expanded.
-* *yangUtils* – some top level functions which are used by yangui controller for creating the main structures.
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/dlux.html
== 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
-
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/l2switch-developer-guide.html
== 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.
-
-[options="header"]
-|=================================
-|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:
-
-[options="header"]
-|========================================
-|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,
-
-[options="header"]
-|===============================================
-|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.
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/lacp-developer-guide.html
== Neutron Northbound
-=== How to add new API support
-OpenStack Neutron is a moving target. It is continuously adding new features
-as new rest APIs. Here is a basic step to add new API support:
-
-In the Neutron Northbound project:
-
-* Add new YANG model for it under `neutron/model/src/main/yang` and
- `update neutron.yang`
-* Add northbound API for it, and neutron-spi
-** Implement `Neutron<New API>Request.java` and `Neutron<New API>Norhtbound.java`
- under
- `neutron/northbound-api/src/main/java/org/opendaylight/neutron/northbound/api/`
-** Implement `INeutron<New API>CRUD.java` and new data structure if any under
- `neutron/neutron-spi/src/main/java/org/opendaylight/neutron/spi/`
-** update
- `neutron/neutron-spi/src/main/java/org/opendaylight/neutron/spi/NeutronCRUDInterfaces.java`
- to wire new CRUD interface
-** Add unit tests, `Neutron<New structure>JAXBTest.java` under
- `neutron/neutron-spi/src/test/java/org/opendaylight/neutron/spi/`
-* update
- `neutron/northbound-api/src/main/java/org/opendaylight/neutron/northbound/api/NeutronNorthboundRSApplication.java`
- to wire new northbound api to `RSApplication`
-* Add transcriber, `Neutron<New API>Interface.java` under
- `transcriber/src/main/java/org/opendaylight/neutron/transcriber/`
-* update
- `transcriber/src/main/java/org/opendaylight/neutron/transcriber/NeutronTranscriberProvider.java`
- to wire a new transcriber
-** Add integration tests `Neutron<New API>Tests.java`
- under `integration/test/src/test/java/org/opendaylight/neutron/e2etest/`
-** update `integration/test/src/test/java/org/opendaylight/neutron/e2etest/ITNeutronE2E.java`
- to run a newly added tests.
-
-In OpenStack networking-odl
-
-* Add new driver (or plugin) for new API with tests.
-
-In a southbound Neutron Provider
-
-* implement actual backend to realize those new API by listening related YANG
- models.
-
-
-=== How to write transcriber
-
-For each Neutron data object, there is an `Neutron*Interface` defined within
-the transcriber artifact that will write that object to the MD-SAL
-configuration datastore.
-
-All `Neutron*Interface` extend `AbstractNeutronInterface`, in which two methods
-are defined:
-
-* one takes the Neutron object as input, and will create a data object from it.
-* one takes an uuid as input, and will create a data object containing the uuid.
-
-----
-protected abstract T toMd(S neutronObject);
-protected abstract T toMd(String uuid);
-----
-
-In addition the `AbstractNeutronInterface` class provides several other
-helper methods (`addMd`, `updateMd`, `removeMd`), which handle the actual
-writing to the configuration datastore.
-
-==== The semantics of the `toMD()` methods
-Each of the Neutron YANG models defines structures containing data.
-Further each YANG-modeled structure has it own builder.
-A particular `toMD()` method instantiates an instance of the correct
-builder, fills in the properties of the builder from the corresponding
-values of the Neutron object and then creates the YANG-modeled structures
-via the `build()` method.
-
-As an example, one of the `toMD` code for Neutron Networks is
-presented below:
-
-----
-protected Network toMd(NeutronNetwork network) {
- NetworkBuilder networkBuilder = new NetworkBuilder();
- networkBuilder.setAdminStateUp(network.getAdminStateUp());
- if (network.getNetworkName() != null) {
- networkBuilder.setName(network.getNetworkName());
- }
- if (network.getShared() != null) {
- networkBuilder.setShared(network.getShared());
- }
- if (network.getStatus() != null) {
- networkBuilder.setStatus(network.getStatus());
- }
- if (network.getSubnets() != null) {
- List<Uuid> subnets = new ArrayList<Uuid>();
- for( String subnet : network.getSubnets()) {
- subnets.add(toUuid(subnet));
- }
- networkBuilder.setSubnets(subnets);
- }
- if (network.getTenantID() != null) {
- networkBuilder.setTenantId(toUuid(network.getTenantID()));
- }
- if (network.getNetworkUUID() != null) {
- networkBuilder.setUuid(toUuid(network.getNetworkUUID()));
- } else {
- logger.warn("Attempting to write neutron network without UUID");
- }
- return networkBuilder.build();
-}
-----
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/neutron-northbound.html
== Neutron Service Developer Guide
-=== Overview
-This Karaf feature (`odl-neutron-service`) provides integration support for OpenStack Neutron
-via the OpenDaylight ML2 mechanism driver. The Neutron Service is only one of the
-components necessary for OpenStack integration.
-It defines YANG models for OpenStack Neutron data models and northbound
-API via REST API and YANG model RESTCONF.
-
-Those developers who want to add new provider for new OpenStack Neutron
-extensions/services (Neutron constantly adds new extensions/services and OpenDaylight
-will keep up with those new things) need to communicate with this Neutron
-Service or add models to Neutron Service.
-If you want to add new extensions/services themselves to the Neutron Service,
-new YANG data models need to be added, but that is out of scope of this document
-because this guide is for a developer who will be _using_ the feature
-to build something separate, but _not_ somebody who will be developing
-code for this feature itself.
-
-=== Neutron Service Architecture
-image::neutron/odl-neutron-service-developer-architecture.png[height="450px", width="550px", title="Neutron Service Architecture"]
-// image original: https://docs.google.com/drawings/d/15xtroJahSFt93K10Zp8AVln_WZgowmhv7MC_2VdZQzg/edit?usp=sharing
-
-The Neutron Service defines YANG models for OpenStack Neutron integration.
-When OpenStack admins/users request changes (creation/update/deletion)
-of Neutron resources, e.g., Neutron network, Neutron subnet, Neutron port, the corresponding YANG model within OpenDaylight will be modified.
-The OpenDaylight OpenStack will subscribe the changes on those models and
-will be notified those modification through MD-SAL when changes are made.
-Then the provider will do the necessary tasks to realize OpenStack integration.
-How to realize it (or even not realize it) is up to each provider.
-The Neutron Service itself does not take care of it.
-
-=== How to Write a SB Neutron Consumer
-In Boron, there is only one options for SB Neutron Consumers:
-
-* Listening for changes via the Neutron YANG model
-
-Until Beryllium there was another way with the legacy I*Aware interface.
-From Boron, the interface was eliminated. So all the SB Neutron Consumers
-have to use Neutron YANG model.
-
-
-=== Neutron YANG models
-Neutron service defines YANG models for Neutron. The details can be found
-at
-
-* https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=tree;f=model/src/main/yang;hb=refs/heads/stable/boron
-
-Basically those models are based on OpenStack Neutron API definitions.
-For exact definitions, OpenStack Neutron source code needs to be referred
-as the above documentation doesn't always cover the necessary details.
-There is nothing special to utilize those Neutron YANG models.
-The basic procedure will be:
-
-. subscribe for changes made to the the model
-. respond on the data change notification for each models
-
-[NOTE]
-Currently there is no way to refuse the request configuration at this
-point. That is left to future work.
-
-[source,java]
-----
-public class NeutronNetworkChangeListener implements DataChangeListener, AutoCloseable {
- private ListenerRegistration<DataChangeListener> registration;
- private DataBroker db;
-
- public NeutronNetworkChangeListener(DataBroker db){
- this.db = db;
- // create identity path to register on service startup
- InstanceIdentifier<Network> path = InstanceIdentifier
- .create(Neutron.class)
- .child(Networks.class)
- .child(Network.class);
- LOG.debug("Register listener for Neutron Network model data changes");
- // register for Data Change Notification
- registration =
- this.db.registerDataChangeListener(LogicalDatastoreType.CONFIGURATION, path, this, DataChangeScope.ONE);
-
- }
-
- @Override
- public void onDataChanged(
- AsyncDataChangeEvent<InstanceIdentifier<?>, DataObject> changes) {
- LOG.trace("Data changes : {}",changes);
-
- // handle data change notification
- Object[] subscribers = NeutronIAwareUtil.getInstances(INeutronNetworkAware.class, this);
- createNetwork(changes, subscribers);
- updateNetwork(changes, subscribers);
- deleteNetwork(changes, subscribers);
- }
-}
-----
-
-=== Neutron configuration
-From Boron, new models of configuration for OpenDaylight to tell
-OpenStack neutron/networking-odl its configuration/capability.
-
-==== hostconfig
-This is for OpenDaylight to tell per-node configuration to Neutron.
-Especially this is used by pseudo agent port binding heavily.
-
-The model definition can be found at
-
-* https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=model/src/main/yang/neutron-hostconfig.yang;hb=refs/heads/stable/boron
-
-How to populate this for pseudo agent port binding is documented at
-
-* http://git.openstack.org/cgit/openstack/networking-odl/tree/doc/source/devref/hostconfig.rst
-
-==== Neutron extension config
-In Boron this is experimental.
-The model definition can be found at
-
-* https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=model/src/main/yang/neutron-extensions.yang;hb=refs/heads/stable/boron
-
-Each Neutron Service provider has its own feature set. Some support
-the full features of OpenStack, but others support only a subset.
-With same supported Neutron API, some functionality may or may not be
-supported. So there is a need for a way that OpenDaylight can tell networking-odl its
-capability. Thus networking-odl can initialize Neutron properly based
-on reported capability.
-
-
-=== Neutorn Logger
-There is another small Karaf feature, `odl-neutron-logger`, which logs changes of Neutron
-YANG models. which can be used for debug/audit.
-
-It would also help to understand how to listen the change.
-
-* https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=neutron-logger/src/main/java/org/opendaylight/neutron/logger/NeutronLogger.java;hb=refs/heads/stable/boron
-
-
-=== API Reference Documentation
-The OpenStack Neutron API references
-
-* http://developer.openstack.org/api-ref-networking-v2.html
-* http://developer.openstack.org/api-ref-networking-v2-ext.html
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/neutron-service-developer-guide.html
== 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:
-
-.MPLS VPN Service Diagram
-image::nic/MPLS_VPN_Service_Diagram.png[MPLS VPN Service Diagram,width=500]
-
-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
- feature:install odl-dlux-all odl-dlux-core odl-dlux-yangui odl-dlux-yangvisualizer
-+
-2. Start mininet topology and verify in DLUX Topology page for the nodes and link.
-+
- 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 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
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/network-intent-composition-(nic)-developer-guide.html
+++ /dev/null
-==== bundle-parent
-This inherits from +odlparent+ and enables functionality useful for OSGi bundles: +
-
-* +maven-javadoc-plugin+ is activated, to build the Javadoc JAR;
-* +maven-source-plugin+ is activated, to build the source JAR;
-* +maven-bundle-plugin+ is activated (including extensions), to build OSGi bundles (using the “bundle” packaging).
-
-In addition to this, JUnit is included as a default dependency in “test” scope.
== ODL Parent Developer Guide
-include::odlparent-parents-developer.adoc[]
-
-include::odlparent-features-developer.adoc[]
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/odl-parent-developer-guide.html
+++ /dev/null
-=== Features
-
-The ODL Parent component for OpenDaylight provides a number of Karaf features which can be used by other Karaf features
-to use certain third-party upstream dependencies.
-
-These features are: +
-
-* Akka features (in the +features-akka+ repository): +
-** +odl-akka-all+ — all Akka bundles;
-** +odl-akka-scala+ — Scala runtime for OpenDaylight;
-** +odl-akka-system+ — Akka actor framework bundles;
-** +odl-akka-clustering+ — Akka clustering bundles and dependencies;
-** +odl-akka-leveldb+ — LevelDB;
-** +odl-akka-persistence+ — Akka persistence;
-* general third-party features (in the +features-odlparent+ repository):
-** +odl-netty+ — all Netty bundles;
-** +odl-guava+ — Guava;
-** +odl-lmax+ — LMAX Disruptor.
-
-To use these, you need to declare a dependency on the appropriate repository in your +features.xml+ file:
-
---------------------------------------
-<repository>mvn:org.opendaylight.odlparent/features-odlparent/{{VERSION}}/xml/features</repository>
---------------------------------------
-
-and then include the feature, _e.g._:
-
---------------------------------------
-<feature name='odl-mdsal-broker-local' version='${project.version}' description="OpenDaylight :: MDSAL :: Broker">
- [...]
- <feature version='[3.3.0,4.0.0)'>odl-lmax</feature>
- [...]
-</feature>
---------------------------------------
-
-You also need to depend on the features repository in your POM:
-
---------------------------------------
-<dependency>
- <groupId>org.opendaylight.odlparent</groupId>
- <artifactId>features-odlparent</artifactId>
- <classifier>features</classifier>
- <type>xml</type>
-</dependency>
---------------------------------------
-
-assuming the appropriate dependency management:
-
---------------------------------------
-<dependencyManagement>
- <dependencies>
- <dependency>
- <groupId>org.opendaylight.odlparent</groupId>
- <artifactId>odlparent-artifacts</artifactId>
- <version>1.7.0-SNAPSHOT</version>
- <scope>import</scope>
- <type>pom</type>
- </dependency>
- </dependencies>
-</dependencyManagement>
---------------------------------------
-
-(the version number there is appropriate for Boron). For the time being you also need to depend separately on the
-individual JARs as compile-time dependencies to build your dependent code; the relevant dependencies are managed in
-+odlparent+'s dependency management.
-
-The suggested version ranges are as follows: +
-
-* +odl-netty+: +[4.0.37,4.1.0)+ or +[4.0.37,5.0.0)+;
-* +odl-guava+: +[18,19)+ (if your code is ready for it, +[19,20)+ is also available, but the current default version of
- Guava in OpenDaylight is 18);
-* +odl-lmax+: +[3.3.4,4.0.0)+
+++ /dev/null
-==== features-parent
-This inherits from +odlparent+ and enables functionality useful for Karaf features: +
-
-* +karaf-maven-plugin+ is activated, to build Karaf features — but for OpenDaylight, projects need to use “jar”
- packaging (**not** “kar”);
-* +features.xml+ files are processed from templates stored in +src/main/features/features.xml+;
-* Karaf features are tested after build to ensure they can be activated in a Karaf container.
-
-The +features.xml+ processing allows versions to be ommitted from certain feature dependencies, and replaced with
-“+{{VERSION}}+”. For example:
-
---------------------------------------
-<features name="odl-mdsal-${project.version}" xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.2.0 http://karaf.apache.org/xmlns/features/v1.2.0">
-
- <repository>mvn:org.opendaylight.odlparent/features-odlparent/{{VERSION}}/xml/features</repository>
-
- [...]
- <feature name='odl-mdsal-broker-local' version='${project.version}' description="OpenDaylight :: MDSAL :: Broker">
- <feature version='${yangtools.version}'>odl-yangtools-common</feature>
- <feature version='${mdsal.version}'>odl-mdsal-binding-dom-adapter</feature>
- <feature version='${mdsal.model.version}'>odl-mdsal-models</feature>
- <feature version='${project.version}'>odl-mdsal-common</feature>
- <feature version='${config.version}'>odl-config-startup</feature>
- <feature version='${config.version}'>odl-config-netty</feature>
- <feature version='[3.3.0,4.0.0)'>odl-lmax</feature>
- [...]
- <bundle>mvn:org.opendaylight.controller/sal-dom-broker-config/{{VERSION}}</bundle>
- <bundle start-level="40">mvn:org.opendaylight.controller/blueprint/{{VERSION}}</bundle>
- <configfile finalname="${config.configfile.directory}/${config.mdsal.configfile}">mvn:org.opendaylight.controller/md-sal-config/{{VERSION}}/xml/config</configfile>
- </feature>
---------------------------------------
-
-As illustrated, versions can be ommitted in this way for repository dependencies, bundle dependencies and configuration
-files. They must be specified traditionally (either hard-coded, or using Maven properties) for feature dependencies.
+++ /dev/null
-==== odlparent
-This inherits from +odlparent-lite+ and mainly provides dependency and plugin management for OpenDaylight projects.
-
-If you use any of the following libraries, you should rely on +odlparent+ to provide the appropriate versions: +
-
-* Akka (and Scala)
-* Apache Commons: +
-** +commons-codec+
-** +commons-fileupload+
-** +commons-io+
-** +commons-lang+
-** +commons-lang3+
-** +commons-net+
-* Apache Shiro
-* Guava
-* JAX-RS with Jersey
-* JSON processing: +
-** GSON
-** Jackson
-* Logging: +
-** Logback
-** SLF4J
-* Netty
-* OSGi: +
-** Apache Felix
-** core OSGi dependencies (+core+, +compendium+...)
-* Testing: +
-** Hamcrest
-** JSON assert
-** JUnit
-** Mockito
-** Pax Exam
-** PowerMock
-* XML/XSL: +
-** Xerces
-** XML APIs
-
-[NOTE]
-This list isn't exhaustive.
-It's also not cast in stone; if you'd like to add a new dependency (or migrate a dependency), please contact
-https://lists.opendaylight.org/mailman/listinfo/odlparent-dev[the mailing list].
-
-+odlparent+ also enforces some Checkstyle verification rules. In particular, it enforces the common license header
-used in all OpenDaylight code:
-
---------------------------------------
-/*
- * Copyright © ${year} ${holder} and others. All rights reserved.
- *
- * This program and the accompanying materials are made available under the
- * terms of the Eclipse Public License v1.0 which accompanies this distribution,
- * and is available at http://www.eclipse.org/legal/epl-v10.html
- */
---------------------------------------
-
-where “+${year}+” is initially the first year of publication, then (after a year has passed) the first and latest years
-of publication, separated by commas (_e.g._ “2014, 2016”), and “+${holder}+” is the initial copyright holder (typically,
-the first author's employer).
-“All rights reserved” is optional.
-
-If you need to disable this license check, _e.g._ for files imported under another license (EPL-compatible of course),
-you can override the +maven-checkstyle-plugin+ configuration. +features-test+ does this for its
-+CustomBundleUrlStreamHandlerFactory+ class, which is ASL-licensed:
-
---------------------------------------
-<plugin>
- <artifactId>maven-checkstyle-plugin</artifactId>
- <executions>
- <execution>
- <id>check-license</id>
- <goals>
- <goal>check</goal>
- </goals>
- <phase>process-sources</phase>
- <configuration>
- <configLocation>check-license.xml</configLocation>
- <headerLocation>EPL-LICENSE.regexp.txt</headerLocation>
- <includeResources>false</includeResources>
- <includeTestResources>false</includeTestResources>
- <sourceDirectory>${project.build.sourceDirectory}</sourceDirectory>
- <excludes>
- <!-- Skip Apache Licensed files -->
- org/opendaylight/odlparent/featuretest/CustomBundleUrlStreamHandlerFactory.java
- </excludes>
- <failsOnError>false</failsOnError>
- <consoleOutput>true</consoleOutput>
- </configuration>
- </execution>
- </executions>
-</plugin>
---------------------------------------
+++ /dev/null
-==== odlparent-lite
-This is the base parent for all OpenDaylight Maven projects and modules. It provides the following, notably to allow
-publishing artifacts to Maven Central: +
-
-* license information;
-* organization information;
-* issue management information (a link to our Bugzilla);
-* continuous integration information (a link to our Jenkins setup);
-* default Maven plugins (+maven-clean-plugin+, +maven-deploy-plugin+, +maven-install-plugin+,
- +maven-javadoc-plugin+ with HelpMojo support, +maven-project-info-reports-plugin+, +maven-site-plugin+ with
- Asciidoc support, +jdepend-maven-plugin+);
-* distribution management information.
-
-It also defines two profiles which help during development:
-
-* +q+ (+-Pq+), the quick profile, which disables tests, code coverage, Javadoc generation, code analysis, etc. —
- anything which isn't necessary to build the bundles and features (see
- http://blog2.vorburger.ch/2016/06/improve-maven-build-speed-with-q.html[this blog post] for details);
-* +addInstallRepositoryPath+ (+-DaddInstallRepositoryPath=.../karaf/system+) which can be used to drop a bundle
- in the appropriate Karaf location, to enable hot-reloading of bundles during development (see
- http://blog2.vorburger.ch/2016/06/maven-install-into-additional.html[this blog post] for details).
-
-For modules which don't produce any useful artifacts (_e.g._ aggregator POMs), you should add the following to avoid
-processing artifacts:
-
---------------------------------------
-<build>
- <plugins>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-deploy-plugin</artifactId>
- <configuration>
- <skip>true</skip>
- </configuration>
- </plugin>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-install-plugin</artifactId>
- <configuration>
- <skip>true</skip>
- </configuration>
- </plugin>
- </plugins>
-</build>
---------------------------------------
+++ /dev/null
-=== Parent POMs
-
-==== Overview
-The ODL Parent component for OpenDaylight provides a number of Maven parent POMs which allow Maven projects to be
-easily integrated in the OpenDaylight ecosystem.
-Technically, the aim of projects in OpenDaylight is to produce Karaf features, and these parent projects provide common
-support for the different types of projects involved.
-
-These parent projects are: +
-
-* +odlparent-lite+ — the basic parent POM for Maven modules which don't produce artifacts (_e.g._ aggregator POMs)
-* +odlparent+ — the common parent POM for Maven modules containing Java code
-* +bundle-parent+ — the parent POM for Maven modules producing OSGi bundles
-* +features-parent+ — the parent POM for Maven modules producing Karaf features
-
-include::odlparent-odlparent-lite-developer.adoc[]
-
-include::odlparent-odlparent-developer.adoc[]
-
-include::odlparent-bundle-parent-developer.adoc[]
-
-include::odlparent-features-parent-developer.adoc[]
== OpFlex agent-ovs Developer Guide
-=== Overview
-agent-ovs is a policy agent that works with OVS to enforce a
-group-based policy networking model with locally attached virtual
-machines or containers. The policy agent is designed to work well with
-orchestration tools like OpenStack.
-
-=== agent-ovs Architecture
-agent-ovs uses libopflex to communicate with an OpFlex-based policy
-repository to enforce policy on network endpoints attached to OVS by
-an orchestration system.
-
-The key components are:
-
-* Agent - coordinates startup and configuration
-* Renderers - Renderers are responsible for rendering policy. This is
- a very general mechanism but the currently-implemented renderer is
- the stitched-mode renderer that can work along with with hardware
- fabrics such as ACI that support policy enforcement.
-* EndpointManager - Keep track of network endpoints and declare them
- to the endpoint repository
-* PolicyManager - Keep track of and index policies
-* FlowManager - render policies to OVS
-
-=== API Reference Documentation
-Internal API documentation can be found here:
-https://jenkins.opendaylight.org/opflex/job/opflex-merge/ws/agent-ovs/doc/html/index.html
\ No newline at end of file
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/opflex-agent-ovs-developer-guide.html
== OpFlex genie Developer Guide
-=== Overview
-Genie is a tool for code generation from a model. It supports
-generating C\++ and Java code. C++ can be generated suitable for use
-with libopflex. C++ and Java can be generated as a plain set of
-objects.
-
-=== Group-based Policy Model
-The group-based policy model is included with the genie tool and can
-be found under the MODEL directory. By running mvn exec:java,
-libmodelgbp will be generated as a library project that, when built
-and installed, will work with libopflex. This model is used by the
-OVS agent.
-
-=== API Reference Documentation
-Complete API documentation for the generated libmodelgbp can be found here:
-https://jenkins.opendaylight.org/opflex/job/opflex-merge/ws/libopflex/doc/html/index.html
\ No newline at end of file
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/opflex-genie-developer-guide.html
== OpFlex libopflex Developer Guide
-=== Overview
-The OpFlex framework allows you to develop agents that can communicate
-using the OpFlex protocol and act as a policy element in an
-OpFlex-based distributed control system. The OpFlex architecture
-provides a distributed control system based on a declarative policy
-information model. The policies are defined at a logically centralized
-policy repository and enforced within a set of distributed policy
-elements. The policy repository communicates with the subordinate
-policy elements using the OpFlex control protocol. This protocol
-allows for bidirectional communication of policy, events, statistics,
-and faults.
-
-Rather than simply providing access to the OpFlex protocol, this
-framework allows you to directly manipulate a management information
-tree containing a hierarchy of managed objects. This tree is kept in
-sync as needed with other policy elements in the system, and you are
-automatically notified when important changes to the model
-occur. Additionally, we can ensure that only those managed objects
-that are important to the local policy element are synchronized
-locally.
-
-==== Object Model
-
-Interactions with the OpFlex framework happen through the management
-information tree. This is a tree of managed objects defined by an
-object model specific to your application. There are a few important
-major category of objects that can appear in the model.
-
-* First, there is the policy object. A policy object represents some
- data related to a policy that describes a user intent for how the
- system should behave. A policy object is stored in the policy
- repository which is the source of "truth" for this object.
-* Second, there is an endpoint object. A endpoint represents an entity
- in the system to which we want to apply policy, which could be a
- network interface, a storage array, or other relevent policy
- endpoint. Endpoints are discovered and reported by policy elements
- locally, and are synchronized into the endpoint repository. The
- originating policy element is the source of truth for the endpoints
- it discovers. Policy elements can retrieve information about
- endpoints discovered by other policy elements by resolving endpoints
- from the endpoint repository.
-* Third, there is the observable object. An observable object
- represents some state related to the operational status or health of
- the policy element. Observable objects will be reported to the
- observer.
-* Finally, there is the local-only object. This is the simplest object
- because it exists only local to a particular policy element. These
- objects can be used to store state specific to that policy element,
- or as helpers to resolve other objects. Read on to learn more.
-
-You can use the genie tool that is included with the framework to
-produce your application model along with a set of generated accessor
-classes that can work with this framework library. You should refer to
-the documentation that accompanies the genie tool for information on
-how to use to to generate your object model. Later in this guide,
-we'll go through examples of how to use the generated managed object
-accessor classes.
-
-==== Programming by Side Effect
-
-When developing software on the OpFlex framework, you'll need to think
-in a slightly different way. Rather than calling an API function that
-would perform some specific action, you'll need to write a managed
-object to the managed object database. Writing that object to the
-store will trigger the side effect of performing the action that you
-want.
-
-For example, a policy element will need to have a component
-responsible for discovering policy endpoints. When it discovers a
-policy endpoint, it would write an endpoint object into the managed
-object database. That endpoint object will contain a reference to
-policy that is relevant to the endpoint object. This will trigger a
-whole cascade of events. First, the framework will notice that an
-endpoint object has been created and it will write it to the endpoint
-repository. Second, the framework to will attempt to resolve the
-unresolved reference to the relevent policy object. There might be a
-whole chain of policy resolutions that will be automatically performed
-to download all the relevent policy until there are no longer any
-dangling references.
-
-As long as there is a locally-created object in the system with a
-reference to that policy, the framework will continually ensure that
-the policy and any transitive policies are kept up to date. The policy
-element can subscribe to updates to these policy classes that will be
-invoked either the first time the policy is resolved or any time the
-policy changes.
-
-A consequence of this design is that the managed object database can
-be temporarily in an inconsistent state with unresolved dangling
-references. Eventually, however, the inconsistency will be fully
-resolved. The policy element must be able to cleanly handle
-partially-resolved or inconsistent state and eventually reach the
-correct state as it receives these update notifications. Note that, in
-the OpFlex architecture, when there is no policy that specifically
-allows a particular action, that action must be prevented.
-
-Let's cover one slightly more complex example. If a policy element
-needs to discover information about an endpoint that is not local to
-that policy element, it will need to retrieve that information from
-the endpoint repository. However, just as there is no API call to
-retrieve a policy object from the policy repository, there is no API
-call to retrieve an endpoint from the endpoint repository.
-
-To get this information, the policy element needs to create a
-local-only object that references the endpoint. Once it creates this
-local-only object, if the endpoint is not already resolved, the
-framework will notice the dangling reference and automatically resolve
-the endpoint from the endpoint respository. When the endpoint
-resolution completes, the framework deliver an update notification to
-the policy element. The policy element will continue to receive any
-updates related to that endpoint until the policy element remove the
-local-only reference to the object. Once this occurs, the framework
-can garbage-collect any unreferenced objects.
-
-==== Threading and Ownership
-The OpFlex framework uses a somewhat unique threading model. Each
-managed object in the system belongs to a particular owner. An owner
-would typically be a single thread that is reponsible for all updates
-to objects with that owner. Though anything can read the state of a
-managed object, only the owner of a managed object is permitted to
-write to it. Though this is not strictly required for correctness, the
-performance of the system wil be best if you ensure that only one
-thread at a time is writing to objects with a particular owner.
-
-Change notifications are delivered in a serialized fashion by a single
-thread. Blocking this thread from a notification callback will stall
-delivery of all notifications. It is therefore best practice to ensure
-that you do not block or perform long-running operations from a
-notification callback.
-
-=== Key APIs and Interfaces
-==== Basic Usage and Initialization
-The primary interface point into the framework is
-opflex::ofcore::OFFramework. You can choose to instantiate your own
-copy of the framework, or you can use the static default instance.
-
-Before you can use the framework, you must initialize it by installing
-your model metadata. The model metadata is accessible through the
-generated model library. In this case, it assumes your model is called
-"mymodel":
-
-[source,cpp]
-----
-#include <opflex/ofcore/OFFramework.h>
-#include <mymodel/metadata/metadata.hpp>
-// ...
-using opflex::ofcore::OFFramework;
-OFFramework::defaultInstance().setModel(mymodel::getMetadata());
-----
-
-The other critical piece of information required for initialization is
-the OpFlex identity information. The identity information is required
-in order to successfully connect to OpFlex peers. In OpFlex, each
-component has a unique name within its policy domain, and each policy
-domain is identified by a globally unique domain name. You can set
-this identity information by calling:
-
-[source,cpp]
-----
-OFFramework::defaultInstance()
- .setOpflexIdentity("[component name]", "[unique domain]");
-----
-You can then start the framework simply by calling:
-
-[source,cpp]
-----
-OFFramework::defaultInstance().start();
-----
-
-Finally, you can add peers after the framework is started by calling
-the +opflex::ofcore::OFFramework::addPeer+ method:
-
-[source,cpp]
-----
-OFFramework::defaultInstance().addPeer("192.168.1.5", 1234);
-----
-
-When connecting to the peer, that peer may provide an additional list
-of peers to connect to, which will be automatically added as peers. If
-the peer does not include itself in the list, then the framework will
-disconnect from that peer and add the peers in the list. In this way,
-it is possible to automatically bootstrap the correct set of peers
-using a known hostname or IP address or a known, fixed anycast IP
-address.
-
-To cleanly shut down, you can call:
-
-[source,cpp]
-----
-OFFramework::defaultInstance().stop();
-----
-
-==== Working with Data in the Tree
-===== Reading from the Tree
-
-You can access data in the managed tree using the generated accessor
-classes. The details of exactly which classes you'll use will depend
-on the model you're using, but let's assume that we have a simple
-model called "simple" with the following classes:
-
-* root - The root node. The URI for the root node is "/"
-* foo - A policy object, and a child of root, with a scalar string
- property called "bar", and a unsigned 64-bit integer property called
- baz. The bar property is the naming property for foo. The URI for a
- foo object would be "/foo/[value of bar]/"
-* fooref - A local-only child of root, with a reference to a foo, and
- a scalar string property called "bar". The bar property is the
- naming property for foo. The URI for a fooref object would be
- "/fooref/[value of bar]/"
-
-In this example, we'll have a generated class for each of the
-objects. There are two main ways to get access to an object in the
-tree.
-
-First, we can get instantiate an accessor class to any node in the
-tree by calling one of its static resolve functions. The resolve
-functions can take either an already-built URI that represents the
-object, or you can call the version that will locate the object by its
-naming properties.
-
-Second, we can access the object also from its parent object using the
-appropriate child resolver member functions.
-
-However we read it, the object we get back is an immutable view into
-the object it references. The properties set locally on that object
-will not change even though the underlying object may have been
-updated in the store. Note, however, that its children can change
-between when you first retrieve the object and when you resolve any
-children.
-
-Another thing that is critical to note again is that when you attempt
-to resolve an object, you can get back nothing, even if the object
-actually does exist on another OpFlex node. You must ensure that some
-object in the managed object database references the remote managed
-object you want before it will be visible to you.
-
-To get access to the root node using the default framework instance,
-we can simply call:
-
-[source,cpp]
-----
-using boost::shared_ptr;
-using boost::optional;
-optional<shared_ptr<simple::root> > r(simple::root::resolve());
-----
-
-Note that whenever we can a resolve function, we get back our data in
-the form of an optional shared pointer to the object instance. If the
-node does not exist, then the optional will be set to
-boost::none. Note that if you dereference an optional that has not
-been set, you'll trigger an assert, so you must check the return as
-follows:
-
-[source,cpp]
-----
-if (!r) {
- // handle missing object
-}
-----
-Now let's get a child node of the root in three different ways:
-
-[source,cpp]
-----
-// Get foo1 by constructing its URI from the root
-optional<shared_ptr<simple::foo> > foo1(simple::foo::resolve("test"));
-// get foo1 by constructing its URI relative to its parent
-foo1 = r.get()->resolveFoo("test");
-// get foo1 by manually building its URI
-foo1 = simple::foo::resolve(opflex::modb::URIBuilder()
- .addElement("foo")
- .addElement("test")
- .build());
-----
-
-All three of these calls will give us the same object, which is the
-"foo" object located at "/foo/test/".
-
-The foo class has a single string property called "bar". We can easily
-access it as follows:
-
-[source,cpp]
-----
-const std::string& barv = foo1.getBar();
-----
-
-===== Writing to the Tree
-Writing to the tree is nearly as easy as reading from it. The key
-concept to understand is the mutator object. If you want to make
-changes to the tree, you must allocate a mutator object. The mutator
-will register itself in some thread-local storage in the framework
-instance you're using. The mutator is specific to a single "owner" for
-the data, so you can only make changes to data associated with that
-owner.
-
-Whenever you modify one of the accessor classes, the change is
-actually forwarded to the currently-active mutator. You won't see any
-of the changes you make until you call the commit member function on
-the mutator. When you do that, all the changes you made are written
-into the store.
-
-Once the changes are written into the store, you will need to call the
-appropriate resolve function again to see the changes.
-
-Allocating a mutator is simple. To create a mutator for the default
-framework instance associated with the owner "owner1", just allocate
-the mutator on the stack. Be sure to call commit() before it goes out
-of scope or you'll lose your changes.
-
-[source,cpp]
-----
-{
- opflex::modb::Mutator mutator("owner1");
- // make changes here
- mutator.commit();
-}
-----
-
-Note that if an exception is thrown while making changes but before
-committing, the mutator will go out of scope and the changes will be
-discarded.
-
-To create a new node, you must call the appropriate add[Child] member
-function on its parent. This function takes parameters for each of the
-naming properties for the object:
-
-[source,cpp]
-----
-shared_ptr<simple::foo> newfoo(root->addFoo("test"));
-----
-
-This will return a shared pointer to a new foo object that has been
-registered in the active mutator but not yet committed. The "bar"
-naming property will be set automatically, but if you want to set the
-"baz" property now, you can do so by calling:
-
-[source,cpp]
-----
-newfoo->setBaz(42);
-----
-
-Note that creating the root node requires a call to the special static
-class method createRootElement:
-
-[source,cpp]
-----
-shared_ptr<simple::root> newroot(simple::root::createRootElement());
-----
-
-Here's a complete example that ties this all together:
-
-[source,cpp]
-----
-{
- opflex::modb::Mutator mutator("owner1");
- shared_ptr<simple::root> newroot(simple::root::createRootElement());
- shared_ptr<simple::root> newfoo(newroot->addFoo("test"));
- newfoo->setBaz(42);
-
- mutator.commit();
-}
-----
-
-==== Update Notifications
-When using the OpFlex framework, you're likely to find that most of
-your time is spend responding to changes in the managed object
-database. To get these notifications, you're going to need to register
-some number of listeners.
-
-You can register an object listener to see all changes related to a
-particular class by calling a static function for that class. You'll
-then get notifications whenever any object in that class is added,
-updated, or deleted. The listener should queue a task to read the new
-state and perform appropriate processing. If this function blocks or
-peforms a long-running operation, then the dispatching of update
-notifications will be stalled, but there will not be any other
-deleterious effects.
-
-If multiple changes happen to the same URI, then at least one
-notification will be delivered but some events may be consolidated.
-
-The update you get will tell you the URI and the Class ID of the
-changed object. The class ID is a unique ID for each class. When you
-get the update, you'll need to call the appropriate resolve function
-to retrieve the new value.
-
-You'll need to create your own object listener derived from
-opflex::modb::ObjectListener:
-
-[source,cpp]
-----
-class MyListener : public ObjectListener {
-public:
- MyListener() { }
- virtual void objectUpdated(class_id_t class_id, const URI& uri) {
- // Your handler here
- }
-};
-----
-
-To register your listener with the default framework instance, just
-call the appropriate class static method:
-
-[source,cpp]
-----
-MyListener listener;
-simple::foo::registerListener(&listener);
-// main loop
-simple::foo::unregisterListener(&listener);
-----
-
-The listener will now recieve notifications whenever any foo or any
-children of any foo object changes.
-
-Note that you must ensure that you unregister your listeners before
-deallocating them.
-
-=== API Reference Documentation
-Complete API documentation can be found through doxygen here:
-https://jenkins.opendaylight.org/opflex/job/opflex-merge/ws/libopflex/doc/html/index.html
-
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/opflex-libopflex-developer-guide.html
* 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 REST API: REST 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
*Topology Data:* Controller IP Address, Links, Nodes, Link Bandwidths, MAC Address of switches, Latency, Host IP address.
+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
*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
+
+*Peer QOS Data:* Node, Port, Transmit Packets, Receive Packets, Collision Count, Receive Frame Error, Receive Over Run Error, Receive Crc Error
+
=== SDNi Wrapper
.SDNiWrapper
image::SDNiWrapper.png[]
* 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 REST API 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://${IPADDRESS}: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.
== SNMP4SDN Developer Guide
-=== Overview
-We propose a southbound plugin that can control the off-the-shelf commodity Ethernet switches for the purpose of building SDN using Ethernet switches. For Ethernet switches, forwarding table, VLAN table, and ACL are where one can install flow configuration on, and this is done via SNMP and CLI in the proposed plugin. In addition, some settings required for Ethernet switches in SDN, e.g., disabling STP and flooding, are proposed.
-
-.SNMP4SDN as an OpenDaylight southbound plugin
-image::snmp4sdn_in_odl_architecture.jpg["SNMP4SDN as an OpenDaylight southbound plugin",width=400]
-
-=== Architecture
-The modules in the plugin are depicted as the following figure.
-
-.Modules in the SNMP4SDN Plugin
-image::snmp4sdn_modules.jpg["Modules in the SNMP4SDN Plugin",width=400]
-
-* AclService: add/remove ACL profile and rule on the switches.
-* FdbService: add/modify/remove FDB table entry on the switches.
-* VlanService: add/modify/remove VLAN table entry on the switches.
-* TopologyService: query and acquire the subnet topology.
-* InventoryService: acquire the switches and their ports.
-* DiscoveryService: probe and resolve the underlying switches as well as the port pairs connecting the switches. The probing is realized by SNMP queries. The updates from discovery will also be reflected to the TopologyService.
-* MiscConfigService: do kinds of settings on switches
-** Supported STP and ARP settings such as enable/disable STP, get port's STP state, get ARP table, set ARP entry, and others
-* VendorSpecificHandler: to assist the flow configuration services to call the switch-talking modules with correct parameters value and order.
-* Switch-talking modules
-** For the services above, when they need to read or configure the underlying switches via SNMP or CLI, these queries are dealt with the modules SNMPHandler and CLIHandler which directly talk with the switches. The SNMPListener is to listen to snmp trap such as link up/down event or switch on/off event.
-
-=== Design
-In terms of the architecture of the SNMP4SDN Plugin's features, the features include flow configuration, topology discovery, and multi-vendor support. Their architectures please refer to Wiki (https://wiki.opendaylight.org/view/SNMP4SDN:Developer_Guide#Design[Developer Guide - Design]).
-
-=== Installation and Configuration Guide
-* Please refer to the 'Getting Started Guide' in https://www.opendaylight.org/downloads, find the SNMP4SDN section.
-* For the latest full guide, please refer to Wiki (https://wiki.opendaylight.org/view/SNMP4SDN:Installation_Guide[Installation Guide], https://wiki.opendaylight.org/view/SNMP4SDN:User_Guide#Configuration[User Guide - Configuration]).
-
-=== Tutorial
-* For the latest full guide, please refer to Wiki (https://wiki.opendaylight.org/view/SNMP4SDN:User_Guide#Tutorial_.2F_How-To[User Guide - Tutorial]).
-
-// === Commit the code via Git CLI
-// The steps to commit code is the same with controller's project, please refer to Wiki (https://wiki.opendaylight.org/view/OpenDaylight_Controller:Pulling,_Hacking,_and_Pushing_the_Code_from_the_CLI#Commit_the_code_via_Git_CLI[here]). Just note to replace the Git location as
-// ----
-// ssh://username@git.opendaylight.org29418/snmp4sdn.git
-// ----
-
-=== Programmatic Interface(s)
-SNMP4SDN Plugin exposes APIs via MD-SAL with YANG model. The methods (RPC call) and data structures for them are listed below.
-
-==== TopologyService
-* RPC call
-** get-edge-list
-** get-node-list
-** get-node-connector-list
-** set-discovery-interval (given interval time in seconds)
-** rediscover
-
-* Data structure
-** node: composed of node-id, node-type
-** node-connector: composed of node-connector-id, node-connector-type, node
-** topo-edge: composed of head-node-connector-id, head-node-connector-type, head-node-id, head-node-type, tail-node-connector-id, tail-node-connector-type, tail-node-id, tail-node-type
-
-==== VlanService
-* RPC call
-** add-vlan (given node ID, VLAN ID, VLAN name)
-** add-vlan-and-set-ports (given node ID, VLAN ID, VLAN name, tagged ports, untagged ports)
-** set-vlan-ports (given node ID, VLAN ID, tagged ports, untagged ports)
-** delete-vlan (given node ID, VLAN ID)
-** get-vlan-table (given node ID)
-
-==== AclService
-* RPC call
-** create-acl-profile (given node ID, acl-profile-index, acl-profile)
-** del-acl-profile (given node ID, acl-profile-index)
-** set-acl-rule (given node ID, acl-index, acl-rule)
-** del-acl-rule (given node ID, acl-index)
-** clear-acl-table (given node ID)
-
-* Data structure
-** acl-profile-index: composed of profile-id, profile name
-** acl-profile: composed of acl-layer, vlan-mask, src-ip-mask, dst-ip-mask
-** acl-layer: IP or ETHERNET
-** acl-index: composed of acl-profile-index, acl-rule-index
-** acl-rule-index: composed of rule-id, rule-name
-** acl-rule: composed of port-list, acl-layer, acl-field, acl-action
-** acl-field: composed of vlan-id, src-ip, dst-ip
-** acl-action: PERMIT or DENY
-
-==== FdbService
-* RPC call
-** set-fdb-entry (given fdb-entry)
-** del-fdb-entry (given node-id, vlan-id, dest-mac-adddr)
-** get-fdb-entry (given node-id, vlan-id, dest-mac-adddr)
-** get-fdb-table (given node-id)
-
-* Data structure
-** fdb-entry: composed of node-id, vlan-id, dest-mac-addr, port, fdb-entry-type
-** fdb-entry-type: OTHER/INVALID/LEARNED/SELF/MGMT
-
-==== MiscConfigService
-* RPC call
-** set-stp-port-state (given node-id, port, is_nable)
-** get-stp-port-state (given node-id, port)
-** get-stp-port-root (given node-id, port)
-** enable-stp (given node-id)
-** disable-stp (given node-id)
-** delete-arp-entry (given node-id, ip-address)
-** set-arp-entry (given node-id, arp-entry)
-** get-arp-entry (given node-id, ip-address)
-** get-arp-table (given node-id)
-
-* Data structure
-** stp-port-state: DISABLE/BLOCKING/LISTENING/LEARNING/FORWARDING/BROKEN
-** arp-entry: composed of ip-address and mac-address
-
-==== SwitchDbService
-* RPC call
-** reload-db
-(The following 4 RPC implemention is TBD)
-** add-switch-entry
-** delete-switch-entry
-** clear-db
-** update-db
-
-* Data structure
-** switch-info: compose of node-ip, node-mac, community, cli-user-name, cli-password, model
-
-=== Help
-* https://wiki.opendaylight.org/view/SNMP4SDN:Main[SNMP4SDN Wiki]
-* SNMP4SDN Mailing List (https://lists.opendaylight.org/mailman/listinfo/snmp4sdn-users[user], https://lists.opendaylight.org/mailman/listinfo/snmp4sdn-dev[developer])
-* https://wiki.opendaylight.org/view/SNMP4SDN:User_Guide#Troubleshooting[Latest troubleshooting in Wiki]
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/alto-developer-guide.html
== SXP Developer Guide
-=== Overview
-SXP (Source-Group Tag eXchange Protocol) project is an effort to enhance OpenDaylight platform with IP-SGT (IP Address to Source Group Tag) bindings that can be learned from connected SXP-aware network nodes. The current implementation supports SXP protocol version 4 according to the Smith, Kandula - SXP https://tools.ietf.org/html/draft-smith-kandula-sxp-04[IETF draft] and grouping of peers and creating filters based on ACL/Prefix-list syntax for filtering outbound and inbound IP-SGT bindings. All protocol legacy versions 1-3 are supported as well. Additionally, version 4 adds bidirectional connection type as an extension of a unidirectional one.
-
-=== SXP Architecture
-The SXP Server manages all connected clients in separate threads and a common SXP protocol agreement is used between connected peers. Each SXP network peer is modelled with its pertaining class, e.g., SXP Server represents the SXP Speaker, SXP Listener the Client. The server program creates the ServerSocket object on a specified port and waits until a client starts up and requests connect on the IP address and port of the server. The client program opens a Socket that is connected to the server running on the specified host IP address and port.
-
-The SXP Listener maintains connection with its speaker peer. From an opened channel pipeline, all incoming SXP messages are processed by various handlers. Message must be decoded, parsed and validated.
-
-The SXP Speaker is a counterpart to the SXP Listener. It maintains a connection with its listener peer and sends composed messages.
-
-The SXP Binding Handler extracts the IP-SGT binding from a message and pulls it into the SXP-Database. If an error is detected during the IP-SGT extraction, an appropriate error code and sub-code is selected and an error message is sent back to the connected peer. All transitive messages are routed directly to the output queue of SXP Binding Dispatcher.
-
-The SXP Binding Dispatcher represents a selector that will decides how many data from the SXP-database will be sent and when. It is responsible for message content composition based on maximum message length.
-
-The SXP Binding Filters handles filtering of outgoing and incoming IP-SGT bindings according to BGP filtering using ACL and Prefix List syntax for specifying filter or based on Peer-sequence length.
-
-The SXP Domains feature provides isolation of SXP peers and bindings learned between them, also exchange of Bindings is possible across SXP-Domains by ACL, Prefix List or Peer-Sequence filters
-
-=== Key APIs and Interfaces
-As this project is fairly small, it provides only few features that install and
-provide all APIs and implementations for this project.
-
-* sxp-controller
-* sxp-api
-* spx-core
-
-==== sxp-controller
-RPC request handling
-
-==== sxp-api
-Contains data holders and entities
-
-==== spx-core
-Main logic and core features
-
-=== API Reference Documentation
-https://wiki.opendaylight.org/images/9/91/SXP_Restconf_Interface_and_Dynamic_Tree.pdf[RESTCONF Interface and Dynamic Tree]
-https://wiki.opendaylight.org/images/6/6e/SXP_Specification_and_Architecture_v03.pdf[Specification and Architecture]
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/sxp-developer-guide.html
== TTP CLI Tools Developer Guide
-=== Overview
-Table Type Patterns are a specification developed by the
-https://www.opennetworking.org/[Open Networking Foundation] to enable
-the description and negotiation of subsets of the OpenFlow protocol.
-This is particularly useful for hardware switches that support OpenFlow
-as it enables the to describe what features they do (and thus also what
-features they do not) support. More details can be found in the full
-specification listed on the
-https://www.opennetworking.org/sdn-resources/onf-specifications/openflow[OpenFlow
-specifications page].
-
-The TTP CLI Tools provide a way for people interested in TTPs to read
-in, validate, output, and manipulate TTPs as a self-contained,
-executable jar file.
-
-=== TTP CLI Tools Architecture
-The TTP CLI Tools use the TTP Model and the YANG Tools/RESTCONF codecs
-to translate between the Data Transfer Objects (DTOs) and JSON/XML.
-
-=== Command Line Options
-This will cover the various options for the CLI Tools. For now, there
-are no options and it merely outputs fixed data using the codecs.
-
-// The CLI tools don't have an APIs in the common sense.
-//
-// === Key APIs and Interfaces
-// Document the key things a user would want to use. For some features,
-// there will only be one logical grouping of APIs. For others there may be
-// more than one grouping.
-//
-// Assuming the API is MD-SAL- and YANG-based, the APIs will be available
-// both via RESTCONF and via Java APIs. Giving a few examples using each is
-// likely a good idea.
-//
-// ==== API Group 1
-// Provide a description of what the API does and some examples of how to
-// use it.
-//
-// ==== API Group 2
-// Provide a description of what the API does and some examples of how to
-// use it.
-//
-// === API Reference Documentation
-// Provide links to JavaDoc, REST API documentation, etc.
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/ttp-cli-tools-developer-guide.html
== TTP Model Developer Guide
-=== Overview
-Table Type Patterns are a specification developed by the
-https://www.opennetworking.org/[Open Networking Foundation] to enable
-the description and negotiation of subsets of the OpenFlow protocol.
-This is particularly useful for hardware switches that support OpenFlow
-as it enables the to describe what features they do (and thus also what
-features they do not) support. More details can be found in the full
-specification listed on the
-https://www.opennetworking.org/sdn-resources/onf-specifications/openflow[OpenFlow
-specifications page].
-
-=== TTP Model Architecture
-The TTP Model provides a YANG-modeled type for a TTP and allows them
-to be associated with a master list of known TTPs, as well as active
-and supported TTPs with nodes in the MD-SAL inventory model.
-
-=== Key APIs and Interfaces
-The key API provided by the TTP Model feature is the ability to store
-a set of TTPs in the MD-SAL as well as associate zero or one active
-TTPs and zero or more supported TTPs along with a given node in the
-MD-SAL inventory model.
-
-=== API Reference Documentation
-
-==== RESTCONF
-See the generated RESTCONF API documentation at:
-http://localhost:8181/apidoc/explorer/index.html
-
-Look for the onf-ttp module to expand and see the various RESTCONF
-APIs.
-
-==== Java Bindings
-
-//TODO: Provide a link to JavaDoc.
-
-As stated above there are 3 locations where a Table Type Pattern can be
-placed into the MD-SAL Data Store. They correspond to 3 different REST
-API URIs:
-
-. +restconf/config/onf-ttp:opendaylight-ttps/onf-ttp:table-type-patterns/+
-. +restconf/config/opendaylight-inventory:nodes/node/{id}/ttp-inventory-node:active_ttp/+
-. +restconf/config/opendaylight-inventory:nodes/node/{id}/ttp-inventory-node:supported_ttps/+
-
-[NOTE]
-===============================
-Typically, these URIs are running on the machine the controller is on
-at port 8181. If you are on the same machine they can thus be accessed
-at +http://localhost:8181/<uri>+
-===============================
-
-=== Using the TTP Model RESTCONF APIs
-
-==== Setting REST HTTP Headers
-
-===== Authentication
-
-The REST API calls require authentication by default. The default
-method is to use basic auth with a user name and password of `admin'.
-
-===== Content-Type and Accept
-
-RESTCONF supports both xml and json. This example focuses on JSON, but
-xml can be used just as easily. When doing a PUT or POST be sure to
-specify the appropriate +Conetnt-Type+ header: either
-+application/json+ or +application/xml+.
-
-When doing a GET be sure to specify the appropriate +Accept+ header:
-again, either +application/json+ or +application/xml+.
-
-==== Content
-
-The contents of a PUT or POST should be a OpenDaylight Table Type
-Pattern. An example of one is provided below. The example can also be
-found at https://git.opendaylight.org/gerrit/gitweb?p=ttp.git;a=blob;f=parser/sample-TTP-from-tests.ttp;h=45130949b25c6f86b750959d27d04ec2208935fb;hb=HEAD[+parser/sample-TTP-from-tests.ttp+ in the TTP git repository].
-
-.Sample Table Type Pattern (json)
------------------------------------------------------
-{
- "table-type-patterns": {
- "table-type-pattern": [
- {
- "security": {
- "doc": [
- "This TTP is not published for use by ONF. It is an example and for",
- "illustrative purposes only.",
- "If this TTP were published for use it would include",
- "guidance as to any security considerations in this doc member."
- ]
- },
- "NDM_metadata": {
- "authority": "org.opennetworking.fawg",
- "OF_protocol_version": "1.3.3",
- "version": "1.0.0",
- "type": "TTPv1",
- "doc": [
- "Example of a TTP supporting L2 (unicast, multicast, flooding), L3 (unicast only),",
- "and an ACL table."
- ],
- "name": "L2-L3-ACLs"
- },
- "identifiers": [
- {
- "doc": [
- "The VLAN ID of a locally attached L2 subnet on a Router."
- ],
- "var": "<subnet_VID>"
- },
- {
- "doc": [
- "An OpenFlow group identifier (integer) identifying a group table entry",
- "of the type indicated by the variable name"
- ],
- "var": "<<group_entry_types/name>>"
- }
- ],
- "features": [
- {
- "doc": [
- "Flow entry notification Extension – notification of changes in flow entries"
- ],
- "feature": "ext187"
- },
- {
- "doc": [
- "Group notifications Extension – notification of changes in group or meter entries"
- ],
- "feature": "ext235"
- }
- ],
- "meter_table": {
- "meter_types": [
- {
- "name": "ControllerMeterType",
- "bands": [
- {
- "type": "DROP",
- "rate": "1000..10000",
- "burst": "50..200"
- }
- ]
- },
- {
- "name": "TrafficMeter",
- "bands": [
- {
- "type": "DSCP_REMARK",
- "rate": "10000..500000",
- "burst": "50..500"
- },
- {
- "type": "DROP",
- "rate": "10000..500000",
- "burst": "50..500"
- }
- ]
- }
- ],
- "built_in_meters": [
- {
- "name": "ControllerMeter",
- "meter_id": 1,
- "type": "ControllerMeterType",
- "bands": [
- {
- "rate": 2000,
- "burst": 75
- }
- ]
- },
- {
- "name": "AllArpMeter",
- "meter_id": 2,
- "type": "ControllerMeterType",
- "bands": [
- {
- "rate": 1000,
- "burst": 50
- }
- ]
- }
- ]
- },
- "table_map": [
- {
- "name": "ControlFrame",
- "number": 0
- },
- {
- "name": "IngressVLAN",
- "number": 10
- },
- {
- "name": "MacLearning",
- "number": 20
- },
- {
- "name": "ACL",
- "number": 30
- },
- {
- "name": "L2",
- "number": 40
- },
- {
- "name": "ProtoFilter",
- "number": 50
- },
- {
- "name": "IPv4",
- "number": 60
- },
- {
- "name": "IPv6",
- "number": 80
- }
- ],
- "parameters": [
- {
- "doc": [
- "documentation"
- ],
- "name": "Showing-curt-how-this-works",
- "type": "type1"
- }
- ],
- "flow_tables": [
- {
- "doc": [
- "Filters L2 control reserved destination addresses and",
- "may forward control packets to the controller.",
- "Directs all other packets to the Ingress VLAN table."
- ],
- "name": "ControlFrame",
- "flow_mod_types": [
- {
- "doc": [
- "This match/action pair allows for flow_mods that match on either",
- "ETH_TYPE or ETH_DST (or both) and send the packet to the",
- "controller, subject to metering."
- ],
- "name": "Frame-To-Controller",
- "match_set": [
- {
- "field": "ETH_TYPE",
- "match_type": "all_or_exact"
- },
- {
- "field": "ETH_DST",
- "match_type": "exact"
- }
- ],
- "instruction_set": [
- {
- "doc": [
- "This meter may be used to limit the rate of PACKET_IN frames",
- "sent to the controller"
- ],
- "instruction": "METER",
- "meter_name": "ControllerMeter"
- },
- {
- "instruction": "APPLY_ACTIONS",
- "actions": [
- {
- "action": "OUTPUT",
- "port": "CONTROLLER"
- }
- ]
- }
- ]
- }
- ],
- "built_in_flow_mods": [
- {
- "doc": [
- "Mandatory filtering of control frames with C-VLAN Bridge reserved DA."
- ],
- "name": "Control-Frame-Filter",
- "priority": "1",
- "match_set": [
- {
- "field": "ETH_DST",
- "mask": "0xfffffffffff0",
- "value": "0x0180C2000000"
- }
- ]
- },
- {
- "doc": [
- "Mandatory miss flow_mod, sends packets to IngressVLAN table."
- ],
- "name": "Non-Control-Frame",
- "priority": "0",
- "instruction_set": [
- {
- "instruction": "GOTO_TABLE",
- "table": "IngressVLAN"
- }
- ]
- }
- ]
- }
- ],
- "group_entry_types": [
- {
- "doc": [
- "Output to a port, removing VLAN tag if needed.",
- "Entry per port, plus entry per untagged VID per port."
- ],
- "name": "EgressPort",
- "group_type": "INDIRECT",
- "bucket_types": [
- {
- "name": "OutputTagged",
- "action_set": [
- {
- "action": "OUTPUT",
- "port": "<port_no>"
- }
- ]
- },
- {
- "name": "OutputUntagged",
- "action_set": [
- {
- "action": "POP_VLAN"
- },
- {
- "action": "OUTPUT",
- "port": "<port_no>"
- }
- ]
- },
- {
- "opt_tag": "VID-X",
- "name": "OutputVIDTranslate",
- "action_set": [
- {
- "action": "SET_FIELD",
- "field": "VLAN_VID",
- "value": "<local_vid>"
- },
- {
- "action": "OUTPUT",
- "port": "<port_no>"
- }
- ]
- }
- ]
- }
- ],
- "flow_paths": [
- {
- "doc": [
- "This object contains just a few examples of flow paths, it is not",
- "a comprehensive list of the flow paths required for this TTP. It is",
- "intended that the flow paths array could include either a list of",
- "required flow paths or a list of specific flow paths that are not",
- "required (whichever is more concise or more useful."
- ],
- "name": "L2-2",
- "path": [
- "Non-Control-Frame",
- "IV-pass",
- "Known-MAC",
- "ACLskip",
- "L2-Unicast",
- "EgressPort"
- ]
- },
- {
- "name": "L2-3",
- "path": [
- "Non-Control-Frame",
- "IV-pass",
- "Known-MAC",
- "ACLskip",
- "L2-Multicast",
- "L2Mcast",
- "[EgressPort]"
- ]
- },
- {
- "name": "L2-4",
- "path": [
- "Non-Control-Frame",
- "IV-pass",
- "Known-MAC",
- "ACL-skip",
- "VID-flood",
- "VIDflood",
- "[EgressPort]"
- ]
- },
- {
- "name": "L2-5",
- "path": [
- "Non-Control-Frame",
- "IV-pass",
- "Known-MAC",
- "ACLskip",
- "L2-Drop"
- ]
- },
- {
- "name": "v4-1",
- "path": [
- "Non-Control-Frame",
- "IV-pass",
- "Known-MAC",
- "ACLskip",
- "L2-Router-MAC",
- "IPv4",
- "v4-Unicast",
- "NextHop",
- "EgressPort"
- ]
- },
- {
- "name": "v4-2",
- "path": [
- "Non-Control-Frame",
- "IV-pass",
- "Known-MAC",
- "ACLskip",
- "L2-Router-MAC",
- "IPv4",
- "v4-Unicast-ECMP",
- "L3ECMP",
- "NextHop",
- "EgressPort"
- ]
- }
- ]
- }
- ]
- }
-}
------------------------------------------------------
-
-==== Making a REST Call
-
-In this example we'll do a PUT to install the sample TTP from above
-into OpenDaylight and then retrieve it both as json and as xml. We'll
-use the https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm[
-Postman - REST Client] for Chrome in the examples, but any method of
-accessing REST should work.
-
-First, we'll fill in the basic information:
-
-.Filling in URL, content, Content-Type and basic auth
-image::ttp-screen1-basic-auth.png[width=500]
-
-. Set the URL to +http://localhost:8181/restconf/config/onf-ttp:opendaylight-ttps/onf-ttp:table-type-patterns/+
-. Set the action to +PUT+
-. Click Headers and
-. Set a header for +Content-Type+ to +application/json+
-. Make sure the content is set to raw and
-. Copy the sample TTP from above into the content
-. Click the Basic Auth tab and
-. Set the username and password to admin
-. Click Refresh headers
-
-.Refreshing basic auth headers
-image::ttp-screen2-applied-basic-auth.png[width=500]
-
-After clicking Refresh headers, we can see that a new header
-(+Authorization+) has been created and this will allow us to
-authenticate to make the REST call.
-
-.PUTting a TTP
-image::ttp-screen3-sent-put.png[width=500]
-
-At this point, clicking send should result in a Status response of +200
-OK+ indicating we've successfully PUT the TTP into OpenDaylight.
-
-.Retrieving the TTP as json via a GET
-image::ttp-screen4-get-json.png[width=500]
-
-We can now retrieve the TTP by:
-
-. Changing the action to +GET+
-. Setting an +Accept+ header to +application/json+ and
-. Pressing send
-
-.Retrieving the TTP as xml via a GET
-image::ttp-screen5-get-xml.png[width=500]
-
-The same process can retrieve the content as xml by setting the
-+Accept+ header to +application/xml+.
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/ttp-model-developer-guide.html
== Virtual Tenant Network (VTN)
-include::vtn-overview.adoc[VTN Overview]
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/developer-guide/virtual-tenant-network-(vtn)-developer-guide.html
+++ /dev/null
-=== OpenDaylight Virtual Tenant Network (VTN) Overview
-
-OpenDaylight Virtual Tenant Network (VTN) is an application that provides multi-tenant virtual network on an SDN controller.
-
-Conventionally, huge investment in the network systems and operating expenses are needed because the network is configured as a silo for each department and system. Therefore various network appliances must be installed for each tenant and those boxes cannot be shared with others. It is a heavy work to design, implement and operate the entire complex network.
-
-The uniqueness of VTN is a logical abstraction plane. This enables the complete separation of logical plane from physical plane. Users can design and deploy any desired network without knowing the physical network topology or bandwidth restrictions.
-
-VTN allows the users to define the network with a look and feel of conventional L2/L3 network. Once the network is designed on VTN, it will automatically be mapped into underlying physical network, and then configured on the individual switch leverage SDN control protocol. The definition of logical plane makes it possible not only to hide the complexity of the underlying network but also to better manage network resources. It achieves reducing reconfiguration time of network services and minimizing network configuration errors. OpenDaylight Virtual Tenant Network (VTN) is an application that provides multi-tenant virtual network on an SDN controller. It provides API for creating a common virtual network irrespective of the physical network.
-
-.VTN Architecture
-image::vtn/vtn-overview.png[width=500]
-
-It is implemented as two major components
-
-* <<_vtn_manager,VTN Manager>>
-* <<_vtn_coordinator,VTN Coordinator>>
-
-==== VTN Manager
-An OpenDaylight Plugin that interacts with other modules to implement the components of the VTN model. It also provides a REST interface to configure VTN components in OpenDaylight. VTN Manager is implemented as one plugin to the OpenDaylight. This provides a REST interface to create/update/delete VTN components. The user command in VTN Coordinator is translated as REST API to VTN Manager by the OpenDaylight Driver component. In addition to the above mentioned role, it also provides an implementation to the OpenStack L2 Network Functions API.
-
-===== Function Outline
-
-The table identifies the functions and the interface used by VTN Components:
-
-[options="header"]
-|===
-| Component | Interface | Purpose
-| VTN Manager |RESTful API | Configure VTN Virtualization model components in OpenDaylight
-| VTN Manager | Neutron API implementation | Handle Networks API from OpenStack (Neutron Interface)
-| VTN Coordinator | RESTful API |
-(1) Uses the RESTful interface of VTN Manager and configures VTN Virtualization model components in OpenDaylight. +
-(2) Handles multiple OpenDaylight orchestration. +
-(3) Provides API to read the physical network details. See https://wiki.OpenDaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Coordinator:RestApi:L2_Network_Example_Using_VTN_Virtualization[samples] for usage.
-
-|===
-
-===== Feature Overview
-
-There are three features
-
-* *odl-vtn-manager* provides VTN Manager's JAVA API.
-* *odl-vtn-manager-rest* provides VTN Manager's REST API.
-* *odl-vtn-manager-neutron* provides the integration with Neutron interface.
-
-REST API documentation for VTN Manager, please refer to:
-https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/
-
-For VTN Java API documentation, please refer to: https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/target/apidocs/index.html
-
-Once the Karaf distribution is up, install dlux and apidocs.
-
-----
-feature:install odl-dlux-all odl-mdsal-apidocs
-----
-
-====== Logging In
-
-To Log in to DLUX, after installing the application:
-
-* Open a browser and enter the login URL as http://<OpenDaylight-IP>:8181/index.html.
-
-NOTE: Replace "<OpenDaylight-IP>" with the IP address of OpenDaylight based on your environment.
-
-* Login to the application with user ID and password credentials as admin.
-
-NOTE: admin is the only default user available for DLUX in this release.
-
-* In the right hand side frame, click "Yang UI".
-
-YANG documentation for VTN Manager, please refer to: https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/
-
-==== VTN Coordinator
-
-The VTN Coordinator is an external application that provides a REST interface for an user to use OpenDaylight VTN Virtualization. It interacts with the VTN Manager plugin to implement the user configuration. It is also capable of multiple OpenDaylight orchestration. It realizes VTN provisioning in OpenDaylight instances. In the OpenDaylight architecture VTN Coordinator is part of the network application, orchestration and services layer. VTN Coordinator will use the REST interface exposed by the VTN Manger to realize the virtual network using OpenDaylight. It uses OpenDaylight APIs (REST) to construct the virtual network in OpenDaylight instances. It provides REST APIs for northbound VTN applications and supports virtual networks spanning across multiple OpenDaylight by coordinating across OpenDaylight.
-
-VTN Coordinator Components:
-
-* Transaction Coordinator
-* Unified Provider Physical Layer (UPPL)
-* Unified Provider Logical LAyer (UPLL)
-* OpenDaylight Controller Diver (ODC Driver)
-
-===== OpenDaylight Virtual Tenant Network (VTN) API Overview
-
-The VTN API module is a sub component of the VTN Coordinator and provides the northbound REST API interface for VTN applications. It consists of two subcomponents:
-
-* Web Server
-* VTN service Java API Library
-
-.VTN-Coordinator_api-architechture
-image::vtn/vtn-coordinator-api-architecture.png[width=300]
-
-====== Web Server
-
-The Web Server module handles the REST APIs received from the VTN applications. It translates the REST APIs to the appropriate Java APIs.
-
-The main functions of this module are:
-
-* Starts via the startup script `catalina.sh`.
-* VTN Application sends HTTP request to Web server in XML or JSON format.
-* Creates a session and acquire a read/write lock.
-* Invokes the VTN Service Java API Library corresponding to the specified URI.
-* Returns the response to the VTN Application.
-
-====== WebServer Class Details
-The list below shows the classes available for Web Server module and their descriptions:
-
-Init Manager:: It is a singleton class for executing the acquisition of configuration information from properties file, log initialization, initialization of VTN Service Java API Library. Executed by init() of VtnServiceWebAPIServlet.
-Configuration Manager:: Maintains the configuration information acquired from properties file.
-VtnServiceCommonUtil:: Utility class
-VtnServiceWebUtil:: Utility class
-VtnServiceWebAPIServlet:: Receives HTTP request from VTN Application and calls the method of corresponding VtnServiceWebAPIHandler.
-herits class HttpServlet, and overrides doGet(), doPut(), doDelete(), doPost().
-VtnServiceWebAPIHandler:: Creates JsonObject(com.google.gson) from HTTP request, and calls method of corresponding VtnServiceWebAPIController.
-VtnServiceWebAPIController:: Creates RestResource() class and calls UPLL API/UPPL API through Java API.
- the time of calling UPLL API/UPPL API, performs the creation/deletion of session, acquisition/release of configuration mode, acquisition/release of read lock by TC API through Java API.
-Data Converter:: Converts HTTP request to JsonObject and JsonXML to JSON.
-
-
-====== VTN Service Java API Library
-It provides the Java API library to communicate with the lower layer modules in the VTN Coordinator.
-The main functions of this library are:
-
-* Creates an IPC client session to the lower layer.
-* Converts the request to IPC framework format.
-* Invokes the lower layer API (i.e. UPPL API, UPLL API, TC API).
-* Returns the response from the lower layer to the web server
-* VTN Service Java API Library Class Details
-
-===== Feature Overview
-
-VTN Coordinator doesn't have Karaf features.
-
-For VTN Coordinator REST API, please refer to: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Coordinator:RestApi
-
-==== Usage Examples
-* https://wiki.OpenDaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Coordinator:RestApi:How_to_configure_L2_Network_with_Single_Controller[L2 Network using Single Controller]
-
+++ /dev/null
-<project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
- <parent>
- <groupId>org.opendaylight.docs</groupId>
- <artifactId>manuals</artifactId>
- <version>0.4.0-SNAPSHOT</version>
- <relativePath>../pom.xml</relativePath>
- </parent>
- <modelVersion>4.0.0</modelVersion>
- <artifactId>openstack</artifactId>
- <packaging>jar</packaging>
- <name>OpenDaylight Docs - Manuals - OpenStack Howto</name>
- <properties>
- <!-- This is set by Jenkins according to the branch. -->
- <release.path.name>local</release.path.name>
- <comments.enabled>1</comments.enabled>
- <bookname>openstack</bookname>
- </properties>
- <!-- ################################################ -->
- <!-- USE "mvn clean generate-sources" to run this POM -->
- <!-- ################################################ -->
- <build>
- <plugins>
- <plugin>
- <groupId>org.asciidoctor</groupId>
- <artifactId>asciidoctor-maven-plugin</artifactId>
- <version>${asciidoctor.version}</version>
- <executions>
- <execution>
- <id>output-docbook</id>
- <phase>generate-sources</phase>
- <goals>
- <goal>process-asciidoc</goal>
- </goals>
- <configuration>
- <backend>docbook5</backend>
- <doctype>book</doctype>
- </configuration>
- </execution>
- </executions>
- <configuration>
- <sourceDirectory>src/main/asciidoc</sourceDirectory>
- <sourceDocumentName>${bookname}.adoc</sourceDocumentName>
- <imagesDir>./images</imagesDir>
- </configuration>
- </plugin>
- <plugin>
- <artifactId>maven-resources-plugin</artifactId>
- <version>2.6</version>
- <executions>
- <execution>
- <id>copy-resources</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>copy-resources</goal>
- </goals>
- <configuration>
- <outputDirectory>${basedir}/target/generated-docs</outputDirectory>
- <resources>
- <resource>
- <directory>src/main/resources</directory>
- <includes>
- <include>**/*.*</include>
- </includes>
- </resource>
- </resources>
- </configuration>
- </execution>
- </executions>
- </plugin>
- <plugin>
- <groupId>com.inocybe.api</groupId>
- <artifactId>sdndocs-maven-plugin</artifactId>
- <version>0.1.0</version>
- <executions>
- <execution>
- <id>generate-webhelp</id>
- <goals>
- <goal>generate-webhelp</goal>
- </goals>
- <phase>compile</phase>
- <configuration>
- <profileAudience>enduser</profileAudience>
- <includes>target/generated-docs/${bookname}.xml</includes>
- <!-- <includes>bk-install-guide.xml</includes> -->
- <generateToc>
- appendix toc,title
- article/appendix nop
- article toc,title
- book toc,title,figure,table,example,equation
- chapter toc,title
- section toc
- part toc,title
- qandadiv toc
- qandaset toc
- reference toc,title
- set toc,title
- </generateToc>
- <webhelpDirname>${bookname}</webhelpDirname>
- <pdfFilenameBase>${bookname}</pdfFilenameBase>
- </configuration>
- </execution>
- </executions>
- <configuration>
- <profileAudience>enduser</profileAudience>
- <chapterAutolabel>1</chapterAutolabel>
- <sectionAutolabel>0</sectionAutolabel>
- <tocSectionDepth>1</tocSectionDepth>
- <formalProcedures>0</formalProcedures>
- <highlightSource>false</highlightSource>
- <xincludeSupported>true</xincludeSupported>
- <showXslMessages>true</showXslMessages>
- <sourceDirectory>.</sourceDirectory>
- <feedbackEmail>mlemay@inocybe.com</feedbackEmail>
- <branding>opendaylight</branding>
- <coverLogoLeft>2.6in</coverLogoLeft>
-<!-- <enableDisqus>${comments.enabled}</enableDisqus>
- <disqusShortname>os-user-guide</disqusShortname>
- <enableGoogleAnalytics>1</enableGoogleAnalytics>
- <googleAnalyticsId>UA-17511903-1</googleAnalyticsId>
- --> <suppressFooterNavigation>0</suppressFooterNavigation>
- <canonicalUrlBase>http://docs.opendaylight.org/user-guide/content/</canonicalUrlBase>
- <glossaryCollection>${basedir}/../glossary/glossary-terms.xml</glossaryCollection>
- </configuration>
- </plugin>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-site-plugin</artifactId>
- <version>3.1</version>
- <configuration>
- <inputDirectory>${project.build.directory}/docbkx/webhelp</inputDirectory>
- </configuration>
- <dependencies>
- <dependency>
- <groupId>org.apache.maven.wagon</groupId>
- <artifactId>wagon-webdav-jackrabbit</artifactId>
- <version>2.2</version>
- </dependency>
- <dependency>
- <groupId>org.slf4j</groupId>
- <artifactId>slf4j-api</artifactId>
- <version>1.6.1</version>
- </dependency>
- </dependencies>
- </plugin>
- </plugins>
- </build>
-</project>
+++ /dev/null
-=== OpenStack with GroupBasedPolicy
-
-This section is for Application Developers and Network Administrators
-who are looking to integrate Group Based Policy with OpenStack.
-
-To enable the *GBP* Neutron Mapper feature, at the karaf console:
-
- 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
-
-For Lithium, *GBP* has one renderer, hence this is loaded by default.
-
-REST calls from OpenStack Neutron are by the Neutron NorthBound project.
-
-*GBP* provides the implementation of the http://developer.openstack.org/api-ref-networking-v2.html[Neutron V2.0 API].
-
-==== 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*
-
-.Neutron Port
-image::groupbasedpolicy/neutronmapper-gbp-mapping-port.png[width=300]
-
-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*
-
-.Neutron Network
-image::groupbasedpolicy/neutronmapper-gbp-mapping-network.png[width=300]
-
-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*
-
-.Neutron Subnet
-image::groupbasedpolicy/neutronmapper-gbp-mapping-subnet.png[width=300]
-
-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*
-
-.Neutron Security Group and Rules
-image::groupbasedpolicy/neutronmapper-gbp-mapping-securitygroup.png[width=300]
-
-*GBP* entity representing Neutron security-group is EndpointGroup.
-
-*Infrastructure EndpointGroups*
-
-Neutron-mapper automatically creates EndpointGroups to manage key infrastructure items such as:
-
-* DHCP EndpointGroup - contains endpoints representing Neutron DHCP ports
-* Router EndpointGroup - contains endpoints representing Neutron router interfaces
-* External EndpointGroup - holds L3-endpoints representing Neutron router gateway ports, also associated with FloatingIP ports.
-
-*Neutron Security Group Rules*
-
-This mapping is most complicated among all others because Neutron security-group-rules are mapped to contracts with clauses,
-subjects, rules, action-refs, classifier-refs, etc.
-Contracts are used between endpoint groups representing Neutron Security Groups.
-For simplification it is important to note that Neutron security-group-rules are similar to a *GBP* rule containing:
-
-* classifier with direction
-* action of *allow*.
-
-
-*Neutron Routers*
-
-.Neutron Router
-image::groupbasedpolicy/neutronmapper-gbp-mapping-router.png[width=300]
-
-Neutron router is represented as a L3-context. This treats a router as a Layer3 namespace, and hence every network attached to it a part
-of that Layer3 namespace.
-
-This allows for multiple routers per tenant with complete isolation.
-
-The mapping of the router to an endpoint represents the router's interface or gateway port.
-
-The mapping to an EndpointGroup represents the internal infrastructure EndpointGroups created by the *GBP* Neutron Mapper
-
-When a Neutron router interface is attached to a network/subnet, that network/subnet and its associated endpoints or Neutron Ports are seamlessly added to the namespace.
-
-*Neutron FloatingIP*
-
-When associated with a Neutron Port, this leverages the *GBP* OfOverlay renderer's NAT capabilities.
-
-A dedicated _external_ interface on each Nova compute host allows for disitributed external access. Each Nova instance associated with a
-FloatingIP address can access the external network directly without having to route via the Neutron controller, or having to enable any form
-of Neutron distributed routing functionality.
-
-Assuming the gateway provisioned in the Neutron Subnet command for the external network is reachable, the combination of *GBP* Neutron Mapper and
-OfOverlay renderer will automatically ARP for this default gateway, requiring no user intervention.
-
-
-*Troubleshooting within GBP*
-
-Logging level for the mapping functionality can be set for package org.opendaylight.groupbasedpolicy.neutron.mapper. An example of enabling TRACE logging level on karaf console:
-
- 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.
-
-.Neutron network mapping
-image::groupbasedpolicy/neutronmapper-gbp-mapping-network-example.png[width=500]
-
-After an subnet is created in the network mapping looks like this.
-
-.Neutron subnet mapping
-image::groupbasedpolicy/neutronmapper-gbp-mapping-subnet-example.png[width=500]
-
-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.
-
-.Neutron port mapping
-image::groupbasedpolicy/neutronmapper-gbp-mapping-port-example.png[width=500]
-
-==== 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 https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)[*GBP* wiki].
-
-==== Administering or Managing GBP Neutron
-
-For consistencies sake, all provisioning should be performed via the Neutron API. (CLI or Horizon).
-
-The mapped policies can be augmented via the *GBP* UX,UX, to:
-
-* Enable Service Function Chaining
-* Add endpoints from outside of Neutron i.e. VMs/containers not provisioned in OpenStack
-* Augment policies/contracts derived from Security Group Rules
-* Overlay additional contracts or groupings
-
-==== Tutorials
-
-A DevStack demo environment can be found on the https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)[*GBP* wiki].
+++ /dev/null
-
- <author>
- <personname>
- <firstname>OpenDaylight</firstname>
- <surname>Community</surname>
- </personname>
- <email>documentation@opendaylight.org</email>
- <affiliation>
- <orgname>Linux Foundation</orgname>
- </affiliation>
- </author>
- <copyright>
- <year>2015</year>
- <holder>Linux Foundation</holder>
- </copyright>
- <releaseinfo>Beryllium</releaseinfo>
- <productname>OpenDaylight</productname>
- <pubdate></pubdate>
- <legalnotice role="license">
- <para> This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at <link xlink:href="http://www.eclipse.org/legal/epl-v10.html"/></para>
- </legalnotice>
- <abstract>
- <para>This guide describes how to use OpenDaylight with OpenStack.</para>
- </abstract>
- <revhistory>
- <revision>
- <date>2014-07-16</date>
- <revdescription>
- <itemizedlist spacing="compact">
- <listitem>
- <para>Initial Guide Creation</para>
- </listitem>
- </itemizedlist>
- </revdescription>
- </revision>
- </revhistory>
-
+++ /dev/null
-=== OpenStack with OVSDB
-
-*Prerequisites:* OpenDaylight requires Java 1.7.0.
-
-* On the control host, http://www.opendaylight.org/software/downloads[Download
- the latest OpenDaylight release] (at the time of writing, this is
- 0.2.1-Helium-SR1.1)
-* Uncompress it as root, and start OpenDaylight (you can start OpenDaylight
- by running karaf directly, but exiting from the shell will shut it down):
-+
-....
-$ tar xvfz distribution-karaf-0.2.1-Helium-SR1.1.tar.gz
-$ cd distribution-karaf-0.2.0-Helium
-$ ./bin/start # Start OpenDaylight as a server process
-....
-+
-* Connect to the Karaf shell, and install the odl-ovsdb-openstack bundle,
- dlux and their dependencies:
-+
-....
-$ ./bin/client # Connect to OpenDaylight with the client
-opendaylight-user@root> feature:install odl-base-all odl-aaa-authn odl-restconf odl-nsf-all odl-adsal-northbound odl-mdsal-apidocs \
-odl-ovsdb-openstack odl-ovsdb-northbound odl-dlux-core
-....
-+
-* If everything is installed correctly, you should now be able to log in to
- the dlux interface on `http://$CONTROL_HOST:8181/dlux/index.html` - the
- default username and password is "admin/admin" (see screenshot below)
-+
-image:dlux-default.png[width=500]
-
-==== Ensuring OpenStack network state is clean
-
-When using OpenDaylight as the Neutron back-end, ODL expects to be the only
-source of truth for Open vSwitch configuration. Because of this, it is
-necessary to remove existing OpenStack and Open vSwitch configurations to
-give OpenDaylight a clean slate.
-
-* Delete instances
-+
-....
-$ nova list
-$ nova delete <instance names>
-....
-+
-* Remove link from subnets to routers
-+
-....
-$ neutron subnet-list
-$ neutron router-list
-$ neutron router-port-list <router name>
-$ neutron router-interface-delete <router name> <subnet ID or name>
-....
-+
-* Delete subnets, nets, routers
-+
-....
-$ neutron subnet-delete <subnet name>
-$ neutron net-list
-$ neutron net-delete <net name>
-$ neutron router-delete <router name>
-....
-+
-* Check that all ports have been cleared - at this point, this should be an
- empty list
-+
-....
-$ neutron port-list
-....
-
-==== Ensure Neutron is stopped
-
-While Neutron is managing the OVS instances on compute and control nodes,
-OpenDaylight and Neutron can be in conflict. To prevent issues, we turn off
-Neutron server on the network controller, and Neutron's Open vSwitch agents
-on all hosts.
-
-* Turn off neutron-server on control node
-+
-....
-# systemctl stop neutron-server
-....
-+
-* On each node in the cluster, shut down and disable Neutron's agent services to ensure that they do not restart after a reboot:
-+
-....
-# systemctl stop neutron-openvswitch-agent
-# systemctl disable neutron-openvswitch-agent
-....
-
-==== Configuring Open vSwitch to be managed by OpenDaylight
-
-On each host (both compute and control nodes) we will clear the pre-existing
-Open vSwitch config and set OpenDaylight to manage the switch:
-
-* Stop the Open vSwitch service, and clear existing OVSDB (ODL expects to
-manage vSwitches completely)
-+
-....
-# systemctl stop openvswitch
-# rm -rf /var/log/openvswitch/*
-# rm -rf /etc/openvswitch/conf.db
-# systemctl start openvswitch
-....
-+
-* At this stage, your Open vSwitch configuration should be empty:
-+
-....
-[root@dneary-odl-compute2 ~]# ovs-vsctl show
-9f3b38cb-eefc-4bc7-828b-084b1f66fbfd
- ovs_version: "2.1.3"
-....
-+
-* Set OpenDaylight as the manager on all nodes
-+
-....
-# ovs-vsctl set-manager tcp:${CONTROL_HOST}:6640
-....
-+
-* You should now see a new section in your Open vSwitch configuration
- showing that you are connected to the OpenDaylight server, and OpenDaylight
- will automatically create a br-int bridge:
-+
-....
-[root@dneary-odl-compute2 ~]# ovs-vsctl show
-9f3b38cb-eefc-4bc7-828b-084b1f66fbfd
- Manager "tcp:172.16.21.56:6640"
- is_connected: true
- Bridge br-int
- Controller "tcp:172.16.21.56:6633"
- fail_mode: secure
- Port br-int
- Interface br-int
- ovs_version: "2.1.3"
-....
-+
-* (BUG WORKAROUND) If SELinux is enabled, you may not have a security
- context in place which allows Open vSwitch remote administration. If you
- do not see the result above (specifically, if you do not see
- "is_connected: true" in the Manager section), set SELinux to Permissive
- mode on all nodes and ensure it stays that way after boot:
-+
-....
-# setenforce 0
-# sed -i -e 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/selinux/config
-....
-+
-* Make sure all nodes, including the control node, are connected to
- OpenDaylight
-* If you reload DLUX, you should now see that all of your Open vSwitch nodes
- are now connected to OpenDaylight
-+
-image:dlux-with-switches.png[width=500]
-+
-* If something has gone wrong, check <code>data/log/karaf.log</code> under
- the OpenDaylight distribution directory. If you do not see any interesting
- log entries, set logging for OVSDB to TRACE level inside Karaf and try again:
-+
-....
-log:set TRACE ovsdb
-....
-
-==== Configuring Neutron to use OpenDaylight
-
-Once you have configured the vSwitches to connect to OpenDaylight, you can
-now ensure that OpenStack Neutron is using OpenDaylight.
-
-First, ensure that port 8080 (which will be used by OpenDaylight to listen
-for REST calls) is available. By default, swift-proxy-service listens on the
-same port, and you may need to move it (to another port or another host), or
-disable that service. I moved it to port 8081 by editing
-<code>/etc/swift/proxy-server.conf</code> and
-<code>/etc/cinder/cinder.conf</code>, modifying iptables appropriately, and
-restarting swift-proxy-service and OpenDaylight.
-
-* Configure Neutron to use OpenDaylight's ML2 driver:
-+
-....
-crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 mechanism_drivers opendaylight
-crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 tenant_network_types vxlan
-
-cat <<EOT>> /etc/neutron/plugins/ml2/ml2_conf.ini
-[ml2_odl]
-password = admin
-username = admin
-url = http://${CONTROL_HOST}:8080/controller/nb/v2/neutron
-EOT
-....
-+
-* Reset Neutron's ML2 database
-+
-....
-mysql -e "drop database if exists neutron_ml2;"
-mysql -e "create database neutron_ml2 character set utf8;"
-mysql -e "grant all on neutron_ml2.* to 'neutron'@'%';"
-neutron-db-manage --config-file /usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf \
---config-file /etc/neutron/plugin.ini upgrade head
-....
-+
-* Restart neutron-server:
-+
- systemctl start neutron-server
-
-==== Verifying it works
-
-* Verify that OpenDaylight's ML2 interface is working:
-+
-....
-curl -u admin:admin http://${CONTROL_HOST}:8080/controller/nb/v2/neutron/networks
-
-{
- "networks" : [ ]
-}
-....
-+
-If this does not work or gives an error, check Neutron's log file in
-<code>/var/log/neutron/server.log</code>. Error messages here should give
-some clue as to what the problem is in the connection with OpenDaylight
-+
-* Create a net, subnet, router, connect ports, and start an instance using
-the Neutron CLI:
-+
-....
-neutron router-create router1
-neutron net-create private
-neutron subnet-create private --name=private_subnet 10.10.5.0/24
-neutron router-interface-add router1 private_subnet
-nova boot --flavor <flavor> --image <image id> --nic net-id=<network id> test1
-nova boot --flavor <flavor> --image <image id> --nic net-id=<network id> test2
-....
-+
-At this point, you have confirmed that OpenDaylight is creating network
-end-points for instances on your network and managing traffic to them.
-
-Congratulations! You're done!
\ No newline at end of file
+++ /dev/null
-=== OpenStack with Virtual Tenant Network
-This section describes using OpenDaylight with the VTN manager feature providing network service for OpenStack. VTN manager utilizes the OVSDB southbound service and Neutron for this implementation. The below diagram depicts the communication of OpenDaylight and two virtual networks connected by an OpenFlow switch using this implementation.
-
-.OpenStack Architecture
-image::vtn/OpenStackDeveloperGuide.png["OpenStack Architecture",width=500]
-
-==== Configure OpenStack to work with OpenDaylight(VTN Feature) using PackStack
-
-===== Prerequisites to install OpenStack using PackStack
-* Fresh CentOS 7.1 minimal install
-* Use the below commands to disable and remove Network Manager in CentOS 7.1,
-+
-....
-# systemctl stop NetworkManager
-# systemctl disable NetworkManager
-....
-+
-* To make SELINUX as permissive, please open the file "/etc/sysconfig/selinux" and change it as "SELINUX=permissive".
-* After making selinux as permissive, please restart the CentOS 7.1 machine.
-
-===== Steps to install OpenStack PackStack in CentOS 7.1
-
-* To install OpenStack juno, use the following command,
-+
-....
-# yum update -y
-# yum -y install https://repos.fedorapeople.org/repos/openstack/openstack-juno/rdo-release-juno-1.noarch.rpm
-....
-+
-* To install the packstack installer, please use the below command,
-+
-....
-# yum -y install openstack-packstack
-....
-+
-* To create all-in-one setup, please use the below command,
-+
-....
-# packstack --allinone --provision-demo=n --provision-all-in-one-ovs-bridge=n
-....
-+
-* This will end up with Horizon started successfully message.
-
-===== Steps to install and deploy OpenDaylight in CentOS 7.1
-* Download the latest Beryllium distribution code in the below link,
-+
-....
-# wget https://nexus.opendaylight.org/content/groups/public/org/opendaylight/integration/distribution-karaf/0.4.0-Beryllium-SR1/distribution-karaf-0.4.0-Beryllium-SR1.zip
-....
-+
-* Unzip the Beryllium distribution code by using the below command,
-+
-....
-# unzip distribution-karaf-0.4.0-Beryllium-SR1.zip
-....
-+
-* Please do the below steps in the OpenDaylight to change jetty port,
-** Change the jetty port from 8080 to something else as swift proxy of OpenStack is using it.
-** Open the file "etc/jetty.xml" and change the jetty port from 8080 to 8910 (we have used 8910 as jetty port you can use any other number).
-** Start VTN Manager and install odl-vtn-manager-neutron in it.
-** Ensure all the required ports(6633/6653,6640 and 8910) are in the listen mode by using the command "netstat -tunpl" in OpenDaylight.
-
-===== Steps to reconfigure OpenStack in CentOS 7.1
-* Steps to stop Open vSwitch Agent and clean up ovs
-+
-....
-# sudo systemctl stop neutron-openvswitch-agent
-# sudo systemctl disable neutron-openvswitch-agent
-# sudo systemctl stop openvswitch
-# sudo rm -rf /var/log/openvswitch/*
-# sudo rm -rf /etc/openvswitch/conf.db
-# sudo systemctl start openvswitch
-# sudo ovs-vsctl show
-....
-+
-* Stop Neutron Server
-+
-....
-# systemctl stop neutron-server
-....
-+
-* Verify that OpenDaylight's ML2 interface is working:
-+
-....
-curl -v admin:admin http://{CONTROL_HOST}:{PORT}/controller/nb/v2/neutron/networks
-
-{
- "networks" : [ ]
-}
-....
-+
-If this does not work or gives an error, check Neutron's log file in
-+/var/log/neutron/server.log+. Error messages here should give
-some clue as to what the problem is in the connection with OpenDaylight
-+
-* Configure Neutron to use OpenDaylight's ML2 driver:
-+
-....
-# sudo crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 mechanism_drivers opendaylight
-# sudo crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 tenant_network_types local
-# sudo crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 type_drivers local
-# sudo crudini --set /etc/neutron/dhcp_agent.ini DEFAULT ovs_use_veth True
-
-# cat <<EOT | sudo tee -a /etc/neutron/plugins/ml2/ml2_conf.ini > /dev/null
- [ml2_odl]
- password = admin
- username = admin
- url = http://{CONTROL_HOST}:{PORT}/controller/nb/v2/neutron
- EOT
-....
-+
-* Reset Neutron's ML2 database
-+
-....
-# sudo mysql -e "drop database if exists neutron_ml2;"
-# sudo mysql -e "create database neutron_ml2 character set utf8;"
-# sudo mysql -e "grant all on neutron_ml2.* to 'neutron'@'%';"
-# sudo neutron-db-manage --config-file /usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini upgrade head
-....
-+
-* Start Neutron Server
-+
-....
-# sudo systemctl start neutron-server
-....
-+
-* Restart the Neutron DHCP service
-+
-....
-# system restart neutron-dhcp-agent.service
-....
-+
-* At this stage, your Open vSwitch configuration should be empty:
-+
-....
-[root@dneary-odl-compute2 ~]# ovs-vsctl show
-686989e8-7113-4991-a066-1431e7277e1f
- ovs_version: "2.3.1"
-....
-+
-* Set OpenDaylight as the manager on all nodes
-+
-....
-# ovs-vsctl set-manager tcp:127.0.0.1:6640
-....
-+
-* You should now see a section in your Open vSwitch configuration
- showing that you are connected to the OpenDaylight server, and OpenDaylight
- will automatically create a br-int bridge:
-+
-....
-[root@dneary-odl-compute2 ~]# ovs-vsctl show
-686989e8-7113-4991-a066-1431e7277e1f
- Manager "tcp:127.0.0.1:6640"
- is_connected: true
- Bridge br-int
- Controller "tcp:127.0.0.1:6633"
- is_connected: true
- fail_mode: secure
- Port "ens33"
- Interface "ens33"
- ovs_version: "2.3.1"
-....
-+
-* Add the default flow to OVS to forward packets to controller when there is a table-miss,
-+
-....
-ovs-ofctl --protocols=OpenFlow13 add-flow br-int priority=0,actions=output:CONTROLLER
-....
-+
-* Please see the https://wiki.opendaylight.org/view/VTN:Beryllium:User_Guide:OpenStack_PackStack_Support[VTN OpenStack PackStack support guide on the wiki] to create VM's from OpenStack Horizon GUI.
-
-==== Implementation details
-
-===== VTN Manager:
-Install *odl-vtn-manager-neutron* feature which provides the integration with Neutron interface.
-
- feature:install odl-vtn-manager-neutron
-
-It subscribes to the events from Open vSwitch and also implements the Neutron requests received by OpenDaylight.
-
-===== Functional Behavior
-
-.StartUp:
-* The ML2 implementation for OpenDaylight will ensure that when Open vSwitch is started, the ODL_IP_ADDRESS configured will be set as manager.
-* When OpenDaylight receives the update of the Open vSwitch on port 6640 (manager port), VTN Manager handles the event and adds a bridge with required port mappings to the Open vSwitch at the OpenStack node.
-* When Neutron starts up, a new network create is POSTed to OpenDaylight, for which VTN Manager creates a Virtual Tenant Network.
-* *Network and Sub-Network Create:* Whenever a new sub network is created, VTN Manager will handle the same and create a vbridge under the VTN.
-* *VM Creation in OpenStack:* The interface mentioned as integration bridge in the configuration file will be added with more interfaces on creation of a new VM in OpenStack and the network is provisioned for it by the VTN Neutron feature. The addition of a new port is captured by the VTN Manager and it creates a vbridge interface with port mapping for the particular port. When the VM starts to communicate with other VMs, the VTN Manger will install flows in the Open vSwitch and other OpenFlow switches to facilitate communication between them.
-
-NOTE:
- To use this feature, VTN feature should be installed
-
-==== Reference
-
-https://wiki.opendaylight.org/images/5/5c/Integration_of_vtn_and_ovsdb_for_helium.pdf
+++ /dev/null
-= OpenDaylight and OpenStack
-:docinfo:
-
-[preface]
-== Overview
-http://www.openstack.org[OpenStack] is a popular open source Infrastructure
-as a service project, covering compute, storage and network management.
-OpenStack can use OpenDaylight as its network management provider through the
-Modular Layer 2 (ML2) north-bound plug-in. OpenDaylight manages the network
-flows for the OpenStack compute nodes via the OVSDB south-bound plug-in. This
-page describes how to set that up, and how to tell when everything is working.
-
-== Installing OpenStack
-
-Installing OpenStack is out of scope for this document, but to get started, it
-is useful to have a minimal multi-node OpenStack deployment.
-
-The reference deployment we will use for this document is a 3 node cluster:
-
-* One control node containing all of the management services for OpenStack
- (Nova, Neutron, Glance, Swift, Cinder, Keystone)
-* Two compute nodes running nova-compute
-* Neutron using the OVS back-end and vxlan for tunnels
-
-Once you have installed OpenStack, verify that it is working by connecting
-to Horizon and performing a few operations. To check the Neutron
-configuration, create two instances on a private subnet bridging to your
-public network, and verify that you can connect to them, and that they can
-see each other.
-
-== Installing OpenDaylight
-
-include::openstack-ovsdb.adoc[]
-
-include::odl-groupbasedpolicy-neutronmapper-user-guide.adoc[]
-
-include::openstack-vtn.adoc[]
-
-[[Category:Documentation]]
-[[Category:OpenStack]]
-
<module>readme</module> <!-- this is just to make sure readme builds -->
<module>developer-guide</module>
<module>user-guide</module>
- <module>howto-openstack</module>
</modules>
</project>
== Atrium User Guide
-=== Overview
-Project Atrium is an open source SDN distribution - a vertically integrated
-set of open source components which together form a complete SDN stack.
-It’s goals are threefold:
-
-* Close the large integration-gap of the elements that are needed to build an SDN stack -
- while there are multiple choices at each layer, there are missing pieces with poor or no integration.
-* Overcome a massive gap in interoperability - This exists both at the switch level,
- where existing products from different vendors have limited compatibility,
- making it difficult to connect an arbitrary switch and controller and at an API level,
- where its difficult to write a portable application across multiple controller platforms.
-* Work closely with network operators on deployable use-cases, so that they could download
- near production quality code from one location, and get started with functioning
- software defined networks on real hardware.
-
-=== Architecture
-The key components of Atrium BGP Peering Router Application are as follows:
-
-* Data Plane Switch - Data plane switch is the entity that uses flow table entries installed by
- BGP Routing Application through SDN controller. In the simplest form data plane switch with
- the installed flows act like a BGP Router.
-* OpenDaylight Controller - OpenDaylight SDN controller has many utility applications or plugins
- which are leveraged by the BGP Router application to manage the control plane information.
-* BGP Routing Application - An application running within the OpenDaylight runtime environment
- to handle I-BGP updates.
-* <<_didm_user_guide,DIDM>> - DIDM manages the drivers specific to each data plane switch connected to the controller.
- The drivers are created primarily to hide the underlying complexity of the devices
- and to expose a uniform API to applications.
-* Flow Objectives API - The driver implementation provides a pipeline abstraction and
- exposes Flow Objectives API. This means applications need to be aware of only the
- Flow Objectives API without worrying about the Table IDs or the pipelines.
-* Control Plane Switch - This component is primarily used to connect the OpenDaylight SDN controller
- with the Quagga Soft-Router and establish a path for forwarding E-BGP packets to and from Quagga.
-* Quagga soft router - An open source routing software that handles E-BGP updates.
-
-=== Running Atrium
-* To run the Atrium BGP Routing Application in OpenDaylight distribution,
- simply install the `odl-atrium-all` feature.
-+
- feature:install odl-atrium-all
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/atrium-user-guide.html
include::core-release-notes.adoc[OpenDaylight Release Notes]
/////
-= Getting Started with OpenDaylight
+A significant amount of this guide has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/index.html
-[partintro]
-
-This first part of the user guide covers the basic user operations of the OpenDaylight Release using the generic base functionality.
-
-include::ch-introduction.adoc[OpenDaylight Controller Overview]
-
-include::ch-dlux.adoc[]
-
-include::ch-xsql-commands.adoc[]
-
-include::ch-clustering.adoc[]
+Please look there as well as here for any content.
= Applications and Plugins
-[partintro]
-
-This second part of the user guide covers project specific usage instructions.
-
include::alto/alto-user-guide.adoc[ALTO]
include::aaa/aaa.adoc[AAA]
+++ /dev/null
-== Setting Up Clustering
-
-=== Clustering Overview
-
-Clustering is a mechanism that enables multiple processes and programs to work
-together as one entity. For example, when you search for something on
-google.com, it may seem like your search request is processed by only one web
-server. In reality, your search request is processed by may web servers
-connected in a cluster. Similarly, you can have multiple instances of
-OpenDaylight working together as one entity.
-
-Advantages of clustering are:
-
-* Scaling: If you have multiple instances of OpenDaylight running, you can
- potentially do more work and store more data than you could with only one
- instance. You can also break up your data into smaller chunks (shards) and
- either distribute that data across the cluster or perform certain operations
- on certain members of the cluster.
-* High Availability: If you have multiple instances of OpenDaylight running and
- one of them crashes, you will still have the other instances working and
- available.
-* Data Persistence: You will not lose any data stored in OpenDaylight after a
- manual restart or a crash.
-
-The following sections describe how to set up clustering on both individual and
-multiple OpenDaylight instances.
-
-=== Single Node Clustering
-
-To enable clustering on a single instance of OpenDaylight, perform the
-following steps:
-
-. Download, unzip, and run the OpenDaylight distribution
-. Install the clustering feature:
-+
- feature:install odl-mdsal-clustering
-
-NOTE: This will enabled the cluster-ready version of the MD-SAL data store, but
- will not actually create a cluster of multiple instances. The result is
- that you will get data persistence, but not the scaling or high
- availability advantages.
-
-=== Multiple Node Clustering
-
-The following sections describe how to set up multiple node clusters in OpenDaylight.
-
-==== Deployment Considerations
-
-To implement clustering, the deployment considerations are as follows:
-
-* To set up a cluster with multiple nodes, we recommend that you use a minimum
- of three machines. You can set up a cluster with just two nodes. However, if
- one of the two nodes fail, the cluster will not be operational.
-+
-NOTE: This is because clustering in OpenDaylight requires a majority of the
- nodes to be up and one node cannot be a majority of two nodes.
-+
-* Every device that belongs to a cluster needs to have an identifier.
- OpenDaylight uses the node's +role+ for this purpose. After you define the
- first node's role as _member-1_ in the +akka.conf+ file, OpenDaylight uses
- _member-1_ to identify that node.
-
-* Data shards are used to contain all or a certain segment of a OpenDaylight's
- MD-SAL datastore. For example, one shard can contain all the inventory data
- while another shard contains all of the topology data.
-+
-If you do not specify a module in the +modules.conf+ file and do not specify
-a shard in +module-shards.conf+, then (by default) all the data is placed in
-the default shard (which must also be defined in +module-shards.conf+ file).
-Each shard has replicas configured. You can specify the details of where the
-replicas reside in +module-shards.conf+ file.
-
-* If you have a three node cluster and would like to be able to tolerate any
- single node crashing, a replica of every defined data shard must be running
- on all three cluster nodes.
-+
-NOTE: This is because OpenDaylight's clustering implementation requires a
- majority of the defined shard replicas to be running in order to
- function. If you define data shard replicas on two of the cluster nodes
- and one of those nodes goes down, the corresponding data shards will not
- function.
-+
-* If you have a three node cluster and have defined replicas for a data shard
- on each of those nodes, that shard will still function even if only two of
- the cluster nodes are running. Note that if one of those remaining two nodes
- goes down, the shard will not be operational.
-
-* It is recommended that you have multiple seed nodes configured. After a
- cluster member is started, it sends a message to all of its seed nodes.
- The cluster member then sends a join command to the first seed node that
- responds. If none of its seed nodes reply, the cluster member repeats this
- process until it successfully establishes a connection or it is shut down.
-
-* After a node is unreachable, it remains down for configurable period of time
- (10 seconds, by default). Once a node goes down, you need to restart it so
- that it can rejoin the cluster. Once a restarted node joins a cluster, it
- will synchronize with the lead node automatically.
-
-==== Setting Up a Multiple Node Cluster
-
-To run OpenDaylight in a three node cluster, perform the following:
-
-First, determine the three machines that will make up the cluster. After that,
-do the following on each machine:
-
-. Copy the OpenDaylight distribution zip file to the machine.
-. Unzip the distribution.
-. Open the following .conf files:
-** configuration/initial/akka.conf
-** configuration/initial/module-shards.conf
-. In each configuration file, make the following changes:
-.. Find every instance of the following lines and replace _127.0.0.1_ with the
- hostname or IP address of the machine on which this file resides and
- OpenDaylight will run:
-+
- netty.tcp {
- hostname = "127.0.0.1"
-+
-NOTE: The value you need to specify will be different for each node in the
- cluster.
-+
-.. Find the following lines and replace _127.0.0.1_ with the hostname or IP
- address of any of the machines that will be part of the cluster:
-+
- cluster {
- seed-nodes = ["akka.tcp://opendaylight-cluster-data@127.0.0.1:2550"]
-+
-.. Find the following section and specify the role for each member node. Here
- we assign the first node with the _member-1_ role, the second node with the
- _member-2_ role, and the third node with the _member-3_ role:
-+
- roles = [
- "member-1"
- ]
-+
-NOTE: This step should use a different role on each node.
-+
-.. Open the configuration/initial/module-shards.conf file and update the
- replicas so that each shard is replicated to all three nodes:
-+
- replicas = [
- "member-1",
- "member-2",
- "member-3"
- ]
-+
-For reference, view a sample config files <<_sample_config_files,below>>.
-+
-. Move into the +<karaf-distribution-directory>/bin+ directory.
-. Run the following command:
-+
- JAVA_MAX_MEM=4G JAVA_MAX_PERM_MEM=512m ./karaf
-+
-. Enable clustering by running the following command at the Karaf command line:
-+
- feature:install odl-mdsal-clustering
-
-OpenDaylight should now be running in a three node cluster. You can use any of
-the three member nodes to access the data residing in the datastore.
-
-// This doesn't work at the moment. The install -s command fails.
-//===== Debugging Clustering
-//
-//To debug clustering first install Jolokia by entering the following command:
-//
-// install -s mvn:org.jolokia/jolokia-osgi/1.1.5
-//
-//After that, you can view specific information about the cluster. For example,
-//to view information about shard designated as _member-1_ on a node, query the
-//shard's data by sending the following HTTP request:
-//
-//*GET http://_<host>_:8181/jolokia/read/org.opendaylight.controller:Category=Shards,name=member-1-shard-inventory-config,type=DistributedConfigDatastore*
-//
-//NOTE: If prompted, enter your credentials for OpenDaylight. The default
-// credentials are a username and password of _admin_.
-//
-//This request should return the following information:
-//
-// {
-// "timestamp": 1410524741,
-// "status": 200,
-// "request": {
-// "mbean": "org.opendaylight.controller:Category=Shards,name=member-1-shard-inventory-config,type=DistributedConfigDatastore",
-// "type": "read"
-// },
-// "value": {
-// "ReadWriteTransactionCount": 0,
-// "LastLogIndex": -1,
-// "MaxNotificationMgrListenerQueueSize": 1000,
-// "ReadOnlyTransactionCount": 0,
-// "LastLogTerm": -1,
-// "CommitIndex": -1,
-// "CurrentTerm": 1,
-// "FailedReadTransactionsCount": 0,
-// "Leader": "member-1-shard-inventory-config",
-// "ShardName": "member-1-shard-inventory-config",
-// "DataStoreExecutorStats": {
-// "activeThreadCount": 0,
-// "largestQueueSize": 0,
-// "currentThreadPoolSize": 1,
-// "maxThreadPoolSize": 1,
-// "totalTaskCount": 1,
-// "largestThreadPoolSize": 1,
-// "currentQueueSize": 0,
-// "completedTaskCount": 1,
-// "rejectedTaskCount": 0,
-// "maxQueueSize": 5000
-// },
-// "FailedTransactionsCount": 0,
-// "CommittedTransactionsCount": 0,
-// "NotificationMgrExecutorStats": {
-// "activeThreadCount": 0,
-// "largestQueueSize": 0,
-// "currentThreadPoolSize": 0,
-// "maxThreadPoolSize": 20,
-// "totalTaskCount": 0,
-// "largestThreadPoolSize": 0,
-// "currentQueueSize": 0,
-// "completedTaskCount": 0,
-// "rejectedTaskCount": 0,
-// "maxQueueSize": 1000
-// },
-// "LastApplied": -1,
-// "AbortTransactionsCount": 0,
-// "WriteOnlyTransactionCount": 0,
-// "LastCommittedTransactionTime": "1969-12-31 16:00:00.000",
-// "RaftState": "Leader",
-// "CurrentNotificationMgrListenerQueueStats": []
-// }
-// }
-//
-//The key information is the name of the shard. Shard names are structured as follows:
-//
-//_<member-name>_-shard-_<shard-name-as-per-configuration>_-_<store-type>_
-//
-//Here are a couple sample data short names:
-//
-//* member-1-shard-topology-config
-//* member-2-shard-default-operational
-
-===== Sample Config Files
-
-.Sample +akka.conf+ file
-----
-odl-cluster-data {
- bounded-mailbox {
- mailbox-type = "org.opendaylight.controller.cluster.common.actor.MeteredBoundedMailbox"
- mailbox-capacity = 1000
- mailbox-push-timeout-time = 100ms
- }
-
- metric-capture-enabled = true
-
- akka {
- loglevel = "DEBUG"
- loggers = ["akka.event.slf4j.Slf4jLogger"]
-
- actor {
-
- provider = "akka.cluster.ClusterActorRefProvider"
- serializers {
- java = "akka.serialization.JavaSerializer"
- proto = "akka.remote.serialization.ProtobufSerializer"
- }
-
- serialization-bindings {
- "com.google.protobuf.Message" = proto
-
- }
- }
- remote {
- log-remote-lifecycle-events = off
- netty.tcp {
- hostname = "10.194.189.96"
- port = 2550
- maximum-frame-size = 419430400
- send-buffer-size = 52428800
- receive-buffer-size = 52428800
- }
- }
-
- cluster {
- seed-nodes = ["akka.tcp://opendaylight-cluster-data@10.194.189.96:2550"]
-
- auto-down-unreachable-after = 10s
-
- roles = [
- "member-1"
- ]
-
- }
- }
-}
-
-odl-cluster-rpc {
- bounded-mailbox {
- mailbox-type = "org.opendaylight.controller.cluster.common.actor.MeteredBoundedMailbox"
- mailbox-capacity = 1000
- mailbox-push-timeout-time = 100ms
- }
-
- metric-capture-enabled = true
-
- akka {
- loglevel = "INFO"
- loggers = ["akka.event.slf4j.Slf4jLogger"]
-
- actor {
- provider = "akka.cluster.ClusterActorRefProvider"
-
- }
- remote {
- log-remote-lifecycle-events = off
- netty.tcp {
- hostname = "10.194.189.96"
- port = 2551
- }
- }
-
- cluster {
- seed-nodes = ["akka.tcp://opendaylight-cluster-rpc@10.194.189.96:2551"]
-
- auto-down-unreachable-after = 10s
- }
- }
-}
-----
-
-.Sample +module-shards.conf+ file
-----
-module-shards = [
- {
- name = "default"
- shards = [
- {
- name="default"
- replicas = [
- "member-1",
- "member-2",
- "member-3"
- ]
- }
- ]
- },
- {
- name = "topology"
- shards = [
- {
- name="topology"
- replicas = [
- "member-1",
- "member-2",
- "member-3"
- ]
- }
- ]
- },
- {
- name = "inventory"
- shards = [
- {
- name="inventory"
- replicas = [
- "member-1",
- "member-2",
- "member-3"
- ]
- }
- ]
- },
- {
- name = "toaster"
- shards = [
- {
- name="toaster"
- replicas = [
- "member-1",
- "member-2",
- "member-3"
- ]
- }
- ]
- }
-]
-----
\ No newline at end of file
+++ /dev/null
-== Using the OpenDaylight User Interface (DLUX)
-
-This section introduces you to the OpenDaylight User Experience (DLUX) application.
-
-=== Getting Started with DLUX
-
-DLUX provides a number of different Karaf features, which you can enable and disable separately. In Beryllum they are:
-. odl-dlux-core
-. odl-dlux-node
-. odl-dlux-yangui
-. odl-dlux-yangvisualizer
-
-=== Logging In
-
-To log in to DLUX, after installing the application:
-
-. Open a browser and enter the login URL http://<your-karaf-ip>:8181/index.html in your browser (Chrome is recommended).
-. Login to the application with your username and password credentials.
-
-NOTE: OpenDaylight's default credentials are _admin_ for both the username and password.
-
-=== Working with DLUX
-
-After you login to DLUX, if you enable only odl-dlux-core feature, you will see only topology application available in the left pane.
-
-NOTE: To make sure topology displays all the details, enable the odl-l2switch-switch feature in Karaf.
-
-DLUX has other applications such as node, yang UI and those apps won't show up, until you enable their features odl-dlux-node and odl-dlux-yangui respectively in the Karaf distribution.
-
-.DLUX Modules
-image::dlux-login.png["DLUX Page",width=500]
-
-NOTE: If you install your application in dlux, they will also show up on the left hand navigation after browser page refresh.
-
-=== Viewing Network Statistics
-
-The *Nodes* module on the left pane enables you to view the network statistics and port information for the switches in the network.
-
-To use the *Nodes* module:
-
-'''
-
-. Select *Nodes* on the left pane.
- The right pane displays atable that lists all the nodes, node connectors and the statistics.
-. Enter a node ID in the *Search Nodes* tab to search by node connectors.
-. Click on the *Node Connector* number to view details such as port ID, port name, number of ports per switch, MAC Address, and so on.
-. Click *Flows* in the Statistics column to view Flow Table Statistics for the particular node like table ID, packet match, active flows and so on.
-. Click *Node Connectors* to view Node Connector Statistics for the particular node ID.
-
-'''
-
-=== Viewing Network Topology
-
-The Topology tab displays a graphical representation of network topology created.
-
-NOTE: DLUX does not allow for editing or adding topology information. The topology is generated and edited in other modules, e.g., the OpenFlow plugin. OpenDaylight stores this information in the MD-SAL datastore where DLUX can read and display it.
-
-To view network topology:
-
-. Select *Topology* on the left pane. You will view the graphical representation on the right pane.
- In the diagram blue boxes represent the switches, the black represents the hosts available, and lines represents how the switches and hosts are connected.
-. Hover your mouse on hosts, links, or switches to view source and destination ports.
-. Zoom in and zoom out using mouse scroll to verify topology for larger topologies.
-
-.Topology Module
-image::dlux-topology.png["DLUX Topology Page",width=500]
-
-=== Interacting with the YANG-based MD-SAL datastore
-
-The *Yang UI* module enables you to interact with the YANG-based MD-SAL datastore. For more information about YANG and how it interacts with the MD-SAL datastore, see the _Controller_ and _YANG Tools_ section of the _OpenDaylight Developer Guide_.
-
-.Yang UI
-image::dlux-yang-ui-screen.png["DLUX Yang UI Page",width=500]
-
-To use Yang UI:
-
-. Select *Yang UI* on the left pane. The right pane is divided in two parts.
-. The top part displays a tree of APIs, subAPIs, and buttons to call possible functions (GET, POST, PUT, and DELETE).
-+
-NOTE: Not every subAPI can call every function. For example, subAPIs in the _operational_ store have GET functionality only.
-+
-Inputs can be filled from OpenDaylight when existing data from OpenDaylight is displayed or can be filled by user on the page and sent to OpenDaylight.
-+
-Buttons under the API tree are variable. It depends on subAPI specifications. Common buttons are:
-+
-* GET to get data from OpenDaylight,
-* PUT and POST for sending data to OpenDaylight for saving
-* DELETE for sending data to OpenDaylight for deleting.
-+
-You must specify the xpath for all these operations. This path is displayed in the same row before buttons and it may include text inputs for specific path element identifiers.
-+
-.Yang API Specification
-image::dlux-yang-api-specification.png["DLUX Yang UI API Specification Page",width=500]
-. The bottom part of the right pane displays inputs according to the chosen subAPI.
-+
-* Lists are handled as a special case. For example, a device can store multiple flows. In this case "flow" is name of the list and every list element is identified by a unique key value. Elements of a list can, in turn, contain other lists.
-* In Yang UI, each list element is rendered with the name of the list it belongs to, its key, its value, and a button for removing it from the list.
-+
-.Yang UI API Specification
-image::dlux-yang-sub-api-screen.png["DLUX Yang UI Sub API Specification Page",width=500]
-+
-. After filling in the relevant inputs, click the *Show Preview* button under the API tree to display request that will be sent to OpenDaylight.
- A pane is displayed on the right side with text of request when some input is filled.
-
-==== Displaying Topology on the *Yang UI*
-
-To display topology:
-
-. Select subAPI network-topology <topology revision number> == > operational == > network-topology.
-. Get data from OpenDaylight by clicking on the "GET" button.
-. Click *Display Topology*.
-
-.DLUX Yang Topology
-image::dlux-yang-topology.png["DLUX Yang Topology Page",width=500]
-
-==== Configuring List Elements on the *Yang UI*
-
-Lists in Yang UI are displayed as trees. To expand or collapse a list, click the arrow before name of the list. To configure list elements in Yang UI:
-
-. To add a new list element with empty inputs use the plus icon-button **+** that is provided after list name.
-. To remove several list elements, use the *X* button that is provided after every list element.
-+
-.DLUX List Elements
-image::dlux-yang-list-elements.png[DLUX list elements,width=500]
-+
-. In the YANG-based data store all elements of a list must have a unique key. If you try to assign two or more elements the same key, a warning icon *!* is displayed near their name buttons.
-+
-.DLUX List Warnings
-image::dlux-yang-list-warning.png[DLUX list warnings,width=500]
-+
-. When the list contains at least one list element, after the *+* icon, there are buttons to select each individual list element. You can choose one of them by clicking on it. In addition, to the right of the list name, there is a button which will display a vertically scrollable pane with all the list elements.
-+
-.DLUX List Button1
-image::dlux-yang-list-button1.png[DLUX list button1,width=500]
+++ /dev/null
-== OpenDaylight Controller Overview
-
-The OpenDaylight controller is JVM software and can be run from any operating system and hardware as long as it supports Java. The controller is an implementation of the Software Defined Network (SDN) concept and makes use of the following tools:
-
-* *Maven*: OpenDaylight uses Maven for easier build automation. Maven uses pom.xml (Project Object Model) to script the dependencies between bundle and also to describe what bundles to load and start.
-
-* *OSGi*: This framework is the back-end of OpenDaylight as it allows dynamically loading bundles and packages JAR files, and binding bundles together for exchanging information.
-* *JAVA interfaces*: Java interfaces are used for event listening, specifications, and forming patterns. This is the main way in which specific bundles implement call-back functions for events and also to indicate awareness of specific state.
-* *REST APIs*: These are northbound APIs such as topology manager, host tracker, flow programmer, static routing, and so on.
-
-The controller exposes open northbound APIs which are used by applications. The OSGi framework and bidirectional REST are supported for the northbound APIs. The OSGi framework is used for applications that run in the same address space as the controller while the REST (web-based) API is used for applications that do not run in the same address space (or even the same system) as the controller. The business logic and algorithms reside in the applications. These applications use the controller to gather network intelligence, run its algorithm to do analytics, and then orchestrate the new rules throughout the network.
-On the southbound, multiple protocols are supported as plugins, e.g. OpenFlow 1.0, OpenFlow 1.3, BGP-LS, and so on. The OpenDaylight controller starts with an OpenFlow 1.0 southbound plugin. Other OpenDaylight contributors begin adding to the controller code. These modules are linked dynamically into a *Service Abstraction Layer* (SAL).
-
-The SAL exposes services to which the modules north of it are written. The SAL figures out how to fulfill the requested service irrespective of the underlying protocol used between the controller and the network devices. This provides investment protection to the applications as OpenFlow and other protocols evolve over time. For the controller to control devices in its domain, it needs to know about the devices, their capabilities, reachability, and so on. This information is stored and managed by the *Topology Manager*. The other components like ARP handler, Host Tracker, Device Manager, and Switch Manager help in generating the topology database for the Topology Manager.
-
-For a more detailed overview of the OpenDaylight controller, see the _OpenDaylight Developer Guide_.
\ No newline at end of file
+++ /dev/null
-== Running XSQL Console Commands and Queries
-
-//* <<XSQL Overview>>
-//* <<Installing XSQL>>
-//* <<XSQL Console Commands>>
-//* <<XSQL Queries>>
-//** <<Example: skip Criteria Operator>>
-:toc:
-
-=== XSQL Overview
-
-XSQL is an XML-based query language that describes simple stored procedures
-which parse XML data, query or update database tables, and compose XML output.
-XSQL allows you to query tree models like a sequential database. For example,
-you could run a query that lists all of the ports configured on a particular
-module and their attributes.
-
-The following sections cover the XSQL installation process, supported XSQL
-commands, and the way to structure queries.
-
-=== Installing XSQL
-
-To run commands from the XSQL console, you must first install XSQL on your
-system:
-
-. Navigate to the directory in which you unzipped OpenDaylight
-. Start Karaf:
-+
- ./bin/karaf
-+
-. Install XSQL:
-+
- feature:install odl-mdsal-xsql
-
-=== XSQL Console Commands
-
-To enter a command in the XSQL console, structure the command as follows:
-*odl:xsql* _<XSQL command>_
-
-The following table describes the commands supported in this OpenDaylight
-release.
-
-.Supported XSQL Console Commands
-[cols="30%,70%",options="headers"]
-|==============================================
-| *Command* | *Description*
-| *r*
-| Repeats the last command you executed.
-| *list vtables*
-| Lists the schema node containers that are currently installed. Whenever an
-OpenDaylight module is installed, its YANG model is placed in the schema
-context. At that point, the XSQL receives a notification, confirms that the
-module's YANG model resides in the schema context and then maps the model to
-XSQL by setting up the necessary vtables and vfields. This command is useful
-when you need to determine vtable information for a query.
-| *list vfields* _<vtable name>_
-| Lists the vfields present in a specific vtable. This command is useful when
-you need to determine vfields information for a query.
-| *jdbc* _<ip address>_
-| When the ODL server is behind a firewall, and the JDBC client cannot connect
-to the JDBC server, run this command to start the client as a server and
-establish a connection.
-| *exit*
-| Closes the console.
-| *tocsv*
-| Enables or disables the forwarding of query output as a .csv file.
-| *filename* _<filename>_
-| Specifies the .tocsv file to which the query data is exported. If you do not
-specify a value for this option when the toccsv option is enabled, the filename
-for the query data file is generated automatically.
-|==============================================
-
-=== XSQL Queries
-
-You can run a query to extract information that meets the criteria you specify
-using the information provided by the *list vtables* and *list vfields*
-_<vtable name>_ commands. Any query you run should be structured as follows:
-
-*select* _<vfields you want to search for, separated by a comma and a space>_
-*from* _<vtables you want to search in, separated by a comma and a space>_
-*where* _<criteria>_ *'*_<criteria operator>_*';*
-
-For example, if you want to search the nodes/node ID field in the
-nodes/node-connector table and find every instance of the Hardware-Address
-object that contains _BA_ in its text string, enter the following query:
-
- select nodes/node.ID from nodes/node-connector where Hardware-Address like '%BA%';
-
-The following criteria operators are supported:
-
-.Supported XSQL Query Criteria Operators
-[cols="20%,80%",options="headers"]
-|==============================================
-| *Criteria Operators* | *Description*
-| *=* | Lists results that equal the value you specify.
-| *!=* | Lists results that do not equal the value you specify.
-| *like* | Lists results that contain the substring you specify. For
- example, if you specify *like %BC%*, every string that contains
- that particular substring is displayed.
-| *<* | Lists results that are less than the value you specify.
-| *>* | Lists results that are more than the value you specify.
-| *and* | Lists results that match both values you specify.
-| *or* | Lists results that match either of the two values you specify.
-| *>=* | Lists results that are more than or equal to the value you specify.
-| *<=* | Lists results that are less than or equal to the value you specify.
-| *is null* | Lists results for which no value is assigned.
-| *not null* | Lists results for which any value is assigned.
-| *skip* | Use this operator to list matching results from a child node,
- even if its parent node does not meet the specified criteria.
- See the following example for more information.
-|==============================================
-
-==== Example: Skip Criteria Operator
-
-If you are looking at the following structure and want to determine all of the
-ports that belong to a YY type module:
-
-* Network Element 1
-** Module 1, Type XX
-*** Module 1.1, Type YY
-**** Port 1
-**** Port 2
-** Module 2, Type YY
-*** Port 1
-*** Port 2
-
-If you specify *Module.Type='YY'* in your query criteria, the ports associated
-with module 1.1 will not be returned since its parent module is type XX.
-Instead, enter *Module.Type='YY' or skip Module!='YY'*. This tells XSQL to
-disregard any parent module data that does not meet the type YY criteria and
-collect results for any matching child modules. In this example, you are
-instructing the query to skip module 1 and collect the relevant data from
-module 1.1.
-
== L2Switch User 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
-
-=== Configuring L2Switch
-This sections below give details about the configuration settings for the components that can be configured.
-
-//The base distribution configuration files are located in distribution/base/target/distributions-l2switch-base-0.1.0-SNAPSHOT-osgipackage/opendaylight/configuration/initial
-
-//The karaf distribution configuration files are located in distribution/karaf/target/assembly/etc/opendaylight/karaf
-
-=== Configuring Loop Remover
-* 52-loopremover.xml
- ** 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
- ** 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"
- ** 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"
- ** 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"
- ** 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"
- ** 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.
-
-=== Configuring Arp Handler
-* 54-arphandler.xml
- ** 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
- *** This field is only relevant when "is-proactive-flood-mode" is set to "true"
- ** 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"
- ** 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"
- ** 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"
- ** 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"
- ** 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"
- ** 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"
- ** 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"
-
-=== Configuring Address Tracker
-* 56-addresstracker.xml
- ** 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.
-
-=== Configuring L2Switch Main
-* 58-l2switchmain.xml
- ** 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"
-
-=== Running the L2Switch project
-
-To run the L2 Switch inside the Lithium OpenDaylight distribution simply install the `odl-l2switch-switch-ui` feature;
-
- feature:install odl-l2switch-switch-ui
-
-//==== Check out the project using git
-// git clone https://git.opendaylight.org/gerrit/p/l2switch.git
-//
-//The above command will create a directory called "l2switch" with the project.
-//
-//==== Run the distribution
-//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.
-
-=== 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
-
-.Address Observations
-image::l2switch-address-observations.png["AddressObservations image",width=500]
-
-=== 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/
-
-.Hosts
-image::l2switch-hosts.png["Hosts image",width=500]
-
-=== 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
-
-.STP status
-image::l2switch-stp-status.png["STPStatus image",width=500]
-
-=== 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
-
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/l2switch-user-guide.html
== Neutron Service User Guide
-=== Overview
-This Karaf feature (`odl-neutron-service`) provides integration support for OpenStack Neutron
-via the OpenDaylight ML2 mechanism driver. The Neutron Service is only one of the
-components necessary for OpenStack integration. For those related components
-please refer to documentations of each component:
-
-* https://wiki.openstack.org/wiki/Neutron
-* https://launchpad.net/networking-odl
-* http://git.openstack.org/cgit/openstack/networking-odl/
-* https://wiki.opendaylight.org/view/NeutronNorthbound:Main
-
-==== Use cases and who will use the feature
-If you want OpenStack integration with OpenDaylight, you will need
-this feature with an OpenDaylight provider feature like ovsdb/netvirt, group based
-policy, VTN, and lisp mapper. For provider configuration, please refer
-to each individual provider's documentation. Since the Neutron service only provides the northbound
-API for the OpenStack Neutron ML2 mechanism driver. Without those provider
-features, the Neutron service itself isn't useful.
-
-=== Neutron Service feature Architecture
-The Neutron service provides northbound API for OpenStack Neutron via
-RESTCONF and also its dedicated REST API.
-It communicates through its YANG model with providers.
-
-image::neutron/odl-neutron-service-architecture.png[height="450px", width="550px", title="Neutron Service Architecture"]
-// image original https://docs.google.com/drawings/d/14CWAo1WQrCMHzNGDeg57P9CiqpkiAE4_njr_0OgAUsw/edit?usp=sharing
-
-
-=== Configuring Neutron Service feature
-As the Karaf feature includes everything necessary for communicating
-northbound, no special configuration is needed.
-Usually this feature is used with an OpenDaylight southbound plugin that implements
-actual network virtualization functionality and OpenStack Neutron.
-The user wants to setup those configurations. Refer to each related
-documentations for each configurations.
-
-=== Administering or Managing `odl-neutron-service`
-There is no specific configuration regarding to Neutron service itself.
-For related configuration, please refer to OpenStack Neutron configuration
-and OpenDaylight related services which are providers for OpenStack.
-
-==== installing `odl-neutron-service` while the controller running
-
-. While OpenDaylight is running, in Karaf prompt, type:
- `feature:install odl-neutron-service`.
-. Wait a while until the initialization is done and the controller stabilizes.
-
-`odl-neutron-service` provides only a unified interface for OpenStack Neutron.
-It doesn't provide actual functionality for network virtualization.
-Refer to each OpenDaylight project documentation for actual configuration with
-OpenStack Neutron.
-
-=== Neutron Logger
-Another service, the Neutron Logger, is provided for debugging/logging purposes.
-It logs changes on Neutron YANG models.
-
- feature:install odl-neutron-logger
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/neutron-service-user-guide.html
+++ /dev/null
-==== 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
-==== 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.
-
-[options="header",cols="20%,80%"]
-|===
-| 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
-----
+++ /dev/null
-==== 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.
-
-.REDIRECT SERVICE
-image::nic/Service_Chaining.png[REDIRECT SERVICE,width=400]
-
-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
-. First flow entry between the source host connected node and the ingress node of the configured service.
-. Second flow entry between the egress Node id the configured service and the ID and destination host connected host.
-. 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 <<_default_requirements,Downloading and deploy Karaf distribution>>.
-
-===== Configuration
-
-====== Mininet
-
-.CONFIGURATION THE NETWORK IN MININET
-image::nic/Redirect_flow.png[CONFIGURATION OF THE NETWORK]
-
-* 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
-----
+++ /dev/null
-==== 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:
-[options="header",cols="20%,80%"]
-|===
-| 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"}} ] } }'
-----
+++ /dev/null
-=== Simple Mininet topology
-
-[source,python]
-----
-!/usr/bin/python
-
-from mininet.topo import Topo
-
-class SimpleTopology( Topo ):
- "Simple topology example."
-
- def __init__( self ):
- "Create custom topo."
-
- # <1>
- Topo.__init__( self )
-
- # <2>
- 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' ) # <3>
-
- # <4>
- 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() ) }
-----
-<1> Initialize topology
-<2> Add hosts and switches
-<3> Host used to represent the service
-<4> Add links
-
-[quote]
-Source: https://gist.github.com/vinothgithub15/315d0a427d5afc39f2d7
+++ /dev/null
-==== 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 Beryllium 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
-----
== 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
-
-include::NIC_requirements.adoc[]
-
-include::NIC_redirect_test_topology.adoc[]
-
-include::NIC_How_To_configure_VTN_Renderer.adoc[How to configure VTN Renderer]
-
-include::NIC_How_To_configure_Redirect_Action.adoc[How to configure Redirect Action]
-
-include::NIC_How_To_configure_QoS_Attribute_Mapping.adoc[How to configure QoS Attribute Mapping]
-
-include::NIC_How_To_configure_Log_Action.adoc[How to configure Log Action]
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/network-intent-composition-(nic)-user-guide.html
== 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 <<_southbound_netconf_connector,NETCONF Southbound User Guide>> or
-https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf[NETCONF Southbound examples on the wiki].
-
-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 <<_southbound_netconf_connector,NETCONF Southbound User Guide>> or
-https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf[NETCONF Southbound examples on the wiki].
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/of-config-user-guide.html
== OpFlex agent-ovs User Guide
-=== Introduction
-agent-ovs is a policy agent that works with OVS to enforce a
-group-based policy networking model with locally attached virtual
-machines or containers. The policy agent is designed to work well with
-orchestration tools like OpenStack.
-
-=== Agent Configuration
-The agent configuration is handled using its config file which is by
-default found at "/etc/opflex-agent-ovs/opflex-agent-ovs.conf"
-
-Here is an example configuration file that documents the available
-options:
-
-----
-{
- // Logging configuration
- // "log": {
- // "level": "info"
- // },
-
- // Configuration related to the OpFlex protocol
- "opflex": {
- // The policy domain for this agent.
- "domain": "openstack",
-
- // The unique name in the policy domain for this agent.
- "name": "example-agent",
-
- // a list of peers to connect to, by hostname and port. One
- // peer, or an anycast pseudo-peer, is sufficient to bootstrap
- // the connection without needing an exhaustive list of all
- // peers.
- "peers": [
- // EXAMPLE:
- {"hostname": "10.0.0.30", "port": 8009}
- ],
-
- "ssl": {
- // SSL mode. Possible values:
- // disabled: communicate without encryption
- // encrypted: encrypt but do not verify peers
- // secure: encrypt and verify peer certificates
- "mode": "disabled",
-
- // The path to a directory containing trusted certificate
- // authority public certificates, or a file containing a
- // specific CA certificate.
- "ca-store": "/etc/ssl/certs/"
- },
-
- "inspector": {
- // Enable the MODB inspector service, which allows
- // inspecting the state of the managed object database.
- // Default: enabled
- "enabled": true,
-
- // Listen on the specified socket for the inspector
- // Default /var/run/opflex-agent-ovs-inspect.sock
- "socket-name": "/var/run/opflex-agent-ovs-inspect.sock"
- }
- },
-
- // Endpoint sources provide metadata about local endpoints
- "endpoint-sources": {
- // Filesystem path to monitor for endpoint information
- "filesystem": ["/var/lib/opflex-agent-ovs/endpoints"]
- },
-
- // Renderers enforce policy obtained via OpFlex.
- "renderers": {
- // Stitched-mode renderer for interoperating with a
- // hardware fabric such as ACI
- // EXAMPLE:
- "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
- // stiched-mode fabric.
- "remote-ip": "10.0.0.32",
-
- // UDP port number of the encapsulated traffic.
- "remote-port": 8472
- }
-
- // Encapsulate traffic with a locally-significant VLAN
- // tag
- // EXAMPLE:
- // "vlan" : {
- // // The name of the uplink interface in OVS
- // "encap-iface": "team0"
- // }
- },
-
- // Configure forwarding policy
- "forwarding": {
- // Configure the virtual distributed router
- "virtual-router": {
- // Enable virtual distributed router. Set to true
- // to enable or false to disable. Default true.
- "enabled": true,
-
- // Override MAC address for virtual router.
- // Default 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. This
- // is not required in stitched mode since the
- // hardware router will send them.
- "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"
- },
-
- "endpoint-advertisements": {
- // Enable generation of periodic ARP/NDP
- // advertisements for endpoints. Default true.
- "enabled": "true"
- }
- },
-
- // Location to store cached IDs for managing flow state
- "flowid-cache-dir": "/var/lib/opflex-agent-ovs/ids"
- }
- }
-}
-----
-
-=== Endpoint Registration
-The agent learns about endpoints using endpoint metadata files located
-by default in "/var/lib/opflex-agent-ovs/endpoints".
-
-These are JSON-format files such as the (unusually complex) example
-below:
-----
-{
- "uuid": "83f18f0b-80f7-46e2-b06c-4d9487b0c754",
- "policy-space-name": "test",
- "endpoint-group-name": "group1",
- "interface-name": "veth0",
- "ip": [
- "10.0.0.1", "fd8f:69d8:c12c:ca62::1"
- ],
- "dhcp4": {
- "ip": "10.200.44.2",
- "prefix-len": 24,
- "routers": ["10.200.44.1"],
- "dns-servers": ["8.8.8.8", "8.8.4.4"],
- "domain": "example.com",
- "static-routes": [
- {
- "dest": "169.254.169.0",
- "dest-prefix": 24,
- "next-hop": "10.0.0.1"
- }
- ]
- },
- "dhcp6": {
- "dns-servers": ["2001:4860:4860::8888", "2001:4860:4860::8844"],
- "search-list": ["test1.example.com", "example.com"]
- },
- "ip-address-mapping": [
- {
- "uuid": "91c5b217-d244-432c-922d-533c6c036ab4",
- "floating-ip": "5.5.5.1",
- "mapped-ip": "10.0.0.1",
- "policy-space-name": "common",
- "endpoint-group-name": "nat-epg"
- },
- {
- "uuid": "22bfdc01-a390-4b6f-9b10-624d4ccb957b",
- "floating-ip": "fdf1:9f86:d1af:6cc9::1",
- "mapped-ip": "fd8f:69d8:c12c:ca62::1",
- "policy-space-name": "common",
- "endpoint-group-name": "nat-epg"
- }
- ],
- "mac": "00:00:00:00:00:01",
- "promiscuous-mode": false
-}
-----
-
-The possible parameters for these files are:
-
-*uuid*:: A globally unique ID for the endpoint
-*endpoint-group-name*:: The name of the endpoint group for the endpoint
-*policy-space-name*:: The name of the policy space for the endpoint group.
-*interface-name*:: The name of the OVS interface to which the endpoint
-is attached
-*ip*:: A list of strings contains either IPv4 or IPv6 addresses that the
-endpoint is allowed to use
-*mac*:: The MAC address for the endpoint's interface.
-*promiscuous-mode*:: Allow traffic from this VM to bypass default port
-security
-*dhcp4*:: A distributed DHCPv4 configuration block (see below)
-*dhcp6*:: A distributed DHCPv6 configuration block (see below)
-*ip-address-mapping*:: A list of IP address mapping configuration blocks (see below)
-
-DHCPv4 configuration blocks can contain the following parameters:
-
-*ip*:: the IP address to return with DHCP. Must be one of the
-configured IPv4 addresses.
-*prefix*:: the subnet prefix length
-*routers*:: a list of default gateways for the endpoint
-*dns*:: a list of DNS server addresses
-*domain*:: The domain name parameter to send in the DHCP reply
-*static-routes*:: A list of static route configuration blocks, which
-contains a "dest", "dest-prefix", and "next-hop" parameters to send as
-static routes to the end host
-
-DHCPv6 configuration blocks can contain the following parameters:
-
-*dns*:: A list of DNS servers for the endpoint
-*search-patch*:: The DNS search path for the endpoint
-
-IP address mapping configuration blocks can contain the following
-parameters:
-
-*uuid*:: a globally unique ID for the virtual endpoint created by the
-mapping.
-*floating-ip*:: Map using DNAT to this floating IPv4 or IPv6 address
-*mapped-ip*:: the source IPv4 or IPv6 address; must be one of the IPs
-assigned to the endpoint.
-*endpoint-group-name*:: The name of the endpoint group for the NATed IP
-*policy-space-name*:: The name of the policy space for the NATed IP
-
-=== Inspector
-The Opflex inspector is a useful command-line tool that will allow you
-to inspect the state of the managed object database for the agent for
-debugging and diagnosis purposes.
-
-The command is called "gbp_inspect" and takes the following arguments:
-----
-# gbp_inspect -h
-Usage: ./gbp_inspect [options]
-Allowed options:
- -h [ --help ] Print this help message
- --log arg Log to the specified file (default
- standard out)
- --level arg (=warning) Use the specified log level (default
- info)
- --syslog Log to syslog instead of file or
- standard out
- --socket arg (=/usr/local/var/run/opflex-agent-ovs-inspect.sock)
- Connect to the specified UNIX domain
- socket (default /usr/local/var/run/opfl
- ex-agent-ovs-inspect.sock)
- -q [ --query ] arg Query for a specific object with
- subjectname,uri or all objects of a
- specific type with subjectname
- -r [ --recursive ] Retrieve the whole subtree for each
- returned object
- -f [ --follow-refs ] Follow references in returned objects
- --load arg Load managed objects from the specified
- file into the MODB view
- -o [ --output ] arg Output the results to the specified
- file (default standard out)
- -t [ --type ] arg (=tree) Specify the output format: tree, list,
- or dump (default tree)
- -p [ --props ] Include object properties in output
-----
-
-Here are some examples of the ways to use this tool.
-
-You can get information about the running system using one or more
-queries, which consist of an object model class name and optionally
-the URI of a specific object. The simplest query is to get a single
-object, nonrecursively:
-
-----
-# gbp_inspect -q DmtreeRoot
---* DmtreeRoot,/
-# gbp_inspect -q GbpEpGroup
---* GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
---* GbpEpGroup,/PolicyUniverse/PolicySpace/test/GbpEpGroup/group1/
-# gbp_inspect -q GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
---* GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
-----
-
-You can also display all the properties for each object:
-----
-# gbp_inspect -p -q GbpeL24Classifier
---* GbpeL24Classifier,/PolicyUniverse/PolicySpace/test/GbpeL24Classifier/classifier4/
- {
- connectionTracking : 1 (reflexive)
- dFromPort : 80
- dToPort : 80
- etherT : 2048 (ipv4)
- name : classifier4
- prot : 6
- }
---* GbpeL24Classifier,/PolicyUniverse/PolicySpace/test/GbpeL24Classifier/classifier3/
- {
- etherT : 34525 (ipv6)
- name : classifier3
- order : 100
- prot : 58
- }
---* GbpeL24Classifier,/PolicyUniverse/PolicySpace/test/GbpeL24Classifier/classifier2/
- {
- etherT : 2048 (ipv4)
- name : classifier2
- order : 101
- prot : 1
- }
-----
-
-You can also request to get the all the children of an object you query for:
-----
-# gbp_inspect -r -q GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
---* GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
- |-* GbpeInstContext,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/GbpeInstContext/
- `-* GbpEpGroupToNetworkRSrc,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/GbpEpGroupToNetworkRSrc/
-----
-
-You can also follow references found in any object downloads:
-----
-# gbp_inspect -fr -q GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
---* GbpEpGroup,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/
- |-* GbpeInstContext,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/GbpeInstContext/
- `-* GbpEpGroupToNetworkRSrc,/PolicyUniverse/PolicySpace/common/GbpEpGroup/nat-epg/GbpEpGroupToNetworkRSrc/
---* GbpFloodDomain,/PolicyUniverse/PolicySpace/common/GbpFloodDomain/fd_ext/
- `-* GbpFloodDomainToNetworkRSrc,/PolicyUniverse/PolicySpace/common/GbpFloodDomain/fd_ext/GbpFloodDomainToNetworkRSrc/
---* GbpBridgeDomain,/PolicyUniverse/PolicySpace/common/GbpBridgeDomain/bd_ext/
- `-* GbpBridgeDomainToNetworkRSrc,/PolicyUniverse/PolicySpace/common/GbpBridgeDomain/bd_ext/GbpBridgeDomainToNetworkRSrc/
---* GbpRoutingDomain,/PolicyUniverse/PolicySpace/common/GbpRoutingDomain/rd_ext/
- |-* GbpRoutingDomainToIntSubnetsRSrc,/PolicyUniverse/PolicySpace/common/GbpRoutingDomain/rd_ext/GbpRoutingDomainToIntSubnetsRSrc/122/%2fPolicyUniverse%2fPolicySpace%2fcommon%2fGbpSubnets%2fsubnets_ext%2f/
- `-* GbpForwardingBehavioralGroupToSubnetsRSrc,/PolicyUniverse/PolicySpace/common/GbpRoutingDomain/rd_ext/GbpForwardingBehavioralGroupToSubnetsRSrc/
---* GbpSubnets,/PolicyUniverse/PolicySpace/common/GbpSubnets/subnets_ext/
- |-* GbpSubnet,/PolicyUniverse/PolicySpace/common/GbpSubnets/subnets_ext/GbpSubnet/subnet_ext4/
- `-* GbpSubnet,/PolicyUniverse/PolicySpace/common/GbpSubnets/subnets_ext/GbpSubnet/subnet_ext6/
-----
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/opflex-agend-ovs-user-guide.html
== ODL-SDNi User Guide
=== Introduction
-This user guide will help to setup the ODL-SDNi application for lithium release and contains the examples configuration using ODL-BGPCEP.
+This user guide will help to setup the ODL-SDNi application for boron release and contains the examples configuration using ODL-BGPCEP.
=== Components
SDNiAggregator(controller), SDNi REST API(controller) and SDNiWrapper(bgpcep) are the three 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).
== TTP CLI Tools User Guide
-=== Overview
-Table Type Patterns are a specification developed by the
-https://www.opennetworking.org/[Open Networking Foundation] to enable
-the description and negotiation of subsets of the OpenFlow protocol.
-This is particularly useful for hardware switches that support OpenFlow
-as it enables the to describe what features they do (and thus also what
-features they do not) support. More details can be found in the full
-specification listed on the
-https://www.opennetworking.org/sdn-resources/onf-specifications/openflow[OpenFlow
-specifications page].
-
-=== TTP CLI Tools Architecture
-The TTP CLI Tools use the TTP Model and the YANG Tools/RESTCONF codecs
-to translate between the Data Transfer Objects (DTOs) and JSON/XML.
-
-// === Configuring <feature>
-//
-// Describe how to configure the feature or the project after installation.
-// Configuration information could include day-one activities for a project
-// such as configuring users, configuring clients/servers and so on.
-//
-// === Administering or Managing <feature>
-// Include related command reference or operations that you could perform
-// using the feature. For example viewing network statistics, monitoring
-// the network, generating reports, and so on.
-//
-// NOTE: Ensure that you create a step procedure whenever required and
-// avoid concepts.
-//
-// For example:
-//
-// .To configure L2switch components perform the following steps.
-// . Step 1:
-// . Step 2:
-// . Step 3:
-
-// === Using the CLI Tools
-//
-// TODO: provide a few examples of using the CLI tools.
-
-// <optional>
-// If there is only one tutorial, you skip the "Tutorials" section and
-// instead just lead with the single tutorial's name.
-//
-// ==== <Tutorial Name>
-// Ensure that the title starts with a gerund. For example using,
-// monitoring, creating, and so on.
-//
-// ===== Overview
-// An overview of the use case.
-//
-// ===== Prerequisites
-// Provide any prerequisite information, assumed knowledge, or environment
-// required to execute the use case.
-//
-// ===== Target Environment
-// Include any topology requirement for the use case. Ideally, provide
-// visual (abstract) layout of network diagrams and any other useful visual
-// aides.
-//
-// ===== Instructions
-// Use case could be a set of configuration procedures. Including
-// screenshots to help demonstrate what is happening is especially useful.
-// Ensure that you specify them separately. For example:
-//
-// . *Setting up the VM*
-// To set up a VM perform the following steps.
-// .. Step 1
-// .. Step 2
-// .. Step 3
-//
-// . *Installing the feature*
-// To install the feature perform the following steps.
-// .. Step 1
-// .. Step 2
-// .. Step 3
-//
-// . *Configuring the environment*
-// To configure the system perform the following steps.
-// .. Step 1
-// .. Step 2
-// .. Step 3
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/ttp-cli-tools-user-guide.html
== L3VPN Service: User Guide
-=== Overview
-L3VPN Service in OpenDaylight provides a framework to create L3VPN based on BGP-MP. It also helps to create Network Virtualization for DC Cloud environment.
-
-=== Modules & Interfaces
-L3VPN service can be realized using the following modules -
-
-==== VPN Service Modules
-. *VPN Manager* : Creates and manages VPNs and VPN Interfaces
-. *BGP Manager* : Configures BGP routing stack and provides interface to routing services
-. *FIB Manager* : Provides interface to FIB, creates and manages forwarding rules in Dataplane
-. *Nexthop Manager* : Creates and manages nexthop egress pointer, creates egress rules in Dataplane
-. *Interface Manager* : Creates and manages different type of network interfaces, e.g., VLAN, l3tunnel etc.,
-. *Id Manager* : Provides cluster-wide unique ID for a given key. Used by different modules to get unique IDs for different entities.
-. *MD-SAL Util* : Provides interface to MD-SAL. Used by service modules to access MD-SAL Datastore and services.
-
-All the above modules can function independently and can be utilized by other services as well.
-
-==== Configuration Interfaces
-The following modules expose configuration interfaces through which user can configure L3VPN Service.
-
-. BGP Manager
-. VPN Manager
-. Interface Manager
-. FIB Manager
-
-===== Configuration Interface Details
-
-.BGP Manager Interface
-. Data Node Path : _/config/bgp:bgp-router/_
-.. Fields :
-... local-as-identifier
-... local-as-number
-.. REST Methods : GET, PUT, DELETE, POST
-. Data Node Path : _/config/bgp:bgp-neighbors/_
-.. Fields :
-... List of bgp-neighbor
-.. REST Methods : GET, PUT, DELETE, POST
-. Data Node Path : _/config/bgp:bgp-neighbors/bgp-neighbor/`{as-number}`/_
-.. Fields :
-... as-number
-... ip-address
-.. REST Methods : GET, PUT, DELETE, POST
-
-.VPN Manager Interface
-. Data Node Path : _/config/l3vpn:vpn-instances/_
-.. Fields :
-... List of vpn-instance
-.. REST Methods : GET, PUT, DELETE, POST
-. Data Node Path : _/config/l3vpn:vpn-interfaces/vpn-instance_
-.. Fields :
-... name
-... route-distinguisher
-... import-route-policy
-... export-route-policy
-.. REST Methods : GET, PUT, DELETE, POST
-. Data Node Path : _/config/l3vpn:vpn-interfaces/_
-.. Fields :
-... List of vpn-interface
-.. REST Methods : GET, PUT, DELETE, POST
-. Data Node Path : _/config/l3vpn:vpn-interfaces/vpn-interface_
-.. Fields :
-... name
-... vpn-instance-name
-.. REST Methods : GET, PUT, DELETE, POST
-. Data Node Path : _/config/l3vpn:vpn-interfaces/vpn-interface/`{name}`/adjacency_
-.. Fields :
-... ip-address
-... mac-address
-.. REST Methods : GET, PUT, DELETE, POST
-
-.Interface Manager Interface
-. Data Node Path : _/config/if:interfaces/interface_
-.. Fields :
-... name
-... type
-... enabled
-... of-port-id
-... tenant-id
-... base-interface
-.. type specific fields
-... when type = _l2vlan_
-.... vlan-id
-... when type = _stacked_vlan_
-.... stacked-vlan-id
-... when type = _l3tunnel_
-.... tunnel-type
-.... local-ip
-.... remote-ip
-.... gateway-ip
-... when type = _mpls_
-.... list labelStack
-.... num-labels
-.. REST Methods : GET, PUT, DELETE, POST
-
-.FIB Manager Interface
-. Data Node Path : _/config/odl-fib:fibEntries/vrfTables_
-.. Fields :
-... List of vrfTables
-.. REST Methods : GET, PUT, DELETE, POST
-. Data Node Path : _/config/odl-fib:fibEntries/vrfTables/`{routeDistinguisher}`/_
-.. Fields :
-... route-distinguisher
-... list vrfEntries
-.... destPrefix
-.... label
-.... nexthopAddress
-.. REST Methods : GET, PUT, DELETE, POST
-. Data Node Path : _/config/odl-fib:fibEntries/ipv4Table_
-.. Fields :
-... list ipv4Entry
-.... destPrefix
-.... nexthopAddress
-.. REST Methods : GET, PUT, DELETE, POST
-
-
-=== Provisioning Sequence & Sample Configurations
-
-[[install]]
-==== Installation
-1. Edit 'etc/custom.properties' and set the following property:
-'vpnservice.bgpspeaker.host.name = <bgpserver-ip>'
-'<bgpserver-ip>' here refers to the IP address of the host where BGP is running.
-
-2. Run ODL and install VPN Service
-'feature:install odl-vpnservice-core'
-
-Use REST interface to configure L3VPN service
-
-[[prer]]
-==== Pre-requisites:
-
-1. BGP stack with VRF support needs to installed and configured
-a. _Configure BGP as specified in Step 1 below._
-
-2. Create pairs of GRE/VxLAN Tunnels (using ovsdb/ovs-vsctl) between each switch and between each switch to the Gateway node
-a. _Create 'l3tunnel' interfaces corresponding to each tunnel in interfaces DS as specified in Step 2 below._
-
-==== Step 1 : Configure BGP
-
-===== 1. Configure BGP Router
-
-*REST API* : _PUT /config/bgp:bgp-router/_
-
-*Sample JSON Data*
-[source,json]
------------------
-{
- "bgp-router": {
- "local-as-identifier": "10.10.10.10",
- "local-as-number": 108
- }
-}
------------------
-
-
-===== 2. Configure BGP Neighbors
-
-*REST API* : _PUT /config/bgp:bgp-neighbors/_
-
-*Sample JSON Data*
-
-[source,json]
------------------
- {
- "bgp-neighbor" : [
- {
- "as-number": 105,
- "ip-address": "169.144.42.168"
- }
- ]
- }
------------------
-
-==== Step 2 : Create Tunnel Interfaces
-Create l3tunnel interfaces corresponding to all GRE/VxLAN tunnels created with ovsdb (<<prer, refer Prerequisites>>). Use following REST Interface -
-
-*REST API* : _PUT /config/if:interfaces/if:interfacce_
-
-*Sample JSON Data*
-
-[source,json]
------------------
-{
- "interface": [
- {
- "name" : "GRE_192.168.57.101_192.168.57.102",
- "type" : "odl-interface:l3tunnel",
- "odl-interface:tunnel-type": "odl-interface:tunnel-type-gre",
- "odl-interface:local-ip" : "192.168.57.101",
- "odl-interface:remote-ip" : "192.168.57.102",
- "odl-interface:portId" : "openflow:1:3",
- "enabled" : "true"
- }
- ]
-}
-
------------------
-
-===== Following is expected as a result of these configurations
-
-1. Unique If-index is generated
-2. 'Interface-state' operational DS is updated
-3. Corresponding Nexthop Group Entry is created
-
-==== Step 3 : OS Create Neutron Ports and attach VMs
-
-At this step user creates VMs.
-
-==== Step 4 : Create VM Interfaces
-Create l2vlan interfaces corresponding to VM created in step 3
-
-*REST API* : _PUT /config/if:interfaces/if:interface_
-
-*Sample JSON Data*
-
-[source,json]
------------------
-{
- "interface": [
- {
- "name" : "dpn1-dp1.2",
- "type" : "l2vlan",
- "odl-interface:of-port-id" : "openflow:1:2",
- "odl-interface:vlan-id" : "1",
- "enabled" : "true"
- }
- ]
-}
-
------------------
-
-==== Step 5: Create VPN Instance
-
-*REST API* : _PUT /config/l3vpn:vpn-instances/l3vpn:vpn-instance/_
-
-*Sample JSON Data*
-
-[source,json]
------------------
-{
- "vpn-instance": [
- {
- "description": "Test VPN Instance 1",
- "vpn-instance-name": "testVpn1",
- "ipv4-family": {
- "route-distinguisher": "4000:1",
- "export-route-policy": "4000:1,5000:1",
- "import-route-policy": "4000:1,5000:1",
- }
- }
- ]
-}
-
------------------
-
-===== Following is expected as a result of these configurations
-
-1. VPN ID is allocated and updated in data-store
-2. Corresponding VRF is created in BGP
-3. If there are vpn-interface configurations for this VPN, corresponding action is taken as defined in step 5
-
-==== Step 5 : Create VPN-Interface and Local Adjacency
-
-_this can be done in two steps as well_
-
-===== 1. Create vpn-interface
-
-*REST API* : _PUT /config/l3vpn:vpn-interfaces/l3vpn:vpn-interface/_
-
-*Sample JSON Data*
-
-[source,json]
------------------
-{
- "vpn-interface": [
- {
- "vpn-instance-name": "testVpn1",
- "name": "dpn1-dp1.2",
- }
- ]
-}
------------------
-
-[NOTE]
-name here is the name of VM interface created in step 3, 4
-
-===== 2. Add Adjacencies on vpn-interafce
-
-*REST API* : _PUT /config/l3vpn:vpn-interfaces/l3vpn:vpn-interface/dpn1-dp1.3/adjacency_
-
-*Sample JSON Data*
-
-[source,json]
------------------
- {
- "adjacency" : [
- {
- "ip-address" : "169.144.42.168",
- "mac-address" : "11:22:33:44:55:66"
- }
- ]
- }
------------------
-
-
-[quote]
-its a list, user can define more than one adjacency on a vpn_interface
-
-Above steps can be carried out in a single step as following
-
-[source,json]
------------------
-{
- "vpn-interface": [
- {
- "vpn-instance-name": "testVpn1",
- "name": "dpn1-dp1.3",
- "odl-l3vpn:adjacency": [
- {
- "odl-l3vpn:mac_address": "11:22:33:44:55:66",
- "odl-l3vpn:ip_address": "11.11.11.2",
- }
- ]
- }
- ]
-}
-
------------------
-
-
-===== Following is expected as a result of these configurations
-
-1. Prefix label is generated and stored in DS
-2. Ingress table is programmed with flow corresponding to interface
-3. Local Egress Group is created
-4. Prefix is added to BGP for advertisement
-5. BGP pushes route update to FIB YANG Interface
-6. FIB Entry flow is added to FIB Table in OF pipeline
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/l3vpn-service_-user-guide.html
== YANG IDE User Guide
-=== Overview
-
-The YANG IDE project provides an Eclipse plugin that is used to create,
-view, and edit Yang model files. It currently supports version 1.0 of
-the Yang specification.
-
-The YANG IDE project uses components from the OpenDaylight project for
-parsing and verifying Yang model files. The "yangtools" parser in
-OpenDaylight is generally used for generating Java code associated
-with Yang models. If you are just using the YANG IDE to view and edit
-Yang models, you do not need to know any more about this.
-
-Although the YANG IDE plugin is used in Eclipse, it is not necessary to
-be familiar with the Java programming language to use it effectively.
-
-The YANG IDE also uses the Maven build tool, but you do not have to be
-a Maven expert to use it, or even know that much about it. Very
-little configuration of Maven files will have to be done by you. In
-fact, about the only thing you will likely ever need to change can be
-done entirely in the Eclipse GUI forms, without even seeing the
-internal structure of the Maven POM file (Project Object Model).
-
-The YANG IDE plugin provides features that are similar to other
-programming language plugins in the Eclipse ecosystem.
-
-For instance, you will find support for the following:
-
-* Immediate "as-you-type" display of syntactic and semantic errors
-* Intelligent completion of language tokens, limited to only choices
-valid in the current scope and namespace
-* Consistent (and customizable) color-coding of syntactic and semantic symbols
-* Provides access to remote Yang models by specifying dependency on
-Maven artifact containing models (or by manual inclusion in project)
-* One-click navigation to referenced symbols in external files
-* Mouse hovers display descriptions of referenced components
-* Tools for refactoring or renaming components respect namespaces
-* Code templates can be entered for common conventions
-
-Forthcoming sections of this manual will step through how to utilize
-these features.
-
-=== Creating a Yang Project
-
-After the plugin is installed, the next thing you have to do is create
-a Yang Project. This is done from the "File" menu, selecting "New",
-and navigating to the "Yang" section and selecting "YANG Project", and
-then clicking "Next" for more items to configure.
-
-Some shortcuts for these steps are the following:
-
-* Typically, the key sequence "Ctrl+n" (press "n" while holding down
-one of the "ctrl" keys) is bound to the "new" function
-* In the "New" wizard dialog, the initial focus is in the filter
-field, where you can enter "yang" to limit the choices to only the
-functions provided by the YANG IDE plugin
-* On the "New" wizard dialog, instead of clicking the "Next" button
-with your mouse, you can press "Alt+n" (you will see a hint for this
-with the "N" being underlined)
-
-==== First Yang Project Wizard Page
-
-After the "Next" button is pressed, it goes to the first wizard page
-that is specific to creating Yang projects. you will see a subtitle on
-this page of "YANG Tools Configuration". In almost all cases, you
-should be able to click "Next" again on this page to go to the next
-wizard page.
-
-However, some information about the fields on this page would be helpful.
-
-You will see the following labeled fields and sections:
-
-===== Yang Files Root Directory
-
-This defaults to "src/main/yang". Except when creating your first
-Yang file, you, you do not even have to know this, as Eclipse presents
-the same interface to view your Yang files no matter what you set
-this to.
-
-===== Source Code Generators
-
-If you do not know what this is, you do not need to know about it. The
-"yangtools" Yang parser from OpenDaylight uses a "code generator"
-component to generate specific kinds of Java classes from the Yang
-models. Again, if you do not need to work with the generated Java
-code, you do not need to change this.
-
-===== Create Example YANG File
-
-This is likely the only field you will ever have any reason to change.
-If this checkbox is set, when the YANG IDE creates the Yang project,
-it will create a sample "acme-system.yang" file which you can view and
-edit to demonstrate the features of the tool to yourself. If you
-do not need this file, then either delete it from the project or
-uncheck the checkbox to prevent its creation.
-
-When done with the fields on this page, click the "Next" button to go
-to the next wizard page.
-
-==== Second Yang Project Wizard Page
-
-This page has a subtitle of "New Maven project". There are several
-fields on this page, but you will only ever have to see and change the
-setting of the first field, the "Create a simple project" checkbox.
-You should always set this ON to avoid the selection of a Maven
-archetype, which is something you do not need to do for creating a
-Yang project.
-
-Click "Next" at the bottom of the page to move to the next wizard page.
-
-==== Third Yang Project Wizard Page
-
-This also has a subtitle of "New Maven project", but with different
-fields to set. You will likely only ever set the first two fields,
-and completely ignore everything else.
-
-The first field is labeled "Group id" in the "Artifact" section. It
-really does not matter what you set this to, but it does have to be set
-to something. For consistency, you might set this to the name or
-nickname of your organization. Otherwise, there are no constraints on
-the value of this field.
-
-The second field is labeled "Artifact id". The value of this field
-will be used as the name of the project you create, so you will have
-to think about what you want the project to be called. Also note that
-this name has to be unique in the Eclipse workspace. You cannot have
-two projects with the same name.
-
-After you have set this field, you will notice that the "Next" button is
-insensitive, but now the "Finish" button is sensitive. You can click
-"Finish" now (or use the keyboard shortcut of "Alt+f"), and the Yang
-IDE will finally create your project.
-
-=== Creating a Yang File
-
-Now that you have created your project, it is time to create your first Yang file.
-
-When you created the Yang project, you might have noticed the other
-option next to "YANG Project", which was "YANG File". That is what
-you will select now. Click "Next" to go to the first wizard page.
-
-==== First Yang File Wizard Page
-
-This wizard page lets you specify where the new file will be located, and its name.
-
-You have to select the particular project you want the file to go
-into, and it needs to go into the "src/main/yang" folder (or a
-different location if you changed that field when creating the
-project).
-
-You then enter the desired name of the file in the "File name". The
-file name should have no spaces or "special characters" in it. You
-can specify a ".yang" extent if you want. If you do not specify an
-extent, the YANG IDE will create it with the ".yang" extent.
-
-Click "Next" to go to the next wizard page.
-
-==== Second Yang File Wizard Page
-
-On this wizard page, you set some metadata about the module that is
-used to initialize the contents of the Yang file.
-
-It has the following fields:
-
-===== Module Name
-
-This will default to the "base name" of the file name you created.
-For instance, if the file name you created was "network-setup.yang",
-this field will default to "network-setup". You should leave this
-value as is. There is no good reason to define a model with a name
-different from the file name.
-
-===== Namespace
-
-This defaults to "urn:opendaylight:xxx", where "xxx" is the "base
-name" of the file name you created. You should put a lot of thought
-into designing a namespace naming scheme that is used throughout your
-organization. It is quite common for this namespace value to look like
-a "http" URL, but note that that is just a convention, and will not
-necessarily imply that there is a web page residing at that HTTP
-address.
-
-===== Prefix
-
-This defaults to the "base name" of the file name you created. It
-mostly does not technically matter what you set this to, as long as
-it is not empty. Conventionally, it should be a "nickname" that is
-used to refer to the given namespace in an abbreviated form, when
-referenced in an "import" statement in another Yang model file.
-
-===== Revision
-
-This has to be a date value in the form of "yyyy-mm-dd", representing
-the last modified date of this Yang model. The value will default to
-the current date.
-
-===== Revision Description
-
-This is just human-readable text, which will go into the "description"
-field underneath the Yang "revision" field, which will describe what
-went into this revision.
-
-When all the fields have the content you want, click the "Finish"
-button to set the YANG IDE create the file in the specified location.
-It will then present the new file in the editor view for additional
-modifications.
-
-=== Accessing Artifacts for Yang Model Imports
-
-You might be working on Yang models that are "abstract" or are
-intended to be imported by other Yang models. You might also, and
-more likely, be working on Yang models that import other "abstract"
-Yang models.
-
-Assuming you are in that latter more common group, you need to consider
-for yourself, and for your organization, how you are going to get
-access to those models that you import.
-
-You could use a very simple and primitive approach of somehow
-obtaining those models from some source as plain files and just
-copying them into the "src/main/yang" folder of your project. For a
-simple demo or a "one-off" very short project, that might be
-sufficient.
-
-A more robust and maintainable approach would be to reference
-"coordinates" of the artifacts containing Yang models to import. When
-you specify unique coordinates associated with that artifact, the Yang
-IDE can retrieve the artifact in the background and make it available
-for your "import" statements.
-
-Those "coordinates" that I speak of refer to the Maven concepts of
-"group id", "artifact id", and "version". you may remember "group id"
-and "artifact id" from the wizard page for creating a Yang project.
-It is the same idea. If you ever produce Yang model artifacts that
-other people are going to import, you will want to think more about what
-you set those values to when you created the project.
-
-For example, the OpenDaylight project produces several importable
-artifacts that you can specify to get access to common Yang models.
-
-==== Turning on Indexing for Maven Repositories
-
-Before we talk about how to add dependencies to Maven artifacts with
-Yang models for import, I need to explain how to make it easier to
-find those artifacts.
-
-In the Yang project that you have created, the "pom.xml" file (also
-called a "POM file") is the file that Maven uses to specify
-dependencies. We will talk about that in a minute, but first we need to
-talk about "repositories". These are where artifacts are stored.
-
-We are going to have Eclipse show us the "Maven Repositories" view.
-In the main menu, select "Window" and then "Show View", and then
-"Other". Like in the "New" dialog, you can enter "maven" in the
-filter field to limit the list to views with "maven" in the name.
-Click on the "Maven Repositories" entry and click OK.
-
-This will usually create the view in the bottom panel of the window.
-
-The view presents an outline view of four principal elements:
-
-* Local Repositories
-* Global Repositories
-* Project Repositories
-* Custom Repositories
-
-For this purpose, the only section you care about is "Project
-Repositories", being the repositories that are only specified in the
-POM for the project. There should be a "right-pointing arrow" icon on
-the line. Click that to expand the entry.
-
-You should see two entries there:
-
-* opendaylight-release
-* opendaylight-snapshot
-
-You will also see internet URLs associated with each of those repositories.
-
-For this purpose, you only care about the first one. Right-click on
-that entry and select "Full Index Enabled". The first time you do
-this on the first project you create, it will spend several minutes
-walking the entire tree of artifacts available at that repository and
-"indexing" all of those components. When this is done, searching for
-available artifacts in that repository will go very quickly.
-
-=== Adding Dependencies Containing Yang Models
-
-Double-click the "pom.xml" file in your project. Instead of just
-bringing up the view of an XML file (although you can see that if you
-like), it presents a GUI form editor with a handful of tabs.
-
-The first tab, "Overview", shows things like the "Group Id", "Artifact
-Id", and "Version", which represents the "Maven coordinate" of your
-project, which I have mentioned before.
-
-Now click on the "Dependencies" tab. You will now see two list
-components, labeled "Dependencies" and "Dependency Management". You
-only care about the "Dependencies" section.
-
-In the "Dependencies" section, you should see one dependency for an
-artifact called "yang-binding". This artifact is part of
-OpenDaylight, but you do not need to know anything about it.
-
-Now click the "Add" button.
-
-This brings up a dialog titled "Select Dependency". It has three
-fields at the top labeled "Group Id", "Artifact Id", and "Version",
-with a "Scope" dropdown. You will never have a need to change the
-"Scope" dropdown, so ignore it. Despite the fact that you will need to
-get values into these fields, in general usage, you will never have to
-manually enter values into them, but you will see values being inserted
-into these fields by the next steps I describe.
-
-Below those fields is a field labeled "Enter groupId, artifactId ...".
-This is effectively a "filter field", like on the "New" dialog, but
-instead of limiting the list from a short list of choices, the value
-you enter there will be matched against all of the artifacts that were
-indexed in the "opendaylight-release" repository (and others). It
-will match the string you enter as a substring of any groupId or
-artifactId.
-
-For all of the entries that match that substring, it will list an
-entry showing the groupId and artifactId, with an expansion arrow. If
-you open it by clicking on the arrow, you will see individual entries
-corresponding to each available version of that artifact, along with
-some metadata about the artifacts between square brackets, mostly
-indicating what "type" of artifact is.
-
-For your purposes, you only ever want to use "bundle" or "jar" artifacts.
-
-Let us consider an example that many people will probably be using.
-
-In the filter field, enter "ietf-yang-types". Depending on what
-versions are available, you should see a small handful of "groupId,
-artifactId" entries there. One of them should be groupId
-"org.opendaylight.mdsal.model" and artifactId "ietf-yang-types".
-Click on the expansion arrow to open that.
-
-What you will see at this point depends on what versions are
-available. You will likely want to select the newest one (most likely
-top of the list) that is also either a "bundle" or "jar" type
-artifact.
-
-If you click on that resulting version entry, you should notice at
-this point that the "Group Id", "Artifact Id", and "Version" fields at
-the top of the dialog are now filled in with the values corresponding
-to this artifact and version.
-
-If this is the version that you want, click OK and this artifact will
-be added to the dependencies in the POM.
-
-This will now make the Yang models found in that artifact available in
-"import" statements in Yang models, not to mention the completion
-choices for that "import" statement.
+This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/yang-ide-user-guide.html
Code Review / docs.git / commitdiff
