--- /dev/null
+OVSDB
+=====
+
+OVSDB Integration
+-----------------
+
+The Open vSwitch database (OVSDB) Southbound Plugin component for
+OpenDaylight implements the OVSDB `RFC
+7047 <https://tools.ietf.org/html/rfc7047>`__ management protocol that
+allows the southbound configuration of switches that support OVSDB. The
+component comprises a library and a plugin. The OVSDB protocol uses
+JSON-RPC calls to manipulate a physical or virtual switch that supports
+OVSDB. Many vendors support OVSDB on various hardware platforms. The
+OpenDaylight controller uses the library project to interact with an OVS
+instance.
+
+.. note::
+
+ Read the OVSDB User Guide before you begin development.
+
+OpenDaylight OVSDB southbound plugin architecture and design
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+OpenVSwitch (OVS) is generally accepted as the unofficial standard for
+Virtual Switching in the Open hypervisor based solutions. Every other
+Virtual Switch implementation, properietery or otherwise, uses OVS in
+some form. For information on OVS, see `Open
+vSwitch <http://openvswitch.org/>`__.
+
+In Software Defined Networking (SDN), controllers and applications
+interact using two channels: OpenFlow and OVSDB. OpenFlow addresses the
+forwarding-side of the OVS functionality. OVSDB, on the other hand,
+addresses the management-plane. A simple and concise overview of Open
+Virtual Switch Database(OVSDB) is available at:
+http://networkstatic.net/getting-started-ovsdb/
+
+Overview of OpenDaylight Controller architecture
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The OpenDaylight controller platform is designed as a highly modular and
+plugin based middleware that serves various network applications in a
+variety of use-cases. The modularity is achieved through the Java OSGi
+framework. The controller consists of many Java OSGi bundles that work
+together to provide the required controller functionalities.
+
+| The bundles can be placed in the following broad categories:
+
+- Network Service Functional Modules (Examples: Topology Manager,
+ Inventory Manager, Forwarding Rules Manager,and others)
+
+- NorthBound API Modules (Examples: Topology APIs, Bridge Domain APIs,
+ Neutron APIs, Connection Manager APIs, and others)
+
+- Service Abstraction Layer(SAL)- (Inventory Services, DataPath
+ Services, Topology Services, Network Config, and others)
+
+- SouthBound Plugins (OpenFlow Plugin, OVSDB Plugin, OpenDove Plugin,
+ and others)
+
+- Application Modules (Simple Forwarding, Load Balancer)
+
+Each layer of the Controller architecture performs specified tasks, and
+hence aids in modularity. While the Northbound API layer addresses all
+the REST-Based application needs, the SAL layer takes care of
+abstracting the SouthBound plugin protocol specifics from the Network
+Service functions.
+
+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
+OpenFlow protocol with the OVS element, the OVSDB plugin will use OVSDB
+schema over JSON-RPC transport.
+
+OVSDB southbound plugin
+~~~~~~~~~~~~~~~~~~~~~~~
+
+| The `Open vSwitch Database Management
+ Protocol-draft-02 <http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02>`__
+ and `Open vSwitch
+ Manual <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf>`__ provide
+ theoretical information about OVSDB. The OVSDB protocol draft is
+ generic enough to lay the groundwork on Wire Protocol and Database
+ Operations, and the OVS Manual currently covers 13 tables leaving
+ space for future OVS expansion, and vendor expansions on proprietary
+ implementations. The OVSDB Protocol is a database records transport
+ protocol using JSON RPC1.0. For information on the protocol structure,
+ see `Getting Started with
+ OVSDB <http://networkstatic.net/getting-started-ovsdb/>`__. The
+ OpenDaylight OVSDB southbound plugin consists of one or more OSGi
+ bundles addressing the following services or functionalities:
+
+- Connection Service - Based on Netty
+
+- Network Configuration Service
+
+- Bidirectional JSON-RPC Library
+
+- OVSDB Schema definitions and Object mappers
+
+- Overlay Tunnel management
+
+- OVSDB to OpenFlow plugin mapping service
+
+- Inventory Service
+
+Connection service
+~~~~~~~~~~~~~~~~~~
+
+| One of the primary services that most southbound plugins provide in
+ 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:
+
+- Connection to a specified element given IP-address, L4-port, and
+ other connectivity options (such as authentication,…)
+
+- Disconnection from an element
+
+- Handling Cluster Mode change notifications to support the
+ OpenDaylight Clustering/High-Availability feature
+
+Network Configuration Service
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+| The goal of the OpenDaylight Network Configuration services is to
+ provide complete management plane solutions needed to successfully
+ install, configure, and deploy the various SDN based network services.
+ These are generic services which can be implemented in part or full by
+ any south-bound protocol plugin. The south-bound plugins can be either
+ of the following:
+
+- The new network virtualization protocol plugins such as OVSDB
+ JSON-RPC
+
+- The traditional management protocols such as SNMP or any others in
+ the middle.
+
+The above definition, and more information on Network Configuration
+Services, is available at :
+https://wiki.opendaylight.org/view/OpenDaylight_Controller:NetworkConfigurationServices
+
+Bidirectional JSON-RPC library
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The OVSDB plugin implements a Bidirectional JSON-RPC library. It is easy
+to design the library as a module that manages the Netty connection
+towards the Element.
+
+| The main responsibilities of this Library are:
+
+- Demarshal and marshal JSON Strings to JSON objects
+
+- Demarshal and marshal JSON Strings from and to the Network Element.
+
+OVSDB Schema definitions and Object mappers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The OVSDB Schema definitions and Object Mapping layer sits above the
+JSON-RPC library. It maps the generic JSON objects to OVSDB schema POJOs
+(Plain Old Java Object) and vice-versa. This layer mostly provides the
+Java Object definition for the corresponding OVSDB schema (13 of them)
+and also will provide much more friendly API abstractions on top of
+these object data. This helps in hiding the JSON semantics from the
+functional modules such as Configuration Service and Tunnel management.
+
+| On the demarshaling side the mapping logic differentiates the Request
+ and Response messages as follows :
+
+- Request messages are mapped by its "method"
+
+- | Response messages are mapped by their IDs which were originally
+ populated by the Request message. The JSON semantics of these OVSDB
+ schema is quite complex. The following figures summarize two of the
+ end-to-end scenarios:
+
+.. figure:: ./images/ConfigurationService-example1.png
+ :alt: End-to-end handling of a Create Bridge request
+
+ End-to-end handling of a Create Bridge request
+
+.. figure:: ./images/MonitorResponse.png
+ :alt: End-to-end handling of a monitor response
+
+ End-to-end handling of a monitor response
+
+Overlay tunnel management
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Network Virtualization using OVS is achieved through Overlay Tunnels.
+The actual Type of the Tunnel may be GRE, VXLAN, or STT. The differences
+in the encapsulation and configuration decide the tunnel types.
+Establishing a tunnel using configuration service requires just the
+sending of OVSDB messages towards the ovsdb-server. However, the scaling
+issues that would arise on the state management at the data-plane (using
+OpenFlow) can get challenging. Also, this module can assist in various
+optimizations in the presence of Gateways. It can also help in providing
+Service guarantees for the VMs using these overlays with the help of
+underlay orchestration.
+
+OVSDB to OpenFlow plugin mapping service
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+| The connect() of the ConnectionService would result in a Node that
+ represents an ovsdb-server. The CreateBridgeDomain() Configuration on
+ the above Node would result in creating an OVS bridge. This OVS Bridge
+ is an OpenFlow Agent for the OpenDaylight OpenFlow plugin with its own
+ Node represented as (example) OF\|xxxx.yyyy.zzzz. Without any help
+ from the OVSDB plugin, the Node Mapping Service of the Controller
+ platform would not be able to map the following:
+
+::
+
+ {OVSDB_NODE + BRIDGE_IDENTFIER} <---> {OF_NODE}.
+
+Without such mapping, it would be extremely difficult for the
+applications to manage and maintain such nodes. This Mapping Service
+provided by the OVSDB plugin would essentially help in providing more
+value added services to the orchestration layers that sit atop the
+Northbound APIs (such as OpenStack).
+
+OVSDB: New features
+~~~~~~~~~~~~~~~~~~~
+
+Schema independent library
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The OVS connection is a node which can have multiple databases. Each
+database is represented by a schema. A single connection can have
+multiple schemas. OSVDB supports multiple schemas. Currently, these are
+two schemas available in the OVSDB, but there is no restriction on the
+number of schemas. Owing to the Northbound v3 API, no code changes in
+ODL are needed for supporting additional schemas.
+
+| Schemas:
+
+- openvswitch : Schema wrapper that represents
+ http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf
+
+- hardwarevtep: Schema wrapper that represents
+ http://openvswitch.org/docs/vtep.5.pdf
+
+OVSDB Library Developer Guide
+-----------------------------
+
+Overview
+~~~~~~~~
+
+The OVSDB library manages the Netty connections to network nodes and
+handles bidirectional JSON-RPC messages. It not only provides OVSDB
+protocol functionality to OpenDaylight OVSDB plugin but also can be used
+as standalone JAVA library for OVSDB protocol.
+
+The main responsibilities of OVSDB library include:
+
+- Manage connections to peers
+
+- Marshal and unmarshal JSON Strings to JSON objects.
+
+- Marshal and unmarshal JSON Strings from and to the Network Element.
+
+Connection Service
+~~~~~~~~~~~~~~~~~~
+
+The OVSDB library provides connection management through the
+OvsdbConnection interface. The OvsdbConnection interface provides OVSDB
+connection management APIs which include both active and passive
+connections. From the library perspective, active OVSDB connections are
+initiated from the controller to OVS nodes while passive OVSDB
+connections are initiated from OVS nodes to the controller. In the
+active connection scenario an application needs to provide the IP
+address and listening port of OVS nodes to the library management API.
+On the other hand, the library management API only requires the info of
+the controller listening port in the passive connection scenario.
+
+For a passive connection scenario, the library also provides a
+connection event listener through the OvsdbConnectionListener interface.
+The listener interface has connected() and disconnected() methods to
+notify an application when a new passive connection is established or an
+existing connection is terminated.
+
+SSL Connection
+~~~~~~~~~~~~~~
+
+In addition to a regular TCP connection, the OvsdbConnection interface
+also provides a connection management API for an SSL connection. To
+start an OVSDB connection with SSL, an application will need to provide
+a Java SSLContext object to the management API. There are different ways
+to create a Java SSLContext, but in most cases a Java KeyStore with
+certificate and private key provided by the application is required.
+Detailed steps about how to create a Java SSLContext is out of the scope
+of this document and can be found in the Java documentation for `JAVA
+Class SSlContext <http://goo.gl/5svszT>`__.
+
+In the active connection scenario, the library uses the given SSLContext
+to create a Java SSLEngine and configures the SSL engine with the client
+mode for SSL handshaking. Normally clients are not required to
+authenticate themselves.
+
+In the passive connection scenario, the library uses the given
+SSLContext to create a Java SSLEngine which will operate in server mode
+for SSL handshaking. For security reasons, the SSLv3 protocol and some
+cipher suites are disabled. Currently the OVSDB server only supports the
+TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA cipher suite and the following
+protocols: SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2.
+
+The SSL engine is also configured to operate on two-way authentication
+mode for passive connection scenarios, i.e., the OVSDB server
+(controller) will authenticate clients (OVS nodes) and clients (OVS
+nodes) are also required to authenticate the server (controller). In the
+two-way authentication mode, an application should keep a trust manager
+to store the certificates of trusted clients and initialize a Java
+SSLContext with this trust manager. Thus during the SSL handshaking
+process the OVSDB server (controller) can use the trust manager to
+verify clients and only accept connection requests from trusted clients.
+On the other hand, users should also configure OVS nodes to authenticate
+the controller. Open vSwitch already supports this functionality in the
+ovsdb-server command with option ``--ca-cert=cacert.pem`` and
+``--bootstrap-ca-cert=cacert.pem``. On the OVS node, a user can use the
+option ``--ca-cert=cacert.pem`` to specify a controller certificate
+directly and the node will only allow connections to the controller with
+the specified certificate. If the OVS node runs ovsdb-server with option
+``--bootstrap-ca-cert=cacert.pem``, it will authenticate the controller
+with the specified certificate cacert.pem. If the certificate file
+doesn’t exist, it will attempt to obtain a certificate from the peer
+(controller) on its first SSL connection and save it to the named PEM
+file ``cacert.pem``. Here is an example of ovsdb-server with
+``--bootstrap-ca-cert=cacert.pem`` option:
+
+``ovsdb-server --pidfile --detach --log-file --remote punix:/var/run/openvswitch/db.sock --remote=db:hardware_vtep,Global,managers --private-key=/etc/openvswitch/ovsclient-privkey.pem -- certificate=/etc/openvswitch/ovsclient-cert.pem --bootstrap-ca-cert=/etc/openvswitch/vswitchd.cacert``
+
+OVSDB protocol transactions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The OVSDB protocol defines the RPC transaction methods in RFC 7047. The
+following RPC methods are supported in OVSDB protocol:
+
+- List databases
+
+- Get schema
+
+- Transact
+
+- Cancel
+
+- Monitor
+
+- Update notification
+
+- Monitor cancellation
+
+- Lock operations
+
+- Locked notification
+
+- Stolen notification
+
+- Echo
+
+According to RFC 7047, an OVSDB server must implement all methods, and
+an OVSDB client is only required to implement the "Echo" method and
+otherwise free to implement whichever methods suit its needs. However,
+the OVSDB library currently doesn’t support all RPC methods. For the
+"Echo" method, the library can handle "Echo" messages from a peer and
+send a JSON response message back, but the library doesn’t support
+actively sending an "Echo" JSON request to a peer. Other unsupported RPC
+methods are listed below:
+
+- Cancel
+
+- Lock operations
+
+- Locked notification
+
+- Stolen notification
+
+In the OVSDB library the RPC methods are defined in the Java interface
+OvsdbRPC. The library also provides a high-level interface OvsdbClient
+as the main interface to interact with peers through the OVSDB protocol.
+In the passive connection scenario, each connection will have a
+corresponding OvsdbClient object, and the application can obtain the
+OvsdbClient object through connection listener callback methods. In
+other words, if the application implements the OvsdbConnectionListener
+interface, it will get notifications of connection status changes with
+the corresponding OvsdbClient object of that connection.
+
+OVSDB database operations
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+RFC 7047 also defines database operations, such as insert, delete, and
+update, to be performed as part of a "transact" RPC request. The OVSDB
+library defines the data operations in Operations.java and provides the
+TransactionBuilder class to help build "transact" RPC requests. To build
+a JSON-RPC transact request message, the application can obtain the
+TransactionBuilder object through a transactBuilder() method in the
+OvsdbClient interface.
+
+The TransactionBuilder class provides the following methods to help
+build transactions:
+
+- getOperations(): Get the list of operations in this transaction.
+
+- add(): Add data operation to this transaction.
+
+- build(): Return the list of operations in this transaction. This is
+ the same as the getOperations() method.
+
+- execute(): Send the JSON RPC transaction to peer.
+
+- getDatabaseSchema(): Get the database schema of this transaction.
+
+If the application wants to build and send a "transact" RPC request to
+modify OVSDB tables on a peer, it can take the following steps:
+
+1. Statically import parameter "op" in Operations.java
+
+ ``import static org.opendaylight.ovsdb.lib.operations.Operations.op;``
+
+2. Obtain transaction builder through transacBuilder() method in
+ OvsdbClient:
+
+ ``TransactionBuilder transactionBuilder = ovsdbClient.transactionBuilder(dbSchema);``
+
+3. Add operations to transaction builder:
+
+ ``transactionBuilder.add(op.insert(schema, row));``
+
+4. Send transaction to peer and get JSON RPC response:
+
+ ``operationResults = transactionBuilder.execute().get();``
+
+ .. note::
+
+ Although the "select" operation is supported in the OVSDB
+ library, the library implementation is a little different from
+ RFC 7047. In RFC 7047, section 5.2.2 describes the "select"
+ operation as follows:
+
+ “The "rows" member of the result is an array of objects. Each object
+ corresponds to a matching row, with each column specified in
+ "columns" as a member, the column’s name as the member name, and its
+ value as the member value. If "columns" is not specified, all the
+ table’s columns are included (including the internally generated
+ "\_uuid" and "\_version" columns).”
+
+ The OVSDB library implementation always requires the column’s name in
+ the "columns" field of a JSON message. If the "columns" field is not
+ specified, none of the table’s columns are included. If the
+ application wants to get the table entry with all columns, it needs
+ to specify all the columns’ names in the "columns" field.
+
+Reference Documentation
+~~~~~~~~~~~~~~~~~~~~~~~
+
+RFC 7047 The Open vSwitch Databse Management Protocol
+https://tools.ietf.org/html/rfc7047
+
+OVSDB MD-SAL Southbound Plugin Developer Guide
+----------------------------------------------
+
+Overview
+~~~~~~~~
+
+The Open vSwitch Database (OVSDB) Model Driven Service Abstraction Layer
+(MD-SAL) Southbound Plugin provides an MD-SAL based interface to Open
+vSwitch systems. This is done by augmenting the MD-SAL topology node
+with a YANG model which replicates some (but not all) of the Open
+vSwitch schema.
+
+OVSDB MD-SAL Southbound Plugin Architecture and Operation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The architecture and operation of the OVSDB MD-SAL Southbound plugin is
+illustrated in the following set of diagrams.
+
+Connecting to an OVSDB Node
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An OVSDB node is a system which is running the OVS software and is
+capable of being managed by an OVSDB manager. The OVSDB MD-SAL
+Southbound plugin in OpenDaylight is capable of operating as an OVSDB
+manager. Depending on the configuration of the OVSDB node, the
+connection of the OVSDB manager can be active or passive.
+
+Active OVSDB Node Manager Workflow
+''''''''''''''''''''''''''''''''''
+
+An active OVSDB node manager connection is made when OpenDaylight
+initiates the connection to the OVSDB node. In order for this to work,
+you must configure the OVSDB node to listen on a TCP port for the
+connection (i.e. OpenDaylight is active and the OVSDB node is passive).
+This option can be configured on the OVSDB node using the following
+command:
+
+::
+
+ ovs-vsctl set-manager ptcp:6640
+
+The following diagram illustrates the sequence of events which occur
+when OpenDaylight initiates an active OVSDB manager connection to an
+OVSDB node.
+
+.. figure:: ./images/ovsdb-sb-active-connection.jpg
+ :alt: Active OVSDB Manager Connection
+
+ Active OVSDB Manager Connection
+
+Step 1
+ Create an OVSDB node by using RESTCONF or an OpenDaylight plugin.
+ The OVSDB node is listed under the OVSDB topology node.
+
+Step 2
+ Add the OVSDB node to the OVSDB MD-SAL southbound configuration
+ datastore. The OVSDB southbound provider is registered to listen for
+ data change events on the portion of the MD-SAL topology data store
+ which contains the OVSDB southbound topology node augmentations. The
+ addition of an OVSDB node causes an event which is received by the
+ OVSDB Southbound provider.
+
+Step 3
+ The OVSDB Southbound provider initiates a connection to the OVSDB
+ node using the connection information provided in the configuration
+ OVSDB node (i.e. IP address and TCP port number).
+
+Step 4
+ The OVSDB Southbound provider adds the OVSDB node to the OVSDB
+ MD-SAL operational data store. The operational data store contains
+ OVSDB node objects which represent active connections to OVSDB
+ nodes.
+
+Step 5
+ The OVSDB Southbound provider requests the schema and databases
+ which are supported by the OVSDB node.
+
+Step 6
+ The OVSDB Southbound provider uses the database and schema
+ information to construct a monitor request which causes the OVSDB
+ node to send the controller any updates made to the OVSDB databases
+ on the OVSDB node.
+
+Passive OVSDB Node Manager Workflow
+'''''''''''''''''''''''''''''''''''
+
+A passive OVSDB node connection to OpenDaylight is made when the OVSDB
+node initiates the connection to OpenDaylight. In order for this to
+work, you must configure the OVSDB node to connect to the IP address and
+OVSDB port on which OpenDaylight is listening. This option can be
+configured on the OVSDB node using the following command:
+
+::
+
+ ovs-vsctl set-manager tcp:<IP address>:6640
+
+The following diagram illustrates the sequence of events which occur
+when an OVSDB node connects to OpenDaylight.
+
+.. figure:: ./images/ovsdb-sb-passive-connection.jpg
+ :alt: Passive OVSDB Manager Connection
+
+ Passive OVSDB Manager Connection
+
+Step 1
+ The OVSDB node initiates a connection to OpenDaylight.
+
+Step 2
+ The OVSDB Southbound provider adds the OVSDB node to the OVSDB
+ MD-SAL operational data store. The operational data store contains
+ OVSDB node objects which represent active connections to OVSDB
+ nodes.
+
+Step 3
+ The OVSDB Southbound provider requests the schema and databases
+ which are supported by the OVSDB node.
+
+Step 4
+ The OVSDB Southbound provider uses the database and schema
+ information to construct a monitor request which causes the OVSDB
+ node to send back any updates which have been made to the OVSDB
+ databases on the OVSDB node.
+
+OVSDB Node ID in the Southbound Operational MD-SAL
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When OpenDaylight initiates an active connection to an OVSDB node, it
+writes an external-id to the Open\_vSwitch table on the OVSDB node. The
+external-id is an OpenDaylight instance identifier which identifies the
+OVSDB topology node which has just been created. Here is an example
+showing the value of the *opendaylight-iid* entry in the external-ids
+column of the Open\_vSwitch table where the node-id of the OVSDB node is
+*ovsdb:HOST1*.
+
+::
+
+ $ ovs-vsctl list open_vswitch
+ ...
+ external_ids : {opendaylight-iid="/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb:HOST1']"}
+ ...
+
+The *opendaylight-iid* entry in the external-ids column of the
+Open\_vSwitch table causes the OVSDB node to have same node-id in the
+operational MD-SAL datastore as in the configuration MD-SAL datastore.
+This holds true if the OVSDB node manager settings are subsequently
+changed so that a passive OVSDB manager connection is made.
+
+If there is no *opendaylight-iid* entry in the external-ids column and a
+passive OVSDB manager connection is made, then the node-id of the OVSDB
+node in the operational MD-SAL datastore will be constructed using the
+UUID of the Open\_vSwitch table as follows.
+
+::
+
+ "node-id": "ovsdb://uuid/b8dc0bfb-d22b-4938-a2e8-b0084d7bd8c1"
+
+The *opendaylight-iid* entry can be removed from the Open\_vSwitch table
+using the following command.
+
+::
+
+ $ sudo ovs-vsctl remove open_vswitch . external-id "opendaylight-iid"
+
+OVSDB Changes by using OVSDB Southbound Config MD-SAL
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+After the connection has been made to an OVSDB node, you can make
+changes to the OVSDB node by using the OVSDB Southbound Config MD-SAL.
+You can make CRUD operations by using the RESTCONF interface or by a
+plugin using the MD-SAL APIs. The following diagram illustrates the
+high-level flow of events.
+
+.. figure:: ./images/ovsdb-sb-config-crud.jpg
+ :alt: OVSDB Changes by using the Southbound Config MD-SAL
+
+ OVSDB Changes by using the Southbound Config MD-SAL
+
+Step 1
+ A change to the OVSDB Southbound Config MD-SAL is made. Changes
+ include adding or deleting bridges and ports, or setting attributes
+ of OVSDB nodes, bridges or ports.
+
+Step 2
+ The OVSDB Southbound provider receives notification of the changes
+ made to the OVSDB Southbound Config MD-SAL data store.
+
+Step 3
+ As appropriate, OVSDB transactions are constructed and transmitted
+ to the OVSDB node to update the OVSDB database on the OVSDB node.
+
+Step 4
+ The OVSDB node sends update messages to the OVSDB Southbound
+ provider to indicate the changes made to the OVSDB nodes database.
+
+Step 5
+ The OVSDB Southbound provider maps the changes received from the
+ OVSDB node into corresponding changes made to the OVSDB Southbound
+ Operational MD-SAL data store.
+
+Detecting changes in OVSDB coming from outside OpenDaylight
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Changes to the OVSDB nodes database may also occur independently of
+OpenDaylight. OpenDaylight also receives notifications for these events
+and updates the Southbound operational MD-SAL. The following diagram
+illustrates the sequence of events.
+
+.. figure:: ./images/ovsdb-sb-oper-crud.jpg
+ :alt: OVSDB Changes made directly on the OVSDB node
+
+ OVSDB Changes made directly on the OVSDB node
+
+Step 1
+ Changes are made to the OVSDB node outside of OpenDaylight (e.g.
+ ovs-vsctl).
+
+Step 2
+ The OVSDB node constructs update messages to inform OpenDaylight of
+ the changes made to its databases.
+
+Step 3
+ The OVSDB Southbound provider maps the OVSDB database changes to
+ corresponding changes in the OVSDB Southbound operational MD-SAL
+ data store.
+
+OVSDB Model
+^^^^^^^^^^^
+
+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/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/boron/southbound/southbound-api/src/main/yang/ovsdb.yang>`__
+file.
+
+There are three augmentations:
+
+**ovsdb-node-augmentation**
+ This augments the topology node and maps primarily to the
+ Open\_vSwitch table of the OVSDB schema. It contains the following
+ attributes.
+
+ - **connection-info** - holds the local and remote IP address and
+ TCP port numbers for the OpenDaylight to OVSDB node connections
+
+ - **db-version** - version of the OVSDB database
+
+ - **ovs-version** - version of OVS
+
+ - **list managed-node-entry** - a list of references to
+ ovsdb-bridge-augmentation nodes, which are the OVS bridges
+ managed by this OVSDB node
+
+ - **list datapath-type-entry** - a list of the datapath types
+ supported by the OVSDB node (e.g. *system*, *netdev*) - depends
+ on newer OVS versions
+
+ - **list interface-type-entry** - a list of the interface types
+ supported by the OVSDB node (e.g. *internal*, *vxlan*, *gre*,
+ *dpdk*, etc.) - depends on newer OVS verions
+
+ - **list openvswitch-external-ids** - a list of the key/value pairs
+ in the Open\_vSwitch table external\_ids column
+
+ - **list openvswitch-other-config** - a list of the key/value pairs
+ in the Open\_vSwitch table other\_config column
+
+**ovsdb-bridge-augmentation**
+ This augments the topology node and maps to an specific bridge in
+ the OVSDB bridge table of the associated OVSDB node. It contains the
+ following attributes.
+
+ - **bridge-uuid** - UUID of the OVSDB bridge
+
+ - **bridge-name** - name of the OVSDB bridge
+
+ - **bridge-openflow-node-ref** - a reference (instance-identifier)
+ of the OpenFlow node associated with this bridge
+
+ - **list protocol-entry** - the version of OpenFlow protocol to use
+ with the OpenFlow controller
+
+ - **list controller-entry** - a list of controller-uuid and
+ is-connected status of the OpenFlow controllers associated with
+ this bridge
+
+ - **datapath-id** - the datapath ID associated with this bridge on
+ the OVSDB node
+
+ - **datapath-type** - the datapath type of this bridge
+
+ - **fail-mode** - the OVSDB fail mode setting of this bridge
+
+ - **flow-node** - a reference to the flow node corresponding to
+ this bridge
+
+ - **managed-by** - a reference to the ovsdb-node-augmentation
+ (OVSDB node) that is managing this bridge
+
+ - **list bridge-external-ids** - a list of the key/value pairs in
+ the bridge table external\_ids column for this bridge
+
+ - **list bridge-other-configs** - a list of the key/value pairs in
+ the bridge table other\_config column for this bridge
+
+**ovsdb-termination-point-augmentation**
+ This augments the topology termination point model. The OVSDB
+ Southbound MD-SAL uses this model to represent both the OVSDB port
+ and OVSDB interface for a given port/interface in the OVSDB schema.
+ It contains the following attributes.
+
+ - **port-uuid** - UUID of an OVSDB port row
+
+ - **interface-uuid** - UUID of an OVSDB interface row
+
+ - **name** - name of the port
+
+ - **interface-type** - the interface type
+
+ - **list options** - a list of port options
+
+ - **ofport** - the OpenFlow port number of the interface
+
+ - **ofport\_request** - the requested OpenFlow port number for the
+ interface
+
+ - **vlan-tag** - the VLAN tag value
+
+ - **list trunks** - list of VLAN tag values for trunk mode
+
+ - **vlan-mode** - the VLAN mode (e.g. access, native-tagged,
+ native-untagged, trunk)
+
+ - **list port-external-ids** - a list of the key/value pairs in the
+ port table external\_ids column for this port
+
+ - **list interface-external-ids** - a list of the key/value pairs
+ in the interface table external\_ids interface for this interface
+
+ - **list port-other-configs** - a list of the key/value pairs in
+ the port table other\_config column for this port
+
+ - **list interface-other-configs** - a list of the key/value pairs
+ in the interface table other\_config column for this interface
+
+Examples of OVSDB Southbound MD-SAL API
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Connect to an OVSDB Node
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+This example RESTCONF command adds an OVSDB node object to the OVSDB
+Southbound configuration data store and attempts to connect to the OVSDB
+host located at the IP address 10.11.12.1 on TCP port 6640.
+
+::
+
+ POST http://<host>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/
+ Content-Type: application/json
+ {
+ "node": [
+ {
+ "node-id": "ovsdb:HOST1",
+ "connection-info": {
+ "ovsdb:remote-ip": "10.11.12.1",
+ "ovsdb:remote-port": 6640
+ }
+ }
+ ]
+ }
+
+Query the OVSDB Southbound Configuration MD-SAL
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Following on from the previous example, if the OVSDB Southbound
+configuration MD-SAL is queried, the RESTCONF command and the resulting
+reply is similar to the following example.
+
+::
+
+ GET http://<host>:8080/restconf/config/network-topology:network-topology/topology/ovsdb:1/
+ Application/json data in the reply
+ {
+ "topology": [
+ {
+ "topology-id": "ovsdb:1",
+ "node": [
+ {
+ "node-id": "ovsdb:HOST1",
+ "ovsdb:connection-info": {
+ "remote-port": 6640,
+ "remote-ip": "10.11.12.1"
+ }
+ }
+ ]
+ }
+ ]
+ }
+
+Reference Documentation
+~~~~~~~~~~~~~~~~~~~~~~~
+
+`Openvswitch
+schema <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf>`__
+
+OVSDB Hardware VTEP Developer Guide
+-----------------------------------
+
+Overview
+~~~~~~~~
+
+TBD
+
+OVSDB Hardware VTEP Architecture
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TBD
+++ /dev/null
-OVSDB NetVirt
-=============
-
-OVSDB Integration
------------------
-
-The Open vSwitch database (OVSDB) Southbound Plugin component for
-OpenDaylight implements the OVSDB `RFC
-7047 <https://tools.ietf.org/html/rfc7047>`__ management protocol that
-allows the southbound configuration of switches that support OVSDB. The
-component comprises a library and a plugin. The OVSDB protocol uses
-JSON-RPC calls to manipulate a physical or virtual switch that supports
-OVSDB. Many vendors support OVSDB on various hardware platforms. The
-OpenDaylight controller uses the library project to interact with an OVS
-instance.
-
-.. note::
-
- Read the OVSDB User Guide before you begin development.
-
-OpenDaylight OVSDB integration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The OpenStack integration architecture uses the following technologies:
-
-- `RFC 7047 <https://tools.ietf.org/html/rfc7047>`__ - The Open vSwitch
- Database Management Protocol
-
-- `OpenFlow
- v1.3 <http://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.3.4.pdf>`__
-
-- `OpenStack Neutron ML2
- Plugin <https://wiki.openstack.org/wiki/Neutron/ML2>`__
-
-OpenDaylight Mechanism Driver for Openstack Neutron ML2
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This code is a part of OpenStack and is available at:
-https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mechanism_odl.py
-
-The ODL neutron driver implementation can be found at:
-https://github.com/openstack/networking-odl
-
-To make changes to this code, please read about `Neutron
-Development <https://wiki.openstack.org/wiki/NeutronDevelopment>`__.
-
-Before submitting the code, run the following tests:
-
-::
-
- tox -e py27
- tox -e pep8
-
-Importing the code in to Eclipse or IntelliJ
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To import code, look at either of the following pages:
-
-- `Getting started with
- Eclipse <https://wiki.opendaylight.org/view/Eclipse_Setup>`__
-
-- `Developing with
- Intellij <https://wiki.opendaylight.org/view/OpenDaylight_Controller:Developing_With_Intellij>`__
-
-.. figure:: ./images/OVSDB_Eclipse.png
- :alt: Avoid conflicting project names
-
- Avoid conflicting project names
-
-- To ensure that a project in Eclipse does not have a conflicting name
- in the workspace, select Advanced > Name Template >
- [groupId].[artifactId] when importing the project.
-
-Browsing the code
-^^^^^^^^^^^^^^^^^
-
-The code is mirrored to
-`GitHub <https://github.com/opendaylight/ovsdb>`__ to make reading code
-online easier.
-
-Source code organization
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-The OVSDB project generates the following Karaf modules:
-
-- ovsdb.karaf — all openstack netvirt related artifacts
-
-- ovsdb.library-karaf — the OVSDB library reference implementation
-
-- ovsdb.openstack.net-virt-sfc-karaf — OpenFlow service function
- chaining
-
-- ovsdb.hwvtepsouthbound-karaf — the hw\_vtep schema southbound plugin
-
-- ovsdb.southbound-karaf - the Open\_vSwitch schema plugin
-
-Following are a brief descriptions on directories you will find a the
-root ovsdb/ directory:
-
-- *commons* contains the parent POM file for Maven project which is
- used to get consistency of settings across the project.
-
-- *features* contains all the Karaf related feature files.
-
-- *hwvtepsouthbound* contains the hw\_vtep southbound plugin.
-
-- *karaf* contains the ovsdb library and southbound and OpenStack
- bundles for the OpenStack integration.
-
-- *library* contains a schema-independent library that is a reference
- implementation for RFC 7047.
-
-- *openstack* contains the northbound handlers for Neutron used by
- OVSDB, as well as their providers. The NetVirt SFC implementation is
- also located here.
-
-- *ovsdb-ui* contains the DLUX implementation for displaying network
- virtualization.
-
-- *resources* contains useful scripts, how-tos, demos and other
- resources.
-
-- *schemas* contains the OVSDB schemas that are implemented in
- OpenDaylight.
-
-- *southbound* contains the plugin for converting from the OVSDB
- protocol to MD-SAL and vice-versa.
-
-- *utils* contains a collection of utilities for using the OpenFlow
- plugin, southbound, Neutron and other helper methods.
-
-Building and running OVSDB
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-| **Prerequisites**
-
-- JDK 1.7+
-
-- Maven 3+
-
-Building a Karaf feature and deploying it in an OpenDaylight Karaf distribution
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-1. From the root ovsdb/ directory, run **mvn clean install**.
-
-2. Unzip the karaf-<VERSION\_NUMBER>-SNAPSHOT.zip file created from step
- 1 in the directory ovsdb/karaf/target/:
-
-::
-
- unzip karaf-<VERSION_NUMBER>-SNAPSHOT.zip
-
-Downloading OVSDB’s Karaf distribution
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Instead of building, you can download the latest OVSDB distribution from
-the Nexus server. The link for that is:
-
-::
-
- https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/ovsdb/karaf/1.3.0-SNAPSHOT/
-
-Running Karaf feature from OVSDB’s Karaf distribution
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-1. Start ODL, from the unzipped directory
-
- ::
-
- bin/karaf
-
-2. 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:
-
- ::
-
- feature:install odl-ovsdb-openstack
-
-Sample output from the Karaf console
-''''''''''''''''''''''''''''''''''''
-
-::
-
- opendaylight-user@root>feature:list | grep -i ovsdb
- opendaylight-user@root>feature:list -i | grep ovsdb
- odl-ovsdb-southbound-api | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: api
- odl-ovsdb-southbound-impl | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: impl
- odl-ovsdb-southbound-impl-rest | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: impl :: REST
- odl-ovsdb-southbound-impl-ui | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: impl :: UI
- odl-ovsdb-library | 1.2.1-SNAPSHOT | x | odl-ovsdb-library-1.2.1-SNAPSHOT | OpenDaylight :: library
- odl-ovsdb-openstack | 1.2.1-SNAPSHOT | x | ovsdb-1.2.1-SNAPSHOT | OpenDaylight :: OVSDB :: OpenStack Network Virtual
-
-Testing patches
-^^^^^^^^^^^^^^^
-
-It is recommended that you test your patches locally before submission.
-
-Neutron integration
-^^^^^^^^^^^^^^^^^^^
-
-To test patches to the Neutron integration, you need a `Multi-Node
-Devstack Setup <http://devstack.org/guides/multinode-lab.html>`__. The
-\`\`resources\`\` folder contains sample \`\`local.conf\`\` files.
-
-Open vSwitch
-^^^^^^^^^^^^
-
-To test patches to the library, you will need a working `Open
-vSwitch <http://openvswitch.org/>`__. Packages are available for most
-Linux distributions. If you would like to run multiple versions of Open
-vSwitch for testing you can use
-`docker-ovs <https://github.com/dave-tucker/docker-ovs>`__ to run Open
-vSwitch in `Docker <https://www.docker.com/>`__ containers.
-
-Mininet
-^^^^^^^
-
-`Mininet <http://mininet.org/>`__ is another useful resource for testing
-patches. Mininet creates multiple Open vSwitches connected in a
-configurable topology.
-
-Vagrant
-^^^^^^^
-
-The Vagrant file in the root of the OVSDB source code provides an easy
-way to create VMs for tests.
-
-- To install Vagrant on your machine, follow the steps at: `Installing
- Vagrant <https://docs.vagrantup.com/v2/installation/>`__.
-
-**Testing with Devstack**
-
-1. Start the controller.
-
- ::
-
- vagrant up devstack-control
- vagrant ssh devstack-control
- cd devstack
- ./stack.sh
-
-2. Run the following:
-
- ::
-
- vagrant up devstack-compute-1
- vagrant ssh devstack-compute-1
- cd devstack
- ./stack.sh
-
-3. To start testing, create a new VM.
-
- ::
-
- nova boot --flavor m1.tiny --image $(nova image-list | grep 'cirros-0.3.1-x86_64-uec\s' | awk '{print $2}') --nic net-id=$(neutron net-list | grep private | awk '{print $2}') test
-
- To create three, use the following:
-
- ::
-
- nova boot --flavor m1.tiny --image $(nova image-list | grep 'cirros-0.3.1-x86_64-uec\s' | awk '{print $2}') --nic net-id=$(neutron net-list | grep private | awk '{print $2}') --num-instances 3 test
-
-**To get a mininet installation for testing:.**
-
-::
-
- vagrant up mininet
- vagrant ssh mininet
-
-1. Use the following to clean up when finished:
-
-::
-
- vagrant destroy
-
-OVSDB integration design
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Resources
-^^^^^^^^^
-
-| See the following:
-
-- `Network
- Heresy <http://networkheresy.com/2012/09/15/remembering-the-management-plane/>`__
-
-| See the OVSDB YouTube Channel for getting started videos and other
- tutorials:
-
-- `ODL OVSDB Youtube
- Channel <http://www.youtube.com/channel/UCMYntfZ255XGgYFrxCNcAzA>`__
-
-- `Mininet OVSDB
- Tutorial <https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial>`__
-
-- `OVSDB Getting
- Started <https://wiki.opendaylight.org/view/OVSDB_Integration:Main#Getting_Started_with_OpenDaylight_OVSDB_Plugin_Network_Virtualization>`__
-
-OpenDaylight OVSDB southbound plugin architecture and design
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-OpenVSwitch (OVS) is generally accepted as the unofficial standard for
-Virtual Switching in the Open hypervisor based solutions. Every other
-Virtual Switch implementation, properietery or otherwise, uses OVS in
-some form. For information on OVS, see `Open
-vSwitch <http://openvswitch.org/>`__.
-
-In Software Defined Networking (SDN), controllers and applications
-interact using two channels: OpenFlow and OVSDB. OpenFlow addresses the
-forwarding-side of the OVS functionality. OVSDB, on the other hand,
-addresses the management-plane. A simple and concise overview of Open
-Virtual Switch Database(OVSDB) is available at:
-http://networkstatic.net/getting-started-ovsdb/
-
-Overview of OpenDaylight Controller architecture
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The OpenDaylight controller platform is designed as a highly modular and
-plugin based middleware that serves various network applications in a
-variety of use-cases. The modularity is achieved through the Java OSGi
-framework. The controller consists of many Java OSGi bundles that work
-together to provide the required controller functionalities.
-
-| The bundles can be placed in the following broad categories:
-
-- Network Service Functional Modules (Examples: Topology Manager,
- Inventory Manager, Forwarding Rules Manager,and others)
-
-- NorthBound API Modules (Examples: Topology APIs, Bridge Domain APIs,
- Neutron APIs, Connection Manager APIs, and others)
-
-- Service Abstraction Layer(SAL)- (Inventory Services, DataPath
- Services, Topology Services, Network Config, and others)
-
-- SouthBound Plugins (OpenFlow Plugin, OVSDB Plugin, OpenDove Plugin,
- and others)
-
-- Application Modules (Simple Forwarding, Load Balancer)
-
-Each layer of the Controller architecture performs specified tasks, and
-hence aids in modularity. While the Northbound API layer addresses all
-the REST-Based application needs, the SAL layer takes care of
-abstracting the SouthBound plugin protocol specifics from the Network
-Service functions.
-
-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
-OpenFlow protocol with the OVS element, the OVSDB plugin will use OVSDB
-schema over JSON-RPC transport.
-
-OVSDB southbound plugin
-~~~~~~~~~~~~~~~~~~~~~~~
-
-| The `Open vSwitch Database Management
- Protocol-draft-02 <http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02>`__
- and `Open vSwitch
- Manual <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf>`__ provide
- theoretical information about OVSDB. The OVSDB protocol draft is
- generic enough to lay the groundwork on Wire Protocol and Database
- Operations, and the OVS Manual currently covers 13 tables leaving
- space for future OVS expansion, and vendor expansions on proprietary
- implementations. The OVSDB Protocol is a database records transport
- protocol using JSON RPC1.0. For information on the protocol structure,
- see `Getting Started with
- OVSDB <http://networkstatic.net/getting-started-ovsdb/>`__. The
- OpenDaylight OVSDB southbound plugin consists of one or more OSGi
- bundles addressing the following services or functionalities:
-
-- Connection Service - Based on Netty
-
-- Network Configuration Service
-
-- Bidirectional JSON-RPC Library
-
-- OVSDB Schema definitions and Object mappers
-
-- Overlay Tunnel management
-
-- OVSDB to OpenFlow plugin mapping service
-
-- Inventory Service
-
-Connection service
-~~~~~~~~~~~~~~~~~~
-
-| One of the primary services that most southbound plugins provide in
- 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:
-
-- Connection to a specified element given IP-address, L4-port, and
- other connectivity options (such as authentication,…)
-
-- Disconnection from an element
-
-- Handling Cluster Mode change notifications to support the
- OpenDaylight Clustering/High-Availability feature
-
-Network Configuration Service
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-| The goal of the OpenDaylight Network Configuration services is to
- provide complete management plane solutions needed to successfully
- install, configure, and deploy the various SDN based network services.
- These are generic services which can be implemented in part or full by
- any south-bound protocol plugin. The south-bound plugins can be either
- of the following:
-
-- The new network virtualization protocol plugins such as OVSDB
- JSON-RPC
-
-- The traditional management protocols such as SNMP or any others in
- the middle.
-
-The above definition, and more information on Network Configuration
-Services, is available at :
-https://wiki.opendaylight.org/view/OpenDaylight_Controller:NetworkConfigurationServices
-
-Bidirectional JSON-RPC library
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The OVSDB plugin implements a Bidirectional JSON-RPC library. It is easy
-to design the library as a module that manages the Netty connection
-towards the Element.
-
-| The main responsibilities of this Library are:
-
-- Demarshal and marshal JSON Strings to JSON objects
-
-- Demarshal and marshal JSON Strings from and to the Network Element.
-
-OVSDB Schema definitions and Object mappers
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The OVSDB Schema definitions and Object Mapping layer sits above the
-JSON-RPC library. It maps the generic JSON objects to OVSDB schema POJOs
-(Plain Old Java Object) and vice-versa. This layer mostly provides the
-Java Object definition for the corresponding OVSDB schema (13 of them)
-and also will provide much more friendly API abstractions on top of
-these object data. This helps in hiding the JSON semantics from the
-functional modules such as Configuration Service and Tunnel management.
-
-| On the demarshaling side the mapping logic differentiates the Request
- and Response messages as follows :
-
-- Request messages are mapped by its "method"
-
-- | Response messages are mapped by their IDs which were originally
- populated by the Request message. The JSON semantics of these OVSDB
- schema is quite complex. The following figures summarize two of the
- end-to-end scenarios:
-
-.. figure:: ./images/ConfigurationService-example1.png
- :alt: End-to-end handling of a Create Bridge request
-
- End-to-end handling of a Create Bridge request
-
-.. figure:: ./images/MonitorResponse.png
- :alt: End-to-end handling of a monitor response
-
- End-to-end handling of a monitor response
-
-Overlay tunnel management
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Network Virtualization using OVS is achieved through Overlay Tunnels.
-The actual Type of the Tunnel may be GRE, VXLAN, or STT. The differences
-in the encapsulation and configuration decide the tunnel types.
-Establishing a tunnel using configuration service requires just the
-sending of OVSDB messages towards the ovsdb-server. However, the scaling
-issues that would arise on the state management at the data-plane (using
-OpenFlow) can get challenging. Also, this module can assist in various
-optimizations in the presence of Gateways. It can also help in providing
-Service guarantees for the VMs using these overlays with the help of
-underlay orchestration.
-
-OVSDB to OpenFlow plugin mapping service
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-| The connect() of the ConnectionService would result in a Node that
- represents an ovsdb-server. The CreateBridgeDomain() Configuration on
- the above Node would result in creating an OVS bridge. This OVS Bridge
- is an OpenFlow Agent for the OpenDaylight OpenFlow plugin with its own
- Node represented as (example) OF\|xxxx.yyyy.zzzz. Without any help
- from the OVSDB plugin, the Node Mapping Service of the Controller
- platform would not be able to map the following:
-
-::
-
- {OVSDB_NODE + BRIDGE_IDENTFIER} <---> {OF_NODE}.
-
-Without such mapping, it would be extremely difficult for the
-applications to manage and maintain such nodes. This Mapping Service
-provided by the OVSDB plugin would essentially help in providing more
-value added services to the orchestration layers that sit atop the
-Northbound APIs (such as OpenStack).
-
-OpenDaylight OVSDB Developer Getting Started Video Series
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The video series were started to help developers bootstrap into OVSDB
-development.
-
-- `OpenDaylight OVSDB Developer Getting
- Started <http://www.youtube.com/watch?v=ieB645oCIPs>`__
-
-- `OpenDaylight OVSDB Developer Getting Started - Northbound API
- Usage <http://www.youtube.com/watch?v=xgevyaQ12cg>`__
-
-- `OpenDaylight OVSDB Developer Getting Started - Java
- APIs <http://www.youtube.com/watch?v=xgevyaQ12cg>`__
-
-- `OpenDaylight OVSDB Developer Getting Started - OpenStack Integration
- OpenFlow v1.0 <http://www.youtube.com/watch?v=NayuY6J-AMA>`__
-
-Other developer tutorials
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-- `OVSDB NetVirt
- Tutorial <https://docs.google.com/presentation/d/1KIuNDuUJGGEV37Zk9yzx9OSnWExt4iD2Z7afycFLf_I/edit?usp=sharing>`__
-
-- `Youtube of OVSDB NetVirt
- tutorial <https://www.youtube.com/watch?v=2axNKHvt5MY&list=PL8F5jrwEpGAiJG252ShQudYeodGSsks2l&index=43>`__
-
-- `OVSDB OpenFlow v1.3 Neutron ML2
- Integration <https://wiki.opendaylight.org/view/OVSDB:OVSDB_OpenStack_Guide>`__
-
-- `Open vSwitch Database Table Explanations and Simple Jackson
- Tutorial <http://networkstatic.net/getting-started-ovsdb/>`__
-
-OVSDB integration: New features
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Schema independent library
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The OVS connection is a node which can have multiple databases. Each
-database is represented by a schema. A single connection can have
-multiple schemas. OSVDB supports multiple schemas. Currently, these are
-two schemas available in the OVSDB, but there is no restriction on the
-number of schemas. Owing to the Northbound v3 API, no code changes in
-ODL are needed for supporting additional schemas.
-
-| Schemas:
-
-- openvswitch : Schema wrapper that represents
- http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf
-
-- hardwarevtep: Schema wrapper that represents
- http://openvswitch.org/docs/vtep.5.pdf
-
-Port security
-^^^^^^^^^^^^^
-
-Based on the fact that security rules can be obtained from a port
-object, OVSDB can apply Open Flow rules. These rules will match on what
-types of traffic the Openstack tenant VM is allowed to use.
-
-Support for security groups is very experimental. There are limitations
-in determining the state of flows in the Open vSwitch. See `Open vSwitch
-and the Intelligent
-Edge <http://%20https//www.youtube.com/watch?v=DSop2uLJZS8>`__ from
-Justin Petit for a deep dive into the challenges we faced creating a
-flow based port security implementation. The current set of rules that
-will be installed only supports filtering of the TCP protocol. This is
-because via a Nicira TCP\_Flag read we can match on a flows TCP\_SYN
-flag, and permit or deny the flow based on the Neutron port security
-rules. If rules are requested for ICMP and UDP, they are ignored until
-greater visibility from the Linux kernel is available as outlined in the
-OpenStack presentation mentioned earlier.
-
-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.
-
-Through the ML2 interface, Neutron security rules are available in the
-port object, following this scope: Neutron Port → Security Group →
-Security Rules.
-
-The current rules are applied on the basis of the following attributes:
-ingress/egress, tcp protocol, port range, and prefix.
-
-OpenStack workflow
-''''''''''''''''''
-
-1. Create a stack.
-
-2. Add the network and subnet.
-
-3. Add the Security Group and Rules.
-
- .. note::
-
- This is no different than what users normally do in regular
- OpenStack deployments.
-
- ::
-
- neutron security-group-create group1 --description "Group 1"
- neutron security-group-list
- neutron security-group-rule-create --direction ingress --protocol tcp group1
-
-4. Start the tenant, specifying the security-group.
-
- ::
-
- nova boot --flavor m1.tiny \
- --image $(nova image-list | grep 'cirros-0.3.1-x86_64-uec\s' | awk '{print $2}') \
- --nic net-id=$(neutron net-list | grep 'vxlan2' | awk '{print $2}') vxlan2 \
- --security-groups group1
-
-Examples: Rules supported
-'''''''''''''''''''''''''
-
-::
-
- neutron security-group-create group2 --description "Group 2"
- neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 54 group2
- neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 80 group2
- neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 1633 group2
- neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 22 group2
-
-::
-
- neutron security-group-create group3 --description "Group 3"
- neutron security-group-rule-create --direction ingress --protocol tcp --remote-ip-prefix 10.200.0.0/16 group3
-
-::
-
- neutron security-group-create group4 --description "Group 4"
- neutron security-group-rule-create --direction ingress --remote-ip-prefix 172.24.0.0/16 group4
-
-::
-
- neutron security-group-create group5 --description "Group 5"
- neutron security-group-rule-create --direction ingress --protocol tcp group5
- neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 54 group5
- neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 80 group5
- neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 1633 group5
- neutron security-group-rule-create --direction ingress --protocol tcp --port-range-min 22 group5
-
-::
-
- neutron security-group-create group6 --description "Group 6"
- neutron security-group-rule-create --direction ingress --protocol tcp --remote-ip-prefix 0.0.0.0/0 group6
-
-::
-
- neutron security-group-create group7 --description "Group 7"
- neutron security-group-rule-create --direction egress --protocol tcp --port-range-min 443 --remote-ip-prefix 172.16.240.128/25 group7
-
-**Reference
-gist**: `Gist <https://gist.github.com/anonymous/1543a410d57f491352c8>`__
-
-Security group rules supported in ODL
-'''''''''''''''''''''''''''''''''''''
-
-The following rules formats are supported in the current implementation.
-The direction (ingress/egress) is always expected. Rules are implemented
-such that tcp-syn packets that do not satisfy the rules are dropped.
-
-+--------------------------+--------------------------+--------------------------+
-| Proto | Port | IP Prefix |
-+==========================+==========================+==========================+
-| TCP | x | x |
-+--------------------------+--------------------------+--------------------------+
-| Any | Any | x |
-+--------------------------+--------------------------+--------------------------+
-| TCP | x | Any |
-+--------------------------+--------------------------+--------------------------+
-| TCP | Any | Any |
-+--------------------------+--------------------------+--------------------------+
-
-Limitations
-'''''''''''
-
-- Soon, conntrack will be supported by OVS. Until then, TCP flags are
- used as way of checking for connection state. Specifically, that is
- done by matching on the TCP-SYN flag.
-
-- The param *--port-range-max* in *security-group-rule-create* is not
- used until the implementation uses contrack.
-
-- No UDP/ICMP specific match support is provided.
-
-- No IPv6 support is provided.
-
-L3 forwarding
-^^^^^^^^^^^^^
-
-OVSDB extends support for the usage of an ODL-Neutron-driver so that
-OVSDB can configure OF 1.3 rules to route IPv4 packets. The driver
-eliminates the need for the router of the L3 Agent. In order to
-accomplish that, OVS 2.1 or a newer version is required. OVSDB also
-supports inbound/outbound NAT, floating IPs.
-
-Starting OVSDB and OpenStack
-''''''''''''''''''''''''''''
-
-1. Build or download OVSDB distribution, as mentioned in `building a
- Karaf feature section <#ovsdbBuildSteps>`__.
-
-2. `Install
- Vagrant <http://docs.vagrantup.com/v2/installation/index.html>`__.
-
-3. Enable the L3 Forwarding feature:
-
- ::
-
- echo 'ovsdb.l3.fwd.enabled=yes' >> ./opendaylight/configuration/config.ini
- echo 'ovsdb.l3gateway.mac=${GATEWAY_MAC}' >> ./configuration/config.ini
-
-4. Run the following commands to get the odl neutron drivers:
-
- ::
-
- git clone https://github.com/dave-tucker/odl-neutron-drivers.git
- cd odl-neutron-drivers
- vagrant up devstack-control devstack-compute-1
-
-5. Use ssh to go to the control node, and clone odl-neutron-drivers
- again:
-
- ::
-
- vagrant ssh devstack-control
- git clone https://github.com/dave-tucker/odl-neutron-drivers.git
- cd odl-neutron-drivers
- sudo python setup.py install
- *leave this shell open*
-
-6. Start odl, as mentioned in `running Karaf feature
- section <#ovsdbStartingOdl>`__.
-
-7. To see processing of neutron event related to L3, do this from
- prompt:
-
- ::
-
- log:set debug org.opendaylight.ovsdb.openstack.netvirt.impl.NeutronL3Adapter
-
-8. From shell, do one of the following: open on ssh into control node or
- vagrant ssh devstack-control.
-
- ::
-
- cd ~/devstack && ./stack.sh
-
-9. From a new shell in the host system, run the following:
-
- ::
-
- cd odl-neutron-drivers
- vagrant ssh devstack-compute-1
- cd ~/devstack && ./stack.sh
-
-OpenStack workflow
-''''''''''''''''''
-
-.. figure:: ./images/L3FwdSample.png
- :alt: Sample workflow
-
- Sample workflow
-
-Use the following steps to set up a workflow like the one shown in
-figure above.
-
-1. Set up authentication. From shell on stack control or vagrant ssh
- devstack-control:
-
- ::
-
- source openrc admin admin
-
- rm -f id_rsa_demo* ; ssh-keygen -t rsa -b 2048 -N -f id_rsa_demo
- nova keypair-add --pub-key id_rsa_demo.pub demo_key
- # nova keypair-list
-
-2. Create two networks and two subnets.
-
- ::
-
- neutron net-create net1 --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
- --provider:network_type gre --provider:segmentation_id 555
-
- neutron subnet-create --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
- net1 10.0.0.0/16 --name subnet1 --dns-nameserver 8.8.8.8
-
- neutron net-create net2 --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
- --provider:network_type gre --provider:segmentation_id 556
-
- neutron subnet-create --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}') \
- net2 20.0.0.0/16 --name subnet2 --dns-nameserver 8.8.8.8
-
-3. Create a router, and add an interface to each of the two subnets.
-
- ::
-
- neutron router-create demorouter --tenant-id $(keystone tenant-list | grep '\s'admin | awk '{print $2}')
- neutron router-interface-add demorouter subnet1
- neutron router-interface-add demorouter subnet2
- # neutron router-port-list demorouter
-
-4. Create two tenant instances.
-
- ::
-
- nova boot --poll --flavor m1.nano --image $(nova image-list | grep 'cirros-0.3.2-x86_64-uec\s' | awk '{print $2}') \
- --nic net-id=$(neutron net-list | grep -w net1 | awk '{print $2}'),v4-fixed-ip=10.0.0.10 \
- --availability-zone nova:devstack-control \
- --key-name demo_key host10
-
- nova boot --poll --flavor m1.nano --image $(nova image-list | grep 'cirros-0.3.2-x86_64-uec\s' | awk '{print $2}') \
- --nic net-id=$(neutron net-list | grep -w net2 | awk '{print $2}'),v4-fixed-ip=20.0.0.20 \
- --availability-zone nova:devstack-compute-1 \
- --key-name demo_key host20
-
-Limitations
-'''''''''''
-
-- To use this feature, you need OVS 2.1 or newer version.
-
-- Owing to OF limitations, icmp responses due to routing failures, like
- ttl expired or host unreacheable, are not generated.
-
-- The MAC address of the default route is not automatically mapped. In
- order to route to L3 destinations outside the networks of the tenant,
- the manual configuration of the default route is necessary. To
- provide the MAC address of the default route, use ovsdb.l3gateway.mac
- in file configuration/config.ini ;
-
-- This feature is Tech preview, which depends on later versions of
- OpenStack to be used without the provided neutron-driver.
-
-- No IPv6 support is provided.
-
-| **More information on L3 forwarding**:
-
-- odl-neutron-driver:
- https://github.com/dave-tucker/odl-neutron-drivers
-
-- OF rules example:
- http://dtucker.co.uk/hack/building-a-router-with-openvswitch.html
-
-LBaaS
-^^^^^
-
-Load-Balancing-as-a-Service (LBaaS) creates an Open vSwitch powered
-L3-L4 stateless load-balancer in a virtualized network environment so
-that individual TCP connections destined to a designated virtual IP
-(VIP) are sent to the appropriate servers (that is to say, serving app
-VMs). The load-balancer works in a session-preserving, proactive manner
-without involving the controller during flow setup.
-
-A Neutron northbound interface is provided to create a VIP which will
-map to a pool of servers (that is to say, members) within a subnet. The
-pools consist of members identified by an IP address. The goal is to
-closely match the API to the OpenStack LBaaS v2 API:
-http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext.html.
-
-Creating an OpenStack workflow
-''''''''''''''''''''''''''''''
-
-1. Create a subnet.
-
-2. Create a floating VIP *A* that maps to a private VIP *B*.
-
-3. Create a Loadbalancer pool *X*.
-
- ::
-
- neutron lb-pool-create --name http-pool --lb-method ROUND_ROBIN --protocol HTTP --subnet-id XYZ
-
-4. Create a Loadbalancer pool member *Y* and associate with pool *X*.
-
- ::
-
- neutron lb-member-create --address 10.0.0.10 --protocol-port 80 http-pool
- neutron lb-member-create --address 10.0.0.11 --protocol-port 80 http-pool
- neutron lb-member-create --address 10.0.0.12 --protocol-port 80 http-pool
- neutron lb-member-create --address 10.0.0.13 --protocol-port 80 http-pool
-
-5. Create a Loadbalancer instance *Z*, and associate pool *X* and VIP
- *B* with it.
-
- ::
-
- neutron lb-vip-create --name http-vip --protocol-port 80 --protocol HTTP --subnet-id XYZ http-pool
-
-Implementation
-''''''''''''''
-
-The current implementation of the proactive stateless load-balancer was
-made using "multipath" action in the Open vSwitch. The "multipath"
-action takes a max\_link parameter value (which is same as the number of
-pool members) as input, and performs a hash of the fields to get a value
-between (0, max\_link). The value of the hash is used as an index to
-select a pool member to handle that session.
-
-Open vSwitch rules
-^^^^^^^^^^^^^^^^^^
-
-Assuming that table=20 contains all the rules to forward the traffic
-destined for a specific destination MAC address, the following are the
-rules needed to be programmed in the LBaaS service table=10. The
-programmed rules makes the translation from the VIP to a different pool
-member for every session.
-
-- Proactive forward rules:
-
- ::
-
- sudo ovs-ofctl -O OpenFlow13 add-flow s1 "table=10,reg0=0,ip,nw_dst=10.0.0.5,actions=load:0x1->NXM_NX_REG0[[]],multipath(symmetric_l4, 1024, modulo_n, 4, 0, NXM_NX_REG1[0..12]),resubmit(,10)"
- sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=0,actions=mod_dl_dst:00:00:00:00:00:10,mod_nw_dst:10.0.0.10,goto_table:20
- sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=1,actions=mod_dl_dst:00:00:00:00:00:11,mod_nw_dst:10.0.0.11,goto_table:20
- sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=2,actions=mod_dl_dst:00:00:00:00:00:12,mod_nw_dst:10.0.0.12,goto_table:20
- sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,reg0=1,nw_dst=10.0.0.5,ip,reg1=3,actions=mod_dl_dst:00:00:00:00:00:13,mod_nw_dst:10.0.0.13,goto_table:20
-
-- Proactive reverse rules:
-
- ::
-
- sudo ovs-ofctl -O OpenFlow13 add-flow s1 table=10,ip,tcp,tp_src=80,actions=mod_dl_src:00:00:00:00:00:05,mod_nw_src:10.0.0.5,goto_table:20
-
-OVSDB project code
-''''''''''''''''''
-
-The current implementation handles all neutron calls in the
-net-virt/LBaaSHandler.java code, and makes calls to the
-net-virt-providers/LoadBalancerService to program appropriate flowmods.
-The rules are updated whenever there is a change in the Neutron LBaaS
-settings. There is no cache of state kept in the net-virt or providers.
-
-Limitations
-'''''''''''
-
-Owing to the inflexibility of the multipath action, the existing LBaaS
-implementation comes with some limitations:
-
-- TCP, HTTP or HTTPS are supported protocols for the pool. (Caution:
- You can lose access to the members if you assign {Proto:TCP, Port:22}
- to LB)
-
-- Member weights are ignored.
-
-- The update of an LB instance is done as a delete + add, and not an
- actual delta.
-
-- The update of an LB member is not supported (because weights are
- ignored).
-
-- Deletion of an LB member leads to the reprogramming of the LB on all
- nodes (because of the way multipath does link hash).
-
-- There is only a single LB instance per subnet because the pool-id is
- not reported in the create load-balancer call.
-
-OVSDB Library Developer Guide
------------------------------
-
-Overview
-~~~~~~~~
-
-The OVSDB library manages the Netty connections to network nodes and
-handles bidirectional JSON-RPC messages. It not only provides OVSDB
-protocol functionality to OpenDaylight OVSDB plugin but also can be used
-as standalone JAVA library for OVSDB protocol.
-
-The main responsibilities of OVSDB library include:
-
-- Manage connections to peers
-
-- Marshal and unmarshal JSON Strings to JSON objects.
-
-- Marshal and unmarshal JSON Strings from and to the Network Element.
-
-Connection Service
-~~~~~~~~~~~~~~~~~~
-
-The OVSDB library provides connection management through the
-OvsdbConnection interface. The OvsdbConnection interface provides OVSDB
-connection management APIs which include both active and passive
-connections. From the library perspective, active OVSDB connections are
-initiated from the controller to OVS nodes while passive OVSDB
-connections are initiated from OVS nodes to the controller. In the
-active connection scenario an application needs to provide the IP
-address and listening port of OVS nodes to the library management API.
-On the other hand, the library management API only requires the info of
-the controller listening port in the passive connection scenario.
-
-For a passive connection scenario, the library also provides a
-connection event listener through the OvsdbConnectionListener interface.
-The listener interface has connected() and disconnected() methods to
-notify an application when a new passive connection is established or an
-existing connection is terminated.
-
-SSL Connection
-~~~~~~~~~~~~~~
-
-In addition to a regular TCP connection, the OvsdbConnection interface
-also provides a connection management API for an SSL connection. To
-start an OVSDB connection with SSL, an application will need to provide
-a Java SSLContext object to the management API. There are different ways
-to create a Java SSLContext, but in most cases a Java KeyStore with
-certificate and private key provided by the application is required.
-Detailed steps about how to create a Java SSLContext is out of the scope
-of this document and can be found in the Java documentation for `JAVA
-Class SSlContext <http://goo.gl/5svszT>`__.
-
-In the active connection scenario, the library uses the given SSLContext
-to create a Java SSLEngine and configures the SSL engine with the client
-mode for SSL handshaking. Normally clients are not required to
-authenticate themselves.
-
-In the passive connection scenario, the library uses the given
-SSLContext to create a Java SSLEngine which will operate in server mode
-for SSL handshaking. For security reasons, the SSLv3 protocol and some
-cipher suites are disabled. Currently the OVSDB server only supports the
-TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA cipher suite and the following
-protocols: SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2.
-
-The SSL engine is also configured to operate on two-way authentication
-mode for passive connection scenarios, i.e., the OVSDB server
-(controller) will authenticate clients (OVS nodes) and clients (OVS
-nodes) are also required to authenticate the server (controller). In the
-two-way authentication mode, an application should keep a trust manager
-to store the certificates of trusted clients and initialize a Java
-SSLContext with this trust manager. Thus during the SSL handshaking
-process the OVSDB server (controller) can use the trust manager to
-verify clients and only accept connection requests from trusted clients.
-On the other hand, users should also configure OVS nodes to authenticate
-the controller. Open vSwitch already supports this functionality in the
-ovsdb-server command with option ``--ca-cert=cacert.pem`` and
-``--bootstrap-ca-cert=cacert.pem``. On the OVS node, a user can use the
-option ``--ca-cert=cacert.pem`` to specify a controller certificate
-directly and the node will only allow connections to the controller with
-the specified certificate. If the OVS node runs ovsdb-server with option
-``--bootstrap-ca-cert=cacert.pem``, it will authenticate the controller
-with the specified certificate cacert.pem. If the certificate file
-doesn’t exist, it will attempt to obtain a certificate from the peer
-(controller) on its first SSL connection and save it to the named PEM
-file ``cacert.pem``. Here is an example of ovsdb-server with
-``--bootstrap-ca-cert=cacert.pem`` option:
-
-``ovsdb-server --pidfile --detach --log-file --remote punix:/var/run/openvswitch/db.sock --remote=db:hardware_vtep,Global,managers --private-key=/etc/openvswitch/ovsclient-privkey.pem -- certificate=/etc/openvswitch/ovsclient-cert.pem --bootstrap-ca-cert=/etc/openvswitch/vswitchd.cacert``
-
-OVSDB protocol transactions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The OVSDB protocol defines the RPC transaction methods in RFC 7047. The
-following RPC methods are supported in OVSDB protocol:
-
-- List databases
-
-- Get schema
-
-- Transact
-
-- Cancel
-
-- Monitor
-
-- Update notification
-
-- Monitor cancellation
-
-- Lock operations
-
-- Locked notification
-
-- Stolen notification
-
-- Echo
-
-According to RFC 7047, an OVSDB server must implement all methods, and
-an OVSDB client is only required to implement the "Echo" method and
-otherwise free to implement whichever methods suit its needs. However,
-the OVSDB library currently doesn’t support all RPC methods. For the
-"Echo" method, the library can handle "Echo" messages from a peer and
-send a JSON response message back, but the library doesn’t support
-actively sending an "Echo" JSON request to a peer. Other unsupported RPC
-methods are listed below:
-
-- Cancel
-
-- Lock operations
-
-- Locked notification
-
-- Stolen notification
-
-In the OVSDB library the RPC methods are defined in the Java interface
-OvsdbRPC. The library also provides a high-level interface OvsdbClient
-as the main interface to interact with peers through the OVSDB protocol.
-In the passive connection scenario, each connection will have a
-corresponding OvsdbClient object, and the application can obtain the
-OvsdbClient object through connection listener callback methods. In
-other words, if the application implements the OvsdbConnectionListener
-interface, it will get notifications of connection status changes with
-the corresponding OvsdbClient object of that connection.
-
-OVSDB database operations
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-RFC 7047 also defines database operations, such as insert, delete, and
-update, to be performed as part of a "transact" RPC request. The OVSDB
-library defines the data operations in Operations.java and provides the
-TransactionBuilder class to help build "transact" RPC requests. To build
-a JSON-RPC transact request message, the application can obtain the
-TransactionBuilder object through a transactBuilder() method in the
-OvsdbClient interface.
-
-The TransactionBuilder class provides the following methods to help
-build transactions:
-
-- getOperations(): Get the list of operations in this transaction.
-
-- add(): Add data operation to this transaction.
-
-- build(): Return the list of operations in this transaction. This is
- the same as the getOperations() method.
-
-- execute(): Send the JSON RPC transaction to peer.
-
-- getDatabaseSchema(): Get the database schema of this transaction.
-
-If the application wants to build and send a "transact" RPC request to
-modify OVSDB tables on a peer, it can take the following steps:
-
-1. Statically import parameter "op" in Operations.java
-
- ``import static org.opendaylight.ovsdb.lib.operations.Operations.op;``
-
-2. Obtain transaction builder through transacBuilder() method in
- OvsdbClient:
-
- ``TransactionBuilder transactionBuilder = ovsdbClient.transactionBuilder(dbSchema);``
-
-3. Add operations to transaction builder:
-
- ``transactionBuilder.add(op.insert(schema, row));``
-
-4. Send transaction to peer and get JSON RPC response:
-
- ``operationResults = transactionBuilder.execute().get();``
-
- .. note::
-
- Although the "select" operation is supported in the OVSDB
- library, the library implementation is a little different from
- RFC 7047. In RFC 7047, section 5.2.2 describes the "select"
- operation as follows:
-
- “The "rows" member of the result is an array of objects. Each object
- corresponds to a matching row, with each column specified in
- "columns" as a member, the column’s name as the member name, and its
- value as the member value. If "columns" is not specified, all the
- table’s columns are included (including the internally generated
- "\_uuid" and "\_version" columns).”
-
- The OVSDB library implementation always requires the column’s name in
- the "columns" field of a JSON message. If the "columns" field is not
- specified, none of the table’s columns are included. If the
- application wants to get the table entry with all columns, it needs
- to specify all the columns’ names in the "columns" field.
-
-Reference Documentation
-~~~~~~~~~~~~~~~~~~~~~~~
-
-RFC 7047 The Open vSwitch Databse Management Protocol
-https://tools.ietf.org/html/rfc7047
-
-OVSDB MD-SAL Southbound Plugin Developer Guide
-----------------------------------------------
-
-Overview
-~~~~~~~~
-
-The Open vSwitch Database (OVSDB) Model Driven Service Abstraction Layer
-(MD-SAL) Southbound Plugin provides an MD-SAL based interface to Open
-vSwitch systems. This is done by augmenting the MD-SAL topology node
-with a YANG model which replicates some (but not all) of the Open
-vSwitch schema.
-
-OVSDB MD-SAL Southbound Plugin Architecture and Operation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The architecture and operation of the OVSDB MD-SAL Southbound plugin is
-illustrated in the following set of diagrams.
-
-Connecting to an OVSDB Node
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-An OVSDB node is a system which is running the OVS software and is
-capable of being managed by an OVSDB manager. The OVSDB MD-SAL
-Southbound plugin in OpenDaylight is capable of operating as an OVSDB
-manager. Depending on the configuration of the OVSDB node, the
-connection of the OVSDB manager can be active or passive.
-
-Active OVSDB Node Manager Workflow
-''''''''''''''''''''''''''''''''''
-
-An active OVSDB node manager connection is made when OpenDaylight
-initiates the connection to the OVSDB node. In order for this to work,
-you must configure the OVSDB node to listen on a TCP port for the
-connection (i.e. OpenDaylight is active and the OVSDB node is passive).
-This option can be configured on the OVSDB node using the following
-command:
-
-::
-
- ovs-vsctl set-manager ptcp:6640
-
-The following diagram illustrates the sequence of events which occur
-when OpenDaylight initiates an active OVSDB manager connection to an
-OVSDB node.
-
-.. figure:: ./images/ovsdb-sb-active-connection.jpg
- :alt: Active OVSDB Manager Connection
-
- Active OVSDB Manager Connection
-
-Step 1
- Create an OVSDB node by using RESTCONF or an OpenDaylight plugin.
- The OVSDB node is listed under the OVSDB topology node.
-
-Step 2
- Add the OVSDB node to the OVSDB MD-SAL southbound configuration
- datastore. The OVSDB southbound provider is registered to listen for
- data change events on the portion of the MD-SAL topology data store
- which contains the OVSDB southbound topology node augmentations. The
- addition of an OVSDB node causes an event which is received by the
- OVSDB Southbound provider.
-
-Step 3
- The OVSDB Southbound provider initiates a connection to the OVSDB
- node using the connection information provided in the configuration
- OVSDB node (i.e. IP address and TCP port number).
-
-Step 4
- The OVSDB Southbound provider adds the OVSDB node to the OVSDB
- MD-SAL operational data store. The operational data store contains
- OVSDB node objects which represent active connections to OVSDB
- nodes.
-
-Step 5
- The OVSDB Southbound provider requests the schema and databases
- which are supported by the OVSDB node.
-
-Step 6
- The OVSDB Southbound provider uses the database and schema
- information to construct a monitor request which causes the OVSDB
- node to send the controller any updates made to the OVSDB databases
- on the OVSDB node.
-
-Passive OVSDB Node Manager Workflow
-'''''''''''''''''''''''''''''''''''
-
-A passive OVSDB node connection to OpenDaylight is made when the OVSDB
-node initiates the connection to OpenDaylight. In order for this to
-work, you must configure the OVSDB node to connect to the IP address and
-OVSDB port on which OpenDaylight is listening. This option can be
-configured on the OVSDB node using the following command:
-
-::
-
- ovs-vsctl set-manager tcp:<IP address>:6640
-
-The following diagram illustrates the sequence of events which occur
-when an OVSDB node connects to OpenDaylight.
-
-.. figure:: ./images/ovsdb-sb-passive-connection.jpg
- :alt: Passive OVSDB Manager Connection
-
- Passive OVSDB Manager Connection
-
-Step 1
- The OVSDB node initiates a connection to OpenDaylight.
-
-Step 2
- The OVSDB Southbound provider adds the OVSDB node to the OVSDB
- MD-SAL operational data store. The operational data store contains
- OVSDB node objects which represent active connections to OVSDB
- nodes.
-
-Step 3
- The OVSDB Southbound provider requests the schema and databases
- which are supported by the OVSDB node.
-
-Step 4
- The OVSDB Southbound provider uses the database and schema
- information to construct a monitor request which causes the OVSDB
- node to send back any updates which have been made to the OVSDB
- databases on the OVSDB node.
-
-OVSDB Node ID in the Southbound Operational MD-SAL
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-When OpenDaylight initiates an active connection to an OVSDB node, it
-writes an external-id to the Open\_vSwitch table on the OVSDB node. The
-external-id is an OpenDaylight instance identifier which identifies the
-OVSDB topology node which has just been created. Here is an example
-showing the value of the *opendaylight-iid* entry in the external-ids
-column of the Open\_vSwitch table where the node-id of the OVSDB node is
-*ovsdb:HOST1*.
-
-::
-
- $ ovs-vsctl list open_vswitch
- ...
- external_ids : {opendaylight-iid="/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb:HOST1']"}
- ...
-
-The *opendaylight-iid* entry in the external-ids column of the
-Open\_vSwitch table causes the OVSDB node to have same node-id in the
-operational MD-SAL datastore as in the configuration MD-SAL datastore.
-This holds true if the OVSDB node manager settings are subsequently
-changed so that a passive OVSDB manager connection is made.
-
-If there is no *opendaylight-iid* entry in the external-ids column and a
-passive OVSDB manager connection is made, then the node-id of the OVSDB
-node in the operational MD-SAL datastore will be constructed using the
-UUID of the Open\_vSwitch table as follows.
-
-::
-
- "node-id": "ovsdb://uuid/b8dc0bfb-d22b-4938-a2e8-b0084d7bd8c1"
-
-The *opendaylight-iid* entry can be removed from the Open\_vSwitch table
-using the following command.
-
-::
-
- $ sudo ovs-vsctl remove open_vswitch . external-id "opendaylight-iid"
-
-OVSDB Changes by using OVSDB Southbound Config MD-SAL
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-After the connection has been made to an OVSDB node, you can make
-changes to the OVSDB node by using the OVSDB Southbound Config MD-SAL.
-You can make CRUD operations by using the RESTCONF interface or by a
-plugin using the MD-SAL APIs. The following diagram illustrates the
-high-level flow of events.
-
-.. figure:: ./images/ovsdb-sb-config-crud.jpg
- :alt: OVSDB Changes by using the Southbound Config MD-SAL
-
- OVSDB Changes by using the Southbound Config MD-SAL
-
-Step 1
- A change to the OVSDB Southbound Config MD-SAL is made. Changes
- include adding or deleting bridges and ports, or setting attributes
- of OVSDB nodes, bridges or ports.
-
-Step 2
- The OVSDB Southbound provider receives notification of the changes
- made to the OVSDB Southbound Config MD-SAL data store.
-
-Step 3
- As appropriate, OVSDB transactions are constructed and transmitted
- to the OVSDB node to update the OVSDB database on the OVSDB node.
-
-Step 4
- The OVSDB node sends update messages to the OVSDB Southbound
- provider to indicate the changes made to the OVSDB nodes database.
-
-Step 5
- The OVSDB Southbound provider maps the changes received from the
- OVSDB node into corresponding changes made to the OVSDB Southbound
- Operational MD-SAL data store.
-
-Detecting changes in OVSDB coming from outside OpenDaylight
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Changes to the OVSDB nodes database may also occur independently of
-OpenDaylight. OpenDaylight also receives notifications for these events
-and updates the Southbound operational MD-SAL. The following diagram
-illustrates the sequence of events.
-
-.. figure:: ./images/ovsdb-sb-oper-crud.jpg
- :alt: OVSDB Changes made directly on the OVSDB node
-
- OVSDB Changes made directly on the OVSDB node
-
-Step 1
- Changes are made to the OVSDB node outside of OpenDaylight (e.g.
- ovs-vsctl).
-
-Step 2
- The OVSDB node constructs update messages to inform OpenDaylight of
- the changes made to its databases.
-
-Step 3
- The OVSDB Southbound provider maps the OVSDB database changes to
- corresponding changes in the OVSDB Southbound operational MD-SAL
- data store.
-
-OVSDB Model
-^^^^^^^^^^^
-
-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/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/boron/southbound/southbound-api/src/main/yang/ovsdb.yang>`__
-file.
-
-There are three augmentations:
-
-**ovsdb-node-augmentation**
- This augments the topology node and maps primarily to the
- Open\_vSwitch table of the OVSDB schema. It contains the following
- attributes.
-
- - **connection-info** - holds the local and remote IP address and
- TCP port numbers for the OpenDaylight to OVSDB node connections
-
- - **db-version** - version of the OVSDB database
-
- - **ovs-version** - version of OVS
-
- - **list managed-node-entry** - a list of references to
- ovsdb-bridge-augmentation nodes, which are the OVS bridges
- managed by this OVSDB node
-
- - **list datapath-type-entry** - a list of the datapath types
- supported by the OVSDB node (e.g. *system*, *netdev*) - depends
- on newer OVS versions
-
- - **list interface-type-entry** - a list of the interface types
- supported by the OVSDB node (e.g. *internal*, *vxlan*, *gre*,
- *dpdk*, etc.) - depends on newer OVS verions
-
- - **list openvswitch-external-ids** - a list of the key/value pairs
- in the Open\_vSwitch table external\_ids column
-
- - **list openvswitch-other-config** - a list of the key/value pairs
- in the Open\_vSwitch table other\_config column
-
-**ovsdb-bridge-augmentation**
- This augments the topology node and maps to an specific bridge in
- the OVSDB bridge table of the associated OVSDB node. It contains the
- following attributes.
-
- - **bridge-uuid** - UUID of the OVSDB bridge
-
- - **bridge-name** - name of the OVSDB bridge
-
- - **bridge-openflow-node-ref** - a reference (instance-identifier)
- of the OpenFlow node associated with this bridge
-
- - **list protocol-entry** - the version of OpenFlow protocol to use
- with the OpenFlow controller
-
- - **list controller-entry** - a list of controller-uuid and
- is-connected status of the OpenFlow controllers associated with
- this bridge
-
- - **datapath-id** - the datapath ID associated with this bridge on
- the OVSDB node
-
- - **datapath-type** - the datapath type of this bridge
-
- - **fail-mode** - the OVSDB fail mode setting of this bridge
-
- - **flow-node** - a reference to the flow node corresponding to
- this bridge
-
- - **managed-by** - a reference to the ovsdb-node-augmentation
- (OVSDB node) that is managing this bridge
-
- - **list bridge-external-ids** - a list of the key/value pairs in
- the bridge table external\_ids column for this bridge
-
- - **list bridge-other-configs** - a list of the key/value pairs in
- the bridge table other\_config column for this bridge
-
-**ovsdb-termination-point-augmentation**
- This augments the topology termination point model. The OVSDB
- Southbound MD-SAL uses this model to represent both the OVSDB port
- and OVSDB interface for a given port/interface in the OVSDB schema.
- It contains the following attributes.
-
- - **port-uuid** - UUID of an OVSDB port row
-
- - **interface-uuid** - UUID of an OVSDB interface row
-
- - **name** - name of the port
-
- - **interface-type** - the interface type
-
- - **list options** - a list of port options
-
- - **ofport** - the OpenFlow port number of the interface
-
- - **ofport\_request** - the requested OpenFlow port number for the
- interface
-
- - **vlan-tag** - the VLAN tag value
-
- - **list trunks** - list of VLAN tag values for trunk mode
-
- - **vlan-mode** - the VLAN mode (e.g. access, native-tagged,
- native-untagged, trunk)
-
- - **list port-external-ids** - a list of the key/value pairs in the
- port table external\_ids column for this port
-
- - **list interface-external-ids** - a list of the key/value pairs
- in the interface table external\_ids interface for this interface
-
- - **list port-other-configs** - a list of the key/value pairs in
- the port table other\_config column for this port
-
- - **list interface-other-configs** - a list of the key/value pairs
- in the interface table other\_config column for this interface
-
-Examples of OVSDB Southbound MD-SAL API
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Connect to an OVSDB Node
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-This example RESTCONF command adds an OVSDB node object to the OVSDB
-Southbound configuration data store and attempts to connect to the OVSDB
-host located at the IP address 10.11.12.1 on TCP port 6640.
-
-::
-
- POST http://<host>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/
- Content-Type: application/json
- {
- "node": [
- {
- "node-id": "ovsdb:HOST1",
- "connection-info": {
- "ovsdb:remote-ip": "10.11.12.1",
- "ovsdb:remote-port": 6640
- }
- }
- ]
- }
-
-Query the OVSDB Southbound Configuration MD-SAL
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Following on from the previous example, if the OVSDB Southbound
-configuration MD-SAL is queried, the RESTCONF command and the resulting
-reply is similar to the following example.
-
-::
-
- GET http://<host>:8080/restconf/config/network-topology:network-topology/topology/ovsdb:1/
- Application/json data in the reply
- {
- "topology": [
- {
- "topology-id": "ovsdb:1",
- "node": [
- {
- "node-id": "ovsdb:HOST1",
- "ovsdb:connection-info": {
- "remote-port": 6640,
- "remote-ip": "10.11.12.1"
- }
- }
- ]
- }
- ]
- }
-
-Reference Documentation
-~~~~~~~~~~~~~~~~~~~~~~~
-
-`Openvswitch
-schema <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf>`__
-
-OVSDB Openstack Developer Guide
--------------------------------
-
-Overview
-~~~~~~~~
-
-The Open vSwitch database (OVSDB) Southbound Plugin component for
-OpenDaylight implements the OVSDB `RFC
-7047 <https://tools.ietf.org/html/rfc7047>`__ management protocol that
-allows the southbound configuration of switches that support OVSDB. The
-component comprises a library and a plugin. The OVSDB protocol uses
-JSON-RPC calls to manipulate a physical or virtual switch that supports
-OVSDB. Many vendors support OVSDB on various hardware platforms. The
-OpenDaylight controller uses the library project to interact with an OVS
-instance.
-
-`OpenStack <http://www.openstack.org>`__ is a popular open source
-Infrastructure as a Service (IaaS) project, covering compute, storage
-and network management. OpenStack can use OpenDaylight as its network
-management provider through the Neutron API, which acts as a northbound
-for OpenStack. the OVSDB NetVirt piece of the OVSDB project is a
-provider for the Neutron API in OpenDaylight. OpenDaylight manages the
-network flows for the OpenStack compute nodes via the OVSDB project,
-with the south-bound plugin. This section describes how to set that up,
-and how to tell when everything is working.
-
-OVSDB Openstack Architecture
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The OpenStack integration architecture uses the following technologies:
-
-- `RFC 7047 <https://tools.ietf.org/html/rfc7047>`__ - The Open vSwitch
- Database Management Protocol
-
-- `OpenFlow
- v1.3 <http://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.3.4.pdf>`__
-
-- `OpenStack Neutron ML2
- Plugin <https://wiki.openstack.org/wiki/Neutron/ML2>`__
-
-.. figure:: images/openstack_integration.png
-
- OpenStack Integration
-
-OVSDB Service Function Chaining Developer Guide
------------------------------------------------
-
-Overview
-~~~~~~~~
-
-The OVSDB NetVirtSfc provides a classification and traffic steering
-component when integrated with OpenStack. Please refer to the Service
-Function Chaining project for the theory and programming of service
-chains.
-
-Installing the NetVirt SFC Feature
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Install the odl-ovsdb-sfc feature. The feature will also ensure that the
-odl-ovsdb-openstack feature as well as the openflowplugin, neutron and
-sfc features are installed.
-
-``feature:install odl-ovsdb-sfc-ui``
-
-Verify the required features are installed:
-
-::
-
- opendaylight-user@root>feature:list -i | grep ovsdb
- odl-ovsdb-southbound-api | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight southbound :: api
- odl-ovsdb-southbound-impl | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound impl
- odl-ovsdb-southbound-impl-rest | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: impl REST
- odl-ovsdb-southbound-impl-ui | 1.2.1-SNAPSHOT | x | odl-ovsdb-southbound-1.2.1-SNAPSHOT | OpenDaylight :: southbound :: impl UI
- odl-ovsdb-library | 1.2.1-SNAPSHOT | x | odl-ovsdb-library-1.2.1-SNAPSHOT | OpenDaylight library
- odl-ovsdb-openstack | 1.2.1-SNAPSHOT | x | ovsdb-1.2.1-SNAPSHOT | OpenDaylight :: OVSDB OpenStack Network Virtual
- odl-ovsdb-sfc-api | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc api
- odl-ovsdb-sfc | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight ovsdb-sfc
- odl-ovsdb-sfc-rest | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc REST
- odl-ovsdb-sfc-ui | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc UI
-
- opendaylight-user@root>feature:list -i | grep sfc
- odl-sfc-model | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: sfc :: Model
- odl-sfc-provider | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: sfc :: Provider
- odl-sfc-provider-rest | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: sfc :: Provider
- odl-sfc-ovs | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: OpenvSwitch
- odl-sfcofl2 | 0.2.0-SNAPSHOT | x | odl-sfc-0.2.0-SNAPSHOT | OpenDaylight :: sfcofl2
- odl-ovsdb-sfc-test | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-test1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc-test
- odl-ovsdb-sfc-api | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc :: api
- odl-ovsdb-sfc | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc
- odl-ovsdb-sfc-rest | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc :: REST
- odl-ovsdb-sfc-ui | 1.2.1-SNAPSHOT | x | odl-ovsdb-sfc-1.2.1-SNAPSHOT | OpenDaylight :: ovsdb-sfc :: UI
-
- opendaylight-user@root>feature:list -i | grep neutron
- odl-neutron-service | 0.6.0-SNAPSHOT | x | odl-neutron-0.6.0-SNAPSHOT | OpenDaylight :: Neutron :: API
- odl-neutron-northbound-api | 0.6.0-SNAPSHOT | x | odl-neutron-0.6.0-SNAPSHOT | OpenDaylight :: Neutron :: Northbound
- odl-neutron-spi | 0.6.0-SNAPSHOT | x | odl-neutron-0.6.0-SNAPSHOT | OpenDaylight :: Neutron :: API
- odl-neutron-transcriber | 0.6.0-SNAPSHOT | x | odl-neutron-0.6.0-SNAPSHOT | OpenDaylight :: Neutron :: Implementation
-
-OVSDB NetVirt Service Function Chaining Example
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The architecture within OpenDaylight can be seen in the following
-figure:
-
-.. figure:: ./images/ovsdb/ODL_SFC_Architecture.png
- :alt: OpenDaylight OVSDB NetVirt SFC Architecture
-
- OpenDaylight OVSDB NetVirt SFC Architecture
-
-Tacker is a Virtual Network Functions Manager that is responsible for
-orchestrating the Service Function Chaining. Tacker is responsible for
-generating templates for Virtual Network Functions for OpenStack to
-instantiate the Service Functions. Tacker also uses the RESTCONF
-interfaces of OpenDaylight to create the Service Function Chains.
-
-Classification
-~~~~~~~~~~~~~~
-
-OVSDB NetVirt SFC implements the classification for the chains. The
-classification steers traffic from the tenant overlay to the chain
-overlay and back to the tenant overlay.
-
-An Access Control List used by NetVirtSFC to create the classifier is
-shown below. This is an example of classifying HTTP traffic using the
-tcp port 80. In this example the user would have created a Service
-Function Chain with the name "http-sfc" as well as all the associated
-Service Functions and Service Function Forwarders for the chain.
-
-http://localhost:8181/restconf/config/ietf-access-control-list:access-lists
-
-::
-
- {
- "access-lists": {
- "acl": [
- {
- "acl-name": "http-acl",
- "access-list-entries": {
- "ace": [
- {
- "rule-name": "http-rule",
- "matches": {
- "source-port-range": {
- "lower-port": 0,
- "upper-port": 0
- },
- "protocol": 6,
- "destination-port-range": {
- "lower-port": 80,
- "upper-port": 80
- }
- },
- "actions": {
- "netvirt-sfc-acl:sfc-name": "http-sfc"
- }
- }
- ]
- }
- }
- ]
- }
- }
-
-When the chain is rendered using the Rendered Service Path RPC,
-NetvirtSfc will add the classification flows. The classification flows
-are shown below. The list shown has been modified to remove the NetVirt
-tenant overlay flows. The classification flow is identified with the
-cookie: 0x1110010000040255. The 6th digit of the cookie identifies the
-flow type as the classifier. The last 8 digits identify the chain with
-the first four digits indicating the NSH NSP and the last four digits
-identifying the NSH NSI. In this case the chain is identified with an
-NSP of 4 and the NSI is 255 to indicate the beginning of the chain.
-
-::
-
- sudo ovs-ofctl --protocol=OpenFlow13 dump-flows br-int
- OFPST_FLOW reply (OF1.3) (xid=0x2):
- cookie=0x0, duration=17.157s, table=0, n_packets=0, n_bytes=0, priority=6 actions=goto_table:1
- cookie=0x14, duration=10.692s, table=0, n_packets=0, n_bytes=0, priority=400,udp,in_port=4,tp_dst=6633 actions=LOCAL
- cookie=0x0, duration=17.134s, table=0, n_packets=0, n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535
- cookie=0x14, duration=10.717s, table=0, n_packets=0, n_bytes=0, priority=350,nsp=4 actions=goto_table:152
- cookie=0x14, duration=10.688s, table=0, n_packets=0, n_bytes=0, priority=400,udp,nw_dst=10.2.1.1,tp_dst=6633 actions=output:4
- cookie=0x0, duration=17.157s, table=1, n_packets=0, n_bytes=0, priority=0 actions=goto_table:11
- cookie=0x1110070000040254, duration=10.608s, table=1, n_packets=0, n_bytes=0, priority=40000,reg0=0x1,nsp=4,nsi=254,in_port=1 actions=goto_table:21
- cookie=0x0, duration=17.157s, table=11, n_packets=0, n_bytes=0, priority=0 actions=goto_table:21
- cookie=0x1110060000040254, duration=10.625s, table=11, n_packets=0, n_bytes=0, nsp=4,nsi=254,in_port=4 actions=load:0x1->NXM_NX_REG0[],move:NXM_NX_NSH_C2[]->NXM_NX_TUN_ID[0..31],resubmit(1,1)
- cookie=0x1110010000040255, duration=10.615s, table=11, n_packets=0, n_bytes=0, tcp,reg0=0x1,tp_dst=80 actions=move:NXM_NX_TUN_ID[0..31]->NXM_NX_NSH_C2[],set_nshc1:0xc0a83246,set_nsp:0x4,set_nsi:255,load:0xa020101->NXM_NX_TUN_IPV4_DST[],load:0x4->NXM_NX_TUN_ID[0..31],resubmit(,0)
- cookie=0x0, duration=17.157s, table=21, n_packets=0, n_bytes=0, priority=0 actions=goto_table:31
- cookie=0x1110040000000000, duration=10.765s, table=21, n_packets=0, n_bytes=0, priority=1024,arp,in_port=LOCAL,arp_tpa=10.2.1.1,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:f6:00:00:0f:00:01->eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xf600000f0001->NXM_NX_ARP_SHA[],load:0xa020101->NXM_OF_ARP_SPA[],IN_PORT
- cookie=0x0, duration=17.157s, table=31, n_packets=0, n_bytes=0, priority=0 actions=goto_table:41
- cookie=0x0, duration=17.157s, table=41, n_packets=0, n_bytes=0, priority=0 actions=goto_table:51
- cookie=0x0, duration=17.157s, table=51, n_packets=0, n_bytes=0, priority=0 actions=goto_table:61
- cookie=0x0, duration=17.142s, table=61, n_packets=0, n_bytes=0, priority=0 actions=goto_table:71
- cookie=0x0, duration=17.140s, table=71, n_packets=0, n_bytes=0, priority=0 actions=goto_table:81
- cookie=0x0, duration=17.116s, table=81, n_packets=0, n_bytes=0, priority=0 actions=goto_table:91
- cookie=0x0, duration=17.116s, table=91, n_packets=0, n_bytes=0, priority=0 actions=goto_table:101
- cookie=0x0, duration=17.107s, table=101, n_packets=0, n_bytes=0, priority=0 actions=goto_table:111
- cookie=0x0, duration=17.083s, table=111, n_packets=0, n_bytes=0, priority=0 actions=drop
- cookie=0x14, duration=11.042s, table=150, n_packets=0, n_bytes=0, priority=5 actions=goto_table:151
- cookie=0x14, duration=11.027s, table=151, n_packets=0, n_bytes=0, priority=5 actions=goto_table:152
- cookie=0x14, duration=11.010s, table=152, n_packets=0, n_bytes=0, priority=5 actions=goto_table:158
- cookie=0x14, duration=10.668s, table=152, n_packets=0, n_bytes=0, priority=650,nsp=4,nsi=255 actions=load:0xa020101->NXM_NX_TUN_IPV4_DST[],goto_table:158
- cookie=0x14, duration=10.995s, table=158, n_packets=0, n_bytes=0, priority=5 actions=drop
- cookie=0xba5eba11ba5eba11, duration=10.645s, table=158, n_packets=0, n_bytes=0, priority=751,nsp=4,nsi=255,in_port=4 actions=move:NXM_NX_NSH_C1[]->NXM_NX_NSH_C1[],move:NXM_NX_NSH_C2[]->NXM_NX_NSH_C2[],move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],IN_PORT
- cookie=0xba5eba11ba5eba11, duration=10.590s, table=158, n_packets=0, n_bytes=0, priority=751,nsp=4,nsi=254,in_port=4 actions=move:NXM_NX_NSI[]->NXM_NX_NSI[],move:NXM_NX_NSP[]->NXM_NX_NSP[],move:NXM_NX_NSH_C1[]->NXM_NX_TUN_IPV4_DST[],move:NXM_NX_NSH_C2[]->NXM_NX_TUN_ID[0..31],IN_PORT
- cookie=0xba5eba11ba5eba11, duration=10.640s, table=158, n_packets=0, n_bytes=0, priority=750,nsp=4,nsi=255 actions=move:NXM_NX_NSH_C1[]->NXM_NX_NSH_C1[],move:NXM_NX_NSH_C2[]->NXM_NX_NSH_C2[],move:NXM_NX_TUN_ID[0..31]->NXM_NX_TUN_ID[0..31],output:4
- cookie=0xba5eba11ba5eba11, duration=10.571s, table=158, n_packets=0, n_bytes=0, priority=761,nsp=4,nsi=254,nshc1=3232248390,in_port=4 actions=move:NXM_NX_NSI[]->NXM_NX_NSI[],move:NXM_NX_NSP[]->NXM_NX_NSP[],move:NXM_NX_NSH_C1[]->NXM_NX_TUN_IPV4_DST[],move:NXM_NX_NSH_C2[]->NXM_NX_TUN_ID[0..31],set_nshc1:0,resubmit(,11)
-
-
-Configuration
-~~~~~~~~~~~~~
-
-Some configuration is required due to application coexistence for the
-OpenFlow programming. The SFC project programs flows for the SFC overlay
-and NetVirt programs flows for the tenant overlay. Coexistence is
-achieved by each application owning a unique set of tables and providing
-a simple handoff between the tables.
-
-First configure NetVirt to use table 1 as it’s starting table:
-
-http://localhost:8181/restconf/config/netvirt-providers-config:netvirt-providers-config
-
-``{ "netvirt-providers-config": { "table-offset": 1 } }``
-
-Next configure SFC to start at table 150 and configure the table
-handoff. The configuration starts SFC at table 150 and sets the handoff
-to table 11 which is the NetVirt SFC classification table.
-
-http://localhost:8181/restconf/config/sfc-of-renderer:sfc-of-renderer-config
-
-``{ "sfc-of-renderer-config": { "sfc-of-app-egress-table-offset": 11, "sfc-of-table-offset": 150 } }``
-
-OVSDB Hardware VTEP Developer Guide
------------------------------------
-
-Overview
-~~~~~~~~
-
-TBD
-
-OVSDB Hardware VTEP Architecture
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-TBD
-
-OVSDB NetVirt
-=============
+OVSDB
+=====
-NetVirt
--------
-
-The OVSDB NetVirt project delivers two major pieces of functionality:
-
-1. The OVSDB Southbound Protocol, and
-
-2. NetVirt, a network virtualization solution.
-
-The following diagram shows the system-level architecture of OVSDB
-NetVirt in an OpenStack-based solution.
-
-.. figure:: ./images/ovsdb/ovsdb-netvirt-architecture.jpg
- :alt: OVSDB NetVirt Architecture
-
- OVSDB NetVirt Architecture
-
-NetVirt is a network virtualization solution that is a Neutron service
-provider, and therefore supports the OpenStack Neutron Networking API
-and extensions.
-
-The OVSDB component implements the OVSDB protocol (RFC 7047), as well as
+The OVSDB project implements the OVSDB protocol (RFC 7047), as well as
plugins to support OVSDB Schemas, such as the Open\_vSwitch database
schema and the hardware\_vtep database schema.
-NetVirt has MDSAL-based interfaces with Neutron on the northbound side,
-and OVSDB and OpenFlow plugins on the southbound side.
-
-OVSDB NetVirt currently supports Open vSwitch virtual switches via
-OpenFlow and OVSDB. Work is underway to support hardware gateways.
-
-NetVirt services are enabled by installing the odl-ovsdb-openstack
-feature using the following command:
-
-::
-
- feature:install odl-ovsdb-openstack
-
-To enable NetVirt’s distributed Layer 3 routing services, the following
-line must be uncommented in the etc/custom.properties file in the
-OpenDaylight distribution prior to starting karaf:
-
-::
-
- ovsdb.l3.fwd.enabled=yes
-
-To start the OpenDaylight controller, run the following application in
-your distribution:
-
-::
-
- bin/karaf
-
-More details about using NetVirt with OpenStack can be found in the
-following places:
-
-1. The "OpenDaylight and OpenStack" guide, and
-
-2. `Getting Started with OpenDaylight OVSDB Plugin Network
- Virtualization <https://wiki.opendaylight.org/view/OVSDB_Integration:Main#Getting_Started_with_OpenDaylight_OVSDB_Plugin_Network_Virtualization>`__
-
-Some additional details about using OpenStack Security Groups and the
-Data Plane Development Kit (DPDK) are provided below.
-
-Security groups
-~~~~~~~~~~~~~~~
-
-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
-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.
-
-Stateful Implementation
-^^^^^^^^^^^^^^^^^^^^^^^
-
-The security group is implemented in two modes, stateful and stateless.
-Stateful can be enabled by setting false to true in
-etc/opendaylight/karaf/netvirt-impl-default-config.xml
-
-The stateful implementation uses the conntrack capabilities of ovs and
-tracks an existing connection. This mode requires OVS2.5 and linux
-kernel 4.3. The ovs which is integrated with netfilter framework tracks
-the connection using the five tuple(layer-3 protocol, source address,
-destination address, layer-4 protocol, layer-4 key). The connection
-state is independent of the upper level state of connection oriented
-protocols like TCP, and even connectionless protocols like UDP will have
-a pseudo state. With this implementation OVS sends the packet to the
-netfilter framework to know whether there is an entry for to the
-connection. netfilter will return the packet to OVS with the appropriate
-flag set. Below are the states we are interested in:
-
-::
-
- -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+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.
-
-Stateless Implementation
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-The stateless mode is for OVS 2.4 and below where connection tracking is
-not supported. Here we have pseudo-connection tracking using the TCP SYN
-flag. Other than TCP packets, all protocol packets is allowed by
-default. For TCP packets, the SYN packets will be dropped by default
-unless there is a specific rule which allows TCP SYN packets to a
-particular port.
-
-Fixed Rules
-^^^^^^^^^^^
-
-The SecurityGroup are associated with the vm port when the vm is
-spawned. By default a set of rules are applied to the vm port referred
-to as fixed security group rule. This includes the DHCP rules the ARP
-rule and the conntrack rules. The conntrack rules will be inserted only
-in the stateful mode.
-
-DHCP rules
-''''''''''
-
-The DHCP rules added to the vm port when a vm is spawned. The fixed DHCP
-rules are
-
-- Allow DHCP server traffic ingress.
-
- ::
-
- 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
-
- ::
-
- 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
-
-- 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.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,
- 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,
- priority=61011,udp6,in_port=2,tp_src=547,tp_dst=546 actions=drop
-
-Arp rules
-'''''''''
-
-The default arp rules allows the arp traffic to go in and out of the vm
-port.
-
-::
-
- 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
-
-Conntrack rules
-'''''''''''''''
-
-These rules are inserted only in stateful mode. The conntrack rules use
-the netfilter framework to track packets. The below rules are added to
-leverage it.
-
-- If a packet is not tracked(connection state –trk) it is send it to
- the netfilter for tracking
-
-- If the packet is already tracked (netfilter filter returns connection
- state +trk,+est) and if the connection is established, then allow the
- packet to go through the pipeline.
-
-- The third rule is the default drop rule which will drop the packet,
- if the packet is tracked and new(netfilter filter returns connection
- state +trk,+new). This rule has lower priority than the custom rules
- which shall be added.
-
- ::
-
- 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,
- ct_state=+trk+est,action=goto_table:50
-
- ::
-
- 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,
- 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,
- dl_dst=fa:16:3e:0d:8d:21,ct_state=-trk,action=ct"("table=0")"
-
- ::
-
- 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
-''''''''''''
-
-This rule is inserted in stateless mode only. This rule will drop TCP
-SYN packet by default
-
-Custom Security Groups
-^^^^^^^^^^^^^^^^^^^^^^
-
-::
-
- 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
-''''''''
-
-If connection tracking is enabled the match will have connection state
-and the action will have commit along with goto. The commit will send
-the packet to the netfilter framework to cache the entry. After a
-commit, for the next packet of this connection netfilter will return
-+trk+est and the packet will match the fixed conntrack rule and get
-forwarded to next table.
-
-::
-
- 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
-
-::
-
- 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
-
-::
-
- 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
-
-Stateless
-'''''''''
-
-If the mode is stateless the match will have only the parameter
-specified in the security rule and a goto in the action. The ct\_state
-and commit action will be missing.
-
-::
-
- 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
-
-::
-
- 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
- actions=goto_table:100
-
-TCP/UDP Port Range
-''''''''''''''''''
-
-The TCP/UDP port range is supported with the help of port mask. This
-will dramatically reduce the number of flows required to cover a port
-range. The below 7 rules can cover a port range from 333 to 777.
-
-::
-
- 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
-
-::
-
- 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
-
-::
-
- 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
-
-::
-
- 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
-
-::
-
- 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
-
-::
-
- 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
-
-::
-
- 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
-
-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.
-
-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,
- 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
-
-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,
- 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
-
-::
-
- 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
-
-Rules supported in ODL
-^^^^^^^^^^^^^^^^^^^^^^
-
-The following rules are supported in the current implementation. The
-direction (ingress/egress) is always expected.
-
-+--------------------+--------------------+--------------------+--------------------+
-| Protocol | Port Range | IP Prefix | Remote Security |
-| | | | Group supported |
-+--------------------+--------------------+--------------------+--------------------+
-| Any | Any | Any | Yes |
-+--------------------+--------------------+--------------------+--------------------+
-| TCP | 1 - 65535 | 0.0.0.0/0 | Yes |
-+--------------------+--------------------+--------------------+--------------------+
-| UDP | 1 - 65535 | 0.0.0.0/0 | Yes |
-+--------------------+--------------------+--------------------+--------------------+
-| ICMP | Any | 0.0.0.0/0 | Yes |
-+--------------------+--------------------+--------------------+--------------------+
-
-Table: Table Supported Rules
-
-Note : IPV6 and port-range feature is not supported as of today
-
-Using OVS with DPDK hosts and OVSDB NetVirt
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The Data Plane Development Kit (`DPDK <http://dpdk.org/>`__) is a
-userspace set of libraries and drivers designed for fast packet
-processing. The userspace datapath variant of OVS can be built with DPDK
-enabled to provide the performance features of DPDK to Open vSwitch
-(OVS). In the 2.4.0 version of OVS, the Open\_vSwtich table schema was
-enhanced to include the lists *datapath-types* and *interface-types*.
-When the OVS with DPDK variant of OVS is running, the *inteface-types*
-list will include DPDK interface types such as *dpdk* and
-*dpdkvhostuser*. The OVSDB Southbound Plugin includes this information
-in the OVSDB YANG model in the MD-SAL, so when a specific OVS host is
-running OVS with DPDK, it is possible for NetVirt to detect that
-information by checking that DPDK interface types are included in the
-list of supported interface types.
-
-For example, query the operational MD-SAL for OVSDB nodes:
-
-HTTP GET:
-
-::
-
- http://{{CONTROLLER-IP}}:8181/restconf/operational/network-topology:network-topology/topology/ovsdb:1/
-
-Result Body:
-
-::
-
- {
- "topology": [
- {
- "topology-id": "ovsdb:1",
- "node": [
- < content edited out >
- {
- "node-id": "ovsdb://uuid/f9b58b6d-04db-459a-b914-fff82b738aec",
- < content edited out >
- "ovsdb:interface-type-entry": [
- {
- "interface-type": "ovsdb:interface-type-ipsec-gre"
- },
- {
- "interface-type": "ovsdb:interface-type-internal"
- },
- {
- "interface-type": "ovsdb:interface-type-system"
- },
- {
- "interface-type": "ovsdb:interface-type-patch"
- },
- {
- "interface-type": "ovsdb:interface-type-dpdkvhostuser"
- },
- {
- "interface-type": "ovsdb:interface-type-dpdk"
- },
- {
- "interface-type": "ovsdb:interface-type-dpdkr"
- },
- {
- "interface-type": "ovsdb:interface-type-vxlan"
- },
- {
- "interface-type": "ovsdb:interface-type-lisp"
- },
- {
- "interface-type": "ovsdb:interface-type-geneve"
- },
- {
- "interface-type": "ovsdb:interface-type-gre"
- },
- {
- "interface-type": "ovsdb:interface-type-tap"
- },
- {
- "interface-type": "ovsdb:interface-type-stt"
- }
- ],
- < content edited out >
- "ovsdb:datapath-type-entry": [
- {
- "datapath-type": "ovsdb:datapath-type-netdev"
- },
- {
- "datapath-type": "ovsdb:datapath-type-system"
- }
- ],
- < content edited out >
- },
- < content edited out >
- ]
- }
- ]
- }
-
-This example illustrates the output of an OVS with DPDK host because the
-list of interface types includes types supported by DPDK.
-
-Bridges on OVS with DPDK hosts need to be created with the *netdev*
-datapath type and DPDK specific ports need to be created with the
-appropriate interface type. The OpenDaylight OVSDB Southbound Plugin
-supports these attributes.
-
-The OpenDaylight NetVirt application checks whether the OVS host is
-using OVS with DPDK when creating the bridges that are expected to be
-present on the host, e.g. *br-int*.
-
-Following are some tips for supporting hosts using OVS with DPDK when
-using NetVirt as the Neutron service provider and *devstack* to deploy
-Openstack.
-
-In addition to the *networking-odl* ML2 plugin, enable the
-*networking-odl-dpdk* plugin in *local.conf*.
-
-::
-
- For working with Openstack Liberty
- enable_plugin networking-odl https://github.com/FedericoRessi/networking-odl integration/liberty
- enable_plugin networking-ovs-dpdk https://github.com/openstack/networking-ovs-dpdk stable/liberty
-
-::
-
- For working with Openstack Mitaka (or later) branch
- enable_plugin networking-odl https://github.com/openstack/networking-odl
- enable_plugin networking-ovs-dpdk https://github.com/openstack/networking-ovs-dpdk
-
-The order of these plugin lines is important. The *networking-odl*
-plugin will install and setup *openvswitch*. The *networking-ovs-dpdk*
-plugin will install OVS with DPDK. Note, the *networking-ovs-dpdk*
-plugin is only being used here to setup OVS with DPDK. The
-*networking-odl* plugin will be used as the Neutron ML2 driver.
-
-For VXLAN tenant network support, the NetVirt application interacts with
-OVS with DPDK host in the same way as OVS hosts using the kernel
-datapath by creating VXLAN ports on *br-int* to communicate with other
-tunnel endpoints. The IP address for the local tunnel endpoint may be
-configured in the *local.conf* file. For example:
-
-::
-
- ODL_LOCAL_IP=192.100.200.10
-
-NetVirt will use this information to configure the VXLAN port on
-*br-int*. On a host with the OVS kernel datapath, it is expected that
-there will be a networking interface configured with this IP address. On
-an OVS with DPDK host, an OVS bridge is created and a DPDK port is added
-to the bridge. The local tunnel endpoint address is then assigned to the
-bridge port of the bridge. So, for example, if the physical network
-interface is associated with *eth0* on the host, a bridge named
-*br-eth0* could be created. The DPDK port, such as *dpdk0* (per the
-naming conventions of OVS with DPDK), is added to bridge *br-eth0*. The
-local tunnel endpoint address is assigned to the network interface
-*br-eth0* which is attached to bridge *br-eth0*. All of this setup is
-not done by NetVirt. The *networking-ovs-dpdk* can be made to perform
-this setup by putting configuration like the following in *local.conf*.
-
-::
-
- ODL_LOCAL_IP=192.168.200.9
- ODL_PROVIDER_MAPPINGS=physnet1:eth0,physnet2:eht1
- OVS_DPDK_PORT_MAPPINGS=eth0:br-eth0,eth1:br-ex
- OVS_BRIDGE_MAPPINGS=physnet1:br-eth0,physnet2:br-ex
-
-The above settings associate the host networking interface *eth0* with
-bridge *br-eth0*. The *networking-ovs-dpdk* plugin will determine the
-DPDK port name associated with *eth0* and add it to the bridge
-*br-eth0*. If using the NetVirt L3 support, these settings will enable
-setup of the *br-ex* bridge and attach the DPDK port associated with
-network interface *eth1* to it.
-
-The following settings are included in *local.conf* to specify specific
-attributes associated with OVS with DPDK. These are used by the
-*networking-ovs-dpdk* plugin to configure OVS with DPDK.
-
-::
-
- OVS_DATAPATH_TYPE=netdev
- OVS_NUM_HUGEPAGES=8192
- OVS_DPDK_MEM_SEGMENTS=8192
- OVS_HUGEPAGE_MOUNT_PAGESIZE=2M
- OVS_DPDK_RTE_LIBRTE_VHOST=y
- OVS_DPDK_MODE=compute
-
-Once the stack is up and running virtual machines may be deployed on OVS
-with DPDK hosts. The *networking-odl* plugin handles ensuring that
-*dpdkvhostuser* interfaces are utilized by Nova instead of the default
-*tap* interface. The *dpdkvhostuser* interface provides the best
-performance for VMs on OVS with DPDK hosts.
-
-A Nova flavor is created for VMs that may be deployed on OVS with DPDK
-hosts.
-
-::
-
- nova flavor-create largepage-flavor 1002 1024 4 1
- nova flavor-key 1002 set "hw:mem_page_size=large"
-
-Then, just specify the flavor when creating a VM.
-
-::
-
- nova boot --flavor largepage-flavor --image cirros-0.3.4-x86_64-uec --nic net-id=<NET ID VALUE> vm-name
-
OVSDB Plugins
-------------
^^^^^^^^^^
https://wiki.opendaylight.org/view/User_talk:Pzhang
-
Code Review / docs.git / commitdiff
