5/17/2017 OVSDB Integration:Design ­ OpenDaylight Project

Page
Page
Discussion
View source
History

Tools
Page information
Permanent link
Printable version

Special pages
Related changes

What links here

Search Search

Log in

OpenDaylight.org
Get Software
Documentation
User Stories
Community
Blog
Q&A Form
Wiki

OVSDB Integration:Design

Contents
1 OVSDB Quick Resources
2 OpenDaylight OVSDB SouthBound Plugin Architecture and Design
3 Bird's eye view of OpenDaylight Controller Architecture
4 OVSDB Southbound plugin
4.1 Connection Service
4.2 Network Configuration Service
4.3 Bidirectional JSON­RPC Library
4.4 OVSDB Schema definitions and Object mappers
4.4.1 End to End Examples
4.5 Overlay Tunnel Management
4.6 OVSDB to OpenFlow plugin mapping service
4.7 Inventory Service
5 What next

OVSDB Quick Resources

Remembering The Management Plane ­ Network Heresy (http://networkheresy.com/2012/09/15/remembering­the­management­plane/)
OVSDB Hangout Recording Weekly Calls and Informational (http://www.youtube.com/channel/UCMYntfZ255XGgYFrxCNcAzA)
Please visit irc.freenode.net #opendaylight­ovsdb and the OVSDB­Dev Listserv (https://lists.opendaylight.org/pipermail/ovsdb­dev/) for
immediate development information and questions.

See the OVSDB YouTube Channel for getting started videos and other tutorials:

OpenDaylight OVSDB YouTube Channel (http://www.youtube.com/channel/UCMYntfZ255XGgYFrxCNcAzA)

Mininet OVSDB Tutorial

OpenDaylight OVSDB SouthBound Plugin Architecture and Design

OpenVSwitch (OVS) has got the collective nod from the industry as the unofficial standard for Virtual Switching in the Open hypervisor based
solutions.
Every other Virtual Switch implementation (properietery or otherwise) is using OVS in some form or shape.
http://openvswitch.org/ has all the information you might need with regards to OVS.

https://wiki.opendaylight.org/view/OVSDB_Integration:Design 1/6
5/17/2017 OVSDB Integration:Design ­ OpenDaylight Project
In the SDN space, controllers and applications can interact with the OpenVSwitch by means of two different channels : OpenFlow and OVSDB.
While the protocol OpenFlow addresses the forwarding­side of the OVS functionality, OVSDB addresses the management­plane.
A simple and concise overview of OVSDB can be found at http://networkstatic.net/getting­started­ovsdb/ (Thanks to Brent's tireless efforts).

This document covers the architecture and design of OVSDB plugin in the OpenDaylight project.

Bird's eye view of OpenDaylight Controller Architecture

The OpenDaylight controller platform is designed as a highly modular and plugin based middleware that serves various network applications on a
variety of use­cases. The modularity is achieved through the Java OSGi framework. The controller comprises many Java OSGi bundles that work
together to provide the needed controller functionalities.
The bundles are placed in the following broad categories:

1. Network Service Functional Modules (such as Topology Manager, Inventory Manager, Forwarding Rules Manager,...)
2. NorthBound API Modules (such as Topology APIs, Bridge Domain APIs, Neutron APIs, Connection Manager APIs, ...)
3. Service Abstraction Layer(SAL)­ (Inventory Services, DataPath Services, Topology Services, Network Config,...)
4. SouthBound Plugins (OpenFlow Plugin, OVSDB Plugin, OpenDove Plugin,...)
5. Application Modules (Simple Forwarding, Load Balancer)

+‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐+
| Connection |Network Config| Neutron |
| Service APIs| APIs | APIs |
+‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐+
| NorthBound API Layer (REST) |
+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+
+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+
| +‐‐‐‐‐‐‐‐‐‐‐‐+ +‐‐‐‐‐‐‐‐‐+ +‐‐‐‐‐‐‐‐‐+ |
| |Connection | |Topology | | Switch | |
| | Manager | | Manager | | Manager | |
| +‐‐‐‐‐‐‐‐‐‐‐‐+ +‐‐‐‐‐‐‐‐‐+ +‐‐‐‐‐‐‐‐‐+ |
| Network Service Functions Layer |
+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+
+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+
| +‐‐‐‐‐‐‐‐‐‐‐‐+ +‐‐‐‐‐‐‐‐‐+ +‐‐‐‐‐‐‐‐‐+ |
| |Connection | |Data Pkt | |Inventory| |
| | Service | | Service | | Service | |
| +‐‐‐‐‐‐‐‐‐‐‐‐+ +‐‐‐‐‐‐‐‐‐+ +‐‐‐‐‐‐‐‐‐+ |
| Service Abstraction Layer (SAL) |
+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+
+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+
| SouthBound API Layer |
| +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ |
| | OpenFlow Plugin| | OVSDB Plugin | |
| | +‐‐‐‐‐‐‐‐‐‐‐‐+ | | +‐‐‐‐‐‐‐‐‐‐‐‐+ | |
| | | Flow Prog | | | | Connection | | |
| | | Service | | | | Service | | |
| | +‐‐‐‐‐‐‐‐‐‐‐‐+ | | +‐‐‐‐‐‐‐‐‐‐‐‐+ | |
| | +‐‐‐‐‐‐‐‐‐‐‐‐+ | | +‐‐‐‐‐‐‐‐‐‐‐‐+ | |
| | | Data Pkt | | | | Net Config | | |
| | | Service | | | | Service | | |
| | +‐‐‐‐‐.‐‐‐‐‐‐+ | | +‐‐‐‐‐.‐‐‐‐‐‐+ | |
| | . | | . | |
| +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ |
+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+

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.

The rest of the document will cover the OVSDB SouthBound plugin design and architecture.

OVSDB Southbound plugin

Before diving into the OVSDB SouthBound Plugin design, how can we not give a commentary on The Open vSwitch Database Management Protocol
[RFC 7047] (http://tools.ietf.org/html/rfc7047).

[RFC 7047] and the [Schema] definitions (http://openvswitch.org/ovs­vswitchd.conf.db.5.pdf) gives all the theoretical info one would expect to know
with regards to OVSDB. [RFC 7047] is sufficiently generic in that it lays the ground work on the Wire Protocol and Database Operations, and the
[Schema] covers (currently) 13 OVS tables ­ With an eye for future schema expansion for OVS and by other vendors on proprietary implementations.

True to its name, it is a Database records Transport protocol using JSON RPC1.0. The authors of these 2 documents have done proper justice to this
subject.

But, you are up for a roller­coaster ride when you try it hands on. Take a peek @ a "transact" message and you will know what I mean :­)

It is nothing like your traditional Protocols that networking engineers are used to. Again, http://networkstatic.net/getting­started­ovsdb/ gives a more
practical look at the protocol structure.

https://wiki.opendaylight.org/view/OVSDB_Integration:Design 2/6
5/17/2017 OVSDB Integration:Design ­ OpenDaylight Project
The OpenDaylight OVSDB southbound plugin consists of one or more OSGi bundles addressing the following services or functionalities :

1. Connection Service ­ Based on Netty

2. Network Configuration Service
3. Bidirectional JSON­RPC Library
4. OVSDB Schema definitions and Object mappers
5. Overlay Tunnel management
6. OVSDB to OpenFlow plugin mapping service
7. Inventory Service

Connection Service

One of the primary services that most southbound plugins provide to SAL in OpenDaylight and NSF is Connection Service. The service provides
protocol specific connectivity to network elements, and supports the connectivity management services as specified by the OpenDaylight Connection
Manager. This includes :

1. Connection to a specified element given IP­address, L4­port, and other connectivity options (such as authentication,...)
2. Disconnection from an element
3. Handling Cluster Mode change notifications to support the OpenDaylight Clustering/High­Availability feature

By default, the ovsdb­server process running on the hypervisor listens on TCP port 6632 (this is configurable). The Connection Service takes in the
connectivity parameters from the connection manager including the IP­address and TCP­Port for connections. Owing to the many benefits it provides,
Connection Service will use the Netty framework (http://netty.io/) for connectivity purposes.

Every successful connection to a network element will result in a Node object (Refer to OpenDaylight SAL Node.java) with the type = "OVSDB" and
value = User­Readable Name of the Connection as specified by the Connection Manager. This Node object is returned to the OpenDaylight Connection
Manager and the application that invoked the Connect() functionality.

IPluginInConnectionService : public Node connect(String identifier, Map<ConnectionConstants, String> params)

And any subsequent interaction with this network element through any of the SAL services (Connection, Configuration, ...) will be via this Node
Object. This Node object will be added to the Inventory maintained and managed by the Plugin's Inventory Service (Section 3.7) The Node object will
also assist with the OVSDB to Openflow mapping (Section 3.6).

And of course, the Node and its "Name" holds the key to the stateful Netty Socket handler maintained under the Connection Object created during the
connect() call. It needs a special mention about the Netty framework's Channel concept, which provides the much needed abstraction on the pipelining.
With this Channel Pipelining and the asynchronous event handling, the message handling process gets much more streamlined and well understood.
Also, makes it easier to replace or manipulate the pipeline functions in a more controlled fashion. More on this in later sections.

Connect to ovsdb­server Successful Connection handling

Network Configuration Service

The goal of OpenDaylight's Network Configuration umbrella of Services is to provide complete Management Plane solutions needed in order to
successfully install, configure and deploy 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 those new network virtualization protocol plugins such as OVSDB JSON­RPC or
Traditional management protocols such as SNMP or any others in the middle.

The above definition and more information on Network Configuration Services are available at :
https://wiki.opendaylight.org/view/OpenDaylight_Controller:NetworkConfigurationServices

The current default OVSDB Schema's support the Layer2 Bridge Domain services as defined in the Networkconfig.bridgedomain component.

https://wiki.opendaylight.org/view/OVSDB_Integration:Design 3/6
5/17/2017 OVSDB Integration:Design ­ OpenDaylight Project
1. Create Bridge Domain : createBridgeDomain(Node node, String bridgeIdentifier, Map<ConfigConstants, Object> params)
2. Delete Bridge Domain : deleteBridgeDomain(Node node, String bridgeIdentifier)
3. Add configurations to a Bridge Domain : addBridgeDomainConfig(Node node, String bridgeIdentifier, Map<ConfigConstants, Object> params)
4. Delete Bridge Domain Configuration : removeBridgeDomainConfig(Node node, String bridgeIdentifier, Map<ConfigConstants, Object> params)
5. Associate a port to a Bridge Domain : addPort(Node node, String bridgeIdentifier, String portIdentifier, Map<ConfigConstants, Object> params);
6. Disassociate a port from a Bridge Domain : deletePort(Node node, String bridgeIdentifier, String portIdentifier)
7. Add configurations to a Node Connector / Port : addPortConfig(Node node, String bridgeIdentifier, String portIdentifier, Map<ConfigConstants,
Object> params)
8. Remove configurations from a Node Connector : removePortConfig(Node node, String bridgeIdentifier, String portIdentifier,
Map<ConfigConstants, Object> params)

The above services are defined as generalized entities in SAL in order to ensure it fits with all relevant SouthBound Plugins equally. Hence the OVSDB
plugin must derive appropriate specific configurations from a generalized request. For example : addPort() or addPortConfig() SAL service call above
takes in a params option which is a Map structure with a Constant Key. These ConfigConstants are defined in SAL networkconfiguration service :

public enum ConfigConstants {

TYPE("type"),
VLAN("Vlan"),
VLAN_MODE("vlan_mode"),
TUNNEL_TYPE("Tunnel Type"),
SOURCE_IP("Source IP"),
DEST_IP("Destination IP"),
MACADDRESS("MAC Address"),
INTERFACE_IDENTIFIER("Interface Identifier"),
MGMT("Management"),
CUSTOM("Custom Configurations");
}

These are mapped to the appropriate OVSDB configurations. So, if the request is to create a VXLAN tunnel with src­ip=x.x.x.x, dst­ip=y.y.y.y, then the
params Map structure may contain :

{
TYPE = "tunnel",
TUNNEL_TYPE = "vxlan",
SOURCE_IP="x.x.x.x",
DEST_IP="y.y.y.y"
}

The above params definition is just an example and this will be expanding based on various supported northbound APIs and the Network Service
Functions supported in the OpenDaylight Controller platform.

Please note that all of the APIs take in the Node parameter which is the Node value returned by the connect() method explained in Connection Service
in Section 3.1.
Please refer to these End­to­End examples to understand the Configuration Service and its operational relationship with other OVSDB
Components

Bidirectional JSON­RPC Library

After various attempts with existing and available json­rpc libraries, the OpenDaylight OVSDB project decided to design and implement a Bidirectional
JSON­RPC library (mainly due to the various limitations in the existing open­source alternatives). Due to the nature of the library, it is very easy to
design it as a module that manages the Netty connection towards the Element. But, it is much more benefitial to maintain the Netty connection and
Channel management at the Connection Service and let the JSON­RPC library be part of the Channel as instantiated by the Connection Service. This
provides the ability for connection Service to keep control of the pipeline and perform various OVSDB wire­protocol operations effectively.

The main responsibilities are of this Library are:

Demarshal and marshal JSON Strings to JSON objects

Demarshal and marshal JSON Strings from and to the Network Element.

This library will abstract all the wire­protocol headaches such as application level fragmentation and reassembly, Encoding formats, and others, and
provides simple and clean objects for others in the pipeline to work on.

At the time of this writing, we have a better understanding on the demarshaling piece of the puzzle. Our understanding on the marshaling is still
evolving and this section will be updated based on the research.

Please refer to these End­to­End examples to understand the operational relationships with other OVSDB Components

OVSDB Schema definitions and Object mappers

OVSDB Schema definitions and Object Mapping layer sits right above the JSON­RPC library which will map between the generic JSON objects to
OVSDB schema POJOs (Plain Old Java Object) and vice­versa. There is a value in providing this abstraction rather than having the POJO object
mapping done on the JSON­RPC library. This helps in evolving independently. This layer mostly provides the Java Object definition for the
corresponding OVSDB schema (13 of them) & 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 of things, the mapping logic differentiates the Request & Response messages as follows :

Request messages are mapped by its "method"

Response messages are mapped by its id which was originally populated by the Request message.

https://wiki.opendaylight.org/view/OVSDB_Integration:Design 4/6
5/17/2017 OVSDB Integration:Design ­ OpenDaylight Project
It is worth to note here that the JSON semantics of these OVSDB schema is quite complex and IMHO unnecessarily convoluted (though we appreciate
the intention of keeping it as generic as possible).
The following figures summarizes a couple of end­to­end scenarios :

End to End Examples

end­to­end handling of a Create Bridge request

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 (GRE, VXLAN, STT) is of a different topic.
The differences between these Tunnel Types are mostly on the Encapsulation and differences in the configuration. But can be treated uniformly for the
sake of this document. While Establishing a Tunnel using configuration service is a simple task of sending OVSDB messages towards the ovsdb­server,

https://wiki.opendaylight.org/view/OVSDB_Integration:Design 5/6
5/17/2017 OVSDB Integration:Design ­ OpenDaylight Project
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 & also helps in providing Service guarantees for the VMs using these Overlays with the help of
underlay orchestration.

This is an evolving topic and more information will be added once the use­cases are nailed down.

OVSDB to OpenFlow plugin mapping service

As explored in Section 3.1, the ConnectionService's connect() would result in a Node that represents a ovsdb­server. The CreateBridgeDomain()
Configuration on the above Node (as defined in Section 3.2) would result in creating a OVS bridge. This OVS Bridge is an OpenFlow Agent for
OpenDaylight's OpenFlow plugin with its own Node represented as (example) OF|xxxx.yyyy.zzzz.

Without any help from the OVSDB plugin, the Controller platform's Node Mapping Service would not be able to map the

{OVSDB_NODE + BRIDGE_IDENTFIER} <‐‐‐> {OF_NODE}.

Without such mapping, it wouuld be extremely difficult or very artificial for the applications to manage and maintain such nodes. This Mapping Service
provided by OVSDB plugin would essentially help in providing much more value added services to the orchestration layers that sit on top of the
Northbound APIs (such as OpenStack).

Inventory Service

Inventory Service provides a simple database of all the Nodes managed and maintained by the OVSDB plugin on a given Controller. For optimization
purposes, it can also provide enhanced services to the OVSDB to OpenFlow mapping service by maintaining the

{OVSDB_NODE + BRIDGE_IDENTFIER} <‐‐‐> {OF_NODE}

mapping because of the static nature of this operation.

What next
Again, stating the obvious, this is just a start and will act as a platform for a rich open­source based Network Virtualization services using OVS and
other OpenDaylight projects.

Retrieved from "https://wiki.opendaylight.org/index.php?title=OVSDB_Integration:Design&oldid=31445"

https://wiki.opendaylight.org/view/OVSDB_Integration:Design 6/6