--- /dev/null
+[submodule "source/submodules/releng/builder"]
+ path = docs/submodules/releng/builder
+ url = ../releng/builder
+ branch = master
--- /dev/null
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS =
+SPHINXBUILD = sphinx-build
+PAPER =
+BUILDDIR = _build
+
+# User-friendly check for sphinx-build
+ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
+ $(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don\'t have Sphinx installed, grab it from http://sphinx-doc.org/)
+endif
+
+# Internal variables.
+PAPEROPT_a4 = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+# the i18n builder cannot share the environment and doctrees with the others
+I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+.PHONY: help
+help:
+ @echo "Please use \`make <target>' where <target> is one of"
+ @echo " html to make standalone HTML files"
+ @echo " dirhtml to make HTML files named index.html in directories"
+ @echo " singlehtml to make a single large HTML file"
+ @echo " pickle to make pickle files"
+ @echo " json to make JSON files"
+ @echo " htmlhelp to make HTML files and a HTML help project"
+ @echo " qthelp to make HTML files and a qthelp project"
+ @echo " applehelp to make an Apple Help Book"
+ @echo " devhelp to make HTML files and a Devhelp project"
+ @echo " epub to make an epub"
+ @echo " epub3 to make an epub3"
+ @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+ @echo " latexpdf to make LaTeX files and run them through pdflatex"
+ @echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
+ @echo " text to make text files"
+ @echo " man to make manual pages"
+ @echo " texinfo to make Texinfo files"
+ @echo " info to make Texinfo files and run them through makeinfo"
+ @echo " gettext to make PO message catalogs"
+ @echo " changes to make an overview of all changed/added/deprecated items"
+ @echo " xml to make Docutils-native XML files"
+ @echo " pseudoxml to make pseudoxml-XML files for display purposes"
+ @echo " linkcheck to check all external links for integrity"
+ @echo " doctest to run all doctests embedded in the documentation (if enabled)"
+ @echo " coverage to run coverage check of the documentation (if enabled)"
+
+.PHONY: clean
+clean:
+ rm -rf $(BUILDDIR)/*
+
+.PHONY: html
+html:
+ $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
+ @echo
+ @echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
+
+.PHONY: dirhtml
+dirhtml:
+ $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
+ @echo
+ @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
+
+.PHONY: singlehtml
+singlehtml:
+ $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
+ @echo
+ @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
+
+.PHONY: pickle
+pickle:
+ $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
+ @echo
+ @echo "Build finished; now you can process the pickle files."
+
+.PHONY: json
+json:
+ $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
+ @echo
+ @echo "Build finished; now you can process the JSON files."
+
+.PHONY: htmlhelp
+htmlhelp:
+ $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
+ @echo
+ @echo "Build finished; now you can run HTML Help Workshop with the" \
+ ".hhp project file in $(BUILDDIR)/htmlhelp."
+
+.PHONY: qthelp
+qthelp:
+ $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
+ @echo
+ @echo "Build finished; now you can run "qcollectiongenerator" with the" \
+ ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
+ @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/OpenDaylightDocumentation.qhcp"
+ @echo "To view the help file:"
+ @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/OpenDaylightDocumentation.qhc"
+
+.PHONY: applehelp
+applehelp:
+ $(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp
+ @echo
+ @echo "Build finished. The help book is in $(BUILDDIR)/applehelp."
+ @echo "N.B. You won't be able to view it unless you put it in" \
+ "~/Library/Documentation/Help or install it in your application" \
+ "bundle."
+
+.PHONY: devhelp
+devhelp:
+ $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
+ @echo
+ @echo "Build finished."
+ @echo "To view the help file:"
+ @echo "# mkdir -p $$HOME/.local/share/devhelp/OpenDaylightDocumentation"
+ @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/OpenDaylightDocumentation"
+ @echo "# devhelp"
+
+.PHONY: epub
+epub:
+ $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
+ @echo
+ @echo "Build finished. The epub file is in $(BUILDDIR)/epub."
+
+.PHONY: epub3
+epub3:
+ $(SPHINXBUILD) -b epub3 $(ALLSPHINXOPTS) $(BUILDDIR)/epub3
+ @echo
+ @echo "Build finished. The epub3 file is in $(BUILDDIR)/epub3."
+
+.PHONY: latex
+latex:
+ $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+ @echo
+ @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
+ @echo "Run \`make' in that directory to run these through (pdf)latex" \
+ "(use \`make latexpdf' here to do that automatically)."
+
+.PHONY: latexpdf
+latexpdf:
+ $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+ @echo "Running LaTeX files through pdflatex..."
+ $(MAKE) -C $(BUILDDIR)/latex all-pdf
+ @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+.PHONY: latexpdfja
+latexpdfja:
+ $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+ @echo "Running LaTeX files through platex and dvipdfmx..."
+ $(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
+ @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+.PHONY: text
+text:
+ $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
+ @echo
+ @echo "Build finished. The text files are in $(BUILDDIR)/text."
+
+.PHONY: man
+man:
+ $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
+ @echo
+ @echo "Build finished. The manual pages are in $(BUILDDIR)/man."
+
+.PHONY: texinfo
+texinfo:
+ $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+ @echo
+ @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
+ @echo "Run \`make' in that directory to run these through makeinfo" \
+ "(use \`make info' here to do that automatically)."
+
+.PHONY: info
+info:
+ $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+ @echo "Running Texinfo files through makeinfo..."
+ make -C $(BUILDDIR)/texinfo info
+ @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
+
+.PHONY: gettext
+gettext:
+ $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
+ @echo
+ @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
+
+.PHONY: changes
+changes:
+ $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
+ @echo
+ @echo "The overview file is in $(BUILDDIR)/changes."
+
+.PHONY: linkcheck
+linkcheck:
+ $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
+ @echo
+ @echo "Link check complete; look for any errors in the above output " \
+ "or in $(BUILDDIR)/linkcheck/output.txt."
+
+.PHONY: doctest
+doctest:
+ $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
+ @echo "Testing of doctests in the sources finished, look at the " \
+ "results in $(BUILDDIR)/doctest/output.txt."
+
+.PHONY: coverage
+coverage:
+ $(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
+ @echo "Testing of coverage in the sources finished, look at the " \
+ "results in $(BUILDDIR)/coverage/python.txt."
+
+.PHONY: xml
+xml:
+ $(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
+ @echo
+ @echo "Build finished. The XML files are in $(BUILDDIR)/xml."
+
+.PHONY: pseudoxml
+pseudoxml:
+ $(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
+ @echo
+ @echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
+
--- /dev/null
+#!/usr/bin/env python3
+# -*- coding: utf-8 -*-
+#
+# OpenDaylight Documentation documentation build configuration file, created by
+# sphinx-quickstart on Mon Mar 28 14:20:08 2016.
+#
+# This file is execfile()d with the current directory set to its
+# containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys
+import os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#sys.path.insert(0, os.path.abspath('.'))
+
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = []
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+# source_suffix = ['.rst', '.md']
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = 'OpenDaylight Documentation'
+copyright = '2016, OpenDaylight Project'
+author = 'OpenDaylight Project'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = '0.3.0'
+# The full version, including alpha/beta/rc tags.
+release = '0.3.0'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+# This patterns also effect to html_static_path and html_extra_path
+exclude_patterns = []
+
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+# If true, keep warnings as "system message" paragraphs in the built documents.
+#keep_warnings = False
+
+# If true, `todo` and `todoList` produce output, else they produce nothing.
+todo_include_todos = False
+
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages. See the documentation for
+# a list of builtin themes.
+html_theme = 'alabaster'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further. For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = []
+
+# The name for this set of Sphinx documents.
+# "<project> v<release> documentation" by default.
+#html_title = 'OpenDaylight Documentation v0.3.0'
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (relative to this directory) to use as a favicon of
+# the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# Add any extra paths that contain custom files (such as robots.txt or
+# .htaccess) here, relative to this directory. These files are copied
+# directly to the root of the documentation.
+#html_extra_path = []
+
+# If not None, a 'Last updated on:' timestamp is inserted at every page
+# bottom, using the given strftime format.
+# The empty string is equivalent to '%b %d, %Y'.
+#html_last_updated_fmt = None
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_domain_indices = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+#html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+#html_show_copyright = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it. The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = None
+
+# Language to be used for generating the HTML full-text search index.
+# Sphinx supports the following languages:
+# 'da', 'de', 'en', 'es', 'fi', 'fr', 'h', 'it', 'ja'
+# 'nl', 'no', 'pt', 'ro', 'r', 'sv', 'tr', 'zh'
+#html_search_language = 'en'
+
+# A dictionary with options for the search language support, empty by default.
+# 'ja' uses this config value.
+# 'zh' user can custom change `jieba` dictionary path.
+#html_search_options = {'type': 'default'}
+
+# The name of a javascript file (relative to the configuration directory) that
+# implements a search results scorer. If empty, the default will be used.
+#html_search_scorer = 'scorer.js'
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'OpenDaylightDocumentationdoc'
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+# The paper size ('letterpaper' or 'a4paper').
+#'papersize': 'letterpaper',
+
+# The font size ('10pt', '11pt' or '12pt').
+#'pointsize': '10pt',
+
+# Additional stuff for the LaTeX preamble.
+#'preamble': '',
+
+# Latex figure (float) alignment
+#'figure_align': 'htbp',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+# author, documentclass [howto, manual, or own class]).
+latex_documents = [
+ (master_doc, 'OpenDaylightDocumentation.tex', 'OpenDaylight Documentation Documentation',
+ 'OpenDaylight Project', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# If true, show page references after internal links.
+#latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+#latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_domain_indices = True
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+ (master_doc, 'opendaylightdocumentation', 'OpenDaylight Documentation Documentation',
+ [author], 1)
+]
+
+# If true, show URL addresses after external links.
+#man_show_urls = False
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+# dir menu entry, description, category)
+texinfo_documents = [
+ (master_doc, 'OpenDaylightDocumentation', 'OpenDaylight Documentation Documentation',
+ author, 'OpenDaylightDocumentation', 'One line description of project.',
+ 'Miscellaneous'),
+]
+
+# Documents to append as an appendix to all manuals.
+#texinfo_appendices = []
+
+# If false, no module index is generated.
+#texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#texinfo_show_urls = 'footnote'
+
+# If true, do not generate a @detailmenu in the "Top" node's menu.
+#texinfo_no_detailmenu = False
+
+
+linkcheck_ignore = [
+ # Ignore jenkins because it's often slow to respond.
+ 'https://jenkins.opendaylight.org/releng',
+ 'https://jenkins.opendaylight.org/sandbox',
+ 'http://\$CONTROL_HOST:8181/dlux/index.html',
+ # The '#' in the path makes sphinx think it's an anchor
+ 'https://git.opendaylight.org/gerrit/#/admin/projects/releng/builder',
+]
--- /dev/null
+API
+===
+
+We are in the process of creating automatically generated API documentation for
+all of OpenDaylight. The following are links to the preliminary documentation
+that you can reference. We will continue to add more API documentation as it
+becomes available.
+
+* mdsal_
+* odlparent_
+* yangtools_
+
+.. _mdsal: https://nexus.opendaylight.org/content/sites/site/org.opendaylight.mdsal/beryllium/apidocs/
+.. _odlparent: https://nexus.opendaylight.org/content/sites/site/org.opendaylight.odlparent/beryllium/apidocs/index.html
+.. _yangtools: https://nexus.opendaylight.org/content/sites/site/org.opendaylight.yangtools/beryllium/apidocs/index.html
--- /dev/null
+OpenDaylight concepts and tools
+===============================
+
+In this section we discuss some of the concepts and tools you encounter with
+basic use of OpenDaylight. The guide walks you through the installation process
+in a subsequent section, but for now familiarize yourself with the information
+below.
+
+* To date, OpenDaylight developers have formed more than 50 projects to address
+ ways to extend network functionality. The projects are a formal structure for
+ developers from the community to meet, document release plans, code, and
+ release the functionality they create in an OpenDaylight release.
+
+ *The typical OpenDaylight user will not join a project team*, but you should
+ know what projects are as we refer to their activities and the functionality
+ they create. The Karaf features to install that functionality often share the
+ project team’s name.
+
+* **Apache Karaf** provides a lightweight runtime to install the Karaf features
+ you want to implement and is included in the OpenDaylight platform software.
+ By default, OpenDaylight has no pre-installed features.
+* After installing OpenDaylight, you install your selected features using the
+ Karaf console to expand networking capabilities. In the Karaf feature list
+ below are the ones you’re most likely to use when creating your network
+ environment.
+
+ As a short example of installing a Karaf feature, OpenDaylight Beryllium
+ offers Application Layer Traffic Optimization (ALTO). The Karaf feature to
+ install ALTO is odl-alto-all. On the Karaf console, the command to install it
+ is:
+
+ feature:install odl-alto-all
+
+* **DLUX** is a web-based interface that OpenDaylight provides for you to manage
+ your network. Its Karaf feature installation name is “odl-dlux-core”.
+
+ a. DLUX draws information from OpenDaylight’s topology and host databases to
+ display the following information:
+
+ i. The network
+ #. Flow statistics
+ #. Host locations
+
+ #. To enable the DLUX UI after installing OpenDaylight, run:
+
+ feature:install odl-dlux-core
+
+ on the Karaf console.
+
+* **Network embedded Experience (NeXt)** is a developer toolkit that provides
+ tools to draw network-centric topology UI elements that offer visualizations
+ of the following:
+
+ a. Large complex network topologies
+ #. Aggregated network nodes
+ #. Traffic/path/tunnel/group visualizations
+ #. Different layout algorithms
+ #. Map overlays
+ #. Preset user-friendly interactions
+
+ NeXt can work with DLUX to build OpenDaylight applications. Check out the
+ NeXt_demo_ for more information on the interface.
+
+* Model-Driven Service Abstraction Layer (MD-SAL) is the OpenDaylight framework
+ that allows developers to create new Karaf features in the form of services
+ and protocol drivers and connects them to one another. You can think of the
+ MD-SAL as having the following two components:
+
+ a. A shared datastore that maintains the following tree-based structures:
+
+ i. The Config Datastore, which maintains a representation of the desired
+ network state.
+ #. The Operational Datastore, which is a representation of the actual
+ network state based on data from the managed network elements.
+
+ b. A message bus that provides a way for the various services and protocol
+ drivers to notify and communicate with one another.
+
+* If you’re interacting with OpenDaylight through DLUX or the REST APIs while
+ using the the OpenDaylight interfaces, the microservices architecture allows
+ you to select available services, protocols, and REST APIs.
+
+.. _NeXt_demo: https://www.youtube.com/watch?v=gBsUDu8aucs
--- /dev/null
+OpenDaylight Experimental Features
+==================================
+
+.. contents::
+ :depth: 1
+ :local:
+
+Messaging4Transport
+-------------------
+Adds AMQP bindings to the MD-SAL, which makes all MD-SAL APIs available via
+that mechanism. AMQP bindings integration exposes the MD-SAL datatree, rpcs,
+and notifications via AMQP, when installed.
+
+Network Intent Composition (NIC)
+--------------------------------
+Offers an interface with an abstraction layer for you to communicate
+“intentions,” i.e., what you expect from the network. The Intent model, which
+is part of NIC's core architecture, describes your networking services
+requirements and transforms the details of the desired state to OpenDaylight.
+NIC has four features:
+
+* odl-nic-core-hazelcast: Provides the following:
+
+ * A distributed intent mapping service implemented using hazelcast, which
+ stores metadata needed to process Intent correctly
+ * An intent REST API to external applications for Create, Read, Update, and
+ Delete (CRUD) operations on intents, conflict resolution, and event handling
+
+* odl-nic-core-mdsal: Provides the following:
+
+ * A distributed Intent mapping service implemented using MD-SAL, which stores
+ metadata needed to process Intent correctly
+ * An Intent rest API to external applications for CRUD operations on Intents,
+ conflict resolution, and event handling
+
+* odl-nic-console: Provides a Karaf CLI extension for Intent CRUD operations
+ and mapping service operations
+* Four renderers to provide specific implementations to render the Intent:
+
+ * Virtual Tenant Network Renderer
+ * Group Based Policy Renderer
+ * OpenFlow Renderer
+ * Network MOdeling Renderer
+
+UNI Manager Plug-in (Unimgr)
+----------------------------
+Formed to initiate the development of data models and APIs that facilitate
+OpenDaylight software applications’ and/or service orchestrators’ ability to
+configure and provision connectivity services.
+
+YANG-PUBSUB
+-----------
+An experimental feature Plugin that allows subscriptions to be placed on
+targeted subtrees of YANG datastores residing on remote devices. Changes in
+YANG objects within the remote subtree can be pushed to OpenDaylight as
+specified and don’t require OpenDaylight to make continuous fetch requests.
+YANG-PUBSUB is developed as a Java project. Development requires Maven version
+3.1.1 or later.
--- /dev/null
+Getting Started Guide
+=====================
+
+.. toctree::
+ :maxdepth: 1
+
+ introduction
+ overview
+ who_should_use
+ concepts_and_tools
+ karaf_features
+ experimental_features
+ other_features
+ api
+ installing_opendaylight
--- /dev/null
+Installing OpenDaylight
+=======================
+
+You complete the following steps to install your networking environment, with
+specific instructions provided in the subsections below.
+
+Before detailing the instructions for these, we address the following:
+Java Runtime Environment (JRE) and operating system information
+Target environment
+Known issues and limitations
+
+
+Install OpenDaylight
+--------------------
+
+Install the Karaf features
+--------------------------
+To install a feature, use the following command, where feature1 is the feature
+name listed in the table below::
+
+ feature:install <feature1>
+
+You can install multiple features using the following command::
+
+
+ feature:install <feature1> <feature2> ... <featureN-name>
+
+.. note:: For compatibility reasons, you cannot enable all Karaf features
+ simultaneously. The table below documents feature installation names and
+ known incompatibilities.Compatibility values indicate the following:
+
+* *all* - the feature can be run with other features.
+* *self+all* - the feature can be installed with other features with a value of
+ *all*, but may interact badly with other features that have a value of
+ *self+all*. Not every combination has been tested.
+
+Uninstalling features
+^^^^^^^^^^^^^^^^^^^^^
+To uninstall a feature, you must shut down OpenDaylight, delete the data
+directory, and start OpenDaylight up again.
+
+.. important:: Uninstalling a feature using the Karaf feature:uninstall command
+ is not supported and can cause unexpected and undesirable behavior.
+
+Listing available features
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+To find the complete list of Karaf features, run the following command::
+
+ feature:list
+
+To list the installed Karaf features, run the following command::
+
+ feature:list -i
+
+Features to implement networking functionality provide release notes you can
+access on the OpenDaylight Wiki: https://wiki.opendaylight.org/view/Project_list
+
+* Authentication, Authorization and Accounting (AAA_)
+* ALTO_
+* BGPCEP_
+* Controller_
+* Control And Provisioning of Wireless Access Points (CAPWAP_)
+* Identification and Driver Management (DIDM_)
+* DLUX_
+* FaaS_
+* Group_Based_Policy_ (GPB)
+* Internet of Things Data Management (IoTDM_)
+* L2_Switch_
+* Link Aggregation Control Protocol (LACP_)
+* LISP_Flow_Mapping_
+* MDSAL_
+* NEMO_
+* NETCONF_
+* NetIDE_
+* NeXt_
+* Network Intent Composition (NIC_)
+* Neutron_Northbound_
+* OF-Config_
+* OpFlex_
+* OpenFlow_Plugin_
+* OpenFlow_Protocol_Library_
+* OVSDB_Netvirt_
+* Packet_Cable_ / PCMM
+* SDN_Interface_Application_
+* Secure Network Bootstrapping Infrastructure (SNBI_)
+* SNMP4SDN_
+* SNMP_Plugin_
+* Secure tag eXchange Protocol (SXP_)
+* Service Function Chaining (SFC_)
+* TCPMD5_
+* Time Series Data Repository (TSDR_)
+* Table Type Patterns (TTP_)
+* Topology_Processing_Framework_
+* Unified Secure Channel (USC_)
+* VPN_Service_
+* Virtual Tenant Network (VTN_)
+* YANG_Tools_
+
+Projects without Release Notes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The following projects participated in Beryllium, but intentionally do not have
+release notes:
+
+* The Documentation Project produced this and the other downloadable
+ documentation.
+* The Integration Group hosted the OpenDaylight-wide tests and main release
+ distribution.
+* Controller Core Functionality Tutorials provided a single test suite
+ (dsbenchmark) that was used as part of integration testing
+* Release Engineering used autorelease to build the Beryllium release artifacts,
+ including the main release download.
+
+Beryllium features
+------------------
+
+.. list-table:: Beryllium features
+ :widths: 10 25 10 5
+ :header-rows: 1
+
+ * - Feature Name
+ - Feature Description
+ - Karaf feature name
+ - Compatibility
+
+ * - Authentication
+ - Enables authentication with support for federation using Apache Shiro
+ - odl-aaa-shiro
+ - all
+
+ * - BGP
+ - Provides support for Border Gateway Protocol (including Link-State
+ Distribution) as a source of L3 topology information
+ - odl-bgpcep-bgp
+ - all
+
+ * - BMP
+ - Provides support for BGP Monitoring Protocol as a monitoring station
+ - odl-bgpcep-bmp
+ - all
+
+ * - DIDM
+ - Device Identification and Driver Management
+ - odl-didm-all
+ - all
+
+ * - Centinel
+ - Provides interfaces for streaming analytics
+ - odl-centinel-all
+ - all
+
+ * - DLUX
+ - Provides an intuitive graphical user interface for OpenDaylight
+ - odl-dlux-all
+ - all
+ * - Fabric as a Service (Faas)
+ - Creates a common abstraction layer on top of a physical network so
+ northbound APIs or services can be more easiliy mapped onto the
+ physical network as a concrete device configuration
+ - odl-faas-all
+ - all
+
+ * - Group Based Policy
+ - Enables Endpoint Registry and Policy Repository REST APIs and associated
+ functionality for Group Based Policy with the default renderer for
+ OpenFlow renderers
+ - odl-groupbasedpolicy-ofoverlay
+ - all
+
+ * - GBP User Interface
+ - Enables a web-based user interface for Group Based Policy
+ - odl-groupbasedpolicyi-ui
+ - all
+
+ * - GBP FaaS renderer
+ - Enables the Fabric as a Service renderer for Group Based Policy
+ - odl-groupbasedpolicy-faas
+ - self+all
+
+ * - GBP Neutron Support
+ - Provides OpenStack Neutron support using Group Based Policy
+ - odl-groupbasedpolicy-neutronmapper
+ - all
+
+ * - L2 Switch
+ - Provides L2 (Ethernet) forwarding across connected OpenFlow switches and
+ support for host tracking
+ - odl-l2switch-switch-ui
+ - self+all
+
+ * - LACP
+ - Enables support for the Link Aggregation Control Protocol
+ - odl-lacp-ui
+ - self+all
+
+ * - LISP Flow Mapping
+ - Enables LISP control plane services including the mapping system
+ services REST API and LISP protocol SB plugin
+ - odl-lispflowmapping-msmr
+ - all
+
+ * - NEMO CLI
+ - Provides intent mappings and implementation with CLI for legacy devices
+ - odl-nemo-cli-renderer
+ - all
+
+ * - NEMO OpenFlow
+ - Provides intent mapping and implementation for OpenFlow devices
+ - odl-nemo-openflow-renderer
+ - self+all
+
+ * - NetIDE
+ - Enables portabilty and cooperation inside a single network by using a
+ client/server multi-controller architecture
+ - odl-netide-rest
+ - all
+
+ * - NETCONF over SSH
+ - Provides support to manage NETCONF-enabled devices over SSH
+ - odl-netconf-connector-ssh
+ - all
+
+ * - OF-CONFIG
+ - Enables remote configuration of OpenFlow datapaths
+ - odl-of-config-rest
+ - all
+
+ * - OVSDB OpenStack Neutron
+ - OpenStack Network Virtualization using OpenDaylight's OVSDB support
+ - odl-ovsdb-openstack
+ - all
+
+ * - OVSDB Southbound
+ - OVSDB MDSAL southbound plugin for Open_vSwitch schema
+ - odl-ovsdb-southbound-impl-ui
+ - all
+
+ * - OVSDB HWVTEP Southbound
+ - OVSDB MDSAL hwvtep southbound plugin for the hw_vtep schema
+ - odl-ovsdb-hwvtepsouthbound-ui
+ - all
+
+ * - OVSDB NetVirt SFC
+ - OVSDB NetVirt support for SFC
+ - odl-ovsdb-sfc-ui
+ - all
+
+ * - OpenFlow Flow Programming
+ - Enables discovery and control of OpenFlow switches and the topoology
+ between them
+ - odl-openflowplugin-flow-services-ui
+ - all
+
+ * - OpenFlow Table Type Patterns
+ - Allows OpenFlow Table Type Patterns to be manually associated with
+ network elements
+ - odl-ttp-all
+ - all
+
+ * - Packetcable PCMM
+ - Enables flow-based dynamic QoS management of CMTS use in the DOCSIS
+ infrastructure and a policy server
+ - odl-packetcable-policy-server
+ - self+all
+
+ * - PCEP
+ - Enables support for PCEP
+ - odl-bgpcep-pcep
+ - all
+
+ * - RESTCONF API Support
+ - Enables REST API access to the MD-SAL including the data store
+ - odl-restconf
+ - all
+
+ * - SDNinterface
+ - Provides support for interaction and sharing of state between
+ (non-clustered) OpenDaylight instances
+ - odl-sdninterfaceapp-all
+ - all
+
+ * - SFC over L2
+ - Supports implementing Service Function Chaining using Layer 2
+ forwarding
+ - odl-sfcofl2
+ - self+all
+
+ * - SFC over LISP
+ - Supports implementing Service Function Chaining using LISP
+ - odl-sfclisp
+ - all
+
+ * - SFC over REST
+ - Supports implementing Service Function Chaining using REST CRUD
+ operations on network elements
+ - odl-sfc-sb-rest
+ - all
+
+ * - SFC over VXLAN
+ - Supports implementing Service Function Chaining using VXLAN tunnels
+ - odl-sfc-ovs
+ - self+all
+
+ * - SNMP Plugin
+ - Enables monitoring and control of network elements via SNMP
+ - odl-snmp-plugin
+ - all
+
+ * - SNMP4SDN
+ - Enables OpenFlow-like control of network elements via SNMP
+ - odl-snmp4sdn-all
+ - all
+
+ * - SSSD Federated Authentication
+ - Enables support for federated authentication using SSSD
+ - odl-aaa-sssd-plugin
+ - all
+
+ * - Secure tag eXchange Protocol (SXP)
+ - Enables distribution of shared tags to network devices
+ - odl-sxp-controller
+ - all
+
+ * - Time Series Data Repository (TSDR)
+ - Enables support for storing and querying time series data with the
+ default data collector for OpenFlow statistics the default data store
+ for HSQLDB
+ - odl-tsdr-hsqldb-all
+ - all
+
+ * - TSDR Data Collectors
+ - Enables support for various TSDR data sources (collectors) including
+ OpenFlow statistics, NetFlow statistics, NetFlow statistics, SNMP data,
+ Syslog, and OpenDaylight (controller) metrics
+ - odl-tsdr-openflow-statistics-collector,
+ odl-tsdr-netflow-statistics-collector,
+ odl-tsdr-snmp-data-collector,
+ odl-tsdr-syslog-collector,
+ odl-tsdr-controller-metrics-collector
+ - all
+
+ * - TSDR Data Stores
+ - Enables support for TSDR data stores including HSQLDB, HBase, and
+ Cassandra
+ - odl-tsdr-hsqldb, odl-tsdr-hbase, or odl-tsdr-cassandra
+ - all
+
+ * - Topology Processing Framework
+ - Enables merged and filtered views of network topologies
+ - odl-topoprocessing-framework
+ - all
+
+ * - Unified Secure Channel (USC)
+ - Enables support for secure, remote connections to network devices
+ - odl-usc-channel-ui
+ - all
+
+ * - VPN Service
+ - Enables support for OpenStack VPNaaS
+ - odl-vpnservice-core
+ - all
+
+ * - VTN Manager
+ - Enables Virtual Tenant Network support
+ - odl-vtn-manager-rest
+ - self+all
+
+ * - VTN Manager Neutron
+ - Enables OpenStack Neutron support of VTN Manager
+ - odl-vtn-manager-neutron
+ - self+all
+
+
+Other Beryllium features
+------------------------
+
+.. list-table:: Other Beryllium features
+ :widths: 10 25 10 5
+ :header-rows: 1
+
+ * - Feature Name
+ - Feature Description
+ - Karaf feature name
+ - Compatibility
+
+ * - OpFlex
+ - Provides OpFlex agent for Open vSwitch to enforce network policy, such
+ as GBP, for locally-attached virtual machines or containers
+ - n/a
+ - all
+
+ * - NeXt
+ - Provides a developer toolkit for designing network-centric topology
+ user interfaces
+ - n/a
+ - all
+
+
+Experimental Beryllium Features
+-------------------------------
+The following functionality is labeled as experimental in OpenDaylight
+Beryllium and should be used accordingly. In general, it is not supposed to be
+used in production unless its limitations are well understood by those
+deploying it.
+
+.. list-table:: Other Beryllium features
+ :widths: 10 25 10 5
+ :header-rows: 1
+
+ * - Feature Name
+ - Feature Description
+ - Karaf feature name
+ - Compatibility
+
+ * - Authorization
+ - Enables configurable role-based authorization
+ - odl-aaa-authz
+ - all
+
+ * - ALTO
+ - Enables support for Application-Layer Traffic Optimization
+ - odl-alto-core
+ - self+all
+
+ * - CAPWAP
+ - Enables control of supported wireless APs
+ - odl-capwap-ac-rest
+ - all
+
+ * - Clustered Authentication
+ - Enables the use of the MD-SAL clustered data store for the
+ authentication database
+ - odl-aaa-authn-mdsal-cluster
+ - all
+
+ * - Controller Shield
+ - Provides controller security information to northbound applications
+ - odl-usecplugin
+ - all
+
+ * - GBP IO Visor Renderer
+ - Provides support for rendering Group Based Policy to IO Visor
+ - odl-groupbasedpolicy-iovisor
+ - all
+
+ * - Internet of Things Data Management
+ - Enables support for the oneM2M specification
+ - odl-iotdm-onem2m
+ - all
+
+ * - LISP Flow Mapping OpenStack Network Virtualization
+ - Experimental support for OpenStack Neutron virtualization
+ - odl-lispflowmapping-neutron
+ - self+all
+
+ * - Messaging4Transport
+ - Introduces an AMQP Northbound to MD-SAL
+ - odl-messaging4transport
+ - all
+
+ * - Network Intent Composition (NIC)
+ - Provides abstraction layer for communcating network intents (including
+ a distributed intent mapping service REST API) using either Hazelcast
+ or the MD-SAL as the backing data store for intents
+ - odl-nic-core-hazelcast or odl-nic-core-mdsal
+ - all
+
+ * - NIC Console
+ - Provides a Karaf CLI extension for intent CRUD operations and mapping
+ service operations
+ - odl-nic-console
+ - all
+
+ * - NIC VTN renderer
+ - Virtual Tenant Network renderer for Network Intent Composition
+ - odl-nic-renderer-vtn
+ - self+all
+
+ * - NIC GBP renderer
+ - Group Based Policy renderer for Network Intent Composition
+ - odl-nic-renderer-gbp
+ - self+all
+
+ * - NIC OpenFlow renderer
+ - OpenFlow renderer for Network Intent Composition
+ - odl-nic-renderer-of
+ - self+all
+
+ * - NIC NEMO renderer
+ - NEtwork MOdeling renderer for Network Intent Composition
+ - odl-nic-renderer-nemo
+ - self+all
+
+ * - OVSDB NetVirt UI
+ - OVSDB DLUX UI
+ - odl-ovsdb-ui
+ - all
+
+ * - Secure Networking Bootstrap
+ - Defines a SNBi domain and associated white lists of devices to be
+ accommodated to the domain
+ - odl-snbi-all
+ - self+all
+
+ * - UNI Manager
+ - Initiates the development of data models and APIs to facilitate
+ configuration and provisioning connectivity services for OpenDaylight
+ applications and services
+ - odl-unimgr
+ - all
+
+ * - YANG PUBSUB
+ - Allows subscriptions to be placed on targeted subtrees of YANG
+ datastores residing on remote devices to obviate the need for
+ OpenDaylight to make continuous fetch requests
+ - odl-yangpush-rest
+ - all
+
+Install support for REST APIs
+-----------------------------
+Most components that offer REST APIs will automatically load the RESTCONF API
+Support component, but if for whatever reason they seem to be missing, install
+the “odl-restconf” feature to activate this support.
+
+
+Install the DLUX interface
+--------------------------
+OpenDaylight’s DLUX web interface draws information from topology and host
+databases to display information about the topology of the network, flow
+statistics, and host locations.
+
+To integrate with OpenDaylight you must enable the DLUX Karaf feature. Each
+feature can be enabled or disabled separately. Ensure that you have created a
+topology and enabled the MD-SAL feature in the Karaf distribution before you
+use DLUX for network management. For more information about enabling the Karaf
+features for DLUX, refer to Enable_DLUX_Feature_.
+
+MD-SAL clustering
+-----------------
+In the Beryllium release and newer, the odl-mdsal-broker installs MD-SAL
+clustering automatically.
+
+.. _Enable_DLUX_Feature: https://wiki.opendaylight.org/view/DLUX:Beryllium_System_Test_Plan#Enabling_The_Feature
+
+
+.. _AAA: https://wiki.opendaylight.org/view/AAA:Beryllium_Release_Notes
+.. _ALTO: https://wiki.opendaylight.org/view/ALTO:Beryllium:Release_Notes
+.. _BGPCEP: https://wiki.opendaylight.org/view/BGP_LS_PCEP:Beryllium_Release_Notes
+.. _CAPWAP: https://wiki.opendaylight.org/view/CAPWAP:Beryllium:Release_Notes
+.. _Controller: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Beryllium:Release_Notes
+.. _DIDM: https://wiki.opendaylight.org/view/DIDM:_Beryllium_Release_Notes
+.. _DLUX: https://wiki.opendaylight.org/view/OpenDaylight_DLUX:Beryllium:Release_Notes
+.. _FaaS: https://wiki.opendaylight.org/view/FaaS:Beryllium_Release_Notes
+.. _Group_Based_Policy: https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Releases/Beryllium:Beryllium_Release_Notes
+.. _IoTDM: https://wiki.opendaylight.org/view/Iotdm:Beryllium_Release_Notes
+.. _L2_Switch: https://wiki.opendaylight.org/view/L2_Switch:Beryllium:Release_Notes
+.. _LACP: https://wiki.opendaylight.org/view/LACP:Beryllium:Release_Notes
+.. _LISP_Flow_Mapping: https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Beryllium_Release_Notes
+.. _MDSAL: https://wiki.opendaylight.org/view/MD-SAL:Beryllium:Release_Notes
+.. _NEMO: https://wiki.opendaylight.org/view/NEMO:Beryllium:Release_Notes
+.. _NETCONF: https://wiki.opendaylight.org/view/OpenDaylight_NETCONF:Beryllium_Release_Notes
+.. _NetIDE: https://wiki.opendaylight.org/view/NetIDE:Release_Notes
+.. _NeXt: https://wiki.opendaylight.org/view/NeXt:Beryllium_Release_Notes
+.. _NIC: https://wiki.opendaylight.org/view/Network_Intent_Composition:Release_Notes
+.. _Neutron_Northbound: https://wiki.opendaylight.org/view/NeutronNorthbound:Beryllium:Release_Notes
+.. _OF-Config: https://wiki.opendaylight.org/view/OF-CONFIG:Beryllium:Release_Notes
+.. _OpFlex: https://wiki.opendaylight.org/view/OpFlex:Beryllium_Release_Notes
+.. _OpenFlow_Plugin: https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Beryllium_Release_Notes
+.. _OpenFlow_Protocol_Library: https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Release_Notes:Beryllium_Release_Notes
+.. _OVSDB_Netvirt: https://wiki.opendaylight.org/view/OpenDaylight_OVSDB:Beryllium_Release_Notes
+.. _Packet_Cable: https://wiki.opendaylight.org/view/PacketCablePCMM:BerylliumReleaseNotes
+.. _SDN_Interface_Application: https://wiki.opendaylight.org/view/ODL-SDNi:Beryllium_Release_Notes
+.. _SNBI: https://wiki.opendaylight.org/view/SNBI_Berrylium_Release_Notes
+.. _SNMP4SDN: https://wiki.opendaylight.org/view/SNMP4SDN:Beryllium_Release_Note
+.. _SNMP_Plugin: https://wiki.opendaylight.org/view/SNMP_Plugin:SNMP_Plugin:Beryllium_Release_Notes
+.. _SXP: https://wiki.opendaylight.org/view/SXP:Beryllium:Release_Notes
+.. _SFC: https://wiki.opendaylight.org/view/Service_Function_Chaining:Beryllium_Release_Notes
+.. _TCPMD5: https://wiki.opendaylight.org/view/TCPMD5:Beryllium_Release_Notes
+.. _TSDR: https://wiki.opendaylight.org/view/TSDR:Beryllium:Release_Notes
+.. _TTP: https://wiki.opendaylight.org/view/Table_Type_Patterns/Beryllium/Release_Notes
+.. _Topology_Processing_Framework: https://wiki.opendaylight.org/view/Topology_Processing_Framework:BERYLLIUM_Release_Notes
+.. _USC: https://wiki.opendaylight.org/view/USC:Beryllium:Release_Notes
+.. _VPN_Service: https://wiki.opendaylight.org/view/Vpnservice:Beryllium_Release_Notes
+.. _VTN: https://wiki.opendaylight.org/view/VTN:Beryllium:Release_Notes
+.. _YANG_Tools: https://wiki.opendaylight.org/view/YANG_Tools:Beryllium:Release_Notes
--- /dev/null
+Introduction
+============
+
+The OpenDaylight project is an open source platform for Software Defined
+Networking (SDN) that uses open protocols to provide centralized, programmatic
+control and network device monitoring. Like many other SDN controllers,
+OpenDaylight supports OpenFlow, as well as offering ready-to-install network
+solutions as part of its platform.
+
+Much as your operating system provides an interface for the devices that
+comprise your computer, OpenDaylight provides an interface that allows you to
+connect network devices quickly and intelligently for optimal network
+performance.
+
+It’s extremely helpful to understand that setting up your networking environment
+with OpenDaylight is not a single software installation. While your first
+chronological step is to install OpenDaylight, you install additional
+functionality packaged as Karaf features to suit your specific needs.
+
+Before walking you through the initial OpenDaylight installation, this guide
+presents a fuller picture of OpenDaylight’s framework and functionality so you
+understand how to set up your networking environment. The guide then takes you
+through the installation process.
+
+What’s different about OpenDaylight
+-----------------------------------
+
+Major distinctions of OpenDaylight’s SDN compared to traditional SDN options are
+the following:
+
+* A microservices architecture, in which a “microservice” is a particular
+ protocol or service that a user wants to enable within their installation of
+ the OpenDaylight controller, for example:
+
+ * A plugin that provides connectivity to devices via the OpenFlow or BGP
+ protocols
+ * An L2-Switch or a service such as Authentication, Authorization, and
+ Accounting (AAA).
+
+* Support for a wide and growing range of network protocols beyond OpenFlow,
+ including SNMP, NETCONF, OVSDB, BGP, PCEP, LISP, and more.
+* Support for developing new functionality comprised of additional networking
+ protocols and services.
+
+.. note:: A thorough understanding of the microservices architecture is
+ important for experienced network developers who want to create new solutions
+ in OpenDaylight. If you are new to networking and OpenDaylight, you most
+ likely won’t design solutions, but you should comprehend the microservices
+ concept to understand how OpenDaylight works and how it differs from other
+ SDN programs.
+
+What you’ll find in this guide
+------------------------------
+
+To set up your environment, you first install OpenDaylight followed by the
+Apache Karaf features that offer the functionality you require. The OpenDaylight
+Getting Started Guide covers feature descriptions, OpenDaylight installation
+procedures, and feature installation.
+
+
+The Getting Started Guide also includes other helpful information, with the
+following organization:
+
+#. An overview of OpenDaylight and common use models
+#. Who should use this guide?
+#. OpenDaylight concepts and tools
+#. Explanations of OpenDaylight Apache Karaf features and other features that
+ extend network functionality
+#. OpenDaylight Beryllium system requirements and Release Notes
+#. OpenDaylight installation instructions
+#. Feature tables with installation names and compatibility notes
--- /dev/null
+OpenDaylight Karaf Features
+===========================
+
+This section provides brief descriptions of the most commonly used Karaf
+features developed by OpenDaylight project teams. They are presented in
+alphabetical order. OpenDaylight installation instructions and a feature table
+that lists installation commands and compatibility follow.
+
+.. contents::
+ :depth: 1
+ :local:
+
+AAA
+---
+Standards-compliant Authentication, Authorization and Accounting Services.
+RESTCONF is the most common consumer of AAA, which installs the AAA features
+automatically. AAA provides:
+
+* Support for persistent data stores
+* Federation and SSO with OpenStack Keystone
+
+The Beryllium release of AAA includes experimental support for having the database of users and credentials stored in the cluster-aware MD-SAL datastore.
+
+ALTO
+----
+Implements the Application-Layer Traffic Optimization (ALTO) base IETF protocol
+to provide network information to applications. It defines abstractions and
+services to enable simplified network views and network services to guide
+application usage of network resources and includes five services:
+
+#. Network Map Service - Provides batch information to ALTO clients in the forms
+ of ALTO network maps.
+#. Cost Map Service - Provides costs between defined groupings.
+#. Filtered Map Service - Allows ALTO clients to query an ALTO server on ALTO
+ network maps and/or cost maps based on additional parameters.
+#. Endpoint Property Service - Allows ALTO clients to look up properties for
+ individual endpoints.
+#. Endpoint Cost Service - Allows an ALTO server to return costs directly
+ amongst endpoints.
+
+Border Gateway Protocol (including Link-state Distribution (BGP)
+----------------------------------------------------------------
+Is a southbound plugin that provides support for Border Gateway Protocol
+(including Link-state Distribution) as a source of L3 topology information.
+
+Border Gateway Monitoring Protocol (BMP)
+----------------------------------------
+Is a southbound plugin that provides support for BGP Monitoring Protocol as a
+monitoring station.
+
+Control and Provisioning of Wireless Access Points (CAPWAP)
+-----------------------------------------------------------
+Enables OpenDaylight to manage CAPWAP-compliant wireless termination point (WTP)
+network devices. Intelligent applications, e.g., radio planning, can be
+developed by tapping into the operational states made available via REST APIs of
+WTP network devices.
+
+Controller Shield
+-----------------
+Creates a repository called the Unified-Security Plugin (USecPlugin) to provide
+controller security information to northbound applications, such as the
+following:
+
+* Collating the source of different attacks reported in southbound plugins
+* Gathering information on suspected controller intrusions and trusted
+ controllers in the network
+
+Information collected at the plugin may also be used to configure firewalls and create IP blacklists for the network.
+
+Device Identification and Driver Management (DIDM)
+--------------------------------------------------
+Provides device-specific functionality, which means that code enabling a feature
+understands the capability and limitations of the device it runs on. 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.
+
+DLUX
+----
+Web based OpenDaylight user interface that includes:
+
+* An MD-SAL flow viewer
+* Network topology visualizer
+* A tool box and YANG model that execute queries and visualize the YANG tree
+
+Fabric as a Service (FaaS)
+--------------------------
+Creates a common abstraction layer on top of a physical network so northbound
+APIs or services can be more easily mapped onto the physical network as a
+concrete device configuration.
+
+Group Based Policy (GBP)
+------------------------
+Defines an application-centric policy model for OpenDaylight that separates
+information about application connectivity requirements from information about
+the underlying details of the network infrastructure. Provides support for:
+
+* Integration with OpenStack Neutron
+* Service Function Chaining
+* OFOverlay support for NAT, table offsets
+
+Internet of Things Data Management (IoTDM)
+------------------------------------------
+Developing a data-centric middleware to act as a oneM2M_-compliant IoT Data
+Broker (IoTDB) and enable authorized applications to retrieve IoT data uploaded
+by any device.
+
+Link Aggregation Control Protocol (LACP)
+----------------------------------------
+LACP can auto-discover and aggregate multiple links between an
+OpenDaylight-controlled network and LACP-enabled endpoints or switches.
+
+Location Identifier Separation Protocol (LISP) Flow Mapping Service (LISP)
+--------------------------------------------------------------------------
+LISP (RFC6830) enables separation of Endpoint Identity (EID) from Routing
+Location (RLOC) by defining an overlay in the EID space, which is mapped to the
+underlying network in the RLOC space.
+
+*LISP Mapping Service* provides the EID-to-RLOC mapping information, including
+forwarding policy (load balancing, traffic engineering, and so on) to LISP
+routers for tunneling and forwarding purposes. The LISP Mapping Service can
+serve the mapping data to data plane nodes as well as to OpenDaylight
+applications.
+
+To leverage this service, a northbound API allows OpenDaylight applications and
+services to define the mappings and policies in the LISP Mapping Service. A
+southbound LISP plugin enables LISP data plane devices to interact with
+OpenDaylight via the LISP protocol.
+
+NEMO
+----
+Is a Domain Specific Language (DSL) for the abstraction of network models and
+identification of operation patterns. NEMO enables network users/applications to
+describe their demands for network resources, services, and logical operations
+in an intuitive way that can be explained and executed by a language engine.
+
+NETCONF
+-------
+Offers four features:
+
+* odl-netconf-mdsal: NETCONF Northbound for MD-SAL and applications
+* odl-netconf-connector: NETCONF Southbound plugin - configured through the
+ configuration subsystem
+* odl-netconf-topology: NETCONF Southbound plugin - configured through the
+ MD-SAL configuration datastore
+* odl-restconf: RESTCONF Northbound for MD-SAL and applications
+
+NetIDE
+------
+Enables portability and cooperation inside a single network by using a
+client/server multi-controller architecture. It provides an interoperability
+layer allowing SDN Applications written for other SDN Controllers to run on
+OpenDaylight. NetIDE details:
+
+* Architecture follows a client/server model: other SDN controllers represent
+ clients with OpenDaylight acting as the server.
+* OpenFlow v1.0/v1.3 is the only southbound protocol supported in this initial
+ release. We are planning for other southbound protocols in later releases.
+* The developer documentation contains the protocol specifications required for
+ developing plugins for other client SDN controllers.
+* The NetIDE Configuration file contains the configurable elements for the
+ engine.
+
+OVSDB-based Network Virtualization Services
+-------------------------------------------
+Several services and plugins in OpenDaylight work together to provide simplified
+integration with the OpenStack Neutron framework. These services enable
+OpenStack to offload network processing to OpenDaylight while enabling
+OpenDaylight to provide enhanced network services to OpenStack.
+
+OVSDB Services are at parity with the Neutron Reference Implementation in
+OpenStack, including support for:
+
+* L2/L3
+
+ * The OpenDaylight Layer-3 Distributed Virtual Router is fully on par with
+ what OpenStack offers and now provides completely decentralized Layer 3
+ routing for OpenStack. ICMP rules for responding on behalf of the L3 router
+ are fully distributed as well.
+ * Full support for distributed Layer-2 switching and distributed IPv4 routing
+ is now available.
+
+* Clustering - Full support for clustering and High Availability (HA) is
+ available in the OpenDaylight Beryllium release. In particular, the OVSDB
+ southbound plugin supports clustering that any application can use, and the
+ Openstack network integration with OpenDaylight (through OVSDB Net-Virt) has
+ full clustering support. While there is no specific limit on cluster size, a
+ 3-node cluster has been tested extensively as part of the Beryllium release.
+
+* Security Groups - Security Group support is available and implemented using
+ OpenFlow rules that provide superior functionality and performance over
+ OpenStack Security Groups, which use IPTables. Security Groups also provide
+ support for ConnTrack with stateful tracking of existing connections.
+ Contract-based Security Groups require OVS v2.5 with contract support.
+
+* Hardware Virtual Tunnel End Point (HW-VTEP) - Full HW-VTEP schema support has
+ been implemented in the OVSDB protocol driver. Support for HW-VTEP via
+ OpenStack through the OVSDB-NetVirt implementation has not yet been provided
+ as we wait for full support of Layer-2 Gateway (L2GW) to be implemented within
+ OpenStack.
+
+* Service Function Chaining
+
+* Open vSwitch southbound support for quality of service and Queue configuration
+ Load Balancer as service (LBaaS) with Distributed Virtual Router, as offered
+ in the Lithium release
+
+* Network Virtualization User interface for DLUX
+
+OpenFlow Configuration Protocol (OF-CONFIG)
+-------------------------------------------
+Provides a process for an Operation Context containing an OpenFlow Switch that uses OF-CONFIG to communicate with an OpenFlow Configuration Point, enabling remote configuration of OpenFlow datapaths.
+
+OpenFlow plugin
+---------------
+Supports connecting to OpenFlow-enabled network devices via the OpenFlow
+specification. It currently supports OpenFlow versions 1.0 and 1.3.2.
+
+In addition to support for the core OpenFlow specification, OpenDaylight
+Beryllium also includes preliminary support for the Table Type Patterns and
+OF-CONFIG specifications.
+
+Path Computation Element Protocol (PCEP)
+----------------------------------------
+Is a southbound plugin that provides support for performing Create, Read,
+Update, and Delete (CRUD) operations on Multiprotocol Label Switching (MPLS)
+tunnels in the underlying network.
+
+Secure Network Bootstrapping Interface (SNBi)
+---------------------------------------------
+Leverages manufacturer-installed IEEE 802.1AR certificates to secure initial
+communications for a zero-touch approach to bootstrapping using Docker. SNBi
+devices and controllers automatically do the following:
+
+#. Discover each other, which includes:
+
+ a. Revealing the physical topology of the network
+ #. Exposing each type of a device
+ #. Assigning the domain for each device
+
+#. Get assigned an IP-address
+#. Establish secure IP connectivity
+
+SNBi creates a basic infrastructure to host, run, and lifecycle-manage multiple
+network functions within a network device, including individual network element
+services, such as:
+
+* Performance measurement
+* Traffic-sniffing functionality
+* Traffic transformation functionality
+
+SNBi also provides a Linux side abstraction layer to forward elements as well
+as enhancements to feature the abstraction and bootstrapping infrastructure.
+You can also use the device type and domain information to initiate controller
+federation processes.
+
+Service Function Chaining (SFC)
+-------------------------------
+Provides the ability to define an ordered list of network services (e.g.
+firewalls, load balancers) that are then "stitched" together in the network to
+create a service chain. SFC provides the chaining logic and APIs necessary for
+OpenDaylight to provision a service chain in the network and an end-user
+application for defining such chains. It includes:
+
+* YANG models to express service function chains
+* SFC receiver for Intent expressions from REST & RPC
+* UI for service chain construction
+* LISP support
+* Function grouping for load balancing
+* OpenFlow renderer for Network Service Headers, MPLS, and VLAN
+* Southbound REST interface
+* IP Tables-based classifier for grouping packets into selected service chains
+* Integration with OpenDaylight GBP project
+* Integration with OpenDaylight OVSDB NetVirt project
+
+SNMP Plugin
+-----------
+The SNMP southbound plugin allows applications acting as an SNMP Manager to
+interact with devices that support an SNMP agent. The SNMP plugin implements a
+general SNMP implementation, which differs from the SNMP4SDN as that project
+leverages only select SNMP features to implement the specific use case of
+making an SNMP-enabled device emulate some features of an OpenFlow-enabled
+device.
+
+SNMP4SDN
+--------
+Provides a southbound SNMP plugin to optimize delivery of SDN controller
+benefits to traditional/legacy ethernet switches through the SNMP interface. It
+offers support for flow configuration on ACLs and enables flow configuration
+via REST API and multi-vendor support.
+
+Source-Group Tag Exchange Protocol (SXP)
+----------------------------------------
+Enables creation of a tag that allows you to filter traffic instead of using
+protocol-specific information like addresses and ports. Via SXP an external
+entity creates the tags, assigns them to traffic appropriately, and publishes
+information about the tags to network devices so they can enforce the tags
+appropriately.
+
+More specifically, SXP Is an IETF-published control protocol designed to
+propagate the binding between an IP address and a source group, which has a
+unique source group tag (SGT). Within the SXP protocol, source groups with
+common network policies are endpoints connecting to the network. SXP updates
+the firewall with SGTs, enabling the firewalls to create topology-independent
+Access Control Lists (ACLs) and provide ACL automation.
+
+SXP source groups have the same meaning as endpoint groups in OpenDaylight’s
+Group Based Policy (GBP), which is used to manipulate policy groups, so you can
+use OpenDaylight GPB with SXP SGTs. The SXP topology-independent policy
+definition and automation can be extended through OpenDaylight for other
+services and networking devices.
+
+Topology Processing Framework
+-----------------------------
+Provides a framework for simplified aggregation and topology data query to
+enable a unified topology view, including multi-protocol, Underlay, and
+Overlay resources.
+
+Time Series Data Repository (TSDR)
+----------------------------------
+Creates a framework for collecting, storing, querying, and maintaining time
+series data in OpenDaylight. You can leverage various data-driven applications
+built on top of TSDR when you install a datastore and at least one collector.
+
+Functionality of TDSR includes:
+
+* Data Query Service - For external data-driven applications to query data from
+ TSDR through REST APIs
+* NBI integration with Grafana - Allows visualization of data collected in TSDR
+ using Grafana
+* Data Purging Service - Periodically purges data from TSDR
+* Data Collection Framework - Data Collection framework to allow plugging in of
+ various types of collectors
+* HSQL data store - Replacement of H2 data store to remove third party
+ component dependency from TSDR
+* Enhancement of existing data stores including HBase to support new features
+ introduced in Beryllium
+* Cassandra data store - Cassandra implementation of TSDR SPIs
+* NetFlow data collector - Collect NetFlow data from network elements
+* SNMP Data Collector - Integrates with SNMP plugin to bring SNMP data into TSDR
+* Syslog data collector - Collects syslog data from network elements
+
+TSDR has multiple features to enable the functionality above. To begin,
+select one of these data stores:
+
+* odl-tsdr-hsqldb-all
+* odl-tsdr-hbase
+* odl-tsdr-cassandra
+
+Then select any “collectors” you want to use:
+
+* odl-tsdr-openflow-statistics-collector
+* odl-tsdr-netflow-statistics-collector
+* odl-tsdr-controller-metrics-collector
+* odl-tsdr-snmp-data-collector
+* odl-tsdr-syslog-collector
+
+See these TSDR_Directions_ for more information.
+
+Unified Secure Channel (USC)
+----------------------------
+Provides a central server to coordinate encrypted communications between
+endpoints. Its client-side agent informs the controller about its encryption
+capabilities and can be instructed to encrypt select flows based on business
+policies.
+
+A possible use case is encrypting controller-to-controller communications;
+however, the framework is very flexible, and client side software is available
+for multiple platforms and device types, enabling USC and OpenDaylight to
+centralize the coordination of encryption across a wide array of endpoint and
+device types.
+
+VPN Service
+-----------
+Implements the infrastructure services required to support L3 VPN service. It
+initially leverages open source routing applications as pluggable components.
+L3 services include:
+
+* The L3 VPN Manager
+* MP-BGP Routing Stack
+* MPLS Label Manager
+* NextHop Manager
+* FIB Service & Openstack Neutron Service
+
+The VPN Service offers:
+
+* An API for L3 VPN Services
+* Integration with open source routing suites, including Quagga & Ryu
+* OpenStack Integration with BGPVPN_Blueprint_ for end-to-end integration
+* OpenStack Neutron integration
+* VPN Service upstreamed as part of SDN-distributed routing and the VPN (SDNVPN)
+ project of Open Platform for NFV project (OPNFV) (available in Brahmaputra
+ release)
+* Network Overlay solution necessary for a Datacenter/Cloud environment
+
+Virtual Tenant Network (VTN)
+----------------------------
+Provides multi-tenant virtual network on an SDN controller, allowing you to
+define the network with a look and feel of a conventional L2/L3 network. Once
+the network is designed on VTN, it automatically maps into the underlying
+physical network and is then configured on the individual switch, leveraging
+the SDN control protocol.
+
+By defining a logical plane with VTN, you can conceal the complexity of the
+underlying network and better manage network resources to reduce network
+configuration time and errors.
+
+.. _BGPVPN_Blueprint: http://docs.openstack.org/developer/networking-bgpvpn/
+.. _oneM2M: http://www.onem2m.org/
+.. _TSDR_Directions: https://wiki.opendaylight.org/view/Grafana_Integration_with_TSDR_Step-by-Step
--- /dev/null
+Other features
+==============
+
+OpFlex
+------
+Provides the OpenDaylight OpFlex Agent , which is a policy agent that works
+with Open vSwitch (OVS), to enforce network policy, e.g., from Group-Based
+Policy, for locally-attached virtual machines or containers.
+
+Network embedded Experience (NeXt)
+----------------------------------
+Provides a network-centric topology UI that offers visualizations of the
+following:
+
+a. Large complex network topologies
+#. Aggregated network nodes
+#. Traffic/path/tunnel/group visualizations
+#. Different layout algorithms
+#. Map overlays
+#. Preset user-friendly interactions
+
+NeXt can work with DLUX to build OpenDaylight applications. NeXt does not
+support Internet Explorer. Check out the NeXt_demo_ for more information on the
+interface.
+
+.. _NeXt_demo: https://www.youtube.com/watch?v=gBsUDu8aucs
--- /dev/null
+Overview
+========
+
+OpenDaylight performs the following functions:
+
+* Logically centralizes programmatic control of the physical and virtual devices
+ in your network.
+* Controls devices with standard, open protocols.
+* Provides higher-level abstractions of its capabilities so experienced network
+ engineers and developers can create new applications to customize network
+ setup and administration.
+
+Common use cases for SDN are as follows:
+
+#. Centralized network monitoring, management, and orchestration
+#. Proactive network management and traffic engineering
+#. Chaining packets through the different VMs, which is known as service
+ function chaining (SFC). SFC enables Network Functions Virtualization (NFV),
+ which is a network architecture concept that virtualizes entire classes of
+ network node functions into building blocks that may connect, or chain
+ together, to create communication services.
+#. Cloud - managing both the virtual overlay and the physical underlay beneath
+ it.
--- /dev/null
+Who should use this guide?
+==========================
+
+OpenDaylight is for users considering open options in network programming. This
+guide provides information for the following types of users:
+
+#. Those new to OpenDaylight who want to install it and select the features they
+ need to run their network environment using only the command line and GUI.
+ Such users include:
+
+ a. Students
+ #. Network administrators and engineers.
+
+#. Network engineers and network application developers who want to use
+ OpenDaylight’s REST APIs to manage their network programmatically.
+#. Network engineers and network application developers who want to write their
+ own OpenDaylight services and plugins for greater functionality. This group
+ of users needs a significant level of expertise in the following areas, which
+ is beyond the scope of this document:
+
+ a. The YANG modeling language
+ #. The Model-Driven Service Abstraction Layer (MD-SAL)
+ #. Maven build tool
+ #. Management of the shared data store
+ #. How to handle notifications and/or Remote Procedure Calls (RPCs)
+
+#. Developers who would like to join the OpenDaylight community and contribute
+ code upstream. People in this group design offerings such as
+ applications/services, protocol implementations, and so on, to increase
+ OpenDaylight functionality for the benefit of all end-users.
+
+.. note:: If you develop code to build new functionality for OpenDaylight and
+ push it upstream (not required), it can become part of the OpenDaylight
+ release. Users can then install the features to implement the solution you’ve
+ created.
--- /dev/null
+.. OpenDaylight Documentation documentation master file, created by
+ sphinx-quickstart on Mon Mar 28 14:20:08 2016.
+ You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Welcome to the OpenDaylight Handbook!
+=====================================
+
+Contents:
+
+.. toctree::
+ :maxdepth: 2
+
+ getting-started-guide/index
+ opendaylight-with-openstack/index
+ submodules/releng/builder/docs/index
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
--- /dev/null
+@ECHO OFF\r
+\r
+REM Command file for Sphinx documentation\r
+\r
+if "%SPHINXBUILD%" == "" (\r
+ set SPHINXBUILD=sphinx-build\r
+)\r
+set BUILDDIR=_build\r
+set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% .\r
+set I18NSPHINXOPTS=%SPHINXOPTS% .\r
+if NOT "%PAPER%" == "" (\r
+ set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%\r
+ set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS%\r
+)\r
+\r
+if "%1" == "" goto help\r
+\r
+if "%1" == "help" (\r
+ :help\r
+ echo.Please use `make ^<target^>` where ^<target^> is one of\r
+ echo. html to make standalone HTML files\r
+ echo. dirhtml to make HTML files named index.html in directories\r
+ echo. singlehtml to make a single large HTML file\r
+ echo. pickle to make pickle files\r
+ echo. json to make JSON files\r
+ echo. htmlhelp to make HTML files and a HTML help project\r
+ echo. qthelp to make HTML files and a qthelp project\r
+ echo. devhelp to make HTML files and a Devhelp project\r
+ echo. epub to make an epub\r
+ echo. epub3 to make an epub3\r
+ echo. latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter\r
+ echo. text to make text files\r
+ echo. man to make manual pages\r
+ echo. texinfo to make Texinfo files\r
+ echo. gettext to make PO message catalogs\r
+ echo. changes to make an overview over all changed/added/deprecated items\r
+ echo. xml to make Docutils-native XML files\r
+ echo. pseudoxml to make pseudoxml-XML files for display purposes\r
+ echo. linkcheck to check all external links for integrity\r
+ echo. doctest to run all doctests embedded in the documentation if enabled\r
+ echo. coverage to run coverage check of the documentation if enabled\r
+ goto end\r
+)\r
+\r
+if "%1" == "clean" (\r
+ for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i\r
+ del /q /s %BUILDDIR%\*\r
+ goto end\r
+)\r
+\r
+\r
+REM Check if sphinx-build is available and fallback to Python version if any\r
+%SPHINXBUILD% 1>NUL 2>NUL\r
+if errorlevel 9009 goto sphinx_python\r
+goto sphinx_ok\r
+\r
+:sphinx_python\r
+\r
+set SPHINXBUILD=python -m sphinx.__init__\r
+%SPHINXBUILD% 2> nul\r
+if errorlevel 9009 (\r
+ echo.\r
+ echo.The 'sphinx-build' command was not found. Make sure you have Sphinx\r
+ echo.installed, then set the SPHINXBUILD environment variable to point\r
+ echo.to the full path of the 'sphinx-build' executable. Alternatively you\r
+ echo.may add the Sphinx directory to PATH.\r
+ echo.\r
+ echo.If you don't have Sphinx installed, grab it from\r
+ echo.http://sphinx-doc.org/\r
+ exit /b 1\r
+)\r
+\r
+:sphinx_ok\r
+\r
+\r
+if "%1" == "html" (\r
+ %SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished. The HTML pages are in %BUILDDIR%/html.\r
+ goto end\r
+)\r
+\r
+if "%1" == "dirhtml" (\r
+ %SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml.\r
+ goto end\r
+)\r
+\r
+if "%1" == "singlehtml" (\r
+ %SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml.\r
+ goto end\r
+)\r
+\r
+if "%1" == "pickle" (\r
+ %SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished; now you can process the pickle files.\r
+ goto end\r
+)\r
+\r
+if "%1" == "json" (\r
+ %SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished; now you can process the JSON files.\r
+ goto end\r
+)\r
+\r
+if "%1" == "htmlhelp" (\r
+ %SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished; now you can run HTML Help Workshop with the ^\r
+.hhp project file in %BUILDDIR%/htmlhelp.\r
+ goto end\r
+)\r
+\r
+if "%1" == "qthelp" (\r
+ %SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished; now you can run "qcollectiongenerator" with the ^\r
+.qhcp project file in %BUILDDIR%/qthelp, like this:\r
+ echo.^> qcollectiongenerator %BUILDDIR%\qthelp\OpenDaylightDocumentation.qhcp\r
+ echo.To view the help file:\r
+ echo.^> assistant -collectionFile %BUILDDIR%\qthelp\OpenDaylightDocumentation.ghc\r
+ goto end\r
+)\r
+\r
+if "%1" == "devhelp" (\r
+ %SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished.\r
+ goto end\r
+)\r
+\r
+if "%1" == "epub" (\r
+ %SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished. The epub file is in %BUILDDIR%/epub.\r
+ goto end\r
+)\r
+\r
+if "%1" == "epub3" (\r
+ %SPHINXBUILD% -b epub3 %ALLSPHINXOPTS% %BUILDDIR%/epub3\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished. The epub3 file is in %BUILDDIR%/epub3.\r
+ goto end\r
+)\r
+\r
+if "%1" == "latex" (\r
+ %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished; the LaTeX files are in %BUILDDIR%/latex.\r
+ goto end\r
+)\r
+\r
+if "%1" == "latexpdf" (\r
+ %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex\r
+ cd %BUILDDIR%/latex\r
+ make all-pdf\r
+ cd %~dp0\r
+ echo.\r
+ echo.Build finished; the PDF files are in %BUILDDIR%/latex.\r
+ goto end\r
+)\r
+\r
+if "%1" == "latexpdfja" (\r
+ %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex\r
+ cd %BUILDDIR%/latex\r
+ make all-pdf-ja\r
+ cd %~dp0\r
+ echo.\r
+ echo.Build finished; the PDF files are in %BUILDDIR%/latex.\r
+ goto end\r
+)\r
+\r
+if "%1" == "text" (\r
+ %SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished. The text files are in %BUILDDIR%/text.\r
+ goto end\r
+)\r
+\r
+if "%1" == "man" (\r
+ %SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished. The manual pages are in %BUILDDIR%/man.\r
+ goto end\r
+)\r
+\r
+if "%1" == "texinfo" (\r
+ %SPHINXBUILD% -b texinfo %ALLSPHINXOPTS% %BUILDDIR%/texinfo\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished. The Texinfo files are in %BUILDDIR%/texinfo.\r
+ goto end\r
+)\r
+\r
+if "%1" == "gettext" (\r
+ %SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished. The message catalogs are in %BUILDDIR%/locale.\r
+ goto end\r
+)\r
+\r
+if "%1" == "changes" (\r
+ %SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.The overview file is in %BUILDDIR%/changes.\r
+ goto end\r
+)\r
+\r
+if "%1" == "linkcheck" (\r
+ %SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Link check complete; look for any errors in the above output ^\r
+or in %BUILDDIR%/linkcheck/output.txt.\r
+ goto end\r
+)\r
+\r
+if "%1" == "doctest" (\r
+ %SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Testing of doctests in the sources finished, look at the ^\r
+results in %BUILDDIR%/doctest/output.txt.\r
+ goto end\r
+)\r
+\r
+if "%1" == "coverage" (\r
+ %SPHINXBUILD% -b coverage %ALLSPHINXOPTS% %BUILDDIR%/coverage\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Testing of coverage in the sources finished, look at the ^\r
+results in %BUILDDIR%/coverage/python.txt.\r
+ goto end\r
+)\r
+\r
+if "%1" == "xml" (\r
+ %SPHINXBUILD% -b xml %ALLSPHINXOPTS% %BUILDDIR%/xml\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished. The XML files are in %BUILDDIR%/xml.\r
+ goto end\r
+)\r
+\r
+if "%1" == "pseudoxml" (\r
+ %SPHINXBUILD% -b pseudoxml %ALLSPHINXOPTS% %BUILDDIR%/pseudoxml\r
+ if errorlevel 1 exit /b 1\r
+ echo.\r
+ echo.Build finished. The pseudo-XML files are in %BUILDDIR%/pseudoxml.\r
+ goto end\r
+)\r
+\r
+:end\r
--- /dev/null
+OpenDaylight with Openstack Guide
+=================================
+
+Overview
+--------
+
+OpenStack_ is a popular open source Infrastructure
+as a service project, covering compute, storage and network management.
+OpenStack can use OpenDaylight as its network management provider through the
+Modular Layer 2 (ML2) north-bound plug-in. OpenDaylight manages the network
+flows for the OpenStack compute nodes via the OVSDB south-bound plug-in. This
+page describes how to set that up, and how to tell when everything is working.
+
+Installing OpenStack
+--------------------
+
+Installing OpenStack is out of scope for this document, but to get started, it
+is useful to have a minimal multi-node OpenStack deployment.
+
+The reference deployment we will use for this document is a 3 node cluster:
+
+* One control node containing all of the management services for OpenStack_
+ (Nova, Neutron, Glance, Swift, Cinder, Keystone)
+* Two compute nodes running nova-compute
+* Neutron using the OVS back-end and vxlan for tunnels
+
+Once you have installed OpenStack_, verify that it is working by connecting
+to Horizon and performing a few operations. To check the Neutron
+configuration, create two instances on a private subnet bridging to your
+public network, and verify that you can connect to them, and that they can
+see each other.
+
+
+Installing OpenDaylight
+-----------------------
+
+.. toctree::
+ :maxdepth: 1
+
+ openstack-with-ovsdb
+ openstack-with-gbp
+ openstack-with-vtn
+
+.. _OpenStack: https://www.openstack.org/
--- /dev/null
+OpenStack with GroupBasedPolicy
+===============================
+
+This section is for Application Developers and Network Administrators
+who are looking to integrate Group Based Policy with OpenStack.
+
+To enable the **GBP** Neutron Mapper feature, at the karaf console:
+
+.. code-block:: bash
+
+ feature:install odl-groupbasedpolicy-neutronmapper
+
+Neutron Mapper has the following dependencies that are automatically loaded:
+
+.. code-block:: bash
+
+ odl-neutron-service
+
+Neutron Northbound implementing REST API used by OpenStack
+
+.. code-block:: bash
+
+ odl-groupbasedpolicy-base
+
+Base **GBP** feature set, such as policy resolution, data model etc.
+
+.. code-block:: bash
+
+ odl-groupbasedpolicy-ofoverlay
+
+For 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 `Neutron V2.0 API <neutron_v2api_>`_.
+
+Features
+--------
+
+List of supported Neutron entities:
+
+* Port
+* Network
+
+ * Standard Internal
+ * External provider L2/L3 network
+
+* Subnet
+* Security-groups
+* Routers
+
+ * Distributed functionality with local routing per compute
+ * External gateway access per compute node (dedicated port required)
+ * Multiple routers per tenant
+
+* FloatingIP NAT
+* IPv4/IPv6 support
+
+The mapping of Neutron entities to **GBP** entities is as follows:
+
+**Neutron Port**
+
+.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-port.png
+
+ Neutron Port
+
+The Neutron port is mapped to an endpoint.
+
+The current implementation supports one IP address per Neutron port.
+
+An endpoint and L3-endpoint belong to multiple EndpointGroups if the Neutron
+port is in multiple Neutron Security Groups.
+
+The key for endpoint is L2-bridge-domain obtained as the parent of
+L2-flood-domain representing Neutron network. The MAC address is from the
+Neutron port.
+An L3-endpoint is created based on L3-context (the parent of the
+L2-bridge-domain) and IP address of Neutron Port.
+
+**Neutron Network**
+
+.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-network.png
+
+ Neutron Network
+
+A Neutron network has the following characteristics:
+
+* defines a broadcast domain
+* defines a L2 transmission domain
+* defines a L2 name space.
+
+To represent this, a Neutron Network is mapped to multiple **GBP** entities.
+The first mapping is to an L2 flood-domain to reflect that the Neutron network
+is one flooding or broadcast domain.
+An L2-bridge-domain is then associated as the parent of L2 flood-domain. This
+reflects both the L2 transmission domain as well as the L2 addressing namespace.
+
+The third mapping is to L3-context, which represents the distinct L3 address space.
+The L3-context is the parent of L2-bridge-domain.
+
+**Neutron Subnet**
+
+
+.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-subnet.png
+
+ Neutron Subnet
+
+Neutron subnet is associated with a Neutron network. The Neutron subnet is
+mapped to a *GBP* subnet where the parent of the subnet is L2-flood-domain
+representing the Neutron network.
+
+**Neutron Security Group**
+
+
+.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-securitygroup.png
+
+ Neutron Security Group and Rules
+
+**GBP** entity representing Neutron security-group is EndpointGroup.
+
+**Infrastructure EndpointGroups**
+
+Neutron-mapper automatically creates EndpointGroups to manage key infrastructure
+items such as:
+
+* DHCP EndpointGroup - contains endpoints representing Neutron DHCP ports
+* Router EndpointGroup - contains endpoints representing Neutron router
+ interfaces
+* External EndpointGroup - holds L3-endpoints representing Neutron router
+ gateway ports, also associated with FloatingIP ports.
+
+**Neutron Security Group Rules**
+
+This mapping is most complicated among all others because Neutron
+security-group-rules are mapped to contracts with clauses,
+subjects, rules, action-refs, classifier-refs, etc.
+Contracts are used between endpoint groups representing Neutron Security Groups.
+For simplification it is important to note that Neutron security-group-rules are
+similar to a **GBP** rule containing:
+
+* classifier with direction
+* action of *allow*.
+
+
+**Neutron Routers**
+
+
+.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-router.png
+
+ Neutron Router
+
+Neutron router is represented as a L3-context. This treats a router as a Layer3
+namespace, and hence every network attached to it a part
+of that Layer3 namespace.
+
+This allows for multiple routers per tenant with complete isolation.
+
+The mapping of the router to an endpoint represents the router's interface or
+gateway port.
+
+The mapping to an EndpointGroup represents the internal infrastructure
+EndpointGroups created by the **GBP** Neutron Mapper
+
+When a Neutron router interface is attached to a network/subnet, that
+network/subnet and its associated endpoints or Neutron Ports are seamlessly
+added to the namespace.
+
+**Neutron FloatingIP**
+
+When associated with a Neutron Port, this leverages the *GBP* OfOverlay
+renderer's NAT capabilities.
+
+A dedicated *external* interface on each Nova compute host allows for
+disitributed external access. Each Nova instance associated with a
+FloatingIP address can access the external network directly without having to
+route via the Neutron controller, or having to enable any form
+of Neutron distributed routing functionality.
+
+Assuming the gateway provisioned in the Neutron Subnet command for the external
+network is reachable, the combination of *GBP* Neutron Mapper and
+OfOverlay renderer will automatically ARP for this default gateway, requiring
+no user intervention.
+
+
+**Troubleshooting within GBP**
+
+Logging level for the mapping functionality can be set for package
+org.opendaylight.groupbasedpolicy.neutron.mapper. An example of enabling TRACE
+logging level on karaf console:
+
+.. code-block:: bash
+
+ log:set TRACE org.opendaylight.groupbasedpolicy.neutron.mapper
+
+**Neutron mapping example**
+
+As an example for mapping can be used creation of Neutron network, subnet and
+port. When a Neutron network is created 3 **GBP** entities are created:
+l2-flood-domain, l2-bridge-domain, l3-context.
+
+.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-network-example.png
+
+ Neutron network mapping
+
+After an subnet is created in the network mapping looks like this.
+
+.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-subnet-example.png
+
+ Neutron subnet mapping
+
+If an Neutron port is created in the subnet an endpoint and l3-endpoint are
+created. The endpoint has key composed from l2-bridge-domain and MAC address
+from Neutron port. A key of l3-endpoint is compesed from l3-context and IP
+address. The network containment of endpoint and l3-endpoint points to the
+subnet.
+
+
+.. figure:: images/groupbasedpolicy/neutronmapper-gbp-mapping-port-example.png
+
+ Neutron port mapping
+
+Configuring GBP Neutron
+-----------------------
+
+No intervention passed initial OpenStack setup is required by the user.
+
+More information about configuration can be found in our DevStack demo
+environment on the `GBP wiki <gbp_wiki_>`_.
+
+Administering or Managing GBP Neutron
+-------------------------------------
+
+For consistencies sake, all provisioning should be performed via the Neutron API. (CLI or Horizon).
+
+The mapped policies can be augmented via the **GBP** UX,UX, to:
+
+* Enable Service Function Chaining
+* Add endpoints from outside of Neutron i.e. VMs/containers not provisioned in OpenStack
+* Augment policies/contracts derived from Security Group Rules
+* Overlay additional contracts or groupings
+
+Tutorials
+---------
+
+A DevStack demo environment can be found on the
+`GBP wiki <gbp_wiki_>`_.
+
+.. _gbp_wiki: https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)
+.. _neutron_v2api: http://developer.openstack.org/api-ref-networking-v2.html
--- /dev/null
+OpenStack with OVSDB
+====================
+
+**Prerequisites**: OpenDaylight requires Java 1.7.0.
+
+* On the control host, `Download
+ the latest OpenDaylight release <ODL_Downloads_>`_ (at the time of writing,
+ this is Beryllium-SR2)
+* Uncompress it as root, and start OpenDaylight (you can start OpenDaylight
+ by running karaf directly, but exiting from the shell will shut it down):
+
+.. code-block:: bash
+
+ tar xvfz distribution-karaf-0.4.2-Beryllium-SR2.tar.gz
+ cd distribution-karaf-0.4.2-Beryllium-SR2
+ ./bin/start # Start OpenDaylight as a server process
+
+* Connect to the Karaf shell, and install the odl-ovsdb-openstack bundle,
+ dlux and their dependencies:
+
+.. code-block:: bash
+
+ ./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:: images/dlux-default.png
+
+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
+
+.. code-block:: bash
+
+ nova list
+ nova delete <instance names>
+
+* Remove link from subnets to routers
+
+.. code-block:: bash
+
+ 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
+
+.. code-block:: bash
+
+ 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
+
+.. code-block:: bash
+
+ 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
+
+.. code-block:: bash
+
+ 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:
+
+.. code-block:: bash
+
+ 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)
+
+.. code-block:: bash
+
+ 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:
+
+.. code-block:: bash
+
+ [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
+
+.. code-block:: bash
+
+ 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:
+
+.. code-block:: bash
+
+ [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:
+
+.. code-block:: bash
+
+ 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:: images/dlux-with-switches.png
+
+* 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:
+
+.. code-block:: bash
+
+ 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:
+
+.. code-block:: bash
+
+ 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
+
+.. code-block:: bash
+
+ 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:
+
+.. code-block:: bash
+
+ systemctl start neutron-server
+
+
+Verifying it works
+------------------
+
+* Verify that OpenDaylight's ML2 interface is working:
+
+.. code-block:: bash
+
+ 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:
+
+.. code-block:: bash
+
+ 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!
+
+
+.. _ODL_Downloads: https://www.opendaylight.org/software/downloads
--- /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.
+
+.. figure:: images/vtn/OpenStackDeveloperGuide.png
+
+ OpenStack Architecture
+
+Configure OpenStack to work with OpenDaylight(VTN Feature) using PackStack
+--------------------------------------------------------------------------
+
+Prerequisites to install OpenStack using PackStack
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+* Fresh CentOS 7.1 minimal install
+* Use the below commands to disable and remove Network Manager in CentOS 7.1,
+
+.. code-block:: bash
+
+ systemctl stop NetworkManager
+ systemctl disable NetworkManager
+
+* To make SELINUX as permissive, please open the file "/etc/sysconfig/selinux" and change it as "SELINUX=permissive".
+* After making selinux as permissive, please restart the CentOS 7.1 machine.
+
+Steps to install OpenStack PackStack in CentOS 7.1
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+* To install OpenStack juno, use the following command,
+
+.. code-block:: bash
+
+ yum update -y
+ yum -y install https://repos.fedorapeople.org/repos/openstack/openstack-juno/rdo-release-juno-1.noarch.rpm
+
+
+* To install the packstack installer, please use the below command,
+
+.. code-block:: bash
+
+ yum -y install openstack-packstack
+
+* To create all-in-one setup, please use the below command,
+
+.. code-block:: bash
+
+ packstack --allinone --provision-demo=n --provision-all-in-one-ovs-bridge=n
+
+* This will end up with Horizon started successfully message.
+
+Steps to install and deploy OpenDaylight in CentOS 7.1
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+* Download the latest Lithium distribution code in the below link,
+
+.. code-block:: bash
+
+ wget https://nexus.opendaylight.org/content/groups/public/org/opendaylight/integration/distribution-karaf/0.3.4-Lithium-SR4/distribution-karaf-0.3.4-Lithium-SR4.zip
+
+
+* Unzip the lithium distribution code by using the below command,
+
+.. code-block:: bash
+
+ unzip distribution-karaf-0.3.4-Lithium-SR4.zip
+
+* Please do the below steps in the OpenDaylight to change jetty port,
+
+ * Change the jetty port from 8080 to something else as swift proxy of
+ OpenStack is using it.
+ * Open the file "etc/jetty.xml" and change the jetty port from 8080 to 8910
+ (we have used 8910 as jetty port you can use any other number).
+ * Start VTN Manager and install odl-vtn-manager-neutron in it.
+ * Ensure all the required ports(6633/6653,6640 and 8910) are in the listen
+ mode by using the command "netstat -tunpl" in OpenDaylight.
+
+Steps to reconfigure OpenStack in CentOS 7.1
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+* Steps to stop Open vSwitch Agent and clean up ovs
+
+.. code-block:: bash
+
+ sudo systemctl stop neutron-openvswitch-agent
+ sudo systemctl disable neutron-openvswitch-agent
+ sudo systemctl stop openvswitch
+ sudo rm -rf /var/log/openvswitch/*
+ sudo rm -rf /etc/openvswitch/conf.db
+ sudo systemctl start openvswitch
+ sudo ovs-vsctl show
+
+
+* Stop Neutron Server
+
+.. code-block:: bash
+
+ systemctl stop neutron-server
+
+
+* Verify that OpenDaylight's ML2 interface is working:
+
+.. code-block:: bash
+
+ curl -v admin:admin http://{CONTROL_HOST}:{PORT}/controller/nb/v2/neutron/networks
+
+ {
+ "networks" : [ ]
+ }
+
+If this does not work or gives an error, check Neutron's log file in
+*/var/log/neutron/server.log*. Error messages here should give
+some clue as to what the problem is in the connection with OpenDaylight
+
+* Configure Neutron to use OpenDaylight's ML2 driver:
+
+.. code-block:: bash
+
+ sudo crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 mechanism_drivers opendaylight
+ sudo crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 tenant_network_types local
+ sudo crudini --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 type_drivers local
+ sudo crudini --set /etc/neutron/dhcp_agent.ini DEFAULT ovs_use_veth True
+
+ cat <<EOT | sudo tee -a /etc/neutron/plugins/ml2/ml2_conf.ini > /dev/null
+ [ml2_odl]
+ password = admin
+ username = admin
+ url = http://{CONTROL_HOST}:{PORT}/controller/nb/v2/neutron
+ EOT
+
+* Reset Neutron's ML2 database
+
+.. code-block:: bash
+
+ sudo mysql -e "drop database if exists neutron_ml2;"
+ sudo mysql -e "create database neutron_ml2 character set utf8;"
+ sudo mysql -e "grant all on neutron_ml2.* to 'neutron'@'%';"
+ sudo neutron-db-manage --config-file /usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini upgrade head
+
+* Start Neutron Server
+
+.. code-block:: bash
+
+ sudo systemctl start neutron-server
+
+* Restart the Neutron DHCP service
+
+.. code-block:: bash
+
+ system restart neutron-dhcp-agent.service
+
+* At this stage, your Open vSwitch configuration should be empty:
+
+.. code-block:: bash
+
+ [root@dneary-odl-compute2 ~]# ovs-vsctl show
+ 686989e8-7113-4991-a066-1431e7277e1f
+ ovs_version: "2.3.1"
+
+
+* Set OpenDaylight as the manager on all nodes
+
+.. code-block:: bash
+
+ ovs-vsctl set-manager tcp:127.0.0.1:6640
+
+
+* You should now see a section in your Open vSwitch configuration
+ showing that you are connected to the OpenDaylight server, and OpenDaylight
+ will automatically create a br-int bridge:
+
+.. code-block:: bash
+
+ [root@dneary-odl-compute2 ~]# ovs-vsctl show
+ 686989e8-7113-4991-a066-1431e7277e1f
+ Manager "tcp:127.0.0.1:6640"
+ is_connected: true
+ Bridge br-int
+ Controller "tcp:127.0.0.1:6633"
+ is_connected: true
+ fail_mode: secure
+ Port "ens33"
+ Interface "ens33"
+ ovs_version: "2.3.1"
+
+* Add the default flow to OVS to forward packets to controller when there is a table-miss,
+
+.. code-block:: bash
+
+ ovs-ofctl --protocols=OpenFlow13 add-flow br-int priority=0,actions=output:CONTROLLER
+
+* Please see the `VTN OpenStack PackStack support guide <VTN_OpenStack_PackStack_>`_
+ on the wiki to create VM's from OpenStack Horizon GUI.
+
+Implementation details
+----------------------
+
+VTN Manager
+^^^^^^^^^^^
+Install **odl-vtn-manager-neutron** feature which provides the integration with
+Neutron interface.
+
+.. code-block:: bash
+
+ feature:install odl-vtn-manager-neutron
+
+It subscribes to the events from Open vSwitch and also implements the Neutron
+requests received by OpenDaylight.
+
+Functional Behavior
+^^^^^^^^^^^^^^^^^^^
+
+**StartUp**
+
+* The ML2 implementation for OpenDaylight will ensure that when Open vSwitch is
+ started, the ODL_IP_ADDRESS configured will be set as manager.
+* When OpenDaylight receives the update of the Open vSwitch on port 6640
+ (manager port), VTN Manager handles the event and adds a bridge with required
+ port mappings to the Open vSwitch at the OpenStack node.
+* When Neutron starts up, a new network create is POSTed to OpenDaylight, for
+ which VTN Manager creates a Virtual Tenant Network.
+* *Network and Sub-Network Create:* Whenever a new sub network is created, VTN
+ Manager will handle the same and create a vbridge under the VTN.
+* *VM Creation in OpenStack:* The interface mentioned as integration bridge in
+ the configuration file will be added with more interfaces on creation of a
+ new VM in OpenStack and the network is provisioned for it by the VTN Neutron
+ feature. The addition of a new port is captured by the VTN Manager and it
+ creates a vbridge interface with port mapping for the particular port. When
+ the VM starts to communicate with other VMs, the VTN Manger will install flows
+ in the Open vSwitch and other OpenFlow switches to facilitate communication
+ between them.
+
+.. note::
+
+ To use this feature, VTN feature should be installed
+
+Reference
+---------
+
+https://wiki.opendaylight.org/images/5/5c/Integration_of_vtn_and_ovsdb_for_helium.pdf
+
+
+.. _VTN_OpenStack_PackStack: https://wiki.opendaylight.org/view/Release/Lithium/VTN/User_Guide/Openstack_Packstack_Support
--- /dev/null
+Subproject commit 50ad196c90755bc55cedc0769f63c3c3e192332a
--- /dev/null
+== BGP Monitoring Protocol Developer Guide
+
+=== Overview
+This section provides an overview of *feature odl-bgpcep-bmp*. This
+feature will install everything needed for BMP (BGP Monitoring Protocol)
+including establishing the connection, processing messages, storing
+information about monitored routers, peers and their Adj-RIB-In
+(unprocessed routing information) and Post-Policy Adj-RIB-In
+and displaying data in BGP RIBs overview.
+The OpenDaylight BMP plugin plays the role of a monitoring station.
+
+=== Key APIs and Interfaces
+
+==== Session handling
+
+_32-bmp.xml_ defines only bmp-dispatcher the parser should be
+using (global-bmp-extensions).
+
+[source,xml]
+----
+ <module>
+ <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">prefix:bmp-dispatcher-impl</type>
+ <name>global-bmp-dispatcher</name>
+ <bmp-extensions>
+ <type xmlns:bmp-spi="urn:opendaylight:params:xml:ns:yang:controller:bmp:spi">bmp-spi:extensions</type>
+ <name>global-bmp-extensions</name>
+ </bmp-extensions>
+ <boss-group>
+ <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-threadgroup</type>
+ <name>global-boss-group</name>
+ </boss-group>
+ <worker-group>
+ <type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-threadgroup</type>
+ <name>global-worker-group</name>
+ </worker-group>
+ </module>
+----
+
+For user configuration of BMP, check User Guide.
+
+==== Parser
+
+The base BMP parser includes messages and attributes from
+https://tools.ietf.org/html/draft-ietf-grow-bmp-15
+
+==== Registration
+
+All parsers and serializers need to be registered
+into _Extension provider_. This _Extension provider_ is configured in
+initial configuration of the parser (_32-bmp.xml_).
+
+[source,xml]
+----
+ <module>
+ <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bmp:spi">prefix:bmp-extensions-impl</type>
+ <name>global-bmp-extensions</name>
+ <extension>
+ <type xmlns:bmp-spi="urn:opendaylight:params:xml:ns:yang:controller:bmp:spi">bmp-spi:extension</type>
+ <name>bmp-parser-base</name>
+ </extension>
+ </module>
+----
+
+* _bmp-parser-base_ - will register parsers and serializers
+implemented in bmp-impl module
+
+==== Parsing
+
+Parsing of BMP elements is mostly done equally to BGP. Some of the BMP messages includes wrapped
+BGP messages.
+
+==== BMP Monitoring Station
+
+The BMP application (Monitoring Station) serves as message processor incoming from monitored routers.
+The processed message is transformed and relevant information is stored. Route information is stored in a BGP
+RIB data structure.
+
+BMP data is displayed only through one URL that is accessible from the base BMP URL:
+
+_http://<controllerIP>:8181/restconf/operational/bmp-monitor:bmp-monitor_
+
+Each Monitor station will be displayed and it may contains multiple monitored routers and peers within:
+
+[source,xml]
+----
+<bmp-monitor xmlns="urn:opendaylight:params:xml:ns:yang:bmp-monitor">
+ <monitor>
+ <monitor-id>example-bmp-monitor</monitor-id>
+ <router>
+ <router-id>127.0.0.11</router-id>
+ <status>up</status>
+ <peer>
+ <peer-id>20.20.20.20</peer-id>
+ <as>72</as>
+ <type>global</type>
+ <peer-session>
+ <remote-port>5000</remote-port>
+ <timestamp-sec>5</timestamp-sec>
+ <status>up</status>
+ <local-address>10.10.10.10</local-address>
+ <local-port>220</local-port>
+ </peer-session>
+ <pre-policy-rib>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <ipv4-route>
+ <prefix>10.10.10.0/24</prefix>
+ <attributes>
+ ...
+ </attributes>
+ </ipv4-route>
+ </ipv4-routes>
+ <attributes>
+ <uptodate>true</uptodate>
+ </attributes>
+ </tables>
+ </pre-policy-rib>
+ <address>10.10.10.10</address>
+ <post-policy-rib>
+ ...
+ </post-policy-rib>
+ <bgp-id>20.20.20.20</bgp-id>
+ <stats>
+ <timestamp-sec>5</timestamp-sec>
+ <invalidated-cluster-list-loop>53</invalidated-cluster-list-loop>
+ <duplicate-prefix-advertisements>16</duplicate-prefix-advertisements>
+ <loc-rib-routes>100</loc-rib-routes>
+ <duplicate-withdraws>11</duplicate-withdraws>
+ <invalidated-as-confed-loop>55</invalidated-as-confed-loop>
+ <adj-ribs-in-routes>10</adj-ribs-in-routes>
+ <invalidated-as-path-loop>66</invalidated-as-path-loop>
+ <invalidated-originator-id>70</invalidated-originator-id>
+ <rejected-prefixes>8</rejected-prefixes>
+ </stats>
+ </peer>
+ <name>name</name>
+ <description>description</description>
+ <info>some info;</info>
+ </router>
+ </monitor>
+</bmp-monitor>
+</source>
+----
+
+=== API Reference Documentation
+Javadocs are generated while creating mvn:site
+and they are located in target/ directory in each module.
include::bgpcep/odl-bgpcep-bgp-all-dev.adoc[BGP]
+include::bgpcep/odl-bgpcep-bmp-dev.adoc[BGP]
+
include::capwap/capwap-dev.adoc[CAPWAP]
include::controller/controller.adoc[Controller]
include::sfc/sfc.adoc[]
+include::snmp4sdn/snmp4sdn-developer.adoc[SNMP4SDN]
+
include::sxp/odl-sxp-dev.adoc[]
include::tcpmd5/odl-tcpmd5-all-dev.adoc[TCP-MD5]
--- /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.
+
+.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]
+
== Virtual Tenant Network (VTN)
include::vtn-overview.adoc[VTN Overview]
-
-include::OpenStack_Support-dev.adoc[Openstack Support Developer Guide]
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.
-It is implemented as two major components
-
-* <<_vtn_coordinator,VTN Coordinator>>
-* <<_vtn_manager,VTN Manager>>
-
.VTN Architecture
image::vtn/vtn-overview.png[width=500]
-==== VTN Coordinator
-
-The VTN Coordinator is an external application that provides a REST interface for a user to use the VTN Virtualization. It interacts with VTN Manager plugin to implement the user configuration. It is also capable of multiple controller orchestration. It realizes Virtual Tenant Network (VTN) provisioning in OpenDaylight Controllers (ODC). In the OpenDaylight architecture VTN Coordinator is part of the network application, orchestration and services layer. VTN Coordinator has been implemented as an external application to the OpenDaylight controller. This component is responsible for the VTN virtualization. VTN Coordinator will use the REST interface exposed by the VTN Manger to realize the virtual network using the OpenDaylight controller. It uses OpenDaylight APIs (REST) to construct the virtual network in ODCs. It provides REST APIs for northbound VTN applications and supports virtual networks spanning across multiple ODCs by coordinating across ODCs.
-
-===== Feature Overview
-
-VTN Coordinator doesn't have Karaf features.
+It is implemented as two major components
-For VTN Coordinator REST API, please refer: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Coordinator:RestApi
+* <<_vtn_manager,VTN Manager>>
+* <<_vtn_coordinator,VTN Coordinator>>
==== VTN Manager
-An OpenDaylight Controller 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 ODL controller. VTN Manager is implemented as one plugin to the OpenDaylight controller. 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 ODC Driver component. In addition to the above mentioned role, it also provides an implementation to the OpenStack L2 Network Functions API.
+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
| 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 controller orchestration. +
+(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.
|===
* *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:
-https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-stable-lithium/lastSuccessfulBuild/artifact/manager/northbound/target/site/wsdocs/rest.html
+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 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.
+
+===== Feature Overview
+
+VTN Coordinator doesn't have Karaf features.
-For VTN Java API documentation, please visit: https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-master/lastSuccessfulBuild/artifact/manager/api/target/apidocs/index.html
+For VTN Coordinator REST API, please refer to: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Coordinator:RestApi
-VTN Manager API: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Manager: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]
-=== 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]
\ No newline at end of file
include::ovsdb/ovsdb-install.adoc[]
-include::tsdr/tsdr-h2-install.adoc[]
-
-include::tsdr/tsdr-hbase-install.adoc[]
+include::tsdr/tsdr-installation-guide.adoc[]
include::vtn/vtn-install.adoc[]
+++ /dev/null
-== TSDR H2 Default Datastore Installation Guide
-This document is for the user to install the artifacts that are needed
-for using Time Series Data Repository (TSDR) functionality in the ODL Controller by enabling the default JPA (H2) Datastore. TSDR is new functionality added in OpenDaylight in Lithium Release.
-
-=== Overview
-In Lithium Release the time deries data records of OpenFlow statistics are collected periodically and stored in a persistent store. For non-production usage, the bundled default JPA based datastore (H2) is utilized based on odl-tsdr-all feature installation. The TSDR records get persisted in H2 store in <install folder>/tsdr/ folder by default.
-
-=== Pre Requisites for Installing TSDR with default H2 datastore
-There are no additional pre-requisites for TSDR based on default datastore
-
-=== Preparing for Installation
-No additional steps required for preparation of installing TSDR feature
-
-=== Installing TSDR with default H2 datastore
-Once OpenDaylight distribution is up, from karaf console install the TSDR feature with default datastore (JPA based datastore H2 store used) can be installed by
-
-feature:install odl-tsdr-all
-
-This will install all dependency features (and can take sometime) before returning control to the console.
-
-=== Verifying your Installation
-If the feature install was successful you should be able to see the following tsdr commands added
-
-**tsdr:list
-**tsdr:purgeAll
-
-==== Troubleshooting
-Check the ../data/log/karaf.log for any exception related to TSDR or JPA related features
-
-=== Post Installation Configuration
-The feature installation takes care of automated configuration of the datasource by installing a file in <install folder>/etc named org.ops4j.datasource-metric.cfg. This contains the default location of <install folder>/tsdr where the H2 datastore files are stored. If you want to change the default location of the datastore files to some other location update the last portion of the url property in the org.ops4j.datasource-metric.cfg and then restart the karaf container
-
-=== Upgrading From a Previous Release
-Lithium being the first release supporting TSDR functionality, only fresh installation is possible.However if you want to move to production usage by enabling the store HBase for TSDR usage, you can do it by uninstalling the TSDR with default H2 datastore, restarting the Karaf container and then enabling the TSDR with HBase store as documented in tsdr-hbase-install.doc
-
-=== Uninstalling TSDR with default H2 datastore
-To uninstall the TSDR functionality with the default store, you need to do the following from karaf console
-* feature:uninstall odl-tsdr-all
-* feature:uninstall odl-tsdr-core
-* feature:uninstall odl-tsdr-H2-persistence
-
-Its recommended to restart the Karaf container after uninstallation of the TSDR functionality with the default store
-
+++ /dev/null
-== TSDR HBase Data Store Installation Guide
-This document is for the user to install the artifacts that are needed
-for using HBase Data Store in Time Series Data Repository, which is
-a new feature available in OpenDaylight Lithium release.
-
-=== Overview
-The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a framework for collecting, storing, querying, and maintaining time series data in the OpenDaylight SDN controller. It contains the following services and components:
-
-* Data Collection Service
-* Data Storage Service
-* TSDR Persistence Layer with data stores as plugins
-* TSDR Data Stores
-* Data Query Service
-* Data Aggregation Service
-* Data Purging Service
-
-Data Collection Service handles the collection of time series data into TSDR and hands it over to Data Storage Service. Data Storage Service stores the data into TSDR through TSDR Persistence Layer. TSDR Persistence Layer provides generic Service APIs allowing various data stores to be plugged in. Data Aggregation Service aggregates time series fine-grained raw data into course-grained roll-up data to control the size of the data. Data Purging Service periodically purges both fine-grained raw data and course-granined aggregated data according to user-defined schedules.
-
-
-In Lithium, we implemented Data Collection Service, Data Storage Service, TSDR Persistence Layer, TSDR HBase Data Store, and TSDR H2 Data Store. Among these services and components, time series data is communicated using a common TSDR data model, which is designed and implemented for the abstraction of the time series data commonalities. With these functions, TSDR will be able to collect the data from the data sources and store them into one of the TSDR data stores: either HBase Data Store or H2 Data Store. We also provided a simple query command from Karaf console for the user to retrieve TSDR data from the data stores.
-
-A future release will contain Data Aggregation service, Data Purging Service, and a full-fledged Data Query Service with Norghbound APIs.
-
-
-=== Prerequisites for Installing TSDR HBase Data Store
-The hardware requirements are the same as those for standard ODL controller installation.
-
-The software requirements for TSDR HBase Data Store are as follows:
-
-* The supported operating system for TSDR HBase Data Store is Linux. We do not support TSDR HBase Data Store on Windows.
-* Besides the software that ODL requires, we also require HBase database running on top of Hadoop single node.
-
-=== Preparing for Installation
-Download HBase (version number to be finalized) from the following website.
-
-http://archive.apache.org/dist/hbase/hbase-0.94.15/
-
-
-=== Installing TSDR HBase Data Store
-Installing TSDR HBase Data Store contains two steps:
-
- * Installing HBase server, and
- * Installing TSDR HBase Data Store features from ODL Karaf console.
-
-This installation guide will only cover the first step. For installing TSDR HBase Data Store features, please refer to TSDR HBase Data Store User Guide.
-
-In Lithium, we only support HBase single node running together on the same machine as ODL controller. Therefore, follow the steps to download and install HBase server onto the same box as where ODL controller is running:
-
-* Create a folder in Linux operating system for the HBase server.
-
-For example, create an hbase directory under /usr/lib:
-
- mkdir /usr/lib/hbase
-
-* Unzip the downloaded HBase server tar file.
-
-Run the following command to unzip the installation package:
-
- tar xvf <hbase-installer-name> /usr/lib/hbase
-
-* Make proper changes in hbase-site.xml
-
- .. Under <hbase-install-directory>/conf/, there is a hbase-site.xml. Although it is not recommended, an experience user with HBase canmodify the data directory for hbase server to store the data.
-
- .. Modify the value of the property with name "hbase.rootdir" in the file to reflect the desired file directory for storing hbase data.
-
-The following is an example of the file:
-
- <configuration>
- <property>
- <name>hbase.rootdir</name>
- <value>file:///usr/lib/hbase/data</value>
- </property>
- <property>
- <name>hbase.zookeeper.property.dataDir</name>
- <value>/usr/lib/hbase/zookeeper</value>
- </property>
- </configuration>
-
-
-=== Verifying your Installation
-After the HBase server is properly installed, start hbase server and hbase shell.
-
-.. start hbase server
-
- cd <hbase-installation-directory>
- ./start-hbase.sh
-
-.. start hbase shell
-
- cd <hbase-insatllation-directory>
- ./hbase shell
-
-=== Post Installation Configuration
-Please refer to HBase Data Store User Guide.
-
-=== Upgrading From a Previous Release
-Lithium is the first release of TSDR. Upgrading is not applicable for TSDR Lithium release.
-
-=== Uninstalling HBase Data Store
-To uninstall TSDR HBase Data Store,
-
-.. stop hbase server
-
- cd <hbase-installation-directory>
- ./stop-hbase.sh
-
-.. remove the file directory that contains the HBase server installation.
-
- rm -r <hbase-installation-directory>
--- /dev/null
+== TSDR Installation Guide
+This document is for the user to install the artifacts that are needed
+for using Time Series Data Repository (TSDR) functionality in the ODL
+Controller by enabling either an HSQLDB, HBase, or Cassandra Data Store.
+
+
+=== Overview
+The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a framework for collecting, storing, querying, and maintaining time series data in the OpenDaylight SDN controller. Please refer to the User Guide for the detailed description of the functionality of the project and how to use the corresponding features provided in TSDR.
+
+=== Pre Requisites for Installing TSDR
+The software requirements for TSDR HBase Data Store are as follows:
+
+* In the case when the user chooses HBase or Cassandra data store, besides the software that ODL requires, we also require HBase and Cassandra database running in single node deployment scenario.
+
+No additional software is required for the HSQLDB Data Stores.
+
+=== Preparing for Installation
+* When using HBase data store, download HBase from the following website:
+
+ http://archive.apache.org/dist/hbase/hbase-0.94.15/
+
+* When using Cassandra data store, download Cassandra from the following website:
+
+ http://www.eu.apache.org/dist/cassandra/2.1.10/
+
+* No additional steps are required to install the TSDR HSQL Data Store.
+
+=== Installing TSDR Data Stores
+==== Installing HSQLDB Data Store
+Once OpenDaylight distribution is up, from karaf console install the HSQLDB data store using the following command:
+
+ feature:install odl-tsdr-hsqldb-all
+
+This will install hsqldb related dependency features (and can take sometime) as well as openflow statistics collector before returning control to the console.
+e
+
+==== Installing HBase Data Store
+Installing TSDR HBase Data Store contains two steps:
+
+ * Installing HBase server, and
+ * Installing TSDR HBase Data Store features from ODL Karaf console.
+
+In Beryllium, we only support HBase single node running together on the same machine as OpenDaylight. Therefore, follow the steps to download and install HBase server onto the same machine as where OpenDaylight is running:
+
+* Create a folder in Linux operating system for the HBase server.
+
+For example, create an hbase directory under /usr/lib:
+
+ mkdir /usr/lib/hbase
+
+* Unzip the downloaded HBase server tar file.
+
+Run the following command to unzip the installation package:
+
+ tar xvf <hbase-installer-name> /usr/lib/hbase
+
+* Make proper changes in hbase-site.xml
+
+ .. Under <hbase-install-directory>/conf/, there is a hbase-site.xml. Although it is not recommended, an experienced user with HBase can modify the data directory for hbase server to store the data.
+
+ .. Modify the value of the property with name "hbase.rootdir" in the file to reflect the desired file directory for storing hbase data.
+
+The following is an example of the file:
+
+ <configuration>
+ <property>
+ <name>hbase.rootdir</name>
+ <value>file:///usr/lib/hbase/data</value>
+ </property>
+ <property>
+ <name>hbase.zookeeper.property.dataDir</name>
+ <value>/usr/lib/hbase/zookeeper</value>
+ </property>
+ </configuration>
+
+* start hbase server
+
+ cd <hbase-installation-directory>
+ ./start-hbase.sh
+
+* start hbase shell
+
+ cd <hbase-insatllation-directory>
+ ./hbase shell
+
+* start Karaf console
+
+* install hbase data store feature from Karaf console
+
+ feature:install odl-tsdr-hbase
+
+==== Installing Cassandra Data Store
+Installing TSDR Cassandra Data Store contains two steps:
+
+ * Installing Cassandra server, and
+ * Installing TSDR Cassandra Data Store features from ODL Karaf console.
+
+In Beryllium, we only support Cassadra single node running together on the same machine as OpenDaylight. Therefore, follow these steps to download and install Cassandra server onto the same machine as where OpenDaylight is running:
+
+Install Cassandra (latest stable version) by downloading the zip file and untar the tar ball to cassandra/ directory on the testing machine.
+
+ mkdir cassandra
+ wget http://www.eu.apache.org/dist/cassandra/2.1.10/apache-cassandra-2.1.10-bin.tar.gz[2.1.10 is current stable version, it can vary]
+ mv apache-cassandra-2.1.10-bin.tar.gz cassandra/
+ cd cassandra
+ tar -xvzf apache-cassandra-2.1.10-bin.tar.gz
+
+Start Cassandra from cassandra directory by running:
+
+ ./apache-cassandra-2.1.10/bin/cassandra
+
+Start cassandra shell by running:
+
+ ./apache-cassandra-2.1.10/bin/cqlsh
+
+Start Karaf according to the instructions above.
+
+Install Cassandra data store feature from Karaf console:
+
+ feature:install odl-tsdr-cassandra
+
+=== Verifying your Installation
+
+After the TSDR data store is installed, no matter whether it is HBase data store, Cassandra data store, or HSQLDB data store, the user can verify the installation with the following steps.
+
+* Verify if the following two tsdr commands are available from Karaf console:
+
+** tsdr:list
+** tsdr:purgeAll
+
+* Verify if openflow statisitcs data can be received successfully:
+
+** Run "feature:install odl-tsdr-openflow-statistics-collector" from Karaf.
+
+** Run mininet to connect to ODL controller. For example, use the following command to start a three node topology:
+
+ "mn --topo single,3 --controller 'remote,ip=172.17.252.210,port=6653' --switch ovsk,protocols=OpenFlow13"
+
+** From Karaf console, the user should be able to retrieve the statistics data of OpenFlow statistics data from the console:
+
+ tsdr:list FLOWSTATS
+
+==== Troubleshooting
+Check the ../data/log/karaf.log for any exception related to TSDR features.
+
+==== Post Installation Configuration
+===== Post Installation Configuration for HSQLDB Data Store
+
+The feature installation takes care of automated configuration of the datasource by installing a file in <install folder>/etc named org.ops4j.datasource-metric.cfg. This contains the default location of <install folder>/tsdr where the HSQLDB datastore files are stored. If you want to change the default location of the datastore files to some other location update the last portion of the url property in the org.ops4j.datasource-metric.cfg and then restart the Karaf container.
+
+===== Post Installation Configuration for HBase Data Store
+
+Please refer to HBase Data Store User Guide.
+
+===== Post Installation Configuration for Cassandra Data Store
+
+There is no post configuration for TSDR Cassandra data store.
+
+=== Upgrading From a Previous Release
+The HBase data store was supported in the previous release as well as in this release. However, we do not support data store upgrade for HBase data store.
+The user needs to reinstall TSDR and start to collect data in TSDR HBase datastore after the installation.
+
+HSQLDB and Cassandra are new data stores introduced in this release. Therefore, upgrading from previous release does not apply in these two data store scenarios.
+
+=== Uninstalling TSDR Data Stores
+==== To uninstall TSDR HSQLDB data store
+To uninstall the TSDR functionality with the default store, you need to do the following from karaf console
+
+ feature:uninstall odl-tsdr-hsqldb-all
+ feature:uninstall odl-tsdr-core
+ feature:uninstall odl-tsdr-hsqldb
+ feature:uninstall odl-tsdr-openflow-statistics-collector
+
+It is recommended to restart the Karaf container after the uninstallation of the TSDR functionality with the default store.
+
+==== To uninstall TSDR HBase Data Store
+To uninstall the TSDR functionality with the HBase data store,
+
+* Uninstall HBase data store related features from karaf console
+
+ feature:uninstall odl-tsdr-hbase
+ feature:uninstall odl-tsdr-core
+
+* stop hbase server
+
+ cd <hbase-installation-directory>
+ ./stop-hbase.sh
+
+* remove the file directory that contains the HBase server installation
+
+ rm -r <hbase-installation-directory>
+
+It is recommended to restart the Karaf container after the uninstallation of the TSDR data store.
+==== To uninstall TSDR Cassandra Data Store
+To uninstall the TSDR functionality with the Cassandra store,
+
+* uninstall cassandra data store related features following from karaf console
+
+ feature:uninstall odl-tsdr-cassandra
+ feature:uninstall odl-tsdr-core
+
+* stop cassandra database
+
+ ps auwx | grep cassandra
+ sudo kill pid
+
+* remove the cassandra installation files
+
+ rm <cassandra-installation-directory>
+
+It is recommended to restart the Karaf container after uninstallation of the TSDR data store.
* <<_vtn_coordinator,VTN Coordinator>>
==== VTN Manager
-An OpenDaylight Controller 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 ODL controller. VTN Manager is implemented as one plugin to the OpenDaylight controller. 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 ODC Driver component. In addition to the above mentioned role, it also provides an implementation to the OpenStack L2 Network Functions API.
+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.
==== VTN Coordinator
-The VTN Coordinator is an external application that provides a REST interface for a user to use the VTN Virtualization. It interacts with VTN Manager plugin to implement the user configuration. It is also capable of multiple controller orchestration. It realizes Virtual Tenant Network (VTN) provisioning in OpenDaylight Controllers (ODC). In the OpenDaylight architecture VTN Coordinator is part of the network application, orchestration and services layer. VTN Coordinator has been implemented as an external application to the OpenDaylight controller. This component is responsible for the VTN virtualization. VTN Coordinator will use the REST interface exposed by the VTN Manger to realize the virtual network using the OpenDaylight controller. It uses OpenDaylight APIs (REST) to construct the virtual network in ODCs. It provides REST APIs for northbound VTN applications and supports virtual networks spanning across multiple ODCs by coordinating across ODCs.
+The VTN Coordinator is an external application that provides a REST interface for an user to use OpenDaylight VTN Virtualization. It interacts with VTN Manager plugin to implement the user configuration. It is also capable of multiple OpenDaylight orchestration. It realizes 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.
=== Preparing for Installation
==== VTN Coordinator
* Arrange a physical/virtual server with any one of the supported 64-bit OS environment.
-** RHEL 6 / 7
-** CentOS 6 / 7
+** RHEL 7
+** CentOS 7
** Fedora 20 / 21 / 22
* Install these packages
- yum install perl-Digest-SHA uuid libxslt libcurl unixODBC json-c
+ yum install perl-Digest-SHA uuid libxslt libcurl unixODBC json-c bzip2
rpm -ivh http://yum.postgresql.org/9.3/redhat/rhel-6-x86_64/pgdg-redhat93-9.3-1.noarch.rpm
Install Feature
- feature:install odl-vtn-manager-rest odl-vtn-manager-neutron
+ feature:install odl-vtn-manager-neutron odl-vtn-manager-rest
NOTE: The above command will install all features of VTN Manager.
You can install only REST or Neutron also.
==== VTN Coordinator
-* Enter into the externalapps directory in the top directory of Lithium
+* Enter into the externalapps directory in the top directory of Beryllium
- cd distribution-karaf-0.2.1-Lithium-SR1/externalapps
+ cd distribution-karaf-0.4.0-Beryllium/externalapps
* Run the below command to extract VTN Coordinator from the tar.bz2 file in the externalapps directory.
- tar –C/ -jxvf distribution.vtn-coordinator-6.0.0.1-Lithium-SR1-bin.tar.bz2
+ tar –C/ -jxvf distribution.vtn-coordinator-6.2.0-Beryllium-bin.tar.bz2
This will install VTN Coordinator to /usr/local/vtn directory.
The name of the tar.bz2 file name varies depending on the version. Please give the same tar.bz2 file name which is there in your directory.
* In the karaf prompt, type the below command to ensure that vtn packages are installed.
- feature:list i | grep vtn
+ feature:list | grep vtn
* Run any VTN Manager REST API
- curl --user "admin":"admin" -H "Accept: application/json" -H \"Content-type: application/json" -X GET \http://localhost:8282/controller/nb/v2/vtn/default/vtns
+ curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns
==== VTN Coordinator
* This will end up with Horizon started successfully message.
===== Steps to install and deploy OpenDaylight in CentOS 7.1
-* Download the latest lithium distribution code in the below link,
+* Download the latest Beryllium distribution code in the below link,
+
....
-# wget https://nexus.opendaylight.org/content/groups/public/org/opendaylight/integration/distribution-karaf/0.3.1-Lithium-SR1/distribution-karaf-0.3.1-Lithium-SR1.zip
+# 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 lithium distribution code by using the below command,
+* Unzip the Beryllium distribution code by using the below command,
+
....
-# unzip distribution-karaf-0.3.1-Lithium-SR1.zip
+# unzip distribution-karaf-0.4.0-Beryllium-SR1.zip
....
+
* Please do the below steps in the OpenDaylight to change jetty port,
ovs-ofctl --protocols=OpenFlow13 add-flow br-int priority=0,actions=output:CONTROLLER
....
+
-* Please see the https://wiki.opendaylight.org/view/Release/Lithium/VTN/User_Guide/Openstack_Packstack_Support[VTN OpenStack PackStack support guide on the wiki] to create VM's from OpenStack Horizon GUI.
+* 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
<tag>HEAD</tag>
</scm>
<properties>
- <nexusproxy>http://nexus.opendaylight.org/content</nexusproxy>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<modules>
--- /dev/null
+== BGP Monitoring Protocol User Guide ==
+
+=== Overview ===
+
+The OpenDaylight Karaf distribution comes preconfigured with baseline BMP configuration.
+
+- *32-bmp.xml* (initial configuration for BMP messages handler service provider and BMP client/server dispatcher settings)
+- *42-bmp-example.xml* (sample initial configuration for the BMP Monitoring Station application)
+
+=== Configuring BMP ===
+
+==== Server Binding ====
+The default shipped configuration will start a BMP server on 0.0.0.0:12345.You can change this behavior in *42-bmp-example.xml*:
+
+[source,xml]
+----
+ <module>
+ <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">prefix:bmp-monitor-impl</type>
+ <name>example-bmp-monitor</name>
+ <!--<binding-address>0.0.0.0</binding-address>-->
+ <binding-port>12345</binding-port>
+ ...
+ </module>
+----
+
+- *binding-address* - adress on which BMP will be started and listen; to change value, uncomment then line first
+- *binding-port* - port on which the address will be started and listen
+
+Multiple instances of the BMP monitoring station (*bmp-monitor-impl* module) can be created. However, each instance must have a unique pair of *binding-address* and *binding-port*
+
+==== Active mode ====
+OpenDaylight's BMP might be configured to act as an active party of the connection (ODL BMP < = > Monitored router). To enable this functionality,
+configure monitored-router with mandatory parameters:
+
+* address (must be unique for each configured "monitored-router"),
+* port,
+* active.
+
+See following example from 42-bmp-example.xml:
+
+[source,xml]
+----
+ <monitored-router>
+ <address>192.0.2.2</address>
+ <port>1234</port>
+ <active>true</active>
+ </monitored-router>
+----
+
+=== Configuration through RESTCONF ===
+
+==== Server Binding ====
+
+*URL:*
+_http://<controllerIP>:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/config:module/odl-bmp-impl-cfg:bmp-monitor-impl/example-bmp-monitor_
+
+*Content-Type:*
+application/xml
+
+*Method:*
+PUT
+
+*Body:*
+[source,xml]
+----
+<module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
+ <name>example-bmp-monitor</name>
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">x:bmp-monitor-impl</type>
+ <bmp-dispatcher xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">
+ <type>bmp-dispatcher</type>
+ <name>global-bmp-dispatcher</name>
+ </bmp-dispatcher>
+ <codec-tree-factory xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">x:binding-codec-tree-factory</type>
+ <name>runtime-mapping-singleton</name>
+ </codec-tree-factory>
+ <extensions xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:spi">x:extensions</type>
+ <name>global-rib-extensions</name>
+ </extensions>
+ <binding-address xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">0.0.0.0</binding-address>
+ <dom-data-provider xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">x:dom-async-data-broker</type>
+ <name>pingpong-broker</name>
+ </dom-data-provider>
+ <binding-port xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">12345</binding-port>
+</module>
+----
+
+* change values for *binding-address* and/or *binding-port*
+
+==== Active mode ====
+
+*URL:*
+_http://<controllerIP>:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/config:module/odl-bmp-impl-cfg:bmp-monitor-impl/example-bmp-monitor_
+
+*Content-Type:*
+application/xml
+
+*Method:*
+PUT
+
+*Body:*
+[source,xml]
+----
+<module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
+ <name>example-bmp-monitor</name>
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">x:bmp-monitor-impl</type>
+ <bmp-dispatcher xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">
+ <type>bmp-dispatcher</type>
+ <name>global-bmp-dispatcher</name>
+ </bmp-dispatcher>
+ <codec-tree-factory xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">x:binding-codec-tree-factory</type>
+ <name>runtime-mapping-singleton</name>
+ </codec-tree-factory>
+ <extensions xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:spi">x:extensions</type>
+ <name>global-rib-extensions</name>
+ </extensions>
+ <binding-address xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">0.0.0.0</binding-address>
+ <dom-data-provider xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">x:dom-async-data-broker</type>
+ <name>pingpong-broker</name>
+ </dom-data-provider>
+ <binding-port xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">12345</binding-port>
+ <monitored-router xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">
+ <address xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">127.0.0.1</address>
+ <port xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">1234</port>
+ <active xmlns="urn:opendaylight:params:xml:ns:yang:controller:bmp:impl">true</active>
+ </monitored-router>
+</module>
+----
+
+* change values for *address* and *port*
include::bgpcep/odl-bgpcep-bgp-all-user.adoc[BGP]
+include::bgpcep/odl-bgpcep-bmp-user.adoc[BMP]
+
include::capwap/capwap-user.adoc[CAPWAP]
include::didm/didm-user.adoc[]
include::snmp/snmp-user-guide.adoc[SNMP]
+include::snmp4sdn/snmp4sdn-user-guide.adoc[SNMP4SDN]
+
include::sxp/odl-sxp-user.adoc[]
include::tcpmd5/odl-tcpmd5-all-user.adoc[TCP-MD5]
-include::tsdr/tsdr-h2-user.adoc[]
-
-include::tsdr/tsdr-hbase-user.adoc[]
+include::tsdr/tsdr-user-guide.adoc[]
include::ttp/ttp-cli-tools-user.adoc[TTP]
+include::unimgr/unimgr-user.adoc[]
+
include::usc/odl-usc-channel-user.adoc[USC]
include::vtn/vtn-user.adoc[]
-=== SFC OpenFlow Layer 2 Renderer User Guide
+=== SFC OpenFlow Renderer User Guide
==== Overview
-The Service Function Chaining (SFC) OpenFlow Layer 2 Renderer (SFCOFL2)
+The Service Function Chaining (SFC) OpenFlow Renderer (SFCOFL2)
implements Service Chaining on OpenFlow switches. It listens for the
creation of a Rendered Service Path (RSP), and once received it programs
Service Function Forwarders (SFF) that are hosted on OpenFlow capable
==== SFC OpenFlow Switch Flow pipeline
The SFC OpenFlow Renderer uses the following tables for its Flow pipeline:
-* Table 0, Transport Ingress
-* Table 1, Path Mapper
-* Table 2, Next Hop
+* Table 0, Classifier
+* Table 1, Transport Ingress
+* Table 2, Path Mapper
+* Table 3, Path Mapper ACL
+* Table 4, Next Hop
* Table 10, Transport Egress
The OpenFlow Table Pipeline is intended to be generic to work for
.SFC OpenFlow Renderer Typical Network Topology
image::sfc/sfcofl2_architecture_nwtopo.jpg["SFC OpenFlow Renderer Typical Network Topology",width=500]
+===== Classifier Table detailed
+
+It is possible for the SFF to also act as a classifier. This table maps subscriber
+traffic to RSPs, and is explained in detail in the classifier documentation.
+
+If the SFF is not a classifier, then this table will just have a simple Goto
+Table 1 flow.
===== Transport Ingress Table detailed
type to be received in a particular SFF, as established in the SFC
configuration.
-Here is an example on SFF1, assuming VLAN is used for the SFF-SF, and the RSP
-tunnel is MPLS:
+Here are two example on SFF1: one where the RSP ingress tunnel is MPLS assuming
+VLAN is used for the SFF-SF, and the other where the RSP ingress tunnel is NSH
+GRE (UDP port 4789):
.Table Transport Ingress
+[width=60%]
|===
|Priority |Match | Action
|256
|EtherType==0x8847 (MPLS unicast)
-|Goto Table 1
+|Goto Table 2
|256
|EtherType==0x8100 (VLAN)
-|Goto Table 1
+|Goto Table 2
+
+|256
+|EtherType==0x0800,udp,tp_dst==4789 (IP v4)
+|Goto Table 2
|5
|Match Any
The Path Mapper table has an entry per expected tunnel transport info
to be received in a particular SFF, as established in the SFC
configuration. The tunnel transport info is used to determine the
-RSP Path ID, and is stored in the OpenFlow Metadata.
+RSP Path ID, and is stored in the OpenFlow Metadata. This table is not
+used for NSH, since the RSP Path ID is stored in the NSH header.
-Since most SF nodes wont support tunneling, the IP header DSCP field is
+For SF nodes that do not support NSH tunneling, the IP header DSCP field is
used to store the RSP Path Id. The RSP Path Id is written to the DSCP
field in the Transport Egress table for those packets sent to an SF.
* The RSP Path 2 (symmetric downlink path) uses MPLS label 101 for ingress and 100 for egress
.Table Path Mapper
+[width=60%]
|===
|Priority |Match | Action
|256
|MPLS Label==100
-|RSP Path=1, Pop MPLS, Goto Table 2
+|RSP Path=1, Pop MPLS, Goto Table 4
|256
|MPLS Label==101
-|RSP Path=2, Pop MPLS, Goto Table 2
+|RSP Path=2, Pop MPLS, Goto Table 4
|256
|VLAN ID==1000, IP DSCP==1
-|RSP Path=1, Pop VLAN, Goto Table 2
+|RSP Path=1, Pop VLAN, Goto Table 4
|256
|VLAN ID==1000, IP DSCP==2
-|RSP Path=2, Pop VLAN, Goto Table 2
+|RSP Path=2, Pop VLAN, Goto Table 4
|5
|Match Any
-|Drop
+|Goto Table 3
|===
-===== Next Hop Table detailed
-The Next Hop table uses the RSP Path Id and source MAC address to
-determine the destination MAC address.
+===== Path Mapper ACL Table detailed
+This table is only populated when PacketIn packets are received from the switch
+for TcpProxy type SFs. These flows are created with an inactivity timer of 60
+seconds and will be automatically deleted upon expiration.
-Here is an example on SFF1, assuming SFF1 is connected to SFF2 and
-RSP Path 1 ingress packets come from external to SFC, for which
-we don’t have the source MAC address (MacSrc).
+===== Next Hop Table detailed
+The Next Hop table uses the RSP Path Id and appropriate packet fields to
+determine where to send the packet next. For NSH, only the NSP (Network
+Services Path, RSP ID) and NSI (Network Services Index, next hop) fields
+from the NSH header are needed to determine the VXLAN tunnel destination
+IP. For VLAN or MPLS, then the source MAC address is used to determine
+the destination MAC address.
+
+Here are two examples on SFF1, assuming SFF1 is connected to SFF2. RSP Paths 1
+and 2 are symmetric VLAN paths. RSP Paths 3 and 4 are symmetric NSH paths.
+RSP Path 1 ingress packets come from external to SFC, for which we don’t have
+the source MAC address (MacSrc).
.Table Next Hop
+[width=75%]
|===
|Priority |Match | Action
|RSP Path==1
|MacDst=SF1, Goto Table 10
+|256
+|nsp=3,nsi=255 (SFF Ingress RSP 3)
+|load:0xa000002->NXM_NX_TUN_IPV4_DST[], Goto Table 10
+
+|256
+|nsp=3,nsi=254 (SFF Ingress from SF, RSP 3)
+|load:0xa00000a->NXM_NX_TUN_IPV4_DST[], Goto Table 10
+
+|256
+|nsp=4,nsi=254 (SFF1 Ingress from SFF2)
+|load:0xa00000a->NXM_NX_TUN_IPV4_DST[], Goto Table 10
+
|5
|Match Any
|Drop
The Transport Egress table prepares egress tunnel information and
sends the packets out.
-Here is an example on SFF1, assuming VLAN is used for the SFF-SF, and the
-RSP tunnel is MPLS:
+Here are two examples on SFF1. RSP Paths 1 and 2 are symmetric MPLS paths that
+use VLAN for the SFF-SF. RSP Paths 3 and 4 are symmetric NSH paths. Since it is
+assumed that switches used for NSH will only have one VXLANport, the NSH
+packets are just sent back where they came from.
.Table Transport Egress
+[width=60%]
|===
|Priority |Match | Action
|RSP Path==2
|Push MPLS Label 100, Port=Ingress
+|256
+|nsp=3,nsi=255 (SFF Ingress RSP 3)
+|IN_PORT
+
+|256
+|nsp=3,nsi=254 (SFF Ingress from SF, RSP 3)
+|IN_PORT
+
+|256
+|nsp=4,nsi=254 (SFF1 Ingress from SFF2)
+|IN_PORT
+
|5
|Match Any
|Drop
To use the SFC OpenFlow Renderer Karaf, at least the following Karaf
features must be installed.
-* odl-openflowplugin-all
-* odl-sfc-core (includes odl-sfc-provider and odl-sfc-model)
+* odl-openflowplugin-nxm-extensions
+* odl-openflowplugin-flow-services
+* odl-sfc-provider
+* odl-sfc-model
* odl-sfcofl2
* odl-sfc-ui (optional)
==== SFCOFL2 Tutorial
===== Overview
-The following Network Topology diagram shows how to configure SFC to
-create a Service Chain.
+In this tutorial, 2 different encapsulations will be shown: MPLS and NSH. The
+following Network Topology diagram is a logical view of the SFFs and SFs involved
+in creating the Service Chains.
.SFC OpenFlow Renderer Typical Network Topology
image::sfc/sfcofl2_architecture_nwtopo.jpg["SFC OpenFlow Renderer Typical Network Topology",width=500]
===== Prerequisites
To use this example, SFF OpenFlow switches must be created and
-connected as illustrated above. Additionally, The SFs must be
-created and connected to the SFFs.
+connected as illustrated above. Additionally, the SFs must be
+created and connected.
===== Target Environment
The target environment is not important, but this use-case was created
-and only tested on Linux.
+and tested on Linux.
===== Instructions
The steps to use this tutorial are as follows. The referenced
configuration in the steps is listed in the following sections.
-There are numerous ways to send the configuration. The following
+There are numerous ways to send the configuration. In the following
configuration chapters, the appropriate `curl` command is shown for
each configuration to be sent, including the URL.
Once the configuration has been successfully created, query the
Rendered Service Paths with either the SFC UI or via RESTCONF.
-Notice that the RSP is symetrical, so the following 2 RSPs will
+Notice that the RSP is symmetrical, so the following 2 RSPs will
be created:
* sfc-path1
string with the appropriate JSON configuration. Also, change the
`localhost` desintation in the URL accordingly.
-====== Service Function configuration
+====== SFCOFL2 NSH Tutorial
+
+The following configuration sections show how to create the different elements
+using NSH encapsulation.
+
+*NSH Service Function configuration* +
+
The Service Function configuration can be sent with the following command:
curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function:service-functions/
"service-function": [
{
"name": "sf1",
- "type": "service-function-type:http-header-enrichment",
+ "type": "http-header-enrichment",
+ "nsh-aware": true,
+ "ip-mgmt-address": "10.0.0.2",
+ "sf-data-plane-locator": [
+ {
+ "name": "sf1dpl",
+ "ip": "10.0.0.10",
+ "port": 4789,
+ "transport": "service-locator:vxlan-gpe",
+ "service-function-forwarder": "sff1"
+ }
+ ]
+ },
+ {
+ "name": "sf2",
+ "type": "firewall",
+ "nsh-aware": true,
+ "ip-mgmt-address": "10.0.0.3",
+ "sf-data-plane-locator": [
+ {
+ "name": "sf2dpl",
+ "ip": "10.0.0.20",
+ "port": 4789,
+ "transport": "service-locator:vxlan-gpe",
+ "service-function-forwarder": "sff2"
+ }
+ ]
+ }
+ ]
+ }
+}
+----
+
+*NSH Service Function Forwarder configuration* +
+
+The Service Function Forwarder configuration can be sent with the
+following command:
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
+
+.SFF configuration JSON
+----
+{
+ "service-function-forwarders": {
+ "service-function-forwarder": [
+ {
+ "name": "sff1",
+ "service-node": "openflow:2",
+ "sff-data-plane-locator": [
+ {
+ "name": "sff1dpl",
+ "data-plane-locator":
+ {
+ "ip": "10.0.0.1",
+ "port": 4789,
+ "transport": "service-locator:vxlan-gpe"
+ }
+ }
+ ],
+ "service-function-dictionary": [
+ {
+ "name": "sf1",
+ "sff-sf-data-plane-locator":
+ {
+ "sf-dpl-name": "sf1dpl",
+ "sff-dpl-name": "sff1dpl"
+ }
+ }
+ ]
+ },
+ {
+ "name": "sff2",
+ "service-node": "openflow:3",
+ "sff-data-plane-locator": [
+ {
+ "name": "sff2dpl",
+ "data-plane-locator":
+ {
+ "ip": "10.0.0.2",
+ "port": 4789,
+ "transport": "service-locator:vxlan-gpe"
+ }
+ }
+ ],
+ "service-function-dictionary": [
+ {
+ "name": "sf2",
+ "sff-sf-data-plane-locator":
+ {
+ "sf-dpl-name": "sf2dpl",
+ "sff-dpl-name": "sff2dpl"
+ }
+ }
+ ]
+ }
+ ]
+ }
+}
+----
+
+*NSH Service Function Chain configuration* +
+
+The Service Function Chain configuration can be sent with the following command:
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-chain:service-function-chains/
+
+.SFC configuration JSON
+----
+{
+ "service-function-chains": {
+ "service-function-chain": [
+ {
+ "name": "sfc-chain1",
+ "symmetric": true,
+ "sfc-service-function": [
+ {
+ "name": "hdr-enrich-abstract1",
+ "type": "http-header-enrichment"
+ },
+ {
+ "name": "firewall-abstract1",
+ "type": "firewall"
+ }
+ ]
+ }
+ ]
+ }
+}
+----
+
+*NSH Service Function Path configuration* +
+
+The Service Function Path configuration can be sent with the following command:
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-path:service-function-paths/
+
+.SFP configuration JSON
+----
+{
+ "service-function-paths": {
+ "service-function-path": [
+ {
+ "name": "sfc-path1",
+ "service-chain-name": "sfc-chain1",
+ "transport-type": "service-locator:vxlan-gpe",
+ "symmetric": true
+ }
+ ]
+ }
+}
+----
+
+*NSH Rendered Service Path creation* +
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X POST --user admin:admin http://localhost:8181/restconf/operations/rendered-service-path:create-rendered-path/
+
+.RSP creation JSON
+----
+{
+ "input": {
+ "name": "sfc-path1",
+ "parent-service-function-path": "sfc-path1",
+ "symmetric": true
+ }
+}
+----
+
+*NSH Rendered Service Path removal* +
+
+The following command can be used to remove a Rendered Service Path
+called `sfc-path1`:
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{"input": {"name": "sfc-path1" } }' -X POST --user admin:admin http://localhost:8181/restconf/operations/rendered-service-path:delete-rendered-path/
+
+*NSH Rendered Service Path Query* +
+
+The following command can be used to query all of the created Rendered Service Paths:
+
+ curl -H "Content-Type: application/json" -H "Cache-Control: no-cache" -X GET --user admin:admin http://localhost:8181/restconf/operational/rendered-service-path:rendered-service-paths/
+
+
+====== SFCOFL2 MPLS Tutorial
+
+The following configuration sections show how to create the different elements
+using MPLS encapsulation.
+
+*MPLS Service Function configuration* +
+
+The Service Function configuration can be sent with the following command:
+
+ curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function:service-functions/
+
+.SF configuration JSON
+----
+{
+ "service-functions": {
+ "service-function": [
+ {
+ "name": "sf1",
+ "type": "http-header-enrichment",
"nsh-aware": false,
"ip-mgmt-address": "10.0.0.2",
"sf-data-plane-locator": [
},
{
"name": "sf2",
- "type": "service-function-type:firewall",
+ "type": "firewall",
"nsh-aware": false,
"ip-mgmt-address": "10.0.0.3",
"sf-data-plane-locator": [
}
----
-====== Service Function Forwarder configuration
+*MPLS Service Function Forwarder configuration* +
+
The Service Function Forwarder configuration can be sent with the
following command:
"mac": "33:33:33:33:33:33",
"port-id" : "2"
}
- }
- ],
- "service-function-dictionary": [
+ },
{
- "name": "sf1",
- "type": "service-function-type:http-header-enrichment",
- "sff-sf-data-plane-locator":
+ "name": "toSf1",
+ "data-plane-locator":
{
"mac": "22:22:22:22:22:22",
"vlan-id": 1000,
- "transport": "service-locator:mac"
+ "transport": "service-locator:mac",
},
"service-function-forwarder-ofs:ofs-port":
{
+ "mac": "33:33:33:33:33:33",
"port-id" : "3"
}
}
+ ],
+ "service-function-dictionary": [
+ {
+ "name": "sf1",
+ "sff-sf-data-plane-locator":
+ {
+ "sf-dpl-name": "sf1-sff1",
+ "sff-dpl-name": "toSf1"
+ }
+ }
]
},
{
"mac": "66:66:66:66:66:66",
"port-id" : "2"
}
+ },
+ {
+ "name": "toSf2",
+ "data-plane-locator":
+ {
+ "mac": "55:55:55:55:55:55",
+ "vlan-id": 2000,
+ "transport": "service-locator:mac"
+ },
+ "service-function-forwarder-ofs:ofs-port":
+ {
+ "port-id" : "3"
+ }
}
],
"service-function-dictionary": [
{
"name": "sf2",
- "type": "service-function-type:firewall",
"sff-sf-data-plane-locator":
{
- "mac": "55:55:55:55:55:55",
- "vlan-id": 2000,
- "transport": "service-locator:mac"
+ "sf-dpl-name": "sf2-sff2",
+ "sff-dpl-name": "toSf2"
+
},
"service-function-forwarder-ofs:ofs-port":
{
}
----
-====== Service Function Chain configuration
+*MPLS Service Function Chain configuration* +
+
The Service Function Chain configuration can be sent with the
following command:
"sfc-service-function": [
{
"name": "hdr-enrich-abstract1",
- "type": "service-function-type:http-header-enrichment"
+ "type": "http-header-enrichment"
},
{
"name": "firewall-abstract1",
- "type": "service-function-type:firewall"
+ "type": "firewall"
}
]
}
}
----
-====== Service Function Path configuration
+*MPLS Service Function Path configuration* +
+
The Service Function Path configuration can be sent with the following
command:
}
----
-====== Rendered Service Path creation
+*MPLS Rendered Service Path creation* +
curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '${JSON}' -X POST --user admin:admin http://localhost:8181/restconf/operations/rendered-service-path:create-rendered-path/
}
----
-====== Rendered Service Path removal
+*MPLS Rendered Service Path removal* +
+
The following command can be used to remove a Rendered Service Path
called `sfc-path1`:
curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{"input": {"name": "sfc-path1" } }' -X POST --user admin:admin http://localhost:8181/restconf/operations/rendered-service-path:delete-rendered-path/
-====== Rendered Service Path Query
+*MPLS Rendered Service Path Query* +
+
The following command can be used to query all of the created Rendered Service Paths:
curl -H "Content-Type: application/json" -H "Cache-Control: no-cache" -X GET --user admin:admin http://localhost:8181/restconf/operational/rendered-service-path:rendered-service-paths/
include::odl-sfc-classifier-user.adoc[SFC Classifier configuration User guide]
-include::odl-sfcofl2-user.adoc[SFC OpenFlow Layer2 Renderer user guide]
+include::odl-sfcofl2-user.adoc[SFC OpenFlow Renderer user guide]
include::odl-sfc-sf-scheduler-user.adoc[Service Function selection scheduler]
--- /dev/null
+== SNMP4SDN User Guide\r
+=== Overview\r
+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.\r
+\r
+.SNMP4SDN as an OpenDaylight southbound plugin \r
+image::snmp4sdn_in_odl_architecture.jpg["SNMP4SDN as an OpenDaylight southbound plugin",width=400]\r
+\r
+=== Configuration\r
+Just follow the steps:\r
+\r
+==== Prepare the switch list database file\r
+A sample is https://wiki.opendaylight.org/view/SNMP4SDN:switch_list_file[here], and we suggest to save it as '/etc/snmp4sdn_swdb.csv' so that SNMP4SDN Plugin can automatically load this file. Note that the first line is title and should not be removed.\r
+\r
+==== Prepare the vendor-specific configuration file\r
+A sample is https://wiki.opendaylight.org/view/SNMP4SDN:snmp4sdn_VendorSpecificSwitchConfig_file[here], and we suggest to save it as '/etc/snmp4sdn_VendorSpecificSwitchConfig.xml' so that SNMP4SDN Plugin can automatically load this file.\r
+\r
+=== Install SNMP4SDN Plugin\r
+If using SNMP4SDN Plugin provided in OpenDaylight release, just do the following from the Karaf CLI:\r
+\r
+----\r
+feature:install odl-snmp4sdn-all\r
+----\r
+\r
+=== Troubleshooting\r
+==== Installation Troubleshooting\r
+===== Feature installation failure\r
+When trying to install a feature, if the following failure occurs:\r
+----\r
+Error executing command: Could not start bundle ... \r
+Reason: Missing Constraint: Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.7))"\r
+----\r
+A workaround: exit Karaf, and edit the file <karaf_directory>/etc/config.properties, remove the line '${services-${karaf.framework}}' and the ", \" in the line above.\r
+\r
+==== Runtime Troubleshooting\r
+===== Problem starting SNMP Trap Interface\r
+It is possible to get the following exception during controller startup. (The error would not be printed in Karaf console, one may see it in <karaf_directory>/data/log/karaf.log)\r
+----\r
+2014-01-31 15:00:44.688 CET [fileinstall-./plugins] WARN o.o.snmp4sdn.internal.SNMPListener - Problem starting SNMP Trap Interface: {}\r
+ java.net.BindException: Permission denied\r
+ at java.net.PlainDatagramSocketImpl.bind0(Native Method) ~[na:1.7.0_51]\r
+ at java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:95) ~[na:1.7.0_51]\r
+ at java.net.DatagramSocket.bind(DatagramSocket.java:376) ~[na:1.7.0_51]\r
+ at java.net.DatagramSocket.<init>(DatagramSocket.java:231) ~[na:1.7.0_51]\r
+ at java.net.DatagramSocket.<init>(DatagramSocket.java:284) ~[na:1.7.0_51]\r
+ at java.net.DatagramSocket.<init>(DatagramSocket.java:256) ~[na:1.7.0_51]\r
+ at org.snmpj.SNMPTrapReceiverInterface.<init>(SNMPTrapReceiverInterface.java:126) ~[org.snmpj-1.4.3.jar:na]\r
+ at org.snmpj.SNMPTrapReceiverInterface.<init>(SNMPTrapReceiverInterface.java:99) ~[org.snmpj-1.4.3.jar:na]\r
+ at org.opendaylight.snmp4sdn.internal.SNMPListener.<init>(SNMPListener.java:75) ~[bundlefile:na]\r
+ at org.opendaylight.snmp4sdn.core.internal.Controller.start(Controller.java:174) [bundlefile:na]\r
+...\r
+----\r
+This indicates that the controller is being run as a user which does not have sufficient OS privileges to bind the SNMPTRAP port (162/UDP)\r
+\r
+==== Switch list file missing\r
+The SNMP4SDN Plugin needs a switch list file, which is necessary for topology discovery and should be provided by the administrator (so please prepare one for the first time using SNMP4SDN Plugin, here is the https://wiki.opendaylight.org/view/SNMP4SDN:switch_list_file[sample]). The default file path is /etc/snmp4sdn_swdb.csv. SNMP4SDN Plugin would automatically load this file and start topology discovery. If this file is not ready there, the following message like this will pop up:\r
+----\r
+2016-02-02 04:21:52,476 | INFO| Event Dispatcher | CmethUtil | 466 - org.opendaylight.snmp4sdn - 0.3.0.SNAPSHOT | CmethUtil.readDB() err: {}\r
+java.io.FileNotFoundException: /etc/snmp4sdn_swdb.csv (No such file or directory)\r
+ at java.io.FileInputStream.open0(Native Method)[:1.8.0_65]\r
+ at java.io.FileInputStream.open(FileInputStream.java:195)[:1.8.0_65]\r
+ at java.io.FileInputStream.<init>(FileInputStream.java:138)[:1.8.0_65]\r
+ at java.io.FileInputStream.<init>(FileInputStream.java:93)[:1.8.0_65]\r
+ at java.io.FileReader.<init>(FileReader.java:58)[:1.8.0_65]\r
+ at org.opendaylight.snmp4sdn.internal.util.CmethUtil.readDB(CmethUtil.java:66)\r
+ at org.opendaylight.snmp4sdn.internal.util.CmethUtil.<init>(CmethUtil.java:43)\r
+...\r
+----\r
+\r
+=== Configuration\r
+Just follow the steps:\r
+\r
+==== 1. Prepare the switch list database file\r
+A sample is https://wiki.opendaylight.org/view/SNMP4SDN:switch_list_file[here], and we suggest to save it as '/etc/snmp4sdn_swdb.csv' so that SNMP4SDN Plugin can automatically load this file.\r
+\r
+NOTE:\r
+The first line is title and should not be removed.\r
+\r
+==== 2. Prepare the vendor-specific configuration file\r
+A sample is https://wiki.opendaylight.org/view/SNMP4SDN:snmp4sdn_VendorSpecificSwitchConfig_file[here], and we suggest to save it as '/etc/snmp4sdn_VendorSpecificSwitchConfig.xml' so that SNMP4SDN Plugin can automatically load this file.\r
+\r
+==== 3. Install SNMP4SDN Plugin\r
+If using SNMP4SDN Plugin provided in OpenDaylight release, just do the following:\r
+\r
+Launch Karaf in Linux console:\r
+----\r
+cd <Beryllium_controller_directory>/bin\r
+(for example, cd distribution-karaf-x.x.x-Beryllium/bin)\r
+----\r
+----\r
+./karaf\r
+----\r
+Then in Karaf console, execute:\r
+----\r
+feature:install odl-snmp4sdn-all\r
+----\r
+\r
+==== 4. Load switch list\r
+For initialization, we need to feed SNMP4SDN Plugin the switch list. Actually SNMP4SDN Plugin automatically try to load the switch list at /etc/snmp4sdn_swdb.csv if there is. If so, this step could be skipped.\r
+In Karaf console, execute:\r
+----\r
+snmp4sdn:ReadDB <switch_list_path>\r
+(For example, snmp4sdn:ReadDB /etc/snmp4sdn_swdb.csv)\r
+(in Windows OS, For example, snmp4sdn:ReadDB D://snmp4sdn_swdb.csv)\r
+----\r
+A sample is https://wiki.opendaylight.org/view/SNMP4SDN:switch_list_file[here], and we suggest to save it as '/etc/snmp4sdn_swdb.csv' so that SNMP4SDN Plugin can automatically load this file. \r
+\r
+NOTE:\r
+The first line is title and should not be removed.\r
+\r
+==== 5. Show switch list\r
+----\r
+snmp4sdn:PrintDB\r
+----\r
+\r
+=== Tutorial\r
+==== Topology Service\r
+===== Execute topology discovery\r
+\r
+The SNMP4SDN Plugin automatically executes topology discovery on startup. One may use the following commands to invoke topology discovery manually. Note that you may need to wait for seconds for itto complete. \r
+\r
+NOTE:\r
+Currently, one needs to manually execute 'snmp4sdn:TopoDiscover' first (just once), then later the automatic topology discovery can be successful. If switches change (switch added or removed), 'snmp4sdn:TopoDiscover' is also required. A future version will fix it to eliminate these requirements.\r
+----\r
+snmp4sdn:TopoDiscover\r
+----\r
+\r
+If one like to discover all inventory (i.e. switches and their ports) but not edges, just execute "TopoDiscoverSwitches":\r
+----\r
+snmp4sdn:TopoDiscoverSwitches\r
+----\r
+\r
+If one like to only discover all edges but not inventory, just execute "TopoDiscoverEdges":\r
+----\r
+snmp4sdn:TopoDiscoverEdges\r
+----\r
+\r
+You can also trigger topology discovery via the REST API by using +curl+ from the Linux console (or any other REST client):\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/topology:rediscover\r
+----\r
+\r
+You can change the periodic topology discovery interval via a REST API:\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/topology:set-discovery-interval -d "{"input":{"interval-second":'<interval_time>'}}" \r
+For example, set the interval as 15 seconds:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/topology:set-discovery-interval -d "{"input":{"interval-second":'15'}}" \r
+----\r
+\r
+===== Show the topology\r
+\r
+SNMP4SDN Plugin supports to show topology via REST API:\r
+\r
+* Get topology\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/topology:get-edge-list\r
+----\r
++\r
+* Get switch list\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/topology:get-node-list\r
+----\r
++\r
+* Get switches' ports list\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/topology:get-node-connector-list\r
+----\r
++\r
+* The three commands above are just for user to get the latest topology discovery result, it does not trigger SNMP4SDN Plugin to do topology discovery.\r
+* To trigger SNMP4SDN Plugin to do topology discover, as described in aforementioned 'Execute topology discovery'.\r
+\r
+==== Flow configuration\r
+\r
+===== FDB configuration\r
+\r
+SNMP4SDN supports to add entry on FDB table via REST API:\r
+\r
+* Get FDB table\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/fdb:get-fdb-table -d "{input:{"node-id":<switch-mac-address-in-number>}}" \r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/fdb:get-fdb-table -d "{input:{"node-id":158969157063648}}" \r
+----\r
++\r
+* Get FDB table entry\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/fdb:get-fdb-entry -d "{input:{"node-id":<switch-mac-address-in-number>, "vlan-id":<vlan-id-in-number>, "dest-mac-addr":<destination-mac-address-in-number>}}" \r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/fdb:get-fdb-entry -d "{input:{"node-id":158969157063648, "vlan-id":1, "dest-mac-addr":158969157063648}}" \r
+----\r
++\r
+* Set FDB table entry\r
++\r
+(Notice invalid value: (1) non unicast mac (2) port not in the VLAN)\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/fdb:set-fdb-entry -d "{input:{"node-id":<switch-mac-address-in-number>, "vlan-id":<vlan-id-in-number>, "dest-mac-addr":<destination-mac-address-in-number>, "port":<port-in-number>, "type":'<type>'}}" \r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/fdb:set-fdb-entry -d "{input:{"node-id":158969157063648, "vlan-id":1, "dest-mac-addr":187649984473770, "port":23, "type":'MGMT'}}" \r
+----\r
++\r
+* Delete FDB table entry\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/fdb:del-fdb-entry -d "{input:{"node-id":<switch-mac-address-in-number>, "vlan-id":<vlan-id-in-number>, "dest-mac-addr":<destination-mac-address-in-number>}}" \r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/fdb:del-fdb-entry -d "{input:{"node-id":158969157063648, "vlan-id":1, "dest-mac-addr":187649984473770}}" \r
+----\r
+\r
+===== VLAN configuration\r
+\r
+SNMP4SDN supports to add entry on VLAN table via REST API:\r
+\r
+* Get VLAN table\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/vlan:get-vlan-table -d "{input:{node-id:<switch-mac-address-in-number>}}" \r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vlan:get-vlan-table -d "{input:{node-id:158969157063648}}" \r
+----\r
++\r
+* Add VLAN\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/vlan:add-vlan -d "{"input":{"node-id":<switch-mac-address-in-number>, "vlan-id":<vlan-id-in-number>, "vlan-name":'<vlan-name>'}}" \r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vlan:add-vlan -d "{"input":{"node-id":158969157063648, "vlan-id":123, "vlan-name":'v123'}}" \r
+----\r
++\r
+* Delete VLAN\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/vlan:delete-vlan -d "{"input":{"node-id":<switch-mac-address-in-number>, "vlan-id":<vlan-id-in-number>}}" \r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vlan:delete-vlan -d "{"input":{"node-id":158969157063648, "vlan-id":123}}" \r
+----\r
++\r
+* Add VLAN and set ports\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/vlan:add-vlan-and-set-ports -d "{"input":{"node-id":<switch-mac-address-in-number>, "vlan-id":<vlan-id-in-number>, "vlan-name":'<vlan-name>', "tagged-port-list":'<tagged-ports-separated-by-comma>', "untagged-port-list":'<untagged-ports-separated-by-comma>'}}" \r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vlan:add-vlan-and-set-ports -d "{"input":{"node-id":158969157063648, "vlan-id":123, "vlan-name":'v123', "tagged-port-list":'1,2,3', "untagged-port-list":'4,5,6'}}" \r
+----\r
++\r
+* Set VLAN ports\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/vlan:set-vlan-ports -d "{"input":{"node-id":<switch-mac-address-in-number>, "vlan-id":<vlan-id-in-number>, "tagged-port-list":'<tagged-ports-separated-by-comma>', "untagged-port-list":'<untagged-ports-separated-by-comma>'}}"\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vlan:set-vlan-ports -d "{"input":{"node-id":"158969157063648", "vlan-id":"123", "tagged-port-list":'4,5', "untagged-port-list":'2,3'}}"\r
+----\r
+\r
+===== ACL configuration\r
+\r
+SNMP4SDN supports to add flow on ACL table via REST API. However, it is so far only implemented for the D-Link DGS-3120 switch.\r
+\r
+ACL configuration via CLI is vendor-specific, and SNMP4SDN will support configuration with vendor-specific CLI in future release.\r
+\r
+To do ACL configuration using the REST APIs, use commands like the following:\r
+\r
+* Clear ACL table\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/acl:clear-acl-table -d "{"input":{"nodeId":<switch-mac-address-in-number>}}" \r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/acl:clear-acl-table -d "{"input":{"nodeId":158969157063648}}"\r
+----\r
++\r
+* Create ACL profile (IP layer)\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/acl:create-acl-profile -d "{input:{"nodeId":<switch-mac-address-in-number>,"profile-id":<profile_id_in_number>,"profile-name":'<profile_name>',"acl-layer":'IP',"vlan-mask":<vlan_mask_in_number>,"src-ip-mask":'<src_ip_mask>',"dst-ip-mask":"<destination_ip_mask>"}}"\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/acl:create-acl-profile -d "{input:{"nodeId":158969157063648,"profile-id":1,"profile-name":'profile_1',"acl-layer":'IP',"vlan-mask":1,"src-ip-mask":'255.255.0.0',"dst-ip-mask":'255.255.255.255'}}"\r
+----\r
++\r
+* Create ACL profile (MAC layer)\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/acl:create-acl-profile -d "{input:{"nodeId":<switch-mac-address-in-number>,"profile-id":<profile_id_in_number>,"profile-name":'<profile_name>',"acl-layer":'ETHERNET',"vlan-mask":<vlan_mask_in_number>}}"\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/acl:create-acl-profile -d "{input:{"nodeId":158969157063648,"profile-id":2,"profile-name":'profile_2',"acl-layer":'ETHERNET',"vlan-mask":4095}}"\r
+----\r
++\r
+* Delete ACL profile\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/acl:del-acl-profile -d "{input:{"nodeId":<switch-mac-address-in-number>,"profile-id":<profile_id_in_number>}}"\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/acl:del-acl-profile -d "{input:{"nodeId":158969157063648,"profile-id":1}}"\r
+----\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/acl:del-acl-profile -d "{input:{"nodeId":<switch-mac-address-in-number>,"profile-name":"<profile_name>"}}"\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/acl:del-acl-profile -d "{input:{"nodeId":158969157063648,"profile-name":'profile_2'}}"\r
+----\r
++\r
+* Set ACL rule\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/acl:set-acl-rule -d "{input:{"nodeId":<switch-mac-address-in-number>,"profile-id":<profile_id_in_number>,"profile-name":'<profile_name>',"rule-id":<rule_id_in_number>,"port-list":[<port_number>,<port_number>,...],"acl-layer":'<acl_layer>',"vlan-id":<vlan_id_in_number>,"src-ip":"<src_ip_address>","dst-ip":'<dst_ip_address>',"acl-action":'<acl_action>'}}" \r
+(<acl_layer>: IP or ETHERNET)\r
+(<acl_action>: PERMIT as permit, DENY as deny)\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/acl:set-acl-rule -d "{input:{"nodeId":158969157063648,"profile-id":1,"profile-name":'profile_1',"rule-id":1,"port-list":[1,2,3],"acl-layer":'IP',"vlan-id":2,"src-ip":'1.1.1.1',"dst-ip":'2.2.2.2',"acl-action":'PERMIT'}}" \r
+----\r
++\r
+* Delete ACL rule\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/acl:del-acl-rule -d "{input:{"nodeId":<switch-mac-address-in-number>,"profile-id":<profile_id_in_number>,"profile-name":'<profile_name>',"rule-id":<rule_id_in_number>}}"\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/acl:del-acl-rule -d "{input:{"nodeId":158969157063648,"profile-id":1,"profile-name":'profile_1',"rule-id":1}}"\r
+----\r
+\r
+==== Special configuration\r
+\r
+SNMP4SDN supports setting the following special configurations via REST API:\r
+\r
+* Set STP port state\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/config:set-stp-port-state -d "{input:{"node-id":<switch-mac-address-in-number>, "port":<port_number>, enable:<true_or_false>}}" \r
+(true: enable, false: disable)\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/config:set-stp-port-state -d "{input:{"node-id":158969157063648, "port":2, enable:false}}" \r
+----\r
++\r
+* Get STP port state\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/config:get-stp-port-state -d "{input:{"node-id":<switch-mac-address-in-number>, "port":<port_number>}}" \r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/config:get-stp-port-state -d "{input:{"node-id":158969157063648, "port":2}}" \r
+----\r
++\r
+* Get STP port root\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/config:get-stp-port-root -d "{input:{"node-id":<switch-mac-address-in-number>, "port":<port_number>}}" \r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/config:get-stp-port-root -d "{input:{"node-id":158969157063648, "port":2}}" \r
+----\r
++\r
+* Enable STP\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/config:enable-stp -d "{input:{"node-id":<switch-mac-address-in-number>}}" \r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/config:enable-stp -d "{input:{"node-id":158969157063648}}" \r
+----\r
++\r
+* Disable STP\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/config:disable-stp -d "{input:{"node-id":<switch-mac-address-in-number>}}"\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/config:disable-stp -d "{input:{"node-id":158969157063648}}"\r
+----\r
++\r
+* Get ARP table\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/config:get-arp-table -d "{input:{"node-id":<switch-mac-address-in-number>}}"\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/config:get-arp-table -d "{input:{"node-id":158969157063648}}"\r
+----\r
++\r
+* Set ARP entry\r
++\r
+(Notice to give IP address with subnet prefix)\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/config:set-arp-entry -d "{input:{"node-id":<switch-mac-address-in-number>, "ip-address":'<ip_address>', "mac-address":<mac_address_in_number>}}"\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/config:set-arp-entry -d "{input:{"node-id":158969157063648, "ip-address":'10.217.9.9', "mac-address":1}}"\r
+----\r
++\r
+* Get ARP entry\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/config:get-arp-entry -d "{input:{"node-id":<switch-mac-address-in-number>, "ip-address":'<ip_address>'}}"\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/config:get-arp-entry -d "{input:{"node-id":158969157063648, "ip-address":'10.217.9.9'}}"\r
+----\r
++\r
+* Delete ARP entry\r
++\r
+----\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://<controller_ip_address>:8181/restconf/operations/config:delete-arp-entry -d "{input:{"node-id":<switch-mac-address-in-number>, "ip-address":'<ip_address>'}}"\r
+\r
+For example:\r
+curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/config:delete-arp-entry -d "{input:{"node-id":158969157063648, "ip-address":'10.217.9.9'}}"\r
+----\r
+\r
+==== Using Postman to invoke REST API\r
+Besides using the curl tool to invoke REST API, like the examples aforementioned, one can also use GUI tool like Postman for better data display.\r
+\r
+* Install Postman: \r
+https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en[Install Postman in the Chrome browser]\r
++\r
+* In the chrome browser bar enter \r
++\r
+----\r
+chrome://apps/\r
+----\r
++\r
+* Click on Postman.\r
+\r
+===== Example: Get VLAN table using Postman\r
+\r
+As the screenshot shown below, one needs to fill in required fields.\r
+----\r
+URL:\r
+http://<controller_ip_address>:8181/restconf/operations/vlan:get-vlan-table\r
+\r
+Accept header:\r
+application/json\r
+\r
+Content-type:\r
+application/json\r
+\r
+Body:\r
+{input:{"node-id":<node_id>}}\r
+for example:\r
+{input:{"node-id":158969157063648}}\r
+----\r
+\r
+.Example: Get VLAN table using Postman\r
+image::snmp4sdn_getvlantable_postman.jpg["Example: Get VLAN table using Postman",width=500]\r
+\r
+=== Multi-vendor support\r
+\r
+So far the supported vendor-specific configurations:\r
+\r
+* Add VLAN and set ports\r
+* (More functions are TBD)\r
+\r
+The SNMP4SDN Plugin would examine whether the configuration is described in the vendor-specific configuration file. If yes, the configuration description would be adopted, otherwise just use the default configuration. For example, adding VLAN and setting the ports is supported via SNMP standard MIB. However we found some special cases, for example, certain Accton switch requires to add VLAN first and then allows to set the ports. So one may describe this in the vendor-specific configuration file.\r
+\r
+A vendor-specific configuration file sample is https://wiki.opendaylight.org/view/SNMP4SDN:snmp4sdn_VendorSpecificSwitchConfig_file[here], and we suggest to save it as '/etc/snmp4sdn_VendorSpecificSwitchConfig.xml' so that SNMP4SDN Plugin can automatically load it.\r
+\r
+=== Help\r
+* https://wiki.opendaylight.org/view/SNMP4SDN:Main[SNMP4SDN Wiki]\r
+* SNMP4SDN Mailing Lists: (https://lists.opendaylight.org/mailman/listinfo/snmp4sdn-users[user], https://lists.opendaylight.org/mailman/listinfo/snmp4sdn-dev[developer])\r
+* Latest https://wiki.opendaylight.org/view/SNMP4SDN:User_Guide#Troubleshooting[troubleshooting] in Wiki\r
+\r
+++ /dev/null
-== TSDR H2 datastore User Guide
-This document describes how to use the embedded JPA datastore H2, which is the default datastore (recommended for non-production use case) introduced as part of OpenDaylight Time Series Data Respository(TSDR) project. This store captures the time series data. This document contains configuration, administration, management, using, and troubleshooting
-sections for the feature.
-
-=== Overview
-In the Lithium Release of Time Series Data Repository (TSDR), time series metrics corresponding to the OpenFlow statistics are captured. For users trying out things on their laptop or non-production environment, TSDR functionality can be enabled with default datastore H2 by installing the feature odl-tsdr-all.
-
-=== TSDR Architecture
-The following wiki pages capture the TSDR Model/Architecture
-
-a. https://wiki.opendaylight.org/view/TSDR_Data_Storage_Service_and_Persistence_with_HBase_Plugin
-b. https://wiki.opendaylight.org/view/TSDR_Data_Collection_Service
-
-Note in Lithium the DataCollection Service is implemented just for OpenFlow Statistics metrics.
-
-
-=== Configuring TSDR with default datastore H2
-The H2 based storage files get stored automatically in <karaf install folder>/tsdr/ directory. If you want to change the default storage location, the configuration file to change can be found in <karaf install folder>/etc directory. The filename is org.ops4j.datasource-metric.cfg. Change the last portion of the url=jdbc:h2:./tsdr/metric to point to different directory.
-
-=== Administering or Managing TSDR with default datastore H2
-Once the TSDR default datastore feature (odl-tsdr-all) is enabled, the TSDR captured OpenFlow statistics metrics can be accessed from Karaf Console by executing the command
-
- tsdr:list <metric-category> <starttimestamp> <endtimestamp>
-
-wherein
-
-* <metric-category> = any one of the following categories FlowGroupStats, FlowMeterStats, FlowStats, FlowTableStats, PortStats, QueueStats
-* <starttimestamp> = to filter the list of metrics starting this timestamp
-* <endtimestamp> = to filter the list of metrics ending this timestamp
-
-If either of <starttimestamp> or <endtimestamp> is not specified, this command displays the latest 1000 metrics captured.
-
-With TSDR functionality with default H2 datastore you get an additional command
-
- tsdr:purgeAll
-
-This will purge the entire collected tsdr metrics record.
+++ /dev/null
-== TSDR HBase Data Store User Guide
-This document describes how to use HBase to capture time series data
-using Time Series Data Repository (TSDR) feature in the OpenDaylight
-Lithium release. This document contains configuration, administration,
-management, usage, and troubleshooting sections for the feature.
-
-=== Overview
-The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a framework for collecting, storing, querying, and maintaining time series data in then OpenDaylight SDN controller. TSDR provides the framework for plugging in proper data collectors to collect various time series data and store into TSDR data stores. With a common data model and generic TSDR data persistence APIs, the user could choose various data stores to be plugged into TSDR Persistence framework. In Lithium, two types of data stores are supported: HBase NoSQL database and H2 relational database.
-
-With the capabilities of data collection, storage, query, aggregation, and purging provided by TSDR, network administrators could leverage various data driven appliations built on top of TSDR for security risk detection, performance analysis, operational configuration optimization, traffic engineering, and network analytics with automated intelligence.
-
-=== TSDR with HBase Data Store Architecture
-TSDR contains the following services and components:
-* Data Collection Service
-* Data Storage Service
-* TSDR Persistence Layer with data stores as plugins
-* TSDR Data Stores
-* Data Query Service
-* Data Aggregation Service
-* Data Purging Service
-
-Data Collection Service handles the collection of time series data into TSDR and hands it over to Data Storage Service. Data Storage Service stores the data into TSDR through TSDR Persistence Layer. TSDR Persistence Layer provides generic Service APIs allowing various data stores to be plugged in. Data Aggregation Service aggregates time series fine-grained raw data into course-grained roll-up data to control the size of the data. Data Purging Service periodically purges both fine-grained raw data and course-granined aggregated data according to user-defined schedules.
-
-
-In Lithium, we implemented Data Collection Service, Data Storage Service, TSDR Persistence Layer, TSDR HBase Data Store, and TSDR H2 Data Store. Among these services and components, time series data is communicated using a common TSDR data model, which is designed and implemented for the abstraction of time series data commonalities. With these functions, TSDR will be able to collect the data from the data sources and store them into one of the TSDR data stores: either HBase Data Store or H2 Data Store. We also provided a simple query command from Karaf console for the user to retrieve TSDR data from the data stores.
-
-
-A future release will contain Data Aggregation service, Data Purging Service, and a full-fledged Data Query Service with Norghbound APIs.
-
-=== Configuring TSDR with HBase Data Store
-After installing HBase Server on the same VM as the OpenDaylight Controller, if the user accepts the default configuration of the HBase Data Store, the user can directly proceed with the installation of HBase Data Store from Karaf console.
-
-Optionally, the user can configure TSDR HBase Data Store following HBase Data Store Configuration Procedure.
-
-* HBase Data Store Configuration Steps
-
-** Open the file etc/tsdr-persistence-hbase.peroperties under karaf distribution directory.
-** Edit the following parameters:
-*** HBase server name
-*** HBase server port
-*** HBase client connection pool size
-*** HBase client write buffer size
-
-After the configuration of HBase Data Store is complete, proceed with the installation of HBase Data Store from Karaf console.
-
-* HBase Data Store Installation Steps
-
-** Start Karaf Console
-** Run the following commands from Karaf Console:
-feature:install odl-tsdr-hbase
-
-
-=== Administering or Managing TSDR HBase Data Store
-
-* Using Karaf Command to retrieve data from HBase Data Store
-The user can retrieve the data from HBase data store using the following commands from Karaf console:
-
-tsdr:list
-
-tsdr:list <CategoryName> <StartTime> <EndTime>
-
-Typing tab will get the context prompt of the arguments when typeing the command in Karaf console.
-
-* Troubleshooting issues with log files
-** Karaf logs
-Similar to other OpenDaylight components and features, TSDR HBase Data Store writes logging information to Karaf logs. All the information messages, warnings, error messages, and debug messages are written to Karaf logs.
-
-** HBase logs
-For HBase system level logs, the user can check standard HBase server logs, which is under <HBase-installation-directory>/logs.
-
-=== Tutorials
-
-==== How to use TSDR to collect, store, and view OpenFlow Interface Statistics
-
-===== Overview
-This tutorial describes an example of using TSDR to collect, store, and view one type of time series data in OpenDaylight environment.
-
-
-===== Prerequisites
-You would need to have the following as prerequisits:
-* One or multiple OpenFlow enabled switches. Alternatively, you can use mininet to simulate such a switch.
-* Successfully installed OpenDaylight Controller.
-* Successfully installed HBase Data Store following TSDR HBase Data Store Installation Guide.
-* Connect the OpenFlow enabled switch(es) to OpenDaylight Controller.
-===== Target Environment
-HBase data store is only supported in Linux operation system.
-
-===== Instructions
-
-* Start OpenDaylight controller.
-
-* Connect OpenFlow enabled switch(es) to the controller.
-
-**If using mininet, run the following commands from mininet command line:
-
-*** mn --topo single,3 --controller 'remote,ip=172.17.252.210,port=6653' --switch ovsk,protocols=OpenFlow13
-
-**If using real switch(es), the OpenDaylight controller should be able to discover the network toplogy containing the switches.
-
-
-* Install tsdr hbase feature from Karaf:
-
-** feature:install odl-tsdr-hbase
-
-* run the following command from Karaf console:
-
-** tsdr:list InterfaceStats
-
-You should be able to see the interface statistics of the switch(es) from the HBase Data Store. If there are too many rows, you can use "tsdr:list InterfaceStats|more" to view it page by page.
-
-By tabbing after "tsdr:list", you will see all the supported data categories. For example, "tsdr:list FlowStats" will output the Flow statistics data collected from the switch(es).
-
-
--- /dev/null
+== TSDR User Guide
+This document describes how to use HSQLDB, HBase, and Cassandra data stores to
+capture time series data using Time Series Data Repository (TSDR) features
+in OpenDaylight. This document contains configuration, administration, management,
+usage, and troubleshooting sections for the features.
+
+=== Overview
+The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a
+framework for collecting, storing, querying, and maintaining time series data.
+TSDR provides the framework for plugging in proper data collectors to collect
+various time series data and store the data into
+TSDR Data Stores. With a common data model and generic TSDR data persistence
+APIs, the user can choose various data stores to be plugged into the TSDR
+persistence framework. Currently, three types of data stores are supported:
+HSQLDB relational database, HBase NoSQL database, and Cassandra NoSQL database.
+
+With the capabilities of data collection, storage, query, aggregation, and
+purging provided by TSDR, network administrators can leverage various data
+driven appliations built on top of TSDR for security risk detection,
+performance analysis, operational configuration optimization, traffic
+engineering, and network analytics with automated intelligence.
+
+
+=== TSDR Architecture
+TSDR has the following major components:
+
+* Data Collection Service
+* Data Storage Service
+* TSDR Persistence Layer with data stores as plugins
+* TSDR Data Stores
+* Data Query Service
+* Grafana integration for time series data visualization
+* Data Aggregation Service
+* Data Purging Service
+
+The Data Collection Service handles the collection of time series data into TSDR and
+hands it over to the Data Storage Service. The Data Storage Service stores the data
+into TSDR through the TSDR Persistence Layer. The TSDR Persistence Layer provides generic
+Service APIs allowing various data stores to be plugged in. The Data Aggregation
+Service aggregates time series fine-grained raw data into course-grained roll-up
+data to control the size of the data. The Data Purging Service periodically purges
+both fine-grained raw data and course-granined aggregated data according to
+user-defined schedules.
+
+We have implemented The Data Collection Service, Data Storage Service, TSDR
+Persistence Layer, TSDR HSQLDB Data Store, TSDR HBase Data Store, and TSDR Cassandra
+Datastore. Among these services and components, time series data is communicated
+using a common TSDR data model, which is designed and implemented for the
+abstraction of time series data commonalities. With these functions, TSDR is
+able to collect the data from the data sources and store them into one of
+the TSDR data stores: HSQLDB Data Store, HBase Data Store or Cassandra Data
+Store. Besides a simple query command from Karaf console to retrieve data from the
+TSDR data stores, we also provided a Data Query Service for the user to use REST API
+to query the data from the data stores. Moreover, the user can use Grafana, which is
+a time series visualization tool to view the data stored in TSDR in various charting
+formats.
+
+=== Configuring TSDR Data Stores
+==== To Configure HSQLDB Data Store
+
+The HSQLDB based storage files get stored automatically in <karaf install folder>/tsdr/
+directory. If you want to change the default storage location, the configuration
+file to change can be found in <karaf install folder>/etc directory. The filename
+is org.ops4j.datasource-metric.cfg. Change the last portion of the url=jdbc:hsqldb:./tsdr/metric
+to point to different directory.
+
+==== To Configure HBase Data Store
+
+After installing HBase Server on the same machine as OpenDaylight, if the user accepts the default configuration of the HBase Data Store, the user can directly proceed with the installation of HBase Data Store from Karaf console.
+
+Optionally, the user can configure TSDR HBase Data Store following HBase Data Store Configuration Procedure.
+
+* HBase Data Store Configuration Steps
+
+** Open the file etc/tsdr-persistence-hbase.peroperties under karaf distribution directory.
+** Edit the following parameters:
+*** HBase server name
+*** HBase server port
+*** HBase client connection pool size
+*** HBase client write buffer size
+
+After the configuration of HBase Data Store is complete, proceed with the installation of HBase Data Store from Karaf console.
+
+* HBase Data Store Installation Steps
+
+** Start Karaf Console
+** Run the following commands from Karaf Console:
+feature:install odl-tsdr-hbase
+
+==== To Configure Cassandra Data Store
+
+Currently, there's no configuration needed for Cassandra Data Store. The user can use Cassandra data store directly after installing the feature from Karaf console.
+
+Additionally separate commands have been implemented to install various data collectors.
+
+=== Administering or Managing TSDR Data Stores
+==== To Administer HSQLDB Data Store
+
+Once the TSDR default datastore feature (odl-tsdr-hsqldb-all) is enabled, the TSDR captured OpenFlow statistics metrics can be accessed from Karaf Console by executing the command
+
+ tsdr:list <metric-category> <starttimestamp> <endtimestamp>
+
+wherein
+
+* <metric-category> = any one of the following categories FlowGroupStats, FlowMeterStats, FlowStats, FlowTableStats, PortStats, QueueStats
+* <starttimestamp> = to filter the list of metrics starting this timestamp
+* <endtimestamp> = to filter the list of metrics ending this timestamp
+* <starttimestamp> and <endtimestamp> are optional.
+* Maximum 1000 records will be displayed.
+
+==== To Administer HBase Data Store
+
+* Using Karaf Command to retrieve data from HBase Data Store
+
+The user first need to install hbase data store from karaf console:
+
+feature:install odl-tsdr-hbase
+
+The user can retrieve the data from HBase data store using the following commands from Karaf console:
+
+ tsdr:list
+ tsdr:list <CategoryName> <StartTime> <EndTime>
+
+Typing tab will get the context prompt of the arguments when typeing the command in Karaf console.
+
+==== To Administer Cassandra Data Store
+
+The user first needs to install Cassandra data store from Karaf console:
+
+ feature:install odl-tsdr-cassandra
+
+Then the user can retrieve the data from Cassandra data store using the following commands from Karaf console:
+
+ tsdr:list
+ tsdr:list <CategoryName> <StartTime> <EndTime>
+
+Typing tab will get the context prompt of the arguments when typeing the command in Karaf console.
+
+=== Installing TSDR Data Collectors
+
+When the user uses HSQLDB data store and installed "odl-tsdr-hsqldb-all" feature from Karaf console, besides the HSQLDB data store, OpenFlow data collector is also installed with this command. However, if the user needs to use other collectors, such as NetFlow Collector, Syslog Collector, SNMP Collector, and Controller Metrics Collector, the user needs to install them with separate commands. If the user uses HBase or Cassandra data store, no collectors will be installed when the data store is installed. Instead, the user needs to install each collector separately using feature install command from Karaf console.
+
+The following is the list of supported TSDR data collectors with the associated feature install commands:
+
+* OpenFlow Data Collector
+
+ feature:install odl-tsdr-openflow-statistics-collector
+
+* SNMP Data Collector
+
+ feature:install odl-tsdr-snmp-data-collector
+
+* NetFlow Data Collector
+
+ feature:install odl-tsdr-netflow-statistics-collector
+
+* Syslog Data Collector
+
+ feature:install odl-tsdr-syslog-collector
+
+* Controller Metrics Collector
+
+ feature:install odl-tsdr-controller-metrics-collector
+
+In order to use controller metrics collector, the user needs to install Sigar library.
+
+The following is the instructions for installing Sigar library on Ubuntu:
+
+*** Install back end library by "sudo apt-get install libhyperic-sigar-java"
+*** Execute "export LD_LIBRARY_PATH=/usr/lib/jni/:/usr/lib:/usr/local/lib" to set the path of the JNI (you can add this to the ".bashrc" in your home directory)
+*** Download the file "sigar-1.6.4.jar". It might be also in your ".m2" directory under "~/.m2/resources/org/fusesource/sigar/1.6.4"
+*** Create the directory "org/fusesource/sigar/1.6.4" under the "system" directory in your controller home directory and place the "sigar-1.6.4.jar" there
+
+=== Configuring TSDR Data Collectors
+
+* SNMP Data Collector Device Credential Configuration
+
+After installing SNMP Data Collector, a configuration file under etc/ directory of ODL distribution is generated: etc/tsdr.snmp.cfg is created.
+
+The following is a sample tsdr.snmp.cfg file:
+
+credentials=[192.168.0.2,public],[192.168.0.3,public]
+
+The above credentials indicate that TSDR SNMP Collector is going to connect to two devices. The IPAddress and Read community string of these two devices are (192.168.0.2, public), and (192.168.0.3) respectively.
+
+The user can make changes to this configuration file any time during runtime. The configuration will be picked up by TSDR in the next cycle of data collection.
+
+==== Polling interval configuration for SNMP Collector and OpenFlow Stats Collector
+
+The default polling interval of SNMP Collector and OpenFlow Stats Collector is 30 seconds and 15 seconds respectively. The user can change the polling interval through restconf APIs at any time. The new polling interval will be picked up by TSDR in the next collection cycle.
+
+* Retrieve Polling Interval API for SNMP Collector
+** URL: http://localhost:8181/restconf/config/tsdr-snmp-data-collector:TSDRSnmpDataCollectorConfig
+** Verb: GET
+
+* Update Polling Interval API for SNMP Collector
+** URL: http://localhost:8181/restconf/operations/tsdr-snmp-data-collector:setPollingInterval
+** Verb: POST
+** Content Type: application/json
+** Input Payload:
+
+ {
+ "input": {
+ "interval": "15000"
+ }
+ }
+
+* Retrieve Polling Interval API for OpenFlowStats Collector
+** URL: http://localhost:8181/restconf/config/tsdr-openflow-statistics-collector:TSDROSCConfig
+** Verb: GET
+
+* Update Polling Interval API for OpenFlowStats Collector
+** URL: http://localhost:8181/restconf/operations/tsdr-openflow-statistics-collector:setPollingInterval
+** Verb: POST
+** Content Type: application/json
+** Input Payload:
+
+ {
+ "input": {
+ "interval": "15000"
+ }
+ }
+
+=== Querying TSDR from REST APIs
+
+TSDR provides two REST APIs for querying data stored in TSDR data stores.
+
+* Query of TSDR Metrics
+** URL: http://localhost:8181/tsdr/metrics/query
+** Verb: GET
+** Parameters:
+*** tsdrkey=[NID=][DC=][MN=][RK=]
+
+ The TSDRKey format indicates the NodeID(NID), DataCategory(DC), MetricName(MN), and RecordKey(RK) of the monitored objects.
+ For example, the following is a valid tsdrkey:
+ [NID=openflow:1][DC=FLOWSTATS][MN=PacketCount][RK=Node:openflow:1,Table:0,Flow:3]
+ The following is also a valid tsdrkey:
+ tsdrkey=[NID=][DC=FLOWSTATS][MN=][RK=]
+ In the case when the sections in the tsdrkey is empty, the query will return all the records in the TSDR data store that matches the filled tsdrkey. In the above example, the query will return all the data in FLOWSTATS data category.
+ The query will return only the first 1000 records that match the query criteria.
+
+*** from=<time_in_seconds>
+*** until=<time_in_seconds>
+
+The following is an example curl command for querying metric data from TSDR data store:
+
+curl -G -v -H "Accept: application/json" -H "Content-Type: application/json" "http://localhost:8181/tsdr/metrics/query" --data-urlencode "tsdrkey=[NID=][DC=FLOWSTATS][MN=][RK=]" --data-urlencode "from=0" --data-urlencode "until=240000000"|more
+
+* Query of TSDR Log type of data
+** URL:http://localhost:8181/tsdr/logs/query
+** Verb: GET
+** Parameters:
+*** tsdrkey=tsdrkey=[NID=][DC=][RK=]
+
+ The TSDRKey format indicates the NodeID(NID), DataCategory(DC), and RecordKey(RK) of the monitored objects.
+ For example, the following is a valid tsdrkey:
+ [NID=openflow:1][DC=NETFLOW][RK]
+ The query will return only the first 1000 records that match the query criteria.
+
+*** from=<time_in_seconds>
+*** until=<time_in_seconds>
+
+The following is an example curl command for querying log type of data from TSDR data store:
+
+curl -G -v -H "Accept: application/json" -H "Content-Type: application/json" "http://localhost:8181/tsdr/logs/query" --data-urlencode "tsdrkey=[NID=][DC=NETFLOW][RK=]" --data-urlencode "from=0" --data-urlencode "until=240000000"|more
+
+=== Grafana integration with TSDR
+
+TSDR provides northbound integration with Grafana time series data visualization tool. All the metric type of data stored in TSDR data store can be visualized using Grafana.
+
+For the detailed instruction about how to install and configure Grafana to work with TSDR, please refer to the following link:
+
+https://wiki.opendaylight.org/view/Grafana_Integration_with_TSDR_Step-by-Step
+
+=== Purging Service configuration
+
+After the data stores are installed from Karaf console, the purging service will be installed as well. A configuration file called tsdr.data.purge.cfg will be generated under etc/ directory of ODL distribution.
+
+The following is the sample default content of the tsdr.data.purge.cfg file:
+
+host=127.0.0.1
+data_purge_enabled=true
+data_purge_time=23:59:59
+data_purge_interval_in_minutes=1440
+retention_time_in_hours=168
+
+The host indicates the IPAddress of the data store. In the case when the data store is together with ODL controller, 127.0.0.1 should be the right value for the host IP. The other attributes are self-explained. The user can change those attributes at any time. The configuration change will be picked up right away by TSDR Purging service at runtime.
+
+=== How to use TSDR to collect, store, and view OpenFlow Interface Statistics
+
+==== Overview
+This tutorial describes an example of using TSDR to collect, store, and view one type of time series data in OpenDaylight environment.
+
+
+==== Prerequisites
+You would need to have the following as prerequisits:
+
+* One or multiple OpenFlow enabled switches. Alternatively, you can use mininet to simulate such a switch.
+* Successfully installed OpenDaylight Controller.
+* Successfully installed HBase Data Store following TSDR HBase Data Store Installation Guide.
+* Connect the OpenFlow enabled switch(es) to OpenDaylight Controller.
+
+==== Target Environment
+HBase data store is only supported in Linux operation system.
+
+==== Instructions
+
+* Start OpenDaylight.
+
+* Connect OpenFlow enabled switch(es) to the controller.
+
+** If using mininet, run the following commands from mininet command line:
+
+*** mn --topo single,3 --controller 'remote,ip=172.17.252.210,port=6653' --switch ovsk,protocols=OpenFlow13
+
+
+* Install tsdr hbase feature from Karaf:
+
+** feature:install odl-tsdr-hbase
+
+* Install OpenFlow Statistics Collector from Karaf:
+
+** feature:install odl-tsdr-openflow-statistics-collector
+
+* run the following command from Karaf console:
+
+** tsdr:list PORTSTATS
+
+You should be able to see the interface statistics of the switch(es) from the HBase Data Store. If there are too many rows, you can use "tsdr:list InterfaceStats|more" to view it page by page.
+
+By tabbing after "tsdr:list", you will see all the supported data categories. For example, "tsdr:list FlowStats" will output the Flow statistics data collected from the switch(es).
+
+=== Troubleshooting
+==== Karaf logs
+
+All TSDR features and components write logging information including information messages, warnings, errors and debug messages into karaf.log.
+
+==== HBase and Cassandra logs
+
+For HBase and Cassandra data stores, the database level logs are written into HBase log and Cassandra logs.
+
+** HBase log
+*** HBase log is under <HBase-installation-directory>/logs/.
+
+** Cassandra log
+*** Cassandra log is under {cassandra.logdir}/system.log. The default {cassandra.logdir} is /var/log/cassandra/.
+
+=== Security
+
+TSDR gets the data from a variety of sources, which can be secured in different ways.
+
+** OpenFlow Security
+*** The OpenFlow data can be configured with Transport Layer Security (TLS) since the OpenFlow Plugin that TSDR depends on provides this security support.
+
+** SNMP Security
+*** The SNMP version3 has security support. However, since ODL SNMP Plugin that TSDR depends on does not support version 3, we (TSDR) will not have security support at this moment.
+
+** NetFlow Security
+*** NetFlow, which cannot be configured with security so we recommend making sure it flows only over a secured management network.
+
+** Syslog Security
+*** Syslog, which cannot be configured with security so we recommend making sure it flows only over a secured management network.
--- /dev/null
+== UNI Manager Plug In Project
+
+=== Overview
+The version of the UNI Manager (UNIMgr) plug-in included in OpenDaylight
+Beryllium release is experimental, serving as a proof-of-concept (PoC) for using
+features of OpenDaylight to provision networked elements with attributes
+satisfying Metro Ethernet Forum (MEF) requirements for delivery of Carrier
+Ethernet service. This initial version of UNIMgr does not enable the full set
+of MEF-defined functionality for Carrier Ethernet service. UNI Manager adheres
+to a minimum set of functionality defined by MEF 7.2 and 10.2 specifications.
+
+UNIMgr receives a request from applications to create an Ethernet Private Line
+(EPL) private Ethernet connection between two endpoints on the network. The
+request must include the IP addresses of the endpoints and a class of service
+identifier.
+
+UNI Manager plug-in translates the request for EPL service into (a) configuring
+two instances of Open vSwitch (OVS), each instance running in one of the
+UNI endpoints, with two ports and a bridge between the ports, and (b) creating a
+GRE tunnel to provide a private connection between the endpoints. This initial
+version of UNIMgr uses only OVSDB on its southbound interface to send
+configuration commands.
+
+UNIMgr also accepts a bits per second datarate parameter, which is translated
+to an OVSDB command to limit the rate at which the OVS instances will forward
+data traffic.
+
+The YANG module used to create the UNIMgr plug-in models MEF-defined UNI and
+Ethernet Virtual Connection (EVC) attributes but does not include the full set
+of UNI and EVC attributes. And of the attributes modeled in the YANG module
+only a subset of them are implemented in the UNIMgr listener code translating
+the Operational data tree to OVSDB commands. The YANG module used to develop
+the PoC UNIMgr plug-in is cl-unimgr-mef.yang. A copy of this module is
+available in the odl-unimgr-api bundle of the UNIMgr project.
+
+Limitations of the PoC version of UNI Manager in OpenDaylight Beryllium include
+those listed below:
+* Uses only OVSDB southbound interface of OpenDaylight
+* Only uses UNI ID, IP Address, and speed UNI attributes
+* Only uses a subset of EVC per UNI attributes
+* Does not use MEF Class of Service or Bandwidth Profile attributes
+* Configures only Open vSwitch network elements
+
+Opportunities for evolution of the UNI Manager plug in include using complete
+MEF Service Layer and MEF Resource Layer YANG models and supporting other
+OpenDaylight southbound protocols like NetConf and OpenFlow.
+
+=== UNI Manager Components
+
+UNI Manager is comprised of the following OpenDaylight Karaf features:
+
+[width="60%",frame="topbot"]
+|======================
+|odl-unimgr-api | OpenDaylight :: UniMgr :: api
+|odl-unimgr | OpenDaylight :: UniMgr
+|odl-unimgr-console | OpenDaylight :: UniMgr :: CLI
+|odl-unimgr-rest | OpenDaylight :: UniMgr :: REST
+|odl-unimgr-ui | OpenDaylight :: UniMgr :: UI
+|======================
+
+=== Installing UNI Manager Plug-in
+
+After launching OpenDaylight install the feature for the UNI Manager plug-in.
+From the karaf command prompt execute the following command to install
+the UNI Manager plug-in:
+
+ $ feature:install odl-manager-ui
+
+=== Explore and exercise the UNI Manager REST API
+
+To see the UNI Manager APIs, browse to this URL:
+http://localhost:8181/apidoc/explorer/index.html
+
+Replace localhost with the IP address or hostname where OpenDaylight is
+running if you are not running OpenDaylight locally on your machine.
+
+See also the UNI Manager Developer's Guide for a full list and description of
+UNI Manager POSTMAN calls.
* OpenDaylight (VTN Feature)
-** VTN Coordinator
+* VTN Coordinator
===== VTN Coordinator
* In /usr/bin, create a soft link as "ln –s /usr/bin/apr-1-config /usr/bin/apr-config".
-* Extract tomcat under "/usr/share/java" by using the below command "tar -xvf apache-tomcat-7.0.56.tar.gz –C /usr/share/java".
+* Extract tomcat under "/usr/share/java" by using the below command "tar -xvf apache-tomcat-8.0.27.tar.gz –C /usr/share/java".
NOTE:
-Please go through the bleow link to download apache-tomcat-7.0.56.tar.gz file,
-https://archive.apache.org/dist/tomcat/tomcat-7/v7.0.56/bin/
+Please go through the bleow link to download apache-tomcat-8.0.27.tar.gz file,
+https://archive.apache.org/dist/tomcat/tomcat-8/v8.0.27/bin/
-* Please go to the directory "cd /usr/share/java/apache-tomcat-7.0.56/bin and unzip tomcat-native.gz using this command "tar -xvf tomcat-native.gz".
+* Please go to the directory "cd /usr/share/java/apache-tomcat-8.0.27/bin and unzip tomcat-native.gz using this command "tar -xvf tomcat-native.gz".
-* Go to the directory "cd /usr/share/java/apache-tomcat-7.0.56/bin/tomcat-native-1.1.27-src/jni/native".
+* Go to the directory "cd /usr/share/java/apache-tomcat-8.0.27/bin/tomcat-native-1.1.33-src/jni/native".
-* Enter the command "./configure --with-apr=/usr/bin/apr-config".
+* Enter the command "./configure --with-os-type=bin --with-apr=/usr/bin/apr-config".
* Enter the command "make" and "make install".
*Enable HTTP/HTTPS in VTN Coordinator*
-Enter the command "system-config-firewall-tui" to enable firewall settings in server.
+Enter the command "firewall-cmd --zone=public --add-port=8083/tcp --permanent" and "firewall-cmd --reload" to enable firewall settings in server.
*Create a CA's private key and a self-signed certificate in server*
* The response should be like this for both HTTP and HTTPS:
+
----
-{"api_version":{"version":"V1.2"}}
+{"api_version":{"version":"V1.4"}}
----
===== Prerequisites to create Network Service in SCVMM machine, Please follow the below steps
. Please go through the below link to download VSEM Provider zip file,
- https://nexus.opendaylight.org/content/groups/public/org/opendaylight/vtn/application/vtnmanager-vsemprovider/1.0.0-Lithium/vtnmanager-vsemprovider-1.0.0-Lithium-bin.zip
+ https://nexus.opendaylight.org/content/groups/public/org/opendaylight/vtn/application/vtnmanager-vsemprovider/2.0.0-Beryllium/vtnmanager-vsemprovider-2.0.0-Beryllium-bin.zip
-. Unzip the vtnmanager-vsemprovider-1.0.0-Lithium-bin.zip file anywhere in your SCVMM machine.
+. Unzip the vtnmanager-vsemprovider-2.0.0-Beryllium-bin.zip file anywhere in your SCVMM machine.
. Stop SCVMM service from *"service manager->tools->servers->select system center virtual machine manager"* and click stop.
-. Go to *"C:/Program Files"* in your SCVMM machine. Inside *"C:/Program Files"*, create a folder named as *"ODLProvider".
+. Go to *"C:/Program Files"* in your SCVMM machine. Inside *"C:/Program Files"*, create a folder named as *"ODLProvider"*.
. Inside *"C:/Program Files/ODLProvider"*, create a folder named as "Module" in your SCVMM machine.
*After executing db_setup, you have encountered the error "Failed to setup database"?*
The error could be due to the below reasons
+
* Access Restriction
The user who owns /usr/local/vtn/ directory and installs VTN Coordinator, can only start db_setup.
.If you encounter an erroneous situation where the REST API is always failing.
----
- Please ensure the firewall settings for port:8282(Lithium release) or port:8083(Post Lithium release) and enable the same.
+ Please ensure the firewall settings for port:8181(Beryllium release) or port:8083(Post Beryllium release) and enable the same.
----
.How to debug a REST API returning a failure message?
Please check the /usr/share/java/apache-tomcat-7.0.39/logs/core/core.log for failure details.
This example demonstrates on how to create a specific VTN Path Map information.
.PathMap
-image::vtn/Pathmap.png[pathmap]
+image::vtn/Pathmap.png["Pathmap" ,width= 500]
===== Requirement
* Save the mininet script given below as pathmap_test.py and run the mininet script in the mininet environment where Mininet is installed.
* Create topology using the below mininet script:
----
-from mininet.topo import Topo
- class MyTopo( Topo ):
+ from mininet.topo import Topo
+ class MyTopo( Topo ):
"Simple topology example."
def __init__( self ):
"Create custom topo."
h2 h2-eth0:s3-eth3
----
+NOTE: Add the default flow to OVS to forward packets to controller when there is a table-miss:
+
+----
+ovs-ofctl --protocols=OpenFlow13 add-flow <switch-name> priority=0,actions=output:CONTROLLER
+----
+
+These flows need to be added only in case of OpenFlow1.3 or using OVS versions (>2.1.1).
+
+Here the switch name is the switches in the topology such as s1,s2,s3.
+
* Generate traffic by pinging between hosts h1 and h2 before creating the portmaps respectively
----
* Create a Flowcondition in the VTN
----
-curl --user admin:admin -H 'content-type: application/json' -X PUT -d '{"name": "flowcond_1","match": [{"index": 1,"ethernet": {"src": "ca:9e:58:0c:1e:f0","dst": "ba:bd:0f:e3:a8:c8","type": 2048},"inetMatch": {"inet4": {"src": "10.0.0.1","dst": "10.0.0.2","protocol": 1}}}]}' http://10.100.9.42:8282/controller/nb/v2/vtn/default/flowconditions/flowcond_1
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:set-flow-condition -d '{"input":{"operation":"SET","present":"false","name":"cond_1", "vtn-flow-match":[{"vtn-ether-match":{},"vtn-inet-match":{"source-network":"10.0.0.1/32","protocol":1,"destination-network":"10.0.0.2/32"},"index":"1"}]}}'
----
* Create a Pathmap in the VTN
----
-curl --user admin:admin -H 'content-type: application/json' -X PUT -d '{"index": 10, "condition":"flowcond_1", "policy":1, "idleTimeout": 300, "hardTimeout": 0}' http://10.100.9.42:8282/controller/nb/v2/vtn/default/pathmaps/1
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-path-map:set-path-map -d '{"input":{"tenant-name":"vtn1","path-map-list":[{"condition":"cond_1","policy":"1","index": "1","idle-timeout":"300","hard-timeout":"0"}]}}'
----
* Get the Path policy information
----
-curl --user admin:admin -H 'content-type: application/json' -X GET -d '{"id": 1,"default": 100000,"cost": [{"location": {"node": {"type": "OF","id": "00:00:00:00:00:00:00:01"},"port": {"type": "OF","id": "3","name": "s1-eth3"}},"cost": 1000},{"location": {"node": {"type": "OF","id": "00:00:00:00:00:00:00:04"},"port": {"type": "OF","id": "2","name": "s4-eth2"}},"cost": 1000},{"location": {"node": {"type": "OF", "id": "00:00:00:00:00:00:00:03"},"port": {"type": "OF","id": "3","name": "s3-eth3"}},"cost": 100000}]}' http://10.100.9.42:8282/controller/nb/v2/vtn/default/pathpolicies/1
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-path-policy:set-path-policy -d '{"input":{"operation":"SET","id": "1","default-cost": "10000","vtn-path-cost": [{"port-desc":"openflow:1,3,s1-eth3","cost":"1000"},{"port-desc":"openflow:4,2,s4-eth2","cost":"100000"},{"port-desc":"openflow:3,3,s3-eth3","cost":"10000"}]}}'
----
===== Verification
"pathinfos": [
{
"in_port_name": "s1-eth1",
- "out_port_name": "s1-eth2",
- "switch_id": "00:00:00:00:00:00:00:01"
+ "out_port_name": "s1-eth3",
+ "switch_id": "openflow:1"
},
{
- "in_port_name": "s2-eth1",
- "out_port_name": "s2-eth2",
- "switch_id": "00:00:00:00:00:00:00:02"
+ "in_port_name": "s4-eth1",
+ "out_port_name": "s4-eth2",
+ "switch_id": "openflow:4"
},
{
- "in_port_name": "s3-eth1",
+ "in_port_name": "s3-eth2",
"out_port_name": "s3-eth3",
- "switch_id": "00:00:00:00:00:00:00:03"
+ "switch_id": "openflow:3"
}
]
}
"pathinfos": [
{
"in_port_name": "s1-eth1",
- "out_port_name": "s1-eth3",
- "switch_id": "00:00:00:00:00:00:00:01"
+ "out_port_name": "s1-eth2",
+ "switch_id": "openflow:1"
},
{
- "in_port_name": "s4-eth1",
- "out_port_name": "s4-eth2",
- "switch_id": "00:00:00:00:00:00:00:04"
+ "in_port_name": "s2-eth1",
+ "out_port_name": "s2-eth2",
+ "switch_id": "openflow:2"
},
{
- "in_port_name": "s3-eth2",
+ "in_port_name": "s3-eth1",
"out_port_name": "s3-eth3",
- "switch_id": "00:00:00:00:00:00:00:03"
+ "switch_id": "openflow:3"
}
]
}
----
curl --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:05-s5-eth2"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn3/vbridges/vbr2/interfaces/if1/portmap.json
----
+
===== Verification
Please verify whether Host h2 and Host h6 are pinging.
-* Send packets from h2 to h6
+* Send packets from h2 to h6
----
mininet> h2 ping h6
----
+----
+ PING 10.0.0.6 (10.0.0.3) 56(84) bytes of data.
+ 64 bytes from 10.0.0.6: icmp_req=1 ttl=64 time=0.780 ms
+ 64 bytes from 10.0.0.6: icmp_req=2 ttl=64 time=0.079 ms
+----
+
+NOTE: Add the default flow to OVS to forward packets to controller when there is a table-miss:
+----
+ovs-ofctl --protocols=OpenFlow13 add-flow <switch-name> priority=0,actions=output:CONTROLLER
+----
+
+These flows need to be added only in case of OpenFlow1.3 or using OVS versions (>2.1.1).
+
+Here the switch name is the switches in the topology such as s1,s2,s3.
+
h1 h1-eth0:s1-eth1
h2 h2-eth0:s2-eth2
----
+
+NOTE: Add the default flow to OVS to forward packets to controller when there is a table-miss:
+
+----
+ovs-ofctl --protocols=OpenFlow13 add-flow <switch-name> priority=0,actions=output:CONTROLLER
+----
+
+These flows need to be added only in case of OpenFlow1.3 or using OVS versions (>2.1.1).
+
+Here the switch name is the switches in the topology such as s1,s2,s3.
+
===== Configuration
* Create a Controller
* Send packets from Host1 to Host3
----
-|mininet> h1 ping 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.780 ms
+ 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.079 ms
----
h3 h3-eth0:s3-eth1
h4 h4-eth0:s3-eth2
----
+
+NOTE: Add the default flow to OVS to forward packets to controller when there is a table-miss:
+
+----
+ovs-ofctl --protocols=OpenFlow13 add-flow <switch-name> priority=0,actions=output:CONTROLLER
+----
+
+These flows need to be added only in case of OpenFlow1.3 or using OVS versions (>2.1.1).
+
+Here the switch name is the switches in the topology such as s1,s2,s3.
+
===== Configuration
* .Create a controller
----
-curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"controller": {"controller_id": "controller1", "ipaddr":"10.100.9.61", "type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8083/vtn-webapi/controllers
+curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"controller": {"controller_id": "controller1", "ipaddr":"10.100.9.61", "type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8083/vtn-webapi/controllers
----
* Create a VTN
----
-curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vtn" : {"vtn_name":"vtn_one","description":"test VTN" }}' http://127.0.0.1:8083/vtn-webapi/vtns.json
+curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vtn" : {"vtn_name":"vtn_one","description":"test VTN" }}' http://127.0.0.1:8083/vtn-webapi/vtns.json
----
* Create two vBridges
----
-curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vbridge" : {"vbr_name":"vbr_one^C"controller_id":"controller1","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges.json
+curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vbridge" : {"vbr_name":"vbr_one^C"controller_id":"controller1","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges.json
curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vbridge" :
{"vbr_name":"vbr_two","controller_id":"controller1","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges.json
----
* Create vBridge interfaces
----
-curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if1","description": "if_desc1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces.json
+curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if1","description": "if_desc1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces.json
curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if1","description": "if_desc1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces.json
----
* Configure two mappings on the interfaces
----
-curl -v --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:03-s3-eth1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/portmap.json
+curl --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:03-s3-eth1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/portmap.json
curl -v --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:02-s2-eth1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if2/portmap.json
----
* Create Flowlist
----
-curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"flowlist": {"fl_name": "flowlist1", "ip_version":"IP"}}' http://127.0.0.1:8083/vtn-webapi/flowlists.json
+curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"flowlist": {"fl_name": "flowlist1", "ip_version":"IP"}}' http://127.0.0.1:8083/vtn-webapi/flowlists.json
----
* Create Flowlistentry
----
-curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"flowlistentry": {"seqnum": "233","macethertype": "0x8000","ipdstaddr": "10.0.0.3","ipdstaddrprefix": "2","ipsrcaddr": "10.0.0.2","ipsrcaddrprefix": "2","ipproto": "17","ipdscp": "55","icmptypenum":"232","icmpcodenum": "232"}}' http://127.0.0.1:8083/vtn-webapi/flowlists/flowlist1/flowlistentries.json
+curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"flowlistentry": {"seqnum": "233","macethertype": "0x8000","ipdstaddr": "10.0.0.3","ipdstaddrprefix": "2","ipsrcaddr": "10.0.0.2","ipsrcaddrprefix": "2","ipproto": "17","ipdscp": "55","icmptypenum":"232","icmpcodenum": "232"}}' http://127.0.0.1:8083/vtn-webapi/flowlists/flowlist1/flowlistentries.json
----
* Create vBridge Interface Flowfilter
----
-curl -v --user admin:adminpass -X POST -H 'content-type: application/json' -d '{"flowfilter" : {"ff_type": "in"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/flowfilters.json
+curl --user admin:adminpass -X POST -H 'content-type: application/json' -d '{"flowfilter" : {"ff_type": "in"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/flowfilters.json
----
===== Flow filter demonstration with DROP action-type
----
-curl -v --user admin:adminpass -X POST -H 'content-type: application/json' -d '{"flowfilterentry": {"seqnum": "233", "fl_name": "flowlist1", "action_type":"drop", "priority":"3", "dscp":"55" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/flowfilters/in/flowfilterentries.json
+curl --user admin:adminpass -X POST -H 'content-type: application/json' -d '{"flowfilterentry": {"seqnum": "233", "fl_name": "flowlist1", "action_type":"drop", "priority":"3", "dscp":"55" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/flowfilters/in/flowfilterentries.json
----
===== Verification
As we have applied the action type "drop" , ping should fail.
===== Flow filter demonstration with PASS action-type
----
-curl -v --user admin:adminpass -X PUT -H 'content-type: application/json' -d '{"flowfilterentry": {"seqnum": "233", "fl_name": "flowlist1", "action_type":"pass", "priority":"3", "dscp":"55" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/flowfilters/in/flowfilterentries/233.json
+curl --user admin:adminpass -X PUT -H 'content-type: application/json' -d '{"flowfilterentry": {"seqnum": "233", "fl_name": "flowlist1", "action_type":"pass", "priority":"3", "dscp":"55" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn_one/vbridges/vbr_two/interfaces/if1/flowfilters/in/flowfilterentries/233.json
----
===== Verification
----
sudo mn --controller=remote,ip=192.168.64.13 --custom vlan_vtn_test.py --topo mytopo
----
+
+NOTE: Add the default flow to OVS to forward packets to controller when there is a table-miss:
+
+----
+ovs-ofctl --protocols=OpenFlow13 add-flow <switch-name> priority=0,actions=output:CONTROLLER
+----
+
+These flows need to be added only in case of OpenFlow1.3 or using OVS versions (>2.1.1).
+
+Here the switch name is the switches in the topology such as s1,s2,s3.
+
===== Configuration
Please follow the below steps to test a vlan map using mininet:
+
* Create a controller
----
This example demonstrates on how to view a specific VTN Dataflow information.
===== Configuration
-The same Configuration as Vlan Mapping Example(https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Coordinator:RestApi:How_to_test_vlan-map_in_Mininet_environment)
+The same Configuration as Vlan Mapping Example(https://wiki.opendaylight.org/view/VTN:Coordinator:Beryllium:HowTos:How_To_test_vlanmap_using_mininet)
===== Verification
Get the VTN Dataflows information
----
-curl -v -X GET -H 'content-type: application/json' --user 'admin:adminpass' "http://127.0.0.1:8083/vtn-webapi/dataflows?controller_id=controllerone&srcmacaddr=924c.e4a3.a743&vlan_id=300&switch_id=00:00:00:00:00:00:00:02&port_name=s2-eth1"
+curl -X GET -H 'content-type: application/json' --user 'admin:adminpass' "http://127.0.0.1:8083/vtn-webapi/dataflows?controller_id=controllerone&srcmacaddr=924c.e4a3.a743&vlan_id=300&switch_id=openflow:2&port_name=s2-eth1"
----
64 bytes from 10.0.0.2: icmp_req=2 ttl=64 time=13.2 ms
----
+NOTE: Add the default flow to OVS to forward packets to controller when there is a table-miss:
+
+----
+ovs-ofctl --protocols=OpenFlow13 add-flow <switch-name> priority=0,actions=output:CONTROLLER
+----
+
+These flows need to be added only in case of OpenFlow1.3 or using OVS versions (>2.1.1).
+
+Here the switch name is the switches in the topology such as s1,s2,s3.
+
===== Configuration
-.Create Controller
+
+* Create Controller
----
-curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"controller": {"controller_id": "controllerone", "ipaddr":"10.100.9.61", "type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8083/vtn-webapi/controllers.json
+curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"controller": {"controller_id": "controllerone", "ipaddr":"10.100.9.61", "type": "odc", "version": "1.0", "auditstatus":"enable"}}' http://127.0.0.1:8083/vtn-webapi/controllers.json
----
-.Create a VTN
+
+* Create a VTN
----
-curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vtn" : {"vtn_name":"vtn1","description":"test VTN" }}' http://127.0.0.1:8083/vtn-webapi/vtns.json
+curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vtn" : {"vtn_name":"vtn1","description":"test VTN" }}' http://127.0.0.1:8083/vtn-webapi/vtns.json
----
-.Create a vBridge in the VTN
+
+* Create a vBridge in the VTN
----
-curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vbridge" : {"vbr_name":"vBridge1","controller_id":"controllerone","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges.json
+curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"vbridge" : {"vbr_name":"vBridge1","controller_id":"controllerone","domain_id":"(DEFAULT)" }}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges.json
----
-.Create two Interfaces into the vBridge
+
+* Create two Interfaces into the vBridge
----
-curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if1","description": "if_desc1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces.json
+curl --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if1","description": "if_desc1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces.json
curl -v --user admin:adminpass -H 'content-type: application/json' -X POST -d '{"interface": {"if_name": "if2","description": "if_desc2"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces.json
----
-.Configure two mappings on the interfaces
+
+* Configure two mappings on the interfaces
----
-curl -v --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:01-s1-eth1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces/if1/portmap.json
+curl --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:01-s1-eth1"}}' http://127.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces/if1/portmap.json
curl -v --user admin:adminpass -H 'content-type: application/json' -X PUT -d '{"portmap":{"logical_port_id": "PP-OF:00:00:00:00:00:00:00:02-s2-eth2"}}' http://17.0.0.1:8083/vtn-webapi/vtns/vtn1/vbridges/vBridge1/interfaces/if2/portmap.json
----
-.Get the VTN stations information
+
+* Get the VTN stations information
----
-curl -v -X GET -H 'content-type: application/json' -H 'username: admin' -H 'password: adminpass' "http://127.0.0.1:8083/vtn-webapi/vtnstations?controller_id=controllerone&vtn_name=vtn1"
+curl -X GET -H 'content-type: application/json' -H 'username: admin' -H 'password: adminpass' "http://127.0.0.1:8083/vtn-webapi/vtnstations?controller_id=controllerone&vtn_name=vtn1"
----
===== Verification
----
-curl -v -X GET -H 'content-type: application/json' -H 'username: admin' -H 'password: adminpass' "http://127.0.0.1:8083/vtn-webapi/vtnstations?controller_id=controllerone&vtn_name=vtn1"
+curl -X GET -H 'content-type: application/json' -H 'username: admin' -H 'password: adminpass' "http://127.0.0.1:8083/vtn-webapi/vtnstations?controller_id=controllerone&vtn_name=vtn1"
{
"vtnstations": [
{
--- /dev/null
+==== How To Configure Flowfilters
+
+===== Overview
+
+* This page explains how to provision flowfilter using VTN Manager. This page targets Beryllium release, so the procedure described here does not work in other releases.
+
+* The flow-filter function discards, permits, or redirects packets of the traffic within a VTN, according to specified flow conditions. The table below lists the actions to be applied when a packet matches the condition:
+
+[options="header",cols="30%,70%"]
+|===
+| Action | Function
+| Pass | Permits the packet to pass along the determined path. +
+As options, packet transfer priority (set priority) and DSCP change (set ip-dscp) is specified.
+| Drop | Discards the packet.
+| Redirect | Redirects the packet to a desired virtual interface. +
+As an option, it is possible to change the MAC address when the packet is transferred.
+|===
+
+.Flow Filter Example
+image::vtn/flow_filter_example.png["Flow filter example",width=500]
+
+* Following steps explain flow-filter function:
+
+** when a packet is transferred to an interface within a virtual network, the flow-filter function evaluates whether the transferred packet matches the condition specifed in the flow-list.
+
+** If the packet matches the condition, the flow-filter applies the flow-list matching action specified in the flow-filter.
+
+===== Requirements
+
+To apply the packet filter, configure the following:
+
+* Create a flow condition.
+* Specify where to apply the flow-filter, for example VTN, vBridge, or interface of vBridge.
+
+To provision OpenFlow switches, this page uses Mininet. Mininet details and set-up can be referred at the below page:
+https://wiki.opendaylight.org/view/OpenDaylight_Controller:Installation#Using_Mininet
+
+Start Mininet, and create three switches (s1, s2, and s3) and four hosts (h1, h2, h3 and h4) in it.
+
+----
+sudo mn --controller=remote,ip=192.168.0.100 --topo tree,2
+----
+
+NOTE: Replace "192.168.0.100" with the IP address of OpenDaylight controller based on your environment.
+
+You can check the topology that you have created by executing "net" command in the Mininet console.
+
+----
+ mininet> net
+ h1 h1-eth0:s2-eth1
+ h2 h2-eth0:s2-eth2
+ h3 h3-eth0:s3-eth1
+ h4 h4-eth0:s3-eth2
+ s1 lo: s1-eth1:s2-eth3 s1-eth2:s3-eth3
+ s2 lo: s2-eth1:h1-eth0 s2-eth2:h2-eth0 s2-eth3:s1-eth1
+ s3 lo: s3-eth1:h3-eth0 s3-eth2:h4-eth0 s3-eth3:s1-eth2
+----
+
+In this guide, you will provision flowfilters to establish communication between h1 and h3.
+
+NOTE: You need to manually add flow entries to OpenFlow switches in the Mininet. The flow entries are needed to forward packets to controller when there is a table-miss. This configuration is required only in case of OpenFlow 1.3 or using OVS versions (>2.1.1).
+
+----
+sudo ovs-ofctl add-flow s1 priority=0,actions=output:CONTROLLER
+sudo ovs-ofctl add-flow s2 priority=0,actions=output:CONTROLLER
+sudo ovs-ofctl add-flow s3 priority=0,actions=output:CONTROLLER
+----
+
+===== Configuration
+
+To provision the virtual L2 network for the two hosts (h1 and h3), execute REST API provided by VTN Manager as follows. It uses curl command to call the REST API.
+
+* Create a virtual tenant named vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn.html#update-vtn[the update-vtn RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:update-vtn -d '{"input":{"tenant-name":"vtn1"}}'
+----
+
+* Create a virtual bridge named vbr1 in the tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vbridge.html#update-vbridge[the update-vbridge RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1"}}'
+----
+
+* Create two interfaces into the virtual bridge by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vinterface.html#update-vinterface[the update-vinterface RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1"}}'
+----
+
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if2"}}'
+----
+
+* Configure two mappings on the interfaces by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-port-map.html#set-port-map[the set-port-map RPC].
+
+** The interface if1 of the virtual bridge will be mapped to the port "s2-eth1" of the switch "openflow:2" of the Mininet.
+
+*** The h1 is connected to the port "s2-eth1".
+
+** The interface if2 of the virtual bridge will be mapped to the port "s3-eth1" of the switch "openflow:3" of the Mininet.
+
+*** The h3 is connected to the port "s3-eth1".
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if1", "node":"openflow:2", "port-name":"s2-eth1"}}'
+----
+
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if2", "node":"openflow:3", "port-name":"s3-eth1"}}'
+----
+
+* Create flowcondition named cond_1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-condition.html#set-flow-condition[the set-flow-condition RPC].
+
+** For option source and destination-network, get inet address of host h1 and h3 from mininet.
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:set-flow-condition -d '{"input":{"name":"cond_1", "vtn-flow-match":[{"vtn-ether-match":{},"vtn-inet-match":{"source-network":"10.0.0.1/32","protocol":1,"destination-network":"10.0.0.3/32"},"index":"1"}]}}'
+----
+
+* Flowfilter can be applied either in VTN, VBR or VBR Interfaces. Here in this page we provision flowfilter with VBR Interface and demonstrate with action type drop and then pass.
+
+* Flow filter demonstration with DROP action-type. Create Flowfilter in VBR Interface if1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-filter.html#set-flow-filter[the set-flow-filter RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input": {"tenant-name": "vtn1", "bridge-name": "vbr1","interface-name":"if1","vtn-flow-filter":[{"condition":"cond_1","vtn-drop-filter":{},"vtn-flow-action":[{"order": "1","vtn-set-inet-src-action":{"ipv4-address":"10.0.0.1/32"}},{"order": "2","vtn-set-inet-dst-action":{"ipv4-address":"10.0.0.3/32"}}],"index": "1"}]}}'
+----
+
+===== Verification of the drop filter
+
+* Please execute ping from h1 to h3. As we have applied the action type "drop" , ping should fail with no packet flows between hosts h1 and h3 as below,
+
+----
+ mininet> h1 ping h3
+----
+
+===== Configuration for pass filter
+
+* Update the flow filter to pass the packets by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-filter.html#set-flow-filter[the set-flow-filter RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input": {"tenant-name": "vtn1", "bridge-name": "vbr1","interface-name":"if1","vtn-flow-filter":[{"condition":"cond_1","vtn-pass-filter":{},"vtn-flow-action":[{"order": "1","vtn-set-inet-src-action":{"ipv4-address":"10.0.0.1/32"}},{"order": "2","vtn-set-inet-dst-action":{"ipv4-address":"10.0.0.3/32"}}],"index": "1"}]}}'
+----
+
+===== Verification For Packets Success
+
+* As we have applied action type PASS now ping should happen between hosts h1 and h3.
+
+----
+ mininet> h1 ping h3
+ PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
+ 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.984 ms
+ 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.110 ms
+ 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.098 ms
+----
+
+* You can also verify the configurations by executing the following REST API. It shows all configuration in VTN Manager.
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns/vtn/vtn1
+----
+
+----
+{
+ "vtn": [
+ {
+ "name": "vtn1",
+ "vtenant-config": {
+ "hard-timeout": 0,
+ "idle-timeout": 300,
+ "description": "creating vtn"
+ },
+ "vbridge": [
+ {
+ "name": "vbr1",
+ "vbridge-config": {
+ "age-interval": 600,
+ "description": "creating vBridge1"
+ },
+ "bridge-status": {
+ "state": "UP",
+ "path-faults": 0
+ },
+ "vinterface": [
+ {
+ "name": "if1",
+ "vinterface-status": {
+ "mapped-port": "openflow:2:1",
+ "state": "UP",
+ "entity-state": "UP"
+ },
+ "port-map-config": {
+ "vlan-id": 0,
+ "node": "openflow:2",
+ "port-name": "s2-eth1"
+ },
+ "vinterface-config": {
+ "description": "Creating if1 interface",
+ "enabled": true
+ },
+ "vinterface-input-filter": {
+ "vtn-flow-filter": [
+ {
+ "index": 1,
+ "condition": "cond_1",
+ "vtn-flow-action": [
+ {
+ "order": 1,
+ "vtn-set-inet-src-action": {
+ "ipv4-address": "10.0.0.1/32"
+ }
+ },
+ {
+ "order": 2,
+ "vtn-set-inet-dst-action": {
+ "ipv4-address": "10.0.0.3/32"
+ }
+ }
+ ],
+ "vtn-pass-filter": {}
+ },
+ {
+ "index": 10,
+ "condition": "cond_1",
+ "vtn-drop-filter": {}
+ }
+ ]
+ }
+ },
+ {
+ "name": "if2",
+ "vinterface-status": {
+ "mapped-port": "openflow:3:1",
+ "state": "UP",
+ "entity-state": "UP"
+ },
+ "port-map-config": {
+ "vlan-id": 0,
+ "node": "openflow:3",
+ "port-name": "s3-eth1"
+ },
+ "vinterface-config": {
+ "description": "Creating if2 interface",
+ "enabled": true
+ }
+ }
+ ]
+ }
+ ]
+ }
+ ]
+}
+----
+
+===== Cleaning Up
+
+* To clean up both VTN and flowcondition.
+
+* You can delete the virtual tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn.html#remove-vtn[the remove-vtn RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:remove-vtn -d '{"input":{"tenant-name":"vtn1"}}'
+----
+
+* You can delete the flowcondition cond_1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-condition.html#remove-flow-condition[the remove-flow-condition RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:remove-flow-condition -d '{"input":{"name":"cond_1"}}'
+----
+
--- /dev/null
+==== How To Configure Service Function Chaining using VTN Manager
+
+===== Overview
+
+This page explains how to configure VTN Manager for Service Chaining. This page targets Beryllium release, so the procedure described here does not work in other releases.
+
+.Service Chaining With One Service
+image::vtn/Service_Chaining_With_One_Service.png["Service Chaining With One Service",width=500]
+
+===== Requirements
+
+* Please refer to the https://wiki.opendaylight.org/view/VTN:Beryllium:Installation_Guide[Installation Pages] to run ODL with VTN Feature enabled.
+* Please ensure Bridge-Utils package is installed in mininet environment before running the mininet script.
+* To install Bridge-Utils package run sudo apt-get install bridge-utils (assuming Ubuntu is used to run mininet, If not then this is not required).
+* Save the mininet script given below as topo_handson.py and run the mininet script in the mininet environment where Mininet is installed.
+
+===== Mininet Script
+
+* https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Scripts:Mininet[Script for emulating network with multiple hosts].
+* Before executing the mininet script, please confirm Controller is up and running.
+* Run the mininet script.
+* Replace <path> and <Controller IP> based on your environment
+
+----
+sudo mn --controller=remote,ip=<Controller IP> --custom <path>\topo_handson.py --topo mytopo2
+----
+
+----
+ mininet> net
+ h11 h11-eth0:s1-eth1
+ h12 h12-eth0:s1-eth2
+ h21 h21-eth0:s2-eth1
+ h22 h22-eth0:s2-eth2
+ h23 h23-eth0:s2-eth3
+ srvc1 srvc1-eth0:s3-eth3 srvc1-eth1:s4-eth3
+ srvc2 srvc2-eth0:s3-eth4 srvc2-eth1:s4-eth4
+ s1 lo: s1-eth1:h11-eth0 s1-eth2:h12-eth0 s1-eth3:s2-eth4 s1-eth4:s3-eth2
+ s2 lo: s2-eth1:h21-eth0 s2-eth2:h22-eth0 s2-eth3:h23-eth0 s2-eth4:s1-eth3 s2-eth5:s4-eth1
+ s3 lo: s3-eth1:s4-eth2 s3-eth2:s1-eth4 s3-eth3:srvc1-eth0 s3-eth4:srvc2-eth0
+ s4 lo: s4-eth1:s2-eth5 s4-eth2:s3-eth1 s4-eth3:srvc1-eth1 s4-eth4:srvc2-eth1
+----
+
+===== Configurations
+
+====== Mininet
+
+* Please follow the below steps to configure the network in mininet as in the below image:
+
+.Mininet Configuration
+image::vtn/Mininet_Configuration.png["Mininet Configuration",width=500]
+
+====== Install flow entries
+
+* In mininet environment, install the following flow entries to send PACKET_IN to the controller.
+
+----
+ $ sudo ovs-ofctl add-flow s1 priority=0,actions=output:CONTROLLER
+ $ sudo ovs-ofctl add-flow s2 priority=0,actions=output:CONTROLLER
+ $ sudo ovs-ofctl add-flow s3 priority=0,actions=output:CONTROLLER
+ $ sudo ovs-ofctl add-flow s4 priority=0,actions=output:CONTROLLER
+----
+
+====== Configure service nodes
+
+* Please execute the following commands in the mininet console where mininet script is executed.
+
+----
+ mininet> srvc1 ip addr del 10.0.0.6/8 dev srvc1-eth0
+ mininet> srvc1 brctl addbr br0
+ mininet> srvc1 brctl addif br0 srvc1-eth0
+ mininet> srvc1 brctl addif br0 srvc1-eth1
+ mininet> srvc1 ifconfig br0 up
+ mininet> srvc1 tc qdisc add dev srvc1-eth1 root netem delay 200ms
+ mininet> srvc2 ip addr del 10.0.0.7/8 dev srvc2-eth0
+ mininet> srvc2 brctl addbr br0
+ mininet> srvc2 brctl addif br0 srvc2-eth0
+ mininet> srvc2 brctl addif br0 srvc2-eth1
+ mininet> srvc2 ifconfig br0 up
+ mininet> srvc2 tc qdisc add dev srvc2-eth1 root netem delay 300ms
+----
+
+===== Controller
+
+====== Multi-Tenancy
+
+* Please execute the below commands to configure the network topology in the controller as in the below image:
+
+.Tenant2
+image::vtn/Tenant2.png["Tenant2",width=500]
+
+====== Please execute the below commands in controller
+
+NOTE:
+The below commands are for the difference in behavior of Manager in Beryllium topology. The Link below has the details for this bug: https://bugs.opendaylight.org/show_bug.cgi?id=3818.
+
+----
+curl --user admin:admin -H 'content-type: application/json' -H 'ipaddr:127.0.0.1' -X PUT http://localhost:8181/restconf/config/vtn-static-topology:vtn-static-topology/static-edge-ports -d '{"static-edge-ports": {"static-edge-port": [ {"port": "openflow:3:3"}, {"port": "openflow:3:4"}, {"port": "openflow:4:3"}, {"port": "openflow:4:4"}]}}'
+----
+
+* Create a virtual tenant named vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn.html#update-vtn[the update-vtn RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:update-vtn -d '{"input":{"tenant-name":"vtn1","update-mode":"CREATE","operation":"SET","description":"creating vtn","idle-timeout":300,"hard-timeout":0}}'
+----
+
+* Create a virtual bridge named vbr1 in the tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vbridge.html#update-vbridge[the update-vbridge RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"creating vbr","tenant-name":"vtn1","bridge-name":"vbr1"}}'
+----
+
+* Create interface if1 into the virtual bridge vbr1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vinterface.html#update-vinterface[the update-vinterface RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vbrif1 interface","tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1"}}'
+----
+
+* Configure port mapping on the interface by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-port-map.html#set-port-map[the set-port-map RPC].
+
+** The interface if1 of the virtual bridge will be mapped to the port "s1-eth2" of the switch "openflow:1" of the Mininet.
+
+*** The h12 is connected to the port "s1-eth2".
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"vlan-id":0,"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1","node":"openflow:1","port-name":"s1-eth2"}}'
+----
+
+* Create interface if2 into the virtual bridge vbr1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vinterface.html#update-vinterface[the update-vinterface RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vbrif2 interface","tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if2"}}'
+----
+
+* Configure port mapping on the interface by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-port-map.html#set-port-map[the set-port-map RPC].
+
+** The interface if2 of the virtual bridge will be mapped to the port "s2-eth2" of the switch "openflow:2" of the Mininet.
+
+*** The h22 is connected to the port "s2-eth2".
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"vlan-id":0,"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if2","node":"openflow:2","port-name":"s2-eth2"}}'
+----
+
+* Create interface if3 into the virtual bridge vbr1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vinterface.html#update-vinterface[the update-vinterface RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vbrif3 interface","tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if3"}}'
+----
+
+* Configure port mapping on the interfaces by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-port-map.html#set-port-map[the set-port-map RPC].
+
+** The interface if3 of the virtual bridge will be mapped to the port "s2-eth3" of the switch "openflow:2" of the Mininet.
+
+*** The h23 is connected to the port "s2-eth3".
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"vlan-id":0,"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if3","node":"openflow:2","port-name":"s2-eth3"}}'
+----
+
+===== Traffic filtering
+
+* Create flowcondition named cond_1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-condition.html#set-flow-condition[the set-flow-condition RPC].
+
+** For option source and destination-network, get inet address of host h12(src) and h22(dst) from mininet.
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:set-flow-condition -d '{"input":{"operation":"SET","present":"false","name":"cond_1","vtn-flow-match":[{"index":1,"vtn-ether-match":{},"vtn-inet-match":{"source-network":"10.0.0.2/32","destination-network":"10.0.0.4/32"}}]}}'
+----
+
+* Flow filter demonstration with DROP action-type. Create Flowfilter in VBR Interface if1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-filter.html#set-flow-filter[the set-flow-filter RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input":{"output":"false","tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1","vtn-flow-filter":[{"condition":"cond_1","index":10,"vtn-drop-filter":{}}]}}'
+----
+
+===== Service Chaining
+
+====== With One Service
+
+* Please execute the below commands to configure the network topology which sends some specific traffic via a single service(External device) in the controller as in the below image:
+
+.Service Chaining With One Service LLD
+image::vtn/Service_Chaining_With_One_Service_LLD.png["Service Chaining With One Service LLD",width=500]
+
+* Create a virtual terminal named vt_srvc1_1 in the tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vterminal.html#update-vterminal[the update-vterminal RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vterminal:update-vterminal -d '{"input":{"update-mode":"CREATE","operation":"SET","tenant-name":"vtn1","terminal-name":"vt_srvc1_1","description":"Creating vterminal"}}'
+----
+
+* Create interface IF into the virtual terminal vt_srvc1_1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vinterface.html#update-vinterface[the update-vinterface RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vterminal IF","enabled":"true","tenant-name":"vtn1","terminal-name":"vt_srvc1_1","interface-name":"IF"}}'
+----
+
+* Configure port mapping on the interfaces by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-port-map.html#set-port-map[the set-port-map RPC].
+
+** The interface IF of the virtual terminal will be mapped to the port "s3-eth3" of the switch "openflow:3" of the Mininet.
+
+*** The h12 is connected to the port "s3-eth3".
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1","terminal-name":"vt_srvc1_1","interface-name":"IF","node":"openflow:3","port-name":"s3-eth3"}}'
+----
+
+* Create a virtual terminal named vt_srvc1_2 in the tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vterminal.html#update-vterminal[the update-vterminal RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vterminal:update-vterminal -d '{"input":{"update-mode":"CREATE","operation":"SET","tenant-name":"vtn1","terminal-name":"vt_srvc1_2","description":"Creating vterminal"}}'
+----
+
+* Create interface IF into the virtual terminal vt_srvc1_2 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vinterface.html#update-vinterface[the update-vinterface RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vterminal IF","enabled":"true","tenant-name":"vtn1","terminal-name":"vt_srvc1_2","interface-name":"IF"}}'
+----
+
+* Configure port mapping on the interfaces by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-port-map.html#set-port-map[the set-port-map RPC].
+
+** The interface IF of the virtual terminal will be mapped to the port "s4-eth3" of the switch "openflow:4" of the Mininet.
+
+*** The h22 is connected to the port "s4-eth3".
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1","terminal-name":"vt_srvc1_2","interface-name":"IF","node":"openflow:4","port-name":"s4-eth3"}}'
+----
+
+* Create flowcondition named cond_1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-condition.html#set-flow-condition[the set-flow-condition RPC].
+
+** For option source and destination-network, get inet address of host h12(src) and h22(dst) from mininet.
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:set-flow-condition -d '{"input":{"operation":"SET","present":"false","name":"cond_1","vtn-flow-match":[{"index":1,"vtn-ether-match":{},"vtn-inet-match":{"source-network":"10.0.0.2/32","destination-network":"10.0.0.4/32"}}]}}'
+----
+
+* Create flowcondition named cond_any by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-condition.html#set-flow-condition[the set-flow-condition RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:set-flow-condition -d '{"input":{"operation":"SET","present":"false","name":"cond_any","vtn-flow-match":[{"index":1}]}}'
+----
+
+* Flow filter demonstration with redirect action-type. Create Flowfilter in virtual terminal vt_srvc1_2 interface IF by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-filter.html#set-flow-filter[the set-flow-filter RPC].
+
+** Flowfilter redirects vt_srvc1_2 to bridge1-IF2
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input":{"output":"false","tenant-name":"vtn1","terminal-name":"vt_srvc1_2","interface-name":"IF","vtn-flow-filter":[{"condition":"cond_any","index":10,"vtn-redirect-filter":{"redirect-destination":{"bridge-name":"vbr1","interface-name":"if2"},"output":"true"}}]}}'
+----
+
+* Flow filter demonstration with redirect action-type. Create Flowfilter in vbridge vbr1 interface if1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-filter.html#set-flow-filter[the set-flow-filter RPC].
+
+** Flow filter redirects Bridge1-IF1 to vt_srvc1_1
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input":{"output":"false","tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1","vtn-flow-filter":[{"condition":"cond_1","index":10,"vtn-redirect-filter":{"redirect-destination":{"terminal-name":"vt_srvc1_1","interface-name":"IF"},"output":"true"}}]}}'
+----
+
+===== Verification
+
+.Service Chaining With One Service
+image::vtn/Service_Chaining_With_One_Service_Verification.png["Service Chaining With One Service Verification",width=500]
+
+* Ping host12 to host22 to view the host rechability, a delay of 200ms will be taken to reach host22 as below.
+
+----
+ mininet> h12 ping h22
+ PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
+ 64 bytes from 10.0.0.4: icmp_seq=35 ttl=64 time=209 ms
+ 64 bytes from 10.0.0.4: icmp_seq=36 ttl=64 time=201 ms
+ 64 bytes from 10.0.0.4: icmp_seq=37 ttl=64 time=200 ms
+ 64 bytes from 10.0.0.4: icmp_seq=38 ttl=64 time=200 ms
+----
+
+====== With two services
+
+* Please execute the below commands to configure the network topology which sends some specific traffic via two services(External device) in the controller as in the below image.
+
+.Service Chaining With Two Services LLD
+image::vtn/Service_Chaining_With_Two_Services_LLD.png["Service Chaining With Two Services LLD",width=500]
+
+* Create a virtual terminal named vt_srvc2_1 in the tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vterminal.html#update-vterminal[the update-vterminal RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vterminal:update-vterminal -d '{"input":{"update-mode":"CREATE","operation":"SET","tenant-name":"vtn1","terminal-name":"vt_srvc2_1","description":"Creating vterminal"}}'
+----
+
+* Create interface IF into the virtual terminal vt_srvc2_1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vinterface.html#update-vinterface[the update-vinterface RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vterminal IF","enabled":"true","tenant-name":"vtn1","terminal-name":"vt_srvc2_1","interface-name":"IF"}}'
+----
+
+* Configure port mapping on the interfaces by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-port-map.html#set-port-map[the set-port-map RPC].
+
+** The interface IF of the virtual terminal will be mapped to the port "s3-eth4" of the switch "openflow:3" of the Mininet.
+
+*** The host h12 is connected to the port "s3-eth4".
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1","terminal-name":"vt_srvc2_1","interface-name":"IF","node":"openflow:3","port-name":"s3-eth4"}}'
+----
+
+* Create a virtual terminal named vt_srvc2_2 in the tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vterminal.html#update-vterminal[the update-vterminal RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vterminal:update-vterminal -d '{"input":{"update-mode":"CREATE","operation":"SET","tenant-name":"vtn1","terminal-name":"vt_srvc2_2","description":"Creating vterminal"}}'
+----
+
+* Create interfaces IF into the virtual terminal vt_srvc2_2 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vinterface.html#update-vinterface[the update-vinterface RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"update-mode":"CREATE","operation":"SET","description":"Creating vterminal IF","enabled":"true","tenant-name":"vtn1","terminal-name":"vt_srvc2_2","interface-name":"IF"}}'
+----
+
+* Configure port mapping on the interfaces by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-port-map.html#set-port-map[the set-port-map RPC].
+
+** The interface IF of the virtual terminal will be mapped to the port "s4-eth4" of the switch "openflow:4" of the mininet.
+
+*** The host h22 is connected to the port "s4-eth4".
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1","terminal-name":"vt_srvc2_2","interface-name":"IF","node":"openflow:4","port-name":"s4-eth4"}}'
+----
+
+* Flow filter demonstration with redirect action-type. Create Flowfilter in virtual terminal vt_srvc2_2 interface IF by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-filter.html#set-flow-filter[the set-flow-filter RPC].
+
+** Flow filter redirects vt_srvc2_2 to Bridge1-IF2.
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input":{"output":"false","tenant-name":"vtn1","terminal-name":"vt_srvc2_2","interface-name":"IF","vtn-flow-filter":[{"condition":"cond_any","index":10,"vtn-redirect-filter":{"redirect-destination":{"bridge-name":"vbr1","interface-name":"if2"},"output":"true"}}]}}'
+----
+
+* Flow filter demonstration with redirect action-type. Create Flowfilter in virtual terminal vt_srvc2_2 interface IF by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-filter.html#set-flow-filter[the set-flow-filter RPC].
+
+** Flow filter redirects vt_srvc1_2 to vt_srvc2_1.
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-filter:set-flow-filter -d '{"input":{"output":"false","tenant-name":"vtn1","terminal-name":"vt_srvc1_2","interface-name":"IF","vtn-flow-filter":[{"condition":"cond_any","index":10,"vtn-redirect-filter":{"redirect-destination":{"terminal-name":"vt_srvc2_1","interface-name":"IF"},"output":"true"}}]}}'
+----
+
+===== Verification
+
+.Service Chaining With Two Service
+image::vtn/Service_Chaining_With_Two_Services.png["Service Chaining With Two Services",width=500]
+
+* Ping host12 to host22 to view the host rechability, a delay of 500ms will be taken to reach host22 as below.
+
+----
+ mininet> h12 ping h22
+ PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
+ 64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=512 ms
+ 64 bytes from 10.0.0.4: icmp_seq=2 ttl=64 time=501 ms
+ 64 bytes from 10.0.0.4: icmp_seq=3 ttl=64 time=500 ms
+ 64 bytes from 10.0.0.4: icmp_seq=4 ttl=64 time=500 ms
+----
+
+* You can verify the configuration by executing the following REST API. It shows all configuration in VTN Manager.
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns
+----
+
+----
+{
+ "vtn": [
+ {
+ "name": "vtn1",
+ "vtenant-config": {
+ "hard-timeout": 0,
+ "idle-timeout": 300,
+ "description": "creating vtn"
+ },
+ "vbridge": [
+ {
+ "name": "vbr1",
+ "vbridge-config": {
+ "age-interval": 600,
+ "description": "creating vbr"
+ },
+ "bridge-status": {
+ "state": "UP",
+ "path-faults": 0
+ },
+ "vinterface": [
+ {
+ "name": "if1",
+ "vinterface-status": {
+ "mapped-port": "openflow:1:2",
+ "state": "UP",
+ "entity-state": "UP"
+ },
+ "port-map-config": {
+ "vlan-id": 0,
+ "node": "openflow:1",
+ "port-name": "s1-eth2"
+ },
+ "vinterface-config": {
+ "description": "Creating vbrif1 interface",
+ "enabled": true
+ },
+ "vinterface-input-filter": {
+ "vtn-flow-filter": [
+ {
+ "index": 10,
+ "condition": "cond_1",
+ "vtn-redirect-filter": {
+ "output": true,
+ "redirect-destination": {
+ "terminal-name": "vt_srvc1_1",
+ "interface-name": "IF"
+ }
+ }
+ }
+ ]
+ }
+ },
+ {
+ "name": "if2",
+ "vinterface-status": {
+ "mapped-port": "openflow:2:2",
+ "state": "UP",
+ "entity-state": "UP"
+ },
+ "port-map-config": {
+ "vlan-id": 0,
+ "node": "openflow:2",
+ "port-name": "s2-eth2"
+ },
+ "vinterface-config": {
+ "description": "Creating vbrif2 interface",
+ "enabled": true
+ }
+ },
+ {
+ "name": "if3",
+ "vinterface-status": {
+ "mapped-port": "openflow:2:3",
+ "state": "UP",
+ "entity-state": "UP"
+ },
+ "port-map-config": {
+ "vlan-id": 0,
+ "node": "openflow:2",
+ "port-name": "s2-eth3"
+ },
+ "vinterface-config": {
+ "description": "Creating vbrif3 interface",
+ "enabled": true
+ }
+ }
+ ]
+ }
+ ],
+ "vterminal": [
+ {
+ "name": "vt_srvc2_2",
+ "bridge-status": {
+ "state": "UP",
+ "path-faults": 0
+ },
+ "vinterface": [
+ {
+ "name": "IF",
+ "vinterface-status": {
+ "mapped-port": "openflow:4:4",
+ "state": "UP",
+ "entity-state": "UP"
+ },
+ "port-map-config": {
+ "vlan-id": 0,
+ "node": "openflow:4",
+ "port-name": "s4-eth4"
+ },
+ "vinterface-config": {
+ "description": "Creating vterminal IF",
+ "enabled": true
+ },
+ "vinterface-input-filter": {
+ "vtn-flow-filter": [
+ {
+ "index": 10,
+ "condition": "cond_any",
+ "vtn-redirect-filter": {
+ "output": true,
+ "redirect-destination": {
+ "bridge-name": "vbr1",
+ "interface-name": "if2"
+ }
+ }
+ }
+ ]
+ }
+ }
+ ],
+ "vterminal-config": {
+ "description": "Creating vterminal"
+ }
+ },
+ {
+ "name": "vt_srvc1_1",
+ "bridge-status": {
+ "state": "UP",
+ "path-faults": 0
+ },
+ "vinterface": [
+ {
+ "name": "IF",
+ "vinterface-status": {
+ "mapped-port": "openflow:3:3",
+ "state": "UP",
+ "entity-state": "UP"
+ },
+ "port-map-config": {
+ "vlan-id": 0,
+ "node": "openflow:3",
+ "port-name": "s3-eth3"
+ },
+ "vinterface-config": {
+ "description": "Creating vterminal IF",
+ "enabled": true
+ }
+ }
+ ],
+ "vterminal-config": {
+ "description": "Creating vterminal"
+ }
+ },
+ {
+ "name": "vt_srvc1_2",
+ "bridge-status": {
+ "state": "UP",
+ "path-faults": 0
+ },
+ "vinterface": [
+ {
+ "name": "IF",
+ "vinterface-status": {
+ "mapped-port": "openflow:4:3",
+ "state": "UP",
+ "entity-state": "UP"
+ },
+ "port-map-config": {
+ "vlan-id": 0,
+ "node": "openflow:4",
+ "port-name": "s4-eth3"
+ },
+ "vinterface-config": {
+ "description": "Creating vterminal IF",
+ "enabled": true
+ },
+ "vinterface-input-filter": {
+ "vtn-flow-filter": [
+ {
+ "index": 10,
+ "condition": "cond_any",
+ "vtn-redirect-filter": {
+ "output": true,
+ "redirect-destination": {
+ "terminal-name": "vt_srvc2_1",
+ "interface-name": "IF"
+ }
+ }
+ }
+ ]
+ }
+ }
+ ],
+ "vterminal-config": {
+ "description": "Creating vterminal"
+ }
+ },
+ {
+ "name": "vt_srvc2_1",
+ "bridge-status": {
+ "state": "UP",
+ "path-faults": 0
+ },
+ "vinterface": [
+ {
+ "name": "IF",
+ "vinterface-status": {
+ "mapped-port": "openflow:3:4",
+ "state": "UP",
+ "entity-state": "UP"
+ },
+ "port-map-config": {
+ "vlan-id": 0,
+ "node": "openflow:3",
+ "port-name": "s3-eth4"
+ },
+ "vinterface-config": {
+ "description": "Creating vterminal IF",
+ "enabled": true
+ }
+ }
+ ],
+ "vterminal-config": {
+ "description": "Creating vterminal"
+ }
+ }
+ ]
+ }
+ ]
+}
+----
+
+===== Cleaning Up
+
+* To clean up both VTN and flowconditions.
+
+* You can delete the virtual tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn.html#remove-vtn[the remove-vtn RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:remove-vtn -d '{"input":{"tenant-name":"vtn1"}}'
+----
+
+* You can delete the flowcondition cond_1 and cond_any by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-condition.html#remove-flow-condition[the remove-flow-condition RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:remove-flow-condition -d '{"input":{"name":"cond_1"}}'
+----
+
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:remove-flow-condition -d '{"input":{"name":"cond_any"}}'
+----
+
--- /dev/null
+==== How To Create Mac Map In VTN
+
+===== Overview
+
+* This page demonstrates Mac Mapping. This demonstration aims at enabling communication between two hosts and denying communication of particular host by associating a Vbridge to the hosts and configuring Mac Mapping (mac address) to the Vbridge.
+
+* This page targets Beryllium release, so the procedure described here does not work in other releases.
+
+.Single Controller Mapping
+image::vtn/Single_Controller_Mapping.png["Single_Controller_Mapping",width=500]
+
+===== Requirement
+
+====== Configure mininet and create a topology
+
+* https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Scripts:Mininet#Network_with_Multiple_Hosts_for_Service_Function_Chain[Script for emulating network with multiple hosts].
+* Before executing the mininet script, please confirm Controller is up and running.
+* Run the mininet script.
+* Replace <path> and <Controller IP> based on your environment.
+
+----
+sudo mn --controller=remote,ip=<Controller IP> --custom <path>\topo_handson.py --topo mytopo2
+----
+
+----
+mininet> net
+h11 h11-eth0:s1-eth1
+h12 h12-eth0:s1-eth2
+h21 h21-eth0:s2-eth1
+h22 h22-eth0:s2-eth2
+h23 h23-eth0:s2-eth3
+srvc1 srvc1-eth0:s3-eth3 srvc1-eth1:s4-eth3
+srvc2 srvc2-eth0:s3-eth4 srvc2-eth1:s4-eth4
+s1 lo: s1-eth1:h11-eth0 s1-eth2:h12-eth0 s1-eth3:s2-eth4 s1-eth4:s3-eth2
+s2 lo: s2-eth1:h21-eth0 s2-eth2:h22-eth0 s2-eth3:h23-eth0 s2-eth4:s1-eth3 s2-eth5:s4-eth1
+s3 lo: s3-eth1:s4-eth2 s3-eth2:s1-eth4 s3-eth3:srvc1-eth0 s3-eth4:srvc2-eth0
+s4 lo: s4-eth1:s2-eth5 s4-eth2:s3-eth1 s4-eth3:srvc1-eth1 s4-eth4:srvc2-eth1
+----
+
+NOTE:
+You need to manually add flow entries to OpenFlow switches in the Mininet. The flow entries are needed to forward packets to controller when there is a table-miss. This configuration is required only in case of OpenFlow 1.3 or using OVS versions (>2.1.1).
+
+----
+sudo ovs-ofctl add-flow s1 priority=0,actions=output:CONTROLLER
+sudo ovs-ofctl add-flow s2 priority=0,actions=output:CONTROLLER
+sudo ovs-ofctl add-flow s3 priority=0,actions=output:CONTROLLER
+sudo ovs-ofctl add-flow s4 priority=0,actions=output:CONTROLLER
+----
+
+===== Configuration
+
+To create Mac Map in VTN, execute REST API provided by VTN Manager as follows. It uses curl command to call REST API.
+
+* Create a virtual tenant named Tenant1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn.html#update-vtn[the update-vtn RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:update-vtn -d '{"input":{"tenant-name":"Tenant1"}}'
+----
+
+* Create a virtual bridge named vBridge1 in the tenant Tenant1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vbridge.html#update-vbridge[the update-vbridge RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"Tenant1","bridge-name":"vBridge1"}}'
+----
+
+* Configuring Mac Mappings on the vBridge1 by giving the mac address of host h12 and host h22 as follows to allow the communication by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-mac-map.html#set-mac-map[the set-mac-map RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-mac-map:set-mac-map -d '{"input":{"operation":"SET","allowed-hosts":["de:05:40:c4:96:76@0","62:c5:33:bc:d7:4e@0"],"tenant-name":"Tenant1","bridge-name":"vBridge1"}}'
+----
+
+NOTE: Mac Address of host h12 and host h22 can be obtained with the following command in mininet.
+
+----
+ mininet> h12 ifconfig
+ h12-eth0 Link encap:Ethernet HWaddr 62:c5:33:bc:d7:4e
+ inet addr:10.0.0.2 Bcast:10.255.255.255 Mask:255.0.0.0
+ inet6 addr: fe80::60c5:33ff:febc:d74e/64 Scope:Link
+----
+
+----
+ mininet> h22 ifconfig
+ h22-eth0 Link encap:Ethernet HWaddr de:05:40:c4:96:76
+ inet addr:10.0.0.4 Bcast:10.255.255.255 Mask:255.0.0.0
+ inet6 addr: fe80::dc05:40ff:fec4:9676/64 Scope:Link
+----
+
+* MAC Mapping will not be activated just by configuring it, a two end communication needs to be established to activate Mac Mapping.
+
+* Ping host h22 from host h12 in mininet, the ping will not happen between the hosts as only one way activation is enabled.
+
+----
+ mininet> h12 ping h22
+ PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
+ From 10.0.0.2 icmp_seq=1 Destination Host Unreachable
+ From 10.0.0.2 icmp_seq=2 Destination Host Unreachable
+----
+
+* Ping host h12 from host h22 in mininet, now the ping communication will take place as the two end communication is enabled.
+
+----
+ mininet> h22 ping h12
+ PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
+ 64 bytes from 10.0.0.2: icmp_req=1 ttl=64 time=91.8 ms
+ 64 bytes from 10.0.0.2: icmp_req=2 ttl=64 time=0.510 ms
+----
+
+* After two end communication enabled, now host h12 can ping host h22
+
+----
+ mininet> h12 ping h22
+ PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
+ 64 bytes from 10.0.0.4: icmp_req=1 ttl=64 time=0.780 ms
+ 64 bytes from 10.0.0.4: icmp_req=2 ttl=64 time=0.079 ms
+----
+
+===== Verification
+
+* To view the configured Mac Map of allowed host execute the following command.
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns/vtn/Tenant1/vbridge/vBridge1/mac-map
+----
+
+----
+{
+ "mac-map": {
+ "mac-map-status": {
+ "mapped-host": [
+ {
+ "mac-address": "c6:44:22:ba:3e:72",
+ "vlan-id": 0,
+ "port-id": "openflow:1:2"
+ },
+ {
+ "mac-address": "f6:e0:43:b6:3a:b7",
+ "vlan-id": 0,
+ "port-id": "openflow:2:2"
+ }
+ ]
+ },
+ "mac-map-config": {
+ "allowed-hosts": {
+ "vlan-host-desc-list": [
+ {
+ "host": "c6:44:22:ba:3e:72@0"
+ },
+ {
+ "host": "f6:e0:43:b6:3a:b7@0"
+ }
+ ]
+ }
+ }
+ }
+}
+----
+
+NOTE:
+When Deny is configured a broadcast message is sent to all the hosts connected to the vBridge, so a two end communication need not be establihed like allow, the hosts can communicate directly without any two way communication enabled.
+
+. To Deny host h23 communication from hosts connected on vBridge1, the following configuration can be applied.
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-mac-map:set-mac-map -d '{"input":{"operation": "SET", "denied-hosts": ["0a:d3:ea:3d:8f:a5@0"],"tenant-name": "Tenant1","bridge-name": "vBridge1"}}'
+----
+
+===== Cleaning Up
+
+* You can delete the virtual tenant Tenant1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn.html#remove-vtn[the remove-vtn RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:remove-vtn -d '{"input":{"tenant-name":"Tenant1"}}'
+----
+
--- /dev/null
+==== How to provision virtual L2 Network
+
+===== Overview
+
+This page explains how to provision virtual L2 network using VTN Manager. This page targets Beryllium release, so the procedure described here does not work in other releases.
+
+.EXAMPLE DEMONSTRATING SINGLE CONTROLLER
+image::vtn/vtn-single-controller-topology-example.png[EXAMPLE DEMONSTRATING SINGLE CONTROLLER]
+
+===== Requirements
+
+====== Mininet
+
+* To provision OpenFlow switches, this page uses Mininet. Mininet details and set-up can be referred at the following page:
+https://wiki.opendaylight.org/view/OpenDaylight_Controller:Installation#Using_Mininet
+
+* Start Mininet and create three switches(s1, s2, and s3) and four hosts(h1, h2, h3, and h4) in it.
+
+----
+ mininet@mininet-vm:~$ sudo mn --controller=remote,ip=192.168.0.100 --topo tree,2
+----
+
+NOTE:
+Replace "192.168.0.100" with the IP address of OpenDaylight controller based on your environment.
+
+* you can check the topology that you have created by executing "net" command in the Mininet console.
+
+----
+ mininet> net
+ h1 h1-eth0:s2-eth1
+ h2 h2-eth0:s2-eth2
+ h3 h3-eth0:s3-eth1
+ h4 h4-eth0:s3-eth2
+ s1 lo: s1-eth1:s2-eth3 s1-eth2:s3-eth3
+ s2 lo: s2-eth1:h1-eth0 s2-eth2:h2-eth0 s2-eth3:s1-eth1
+ s3 lo: s3-eth1:h3-eth0 s3-eth2:h4-eth0 s3-eth3:s1-eth2
+----
+
+* In this guide, you will provision the virtual L2 network to establish communication between h1 and h3.
+
+* You need to manually add flow entries to OpenFlow switches in the Mininet. The flow entries are needed to forward packets to controller when there is a table-miss. This configuration is required only in case of Openflow 1.3 or using OVS version(>2.1.1).
+
+----
+ sudo ovs-ofctl add-flow s1 priority=0,actions=output:CONTROLLER
+ sudo ovs-ofctl add-flow s2 priority=0,actions=output:CONTROLLER
+ sudo ovs-ofctl add-flow s3 priority=0,actions=output:CONTROLLER
+----
+
+===== Configuration
+
+To provision the virtual L2 network for the two hosts (h1 and h3), execute REST API provided by VTN Manager as follows. It uses curl command to call the REST API.
+
+* Create a virtual tenant named vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn.html#update-vtn[the update-vtn RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:update-vtn -d '{"input":{"tenant-name":"vtn1"}}'
+----
+
+* Create a virtual bridge named vbr1 in the tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vbridge.html#update-vbridge[the update-vbridge RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1"}}'
+----
+
+* Create two interfaces into the virtual bridge by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vinterface.html#update-vinterface[the update-vinterface RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if1"}}'
+----
+
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if2"}}'
+----
+
+* Configure two mappings on the created interfaces by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-port-map.html#set-port-map[the set-port-map RPC].
+
+** The interface if1 of the virtual bridge will be mapped to the port "s2-eth1" of the switch "openflow:2" of the Mininet.
+*** The h1 is connected to the port "s2-eth1".
+
+** The interface if2 of the virtual bridge will be mapped to the port "s3-eth1" of the switch "openflow:3" of the Mininet.
+*** The h3 is connected to the port "s3-eth1".
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if1", "node":"openflow:2", "port-name":"s2-eth1"}}'
+----
+
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if2", "node":"openflow:3", "port-name":"s3-eth1"}}'
+----
+
+===== Verification
+
+* Please execute ping from h1 to h3 to verify if the virtual L2 network for h1 and h3 is provisioned successfully.
+
+----
+ mininet> h1 ping h3
+ PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
+ 64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=243 ms
+ 64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=0.341 ms
+ 64 bytes from 10.0.0.3: icmp_seq=3 ttl=64 time=0.078 ms
+ 64 bytes from 10.0.0.3: icmp_seq=4 ttl=64 time=0.079 ms
+----
+
+* You can also verify the configuration by executing the following REST API. It shows all configuration in VTN Manager.
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns/
+----
+
+* The result of the command should be like this.
+
+----
+{
+ "vtns": {
+ "vtn": [
+ {
+ "name": "vtn1",
+ "vtenant-config": {
+ "idle-timeout": 300,
+ "hard-timeout": 0
+ },
+ "vbridge": [
+ {
+ "name": "vbr1",
+ "bridge-status": {
+ "state": "UP",
+ "path-faults": 0
+ },
+ "vbridge-config": {
+ "age-interval": 600
+ },
+ "vinterface": [
+ {
+ "name": "if2",
+ "vinterface-status": {
+ "entity-state": "UP",
+ "state": "UP",
+ "mapped-port": "openflow:3:3"
+ },
+ "vinterface-config": {
+ "enabled": true
+ },
+ "port-map-config": {
+ "vlan-id": 0,
+ "port-name": "s3-eth1",
+ "node": "openflow:3"
+ }
+ },
+ {
+ "name": "if1",
+ "vinterface-status": {
+ "entity-state": "UP",
+ "state": "UP",
+ "mapped-port": "openflow:2:1"
+ },
+ "vinterface-config": {
+ "enabled": true
+ },
+ "port-map-config": {
+ "vlan-id": 0,
+ "port-name": "s2-eth1",
+ "node": "openflow:2"
+ }
+ }
+ ]
+ }
+ ]
+ }
+ ]
+ }
+}
+----
+
+===== Cleaning Up
+
+* You can delete the virtual tenant vtn1 by executing
+https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn.html#remove-vtn[the remove-vtn RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:remove-vtn -d '{"input":{"tenant-name":"vtn1"}}'
+----
+
+
+
--- /dev/null
+==== How to use VTN to change the path of the packet flow
+
+===== Overview
+
+* This page explains how to create specific VTN Pathmap using VTN Manager. This page targets Beryllium release, so the procedure described here does not work in other releases.
+
+.Pathmap
+image::vtn/Pathmap.png["Pathmap",width=500]
+
+===== Requirement
+
+* Save the mininet script given below as pathmap_test.py and run the mininet script in the mininet environment where Mininet is installed.
+
+* Create topology using the below mininet script:
+
+----
+ from mininet.topo import Topo
+ class MyTopo( Topo ):
+ "Simple topology example."
+ def __init__( self ):
+ "Create custom topo."
+ # Initialize topology
+ Topo.__init__( self )
+ # Add hosts and switches
+ leftHost = self.addHost( 'h1' )
+ rightHost = self.addHost( 'h2' )
+ leftSwitch = self.addSwitch( 's1' )
+ middleSwitch = self.addSwitch( 's2' )
+ middleSwitch2 = self.addSwitch( 's4' )
+ rightSwitch = self.addSwitch( 's3' )
+ # Add links
+ self.addLink( leftHost, leftSwitch )
+ self.addLink( leftSwitch, middleSwitch )
+ self.addLink( leftSwitch, middleSwitch2 )
+ self.addLink( middleSwitch, rightSwitch )
+ self.addLink( middleSwitch2, rightSwitch )
+ self.addLink( rightSwitch, rightHost )
+ topos = { 'mytopo': ( lambda: MyTopo() ) }
+----
+
+* After creating new file with the above script start the mininet as below,
+
+----
+sudo mn --controller=remote,ip=10.106.138.124 --custom pathmap_test.py --topo mytopo
+----
+
+NOTE: Replace "10.106.138.124" with the IP address of OpenDaylight controller based on your environment.
+
+----
+ mininet> net
+ h1 h1-eth0:s1-eth1
+ h2 h2-eth0:s3-eth3
+ s1 lo: s1-eth1:h1-eth0 s1-eth2:s2-eth1 s1-eth3:s4-eth1
+ s2 lo: s2-eth1:s1-eth2 s2-eth2:s3-eth1
+ s3 lo: s3-eth1:s2-eth2 s3-eth2:s4-eth2 s3-eth3:h2-eth0
+ s4 lo: s4-eth1:s1-eth3 s4-eth2:s3-eth2
+ c0
+----
+
+NOTE: You need to manually add flow entries to OpenFlow switches in the Mininet. The flow entries are needed to forward packets to controller when there is a table-miss. This configuration is required only in case of OpenFlow 1.3 or using OVS versions (>2.1.1).
+
+----
+ sudo ovs-ofctl add-flow s1 priority=0,actions=output:CONTROLLER
+ sudo ovs-ofctl add-flow s2 priority=0,actions=output:CONTROLLER
+ sudo ovs-ofctl add-flow s3 priority=0,actions=output:CONTROLLER
+----
+
+* Generate traffic by pinging between host h1 and host h2 before creating the portmaps respectively.
+
+----
+ mininet> h1 ping h2
+ PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
+ From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
+ From 10.0.0.1 icmp_seq=2 Destination Host Unreachable
+ From 10.0.0.1 icmp_seq=3 Destination Host Unreachable
+ From 10.0.0.1 icmp_seq=4 Destination Host Unreachable
+----
+
+===== Configuration
+
+* To change the path of the packet flow, execute REST API provided by VTN Manager as follows. It uses curl command to call the REST API.
+
+* Create a virtual tenant named vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn.html#update-vtn[the update-vtn RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:update-vtn -d '{"input":{"tenant-name":"vtn1"}}'
+----
+
+* Create a virtual bridge named vbr1 in the tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vbridge.html#update-vbridge[the update-vbridge RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1"}}'
+----
+
+* Create two interfaces into the virtual bridge by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vinterface.html#update-vinterface[the update-vinterface RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if1"}}'
+----
+
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vinterface:update-vinterface -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1","interface-name":"if2"}}'
+----
+
+* Configure two mappings on the interfaces by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-port-map.html#set-port-map[the set-port-map RPC].
+
+** The interface if1 of the virtual bridge will be mapped to the port "s2-eth1" of the switch "openflow:1" of the Mininet.
+
+*** The h1 is connected to the port "s1-eth1".
+
+** The interface if2 of the virtual bridge will be mapped to the port "s3-eth1" of the switch "openflow:3" of the Mininet.
+
+*** The h3 is connected to the port "s3-eth3".
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if1", "node":"openflow:1", "port-name":"s1-eth1"}}'
+----
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-port-map:set-port-map -d '{"input":{"tenant-name":"vtn1", "bridge-name":"vbr1", "interface-name":"if2", "node":"openflow:3", "port-name":"s3-eth3"}}'
+----
+
+* Genarate traffic by pinging between host h1 and host h2 after creating the portmaps respectively.
+
+----
+ mininet> h1 ping h2
+ PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
+ 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.861 ms
+ 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.101 ms
+ 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.101 ms
+----
+
+* Get the Dataflows information by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow.html#get-data-flow[the get-data-flow RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow:get-data-flow -d '{"input":{"tenant-name":"vtn1","mode":"DETAIL","node":"openflow:1","data-flow-port":{"port-id":1,"port-name":"s1-eth1"}}}'
+----
+
+* Create flowcondition named cond_1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-condition.html#set-flow-condition[the set-flow-condition RPC].
+
+** For option source and destination-network, get inet address of host h1 or host h2 from mininet
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:set-flow-condition -d '{"input":{"operation":"SET","present":"false","name":"cond_1", "vtn-flow-match":[{"vtn-ether-match":{},"vtn-inet-match":{"source-network":"10.0.0.1/32","protocol":1,"destination-network":"10.0.0.2/32"},"index":"1"}]}}'
+----
+
+* Create pathmap with flowcondition cond_1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-path-map.html#set-path-map[the set-path-map RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-path-map:set-path-map -d '{"input":{"tenant-name":"vtn1","path-map-list":[{"condition":"cond_1","policy":"1","index": "1","idle-timeout":"300","hard-timeout":"0"}]}}'
+----
+
+* Create pathpolicy by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-path-policy.html#set-path-policy[the set-path-policy RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-path-policy:set-path-policy -d '{"input":{"operation":"SET","id": "1","default-cost": "10000","vtn-path-cost": [{"port-desc":"openflow:1,3,s1-eth3","cost":"1000"},{"port-desc":"openflow:4,2,s4-eth2","cost":"1000"},{"port-desc":"openflow:3,3,s3-eth3","cost":"100000"}]}}'
+----
+
+===== Verification
+
+* Before applying Path policy get node information by executing get dataflow command.
+
+----
+"data-flow-info": [
+{
+ "physical-route": [
+ {
+ "physical-ingress-port": {
+ "port-name": "s3-eth3",
+ "port-id": "3"
+ },
+ "physical-egress-port": {
+ "port-name": "s3-eth1",
+ "port-id": "1"
+ },
+ "node": "openflow:3",
+ "order": 0
+ },
+ {
+ "physical-ingress-port": {
+ "port-name": "s2-eth2",
+ "port-id": "2"
+ },
+ "physical-egress-port": {
+ "port-name": "s2-eth1",
+ "port-id": "1"
+ },
+ "node": "openflow:2",
+ "order": 1
+ },
+ {
+ "physical-ingress-port": {
+ "port-name": "s1-eth2",
+ "port-id": "2"
+ },
+ "physical-egress-port": {
+ "port-name": "s1-eth1",
+ "port-id": "1"
+ },
+ "node": "openflow:1",
+ "order": 2
+ }
+ ],
+ "data-egress-node": {
+ "interface-name": "if1",
+ "bridge-name": "vbr1",
+ "tenant-name": "vtn1"
+ },
+ "data-egress-port": {
+ "node": "openflow:1",
+ "port-name": "s1-eth1",
+ "port-id": "1"
+ },
+ "data-ingress-node": {
+ "interface-name": "if2",
+ "bridge-name": "vbr1",
+ "tenant-name": "vtn1"
+ },
+ "data-ingress-port": {
+ "node": "openflow:3",
+ "port-name": "s3-eth3",
+ "port-id": "3"
+ },
+ "flow-id": 32
+ },
+}
+----
+
+* After applying Path policy get node information by executing get dataflow command.
+
+----
+"data-flow-info": [
+{
+ "physical-route": [
+ {
+ "physical-ingress-port": {
+ "port-name": "s1-eth1",
+ "port-id": "1"
+ },
+ "physical-egress-port": {
+ "port-name": "s1-eth3",
+ "port-id": "3"
+ },
+ "node": "openflow:1",
+ "order": 0
+ },
+ {
+ "physical-ingress-port": {
+ "port-name": "s4-eth1",
+ "port-id": "1"
+ },
+ "physical-egress-port": {
+ "port-name": "s4-eth2",
+ "port-id": "2"
+ },
+ "node": "openflow:4",
+ "order": 1
+ },
+ {
+ "physical-ingress-port": {
+ "port-name": "s3-eth2",
+ "port-id": "2"
+ },
+ "physical-egress-port": {
+ "port-name": "s3-eth3",
+ "port-id": "3"
+ },
+ "node": "openflow:3",
+ "order": 2
+ }
+ ],
+ "data-egress-node": {
+ "interface-name": "if2",
+ "bridge-name": "vbr1",
+ "tenant-name": "vtn1"
+ },
+ "data-egress-port": {
+ "node": "openflow:3",
+ "port-name": "s3-eth3",
+ "port-id": "3"
+ },
+ "data-ingress-node": {
+ "interface-name": "if1",
+ "bridge-name": "vbr1",
+ "tenant-name": "vtn1"
+ },
+ "data-ingress-port": {
+ "node": "openflow:1",
+ "port-name": "s1-eth1",
+ "port-id": "1"
+ },
+}
+----
+
+===== Cleaning Up
+
+* To clean up both VTN and flowcondition.
+
+* You can delete the virtual tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn.html#remove-vtn[the remove-vtn RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:remove-vtn -d '{"input":{"tenant-name":"vtn1"}}'
+----
+
+* You can delete the flowcondition cond_1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow-condition.html#remove-flow-condition[the remove-flow-condition RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow-condition:remove-flow-condition -d '{"input":{"name":"cond_1"}}'
+----
+
--- /dev/null
+==== How To View Dataflows
+
+===== Overview
+
+This page explains how to view Dataflows using VTN Manager. This page targets Beryllium release, so the procedure described here does not work in other releases.
+
+Dataflow feature enables retrieval and display of data flows in the openflow network. The data flows can be retrieved based on an openflow switch or a switch port or a L2 source host.
+
+The flow information provided by this feature are
+
+* Location of virtual node which maps the incoming packet and outgoing packets.
+
+* Location of physical switch port where incoming and outgoing packets is sent and received.
+
+* A sequence of physical route info which represents the packet route in the physical network.
+
+===== Configuration
+
+* To view Dataflow information, configure with VLAN Mapping
+ https://wiki.opendaylight.org/view/VTN:Mananger:How_to_test_Vlan-map_using_mininet.
+
+===== Verification
+
+After creating vlan mapping configuration from the above page, execute as below in mininet to get switch details.
+
+----
+ mininet> net
+ h1 h1-eth0.200:s1-eth1
+ h2 h2-eth0.300:s2-eth2
+ h3 h3-eth0.200:s2-eth3
+ h4 h4-eth0.300:s2-eth4
+ h5 h5-eth0.200:s3-eth2
+ h6 h6-eth0.300:s3-eth3
+ s1 lo: s1-eth1:h1-eth0.200 s1-eth2:s2-eth1 s1-eth3:s3-eth1
+ s2 lo: s2-eth1:s1-eth2 s2-eth2:h2-eth0.300 s2-eth3:h3-eth0.200 s2-eth4:h4-eth0.300
+ s3 lo: s3-eth1:s1-eth3 s3-eth2:h5-eth0.200 s3-eth3:h6-eth0.300
+ c0
+ mininet>
+----
+
+Please execute ping from h1 to h3 to check hosts reachability.
+
+----
+ mininet> h1 ping h3
+ PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
+ 64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=11.4 ms
+ 64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=0.654 ms
+ 64 bytes from 10.0.0.3: icmp_seq=3 ttl=64 time=0.093 ms
+----
+
+Parallely execute below Restconf command to get data flow information of node "openflow:1" and its port "s1-eth1".
+
+* Get the Dataflows information by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-flow.html#get-data-flow[the get-data-flow RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-flow:get-data-flow -d '{"input":{"tenant-name":"vtn1","mode":"DETAIL","node":"openflow:1","data-flow-port":{"port-id":"1","port-name":"s1-eth1"}}}'
+----
+
+----
+{
+ "output": {
+ "data-flow-info": [
+ {
+ "averaged-data-flow-stats": {
+ "packet-count": 1.1998800119988002,
+ "start-time": 1455241209151,
+ "end-time": 1455241219152,
+ "byte-count": 117.58824117588242
+ },
+ "physical-route": [
+ {
+ "physical-ingress-port": {
+ "port-name": "s2-eth3",
+ "port-id": "3"
+ },
+ "physical-egress-port": {
+ "port-name": "s2-eth1",
+ "port-id": "1"
+ },
+ "node": "openflow:2",
+ "order": 0
+ },
+ {
+ "physical-ingress-port": {
+ "port-name": "s1-eth2",
+ "port-id": "2"
+ },
+ "physical-egress-port": {
+ "port-name": "s1-eth1",
+ "port-id": "1"
+ },
+ "node": "openflow:1",
+ "order": 1
+ }
+ ],
+ "data-egress-node": {
+ "bridge-name": "vbr1",
+ "tenant-name": "vtn1"
+ },
+ "hard-timeout": 0,
+ "idle-timeout": 300,
+ "data-flow-stats": {
+ "duration": {
+ "nanosecond": 640000000,
+ "second": 362
+ },
+ "packet-count": 134,
+ "byte-count": 12932
+ },
+ "data-egress-port": {
+ "node": "openflow:1",
+ "port-name": "s1-eth1",
+ "port-id": "1"
+ },
+ "data-ingress-node": {
+ "bridge-name": "vbr1",
+ "tenant-name": "vtn1"
+ },
+ "data-ingress-port": {
+ "node": "openflow:2",
+ "port-name": "s2-eth3",
+ "port-id": "3"
+ },
+ "creation-time": 1455240855753,
+ "data-flow-match": {
+ "vtn-ether-match": {
+ "vlan-id": 200,
+ "source-address": "6a:ff:e2:81:86:bb",
+ "destination-address": "26:9f:82:70:ec:66"
+ }
+ },
+ "virtual-route": [
+ {
+ "reason": "VLANMAPPED",
+ "virtual-node-path": {
+ "bridge-name": "vbr1",
+ "tenant-name": "vtn1"
+ },
+ "order": 0
+ },
+ {
+ "reason": "FORWARDED",
+ "virtual-node-path": {
+ "bridge-name": "vbr1",
+ "tenant-name": "vtn1"
+ },
+ "order": 1
+ }
+ ],
+ "flow-id": 16
+ },
+ {
+ "averaged-data-flow-stats": {
+ "packet-count": 1.1998800119988002,
+ "start-time": 1455241209151,
+ "end-time": 1455241219152,
+ "byte-count": 117.58824117588242
+ },
+ "physical-route": [
+ {
+ "physical-ingress-port": {
+ "port-name": "s1-eth1",
+ "port-id": "1"
+ },
+ "physical-egress-port": {
+ "port-name": "s1-eth2",
+ "port-id": "2"
+ },
+ "node": "openflow:1",
+ "order": 0
+ },
+ {
+ "physical-ingress-port": {
+ "port-name": "s2-eth1",
+ "port-id": "1"
+ },
+ "physical-egress-port": {
+ "port-name": "s2-eth3",
+ "port-id": "3"
+ },
+ "node": "openflow:2",
+ "order": 1
+ }
+ ],
+ "data-egress-node": {
+ "bridge-name": "vbr1",
+ "tenant-name": "vtn1"
+ },
+ "hard-timeout": 0,
+ "idle-timeout": 300,
+ "data-flow-stats": {
+ "duration": {
+ "nanosecond": 587000000,
+ "second": 362
+ },
+ "packet-count": 134,
+ "byte-count": 12932
+ },
+ "data-egress-port": {
+ "node": "openflow:2",
+ "port-name": "s2-eth3",
+ "port-id": "3"
+ },
+ "data-ingress-node": {
+ "bridge-name": "vbr1",
+ "tenant-name": "vtn1"
+ },
+ "data-ingress-port": {
+ "node": "openflow:1",
+ "port-name": "s1-eth1",
+ "port-id": "1"
+ },
+ "creation-time": 1455240855747,
+ "data-flow-match": {
+ "vtn-ether-match": {
+ "vlan-id": 200,
+ "source-address": "26:9f:82:70:ec:66",
+ "destination-address": "6a:ff:e2:81:86:bb"
+ }
+ },
+ "virtual-route": [
+ {
+ "reason": "VLANMAPPED",
+ "virtual-node-path": {
+ "bridge-name": "vbr1",
+ "tenant-name": "vtn1"
+ },
+ "order": 0
+ },
+ {
+ "reason": "FORWARDED",
+ "virtual-node-path": {
+ "bridge-name": "vbr1",
+ "tenant-name": "vtn1"
+ },
+ "order": 1
+ }
+ ],
+ "flow-id": 15
+ }
+ ]
+ }
+}
+----
+
--- /dev/null
+==== How To Test Vlan-Map In Mininet Environment
+
+===== Overview
+This page explains how to test Vlan-map in a multi host scenario using mininet. This page targets Beryllium release, so the procedure described here does not work in other releases.
+
+.Example that demonstrates vlanmap testing in Mininet Environment
+image::vtn/vlanmap_using_mininet.png[Example that demonstrates vlanmap testing in Mininet Environment]
+
+===== Requirements
+Save the mininet script given below as vlan_vtn_test.py and run the mininet script in the mininet environment where Mininet is installed.
+
+===== Mininet Script
+https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Scripts:Mininet#Network_with_hosts_in_different_vlan
+
+* Run the mininet script
+
+----
+sudo mn --controller=remote,ip=192.168.64.13 --custom vlan_vtn_test.py --topo mytopo
+----
+
+NOTE:
+Replace "192.168.64.13" with the IP address of OpenDaylight controller based on your environment.
+
+* You can check the topology that you have created by executing "net" command in the Mininet console.
+
+----
+ mininet> net
+ h1 h1-eth0.200:s1-eth1
+ h2 h2-eth0.300:s2-eth2
+ h3 h3-eth0.200:s2-eth3
+ h4 h4-eth0.300:s2-eth4
+ h5 h5-eth0.200:s3-eth2
+ h6 h6-eth0.300:s3-eth3
+ s1 lo: s1-eth1:h1-eth0.200 s1-eth2:s2-eth1 s1-eth3:s3-eth1
+ s2 lo: s2-eth1:s1-eth2 s2-eth2:h2-eth0.300 s2-eth3:h3-eth0.200 s2-eth4:h4-eth0.300
+ s3 lo: s3-eth1:s1-eth3 s3-eth2:h5-eth0.200 s3-eth3:h6-eth0.300
+ c0
+----
+
+NOTE:
+You need to manually add flow entries to OpenFlow switches in the Mininet. The flow entries are needed to forward packets to controller when there is a table-miss. This configuration is required only in case of OpenFlow 1.3 or using OVS versions (>2.1.1).
+
+----
+ sudo ovs-ofctl add-flow s1 priority=0,actions=output:CONTROLLER
+ sudo ovs-ofctl add-flow s2 priority=0,actions=output:CONTROLLER
+ sudo ovs-ofctl add-flow s3 priority=0,actions=output:CONTROLLER
+----
+
+===== Configuration
+
+To test vlan-map, execute REST API provided by VTN Manager as follows.
+
+* Create a virtual tenant named vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn.html#update-vtn[the update-vtn RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:update-vtn -d '{"input":{"tenant-name":"vtn1"}}'
+----
+
+* Create a virtual bridge named vbr1 in the tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vbridge.html#update-vbridge[the update-vbridge RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr1"}}'
+----
+
+* Configure a vlan map with vlanid 200 for vBridge vbr1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vlan-map.html#add-vlan-map[the add-vlan-map RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vlan-map:add-vlan-map -d '{"input":{"vlan-id":200,"tenant-name":"vtn1","bridge-name":"vbr1"}}'
+----
+
+* Create a virtual bridge named vbr2 in the tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vbridge.html#update-vbridge[the update-vbridge RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vbridge:update-vbridge -d '{"input":{"tenant-name":"vtn1","bridge-name":"vbr2"}}'
+----
+
+* Configure a vlan map with vlanid 300 for vBridge vbr2 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn-vlan-map.html#add-vlan-map[the add-vlan-map RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn-vlan-map:add-vlan-map -d '{"input":{"vlan-id":300,"tenant-name":"vtn1","bridge-name":"vbr2"}}'
+----
+
+===== Verification
+
+* Please execute pingall in mininet environment to view the host reachability.
+
+----
+ mininet> pingall
+ Ping: testing ping reachability
+ h1 -> X h3 X h5 X
+ h2 -> X X h4 X h6
+ h3 -> h1 X X h5 X
+ h4 -> X h2 X X h6
+ h5 -> h1 X h3 X X
+ h6 -> X h2 X h4 X
+----
+
+* You can also verify the configuration by executing the following REST API. It shows all configurations in VTN Manager.
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns
+----
+
+* The result of the command should be like this.
+
+----
+{
+ "vtns": {
+ "vtn": [
+ {
+ "name": "vtn1",
+ "vtenant-config": {
+ "hard-timeout": 0,
+ "idle-timeout": 300,
+ "description": "creating vtn"
+ },
+ "vbridge": [
+ {
+ "name": "vbr2",
+ "vbridge-config": {
+ "age-interval": 600,
+ "description": "creating vbr2"
+ },
+ "bridge-status": {
+ "state": "UP",
+ "path-faults": 0
+ },
+ "vlan-map": [
+ {
+ "map-id": "ANY.300",
+ "vlan-map-config": {
+ "vlan-id": 300
+ },
+ "vlan-map-status": {
+ "active": true
+ }
+ }
+ ]
+ },
+ {
+ "name": "vbr1",
+ "vbridge-config": {
+ "age-interval": 600,
+ "description": "creating vbr1"
+ },
+ "bridge-status": {
+ "state": "UP",
+ "path-faults": 0
+ },
+ "vlan-map": [
+ {
+ "map-id": "ANY.200",
+ "vlan-map-config": {
+ "vlan-id": 200
+ },
+ "vlan-map-status": {
+ "active": true
+ }
+ }
+ ]
+ }
+ ]
+ }
+ ]
+ }
+}
+----
+
+===== Cleaning Up
+
+* You can delete the virtual tenant vtn1 by executing
+ https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-beryllium/lastSuccessfulBuild/artifact/manager/model/target/site/models/vtn.html#remove-vtn[the remove-vtn RPC].
+
+----
+curl --user "admin":"admin" -H "Content-type: application/json" -X POST http://localhost:8181/restconf/operations/vtn:remove-vtn -d '{"input":{"tenant-name":"vtn1"}}'
+----
+
This guide describes how to set up OpenStack for integration with OpenDaylight Controller.
-While OpenDaylight Controller provides several ways to integrate with OpenStack, this guide focus on the way which uses VTN features available on OpenDaylight controller.In the integration, VTN Manager work as network service provider for OpenStack.
+While OpenDaylight Controller provides several ways to integrate with OpenStack, this guide focus on the way which uses VTN features available on OpenDaylight. In the integration, VTN Manager work as network service provider for OpenStack.
VTN Manager features, enable OpenStack to work in pure OpenFlow environment in which all switches in data plane are OpenFlow switch.
- Login again and check the output of ifconfig to ensure that both interfaces are listed
==== OpenDaylight Settings and Execution
-===== vtn.ini
- * VTN uses the configuration parameters from 'vtn.ini' file for the OpenStack integration.
+
+===== VTN Configuration for OpenStack Integration:
+
+ * VTN uses the configuration parameters from "90-vtn-neutron.xml" file for the OpenStack integration.
* These values will be set for the OpenvSwitch, in all the participating OpenStack nodes.
- * A configuration file 'vtn.ini'''' needs to be created manually in the 'configuration' directory.
- * The contents of 'vtn.ini' should be as follows:
+ * A configuration file "90-vtn-neutron.xml" will be generated automatically by following the below steps,
+ * Download the latest Beryllium karaf distribution from the below link,
+
+
+ http://www.opendaylight.org/software/downloads
+
+
+ * cd "distribution-karaf-0.4.0-Beryllium" and run karaf by using the following command "./bin/karaf".
+ * Install the below feature to generate "90-vtn-neutron.xml",
+
+----
+ feature:install odl-vtn-manager-neutron
+----
+
+ * Check "90-vtn-neutron.xml" file from the following path "distribution-karaf-0.4.0-Beryllium/etc/opendaylight/karaf/".
+
+TIP: After running OpenDaylight, please ensure OpenDaylight listens to the ports:6633,6653, 6640 and 8080
+
+TIP: Please allow the ports in firewall for the devstack to be able to communicate with OpenDaylight.
+
+NOTE:
+
+* 6633/6653 - OpenFlow Ports
+* 6640 - Open vSwitch Manager Port
+* 8282 - Port for REST API
+
+ * The contents of "90-vtn-neutron.xml" should be as follows:
bridgename=br-int
failmode=secure
* The values of the configuration parameters must be changed based on the user environment.
- * Especially, "portname" should be carefully configured, because if the value is wrong, OpenDaylight controller fails to forward packets.
+ * Especially, "portname" should be carefully configured, because if the value is wrong, OpenDaylight fails to forward packets.
* Other parameters works fine as is for general use cases.
** bridgename
*** The name of the bridge in Open vSwitch, that will be created by OpenDaylight Controller.
** portname
*** The name of the port that will be created in the vbridge in Open vSwitch.
*** This must be the same name of the interface of OpenStack Nodes which is used for interconnecting OpenStack Nodes in data plane.(in our case:eth1)
- *** By default, if vtn.ini is not created, VTN uses ens33 as portname.
+ *** By default, if 90-vtn-neutron.xml is not created, VTN uses ens33 as portname.
** protocols
*** OpenFlow protocol through which OpenFlow Switch and Controller communicate.
*** The values can be OpenFlow13 or OpenFlow10.
*** The value can be "standalone" or "secure".
*** Please use "secure" for general use cases.
-==== Start OpenDaylight
-
- * Please install the feature *odl-vtn-manager-neutron* that provides the integration with Neutron interface.
-
-feature:install odl-vtn-manager-neutron
-
-TIP: After running OpenDaylight, please ensure OpenDaylight listens to the ports:6633,6653, 6640 and 8080
-
-TIP: Please allow the ports in firewall for the devstack to be able to communicate with OpenDaylight.
-
-NOTE:
-* 6633/6653 - OpenFlow Ports
-* 6640 - Open vSwitch Manager Port
-* 8282 - Port for REST API
-
==== Devstack Setup
===== VTN Devstack Script
* The local.conf is a user-maintained settings file. This allows all custom settings for DevStack to be contained in a single file. This file is processed strictly in sequence.
-The following datas are needed to be set in the local.conf file:
+The following data are needed to be set in the local.conf file:
* Set the Host_IP as the detection is unreliable.
* Set FLOATING_RANGE to a range not used on the local network, i.e. 192.168.1.224/27. This configures IP addresses ending in 225-254 to be used as floating IPs.
* Set FLAT_INTERFACE to the Ethernet interface that connects the host to your local network. This is the interface that should be configured with the static IP address mentioned above.
** git clone https://git.openstack.org/openstack-dev/devstack;
* Switch to stable/Juno Version branch
** cd devstack
-** git checkout stable/juno
+
+
+ git checkout stable/juno
NOTE:
If you want to use stable/kilo Version branch, Please execute the below command in devstack folder
-
-
+
+
git checkout stable/kilo
NOTE:
If you want to use stable/liberty Version branch, Please execute the below command in devstack folder
-
-
+
+
git checkout stable/liberty
===== Stack Control Node
* The output of the ovs-vsctl show will be similar to the one seen in control node.
===== Additional Verifications
-* Please visit the OpenDaylight DLUX GUI after stacking all the nodes, http://<ODL_IP_ADDRESS>:8181/dlux/index.html. The switches, topology and the ports that are currently read can be validated.
+* Please visit the OpenDaylight DLUX GUI after stacking all the nodes, http://<ODL_IP_ADDRESS>:8181/index.html. The switches, topology and the ports that are currently read can be validated.
TIP: If the interconnected between the Open vSwitch is not seen, Please bring up the interface for the dataplane manually using the below comamnd
* <<_vtn_coordinator,VTN Coordinator>>
==== VTN Manager
-An OpenDaylight Controller 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 ODL controller. VTN Manager is implemented as one plugin to the OpenDaylight controller. 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 ODC Driver component. In addition to the above mentioned role, it also provides an implementation to the OpenStack L2 Network Functions API.
+An OpenDaylight Plugin that interacts with other modules to implement the components of the VTN model. It also provides a REST interface to configure VTN components in OpenDaylight. VTN Manager is implemented as one plugin to the OpenDaylight. This provides a REST interface to create/update/delete VTN components. The user command in VTN Coordinator is translated as REST API to VTN Manager by the OpenDaylight Driver component. In addition to the above mentioned role, it also provides an implementation to the OpenStack L2 Network Functions API.
===== Features Overview
----
curl --user "admin":"admin" -H "Accept: application/json" -H \
"Content-type: application/json" -X POST \
- http://localhost:8282/controller/nb/v2/vtn/default/vtns/Tenant1 \
- -d '{"description": "My First Virtual Tenant Network"}'
+ http://localhost:8181/restconf/operations/vtn:update-vtn \
+ -d '{"input":{"tenant-name":"vtn1"}}'
----
You can check the list of all tenants by executing the following command.
----
curl --user "admin":"admin" -H "Accept: application/json" -H \
"Content-type: application/json" -X GET \
- http://localhost:8282/controller/nb/v2/vtn/default/vtns
+ http://localhost:8181/restconf/operational/vtn:vtns
----
-REST API documentation for VTN Manager, please refer: https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-merge-master/lastSuccessfulBuild/artifact/manager/northbound/target/site/wsdocs/rest.html
+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/
==== VTN Coordinator
-The VTN Coordinator is an external application that provides a REST interface for a user to use the VTN Virtualization. It interacts with VTN Manager plugin to implement the user configuration. It is also capable of multiple controller orchestration. It realizes Virtual Tenant Network (VTN) provisioning in OpenDaylight Controllers (ODC). In the OpenDaylight architecture VTN Coordinator is part of the network application, orchestration and services layer. VTN Coordinator has been implemented as an external application to the OpenDaylight controller. This component is responsible for the VTN virtualization. VTN Coordinator will use the REST interface exposed by the VTN Manger to realize the virtual network using the OpenDaylight controller. It uses OpenDaylight APIs (REST) to construct the virtual network in ODCs. It provides REST APIs for northbound VTN applications and supports virtual networks spanning across multiple ODCs by coordinating across ODCs.
+The VTN Coordinator is an external application that provides a REST interface for an user to use OpenDaylight VTN Virtualization. It interacts with VTN Manager plugin to implement the user configuration. It is also capable of multiple OpenDaylight orchestration. It realizes Virtual Tenant Network (VTN) provisioning in OpenDaylight instances. In the OpenDaylight architecture VTN Coordinator is part of the network application, orchestration and services layer. VTN Coordinator will use the REST interface exposed by the VTN Manger to realize the virtual network using OpenDaylight. It uses OpenDaylight APIs (REST) to construct the virtual network in OpenDaylight instances. It provides REST APIs for northbound VTN applications and supports virtual networks spanning across multiple OpenDaylight by coordinating across OpenDaylight.
-For VTN Coordinator REST API, please refer: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Coordinator:RestApi
+For VTN Coordinator REST API, please refer to: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:VTN_Coordinator:RestApi
==== Network Virtualization Function
When an IP address is registered with a virtual interface of the vRouter, the default routing information for that interface is registered. It is also possible to statically register routing information for a virtual interface.
* ARP learning function
The vRouter associates a destination IP address, MAC address and a virtual interface, based on an ARP request to its host or a reply packet for an ARP request, and maintains this information in an ARP table prepared for each routing domain. The registered ARP entry is retained until the aging timer, described later, times out. The vRouter transmits an ARP request on an individual aging timer basis and deletes the associated entry from the ARP table if no reply is returned. For static ARP learning, you can register ARP entry information manually.
-*DHCP relay agent function
+* DHCP relay agent function
The vRouter also provides the DHCP relay agent function.
==== Flow Filter Functions
[cols="2*"]
|===
+| Action | Function
| Pass
| Pass particular packets matching the specified conditions.
include::VTN_OpenStack_Support-user.adoc[VTN OpenStack Configuration]
-=== VTN Usage Examples
+=== VTN Manager Usage Examples
+
+include::VTN_Manager_How_To_Provision_Virtual_L2_Network.adoc[How to provision virtual L2 Network]
+
+include::VTN_Manager_How_To_test_vlan_map_using_mininet.adoc[How To Test Vlan-map using Mininet Environment]
+
+include::VTN_Manager_How_To_Configure_Service_Function_Chaining_Support.adoc[How To Configure Service Function Chaining Support using Mininet Environmen]
+
+include::VTN_Manager_How_To_View_Dataflows.adoc[How To View Dataflow in VTN Manager]
+
+include::VTN_Manager_How_To_Create_Mac_Map_In_VTN.adoc[How To Create Mac Map In VTN]
+
+include::VTN_Manager_How_To_Configure_Flowfilters.adoc[How To Configure Flow Filters using VTN]
+
+include::VTN_Manager_How_To_Use_VTN_to_change_the_path_of_the_packet_flow.adoc[How To Use VTN to change the path of the packet flow]
+
+=== VTN Coordinator Usage Examples
include::VTN_How_To_configure_L2_Network_with_Single_Controller.adoc[How to configure L2 Network with Single Controller]
include::VTN_How_To_Troubleshoot_Coordinator_Installation.adoc[Troubleshoot VTN Coordinator]
include::VTN_How_To_Support_for_Microsoft_SCVMM.adoc[Support for Microsoft SCVMM 2012 R2 with ODL VTN]
+
<properties>
<asciidoctor.version>0.1.4</asciidoctor.version>
<current.branch>master</current.branch>
- <nexusproxy>http://nexus.opendaylight.org/content</nexusproxy>
+ <nexusproxy>https://nexus.opendaylight.org/content</nexusproxy>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<sitedeploy>${nexusproxy}/sites/site/${project.groupId}/${current.branch}/${project.artifactId}</sitedeploy>
</properties>
--- /dev/null
+[tox]
+minversion = 1.6
+envlist = docs,docs-linkcheck
+skipsdist = true
+
+[testenv:docs]
+deps = sphinx
+commands = sphinx-build -b html -n -d {envtmpdir}/doctrees ./docs/ {envtmpdir}/html
+
+[testenv:docs-linkcheck]
+deps = sphinx
+commands = sphinx-build -b linkcheck -d {envtmpdir}/doctrees ./docs/ {envtmpdir}/linkcheck
Code Review / docs.git / commitdiff
