4360 <http://tools.ietf.org/html/rfc4360>`__.
All the concepts are described in one yang model:
-`bgp-types.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/yang/bgp-types.yang;hb=refs/heads/stable/beryllium>`__.
+`bgp-types.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/yang/bgp-types.yang;hb=refs/heads/stable/boron>`__.
Outside generated classes, there is just one class
-`NextHopUtil <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/java/org/opendaylight/bgp/concepts/NextHopUtil.java;hb=refs/heads/stable/beryllium>`__
+`NextHopUtil <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/java/org/opendaylight/bgp/concepts/NextHopUtil.java;hb=refs/heads/stable/boron>`__
that contains methods for serializing and parsing NextHop.
BGP parser
*IMPL* module contains actual parsers and serializers for BGP messages
and
-`Activator <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-impl/src/main/java/org/opendaylight/protocol/bgp/parser/impl/BGPActivator.java;hb=refs/heads/stable/beryllium>`__
+`Activator <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-impl/src/main/java/org/opendaylight/protocol/bgp/parser/impl/BGPActivator.java;hb=refs/heads/stable/boron>`__
class
*SPI* module contains helper classes needed for registering parsers into
The configuration of bgp-parser-spi specifies one implementation of
*Extension provider* that will take care of registering mentioned parser
extensions:
-`SimpleBGPExtensionProviderContext <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi/pojo/SimpleBGPExtensionProviderContext.java;hb=refs/heads/stable/beryllium>`__.
+`SimpleBGPExtensionProviderContext <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi/pojo/SimpleBGPExtensionProviderContext.java;hb=refs/heads/stable/boron>`__.
All registries are implemented in package
-`bgp-parser-spi <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi;hb=refs/heads/stable/beryllium>`__.
+`bgp-parser-spi <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi;hb=refs/heads/stable/boron>`__.
Serializing
^^^^^^^^^^^
specific AFI/SAFI table is set to *true*. Without graceful restart, the
messages are generated by OpenDaylight itself and sent after second
keepalive for each AFI/SAFI. This is done in
-`BGPSynchronization <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPSynchronization.java;hb=refs/heads/stable/beryllium>`__.
+`BGPSynchronization <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPSynchronization.java;hb=refs/heads/stable/boron>`__.
**Peers**
-`BGPPeer <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPPeer.java;hb=refs/heads/stable/beryllium>`__
+`BGPPeer <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPPeer.java;hb=refs/heads/stable/boron>`__
has various meanings. If you configure BGP listener, *BGPPeer*
represents the BGP listener itself. If you are configuring BGP speaker,
you need to provide a list of peers, that are allowed to connect to this
speaker. Unknown peer represents, in this case, a peer that is allowed
to be refused. *BGPPeer* represents in this case peer, that is supposed
to connect to your speaker. *BGPPeer* is stored in
-`BGPPeerRegistry <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/StrictBGPPeerRegistry.java;hb=refs/heads/stable/beryllium>`__.
+`BGPPeerRegistry <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/StrictBGPPeerRegistry.java;hb=refs/heads/stable/boron>`__.
This registry controls the number of sessions. Our strict implementation
limits sessions to one per peer.
-`ApplicationPeer <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/ApplicationPeer.java;hb=refs/heads/stable/beryllium>`__
+`ApplicationPeer <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/ApplicationPeer.java;hb=refs/heads/stable/boron>`__
is a special case of peer, that has it’s own RIB. This RIB is populated
from RESTCONF. The RIB is synchronized with default BGP RIB. Incoming
routes to the default RIB are treated in the same way as they were from
*Ipv4Routes*, *Ipv6Routes*, *LinkstateRoutes* and *FlowspecRoutes*.
Each route type needs to provide a
-`RIBSupport.java <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-spi/src/main/java/org/opendaylight/protocol/bgp/rib/spi/RIBSupport.java;hb=refs/heads/stable/beryllium>`__
+`RIBSupport.java <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-spi/src/main/java/org/opendaylight/protocol/bgp/rib/spi/RIBSupport.java;hb=refs/heads/stable/boron>`__
implementation. *RIBSupport* tells RIB how to parse binding-aware data
(BGP Update message) to binding-independent (datastore format).
RIB
-**`AdjRibInWriter <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibInWriter.java;hb=refs/heads/stable/beryllium>`__**
+**`AdjRibInWriter <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibInWriter.java;hb=refs/heads/stable/boron>`__**
- represents the first step in putting data to datastore. This writer is
notified whenever a peer receives an Update message. The message is
transformed into binding-independent format and pushed into datastore to
*adj-rib-in*. This RIB is associated with a peer.
-**`EffectiveRibInWriter <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/EffectiveRibInWriter.java;hb=refs/heads/stable/beryllium>`__**
+**`EffectiveRibInWriter <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/EffectiveRibInWriter.java;hb=refs/heads/stable/boron>`__**
- this writer is notified whenever *adj-rib-in* is updated. It applies
all configured import policies to the routes and stores them in
*effective-rib-in*. This RIB is also associated with a peer.
-**`LocRibWriter <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/LocRibWriter.java;hb=refs/heads/stable/beryllium>`__**
+**`LocRibWriter <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/LocRibWriter.java;hb=refs/heads/stable/boron>`__**
- this writer is notified whenever **any** *effective-rib-in* is updated
(in any peer). Performs best path selection filtering and stores the
routes in *loc-rib*. It also determines which routes need to be
advertised and fills in *adj-rib-out* that is per peer as well.
-**`AdjRibOutListener <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibOutListener.java;h=a14fd54a29ea613b381a36248f67491d968963b8;hb=refs/heads/stable/beryllium>`__**
+**`AdjRibOutListener <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibOutListener.java;h=a14fd54a29ea613b381a36248f67491d968963b8;hb=refs/heads/stable/boron>`__**
- listens for changes in *adj-rib-out*, transforms the routes into
BGPUpdate messages and sends them to its associated peer.
--------
This module contains only one YANG model
-`bgp-inet.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/inet/src/main/yang/bgp-inet.yang;hb=refs/heads/stable/beryllium>`__
+`bgp-inet.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/inet/src/main/yang/bgp-inet.yang;hb=refs/heads/stable/boron>`__
that summarizes the ipv4 and ipv6 extensions to RIB routes and BGP
messages.
for IPv6 AFI. The RFC defines an extension to BGP in form of a new
subsequent address family, NLRI and extended communities. All of those
are defined in the
-`bgp-flowspec.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/flowspec/src/main/yang/bgp-flowspec.yang;hb=refs/heads/stable/beryllium>`__
+`bgp-flowspec.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/flowspec/src/main/yang/bgp-flowspec.yang;hb=refs/heads/stable/boron>`__
model. In addition to generated sources, the module contains parsers for
newly defined elements and RIBSupport for flowspec-routes. The route key
of flowspec routes is a string representing human-readable flowspec
version 04. The draft defines an extension to BGP in form of a new
address family, subsequent address family, NLRI and path attribute. All
of those are defined in the
-`bgp-linkstate.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/yang/bgp-linkstate.yang;hb=refs/heads/stable/beryllium>`__
+`bgp-linkstate.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/yang/bgp-linkstate.yang;hb=refs/heads/stable/boron>`__
model. In addition to generated sources, the module contains
-`LinkstateAttributeParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/attribute/LinkstateAttributeParser.java;hb=refs/heads/stable/beryllium>`__,
-`LinkstateNlriParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/nlri/LinkstateNlriParser.java;hb=refs/heads/stable/beryllium>`__,
+`LinkstateAttributeParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/attribute/LinkstateAttributeParser.java;hb=refs/heads/stable/boron>`__,
+`LinkstateNlriParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/nlri/LinkstateNlriParser.java;hb=refs/heads/stable/boron>`__,
activators for both, parser and RIB, and RIBSupport handler for
linkstate address family. As each route needs a key, in case of
linkstate, the route key is defined as a binary string, containing all
the NLRI. The AFI indicates, as usual, the address family of the
associated route. The fact that the NLRI contains a label is indicated
by using SAFI value 4. All of those are defined in
-`bgp-labeled-unicast.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob_plain;f=bgp/labeled-unicast/src/main/yang/bgp-labeled-unicast.yang;hb=refs/heads/stable/beryllium>`__
+`bgp-labeled-unicast.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob_plain;f=bgp/labeled-unicast/src/main/yang/bgp-labeled-unicast.yang;hb=refs/heads/stable/boron>`__
model. In addition to the generated sources, the module contains new
NLRI codec and RIBSupport. The route key is defined as a binary, where
whole NLRI information is encoded.
::
- cp -n ~/.m2/settings.xml{,.orig} ; \wget -q -O - https://raw.githubusercontent.com/opendaylight/odlparent/stable/lithium/settings.xml > ~/.m2/settings.xml
+ cp -n ~/.m2/settings.xml{,.orig} ; \wget -q -O - https://raw.githubusercontent.com/opendaylight/odlparent/stable/boron/settings.xml > ~/.m2/settings.xml
.. note::
Flow mod driver API
~~~~~~~~~~~~~~~~~~~
-The Beryllium release includes a flow mod driver for the HP 3800. This
+This release includes a flow mod driver for the HP 3800. This
driver adjusts the flows and push the same to the device. This API takes
the flow to be adjusted as input and displays the adjusted flow as
output in the REST output container. Here is the REST API to adjust and
DLUX modules are the individual features such as nodes and topology.
Each module has a defined structure and you can find all existing
modules at
-https://github.com/opendaylight/dlux/tree/stable/lithium/modules.
+https://github.com/opendaylight/dlux/tree/stable/boron/modules.
Module Structure
~~~~~~~~~~~~~~~~
1. Create a maven project to place blueprint configuration. For
reference, take a look at topology bundle, present at
- https://github.com/opendaylight/dlux/tree/stable/lithium/bundles/topology.
+ https://github.com/opendaylight/dlux/tree/stable/boron/bundles/topology.
All the existing DLUX modules' configurations are available under
bundles directory of DLUX code.
2. In pom.xml, you have to add a maven plugin to unpack your module code
under generated-resources of this project. For reference, you can
check pom.xml of dlux/bundles/topology at
- https://github.com/opendaylight/dlux/tree/stable/lithium/bundles/topology.
+ https://github.com/opendaylight/dlux/tree/stable/boron/bundles/topology.
Your bundle will eventually get deployed in Karaf as feature, so your
bundle should contain all your module code. If you want to combine
module and bundle project, that should not be an issue either.
project. It can be found on the github mirror of OpenDaylight’s
repositories:
-- https://github.com/opendaylight/coretutorials/tree/stable/lithium/ncmount
+- https://github.com/opendaylight/coretutorials/tree/stable/boron/ncmount
or checked out from the official OpenDaylight repository:
be found in the
``onDataChanged(AsyncDataChangeEvent<InstanceIdentifier<?>, DataObject>
change)`` callback of `NcmountProvider
-class <https://github.com/opendaylight/coretutorials/blob/stable/lithium/ncmount/impl/src/main/java/ncmount/impl/NcmountProvider.java>`__.
+class <https://github.com/opendaylight/coretutorials/blob/stable/boron/ncmount/impl/src/main/java/ncmount/impl/NcmountProvider.java>`__.
Reading data from the device
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<version>${NETIDE_VERSION}</version>
</dependency>
-The current stable version for NetIDE is ``0.1.0-Beryllium``.
+The current stable version for NetIDE is ``0.2.0-Boron``.
Protocol specification
~~~~~~~~~~~~~~~~~~~~~~
- odl-nic-console: Provides a karaf CLI extension for intent CRUD
operations and mapping service operations.
-- odl-nic-renderer-of - Generic Openflow Renderer.
+- odl-nic-renderer-of - Generic OpenFlow Renderer.
- odl-nic-renderer-vtn - a feature that transforms an intent to a
network modification using the VTN project
MPLS VPN Service Diagram
where PE (Provider Edge) and P (Provider) switches are managed by
-Opendaylight. In NIC’s terminology the endpoints are the PE switches.
+OpenDaylight. In NIC’s terminology the endpoints are the PE switches.
There could be many P switches between the PEs.
In order for NIC to recognize endpoints as MPLS endpoints, the user is
3. Switch-Port: Ingress (or Egress) for source (or Destination) endpoint
of the source (or Destination) PE
-An intent:add between two MPLS endpoints renders Openflow rules for: 1.
+An intent:add between two MPLS endpoints renders OpenFlow rules for: 1.
push/pop labels to the MPLS endpoint nodes after an IPv4 Prefix match.
2. forward to port rule after MPLS label match to all the switches that
form the shortest path between the endpoints (calculated using Dijkstra
intent:add -f uva -t eur -a ALLOW
intent:add -f eur -t uva -a ALLOW
-5. Verify by running ovs command on mininet if the flows were pushed
+5. Verify by running ovs-ofctl command on mininet if the flows were pushed
correctly to the nodes that form the shortest path.
Example:
- ovsdb.library-karaf — the OVSDB library reference implementation
-- ovsdb.openstack.net-virt-sfc-karaf — openflow service function
+- ovsdb.openstack.net-virt-sfc-karaf — OpenFlow service function
chaining
- ovsdb.hwvtepsouthbound-karaf — the hw\_vtep schema southbound plugin
- Maven 3+
-Building a Karaf feature and deploying it in an Opendaylight Karaf distribution
+Building a Karaf feature and deploying it in an OpenDaylight Karaf distribution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1. From the root ovsdb/ directory, run **mvn clean install**.
bin/karaf
-1. Once karaf has started, and you see the Opendaylight ascii art in the
+1. Once karaf has started, and you see the OpenDaylight ascii art in the
console, the last step is to start the OVSDB plugin framework with
the following command in the karaf console:
Each of the SouthBound Plugins serves a different purpose, with some
overlapping. For example, the OpenFlow plugin might serve the Data-Plane
needs of an OVS element, while the OVSDB plugin can serve the management
-plane needs of the same OVS element. As the Openflow Plugin talks
+plane needs of the same OVS element. As the OpenFlow Plugin talks
OpenFlow protocol with the OVS element, the OVSDB plugin will use OVSDB
schema over JSON-RPC transport.
~~~~~~~~~~~~~~~~~~
| One of the primary services that most southbound plugins provide in
- Opendaylight a Connection Service. The service provides protocol
+ OpenDaylight a Connection Service. The service provides protocol
specific connectivity to network elements, and supports the
connectivity management services as specified by the OpenDaylight
Connection Manager. The connectivity services include:
Using the port security groups of Neutron, one can add rules that
restrict the network access of the tenants. The OVSDB Neutron
integration checks the port security rules configured, and apply them by
-means of openflow rules.
+means of OpenFlow rules.
Through the ML2 interface, Neutron security rules are available in the
port object, following this scope: Neutron Port → Security Group →
The OVSDB Southbound MD-SAL operates using a YANG model which is based
on the abstract topology node model found in the `network topology
-model <https://github.com/opendaylight/yangtools/blob/stable/lithium/model/ietf/ietf-topology/src/main/yang/network-topology%402013-10-21.yang>`__.
+model <https://github.com/opendaylight/yangtools/blob/stable/boron/model/ietf/ietf-topology/src/main/yang/network-topology%402013-10-21.yang>`__.
The augmentations for the OVSDB Southbound MD-SAL are defined in the
-`ovsdb.yang <https://github.com/opendaylight/ovsdb/blob/stable/lithium/southbound/southbound-api/src/main/yang/ovsdb.yang>`__
+`ovsdb.yang <https://github.com/opendaylight/ovsdb/blob/stable/boron/southbound/southbound-api/src/main/yang/ovsdb.yang>`__
file.
There are three augmentations:
(defaults to )
opendaylight-user@root> wrapper:install
- Creating file: /home/user/odl/distribution-karaf-0.3.0-Lithium/bin/karaf-wrapper
- Creating file: /home/user/odl/distribution-karaf-0.3.0-Lithium/bin/karaf-service
- Creating file: /home/user/odl/distribution-karaf-0.3.0-Lithium/etc/karaf-wrapper.conf
- Creating file: /home/user/odl/distribution-karaf-0.3.0-Lithium/lib/libwrapper.so
- Creating file: /home/user/odl/distribution-karaf-0.3.0-Lithium/lib/karaf-wrapper.jar
- Creating file: /home/user/odl/distribution-karaf-0.3.0-Lithium/lib/karaf-wrapper-main.jar
+ Creating file: /home/user/odl/distribution-karaf-0.5.0-Boron/bin/karaf-wrapper
+ Creating file: /home/user/odl/distribution-karaf-0.5.0-Boron/bin/karaf-service
+ Creating file: /home/user/odl/distribution-karaf-0.5.0-Boron/etc/karaf-wrapper.conf
+ Creating file: /home/user/odl/distribution-karaf-0.5.0-Boron/lib/libwrapper.so
+ Creating file: /home/user/odl/distribution-karaf-0.5.0-Boron/lib/karaf-wrapper.jar
+ Creating file: /home/user/odl/distribution-karaf-0.5.0-Boron/lib/karaf-wrapper-main.jar
Setup complete. You may wish to tweak the JVM properties in the wrapper configuration file:
- /home/user/odl/distribution-karaf-0.3.0-Lithium/etc/karaf-wrapper.conf
+ /home/user/odl/distribution-karaf-0.5.0-Boron/etc/karaf-wrapper.conf
before installing and starting the service.
Ubuntu/Debian Linux system detected:
To install the service:
- $ ln -s /home/user/odl/distribution-karaf-0.3.0-Lithium/bin/karaf-service /etc/init.d/
+ $ ln -s /home/user/odl/distribution-karaf-0.5.0-Boron/bin/karaf-service /etc/init.d/
To start the service when the machine is rebooted:
$ update-rc.d karaf-service defaults
Configuration of PCEP parsers specifies one implementation of *Extension
provider* that will take care of registering mentioned parser
extensions:
-`SimplePCEPExtensionProviderContext <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/spi/src/main/java/org/opendaylight/protocol/pcep/spi/pojo/SimplePCEPExtensionProviderContext.java;hb=refs/for/stable/beryllium>`__.
+`SimplePCEPExtensionProviderContext <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/spi/src/main/java/org/opendaylight/protocol/pcep/spi/pojo/SimplePCEPExtensionProviderContext.java;hb=refs/for/stable/boron>`__.
All registries are implemented in package
-`pcep-spi <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=pcep/spi/src/main/java/org/opendaylight/protocol/pcep/spi/pojo;hb=refs/for/stable/beryllium>`__.
+`pcep-spi <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=pcep/spi/src/main/java/org/opendaylight/protocol/pcep/spi/pojo;hb=refs/for/stable/boron>`__.
Parsing
^^^^^^^
The stateful draft declared new elements as well as additional fields or
TLVs (type,length,value) to known objects. All new elements are defined
in yang models, that contain augmentations to elements defined in
-`pcep-types.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/api/src/main/yang/pcep-types.yang;hb=refs/for/stable/beryllium>`__.
+`pcep-types.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/api/src/main/yang/pcep-types.yang;hb=refs/for/stable/boron>`__.
In the case of extending known elements, the *Parser* class merely
extends the base class and overrides necessary methods as shown in
following diagram:
| The yang models of subobject, SR-PCE-CAPABILITY TLV and appropriate
augmentations are defined in
- `odl-pcep-segment-routing.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/yang/odl-pcep-segment-routing.yang;hb=refs/for/stable/beryllium>`__.
+ `odl-pcep-segment-routing.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/yang/odl-pcep-segment-routing.yang;hb=refs/for/stable/boron>`__.
| The pcep-segment-routing module includes parsers/serializers for new
subobject
- (`SrEroSubobjectParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/java/org/opendaylight/protocol/pcep/segment/routing/SrEroSubobjectParser.java;hb=refs/for/stable/beryllium>`__)
+ (`SrEroSubobjectParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/java/org/opendaylight/protocol/pcep/segment/routing/SrEroSubobjectParser.java;hb=refs/for/stable/boron>`__)
and TLV
- (`SrPceCapabilityTlvParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/java/org/opendaylight/protocol/pcep/segment/routing/SrPceCapabilityTlvParser.java;hb=refs/for/stable/beryllium>`__).
+ (`SrPceCapabilityTlvParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/segment-routing/src/main/java/org/opendaylight/protocol/pcep/segment/routing/SrPceCapabilityTlvParser.java;hb=refs/for/stable/boron>`__).
The pcep-segment-routing module implements
`draft-ietf-pce-lsp-setup-type-01 <http://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-01>`__,
For Segment Routing, PST = 1 is defined.
The Path Setup Type TLV is modeled with yang in module
-`pcep-types.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/api/src/main/yang/pcep-types.yang;hb=refs/for/stable/beryllium>`__.
+`pcep-types.yang <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/api/src/main/yang/pcep-types.yang;hb=refs/for/stable/boron>`__.
A parser/serializer is implemented in
-`PathSetupTypeTlvParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/impl/src/main/java/org/opendaylight/protocol/pcep/impl/tlv/PathSetupTypeTlvParser.java;hb=refs/for/stable/beryllium>`__
+`PathSetupTypeTlvParser <https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=pcep/impl/src/main/java/org/opendaylight/protocol/pcep/impl/tlv/PathSetupTypeTlvParser.java;hb=refs/for/stable/boron>`__
and it is overriden in segment-routing module to provide the aditional
PST.
underlay topologies and underlay items from overlay items. The required
information for Link Computation is provided via the Link Computation
model in
-(`topology-link-computation.yang <https://git.opendaylight.org/gerrit/gitweb?p=topoprocessing.git;a=blob;f=topoprocessing-api/src/main/yang/topology-link-computation.yang;hb=refs/heads/stable/beryllium>`__).
+(`topology-link-computation.yang <https://git.opendaylight.org/gerrit/gitweb?p=topoprocessing.git;a=blob;f=topoprocessing-api/src/main/yang/topology-link-computation.yang;hb=refs/heads/stable/boron>`__).
Link Computation Functionality
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* odlparent_
* yangtools_
-.. _mdsal: https://nexus.opendaylight.org/content/sites/site/org.opendaylight.mdsal/beryllium/apidocs/
-.. _odlparent: https://nexus.opendaylight.org/content/sites/site/org.opendaylight.odlparent/beryllium/apidocs/index.html
-.. _yangtools: https://nexus.opendaylight.org/content/sites/site/org.opendaylight.yangtools/beryllium/apidocs/index.html
+.. _mdsal: https://nexus.opendaylight.org/content/sites/site/org.opendaylight.mdsal/boron/apidocs/
+.. _odlparent: https://nexus.opendaylight.org/content/sites/site/org.opendaylight.odlparent/boron/apidocs/index.html
+.. _yangtools: https://nexus.opendaylight.org/content/sites/site/org.opendaylight.yangtools/boron/apidocs/index.html
below are the ones you’re most likely to use when creating your network
environment.
- As a short example of installing a Karaf feature, OpenDaylight Beryllium
+ As a short example of installing a Karaf feature, OpenDaylight
offers Application Layer Traffic Optimization (ALTO). The Karaf feature to
install ALTO is odl-alto-all. On the Karaf console, the command to install it
is:
For Example::
- $ ls distribution-karaf-0.4.0-Beryllium.zip
- distribution-karaf-0.4.0-Beryllium.zip
- $ unzip distribution-karaf-0.4.0-Beryllium.zip
- Archive: distribution-karaf-0.4.0-Beryllium.zip
- creating: distribution-karaf-0.4.0-Beryllium/
- creating: distribution-karaf-0.4.0-Beryllium/configuration/
- creating: distribution-karaf-0.4.0-Beryllium/data/
- creating: distribution-karaf-0.4.0-Beryllium/data/tmp/
- creating: distribution-karaf-0.4.0-Beryllium/deploy/
- creating: distribution-karaf-0.4.0-Beryllium/etc/
- creating: distribution-karaf-0.4.0-Beryllium/externalapps/
+ $ ls distribution-karaf-0.5.x-Boron.zip
+ distribution-karaf-0.5.x-Boron.zip
+ $ unzip distribution-karaf-0.5.x-Boron.zip
+ Archive: distribution-karaf-0.5.x-Boron.zip
+ creating: distribution-karaf-0.5.x-Boron/
+ creating: distribution-karaf-0.5.x-Boron/configuration/
+ creating: distribution-karaf-0.5.x-Boron/data/
+ creating: distribution-karaf-0.5.x-Boron/data/tmp/
+ creating: distribution-karaf-0.5.x-Boron/deploy/
+ creating: distribution-karaf-0.5.x-Boron/etc/
+ creating: distribution-karaf-0.5.x-Boron/externalapps/
...
- inflating: distribution-karaf-0.4.0-Beryllium/bin/start.bat
- inflating: distribution-karaf-0.4.0-Beryllium/bin/status.bat
- inflating: distribution-karaf-0.4.0-Beryllium/bin/stop.bat
- $ cd distribution-karaf-0.4.0-Beryllium
+ inflating: distribution-karaf-0.5.x-Boron/bin/start.bat
+ inflating: distribution-karaf-0.5.x-Boron/bin/status.bat
+ inflating: distribution-karaf-0.5.x-Boron/bin/stop.bat
+ $ cd distribution-karaf-0.5.x-Boron
$ ./bin/karaf
________ ________ .__ .__ .__ __
http://stackoverflow.com/questions/35679852/karaf-exception-is-thrown-while-installing-org-fusesource-leveldbjni
-Beryllium features
-==================
+Karaf OpenDaylight Features
+===========================
-.. list-table:: Beryllium features
+.. list-table:: Karaf OpenDaylight features
:widths: 10 25 10 5
:header-rows: 1
- self+all
-Other Beryllium features
-========================
+Other OpenDaylight features
+===========================
-.. list-table:: Other Beryllium features
+.. list-table:: Other OpenDaylight features
:widths: 10 25 10 5
:header-rows: 1
- all
-Experimental Beryllium Features
-===============================
-The following functionality is labeled as experimental in OpenDaylight
-Beryllium and should be used accordingly. In general, it is not supposed to be
+Experimental OpenDaylight Features
+==================================
+The following functionality is labeled as experimental in this OpenDaylight
+release and should be used accordingly. In general, it is not supposed to be
used in production unless its limitations are well understood by those
deploying it.
-.. list-table:: Other Beryllium features
+.. list-table:: Other features
:widths: 10 25 10 5
:header-rows: 1
#. OpenDaylight concepts and tools
#. Explanations of OpenDaylight Apache Karaf features and other features that
extend network functionality
-#. OpenDaylight Beryllium system requirements and Release Notes
+#. OpenDaylight system requirements and Release Notes
#. OpenDaylight installation instructions
#. Feature tables with installation names and compatibility notes
* Support for persistent data stores
* Federation and SSO with OpenStack Keystone
-The Beryllium release of AAA includes experimental support for having the database of users and credentials stored in the cluster-aware MD-SAL datastore.
+This release of AAA includes experimental support for having the database of users and credentials stored in the cluster-aware MD-SAL datastore.
ALTO
====
is now available.
* Clustering - Full support for clustering and High Availability (HA) is
- available in the OpenDaylight Beryllium release. In particular, the OVSDB
+ available in the this OpenDaylight release. In particular, the OVSDB
southbound plugin supports clustering that any application can use, and the
Openstack network integration with OpenDaylight (through OVSDB Net-Virt) has
full clustering support. While there is no specific limit on cluster size, a
- 3-node cluster has been tested extensively as part of the Beryllium release.
+ 3-node cluster has been tested extensively as part of the release.
* Security Groups - Security Group support is available and implemented using
OpenFlow rules that provide superior functionality and performance over
* Service Function Chaining
* Open vSwitch southbound support for quality of service and Queue configuration
- Load Balancer as service (LBaaS) with Distributed Virtual Router, as offered
- in the Lithium release
+ Load Balancer as service (LBaaS) with Distributed Virtual Router
* Network Virtualization User interface for DLUX
specification. It currently supports OpenFlow versions 1.0 and 1.3.2.
In addition to support for the core OpenFlow specification, OpenDaylight
-Beryllium also includes preliminary support for the Table Type Patterns and
+also includes preliminary support for the Table Type Patterns and
OF-CONFIG specifications.
Path Computation Element Protocol (PCEP)
various types of collectors
* HSQL data store - Replacement of H2 data store to remove third party
component dependency from TSDR
-* Enhancement of existing data stores including HBase to support new features
- introduced in Beryllium
* Cassandra data store - Cassandra implementation of TSDR SPIs
* NetFlow data collector - Collect NetFlow data from network elements
* NetFlowV9 - version 9 Netflow collector
for using Centinel functionality in the OpenDaylight by enabling the
default Centinel feature. Centinel is a distributed reliable framework
for collection, aggregation and analysis of streaming data which is
-added in OpenDaylight Beryllium Release.
+added in this OpenDaylight release.
Overview
--------
receive events from multiple streaming sources
(e.g., Syslog, Thrift, Avro, AMQP, Log4j, HTTP/REST).
-In Beryllium, we develop a "Log Service" and plug-in for log analyzer (e.g., Graylog).
+In this release, we develop a "Log Service" and plug-in for log analyzer (e.g., Graylog).
The Log service process real time events coming from log analyzer.
Additionally, we provide stream collector (Flume- and Sqoop-based) that collects logs
from OpenDaylight and sinks them to persistence service (integrated with TSDR).
Upgrading From a Previous Release
---------------------------------
-Beryllium being the first release supporting Centinel functionality, only fresh installation is possible.
+Only fresh installation is supported.
Uninstalling Centinel
---------------------
feature:install odl-tsdr-hsqldb-all
-This will install hsqldb related dependency features (and can take sometime) as well as openflow statistics collector before returning control to the console.
+This will install hsqldb related dependency features (and can take sometime) as well as OpenFlow statistics collector before returning control to the console.
Installing HBase Data Store
#. Installing HBase server, and
#. Installing TSDR HBase Data Store features from ODL Karaf console.
-In Beryllium, we only support HBase single node running together on the same machine as OpenDaylight. Therefore, follow the steps to download and install HBase server onto the same machine as where OpenDaylight is running:
+In this release, we only support HBase single node running together on the same machine as OpenDaylight. Therefore, follow the steps to download and install HBase server onto the same machine as where OpenDaylight is running:
#. Create a folder in Linux operating system for the HBase server. For example, create an hbase directory under ``/usr/lib``::
#. Installing Cassandra server, and
#. Installing TSDR Cassandra Data Store features from ODL Karaf console.
-In Beryllium, we only support Cassadra single node running together on the same machine as OpenDaylight. Therefore, follow these steps to download and install Cassandra server onto the same machine as where OpenDaylight is running:
+In this release, we only support Cassadra single node running together on the same machine as OpenDaylight. Therefore, follow these steps to download and install Cassandra server onto the same machine as where OpenDaylight is running:
#. Install Cassandra (latest stable version) by downloading the zip file and untar the tar ball to cassandra/ directory on the testing machine::
After the TSDR data store is installed, no matter whether it is HBase data store, Cassandra data store, or HSQLDB data store, the user can verify the installation with the following steps.
-#. Verify if the following two tsdr commands are available from Karaf console::
+#. Verify if the following two TSDR commands are available from Karaf console::
tsdr:list
tsdr:purgeAll
-#. Verify if openflow statisitcs data can be received successfully:
+#. Verify if OpenFlow statistics data can be received successfully:
#. Run "feature:install odl-tsdr-openflow-statistics-collector" from Karaf.
* **Integration Group** hosted the OpenDaylight-wide tests and main release distribution
* **Release Engineering - autorelease** was used to build the Boron release artifacts and including the main release download.
-.. _AAA: https://wiki.opendaylight.org/view/AAA:Beryllium_Release_Notes
-.. _ALTO: https://wiki.opendaylight.org/view/ALTO:Beryllium:Release_Notes
-.. _BGPCEP: https://wiki.opendaylight.org/view/BGP_LS_PCEP:Beryllium_Release_Notes
-.. _CAPWAP: https://wiki.opendaylight.org/view/CAPWAP:Beryllium:Release_Notes
-.. _Controller: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Beryllium:Release_Notes
-.. _DIDM: https://wiki.opendaylight.org/view/DIDM:_Beryllium_Release_Notes
-.. _DLUX: https://wiki.opendaylight.org/view/OpenDaylight_DLUX:Beryllium:Release_Notes
-.. _FaaS: https://wiki.opendaylight.org/view/FaaS:Beryllium_Release_Notes
-.. _Group_Based_Policy: https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Releases/Beryllium:Beryllium_Release_Notes
-.. _IoTDM: https://wiki.opendaylight.org/view/Iotdm:Beryllium_Release_Notes
-.. _L2_Switch: https://wiki.opendaylight.org/view/L2_Switch:Beryllium:Release_Notes
-.. _LACP: https://wiki.opendaylight.org/view/LACP:Beryllium:Release_Notes
-.. _LISP_Flow_Mapping: https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Beryllium_Release_Notes
-.. _MDSAL: https://wiki.opendaylight.org/view/MD-SAL:Beryllium:Release_Notes
-.. _NEMO: https://wiki.opendaylight.org/view/NEMO:Beryllium:Release_Notes
-.. _NETCONF: https://wiki.opendaylight.org/view/OpenDaylight_NETCONF:Beryllium_Release_Notes
+.. _AAA: https://wiki.opendaylight.org/view/AAA:Boron_Release_Notes
+.. _ALTO: https://wiki.opendaylight.org/view/ALTO:Boron:Release_Notes
+.. _BGPCEP: https://wiki.opendaylight.org/view/BGP_LS_PCEP:Boron_Release_Notes
+.. _CAPWAP: https://wiki.opendaylight.org/view/CAPWAP:Boron:Release_Notes
+.. _Controller: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Boron:Release_Notes
+.. _DIDM: https://wiki.opendaylight.org/view/DIDM:_Boron_Release_Notes
+.. _DLUX: https://wiki.opendaylight.org/view/OpenDaylight_DLUX:Boron:Release_Notes
+.. _FaaS: https://wiki.opendaylight.org/view/FaaS:Boron_Release_Notes
+.. _Group_Based_Policy: https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Releases/Boron:Boron_Release_Notes
+.. _IoTDM: https://wiki.opendaylight.org/view/Iotdm:Boron_Release_Notes
+.. _L2_Switch: https://wiki.opendaylight.org/view/L2_Switch:Boron:Release_Notes
+.. _LACP: https://wiki.opendaylight.org/view/LACP:Boron:Release_Notes
+.. _LISP_Flow_Mapping: https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Boron_Release_Notes
+.. _MDSAL: https://wiki.opendaylight.org/view/MD-SAL:Boron:Release_Notes
+.. _NEMO: https://wiki.opendaylight.org/view/NEMO:Boron:Release_Notes
+.. _NETCONF: https://wiki.opendaylight.org/view/OpenDaylight_NETCONF:Boron_Release_Notes
.. _NetIDE: https://wiki.opendaylight.org/view/NetIDE:Release_Notes
-.. _NeXt: https://wiki.opendaylight.org/view/NeXt:Beryllium_Release_Notes
+.. _NeXt: https://wiki.opendaylight.org/view/NeXt:Boron_Release_Notes
.. _NIC: https://wiki.opendaylight.org/view/Network_Intent_Composition:Release_Notes
-.. _Neutron_Northbound: https://wiki.opendaylight.org/view/NeutronNorthbound:Beryllium:Release_Notes
-.. _OF-Config: https://wiki.opendaylight.org/view/OF-CONFIG:Beryllium:Release_Notes
-.. _OpFlex: https://wiki.opendaylight.org/view/OpFlex:Beryllium_Release_Notes
-.. _OpenFlow_Plugin: https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Beryllium_Release_Notes
-.. _OpenFlow_Protocol_Library: https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Release_Notes:Beryllium_Release_Notes
-.. _OVSDB_Netvirt: https://wiki.opendaylight.org/view/OpenDaylight_OVSDB:Beryllium_Release_Notes
-.. _Packet_Cable: https://wiki.opendaylight.org/view/PacketCablePCMM:BerylliumReleaseNotes
-.. _SDN_Interface_Application: https://wiki.opendaylight.org/view/ODL-SDNi:Beryllium_Release_Notes
+.. _Neutron_Northbound: https://wiki.opendaylight.org/view/NeutronNorthbound:Boron:Release_Notes
+.. _OF-Config: https://wiki.opendaylight.org/view/OF-CONFIG:Boron:Release_Notes
+.. _OpFlex: https://wiki.opendaylight.org/view/OpFlex:Boron_Release_Notes
+.. _OpenFlow_Plugin: https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Boron_Release_Notes
+.. _OpenFlow_Protocol_Library: https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Release_Notes:Boron_Release_Notes
+.. _OVSDB_Netvirt: https://wiki.opendaylight.org/view/OpenDaylight_OVSDB:Boron_Release_Notes
+.. _Packet_Cable: https://wiki.opendaylight.org/view/PacketCablePCMM:BoronReleaseNotes
+.. _SDN_Interface_Application: https://wiki.opendaylight.org/view/ODL-SDNi:Boron_Release_Notes
.. _SNBI: https://wiki.opendaylight.org/view/SNBI_Berrylium_Release_Notes
-.. _SNMP4SDN: https://wiki.opendaylight.org/view/SNMP4SDN:Beryllium_Release_Note
-.. _SNMP_Plugin: https://wiki.opendaylight.org/view/SNMP_Plugin:SNMP_Plugin:Beryllium_Release_Notes
-.. _SXP: https://wiki.opendaylight.org/view/SXP:Beryllium:Release_Notes
-.. _SFC: https://wiki.opendaylight.org/view/Service_Function_Chaining:Beryllium_Release_Notes
-.. _TCPMD5: https://wiki.opendaylight.org/view/TCPMD5:Beryllium_Release_Notes
-.. _TSDR: https://wiki.opendaylight.org/view/TSDR:Beryllium:Release_Notes
-.. _TTP: https://wiki.opendaylight.org/view/Table_Type_Patterns/Beryllium/Release_Notes
-.. _Topology_Processing_Framework: https://wiki.opendaylight.org/view/Topology_Processing_Framework:BERYLLIUM_Release_Notes
-.. _USC: https://wiki.opendaylight.org/view/USC:Beryllium:Release_Notes
-.. _VPN_Service: https://wiki.opendaylight.org/view/Vpnservice:Beryllium_Release_Notes
-.. _VTN: https://wiki.opendaylight.org/view/VTN:Beryllium:Release_Notes
-.. _YANG_Tools: https://wiki.opendaylight.org/view/YANG_Tools:Beryllium:Release_Notes
+.. _SNMP4SDN: https://wiki.opendaylight.org/view/SNMP4SDN:Boron_Release_Note
+.. _SNMP_Plugin: https://wiki.opendaylight.org/view/SNMP_Plugin:SNMP_Plugin:Boron_Release_Notes
+.. _SXP: https://wiki.opendaylight.org/view/SXP:Boron:Release_Notes
+.. _SFC: https://wiki.opendaylight.org/view/Service_Function_Chaining:Boron_Release_Notes
+.. _TCPMD5: https://wiki.opendaylight.org/view/TCPMD5:Boron_Release_Notes
+.. _TSDR: https://wiki.opendaylight.org/view/TSDR:Boron:Release_Notes
+.. _TTP: https://wiki.opendaylight.org/view/Table_Type_Patterns/Boron/Release_Notes
+.. _Topology_Processing_Framework: https://wiki.opendaylight.org/view/Topology_Processing_Framework:Boron_Release_Notes
+.. _USC: https://wiki.opendaylight.org/view/USC:Boron:Release_Notes
+.. _VPN_Service: https://wiki.opendaylight.org/view/Vpnservice:Boron_Release_Notes
+.. _VTN: https://wiki.opendaylight.org/view/VTN:Boron:Release_Notes
+.. _YANG_Tools: https://wiki.opendaylight.org/view/YANG_Tools:Boron:Release_Notes
odl-groupbasedpolicy-ofoverlay
-For Lithium, **GBP** has one renderer, hence this is loaded by default.
+For this release, **GBP** has one renderer, hence this is loaded by default.
REST calls from OpenStack Neutron are by the Neutron NorthBound project.
* On the control host, `Download
the latest OpenDaylight release <ODL_Downloads_>`_ (at the time of writing,
- this is Beryllium-SR2)
+ this is Boron)
* Uncompress it as root, and start OpenDaylight (you can start OpenDaylight
by running karaf directly, but exiting from the shell will shut it down):
.. code-block:: bash
- tar xvfz distribution-karaf-0.4.2-Beryllium-SR2.tar.gz
- cd distribution-karaf-0.4.2-Beryllium-SR2
+ tar xvfz distribution-karaf-0.5.0-Boron.tar.gz
+ cd distribution-karaf-0.5.0-Boron
./bin/start # Start OpenDaylight as a server process
* Connect to the Karaf shell, and install the odl-ovsdb-openstack bundle,
Then restart the karaf process.
-.. note::
-
- This is a change from the Lithium release, in which
- “etc/org.opendaylight.aaa.authn.cfg” was edited to set
- “authEnabled=false”. Please use the “shiro.ini” mechanism to disable
- AAA going forward.
-
How application developers can leverage AAA to provide servlet security
-----------------------------------------------------------------------
- TokenAuthRealm
- An AuthorizingRealm built to bridge the Shiro-based AAA service
- with the Lithium h2-based AAA implementation.
+ with the h2-based AAA implementation.
- Exposes a RESTful web service to manipulate IdM policy on a
per-node basis. If identical AAA policy is desired across a
OpenDaylight AAA has support for Role Based Access Control based on the
Apache Shiro permissions system. Configuration of the authorization
system is done offline; authorization currently cannot be configured
-after the controller is started. Thus, Authorization in the Beryllium
+after the controller is started. Thus, Authorization in this
release is aimed towards supporting coarse-grained security policies,
with the aim to provide more robust configuration capabilities in the
future. Shiro-based Authorization is documented on the Apache Shiro
Scope of CAPWAP Project
-----------------------
-In the Lithium release, CAPWAP project aims to only detect the WTPs and
+In this release, CAPWAP project aims to only detect the WTPs and
store their basic attributes in the operational data store, which is
accessible via REST and JAVA APIs.
Configuring CAPWAP
------------------
-As of Lithium, there are no configuration requirements.
+As of this release, there are no configuration requirements.
Administering or Managing CAPWAP
--------------------------------
Overview
--------
-In the Beryllium Release of Centinel, this framework enables SDN
+In this release of Centinel, this framework enables SDN
applications/services to receive events from multiple streaming sources
(e.g., Syslog, Thrift, Avro, AMQP, Log4j, HTTP/REST) and execute actions
like network configuration/batch processing/real-time analytics. It also
1. Check whether Graylog is up and running and plugins deployed as
mentioned in `installation
- guide <http://opendaylight.readthedocs.io/en/stable-beryllium/getting-started-guide/index.html>`__.
+ guide <https://opendaylight.readthedocs.io/en/stable-boron/getting-started-guide/project-specific-guides/centinel.html>`__.
2. Check whether HBase is up and respective tables and column families
as mentioned in `installation
- guide <http://opendaylight.readthedocs.io/en/stable-beryllium/getting-started-guide/index.html>`__
+ guide <https://opendaylight.readthedocs.io/en/stable-boron/getting-started-guide/project-specific-guides/centinel.html>`__
are created.
3. Check if apache flume is up and running.
Run REST adjust-flow command to adjust flows and push to the device
-------------------------------------------------------------------
-**Flow mod driver for HP 3800 device is added in Beryllium release.**
+**Flow mod driver for HP 3800 device**
This driver adjusts the flows and push the same to the device. This API
takes the flow to be adjusted as input and displays the adjusted flow as
It is important to show the overall philosophy of **GBP** as it sets the
project’s direction.
-In the Beryllium release of OpenDaylight, **GBP** focused on **expressed
+In this release of OpenDaylight, **GBP** focused on **expressed
intent**, **refactoring of how renderers consume and publish Subject
Feature Definitions for multi-renderer support**.
- Endpoints:
- Define concrete uniquely identifiable entities. In Beryllium,
+ Define concrete uniquely identifiable entities. In this release,
examples could be a Docker container, or a Neutron port
- EndpointGroups:
The *classifier* and *action* portions of the model can be thought of as
hooks, with their definition provided by each *renderer* about its
-domain specific capabilities. In **GBP** Beryllium, there is one
+domain specific capabilities. In **GBP** for this release, there is one
renderer, the *`OpenFlow Overlay renderer (OfOverlay). <#OfOverlay>`__*
These hooks are filled with *definitions* of the types of *features* the
looks as so:
.. figure:: ./images/groupbasedpolicy/GBP_High-levelBerylliumArchitecture.png
- :alt: GBP High Level Beryllium Architecture
+ :alt: GBP High Level Architecture
- GBP High Level Beryllium Architecture
+ GBP High Level Architecture
The major benefit of this architecture is that the mapping of the
domain-specific-language is completely separate and independent of the
can now be leveraged across NetConf devices simultaneously:
.. figure:: ./images/groupbasedpolicy/GBP_High-levelExtraRenderer.png
- :alt: GBP High Level Beryllium Architecture - adding a renderer
+ :alt: GBP High Level Architecture - adding a renderer
- GBP High Level Beryllium Architecture - adding a renderer
+ GBP High Level Architecture - adding a renderer
As other domain-specific mappings occur, they too can leverage the same
renderers, as the renderers only need to implement the **GBP** access
mapping to the access and forwarding models. For instance:
.. figure:: ./images/groupbasedpolicy/High-levelBerylliumArchitectureEvolution2.png
- :alt: GBP High Level Beryllium Architecture - adding a renderer
+ :alt: GBP High Level Architecture - adding a renderer
- GBP High Level Beryllium Architecture - adding a renderer
+ GBP High Level Architecture - adding a renderer
In summary, the **GBP** architecture:
- Consumer Endpoint Identification Constraint
- Label based criteria for matching against endpoints. In Beryllium
+ Label based criteria for matching against endpoints. In this release
this can be used to label endpoints based on IpPrefix.
The second category is the provider matchers, which match against the
- Consumer Endpoint Identification Constraint
- Label based criteria for matching against endpoints. In Beryllium
+ Label based criteria for matching against endpoints. In this release
this can be used to label endpoints based on IpPrefix.
Clauses have a list of subjects that apply when all the matchers in the
Demo/Development environment
----------------------------
-The **GBP** project for Beryllium has two demo/development environments.
+The **GBP** project for this release has two demo/development environments.
- Docker based GBP and GBP+SFC integration Vagrant environment
Running the L2Switch project
----------------------------
-To run the L2 Switch inside the Lithium OpenDaylight distribution simply
+To run the L2 Switch inside the OpenDaylight distribution simply
install the ``odl-l2switch-switch-ui`` feature;
::
Prerequisites
^^^^^^^^^^^^^
-- **OpenDaylight Beryllium**
+- **OpenDaylight Boron**
- **The Postman Chrome App**: the most convenient way to follow along
this tutorial is to use the `Postman Chrome
file. You can import this file to Postman by clicking *Import* at the
top, choosing *Download from link* and then entering the following
URL:
- ``https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=blob_plain;f=resources/tutorial/Beryllium_Tutorial.json.postman_collection;hb=refs/heads/stable/beryllium``.
+ ``https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=blob_plain;f=resources/tutorial/Beryllium_Tutorial.json.postman_collection;hb=refs/heads/stable/boron``.
Alternatively, you can save the file on your machine, or if you have
the repository checked out, you can import from there. You will need
to create a new Postman Environment and define some variables within:
Mapping RPC REST API. This is so that you can see the actual request
URLs and body content on the page.
-1. Install and run OpenDaylight Beryllium release on the controller VM.
- Please follow the general OpenDaylight Beryllium Installation Guide
+1. Install and run OpenDaylight Boron release on the controller VM.
+ Please follow the general OpenDaylight Boron Installation Guide
for this step. Once the OpenDaylight controller is running install
the *odl-lispflowmapping-msmr* feature from the Karaf CLI:
.. note::
- The ``resources/tutorial`` directory in the *stable/beryllium*
+ The ``resources/tutorial`` directory in the *stable/boron*
branch of the project git repository has the files used in the
tutorial `checked
- in <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial;hb=refs/heads/stable/beryllium>`__,
+ in <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial;hb=refs/heads/stable/boron>`__,
so you can just copy the files to ``/root/lispd.conf`` on the
respective VMs. You will also find the JSON files referenced
below in the same directory.
- Serves as an alternative interface for MD-SAL (besides RESTCONF)
and allows users to read/write data from MD-SAL’s datastore and to
invoke its rpcs (NETCONF notifications are not available in the
- Beryllium release of OpenDaylight)
+ Boron release of OpenDaylight)
.. note::
- `RFC-6470 <https://tools.ietf.org/html/rfc6470>`__
- (partially, only the schema-change notification is available in
- Beryllium release)
+ Boron release)
- `RFC-6022 <https://tools.ietf.org/html/rfc6022>`__
- `draft-ietf-netconf-yang-library-06 <https://tools.ietf.org/html/draft-ietf-netconf-yang-library-06>`__
-Notifications over NETCONF are not supported in the Beryllium release.
+Notifications over NETCONF are not supported in the Boron release.
**Tip**
**Tip**
Download testtool from OpenDaylight Nexus at:
- https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.0.2-Beryllium-SR2/
+ https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.1.0-Boron/
**Nexus contains 3 executable tools:**
Netconf-testtool is now part of default maven build profile for
controller and can be also downloaded from nexus. The executable jar for
testtool can be found at:
-`nexus-artifacts <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.0.2-Beryllium-SR2/>`__
+`nexus-artifacts <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.1.0-Boron/>`__
Running testtool
^^^^^^^^^^^^^^^^
Downloading and deploy Karaf distribution
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Get the Beryllium distribution.
+- Get the Boron distribution.
- Unzip the downloaded zip distribution.
The security group in openstack helps to filter packets based on
policies configured. The current implementation in openstack uses
-iptables to realize security groups. In Opendaylight instead of iptable
+iptables to realize security groups. In OpenDaylight instead of iptable
rules, ovs flows are used. This will remove the many layers of
bridges/ports required in iptable implementation.
The current rules are applied on the basis of the following attributes:
ingress/egress, protocol, port range, and prefix. In the pipeline, table
-40 is used for egress acl and table 90 for ingress acl rules.
+40 is used for egress ACL and table 90 for ingress ACL rules.
Stateful Implementation
^^^^^^^^^^^^^^^^^^^^^^^
::
- -trk - The packet was never send to netfilter framework
+ -trk - The packet was never send to netfilter framework
::
- +trk+est - It is already known and connection which was allowed previously,
- pass it to the next table.
+ +trk+est - It is already known and connection which was allowed previously,
+ pass it to the next table.
::
- +trk+new - This is a new connection. So if there is a specific rule in the
- table which allows this traffic with a commit action an entry will be made
- in the netfilter framework. If there is no specific rule to allow this
- traffic the packet will be dropped.
+ +trk+new - This is a new connection. So if there is a specific rule in the
+ table which allows this traffic with a commit action an entry will be made
+ in the netfilter framework. If there is no specific rule to allow this
+ traffic the packet will be dropped.
So, by default, a packet is be dropped unless there is a rule to allow
the packet.
::
- cookie=0x0, duration=36.848s, table=90, n_packets=2, n_bytes=717,
+ cookie=0x0, duration=36.848s, table=90, n_packets=2, n_bytes=717,
priority=61006,udp,dl_src=fa:16:3e:a1:f9:d0,
- tp_src=67,tp_dst=68 actions=goto_table:100
+ tp_src=67,tp_dst=68 actions=goto_table:100
::
- cookie=0x0, duration=36.566s, table=90, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=36.566s, table=90, n_packets=0, n_bytes=0,
priority=61006,udp6,dl_src=fa:16:3e:a1:f9:d0,
- tp_src=547,tp_dst=546 actions=goto_table:100
+ tp_src=547,tp_dst=546 actions=goto_table:100
- Allow DHCP client traffic egress.
::
- cookie=0x0, duration=2165.596s, table=40, n_packets=2, n_bytes=674,
- priority=61012,udp,tp_src=68,tp_dst=67 actions=goto_table:50
+ cookie=0x0, duration=2165.596s, table=40, n_packets=2, n_bytes=674,
+ priority=61012,udp,tp_src=68,tp_dst=67 actions=goto_table:50
::
- cookie=0x0, duration=2165.513s, table=40, n_packets=0, n_bytes=0,
- priority=61012,udp6,tp_src=546,tp_dst=547 actions=goto_table:50
+ cookie=0x0, duration=2165.513s, table=40, n_packets=0, n_bytes=0,
+ priority=61012,udp6,tp_src=546,tp_dst=547 actions=goto_table:50
- Prevent DHCP server traffic from the vm port.(DHCP Spoofing)
::
- cookie=0x0, duration=34.711s, table=40, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=34.711s, table=40, n_packets=0, n_bytes=0,
priority=61011,udp,in_port=2,tp_src=67,tp_dst=68 actions=drop
::
- cookie=0x0, duration=34.519s, table=40, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=34.519s, table=40, n_packets=0, n_bytes=0,
priority=61011,udp6,in_port=2,tp_src=547,tp_dst=546 actions=drop
Arp rules
::
- cookie=0x0, duration=35.015s, table=40, n_packets=10, n_bytes=420,
+ cookie=0x0, duration=35.015s, table=40, n_packets=10, n_bytes=420,
priority=61010,arp,arp_sha=fa:16:3e:93:88:60 actions=goto_table:50
::
- cookie=0x0, duration=35.582s, table=90, n_packets=1, n_bytes=42,
- priority=61010,arp,arp_tha=fa:16:3e:93:88:60 actions=goto_table:100
+ cookie=0x0, duration=35.582s, table=90, n_packets=1, n_bytes=42,
+ priority=61010,arp,arp_tha=fa:16:3e:93:88:60 actions=goto_table:100
Conntrack rules
'''''''''''''''
::
- cookie=0x0, duration=35.015s table=40,priority=61021,in_port=3,
+ cookie=0x0, duration=35.015s table=40,priority=61021,in_port=3,
ct_state=-trk,action=ct"("table=0")"
::
- cookie=0x0, duration=35.015s table=40,priority=61020,in_port=3,
+ cookie=0x0, duration=35.015s table=40,priority=61020,in_port=3,
ct_state=+trk+est,action=goto_table:50
::
- cookie=0x0, duration=35.015s table=40,priority=36002,in_port=3,
+ cookie=0x0, duration=35.015s table=40,priority=36002,in_port=3,
ct_state=+new,actions=drop
::
- cookie=0x0, duration=35.015s table=90,priority=61022,
+ cookie=0x0, duration=35.015s table=90,priority=61022,
dl_dst=fa:16:3e:0d:8d:21,ct_state=+trk+est,action=goto_table:100
::
- cookie=0x0, duration=35.015s table=90,priority=61021,
+ cookie=0x0, duration=35.015s table=90,priority=61021,
dl_dst=fa:16:3e:0d:8d:21,ct_state=-trk,action=ct"("table=0")"
::
- cookie=0x0, duration=35.015s table=90,priority=36002,
+ cookie=0x0, duration=35.015s table=90,priority=36002,
dl_dst=fa:16:3e:0d:8d:21,ct_state=+new,actions=drop
TCP SYN Rule
::
- User can add security groups in openstack via command line or UI. When we associate this security group with a vm the flows related to each security group will be added in the related tables. A preconfigured security group called the default security group is available in neutron db.
+ User can add security groups in openstack via command line or UI. When we associate this security group with a vm the flows related to each security group will be added in the related tables. A preconfigured security group called the default security group is available in neutron db.
Stateful
''''''''
::
- cookie=0x0, duration=202.516s, table=40, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=202.516s, table=40, n_packets=0, n_bytes=0,
priority=61007,ct_state=+new+trk,icmp,dl_src=fa:16:3e:ee:a5:ec,
- nw_dst=0.0.0.0/24,icmp_type=2,icmp_code=4 actions=ct(commit),goto_table:50
+ nw_dst=0.0.0.0/24,icmp_type=2,icmp_code=4 actions=ct(commit),goto_table:50
::
- cookie=0x0, duration=60.701s, table=90, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=60.701s, table=90, n_packets=0, n_bytes=0,
priority=61007,ct_state=+new+trk,udp,dl_dst=fa:16:3e:22:59:2f,
- nw_src=10.100.5.3,tp_dst=2222 actions=ct(commit),goto_table:100
+ nw_src=10.100.5.3,tp_dst=2222 actions=ct(commit),goto_table:100
::
- cookie=0x0, duration=58.988s, table=90, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=58.988s, table=90, n_packets=0, n_bytes=0,
priority=61007,ct_state=+new+trk,tcp,dl_dst=fa:16:3e:22:59:2f,
- nw_src=10.100.5.3,tp_dst=1111 actions=ct(commit),goto_table:100
+ nw_src=10.100.5.3,tp_dst=1111 actions=ct(commit),goto_table:100
Stateless
'''''''''
::
- cookie=0x0, duration=13211.171s, table=40, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=13211.171s, table=40, n_packets=0, n_bytes=0,
priority=61007,icmp,dl_src=fa:16:3e:93:88:60,nw_dst=0.0.0.0/24,
- icmp_type=2,icmp_code=4 actions=goto_table:50
+ icmp_type=2,icmp_code=4 actions=goto_table:50
::
- cookie=0x0, duration=199.674s, table=90, n_packets=0, n_bytes=0,
- priority=61007,udp,dl_dst=fa:16:3e:dc:49:ff,nw_src=10.100.5.3,tp_dst=2222
+ cookie=0x0, duration=199.674s, table=90, n_packets=0, n_bytes=0,
+ priority=61007,udp,dl_dst=fa:16:3e:dc:49:ff,nw_src=10.100.5.3,tp_dst=2222
actions=goto_table:100
::
- cookie=0x0, duration=199.780s, table=90, n_packets=0, n_bytes=0,
- priority=61007,tcp,dl_dst=fa:16:3e:93:88:60,nw_src=10.100.5.4,tp_dst=3333
+ cookie=0x0, duration=199.780s, table=90, n_packets=0, n_bytes=0,
+ priority=61007,tcp,dl_dst=fa:16:3e:93:88:60,nw_src=10.100.5.4,tp_dst=3333
actions=goto_table:100
TCP/UDP Port Range
::
- cookie=0x0, duration=56.129s, table=90, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=56.129s, table=90, n_packets=0, n_bytes=0,
priority=61007,udp,dl_dst=fa:16:3e:f9:2c:42,nw_src=0.0.0.0/24,
- tp_dst=0x200/0xff00 actions=goto_table:100
+ tp_dst=0x200/0xff00 actions=goto_table:100
::
- cookie=0x0, duration=55.805s, table=90, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=55.805s, table=90, n_packets=0, n_bytes=0,
priority=61007,udp,dl_dst=fa:16:3e:f9:2c:42,nw_src=0.0.0.0/24,
- tp_dst=0x160/0xffe0 actions=goto_table:100
+ tp_dst=0x160/0xffe0 actions=goto_table:100
::
- cookie=0x0, duration=55.587s, table=90, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=55.587s, table=90, n_packets=0, n_bytes=0,
priority=61007,udp,dl_dst=fa:16:3e:f9:2c:42,nw_src=0.0.0.0/24,
- tp_dst=0x300/0xfff8 actions=goto_table:100
+ tp_dst=0x300/0xfff8 actions=goto_table:100
::
- cookie=0x0, duration=55.437s, table=90, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=55.437s, table=90, n_packets=0, n_bytes=0,
priority=61007,udp,dl_dst=fa:16:3e:f9:2c:42,nw_src=0.0.0.0/24,
- tp_dst=0x150/0xfff0 actions=goto_table:100
+ tp_dst=0x150/0xfff0 actions=goto_table:100
::
- cookie=0x0, duration=55.282s, table=90, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=55.282s, table=90, n_packets=0, n_bytes=0,
priority=61007,udp,dl_dst=fa:16:3e:f9:2c:42,nw_src=0.0.0.0/24,
- tp_dst=0x14e/0xfffe actions=goto_table:100
+ tp_dst=0x14e/0xfffe actions=goto_table:100
::
- cookie=0x0, duration=54.063s, table=90, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=54.063s, table=90, n_packets=0, n_bytes=0,
priority=61007,udp,dl_dst=fa:16:3e:f9:2c:42,nw_src=0.0.0.0/24,
- tp_dst=0x308/0xfffe actions=goto_table:100
+ tp_dst=0x308/0xfffe actions=goto_table:100
::
- cookie=0x0, duration=55.130s, table=90, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=55.130s, table=90, n_packets=0, n_bytes=0,
priority=61007,udp,dl_dst=fa:16:3e:f9:2c:42,nw_src=0.0.0.0/24,
- tp_dst=333 actions=goto_table:100
+ tp_dst=333 actions=goto_table:100
CIDR/Remote Security Group
^^^^^^^^^^^^^^^^^^^^^^^^^^
::
- When adding a security group we can select the rule to applicable to a
- set of CIDR or to a set of VMs which has a particular security group
- associated with it.
+ When adding a security group we can select the rule to applicable to a
+ set of CIDR or to a set of VMs which has a particular security group
+ associated with it.
If CIDR is selected there will be only one flow rule added allowing the
traffic from/to the IP’s belonging to that CIDR.
::
- cookie=0x0, duration=202.516s, table=40, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=202.516s, table=40, n_packets=0, n_bytes=0,
priority=61007,ct_state=+new+trk,icmp,dl_src=fa:16:3e:ee:a5:ec,
- nw_dst=0.0.0.0/24,icmp_type=2,icmp_code=4 actions=ct(commit),goto_table:50
+ nw_dst=0.0.0.0/24,icmp_type=2,icmp_code=4 actions=ct(commit),goto_table:50
If a remote security group is selected a flow will be inserted for every
vm which has that security group associated.
::
- cookie=0x0, duration=60.701s, table=90, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=60.701s, table=90, n_packets=0, n_bytes=0,
priority=61007,ct_state=+new+trk,udp,dl_dst=fa:16:3e:22:59:2f,
- nw_src=10.100.5.3,tp_dst=2222 actions=ct(commit),goto_table:100
+ nw_src=10.100.5.3,tp_dst=2222 actions=ct(commit),goto_table:100
::
- cookie=0x0, duration=58.988s, table=90, n_packets=0, n_bytes=0,
+ cookie=0x0, duration=58.988s, table=90, n_packets=0, n_bytes=0,
priority=61007,ct_state=+new+trk,tcp,dl_dst=fa:16:3e:22:59:2f,
- nw_src=10.100.5.3,tp_dst=1111 actions=ct(commit),goto_table:100
+ nw_src=10.100.5.3,tp_dst=1111 actions=ct(commit),goto_table:100
Rules supported in ODL
^^^^^^^^^^^^^^^^^^^^^^
The OVSDB Southbound Plugin provides a YANG model which is based on the
abstract `network topology
-model <https://github.com/opendaylight/yangtools/blob/stable/beryllium/yang/yang-parser-impl/src/test/resources/ietf/network-topology%402013-10-21.yang>`__.
+model <https://github.com/opendaylight/yangtools/blob/stable/boron/yang/yang-parser-impl/src/test/resources/ietf/network-topology%402013-10-21.yang>`__.
The details of the OVSDB YANG model are defined in the
-`ovsdb.yang <https://github.com/opendaylight/ovsdb/blob/stable/beryllium/southbound/southbound-api/src/main/yang/ovsdb.yang>`__
+`ovsdb.yang <https://github.com/opendaylight/ovsdb/blob/stable/boron/southbound/southbound-api/src/main/yang/ovsdb.yang>`__
file.
The OVSDB YANG model defines three augmentations:
This section will show some examples on how to manage QoS and Queue
entries via the configuration MD-SAL. The examples will be illustrated
by using RESTCONF (see `QoS and Queue Postman
-Collection <https://github.com/opendaylight/ovsdb/blob/stable/beryllium/resources/commons/Qos-and-Queue-Collection.json.postman_collection>`__
+Collection <https://github.com/opendaylight/ovsdb/blob/stable/boron/resources/commons/Qos-and-Queue-Collection.json.postman_collection>`__
).
A pre-requisite for managing QoS and Queue entries is that the OVS host
schema <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf>`__
`OVSDB and Netvirt Postman
-Collection <https://github.com/opendaylight/ovsdb/blob/stable/beryllium/resources/commons>`__
+Collection <https://github.com/opendaylight/ovsdb/blob/stable/boron/resources/commons>`__
OVSDB Hardware VTEP SouthBound Plugin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
::
{
- "network-topology:node": [
- {
- "node-id": "hwvtep://192.168.1.115:6640",
- "hwvtep:connection-info":
- {
- "hwvtep:remote-port": 6640,
- "hwvtep:remote-ip": "192.168.1.115"
- }
- }
- ]
+ "network-topology:node": [
+ {
+ "node-id": "hwvtep://192.168.1.115:6640",
+ "hwvtep:connection-info":
+ {
+ "hwvtep:remote-port": 6640,
+ "hwvtep:remote-ip": "192.168.1.115"
+ }
+ }
+ ]
}
-Please replace *odl* in the URL with the IP address of your OpendayLight
+Please replace *odl* in the URL with the IP address of your OpenDaylight
controller and change *192.168.1.115* to your hwvtep node IP.
**NOTE**: The format of node-id is fixed. It will be one of the two:
::
- hwvtep://ip:port
+ hwvtep://ip:port
Switch initiates connection:
::
- hwvtep://uuid/<uuid of switch>
+ hwvtep://uuid/<uuid of switch>
The reason for using UUID is that we can distinguish between multiple
switches if they are behind a NAT.
::
{
- "node": [
- {
- "node-id": "hwvtep://192.168.1.115:6640",
- "hwvtep:switches": [
- {
- "switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640/physicalswitch/br0']"
- }
- ],
- "hwvtep:connection-info": {
- "local-ip": "192.168.92.145",
- "local-port": 47802,
- "remote-port": 6640,
- "remote-ip": "192.168.1.115"
- }
- },
- {
- "node-id": "hwvtep://192.168.1.115:6640/physicalswitch/br0",
- "hwvtep:management-ips": [
- {
- "management-ips-key": "192.168.1.115"
- }
- ],
- "hwvtep:physical-switch-uuid": "37eb5abd-a6a3-4aba-9952-a4d301bdf371",
- "hwvtep:managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']",
- "hwvtep:hwvtep-node-description": "",
- "hwvtep:tunnel-ips": [
- {
- "tunnel-ips-key": "192.168.1.115"
- }
- ],
- "hwvtep:hwvtep-node-name": "br0"
- }
- ]
+ "node": [
+ {
+ "node-id": "hwvtep://192.168.1.115:6640",
+ "hwvtep:switches": [
+ {
+ "switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640/physicalswitch/br0']"
+ }
+ ],
+ "hwvtep:connection-info": {
+ "local-ip": "192.168.92.145",
+ "local-port": 47802,
+ "remote-port": 6640,
+ "remote-ip": "192.168.1.115"
+ }
+ },
+ {
+ "node-id": "hwvtep://192.168.1.115:6640/physicalswitch/br0",
+ "hwvtep:management-ips": [
+ {
+ "management-ips-key": "192.168.1.115"
+ }
+ ],
+ "hwvtep:physical-switch-uuid": "37eb5abd-a6a3-4aba-9952-a4d301bdf371",
+ "hwvtep:managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']",
+ "hwvtep:hwvtep-node-description": "",
+ "hwvtep:tunnel-ips": [
+ {
+ "tunnel-ips-key": "192.168.1.115"
+ }
+ ],
+ "hwvtep:hwvtep-node-name": "br0"
+ }
+ ]
}
If there is a physical switch which has already been created by manual
::
{
- "network-topology:node": [
- {
- "node-id": "hwvtep://192.168.1.115:6640/physicalswitch/br0",
- "hwvtep-node-name": "ps0",
- "hwvtep-node-description": "",
- "management-ips": [
- {
- "management-ips-key": "192.168.1.115"
- }
- ],
- "tunnel-ips": [
- {
- "tunnel-ips-key": "192.168.1.115"
- }
- ],
- "managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']"
- }
- ]
+ "network-topology:node": [
+ {
+ "node-id": "hwvtep://192.168.1.115:6640/physicalswitch/br0",
+ "hwvtep-node-name": "ps0",
+ "hwvtep-node-description": "",
+ "management-ips": [
+ {
+ "management-ips-key": "192.168.1.115"
+ }
+ ],
+ "tunnel-ips": [
+ {
+ "tunnel-ips-key": "192.168.1.115"
+ }
+ ],
+ "managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']"
+ }
+ ]
}
Note: "managed-by" must provided by user. We can get its value after the
::
{
- "logical-switches": [
- {
- "hwvtep-node-name": "ls0",
- "hwvtep-node-description": "",
- "tunnel-key": "10000"
- }
- ]
+ "logical-switches": [
+ {
+ "hwvtep-node-name": "ls0",
+ "hwvtep-node-description": "",
+ "tunnel-key": "10000"
+ }
+ ]
}
Create a physical locator
::
- {
- "termination-point": [
- {
- "tp-id": "vxlan_over_ipv4:192.168.0.116",
- "encapsulation-type": "encapsulation-type-vxlan-over-ipv4",
- "dst-ip": "192.168.0.116"
- }
- ]
- }
+ {
+ "termination-point": [
+ {
+ "tp-id": "vxlan_over_ipv4:192.168.0.116",
+ "encapsulation-type": "encapsulation-type-vxlan-over-ipv4",
+ "dst-ip": "192.168.0.116"
+ }
+ ]
+ }
The "tp-id" of locator is "{encapsualation-type}: {dst-ip}".
::
{
- "remote-mcast-macs": [
- {
- "mac-entry-key": "00:00:00:00:00:00",
- "logical-switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']/hwvtep:logical-switches[hwvtep:hwvtep-node-name='ls0']",
- "locator-set": [
- {
- "locator-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://219.141.189.115:6640']/network-topology:termination-point[network-topology:tp-id='vxlan_over_ipv4:192.168.0.116']"
- }
- ]
- }
- ]
+ "remote-mcast-macs": [
+ {
+ "mac-entry-key": "00:00:00:00:00:00",
+ "logical-switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']/hwvtep:logical-switches[hwvtep:hwvtep-node-name='ls0']",
+ "locator-set": [
+ {
+ "locator-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://219.141.189.115:6640']/network-topology:termination-point[network-topology:tp-id='vxlan_over_ipv4:192.168.0.116']"
+ }
+ ]
+ }
+ ]
}
The physical locator *vxlan\_over\_ipv4:192.168.0.116* is just created
::
{
- "network-topology:termination-point": [
- {
- "tp-id": "port0",
- "hwvtep-node-name": "port0",
- "hwvtep-node-description": "",
- "vlan-bindings": [
- {
- "vlan-id-key": "100",
- "logical-switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']/hwvtep:logical-switches[hwvtep:hwvtep-node-name='ls0']"
- }
- ]
- }
- ]
+ "network-topology:termination-point": [
+ {
+ "tp-id": "port0",
+ "hwvtep-node-name": "port0",
+ "hwvtep-node-description": "",
+ "vlan-bindings": [
+ {
+ "vlan-id-key": "100",
+ "logical-switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']/hwvtep:logical-switches[hwvtep:hwvtep-node-name='ls0']"
+ }
+ ]
+ }
+ ]
}
At this point, we have completed the basic configuration.
::
{
- "remote-ucast-macs": [
- {
- "mac-entry-key": "11:11:11:11:11:11",
- "logical-switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']/hwvtep:logical-switches[hwvtep:hwvtep-node-name='ls0']",
- "ipaddr": "1.1.1.1",
- "locator-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']/network-topology:termination-point[network-topology:tp-id='vxlan_over_ipv4:192.168.0.116']"
- }
- ]
+ "remote-ucast-macs": [
+ {
+ "mac-entry-key": "11:11:11:11:11:11",
+ "logical-switch-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']/hwvtep:logical-switches[hwvtep:hwvtep-node-name='ls0']",
+ "ipaddr": "1.1.1.1",
+ "locator-ref": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='hwvtep:1']/network-topology:node[network-topology:node-id='hwvtep://192.168.1.115:6640']/network-topology:termination-point[network-topology:tp-id='vxlan_over_ipv4:192.168.0.116']"
+ }
+ ]
}
Create a local-ucast-macs entry
::
- cd <Beryllium_controller_directory>/bin
- (for example, cd distribution-karaf-x.x.x-Beryllium/bin)
+ cd <Boron_controller_directory>/bin
+ (for example, cd distribution-karaf-x.x.x-Boron/bin)
::
can be performed using OpenDaylight as a centralized point for relaying
the information.
-OpenDayLight can create filters for exporting and receiving IP-SGT
+OpenDaylight can create filters for exporting and receiving IP-SGT
bindings used on specific peer groups, thus can provide more complex
maintaining of policy groups.
--------
The version of the UNI Manager (UNIMgr) plug-in included in OpenDaylight
-Beryllium release is experimental, serving as a proof-of-concept (PoC)
+Boron release is experimental, serving as a proof-of-concept (PoC)
for using features of OpenDaylight to provision networked elements with
attributes satisfying Metro Ethernet Forum (MEF) requirements for
delivery of Carrier Ethernet service. This initial version of UNIMgr
cl-unimgr-mef.yang. A copy of this module is available in the
odl-unimgr-api bundle of the UNIMgr project.
-Limitations of the PoC version of UNI Manager in OpenDaylight Beryllium
+Limitations of the PoC version of UNI Manager in OpenDaylight Boron
include those listed below: \* Uses only OVSDB southbound interface of
OpenDaylight \* Only uses UNI ID, IP Address, and speed UNI attributes
\* Only uses a subset of EVC per UNI attributes \* Does not use MEF
Code Review / docs.git / commitdiff