This project is providing manuals and documentation for OpenDaylight
-You will find guides in manuals:
+For the documentation see:
+http://docs.opendaylight.org/
+
+For information on how to contribute to and/or build the documentation see:
+http://docs.opendaylight.org/en/latest/documentation.html
# 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('.'))
+sys.path.insert(0, os.path.abspath('submodules/spectrometer/server'))
# -- General configuration ------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
-extensions = []
+extensions = ['sphinx.ext.autodoc']
# Disable javasphinx generation until we have a solution to long build
# times. readthedocs timesout after 902 seconds.
be toward merging it rather than blocking on relatively minor edits.
Formatting Preferences
-^^^^^^^^^^^^^^^^^^^^^^
+----------------------
In general, the documentation team has focused on trying to make sure
that the instructions are comprehensible, but not being overly pedantic
* Line wrapping at something reasonable, i.e., 72–100 characters
Key terms
-^^^^^^^^^
+---------
* Functionality: something useful a project provides abstractly
* Feature: a Karaf feature that somebody could install
other terms is hard.
Common writing style mistakes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-----------------------------
* In per-project user documentation, you should never say *git clone*,
but should assume people have downloaded and installed the controller
project.
Grammar Preferences
-"""""""""""""""""""
+^^^^^^^^^^^^^^^^^^^
* Avoid contractions: use cannot instead of can't, it is instead of
it's, and the like.
YANG IDE Installation Guide
-==========================
+===========================
Overview
--------
sample Yang model file (acme-system.yang).
Pre Requisites for Installing YANG IDE
--------------------------------------
+--------------------------------------
* YANG IDE has the same hardware requirements as the Eclipse IDE, which
is about the same as the hardware requirements for Java 7.
Installing YANG IDE
-------------------
+-------------------
The YANG IDE plugin can be installed by using the public update site URL
provided, which is http://abc.def .
uninstall that plugin before you install this one.
Uninstalling YANG IDE
---------------------
+---------------------
Uninstalling the YANG IDE plugin is the same as uninstalling any other Eclipse plugin.
-Subproject commit 94305ea009b960e9acc0c7f53b63bda6799e818f
+Subproject commit b8410b1299b7ee1e1b843850a558e68609575fa1
-Subproject commit 17eb4cba8b612391c30bd334c34779c1740df6dc
+Subproject commit 42e2183c83a939313b2663f5763e11db55c44697
-Subproject commit fe897d64d298e3ee50e161e3a7d2c835f2c94027
+Subproject commit 1a0bece17ca76ee1e887d1e66992df63774d1f9b
-Subproject commit a821293befe5f3fd0920e98642d2ee5554d4a4e2
+Subproject commit e714b02ea6f1ab2adc04140dfe8d5a6a75462268
-Subproject commit 2e39f0c9fe381855ea45dfd98406b557adecd4c0
+Subproject commit 1870dba1bee464eeb248bdeef87b40103a86b044
<version>${ALTO_VERSION}</version>
</dependency>
-The current stable version for ALTO is `0.2.0-Beryllium`.
+The current stable version for ALTO is `0.3.0-Boron`.
=== Putting/Fetching data from ALTO ===
== BGP Developer Guide
=== Overview
-This section provides an overview of *feature odl-bgpcep-bgp-all* . This
+This section provides an overview of the `odl-bgpcep-bgp-all` Karaf feature. This
feature will install everything needed for BGP (Border Gateway Protocol)
from establishing the connection, storing the data in RIBs (Route Information
Base) and displaying data in network-topology overview.
Each feature represents a module in the BGPCEP codebase. The following diagram
illustrates how the features are related.
-image::bgpcep/bgp-dependency-tree.png[height="450px", width="550px",title="BGP Dependency Tree"]
+image::bgpcep/bgp-dependency-tree.png[width="500px",title="BGP Dependency Tree"]
=== Key APIs and Interfaces
==== BGP concepts
This module contains the base BGP concepts contained in
-http://tools.ietf.org/html/rfc4271[RFC4271],
-http://tools.ietf.org/html/rfc4760[RFC4760],
-http://tools.ietf.org/html/rfc4456[RFC4456],
-http://tools.ietf.org/html/rfc1997[RFC1997] and
-http://tools.ietf.org/html/rfc4360[RFC4360].
+http://tools.ietf.org/html/rfc4271[RFC 4271],
+http://tools.ietf.org/html/rfc4760[RFC 4760],
+http://tools.ietf.org/html/rfc4456[RFC 4456],
+http://tools.ietf.org/html/rfc1997[RFC 1997] and
+http://tools.ietf.org/html/rfc4360[RFC 4360].
-All the concepts are described in one yang model :
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/yang/bgp-types.yang;hb=refs/heads/stable/lithium[bgp-types.yang]
-.
+All the concepts are described in one yang model:
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/yang/bgp-types.yang;hb=refs/heads/stable/beryllium[bgp-types.yang].
Outside generated classes, there is just one class
-_https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/java/org/opendaylight/bgp/concepts/NextHopUtil.java;hb=refs/heads/stable/lithium[NextHopUtil]_
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/java/org/opendaylight/bgp/concepts/NextHopUtil.java;hb=refs/heads/stable/beryllium[NextHopUtil]
that contains methods for serializing and parsing NextHop.
==== BGP parser
Base BGP parser includes messages and attributes from
-http://tools.ietf.org/html/rfc4271[RFC4271],
-http://tools.ietf.org/html/rfc4760[RFC4760],
-http://tools.ietf.org/html/rfc1997[RFC1997] and
-http://tools.ietf.org/html/rfc4360[RFC4360].
+http://tools.ietf.org/html/rfc4271[RFC 4271],
+http://tools.ietf.org/html/rfc4760[RFC 4760],
+http://tools.ietf.org/html/rfc1997[RFC 1997] and
+http://tools.ietf.org/html/rfc4360[RFC 4360].
_API_ module defines BGP messages in YANG.
_IMPL_ module contains actual parsers and serializers for BGP messages
and
-_https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-impl/src/main/java/org/opendaylight/protocol/bgp/parser/impl/BGPActivator.java;hb=refs/heads/stable/lithium[Activator]_
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-impl/src/main/java/org/opendaylight/protocol/bgp/parser/impl/BGPActivator.java;hb=refs/heads/stable/beryllium[Activator]
class
_SPI_ module contains helper classes needed for registering parsers into
===== Registration
-As mentioned before, all parsers and serializers need to be registered
+All parsers and serializers need to be registered
into the _Extension provider_. This _Extension provider_ is configured in
-initial configuration of the parser-spi module (_31-bgp.xml_).
+initial configuration of the parser-spi module (`31-bgp.xml`).
[source,xml]
----
The configuration of bgp-parser-spi specifies one implementation of
_Extension provider_ that will take care of registering mentioned parser
extensions:
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi/pojo/SimpleBGPExtensionProviderContext.java;hb=refs/heads/stable/lithium[SimpleBGPExtensionProviderContext].
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi/pojo/SimpleBGPExtensionProviderContext.java;hb=refs/heads/stable/beryllium[SimpleBGPExtensionProviderContext].
All registries are implemented in package
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi;hb=refs/heads/stable/lithium[bgp-parser-spi].
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi;hb=refs/heads/stable/beryllium[bgp-parser-spi].
===== Serializing
-The serializing of BGP elements is mostly done in the same way as in PCEP, the only
-exception is the serialization of path attributes, that is described
+The serializing of BGP elements is mostly done in the same way as in <<_pcep_developer_guide,PCEP>>, the only
+exception is the serialization of path attributes, which is described
here. Path attributes are different from any other BGP element, as
path attributes don't implement one common interface, but this
interface contains getters for individual path attributes (this
go through the registrations and offer this object to the each
registered parser. This way the object will be passed also to
serializers unknown to module bgp-parser, for example to
-LinkstateAttributeParser. RFC4271 recommends ordering path attributes,
+LinkstateAttributeParser. RFC 4271 recommends ordering path attributes,
hence the serializers are ordered in a list as they are registered in
the _Activator_. In other words, this is the only case, where
registration ordering matters.
-image::bgpcep/PathAttributesSerialization.png[height="450px", width="550px",title="PathAttributesSerialization"]
+image::bgpcep/PathAttributesSerialization.png[width="500px",title="PathAttributesSerialization"]
_serialize()_ method in each Path Attribute parser contains check for
presence of its attribute in the PathAttributes object, which simply
=== BGP RIB
-The BGP RIB module can be divided into two semantic parts:
+The BGP RIB module can be divided into two parts:
+
* BGP listener and speaker session handling
* RIB handling.
==== Session handling
-_31-bgp.xml_ defines only bgp-dispatcher and the parser it should be
+`31-bgp.xml` defines only bgp-dispatcher and the parser it should be
using (global-bgp-extensions).
[source,xml]
----
- <module>
+<module>
<type>prefix:bgp-dispatcher-impl</type>
<name>global-bgp-dispatcher</name>
<bgp-extensions>
<type>netty:netty-threadgroup</type>
<name>global-worker-group</name>
</worker-group>
- </module>
+</module>
----
For user configuration of BGP, check User Guide.
Synchronization is a phase, where upon connection, a BGP speaker sends all
available data about topology to its new client. After the whole
-topology has been advertized, the synchronization is over. For the
+topology has been advertised, the synchronization is over. For the
listener, the synchronization is over when the RIB receives End-of-RIB
(EOR) messages. There is a special EOR message for each AFI (Address Family
Identifier).
-* IPv4 EOR is an empty Update message
+* IPv4 EOR is an empty Update message.
* Ipv6 EOR is an Update message with empty MP_UNREACH attribute where
AFI and SAFI (Subsequent Address Family Identifier) are set to Ipv6.
-OpenDaylight also supports EOR for IPv4 in this format
+OpenDaylight also supports EOR for IPv4 in this format.
* Linkstate EOR is an Update message with empty MP_UNREACH attribute
-where AFI and SAFI are set to Linkstate
+where AFI and SAFI are set to Linkstate.
For BGP connections, where both peers support graceful restart, the EORs
are sent by the BGP speaker and are redirected to RIB, where the specific
AFI/SAFI table is set to _true_. Without graceful restart, the
messages are generated by OpenDaylight itself and sent after second keepalive for
each AFI/SAFI. This is done in
-_https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPSynchronization.java;hb=refs/heads/stable/lithium[BGPSynchronization]_
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPSynchronization.java;hb=refs/heads/stable/beryllium[BGPSynchronization].
*Peers*
-_https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPPeer.java;hb=refs/heads/stable/lithium[BGPPeer]_
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPPeer.java;hb=refs/heads/stable/beryllium[BGPPeer]
has various meanings. If you configure BGP listener, _BGPPeer_
represents the BGP listener itself. If you are configuring BGP speaker,
you need to provide a list of peers, that are allowed to connect to this
speaker. Unknown peer represents, in this case, a peer that is allowed
to be refused. _BGPPeer_ represents in this case peer, that is supposed
-to connect to your speaker. _BGPPeer_ is stored in _https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/StrictBGPPeerRegistry.java;hb=refs/heads/stable/lithium[BGPPeerRegistry]_.
+to connect to your speaker. _BGPPeer_ is stored in https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/StrictBGPPeerRegistry.java;hb=refs/heads/stable/beryllium[BGPPeerRegistry].
This registry controls the number of sessions. Our strict implementation
limits sessions to one per peer.
-_https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/ApplicationPeer.java;hb=refs/heads/stable/lithium[ApplicationPeer]_
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/ApplicationPeer.java;hb=refs/heads/stable/beryllium[ApplicationPeer]
is a special case of peer, that has it's own RIB. This RIB is populated
from RESTCONF. The RIB is synchronized with default BGP RIB. Incoming
routes to the default RIB are treated in the same way as they were from a
==== RIB handling
RIB (Route Information Base) is defined as a concept in
-http://tools.ietf.org/html/rfc4271#section-3.2[RFC4271]. RFC does not
+http://tools.ietf.org/html/rfc4271#section-3.2[RFC 4271]. RFC does not
define how it should be implemented. In our implementation,
-the routes are stored in MD-SALs data-store. There are four supported
+the routes are stored in the MD-SAL datastore. There are four supported
routes - _Ipv4Routes_, _Ipv6Routes_, _LinkstateRoutes_ and
_FlowspecRoutes_.
Each route type needs to provide a
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-spi/src/main/java/org/opendaylight/protocol/bgp/rib/spi/RIBSupport.java;hb=refs/heads/stable/lithium[RIBSupport.java]
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-spi/src/main/java/org/opendaylight/protocol/bgp/rib/spi/RIBSupport.java;hb=refs/heads/stable/beryllium[RIBSupport.java]
implementation. _RIBSupport_ tells RIB how to parse binding-aware data
(BGP Update message) to binding-independent (datastore format).
image::bgpcep/RIB.png[height="450px", width="550px",title="RIB"]
-*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibInWriter.java;hb=refs/heads/stable/lithium[AdjRibInWriter]*
+*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibInWriter.java;hb=refs/heads/stable/beryllium[AdjRibInWriter]*
- represents the first step in putting data to datastore. This writer is
notified whenever a peer receives an Update message. The message is
transformed into binding-independent format and pushed into datastore to
_adj-rib-in_. This RIB is associated with a peer.
-*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/EffectiveRibInWriter.java;hb=refs/heads/stable/lithium[EffectiveRibInWriter]*
+*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/EffectiveRibInWriter.java;hb=refs/heads/stable/beryllium[EffectiveRibInWriter]*
- this writer is notified whenever _adj-rib-in_ is updated. It applies
all configured import policies to the routes and stores them in
_effective-rib-in_. This RIB is also associated with a peer.
-*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/LocRibWriter.java;hb=refs/heads/stable/lithium[LocRibWriter]*
+*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/LocRibWriter.java;hb=refs/heads/stable/beryllium[LocRibWriter]*
- this writer is notified whenever *any* _effective-rib-in_ is updated
(in any peer). Performs best path selection filtering and stores the
routes in _loc-rib_. It also determines which routes need to be
advertised and fills in _adj-rib-out_ that is per peer as well.
-*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibOutListener.java;h=a14fd54a29ea613b381a36248f67491d968963b8;hb=refs/heads/stable/lithium[AdjRibOutListener]*
+*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibOutListener.java;h=a14fd54a29ea613b381a36248f67491d968963b8;hb=refs/heads/stable/beryllium[AdjRibOutListener]*
- listens for changes in _adj-rib-out_, transforms the routes into
BGPUpdate messages and sends them to its associated peer.
=== BGP inet
This module contains only one YANG model
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/inet/src/main/yang/bgp-inet.yang;hb=refs/heads/stable/lithium[bgp-inet.yang]
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/inet/src/main/yang/bgp-inet.yang;hb=refs/heads/stable/beryllium[bgp-inet.yang]
that summarizes the ipv4 and ipv6 extensions to RIB routes and BGP
messages.
=== BGP flowspec
BGP flowspec is a module that implements
-http://tools.ietf.org/html/rfc5575[RFC5575]. The RFC defines an
-extension to BGP in form of a new subsequent address family, NLRI and
+http://tools.ietf.org/html/rfc5575[RFC 5575] for IPv4 AFI and https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-06[draft-ietf-idr-flow-spec-v6-06] for IPv6 AFI.
+The RFC defines an extension to BGP in form of a new subsequent address family, NLRI and
extended communities. All of those are defined in the
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/flowspec/src/main/yang/bgp-flowspec.yang;hb=refs/heads/stable/lithium[bgp-flowspec.yang]
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/flowspec/src/main/yang/bgp-flowspec.yang;hb=refs/heads/stable/beryllium[bgp-flowspec.yang]
model. In addition to generated sources, the module contains parsers for
newly defined elements and RIBSupport for flowspec-routes. The route key of
flowspec routes is a string representing human-readable flowspec
version 04. The draft defines an extension to BGP in form of a new
address family, subsequent address family, NLRI and path attribute. All
of those are defined in the
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/yang/bgp-linkstate.yang;hb=refs/heads/stable/lithium[bgp-linkstate.yang]
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/yang/bgp-linkstate.yang;hb=refs/heads/stable/beryllium[bgp-linkstate.yang]
model. In addition to generated sources, the module contains
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/attribute/LinkstateAttributeParser.java;hb=refs/heads/stable/lithium[LinkstateAttributeParser],
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/nlri/LinkstateNlriParser.java;hb=refs/heads/stable/lithium[LinkstateNlriParser],
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/attribute/LinkstateAttributeParser.java;hb=refs/heads/stable/beryllium[LinkstateAttributeParser],
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/nlri/LinkstateNlriParser.java;hb=refs/heads/stable/beryllium[LinkstateNlriParser],
activators for both, parser and RIB, and RIBSupport handler for
linkstate address family. As each route needs a key, in case of
linkstate, the route key is defined as a binary string, containing all
-the nlri serialized to byte format.
+the NLRI serialized to byte format.
+The BGP linkstate extension also supports distribution of MPLS TE state as defined in https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-03[draft-ietf-idr-te-lsp-distribution-03],
+extension for Segment Routing https://tools.ietf.org/html/draft-gredler-idr-bgp-ls-segment-routing-ext-00[draft-gredler-idr-bgp-ls-segment-routing-ext-00] and
+Segment Routing Egress Peer Engineering https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-02[draft-ietf-idr-bgpls-segment-routing-epe-02].
+
+=== BGP labeled-unicast
+
+BGP labeled unicast is a module that implements https://tools.ietf.org/html/rfc3107[RFC 3107]. The RFC defines an extension to the BGP MP to carry Label Mapping Information
+as a part of the NLRI. The AFI indicates, as usual, the address family of the associated route. The fact that the NLRI contains a label
+is indicated by using SAFI value 4. All of those are defined in https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob_plain;f=bgp/labeled-unicast/src/main/yang/bgp-labeled-unicast.yang;hb=refs/heads/stable/beryllium[bgp-labeled-unicast.yang] model. In addition to the generated sources,
+the module contains new NLRI codec and RIBSupport. The route key is defined as a binary, where whole NLRI information is encoded.
=== BGP topology provider
<name>global-pcep-extensions</name>
</pcep-extensions>
<pcep-session-proposal-factory>
- <type xmlns:pcep="urn:opendaylight:params:xml:ns:yang:controller:pcep">pcep:pcep-session-proposal-factory</type>
- <name>stateful07-proposal</name>
+ <type xmlns:pcep="urn:opendaylight:params:xml:ns:yang:controller:pcep">pcep:pcep-session-proposal-factory</type>
+ <name>global-pcep-session-proposal-factory</name>
</pcep-session-proposal-factory>
<boss-group>
<type xmlns:netty="urn:opendaylight:params:xml:ns:yang:controller:netty">netty:netty-threadgroup</type>
[source,xml]
----
- <module>
- <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">prefix:pcep-extensions-impl</type>
- <name>global-pcep-extensions</name>
- <extension>
- <type xmlns:pcepspi="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">pcepspi:extension</type>
- <name>pcep-parser-base</name>
- </extension>
- <extension>
- <type xmlns:pcepspi="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">pcepspi:extension</type>
- <name>pcep-parser-ietf-stateful07</name>
- </extension>
- <extension>
- <type xmlns:pcepspi="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">pcepspi:extension</type>
- <name>pcep-parser-ietf-initiated00</name>
- </extension>
- </module>
+<module>
+ <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">prefix:pcep-extensions-impl</type>
+ <name>global-pcep-extensions</name>
+ <extension>
+ <type xmlns:pcepspi="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">pcepspi:extension</type>
+ <name>pcep-parser-base</name>
+ </extension>
+ <extension>
+ <type xmlns:pcepspi="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">pcepspi:extension</type>
+ <name>pcep-parser-ietf-stateful07</name>
+ </extension>
+ <extension>
+ <type xmlns:pcepspi="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">pcepspi:extension</type>
+ <name>pcep-parser-ietf-initiated00</name>
+ </extension>
+ <extension>
+ <type xmlns:pcepspi="urn:opendaylight:params:xml:ns:yang:controller:pcep:spi">pcepspi:extension</type>
+ <name>pcep-parser-sync-optimizations</name>
+ </extension>
+</module>
----
* _pcep-parser-base_ - will register parsers and serializers
implemented in pcep-impl module
* _pcep-parser-ietf-stateful07_ - will register parsers and
-serializers implemented in stateful07 module
+serializers of draft-ietf-pce-stateful-pce-07 implementation
+
+* _pcep-parser-ietf-initiated00_ - will register parser and
+serializer of draft-ietf-pce-pce-initiated-lsp-00 implementation
+
+* _pcep-parser-sync-optimizations_ - will register parser and
+serializers of draft-ietf-pce-stateful-sync-optimizations-03 implementation
Stateful07 module is a good example of a PCEP parser extension.
Configuration of PCEP parsers specifies one implementation of _Extension
provider_ that will take care of registering mentioned parser
extensions:
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/spi/src/main/java/org/opendaylight/protocol/pcep/spi/pojo/SimplePCEPExtensionProviderContext.java;hb=refs/for/stable/lithium[SimplePCEPExtensionProviderContext].
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/spi/src/main/java/org/opendaylight/protocol/pcep/spi/pojo/SimplePCEPExtensionProviderContext.java;hb=refs/for/stable/beryllium[SimplePCEPExtensionProviderContext].
All registries are implemented in package
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=pcep/spi/src/main/java/org/opendaylight/protocol/pcep/spi/pojo;hb=refs/for/stable/lithium[pcep-spi].
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=pcep/spi/src/main/java/org/opendaylight/protocol/pcep/spi/pojo;hb=refs/for/stable/beryllium[pcep-spi].
===== Parsing
The stateful draft declared new elements as well as additional fields or
TLVs (type,length,value) to known objects. All new elements are defined in yang models, that
contain augmentations to elements defined in
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/api/src/main/yang/pcep-types.yang;hb=refs/for/stable/lithium[pcep-types.yang].
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/api/src/main/yang/pcep-types.yang;hb=refs/for/stable/beryllium[pcep-types.yang].
In the case of extending known elements, the _Parser_ class merely extends
the base class and overrides necessary methods as shown in following
diagram:
The yang models of subobject, SR-PCE-CAPABILITY TLV and appropriate
augmentations are defined in
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/yang/odl-pcep-segment-routing.yang;hb=refs/for/stable/lithium[odl-pcep-segment-routing.yang]. +
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/yang/odl-pcep-segment-routing.yang;hb=refs/for/stable/beryllium[odl-pcep-segment-routing.yang]. +
The pcep-segment-routing module includes parsers/serializers for new
subobject
-(https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/java/org/opendaylight/protocol/pcep/segment/routing/SrEroSubobjectParser.java;hb=refs/for/stable/lithium[SrEroSubobjectParser])
+(https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/java/org/opendaylight/protocol/pcep/segment/routing/SrEroSubobjectParser.java;hb=refs/for/stable/beryllium[SrEroSubobjectParser])
and TLV
-(https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/java/org/opendaylight/protocol/pcep/segment/routing/SrPceCapabilityTlvParser.java;hb=refs/for/stable/lithium[SrPceCapabilityTlvParser]).
+(https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/java/org/opendaylight/protocol/pcep/segment/routing/SrPceCapabilityTlvParser.java;hb=refs/for/stable/beryllium[SrPceCapabilityTlvParser]).
The pcep-segment-routing module implements
http://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-01[draft-ietf-pce-lsp-setup-type-01],
For Segment Routing, PST = 1 is defined.
The Path Setup Type TLV is modeled with yang in module
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/api/src/main/yang/pcep-types.yang;hb=refs/for/stable/lithium[pcep-types.yang].
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/api/src/main/yang/pcep-types.yang;hb=refs/for/stable/beryllium[pcep-types.yang].
A parser/serializer is implemented in
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/impl/src/main/java/org/opendaylight/protocol/pcep/impl/tlv/PathSetupTypeTlvParser.java;hb=refs/for/stable/lithium[PathSetupTypeTlvParser]
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/impl/src/main/java/org/opendaylight/protocol/pcep/impl/tlv/PathSetupTypeTlvParser.java;hb=refs/for/stable/beryllium[PathSetupTypeTlvParser]
and it is overriden in segment-routing module to provide the aditional
PST.
+==== PCEP Synchronization Procedures Optimization
+
+Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE draft-ietf-pce-stateful-sync-optimizations-03 specifies following optimizations for state synchronization and the corresponding PCEP procedures and extensions:
+
+* *State Synchronization Avoidance:* To skip state synchronization if the state has survived and not changed during session restart.
+
+* *Incremental State Synchronization:* To do incremental (delta) state synchronization when possible.
+
+* *PCE-triggered Initial Synchronization:* To let PCE control the timing of the initial state synchronization.
+The capability can be applied to both full and incremental state synchronization.
+
+* *PCE-triggered Re-synchronization:* To let PCE re-synchronize the state for sanity check.
+
+
==== PCEP Topology
PCEP data is displayed only through one URL that is accessible from the base network-topology URL:
include::netide/netide-developer-guide.adoc[]
+include::neutron/odl-neutron-service-dev.adoc[]
+
include::neutron/neutron.adoc[]
include::odlparent/odlparent-developer.adoc[]
=== Key APIs and Interfaces
+==== FlowObjective API
+
+Following are the list of the APIs to create the flow objectives to install the
+flow rule in OpenFlow switch in pipeline agnostic way. Currently these APIs are
+getting consumed by Atrium project.
+
+Install the Forwarding Objective:
+
+---
+http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward
+---
+
+Install the Filter Objective
+
+---
+http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter
+---
+
+
+Install the Next Objective:
+
+---
+http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next
+---
+
+==== Flow mod driver API
+
The Beryllium release includes a flow mod driver for the HP 3800.
-This driver adjusts the flows and push the same to the device.
+This driver adjusts the flows and push the same to the device.
This API takes the flow to be adjusted as input and displays the adjusted flow as output in the REST output container.
Here is the REST API to adjust and push flows to HP 3800 device:
== Neutron Northbound
-=== How to Write a SB Neutron Consumer
-
-In Lithium, there will be two options for SB Neutron Consumers:
-
-* Using the legacy I*Aware interfaces
-* Listening for changes via the Neutron YANG model
-
-=== How to use the legacy I*Aware interfaces
-
-For each neutron data object, there is an I*Aware interface defined to allow
-southbound providers that don't want to use the MD-SAL to register with the
-Neutron service to be made aware of potential operations on that type of
-object. For each modification operation (create, update and delete), the
-I*Aware interface defines a pair of calls (The general template
-is shown in the following table, please see javadoc of the specific interface
-for specific details)
-
-.I*Aware Methods
-|===
-|Create |Update |Delete
-
-|canCreate*()
-|canUpdate*()
-|canDelete*()
-
-|neutron*Created()
-|neutron*Updated()
-|neutron*Deleted()
-|===
-
-==== The semantics of the can*() methods
-
-Each of the can*() methods gives a southbound provider a vote on whether a
-proposed change is acceptable or not. A southbound provider that implements
-a particular can*() method is expected to return an HTTP response code as
-its "vote" - values between 200 and 299 are a "yes" vote, other values are
-a "no" vote. The neutron white board pattern is an all or nothing affair:
-if any one southbound provider votes no on a change, that change is rejected.
-
-For the canCreate*() method, the southbound provider recieves the proposed
-object. In the case of canDelete*(), the southbound provider recieves the
-current object that will be removed. Lastly, the canUpdate*() method passed
-the current object and the proposed delta.
-
-==== The semantics of the neutron*() methods
-
-Once all southbound providers vote yes for a particular change, the neutron
-service transcribes the change into its caches/MD-SAL models and then calls
-the appropriate neutron*() method on each registered southbound provider.
-At this point, the southbound provider is expected to meet the request as
-best they can and when they can, taking responsibility for any errors that
-might be incurred (there is no back signalling of errors). For these calls,
-the modified object is provided in all cases, except for the neutron*Deleted()
-method. This passes an instance of the deleted object that will be garbage
-collected once all the southbound providers are finished with it.
-
-==== How to register your consumer with the Neutron Service
-
-A southbound provider that wants to register with the neutron service
-via a particular I*Aware interface must first implement that interface.
-Then, in the init class of its Activator method, it should add the name of
-the implemented I*Aware class as an interface that is managed, along with
-the class that implements the interface as the implementation via the
-setInterface method. The following example from the Neutron test dummy
-provider shows it is registering for *all* I*Aware interfaces:
-
-[source,java]
-----
- @Override
- public void init(BundleContext context, DependencyManager manager) throws Exception {
- manager.add(createComponent().setInterface(new String[] {
- INeutronFirewallAware.class.getName()}, null)
- .setImplementation(NeutronFirewallDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronFirewallPolicyAware.class.getName()}, null)
- .setImplementation(NeutronFirewallPolicyDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronFirewallRuleAware.class.getName()}, null)
- .setImplementation(NeutronFirewallRuleDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronFloatingIPAware.class.getName()}, null)
- .setImplementation(NeutronFloatingIPDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronLoadBalancerAware.class.getName()}, null)
- .setImplementation(NeutronLoadBalancerDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronLoadBalancerHealthMonitorAware.class.getName()}, null)
- .setImplementation(NeutronLoadBalancerHealthMonitorDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronLoadBalancerListenerAware.class.getName()}, null)
- .setImplementation(NeutronLoadBalancerListenerDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronLoadBalancerPoolAware.class.getName()}, null)
- .setImplementation(NeutronLoadBalancerPoolDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronLoadBalancerPoolMemberAware.class.getName()}, null)
- .setImplementation(NeutronLoadBalancerPoolMemberDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronNetworkAware.class.getName()}, null)
- .setImplementation(NeutronNetworkDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronPortAware.class.getName()}, null)
- .setImplementation(NeutronPortDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronRouterAware.class.getName()}, null)
- .setImplementation(NeutronRouterDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronSecurityGroupAware.class.getName()}, null)
- .setImplementation(NeutronSecurityGroupDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronSecurityRuleAware.class.getName()}, null)
- .setImplementation(NeutronSecurityRuleDummyProvider.class));
- manager.add(createComponent().setInterface(new String[] {
- INeutronSubnetAware.class.getName()}, null)
- .setImplementation(NeutronSubnetDummyProvider.class));
- }
-----
-
-=== How to use the Neutron YANG model
-
-For each neutron data object, there is an Neutron*Interface defined within
+=== How to add new API support
+OpenStack Neutron is a moving target. It is continuously adding new features
+as new rest APIs. Here is a basic step to add new API support:
+
+In the Neutron Northbound project:
+
+* Add new YANG model for it under `neutron/model/src/main/yang` and
+ `update neutron.yang`
+* Add northbound API for it, and neutron-spi
+** Implement `Neutron<New API>Request.java` and `Neutron<New API>Norhtbound.java`
+ under
+ `neutron/northbound-api/src/main/java/org/opendaylight/neutron/northbound/api/`
+** Implement `INeutron<New API>CRUD.java` and new data structure if any under
+ `neutron/neutron-spi/src/main/java/org/opendaylight/neutron/spi/`
+** update
+ `neutron/neutron-spi/src/main/java/org/opendaylight/neutron/spi/NeutronCRUDInterfaces.java`
+ to wire new CRUD interface
+** Add unit tests, `Neutron<New structure>JAXBTest.java` under
+ `neutron/neutron-spi/src/test/java/org/opendaylight/neutron/spi/`
+* update
+ `neutron/northbound-api/src/main/java/org/opendaylight/neutron/northbound/api/NeutronNorthboundRSApplication.java`
+ to wire new northbound api to `RSApplication`
+* Add transcriber, `Neutron<New API>Interface.java` under
+ `transcriber/src/main/java/org/opendaylight/neutron/transcriber/`
+* update
+ `transcriber/src/main/java/org/opendaylight/neutron/transcriber/NeutronTranscriberProvider.java`
+ to wire a new transcriber
+** Add integration tests `Neutron<New API>Tests.java`
+ under `integration/test/src/test/java/org/opendaylight/neutron/e2etest/`
+** update `integration/test/src/test/java/org/opendaylight/neutron/e2etest/ITNeutronE2E.java`
+ to run a newly added tests.
+
+In OpenStack networking-odl
+
+* Add new driver (or plugin) for new API with tests.
+
+In a southbound Neutron Provider
+
+* implement actual backend to realize those new API by listening related YANG
+ models.
+
+
+=== How to write transcriber
+
+For each Neutron data object, there is an `Neutron*Interface` defined within
the transcriber artifact that will write that object to the MD-SAL
-configurational datastore. +
-All Neutron*Interface extend AbstractNeutronInterface, in which two methods
-are defined: +
+configuration datastore.
+
+All `Neutron*Interface` extend `AbstractNeutronInterface`, in which two methods
+are defined:
-* one takes the neutron object as input, and will create a data object from it. +
+* one takes the Neutron object as input, and will create a data object from it.
* one takes an uuid as input, and will create a data object containing the uuid.
----
protected abstract T toMd(String uuid);
----
-In addition the AbstractNeutronInterface class provides several other
-helper methods (addMd, updateMd, removeMd), which handle the actual
+In addition the `AbstractNeutronInterface` class provides several other
+helper methods (`addMd`, `updateMd`, `removeMd`), which handle the actual
writing to the configuration datastore.
-==== The semantics of the toMD() methods
+==== The semantics of the `toMD()` methods
Each of the Neutron YANG models defines structures containing data.
-Further each YANG-modeled structures has it own builder.
-A particular toMD() method instantiates an instance of the correct
+Further each YANG-modeled structure has it own builder.
+A particular `toMD()` method instantiates an instance of the correct
builder, fills in the properties of the builder from the corresponding
values of the Neutron object and then creates the YANG-modeled structures
-via the build() method.
+via the `build()` method.
-As an example, one of the toMD code for Neutron Networks is
+As an example, one of the `toMD` code for Neutron Networks is
presented below:
----
- protected Network toMd(NeutronNetwork network) {
- NetworkBuilder networkBuilder = new NetworkBuilder();
- networkBuilder.setAdminStateUp(network.getAdminStateUp());
- if (network.getNetworkName() != null) {
- networkBuilder.setName(network.getNetworkName());
- }
- if (network.getShared() != null) {
- networkBuilder.setShared(network.getShared());
- }
- if (network.getStatus() != null) {
- networkBuilder.setStatus(network.getStatus());
- }
- if (network.getSubnets() != null) {
- List<Uuid> subnets = new ArrayList<Uuid>();
- for( String subnet : network.getSubnets()) {
- subnets.add(toUuid(subnet));
- }
- networkBuilder.setSubnets(subnets);
- }
- if (network.getTenantID() != null) {
- networkBuilder.setTenantId(toUuid(network.getTenantID()));
- }
- if (network.getNetworkUUID() != null) {
- networkBuilder.setUuid(toUuid(network.getNetworkUUID()));
- } else {
- logger.warn("Attempting to write neutron network without UUID");
+protected Network toMd(NeutronNetwork network) {
+ NetworkBuilder networkBuilder = new NetworkBuilder();
+ networkBuilder.setAdminStateUp(network.getAdminStateUp());
+ if (network.getNetworkName() != null) {
+ networkBuilder.setName(network.getNetworkName());
+ }
+ if (network.getShared() != null) {
+ networkBuilder.setShared(network.getShared());
+ }
+ if (network.getStatus() != null) {
+ networkBuilder.setStatus(network.getStatus());
+ }
+ if (network.getSubnets() != null) {
+ List<Uuid> subnets = new ArrayList<Uuid>();
+ for( String subnet : network.getSubnets()) {
+ subnets.add(toUuid(subnet));
}
- return networkBuilder.build();
+ networkBuilder.setSubnets(subnets);
+ }
+ if (network.getTenantID() != null) {
+ networkBuilder.setTenantId(toUuid(network.getTenantID()));
+ }
+ if (network.getNetworkUUID() != null) {
+ networkBuilder.setUuid(toUuid(network.getNetworkUUID()));
+ } else {
+ logger.warn("Attempting to write neutron network without UUID");
}
+ return networkBuilder.build();
+}
----
--- /dev/null
+== Neutron Service Developer Guide
+
+=== Overview
+This Karaf feature (`odl-neutron-service`) provides integration support for OpenStack Neutron
+via the OpenDaylight ML2 mechanism driver. The Neutron Service is only one of the
+components necessary for OpenStack integration.
+It defines YANG models for OpenStack Neutron data models and northbound
+API via REST API and YANG model RESTCONF.
+
+Those developers who want to add new provider for new OpenStack Neutron
+extensions/services (Neutron constantly adds new extensions/services and OpenDaylight
+will keep up with those new things) need to communicate with this Neutron
+Service or add models to Neutron Service.
+If you want to add new extensions/services themselves to the Neutron Service,
+new YANG data models need to be added, but that is out of scope of this document
+because this guide is for a developer who will be _using_ the feature
+to build something separate, but _not_ somebody who will be developing
+code for this feature itself.
+
+=== Neutron Service Architecture
+image::neutron/odl-neutron-service-developer-architecture.png[height="450px", width="550px", title="Neutron Service Architecture"]
+// image original: https://docs.google.com/drawings/d/15xtroJahSFt93K10Zp8AVln_WZgowmhv7MC_2VdZQzg/edit?usp=sharing
+
+The Neutron Service defines YANG models for OpenStack Neutron integration.
+When OpenStack admins/users request changes (creation/update/deletion)
+of Neutron resources, e.g., Neutron network, Neutron subnet, Neutron port, the corresponding YANG model within OpenDaylight will be modified.
+The OpenDaylight OpenStack will subscribe the changes on those models and
+will be notified those modification through MD-SAL when changes are made.
+Then the provider will do the necessary tasks to realize OpenStack integration.
+How to realize it (or even not realize it) is up to each provider.
+The Neutron Service itself does not take care of it.
+
+=== How to Write a SB Neutron Consumer
+In Boron, there is only one options for SB Neutron Consumers:
+
+* Listening for changes via the Neutron YANG model
+
+Until Beryllium there was another way with the legacy I*Aware interface.
+From Boron, the interface was eliminated. So all the SB Neutron Consumers
+have to use Neutron YANG model.
+
+
+=== Neutron YANG models
+Neutron service defines YANG models for Neutron. The details can be found
+at
+
+* https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=tree;f=model/src/main/yang;hb=refs/heads/stable/boron
+
+Basically those models are based on OpenStack Neutron API definitions.
+For exact definitions, OpenStack Neutron source code needs to be referred
+as the above documentation doesn't always cover the necessary details.
+There is nothing special to utilize those Neutron YANG models.
+The basic procedure will be:
+
+. subscribe for changes made to the the model
+. respond on the data change notification for each models
+
+[NOTE]
+Currently there is no way to refuse the request configuration at this
+point. That is left to future work.
+
+[source,java]
+----
+public class NeutronNetworkChangeListener implements DataChangeListener, AutoCloseable {
+ private ListenerRegistration<DataChangeListener> registration;
+ private DataBroker db;
+
+ public NeutronNetworkChangeListener(DataBroker db){
+ this.db = db;
+ // create identity path to register on service startup
+ InstanceIdentifier<Network> path = InstanceIdentifier
+ .create(Neutron.class)
+ .child(Networks.class)
+ .child(Network.class);
+ LOG.debug("Register listener for Neutron Network model data changes");
+ // register for Data Change Notification
+ registration =
+ this.db.registerDataChangeListener(LogicalDatastoreType.CONFIGURATION, path, this, DataChangeScope.ONE);
+
+ }
+
+ @Override
+ public void onDataChanged(
+ AsyncDataChangeEvent<InstanceIdentifier<?>, DataObject> changes) {
+ LOG.trace("Data changes : {}",changes);
+
+ // handle data change notification
+ Object[] subscribers = NeutronIAwareUtil.getInstances(INeutronNetworkAware.class, this);
+ createNetwork(changes, subscribers);
+ updateNetwork(changes, subscribers);
+ deleteNetwork(changes, subscribers);
+ }
+}
+----
+
+=== Neutron configuration
+From Boron, new models of configuration for OpenDaylight to tell
+OpenStack neutron/networking-odl its configuration/capability.
+
+==== hostconfig
+This is for OpenDaylight to tell per-node configuration to Neutron.
+Especially this is used by pseudo agent port binding heavily.
+
+The model definition can be found at
+
+* https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=model/src/main/yang/neutron-hostconfig.yang;hb=refs/heads/stable/boron
+
+How to populate this for pseudo agent port binding is documented at
+
+* http://git.openstack.org/cgit/openstack/networking-odl/tree/doc/source/devref/hostconfig.rst
+
+==== Neutron extension config
+In Boron this is experimental.
+The model definition can be found at
+
+* https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=model/src/main/yang/neutron-extensions.yang;hb=refs/heads/stable/boron
+
+Each Neutron Service provider has its own feature set. Some support
+the full features of OpenStack, but others support only a subset.
+With same supported Neutron API, some functionality may or may not be
+supported. So there is a need for a way that OpenDaylight can tell networking-odl its
+capability. Thus networking-odl can initialize Neutron properly based
+on reported capability.
+
+
+=== Neutorn Logger
+There is another small Karaf feature, `odl-neutron-logger`, which logs changes of Neutron
+YANG models. which can be used for debug/audit.
+
+It would also help to understand how to listen the change.
+
+* https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=neutron-logger/src/main/java/org/opendaylight/neutron/logger/NeutronLogger.java;hb=refs/heads/stable/boron
+
+
+=== API Reference Documentation
+The OpenStack Neutron API references
+
+* http://developer.openstack.org/api-ref-networking-v2.html
+* http://developer.openstack.org/api-ref-networking-v2-ext.html
* VTN service Java API Library
.VTN-Coordinator_api-architechture
-image::vtn/Vtn-coordinator-api-architecture.png[width=300]
+image::vtn/vtn-coordinator-api-architecture.png[width=300]
====== Web Server
https://tools.ietf.org/html/rfc7285[RFC 7285] in OpenDaylight.
This user guide will introduce the three basic services (namely
-`simple-ird`, `manual-maps` and `host-tracker`) which are implemented in
+`simple-ird`, `manual-maps` and `host-tracker`) which are implemented since
the Beryllium release, and give instructions on how to configure them to
provide corresponding ALTO services.
+A new feature named `simple-pce` (**Simple Path Computation Engine**) is
+added into Boron release as an ALTO extension service.
+
=== How to Identify ALTO Resources ===
Each ALTO resource can be uniquely identified by a tuple . For each
The `resource-config` package also provides a query RPC to config the resources.
You can CREATE, UPDATE and DELETE *network-maps* and *cost-maps* via query RPC.
+=== Simple Path Computation Engine ===
+
+The `simple-pce` module provides a simple path computation engine for ALTO and other
+projects. It supports basic CRUD (create, read, update, delete) operations to manage
+L2 and L3 routing with/without rate limitation. This module is an independent
+feature, so you can follow the instruction below to install it independently.
+
+[source,bash]
+karaf > feature:install odl-alto-extenstion
+
+NOTE: The rate limitation meter requires OpenFlow 1.3 support.
+
+==== Basic Usage with RESTCONF API ====
+
+You can use the simple path computation engine with RESTCONF API, which is defined
+in the YANG model https://git.opendaylight.org/gerrit/gitweb?p=alto.git;a=blob;f=alto-extensions/simple-pce/api/src/main/yang/alto-spce.yang;h=f5bbe6744f7dfba493edd275aa18114e363727ab;hb=refs/heads/stable/boron[here].
+
=== Use Case ===
==== Server Selection ====
== BGP User Guide ==
-=== Overview ===
-The OpenDaylight Karaf distribution comes pre-configured with baseline BGP
-configuration. You can find it in the etc/opendaylight/karaf directory and it
+=== Configuring BGP ===
+
+The OpenDaylight Karaf distribution comes pre-configured with a baseline BGP
+configuration. You can find it in the `etc/opendaylight/karaf` directory and it
consists of two files:
-- *31-bgp.xml* (defines the basic parser and RIB support)
-- *41-bgp-example.xml* (which contains a sample configuration which needs to be
+`31-bgp.xml`:: defines the basic parser and RIB support
+`41-bgp-example.xml`:: contains a sample configuration which needs to be
customized to your deployment)
The next sections will describe how to configure BGP manually or using RESTCONF.
-=== Configuring BGP ===
-
==== RIB ====
+
+The configuration of the Routing Information Base (RIB) is specified using a block in the `41-bgp-example.xml` file.
+
[source,xml]
----
<module>
</module>
----
-- *rib-id* - BGP RIB Identifier, in this configuration file you can specify more BGP RIBs by
-copy-pasting the above module. These RIBs must have a unique rib-id and name.
-- *local-as* - Our local AS number (where OpenDaylight is deployed), we use this in best path selection
-- *bgp-id* - Our local BGP identifier (the IP of the VM where OpenDaylight is deployed),
+- *type* - should always be set to `prefix:rib-impl`
+- *name* and *rib-id* - BGP RIB Identifier, you can specify multiple BGP RIBs by
+having multiple the above `module` blocks. Each such RIB must have a unique rib-id and name.
+- *local-as* - the local AS number (where OpenDaylight is deployed), we use this in best path selection
+- *bgp-id* - the local BGP identifier (the IP of the VM where OpenDaylight is deployed),
we use this in best path selection.
-- *cluster-id* - Cluster Identifier, non-mandatory, if not specified, BGP Identifier will be used
+- *cluster-id* - cluster identifier, optional, if not specified, BGP Identifier will be used
-MIGHT NOT BE NEEDED: depending on your BGP router, you might need to switch from
+Depending on your BGP router, you might need to switch from
linkstate attribute type 99 to 29. Check with your router vendor. Change the
field iana-linkstate-attribute-type to true if your router supports type 29.
-This snippet is located in 31-bgp.xml file.
+This snippet is located in `31-bgp.xml` file.
[source,xml]
----
----
- *iana-linkstate-attribute-type* - IANA has issued an early allocation for the
-BGP Linkstate path attribute (=29). To preserve (TYPE = 99) set value bellow
+BGP linkstate path attribute (=29). To preserve he old value (=99) set this to
to false; to use IANA assigned type set the value to true or remove it as it's true by default.
==== BGP Peer ====
</module>
----
-- *name* - BGP Peer name, in this configuration file you can specify more BGP Peers by copy-pasting the above module. These peers must have a *unique* name.
-- *host* - IP address or hostname of BGP speaker (IP where OpenDaylight should connect to gather topology)
-- *holdtimer* - unit: seconds
-- *peer-role* - If peer role is not present, default value "ibgp" will be used (allowed values are also "ebgp" and "rr-client"). This field is case-sensitive.
+- *name* - BGP Peer name, in this configuration file you specify multiple BGP Peers by replicating the above `module` block. Each peers must have a unique name.
+- *host* - IP address or hostname of BGP speaker where OpenDaylight should connect to the peer
+- *holdtimer* - hold time in seconds
+- *peer-role* - If peer role is not present, default value "ibgp" will be used (other allowed values are "ebgp" and "rr-client"). This field is case-sensitive.
- *rib* - BGP RIB identifier
-==== Configure Connection Attributes - OPTIONAL ====
+==== Configure Connection Attributes (Optional) ====
[source,xml]
----
</module>
----
-- *min-sleep* - Minimum sleep time (miliseconds) in between reconnect tries
-- *max-sleep* - Maximum sleep time (miliseconds) in between reconnect tries
-- *sleep-factor* - Power factor of the sleep time between reconnect tries
-- *connect-time* - How long we should wait (miliseconds) for the TCP connect
-attempt, overrides default connection timeout dictated by TCP retransmits
+- *min-sleep* - minimum sleep time (miliseconds) in between reconnect tries
+- *max-sleep* - maximum sleep time (miliseconds) in between reconnect tries
+- *sleep-factor* - power factor of the sleep time between reconnect tries, i.e., the previous sleep time will be multiplied by this number to determine the next sleep time, but never exceed *max-sleep*
+- *connect-time* - how long BGP should wait (miliseconds) for the TCP connect
+attempt, overrides default connection timeout dictated by TCP.
==== BGP Speaker Configuration ====
-Previous entries addressed the configuration of a BGP connection initiated by
-OpenDaylight. OpenDaylight also supports BGP Speaker functionality and accepts
-incoming BGP connections.
+The previous entries described configuration of a BGP connections initiated by
+OpenDaylight. OpenDaylight can also accept incoming BGP connections.
-*The configuration of BGP speaker is located in: 41-bgp-example.xml:
+The configuration of BGP speaker is located in: `41-bgp-example.xml`:
[source,xml]
----
</module>
----
-*Changing speaker configuration*
- Changing binding address: Uncomment tag binding-address and change the address to e.g. _127.0.0.1_. The default binding address is _0.0.0.0_.
- Changing binding port: Uncomment tag binding-port and change the port to e.g.
- _1790_. The default binding port is _179_ as specified in link:http://tools.ietf.org/html/rfc4271[BGP RFC]. --
+ _1790_. The default binding port is _179_ as specified in link:http://tools.ietf.org/html/rfc4271[RFC 4271].
==== Incomming BGP Connections ====
-*BGP speaker drops all BGP connections from unknown BGP peers.* The decision is
+*The BGP speaker drops all BGP connections from unknown BGP peers.* The decision is
made in component bgp-peer-registry that is injected into the speaker (The
-registry is configured in 31-bgp.xml).
+registry is configured in `31-bgp.xml`).
-To add BGP Peer configuration into the registry, it is necessary to configure
-regular BGP peer just like in example in 41-bgp-example.xml. Notice that the
+To add a BGP Peer configuration into the registry, it is necessary to configure
+regular BGP peer just like in example in `41-bgp-example.xml`. Notice that the
BGP peer depends on the same bgp-peer-registry as bgp-speaker:
[source,xml]
the connection to 192.0.2.1 is initiated by OpenDaylight but will also be accepted from
192.0.2.1. In case both connections are being established, only one of them
will be preserved and the other will be dropped. The connection initiated from
-device with lower bgp id will be dropped by the registry. Each BGP peer must
-be configured in its own module. Note, that the name of the module needs to be
-unique, so if you are configuring more peers, when changing the *host*, change
-also the *name*.
-There is a way to configure the peer only for incoming connections (The
-connection will not be initiated by the OpenDaylight, OpenDaylight will only wait for incoming
-connection from the peer. The peer is identified by its IP address). To
-configure peer only for incoming connection add attribute initiate-connection
-to peer's configuration:
+device with lower BGP id will be dropped by the registry. Each BGP peer must
+be configured in its own `module` block. Note, that the name of the module needs to be
+unique, so if you are configuring more peers, when changing the *host*, also change
+the *name*.
+
+To configure a peer that only listens for incoming connections and instruct
+OpenDaylight not to initiate the connection, add the initiate-connection attribute
+to peer's configuration and set it to false:
[source,xml]
----
</module>
----
-- *initiate-connection* - if set to false OpenDaylight will not initiate connection to this peer. Default value is true for all peers.
+- *initiate-connection* - if set to false OpenDaylight will not initiate connection to this peer. Default value is true.
==== BGP Application Peer ====
a BGP peer is not configured, the connection with OpenDaylight won't be
successful). As a first step, configure RIB. Then, instead of configuring
regular peer, configure this application peer, with its own application RIB.
-Change the value in bold bgp-peer-id which is your local BGP-ID that will be
-used in BGP Best Path Selection algorithm.
+Change the bgp-peer-id, which is your local BGP ID that will be
+used in BGP best path selection algorithm.
[source,xml]
----
</module>
----
-- *bgp-peer-id* - Our local BGP identifier (the IP of the VM where OpenDaylight is deployed), we use this in best path selection
+- *bgp-peer-id* - the local BGP identifier (the IP of the VM where OpenDaylight is deployed), we use this in best path selection
- *target-rib* - RIB ID of existing RIB where the data should be transferred
- *application-rib-id* - RIB ID of local application RIB (all the routes that you put to OpenDaylight will be displayed here)
=== Configuration through RESTCONF ===
-Another method to configure BGP is dynamically through RESTCONF. Before you
-start, make sure, you've completed steps 1-5 in Installation Guide. Instead of
+Another method to configure BGP is dynamically through RESTCONF. Instead of
restarting Karaf, install another feature, that provides you the access to
'restconf/config/' URLs.
-feature:install odl-netconf-connector-all
+ feature:install odl-netconf-connector-all
To check what modules you have currently configured, check following link:
http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/
+
This URL is also used to POST new configuration. If you want to change any
other configuration that is listed here, make sure you include the correct
namespaces. RESTCONF will tell you if some namespace is wrong.
==== RIB ====
-First, configure RIB. This module is already present in the configuration,
+First, configure the RIB. This module is already present in the configuration,
therefore we change only the parameters we need. In this case, it's
*bgp-rib-id* and *local-as*.
-*URL:* _
+*URL:*
_http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-bgp-rib-impl-cfg:rib-impl/example-bgp-rib_
*PUT:*
</local-table>
<local-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
<type>bgp-table-type</type>
- <name>flowspec</name>
+ <name>ipv4-flowspec</name>
+ </local-table>
+ <local-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
+ <type>bgp-table-type</type>
+ <name>ipv6-flowspec</name>
+ </local-table>
+ <local-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
+ <type>bgp-table-type</type>
+ <name>labeled-unicast</name>
</local-table>
<bgp-rib-id xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">192.0.2.2</bgp-rib-id>
+ <openconfig-provider xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp-openconfig-spi">x:bgp-openconfig-provider</type>
+ <name>openconfig-bgp</name>
+ </openconfig-provider>
</module>
----
-IMPORTANT: MIGHT NOT BE NEEDED depending on your BGP router, you might need a
-switch from linkstate attribute type 99 to 29. Check with your router vendor.
-Switch the field to true if your router supports type 29.
+Depending on your BGP router, you might need to switch from
+linkstate attribute type 99 to 29. Check with your router vendor. Change the
+field iana-linkstate-attribute-type to true if your router supports type 29.
+You can do that with the following RESTCONF operation:
*URL:* _http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-bgp-linkstate-cfg:bgp-linkstate/bgp-linkstate_
==== BGP Peer ====
-We also need to add new module to configuration (bgp-peer). In this case, the
+We also need to add a new module to configuration (bgp-peer). In this case, the
whole module needs to be configured. Please change values *host*, *holdtimer*
and *peer-role* (if necessary).
-.*POST:*
+*URL:* _http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules_
+
+*POST:*
[source,xml]
----
</advertized-table>
<advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type>
- <name>flowspec</name>
+ <name>ipv4-flowspec</name>
+ </advertized-table>
+ <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type>
+ <name>ipv6-flowspec</name>
+ </advertized-table>
+ <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type>
+ <name>labeled-unicast</name>
</advertized-table>
</module>
----
Change the value *bgp-peer-id* which is your local BGP ID that will be used in
BGP Best Path Selection algorithm.
-.*POST:*
+*URL:* _http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules_
+
+*POST:*
[source,xml]
----
<module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
This section summarizes how data from BGP can be viewed through RESTCONF. Currently it is the only way to view the data.
-IMPORTANT: From Helium release the port changed from 8080 to 8181.
-
===== Network Topology View =====
-Basic URL for network topology is *http://localhost:8181/restconf/operational/network-topology:network-topology/* .
+The URL for network topology is: http://localhost:8181/restconf/operational/network-topology:network-topology/
-If BGP is configured properly, it should display output similar to this one:
+If BGP is configured properly, it should display output similar to:
[source,xml]
----
</network-topology>
----
-BGP data as were sent from BGP speaker are listed in three topologies (if all three are configured):
+BGP topology information as learned from BGP peers are is in three topologies (if all three are configured):
-*example-linkstate-topology* - displays links and nodes advertised through linkstate Update messages
+* *example-linkstate-topology* - displays links and nodes advertised through linkstate update messages
-http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-linkstate-topology
+** http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-linkstate-topology
-*example-ipv4-topology* - display Ipv4 adresses of nodes in the topology
+* *example-ipv4-topology* - display IPv4 addresses of nodes in the topology
-http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-ipv4-topology
+** http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-ipv4-topology
-*example-ipv6-topology* - display Ipv6 adresses of nodes in the topology
+* *example-ipv6-topology* - display IPv6 addresses of nodes in the topology
-http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-ipv6-topology
+** http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-ipv6-topology
===== Route Information Base (RIB) View =====
-Another view of BGP data is through *BGP RIBs*, located here:
-
-http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/
+Another view of BGP data is through *BGP RIBs*, located here: http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/
There are multiple RIBs configured:
- LocRib (per RIB) : Local RIB, BGP routes from all peers
- AdjRibsOut (per Peer) : BGP routes that will be advertizes, after applying Export policies
-This is how the output looks like, when address families for IPv4 and Linkstate were configured:
+This is how the empty output looks like, when address families for IPv4 Unicast, IPv6 Unicast, IPv4 Flowspec, IPv6 Flowspec, IPv4 Labeled Unicast and Linkstate were configured:
[source,xml]
----
-<loc-rib>
- <tables>
- </attributes>
- <safi>x:linkstate-subsequent-address-family</safi>
- <afi>x:linkstate-address-family</afi>
- </linkstate-routes>
- </tables>
- <tables>
- </attributes>
- <safi>x:unicast-subsequent-address-family</safi>
- <afi>x:ipv4-address-family</afi>
- </ipv4-routes>
- </tables>
+<loc-rib xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv6-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ <ipv6-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ </ipv6-routes>
+ </tables>
+ <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>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ </ipv4-routes>
+ </tables>
+ <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-flowspec">x:flowspec-subsequent-address-family</safi>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ <flowspec-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ </flowspec-routes>
+ </tables>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv6-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">x:flowspec-subsequent-address-family</safi>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ <flowspec-ipv6-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ </flowspec-ipv6-routes>
+ </tables>
+ <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-labeled-unicast">x:labeled-unicast-subsequent-address-family</safi>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ <labeled-unicast-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
+ </labeled-unicast-routes>
+ </tables>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-linkstate">x:linkstate-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-linkstate">x:linkstate-subsequent-address-family</safi>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ <linkstate-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-linkstate">
+ </linkstate-routes>
+ </tables>
</loc-rib>
----
You can see details for each AFI by expanding the RESTCONF link:
-*IPv4* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes
+* *IPv4 Unicast* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes
+
+* *IPv6 Unicast* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/ipv6-routes
+
+* *IPv4 Labeled Unicast* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes
+
+* *IPv4 Flowspec* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes
+
+* *IPv6 Flowspec* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes
-*Linkstate* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-linkstate:linkstate-address-family/bgp-linkstate:linkstate-subsequent-address-family/linkstate-routes
+* *Linkstate* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-linkstate:linkstate-address-family/bgp-linkstate:linkstate-subsequent-address-family/linkstate-routes
==== Populate RIB ====
-If your peer is configured, you can populate the RIB by making following POST call to RESTCONF:
+If an application peer is configured, you can populate its RIB by making POST calls to RESTCONF like the following.
-*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/
+===== IPv4 Unicast =====
+
+*Add route:*
+
+*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/
- where example-app-rib is your application RIB id (that you specified in the configuration) and tables specifies AFI and SAFI of the data that you want to add.
-*POST:*
+*Method:* POST
*Content-Type:* application/xml
[source,xml]
----
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv4-route>
- <prefix>200.20.160.1/32</prefix>
+ <?xml version="1.0" encoding="UTF-8" standalone="no"?>
+ <ipv4-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <prefix>1.1.1.1/32</prefix>
+ <attributes>
+ <ipv4-next-hop>
+ <global>199.20.160.41</global>
+ </ipv4-next-hop><as-path/>
+ <multi-exit-disc>
+ <med>0</med>
+ </multi-exit-disc>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <originator-id>
+ <originator>41.41.41.41</originator>
+ </originator-id>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <cluster-id>
+ <cluster>40.40.40.40</cluster>
+ </cluster-id>
+ </attributes>
+ </ipv4-route>
+----
+
+The request results in *204 No content*. This is expected.
+
+*Delete route:*
+
+*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/bgp-inet:ipv4-route/<route-id>
+
+*Method:* DELETE
+
+===== IPv6 Unicast =====
+
+*Add route:*
+
+*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes/
+
+*Method:* POST
+
+*Content-Type:* application/xml
+
+[source,xml]
+----
+ <ipv6-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <prefix>2001:db8:30::3/128</prefix>
+ <attributes>
+ <ipv6-next-hop>
+ <global>2001:db8:1::6</global>
+ </ipv6-next-hop>
+ <as-path/>
+ <origin>
+ <value>egp</value>
+ </origin>
+ </attributes>
+ </ipv6-route>
+----
+
+The request results in *204 No content*. This is expected.
+
+*Delete route:*
+
+*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes/bgp-inet:ipv6-route/<route-id>
+
+*Method:* DELETE
+
+===== IPv4 Labeled Unicast =====
+
+*Add route:*
+
+*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes
+
+*Method:* POST
+
+*Content-Type:* application/xml
+
+[source,xml]
+----
+ <labeled-unicast-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
+ <route-key>label1</route-key>
+ <prefix>1.1.1.1/32</prefix>
+ <label-stack>
+ <label-value>123</label-value>
+ </label-stack>
+ <label-stack>
+ <label-value>456</label-value>
+ </label-stack>
+ <label-stack>
+ <label-value>342</label-value>
+ </label-stack>
+ <attributes>
+ <ipv4-next-hop>
+ <global>199.20.160.41</global>
+ </ipv4-next-hop>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path/>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ </attributes>
+ </labeled-unicast-route>
+----
+
+The request results in *204 No content*. This is expected.
+
+*Delete route:*
+
+*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes/bgp-labeled-unicast:labeled-unicast-route/<route-id>
+
+*Method:* DELETE
+
+===== IPv4 Flowspec =====
+
+*Add route:*
+
+*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes
+
+*Method:* POST
+
+*Content-Type:* application/xml
+
+[source,xml]
+----
+<flowspec-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ <route-key>flow1</route-key>
+ <flowspec>
+ <destination-prefix>192.168.0.1/32</destination-prefix>
+ </flowspec>
+ <flowspec>
+ <source-prefix>10.0.0.1/32</source-prefix>
+ </flowspec>
+ <flowspec>
+ <protocol-ips>
+ <op>equals end-of-list</op>
+ <value>6</value>
+ </protocol-ips>
+ </flowspec>
+ <flowspec>
+ <ports>
+ <op>equals end-of-list</op>
+ <value>80</value>
+ </ports>
+ </flowspec>
+ <flowspec>
+ <destination-ports>
+ <op>greater-than</op>
+ <value>8080</value>
+ </destination-ports>
+ <destination-ports>
+ <op>and-bit less-than end-of-list</op>
+ <value>8088</value>
+ </destination-ports>
+ </flowspec>
+ <flowspec>
+ <source-ports>
+ <op>greater-than end-of-list</op>
+ <value>1024</value>
+ </source-ports>
+ </flowspec>
+ <flowspec>
+ <types>
+ <op>equals end-of-list</op>
+ <value>0</value>
+ </types>
+ </flowspec>
+ <flowspec>
+ <codes>
+ <op>equals end-of-list</op>
+ <value>0</value>
+ </codes>
+ </flowspec>
+ <flowspec>
+ <tcp-flags>
+ <op>match end-of-list</op>
+ <value>32</value>
+ </tcp-flags>
+ </flowspec>
+ <flowspec>
+ <packet-lengths>
+ <op>greater-than</op>
+ <value>400</value>
+ </packet-lengths>
+ <packet-lengths>
+ <op>and-bit less-than end-of-list</op>
+ <value>500</value>
+ </packet-lengths>
+ </flowspec>
+ <flowspec>
+ <dscps>
+ <op>equals end-of-list</op>
+ <value>20</value>
+ </dscps>
+ </flowspec>
+ <flowspec>
+ <fragments>
+ <op>match end-of-list</op>
+ <value>first</value>
+ </fragments>
+ </flowspec>
+ <attributes>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path/>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <extended-communities>
+ ....
+ </extended-communities>
+ </attributes>
+</flowspec-route>
+----
+
+*Flowspec Extended Communities (Actions):*
+
+[source,xml]
+----
+ <extended-communities>
+ <transitive>true</transitive>
+ <traffic-rate-extended-community>
+ <informative-as>123</informative-as>
+ <local-administrator>AAAAAA==</local-administrator>
+ </traffic-rate-extended-community>
+ </extended-communities>
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <traffic-action-extended-community>
+ <sample>true</sample>
+ <terminal-action>false</terminal-action>
+ </traffic-action-extended-community>
+ </extended-communities>
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-extended-community>
+ <global-administrator>123</global-administrator>
+ <local-administrator>AAAAew==</local-administrator>
+ </redirect-extended-community>
+ </extended-communities>
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-ipv4>
+ <global-administrator>192.168.0.1</global-administrator>
+ <local-administrator>12345</local-administrator>
+ </redirect-ipv4>
+ </extended-communities>
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-as4>
+ <global-administrator>64495</global-administrator>
+ <local-administrator>12345</local-administrator>
+ </redirect-as4>
+ </extended-communities>
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-ip-nh-extended-community>
+ <copy>false</false>
+ </redirect-ip-nh-extended-community>
+ </extended-communities>
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <traffic-marking-extended-community>
+ <global-administrator>20</global-administrator>
+ </traffic-marking-extended-community>
+ </extended-communities>
+----
+
+The request results in *204 No content*. This is expected.
+
+*Delete route:*
+
+*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes/bgp-flowspec:flowspec-route/<route-id>
+
+*Method:* DELETE
+
+===== IPv6 Flowspec =====
+
+*Add route:*
+
+*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes
+
+*Method:* POST
+
+*Content-Type:* application/xml
+
+[source,xml]
+----
+<flowspec-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ <route-key>flow-v6</route-key>
+ <flowspec>
+ <destination-prefix>2001:db8:30::3/128</destination-prefix>
+ </flowspec>
+ <flowspec>
+ <source-prefix>2001:db8:31::3/128</source-prefix>
+ </flowspec>
+ <flowspec>
+ <flow-label>
+ <op>equals end-of-list</op>
+ <value>1</value>
+ </flow-label>
+ </flowspec>
<attributes>
- <ipv4-next-hop>
- <global>199.20.160.41</global>
- </ipv4-next-hop><as-path/>
- <multi-exit-disc>
- <med>0</med>
- </multi-exit-disc>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <originator-id>
- <originator>41.41.41.41</originator>
- </originator-id>
- <origin>
- <value>igp</value>
- </origin>
- <cluster-id>
- <cluster>40.40.40.40</cluster>
- </cluster-id>
+ <extended-communities>
+ <redirect-ipv6>
+ <global-administrator>2001:db8:1::6</global-administrator>
+ <local-administrator>12345</local-administrator>
+ </redirect-ipv6>
+ </extended-communities>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path/>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
</attributes>
- </ipv4-route>
-</ipv4-routes>
+</flowspec-route>
----
The request results in *204 No content*. This is expected.
+
+*Delete route:*
+
+*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes/bgp-flowspec:flowspec-route/<route-id>
+
+*Method:* DELETE
\ No newline at end of file
- *listen-address* - adress on which PCE will be started and listen
- *listen-port* - port on which the address will be started and listen
-PCEP default configuration is set to conform stateful PCEP extension:
+PCEP default configuration is set to conform stateful PCEP extensions:
-link:http://tools.ietf.org/html/draft-ietf-pce-stateful-pce[draft-ietf-pce-stateful-pce] - in versions 02 and 07
+- http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-07[draft-ietf-pce-stateful-pce-07] - PCEP Extensions for Stateful PCE
+- https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00[draft-ietf-pce-pce-initiated-lsp-00] - PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model
+- https://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations-03[draft-ietf-pce-stateful-sync-optimizations-03] - Optimizations of Label Switched Path State
+Synchronization Procedures for a Stateful PCE
==== PCEP Segment Routing ====
-Conforms link:http://tools.ietf.org/html/draft-ietf-pce-segment-routing-01[draft-eitf-pce-segment-routing] - PCEP extension for Segment Routing
+Conforms link:http://tools.ietf.org/html/draft-ietf-pce-segment-routing-01[draft-ietf-pce-segment-routing] - PCEP extension for Segment Routing
The default configuration file is located in etc/opendaylight/karaf.
- *33-pcep-segment-routing.xml* - You don't need to edit this file.
+=== Tunnel Management ===
+
+Programming tunnels through PCEP is one of the key features of PCEP implementation in OpenDaylight.
+User can create, update and delete tunnel via RESTCONF calls.
+Tunnel (LSP - Label Switched Path) arguments are passed through RESTCONF and generate a PCEP message that is sent to PCC (which is also specified via RESTCONF call).
+PCC sends a response back to OpenDaylight. The response is then interpreted and sent to RESTCONF, where, in case of success, the new LSP is displayed.
+
+The PCE Segment Routing Extends draft-ietf-pce-stateful-pce-07 and draft-ietf-pce-pce-initiated-lsp-00, brings new Segment Routing Explicit Route Object (SR-ERO) subobject composed of SID (Segment Identifier)
+and/or NAI (Node or Adjacency Identifier). Segment Routing path is carried in the ERO object, as a list of SR-ERO subobjects ordered by user.
+The draft redefines format of messages (PCUpd, PCRpt, PCInitiate) - along with common header, they can hold SPR, LSP and SR-ERO (containing only SR-ERO subobjects) objects.
+
+==== Creating LSP ====
+An LSP in PCEP can be created in one or two steps. Making an add-lsp operation will trigger a PcInitiate message to PCC.
+
+*URL:* http://localhost:8181/restconf/operations/network-topology-pcep:add-lsp
+
+*Method:* POST
+
+*Content-Type:* application/xml
+
+*Body:*
+
+*PCE Active Stateful:*
+[source,xml]
+----
+<input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
+ <node>pcc://43.43.43.43</node>
+ <name>update-tunel</name>
+ <arguments>
+ <lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
+ <delegate>true</delegate>
+ <administrative>true</administrative>
+ </lsp>
+ <endpoints-obj>
+ <ipv4>
+ <source-ipv4-address>43.43.43.43</source-ipv4-address>
+ <destination-ipv4-address>39.39.39.39</destination-ipv4-address>
+ </ipv4>
+ </endpoints-obj>
+ <ero>
+ <subobject>
+ <loose>false</loose>
+ <ip-prefix><ip-prefix>201.20.160.40/32</ip-prefix></ip-prefix>
+ </subobject>
+ <subobject>
+ <loose>false</loose>
+ <ip-prefix><ip-prefix>195.20.160.39/32</ip-prefix></ip-prefix>
+ </subobject>
+ <subobject>
+ <loose>false</loose>
+ <ip-prefix><ip-prefix>39.39.39.39/32</ip-prefix></ip-prefix>
+ </subobject>
+ </ero>
+ </arguments>
+ <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
+</input>
+----
+
+*PCE Segment Routing:*
+[source,xml]
+----
+<input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
+ <node>pcc://43.43.43.43</node>
+ <name>update-tunnel</name>
+ <arguments>
+ <lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
+ <delegate>true</delegate>
+ <administrative>true</administrative>
+ </lsp>
+ <endpoints-obj>
+ <ipv4>
+ <source-ipv4-address>43.43.43.43</source-ipv4-address>
+ <destination-ipv4-address>39.39.39.39</destination-ipv4-address>
+ </ipv4>
+ </endpoints-obj>
+ <path-setup-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
+ <pst>1</pst>
+ </path-setup-type>
+ <ero>
+ <subobject>
+ <loose>false</loose>
+ <sid-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">ipv4-node-id</sid-type>
+ <m-flag xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">true</m-flag>
+ <sid xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">12</sid>
+ <ip-address xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">39.39.39.39</ip-address>
+ </subobject>
+ </ero>
+ </arguments>
+ <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
+</input>
+----
+
+==== Updating LSP ====
+Making an update-lsp operation will trigger a PCUpd message to PCC. Updating can be used to change or add additional information to the LSP.
+
+You can only successfully update an LSP if you own the delegation. You automatically own the delegation, if you've created the LSP.
+You don't own it, if another PCE created this LSP. In this case PCC is only reporting this LSP for you, as read-only (you'll see +<delegate>false</delegate>+).
+However OpenDaylight won't restrict you from trying to modify the LSP, but you will be stopped by receiving a PCErr message from PCC.
+
+To revoke delegation, don't forget to set +<delegate>+ to true.
+
+*URL:* http://localhost:8181/restconf/operations/network-topology-pcep:update-lsp
+
+*Method:* POST
+
+*Content-Type:* application/xml
+
+*Body:*
+
+*PCE Active Stateful:*
+[source,xml]
+----
+<input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
+ <node>pcc://43.43.43.43</node>
+ <name>update-tunel</name>
+ <arguments>
+ <lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
+ <delegate>true</delegate>
+ <administrative>true</administrative>
+ </lsp>
+ <ero>
+ <subobject>
+ <loose>false</loose>
+ <ip-prefix><ip-prefix>200.20.160.41/32</ip-prefix></ip-prefix>
+ </subobject>
+ <subobject>
+ <loose>false</loose>
+ <ip-prefix><ip-prefix>196.20.160.39/32</ip-prefix></ip-prefix>
+ </subobject>
+ <subobject>
+ <loose>false</loose>
+ <ip-prefix><ip-prefix>39.39.39.39/32</ip-prefix></ip-prefix>
+ </subobject>
+ </ero>
+ </arguments>
+ <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
+</input>
+----
+
+*PCE Segment Routing:*
+[source,xml]
+----
+<input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
+ <node>pcc://43.43.43.43</node>
+ <name>update-tunnel</name>
+ <arguments>
+ <lsp xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
+ <delegate>true</delegate>
+ <administrative>true</administrative>
+ </lsp>
+ <path-setup-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:ietf:stateful">
+ <pst>1</pst>
+ </path-setup-type>
+ <ero>
+ <subobject>
+ <loose>false</loose>
+ <sid-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">ipv4-node-id</sid-type>
+ <m-flag xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">true</m-flag>
+ <sid xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">11</sid>
+ <ip-address xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">200.20.160.41</ip-address>
+ </subobject>
+ <subobject>
+ <loose>false</loose>
+ <sid-type xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">ipv4-node-id</sid-type>
+ <m-flag xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">true</m-flag>
+ <sid xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">12</sid>
+ <ip-address xmlns="urn:opendaylight:params:xml:ns:yang:pcep:segment:routing">39.39.39.39</ip-address>
+ </subobject>
+ </ero>
+ </arguments>
+ <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
+</input>
+----
+
+==== Removing LSP ====
+Removing LSP from PCC is done via following RESTCONF URL. Making a remove-lsp operation will trigger a PCInitiate message to PCC, with remove-flag in SRP set to true.
+
+You can only successfully remove an LSP if you own the delegation. You automatically own the delegation, if you've created the LSP.
+You don't own it, if another PCE created this LSP. In this case PCC is only reporting this LSP for you, as read-only (you'll see +<delegate>false</delegate>+).
+However OpenDaylight won't restrict you from trying to remove the LSP, but you will be stopped by receiving a PCErr message from PCC.
+
+To revoke delegation, don't forget to set +<delegate>+ to true.
+
+*URL:* http://localhost:8181/restconf/operations/network-topology-pcep:remove-lsp
+
+*Method:* POST
+
+*Content-Type:* application/xml
+
+*Body:*
+[source,xml]
+----
+<input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
+ <node>pcc://43.43.43.43</node>
+ <name>update-tunel</name>
+ <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
+</input>
+----
+
+==== PCE-triggered Initial Synchronization ====
+Making an trigger-sync operation will trigger a PCUpd message to PCC with PLSP-ID = 0 and SYNC = 1 in order to trigger the LSP-DB synchronization process.
+
+*URL:* http://localhost:8181/restconf/operations/network-topology-pcep:trigger-sync
+
+*Method:* POST
+
+*Content-Type:* application/xml
+
+*Body:*
+[source,xml]
+----
+<input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
+ <node>pcc://43.43.43.43</node>
+ <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
+</input>
+----
+
+==== PCE-triggered Re-synchronization ====
+Making an trigger-resync operation will trigger a PCUpd message to PCC. The PCE can choose to re-synchronize its entire LSP database or a single LSP.
+
+*URL:* http://localhost:8181/restconf/operations/network-topology-pcep:trigger-sync
+
+*Method:* POST
+
+*Content-Type:* application/xml
+
+*Body:*
+[source,xml]
+----
+<input xmlns="urn:opendaylight:params:xml:ns:yang:topology:pcep">
+ <node>pcc://43.43.43.43</node>
+ <name>re-sync-lsp</name>
+ <network-topology-ref xmlns:topo="urn:TBD:params:xml:ns:yang:network-topology">/topo:network-topology/topo:topology[topo:topology-id="pcep-topology"]</network-topology-ref>
+</input>
+----
+
+==== PCE-triggered LSP database Re-synchronization ====
+
+PCE-triggered LSP database Re-synchronization works same as in PCE-triggered Initial Synchronization.
\ No newline at end of file
include::netide/odl-netide-user-guide.adoc[NetIDE]
+include::neutron/odl-neutron-service-user.adoc[]
+
include::nic/nic-user.adoc[NIC]
include::ocpplugin/ocp-user-guide.adoc[OCP]
--- /dev/null
+=== Clustering in LISP Flow Mapping
+Documentation regarding setting up a 3-node OpenDaylight cluster is described at following https://wiki.opendaylight.org/view/Running_and_testing_an_OpenDaylight_Cluster#Three-node_cluster[odl wiki page].
+
+To turn on clustering in LISP Flow Mapping it is necessary:
+
+* run script *deploy.py* script. This script is in https://git.opendaylight.org/gerrit/integration/test[integration-test] project placed at _tools/clustering/cluster-deployer/deploy.py_. A whole deploy.py command can looks like:
+=======
+{path_to_integration_test_project}/tools/clustering/cluster-deployer/*deploy.py* +
+--*distribution* {path_to_distribution_in_zip_format} +
+--*rootdir* {dir_at_remote_host_where_copy_odl_distribution} +
+--*hosts* {IP1},{IP2},{IP3} +
+--*clean* +
+--*template* lispflowmapping +
+--*rf* 3 +
+--*user* {user_name_of_remote_hosts} +
+--*password* {password_to_remote_hosts}
+=======
+Running this script will cause that specified *distribution* to be deployed to remote *hosts* specified through their IP adresses with using credentials (*user* and *password*). The distribution will be copied to specified *rootdir*. As part of the deployment, a *template* which contains a set of controller files which are different from standard ones. In this case it is specified in +
+_{path_to_integration_test_project}/tools/clustering/cluster-deployer/lispflowmapping_ directory. +
+Lispflowmapping templates are part of integration-test project. There are 5 template files: +
+
+* akka.conf.template
+* jolokia.xml.template
+* module-shards.conf.template
+* modules.conf.template
+* org.apache.karaf.features.cfg.template
+
+After copying the distribution, it is unzipped and started on all of specified *hosts* in cluster aware manner.
+
+==== Remarks
+It is necessary to have:
+
+* *unzip* program installed on all of the host
+* set all remote hosts /etc/sudoers files to not *requiretty* (should only matter on debian hosts)
Additional information is also available on the https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Main[Lisp Flow Mapping wiki]
-
+include::lispflowmapping-clustering-user.adoc[Clustering in lispflowmapping]
--- /dev/null
+== Neutron Service User Guide
+
+=== Overview
+This Karaf feature (`odl-neutron-service`) provides integration support for OpenStack Neutron
+via the OpenDaylight ML2 mechanism driver. The Neutron Service is only one of the
+components necessary for OpenStack integration. For those related components
+please refer to documentations of each component:
+
+* https://wiki.openstack.org/wiki/Neutron
+* https://launchpad.net/networking-odl
+* http://git.openstack.org/cgit/openstack/networking-odl/
+* https://wiki.opendaylight.org/view/NeutronNorthbound:Main
+
+==== Use cases and who will use the feature
+If you want OpenStack integration with OpenDaylight, you will need
+this feature with an OpenDaylight provider feature like ovsdb/netvirt, group based
+policy, VTN, and lisp mapper. For provider configuration, please refer
+to each individual provider's documentation. Since the Neutron service only provides the northbound
+API for the OpenStack Neutron ML2 mechanism driver. Without those provider
+features, the Neutron service itself isn't useful.
+
+=== Neutron Service feature Architecture
+The Neutron service provides northbound API for OpenStack Neutron via
+RESTCONF and also its dedicated REST API.
+It communicates through its YANG model with providers.
+
+image::neutron/odl-neutron-service-architecture.png[height="450px", width="550px", title="Neutron Service Architecture"]
+// image original https://docs.google.com/drawings/d/14CWAo1WQrCMHzNGDeg57P9CiqpkiAE4_njr_0OgAUsw/edit?usp=sharing
+
+
+=== Configuring Neutron Service feature
+As the Karaf feature includes everything necessary for communicating
+northbound, no special configuration is needed.
+Usually this feature is used with an OpenDaylight southbound plugin that implements
+actual network virtualization functionality and OpenStack Neutron.
+The user wants to setup those configurations. Refer to each related
+documentations for each configurations.
+
+=== Administering or Managing `odl-neutron-service`
+There is no specific configuration regarding to Neutron service itself.
+For related configuration, please refer to OpenStack Neutron configuration
+and OpenDaylight related services which are providers for OpenStack.
+
+==== installing `odl-neutron-service` while the controller running
+
+. While OpenDaylight is running, in Karaf prompt, type:
+ `feature:install odl-neutron-service`.
+. Wait a while until the initialization is done and the controller stabilizes.
+
+`odl-neutron-service` provides only a unified interface for OpenStack Neutron.
+It doesn't provide actual functionality for network virtualization.
+Refer to each OpenDaylight project documentation for actual configuration with
+OpenStack Neutron.
+
+=== Neutron Logger
+Another service, the Neutron Logger, is provided for debugging/logging purposes.
+It logs changes on Neutron YANG models.
+
+ feature:install odl-neutron-logger
--- /dev/null
+==== Requirement
+
+* Before execute the follow steps, please, use default requirements. See section <<_default_requirements,Default Requirements>>.
+
+==== How to configure Log Action
+
+This section demonstrates log action in OF Renderer. This demonstration aims at enabling communication between two hosts and logging the flow statistics details of the particular traffic.
+
+===== Configuration
+
+Please execute the following CLI commands to test network intent using mininet:
+
+* To provision the network for the two hosts (h1 and h3), add intents that allows traffic in both directions by execute the following CLI command.
+----
+intent:add –a ALLOW -t <DESTINATION_MAC> -f <SOURCE_MAC>
+----
+
+Example:
+----
+intent:add -a ALLOW -t 00:00:00:00:00:03 -f 00:00:00:00:00:01
+intent:add -a ALLOW -t 00:00:00:00:00:01 -f 00:00:00:00:00:03
+----
+
+* To log the flow statistics details of the particular traffic.
+----
+intent:add –a LOG -t <DESTINATION_MAC> -f <SOURCE_MAC>
+----
+
+Example:
+----
+intent:add -a LOG -t 00:00:00:00:00:03 -f 00:00:00:00:00:01
+----
+
+====== Verification
+
+* As we have applied action type ALLOW now ping should happen between hosts h1 and h3.
+----
+ mininet> h1 ping h3
+ PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
+ 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.984 ms
+ 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.110 ms
+ 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.098 ms
+----
+
+* To view the flow statistics log details such as, byte count, packet count and duration, check the karaf.log.
+----
+2015-12-15 22:56:20,256 | INFO | lt-dispatcher-23 | IntentFlowManager | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Creating block intent for endpoints: source00:00:00:00:00:01 destination 00:00:00:00:00:03
+2015-12-15 22:56:20,252 | INFO | lt-dispatcher-29 | FlowStatisticsListener | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Flow Statistics gathering for Byte Count:Counter64 [_value=238]
+2015-12-15 22:56:20,252 | INFO | lt-dispatcher-29 | FlowStatisticsListener | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Flow Statistics gathering for Packet Count:Counter64 [_value=3]
+2015-12-15 22:56:20,252 | INFO | lt-dispatcher-29 | FlowStatisticsListener | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Flow Statistics gathering for Duration in Nano second:Counter32 [_value=678000000]
+2015-12-15 22:56:20,252 | INFO | lt-dispatcher-29 | FlowStatisticsListener | 264 - org.opendaylight.nic.of-renderer - 1.1.0.SNAPSHOT | Flow Statistics gathering for Duration in Second:Counter32 [_value=49]
+----
--- /dev/null
+==== How to configure QoS Attribute Mapping
+
+This section explains how to provision QoS attribute mapping constraint using NIC OF-Renderer.
+
+The QoS attribute mapping currently supports DiffServ. It uses a 6-bit differentiated services code point (DSCP) in the 8-bit differentiated services field (DS field) in the IP header.
+
+[options="header",cols="20%,80%"]
+|===
+| Action | Function
+|Allow | Permits the packet to be forwarded normally, but allows for packet header fields, e.g., DSCP, to be modified.
+|===
+
+The following steps explain QoS Attribute Mapping function:
+
+* Initially configure the QoS profile which contains profile name and DSCP value.
+* When a packet is transferred from a source to destination, the flow builder evaluates whether the transferred packet matches the condition such as action, endpoints in the flow.
+* If the packet matches the endpoints, the flow builder applies the flow matching action and DSCP value.
+
+===== Requirement
+
+* Before execute the following steps, please, use the default requirements. See section <<_default_requirements,Default Requirements>>.
+
+===== Configuration
+
+Please execute the following CLI commands to test network intent using mininet:
+
+* To apply the QoS constraint, configure the QoS profile.
+----
+intent:qosConfig -p <qos_profile_name> -d <valid_dscp_value>
+----
+
+Example:
+----
+intent:qosConfig -p High_Quality -d 46
+----
+NOTE: Valid DSCP value ranges from 0-63.
+
+* To provision the network for the two hosts (h1 and h3), add intents that allows traffic in both directions by execute the following CLI command.
+
+Demonstrates the ALLOW action with constraint QoS and QoS profile name.
+----
+intent:add -a ALLOW -t <DESTINATION_MAC> -f <SOURCE_MAC> -q QOS -p <qos_profile_name>
+----
+
+Example:
+----
+intent:add -a ALLOW -t 00:00:00:00:00:03 -f 00:00:00:00:00:01 -q QOS -p High_Quality
+intent:add -a ALLOW -t 00:00:00:00:00:01 -f 00:00:00:00:00:03 -q QOS -p High_Quality
+----
+
+====== Verification
+
+* As we have applied action type ALLOW now ping should happen between hosts h1 and h3.
+----
+ mininet> h1 ping h3
+ PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
+ 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=0.984 ms
+ 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.110 ms
+ 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.098 ms
+----
+
+* Verification of the flow entry and ensuring the mod_nw_tos is part of actions.
+----
+ mininet> dpctl dump-flows
+ *** s1 ------------------------------------------------------------------------
+ NXST_FLOW reply (xid=0x4):
+ cookie=0x0, duration=21.873s, table=0, n_packets=3, n_bytes=294, idle_age=21, priority=9000,dl_src=00:00:00:00:00:03,dl_dst=00:00:00:00:00:01 actions=NORMAL,mod_nw_tos:184
+ cookie=0x0, duration=41.252s, table=0, n_packets=3, n_bytes=294, idle_age=41, priority=9000,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:03 actions=NORMAL,mod_nw_tos:184
+----
--- /dev/null
+==== How to configure Redirect Action
+
+The section explains the redirect action supported in NIC. The redirect functionality supports forwarding (to redirect) the traffic to a service configured in SFC before forwarding it to the destination.
+
+.REDIRECT SERVICE
+image::nic/Service_Chaining.png[REDIRECT SERVICE,width=400]
+
+Following steps explain Redirect action function:
+
+* Configure the service in SFC using the SFC APIs.
+* Configure the intent with redirect action and the service information where the traffic needs to be redirected.
+* The flows are computed as below
+. First flow entry between the source host connected node and the ingress node of the configured service.
+. Second flow entry between the egress Node id the configured service and the ID and destination host connected host.
+. Third flow entry between the destination host node and the source host node.
+
+
+===== Requirement
+* Save the mininet <<_simple_mininet_topology,Simple Mininet topology>> script as redirect_test.py
+
+* Start mininet, and create switches in it.
+
+Replace <Controller IP> based on your environment.
+
+----
+sudo mn --controller=remote,ip=<Controller IP>--custom redirect_test.py --topo mytopo2
+----
+
+----
+ mininet> net
+ h1 h1-eth0:s1-eth1
+ h2 h2-eth0:s1-eth2
+ h3 h3-eth0:s2-eth1
+ h4 h4-eth0:s2-eth2
+ h5 h5-eth0:s2-eth3
+ srvc1 srvc1-eth0:s3-eth3 srvc1-eth1:s4-eth3
+ s1 lo: s1-eth1:h1-eth0 s1-eth2:h2-eth0 s1-eth3:s2-eth4 s1-eth4:s3-eth2
+ s2 lo: s2-eth1:h3-eth0 s2-eth2:h4-eth0 s2-eth3:h5-eth0 s2-eth4:s1-eth3 s2-eth5:s4-eth1
+ s3 lo: s3-eth1:s4-eth2 s3-eth2:s1-eth4 s3-eth3:srvc1-eth0
+ s4 lo: s4-eth1:s2-eth5 s4-eth2:s3-eth1 s4-eth3:srvc1-eth1
+ c0
+----
+
+===== Starting the Karaf
+
+* Before execute the following steps, please, use the default requirements. See section <<_default_requirements,Downloading and deploy Karaf distribution>>.
+
+===== Configuration
+
+====== Mininet
+
+.CONFIGURATION THE NETWORK IN MININET
+image::nic/Redirect_flow.png[CONFIGURATION OF THE NETWORK]
+
+* Configure srvc1 as service node in the mininet environment.
+
+Please execute the following commands in the mininet console (where mininet script is executed).
+----
+ srvc1 ip addr del 10.0.0.6/8 dev srvc1-eth0
+ srvc1 brctl addbr br0
+ srvc1 brctl addif br0 srvc1-eth0
+ srvc1 brctl addif br0 srvc1-eth1
+ srvc1 ifconfig br0 up
+ srvc1 tc qdisc add dev srvc1-eth1 root netem delay 200ms
+----
+
+====== Configure service in SFC
+The service (srvc1) is configured using SFC REST API. As part of the configuration the ingress and egress node connected the service is configured.
+
+----
+curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{
+ "service-functions": {
+ "service-function": [
+ {
+ "name": "srvc1",
+ "sf-data-plane-locator": [
+ {
+ "name": "Egress",
+ "service-function-forwarder": "openflow:4"
+ },
+ {
+ "name": "Ingress",
+ "service-function-forwarder": "openflow:3"
+ }
+ ],
+ "nsh-aware": false,
+ "type": "delay"
+ }
+ ]
+ }
+}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function:service-functions/
+----
+
+*SFF RESTCONF Request*
+
+Configuring switch and port information for the service functions.
+----
+curl -i -H "Content-Type: application/json" -H "Cache-Control: no-cache" --data '{
+ "service-function-forwarders": {
+ "service-function-forwarder": [
+ {
+ "name": "openflow:3",
+ "service-node": "OVSDB2",
+ "sff-data-plane-locator": [
+ {
+ "name": "Ingress",
+ "data-plane-locator":
+ {
+ "vlan-id": 100,
+ "mac": "11:11:11:11:11:11",
+ "transport": "service-locator:mac"
+ },
+ "service-function-forwarder-ofs:ofs-port":
+ {
+ "port-id" : "3"
+ }
+ }
+ ],
+ "service-function-dictionary": [
+ {
+ "name": "srvc1",
+ "sff-sf-data-plane-locator":
+ {
+ "sf-dpl-name" : "openflow:3",
+ "sff-dpl-name" : "Ingress"
+ }
+ }
+ ]
+ },
+ {
+ "name": "openflow:4",
+ "service-node": "OVSDB3",
+ "sff-data-plane-locator": [
+ {
+ "name": "Egress",
+ "data-plane-locator":
+ {
+ "vlan-id": 200,
+ "mac": "44:44:44:44:44:44",
+ "transport": "service-locator:mac"
+ },
+ "service-function-forwarder-ofs:ofs-port":
+ {
+ "port-id" : "3"
+ }
+ }
+ ],
+ "service-function-dictionary": [
+ {
+ "name": "srvc1",
+ "sff-sf-data-plane-locator":
+ {
+ "sf-dpl-name" : "openflow:4",
+ "sff-dpl-name" : "Egress"
+ }
+ }
+ ]
+ }
+ ]
+ }
+}' -X PUT --user admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/
+----
+
+====== CLI Command
+To provision the network for the two hosts (h1 and h5).
+
+Demonstrates the redirect action with service name srvc1.
+
+----
+intent:add -f <SOURCE_MAC> -t <DESTINATION_MAC> -a REDIRECT -s <SERVICE_NAME>
+----
+
+Example:
+----
+intent:add -f 32:bc:ec:65:a7:d1 -t c2:80:1f:77:41:ed -a REDIRECT -s srvc1
+----
+
+====== Verification
+
+* As we have applied action type redirect now ping should happen between hosts h1 and h5.
+----
+ mininet> h1 ping h5
+ PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
+ 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=201 ms
+ 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=200 ms
+ 64 bytes from 10.0.0.5: icmp_seq=4 ttl=64 time=200 ms
+----
+The redirect functionality can be verified by the time taken by the ping operation (200ms). The service srvc1 configured using SFC introduces 200ms delay. As the traffic from h1 to h5 is redirected via the srvc1, the time taken by the traffic from h1 to h5 will take about 200ms.
+
+* Flow entries added to nodes for the redirect action.
+----
+ mininet> dpctl dump-flows
+ *** s1 ------------------------------------------------------------------------
+ NXST_FLOW reply (xid=0x4):
+ cookie=0x0, duration=9.406s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=1,dl_src=32:bc:ec:65:a7:d1, dl_dst=c2:80:1f:77:41:ed actions=output:4
+ cookie=0x0, duration=9.475s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=3,dl_src=c2:80:1f:77:41:ed, dl_dst=32:bc:ec:65:a7:d1 actions=output:1
+ cookie=0x1, duration=362.315s, table=0, n_packets=144, n_bytes=12240, idle_age=4, priority=9500,dl_type=0x88cc actions=CONTROLLER:65535
+ cookie=0x1, duration=362.324s, table=0, n_packets=4, n_bytes=168, idle_age=3, priority=10000,arp actions=CONTROLLER:65535,NORMAL
+ *** s2 ------------------------------------------------------------------------
+ NXST_FLOW reply (xid=0x4):
+ cookie=0x0, duration=9.503s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=3,dl_src=c2:80:1f:77:41:ed, dl_dst=32:bc:ec:65:a7:d1 actions=output:4
+ cookie=0x0, duration=9.437s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=5,dl_src=32:bc:ec:65:a7:d1, dl_dst=c2:80:1f:77:41:ed actions=output:3
+ cookie=0x3, duration=362.317s, table=0, n_packets=144, n_bytes=12240, idle_age=4, priority=9500,dl_type=0x88cc actions=CONTROLLER:65535
+ cookie=0x3, duration=362.32s, table=0, n_packets=4, n_bytes=168, idle_age=3, priority=10000,arp actions=CONTROLLER:65535,NORMAL
+ *** s3 ------------------------------------------------------------------------
+ NXST_FLOW reply (xid=0x4):
+ cookie=0x0, duration=9.41s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=2,dl_src=32:bc:ec:65:a7:d1, dl_dst=c2:80:1f:77:41:ed actions=output:3
+ *** s4 ------------------------------------------------------------------------
+ NXST_FLOW reply (xid=0x4):
+ cookie=0x0, duration=9.486s, table=0, n_packets=6, n_bytes=588, idle_age=3, priority=9000,in_port=3,dl_src=32:bc:ec:65:a7:d1, dl_dst=c2:80:1f:77:41:ed actions=output:1
+----
==== How to configure VTN Renderer
-The NIC Model provides an abstract model for expressing the desired state and operation of the network.
+The section demonstrates allow or block packets of the traffic within a VTN Renderer, according to the specified flow conditions.
-===== Requirement
-
-* Configure mininet and create a topology:
-
-Replace <Controller IP> based on your environment
-
-----
-$ mininet@mininet-vm:~$ sudo mn --controller=remote,ip=<Controller IP> --topo tree,2
-----
-
-----
- 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
- c0
-----
-
-===== Downloading and deploy Karaf distribution
-* Get the Lithium Distribution.
+The table below lists the actions to be applied when a packet matches the condition:
+[options="header",cols="20%,80%"]
+|===
+| Action | Function
+|Allow | Permits the packet to be forwarded normally.
+|Block | Discards the packet preventing it from being forwarded.
+|===
-* Unzip the downloaded zip distribution
-
-* To run the Karaf
-
-----
-./bin/karaf
-----
-
-* Once the console is up, type as below to install feature.
+===== Requirement
-----
-feature:install odl-nic-renderer-vtn
-----
+* Before execute the follow steps, please, use default requirements. See section <<_default_requirements,Default Requirements>>.
===== Configuration
Please execute the following curl commands to test network intent using mininet:
-* Create Intent
+====== Create Intent
+To provision the network for the two hosts(h1 and h2) and demonstrates the action allow.
----
curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436034 -d '{ "intent:intent" : { "intent:id": "b9a13232-525e-4d8c-be21-cd65e3436034", "intent:actions" : [ { "order" : 2, "allow" : {} } ], "intent:subjects" : [ { "order":1 , "end-point-group" : {"name":"10.0.0.1"} }, { "order":2 , "end-point-group" : {"name":"10.0.0.2"}} ] } }'
----
+To provision the network for the two hosts(h2 and h3) and demonstrates the action allow.
----
curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436035 -d '{ "intent:intent" : { "intent:id": "b9a13232-525e-4d8c-be21-cd65e3436035", "intent:actions" : [ { "order" : 2, "allow" : {} } ], "intent:subjects" : [ { "order":1 , "end-point-group" : {"name":"10.0.0.2"} }, { "order":2 , "end-point-group" : {"name":"10.0.0.3"}} ] } }'
----
-.Verification
+====== Verification
+As we have applied action type allow now ping should happen between hosts (h1 and h2) and (h2 and h3).
----
mininet> pingall
Ping: testing ping reachability
h4 -> X X X
----
-* Update an Intent
+====== Update the intent
+To provision block action that indicates traffic is not allowed between h1 and h2.
----
curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436034 -d '{ "intent:intent" : { "intent:id": "b9a13232-525e-4d8c-be21-cd65e3436034", "intent:actions" : [ { "order" : 2, "block" : {} } ], "intent:subjects" : [ { "order":1 , "end-point-group" : {"name":"10.0.0.1"} }, { "order":2 , "end-point-group" : {"name":"10.0.0.2"}} ] } }'
----
-.Verification
+====== Verification
+As we have applied action type block now ping should not happen between hosts (h1 and h2).
----
mininet> pingall
Ping: testing ping reachability
NOTE: Old actions and hosts are replaced by the new action and hosts.
-* Delete an Intent
+====== Delete the intent
+Respective intent and the traffics will be deleted.
----
curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X DELETE http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436035
----
-.Verification
+====== Verification
+
+Deletion of intent and flow.
----
mininet> pingall
Ping: testing ping reachability
NOTE: Ping between two hosts can also be done using MAC Address
+To provision the network for the two hosts(h1 MAC address and h2 MAC address).
----
curl -v --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X PUT http://localhost:8181/restconf/config/intent:intents/intent/b9a13232-525e-4d8c-be21-cd65e3436035 -d '{ "intent:intent" : { "intent:id": "b9a13232-525e-4d8c-be21-cd65e3436035", "intent:actions" : [ { "order" : 2, "allow" : {} } ], "intent:subjects" : [ { "order":1 , "end-point-group" : {"name":"6e:4f:f7:27:15:c9"} }, { "order":2 , "end-point-group" : {"name":"aa:7d:1f:4a:70:81"}} ] } }'
----
--- /dev/null
+=== Simple Mininet topology
+
+[source,python]
+----
+!/usr/bin/python
+
+from mininet.topo import Topo
+
+class SimpleTopology( Topo ):
+ "Simple topology example."
+
+ def __init__( self ):
+ "Create custom topo."
+
+ # <1>
+ Topo.__init__( self )
+
+ # <2>
+ Switch1 = self.addSwitch( 's1' )
+ Switch2 = self.addSwitch( 's2' )
+ Switch3 = self.addSwitch( 's3' )
+ Switch4 = self.addSwitch( 's4' )
+ Host11 = self.addHost( 'h1' )
+ Host12 = self.addHost( 'h2' )
+ Host21 = self.addHost( 'h3' )
+ Host22 = self.addHost( 'h4' )
+ Host23 = self.addHost( 'h5' )
+ Service1 = self.addHost( 'srvc1' ) # <3>
+
+ # <4>
+ self.addLink( Host11, Switch1 )
+ self.addLink( Host12, Switch1 )
+ self.addLink( Host21, Switch2 )
+ self.addLink( Host22, Switch2 )
+ self.addLink( Host23, Switch2 )
+ self.addLink( Switch1, Switch2 )
+ self.addLink( Switch2, Switch4 )
+ self.addLink( Switch4, Switch3 )
+ self.addLink( Switch3, Switch1 )
+ self.addLink( Switch3, Service1 )
+ self.addLink( Switch4, Service1 )
+
+
+topos = { 'simpletopology': ( lambda: SimpleTopology() ) }
+----
+<1> Initialize topology
+<2> Add hosts and switches
+<3> Host used to represent the service
+<4> Add links
+
+[quote]
+Source: https://gist.github.com/vinothgithub15/315d0a427d5afc39f2d7
--- /dev/null
+==== Default Requirements
+
+Start mininet, and create three switches (s1, s2, and s3) and four hosts (h1, h2, h3, and h4) in it.
+
+Replace <Controller IP> based on your environment.
+
+----
+$ sudo mn --mac --topo single,2 --controller=remote,ip=<Controller IP>
+----
+
+----
+ mininet> net
+ h1 h1-eth0:s2-eth1
+ h2 h2-eth0:s2-eth2
+ h3 h3-eth0:s3-eth1
+ h4 h4-eth0:s3-eth2
+ s1 lo: s1-eth1:s2-eth3 s1-eth2:s3-eth3
+ s2 lo: s2-eth1:h1-eth0 s2-eth2:h2-eth0 s2-eth3:s1-eth1
+ s3 lo: s3-eth1:h3-eth0 s3-eth2:h4-eth0 s3-eth3:s1-eth2
+----
+
+==== Downloading and deploy Karaf distribution
+* Get the Beryllium distribution.
+
+* Unzip the downloaded zip distribution.
+
+* To run the Karaf.
+----
+./bin/karaf
+----
+
+* Once the console is up, type as below to install feature.
+----
+feature:install odl-nic-core-mdsal odl-nic-console odl-nic-listeners
+----
=== NIC Usage Examples
-In addition to the one example here, please see the wiki for more use cases:
-https://wiki.opendaylight.org/view/Network_Intent_Composition:Use_Cases
+include::NIC_requirements.adoc[]
+
+include::NIC_redirect_test_topology.adoc[]
include::NIC_How_To_configure_VTN_Renderer.adoc[How to configure VTN Renderer]
+
+include::NIC_How_To_configure_Redirect_Action.adoc[How to configure Redirect Action]
+
+include::NIC_How_To_configure_QoS_Attribute_Mapping.adoc[How to configure QoS Attribute Mapping]
+
+include::NIC_How_To_configure_Log_Action.adoc[How to configure Log Action]
-sphinx>=1.4.4
+sphinx==1.4.4
sphinx_bootstrap_theme>=0.4.11
robotframework
+-rdocs/submodules/spectrometer/server/requirements.txt
Code Review / docs.git / commitdiff
