How are OVS, OVN, OVSDB and OpenFlow related?

We have seen these OVS, OVN, OVSDB and OpenFlow in various technology articles.  Do you know how they are related?  Or are they related at all?

Well, they all start with the letter "O", this will be great for a Sesame Street episode for us to learn words with the letter "O".  

They all start with the letter O because they are all have "open" in their name.

With "open" in their name, does that make them related?

OVS, OVN, OVSDB and OpenFlow are related but not because they have "open" in their name.

Before we look at how they are related let us take an overview of what they are and some of the key concept that we need to know.  We can only take an overview of OVS, OVN, OVSDB and OpenFlow in this post as they by itself can be one or more blog post to cover.

OVS

OVS is the short form of Open vSwitch.  It is an open source software based virtual network switching module that can be deployed on hypervisor such as KVM or white box switching hardware.   Detail description of OVS can be found on it homepage and GitHub page. 

A list of OVS feature can be found here.  The latest version is release 1.5

OVS is heavily used in OpenStack as KVM is the most deployed hypervsior for OpenStack while OVS is the default virtual switching module for KVM.

This diagram from OVS home page describe what OVS is:

image source: http://openvswitch.org/

As you can see both OpenFlow and OVSDB is related to OVS.  Will discus this in more detail later in this post.

 

OVN

OVN stands for Open Virtual Network and is pronounced as "oven".  This is why the logo looks like the front of an oven.  It is a sub-project within OVS.

Back in March 2015, I have already written an article on OVN.  Please refer to this post for OVN details.

OVSDB

OVSDB is a protocol. It stands for Open vSwtch Database Management protocol. It is used to manage an Open vSwitch. This is the management plan for Open vSwitch. It is defined in RFC 7047.

The heart of OVSDB is the database or schema that defines the configuration of the OVS as well as the QoS policies. Management module uses the JSON-RPC as the transport to communicate with the ovsdb-server module of the OVS. (note: JSON = JavaScript Object Notation and JSON-RPC is a Remote Procedural Call encode in JSON format).

OpenFlow

OpenFlow is a protocol.  It is one form of  control plane for Open vSwitch and is defined in RFC 7149.

The main idea is to setup flow table that defines the action of a particular flow.  The basic action types are forward and drop with other optional/recommended actions such as flood, enqueue or modify field.  

This diagram explains the Flow Table:

 

Putting OVS, OVN, OVSDB and OpenFlow together

This diagram summarize the relationship between OVS, OVSDB and OpenFlow

At this time OVN is part of OVS and uses the same interface ovsdb-server and ovs-vswitchd:

Summary

Both OVS and OVN are open source switching modules with OVSDB as the management plane and OpenFlow is used to program the flow from the controller to the OVS.

Network Virtualization for OVS (Open vSwitch) - Open Virtual Network

Open vSwitch is a open source virtual switch that provide logical switching on hypervisors similar to the VMware vSwitch and the Cisco Nexus 1000V. Full feature of Open vSwitch can be found here.  We can find good resource on Open vSwitch here and here

Open vSwitch has 3 main components:

• ovsdv-vswitchd
• ovsdb-server
• Kernel module

 

image source: http://www.jedelman.com/uploads/9/7/8/6/9786883/8614557.jpg?531

This diagram explain the operation of Open vSwitch very well.  Visually we can see the various components in a physical host (a picture is worth a thousand words).

 

image source: https://networkheresy.files.wordpress.com/2011/06/screen-shot-2011-06-05-at-6-44-32-pm.png

When we look at the features supported by Open vSwitch (OVS), we see that the list is very comprehensive for a switch.  (note: a switch is for layer 2 switching, check out my other post if you are not familiar with the 7 Layers of the OSI model).  There are 2 features on the list that makes OVS a good tool for OpenStack.  The 2 features are:

1. OpenFlow protocol support
2. Multiple tunneling protocols (GRE, VXLAN, IPsec, GRE and VXLAN over IPsec)

According to this article, OVS is the most popular plugin for OpenStack.

Open Virtual Network

On Jan 13, 2015, it was announced that a new sub-project was created under the OVS project - Open Virtual Network (OVN).

The main idea of Open Virtual Network is provide a lightweight control plane that provides native support for common virtual networking abstractions.  

Open Virtual Network (OVN) will include:

• logical switches and routers,
• security groups, and
• L2/L3/L4 ACLs,

and they are to be implemented on top of a an overly network such as VXLAN, NVGRE or GENEVE.   This is  most suitable to integrate with OpenStack Neutron as a plugin.

This article further explain that OVN provide Neutron with improved data plane performance through shortcut, distributed logical L3 processing and in-kernel based security groups, without running special OpenStack agents on hypervisors. Lastly, it will provide a scale-out and highly available gateway solution responsible for bridging from logical into physical space.

OVN will also work with Linux container systems.  Containers are also widely deployed in the OpenStack platforms. I also had a blog post on this topic on my OpenStack for Beginners series.

Open Virtual Network Architecture
Open Virtual Network builds on top of OVS and has the following layers:

1. Open vSwitch
2. OVN Controller
3. OVN Database

Detail of the OVN architecture can be found in this OVN Architectural Guide.

1. Open vSwitch
As Open Virtual Network is a sub-project OVS and is therefore a natural layer for the foundation.  OVS has special extension for OpenFlow support and thus OVN is tailor to how OVS used OpenFlow.  OVN may not work with other OpenFlow implementation.

OVN used the OVS integration guide (IntegrationGuide.md) in the OVS repository.  This defines the interaction between the OVN controller and the hypervisor or container that used the OVS.

2. OVN Controller
This controller resides on each hypervisor and is not a centralized model that is popular on most SDN implementation.  The OVN controller runs on the hypervisor or host as a daemon.  The OVN controller on the southbound interface with the ovs-switchd using the OpenFlow protocol and the ovsdb-server using the OSVDB protocol. And on the northbound interfaces with the OVN Database using the OSVDB protocol.

This diagram is taken from the OVN Architecture Guide:

                             OVN Database
                                    |
                                    |
                          (OVSDB Protocol)
                                    |
   +-------------------------------------------------------------------+
   |                                |                                  |
   |                                |                                  |
   |                           ovn-controller                          |
   |                              |     |                              |
   |                              |     |                              |
   |               +--------------+     +--------------+               |
   |               |                                   |               |
   |               |                                   |               |
   |       (OVSDB Protocol)                       (OpenFlow)           |
   |               |                                   |               |
   |               |                                   |               |
   |         ovsdb-server                         ovs-vswitchd         |
   |                                                                   |
   +---------------------------- Hypervisor ---------------------------+

3. OVN Database
At this initial state of OVN, OVSDB is being used as the OVN Database. One of the design goal for the OVN Database is high availability but the ovsdb-server does not support clustering and it is important to resolve this issue as the OVN is supported to be a production ready feature.

This OVN Database stores 3 types of information:

1. Physical Network Information
2. Logical Network Information
3. Binding (logical element location, logical port and MAC address association)

Cloud Management System
Open Virtual Network requires a Cloud Management System such as OpenStack to function.  There is a plugin available for OpenStack and OVN integration.  This plugin translate the Cloud Management System configuration into the OVN Logical network information (in the form of logical data path flows) that are stored in the OVN Database.

More to come in the near future
Hopefully, we can see more development of this Open Virtual Network soon and if I am able to attend the OpenStack Vancouver summit I will certainly gather more information in this area and share them in this blog.

Reference:

"Features." Features. N.p., n.d. Web. 12 Mar. 2015.

 "OVN, Bringing Native Virtual Networking to OVS." Network Heresy. N.p., 13 Jan. 2015. Web. 12 Mar. 2015.

OpenDaylight - an alternative to VMware NSX and Cisco XNC.

Before I worked on this blog post, I always think that OpenDaylight is a SDN Controller.  While it is correct to say that OpenDaylight is a SDN controller, it is in fact an Open Source project in which the controller is the core functionality.  In OpenDaylight wiki page, we can see a list of projects that is under the umbrella of OpenDaylight Project from the Linux Foundation. 

OpenDaylight Project is described by this web site as:

The OpenDaylight Project is a collaborative open source project that aims to accelerate adoption of Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) for a more transparent approach that fosters new innovation and reduces risk. Founded by industry leaders and open to all, the OpenDaylight community is developing a common, open SDN framework consisting of code and blueprints

According to Neel Jacques, executive director of OpenDaylight:

“The OpenDaylight community has taken on the monumental task of bringing together all the disparate technologies, thoughts and ideas around SDN and forming it into a cohesive platform. The community has made amazing progress in a short amount of time as you can see in this second release which integrates more functionality, apps and use cases. Helium brings us one step closer to having one common platform the entire industry can standardize on.”

OpenStack name its release by city or street name.  OpenDaylight name its release by elements in the Periodic Table.  The first release was Hydrogen and the second release was Helium.  The OpenDaylight Helium release was available for download as of September 29, 1014.

Image source: https://www.sdncentral.com/wp-content/uploads/2014/09/opendaylight-project-helium-diagram.jpg

From OpenDaylight’s announcement “OpenDaylight paves way for innovation in SDN with latest open source software release”, I have summarized what’s new in the Helium release:

• 11 new protocols, applications and technologies
• New User Interface
• Simpler and customizable installation process
• User can build on-demand combinations of components and features to customize their solutions
• Open vSwitch Database Integration Project that provides technology preview of advanced OpenStack features
• High Availability
• Clustering
• Security
• OpenFlow Table Type Patterns
• Service Function Chaining

There are 3 things that I would like to highlight and comment:

1. Apache Karaf

One good feature for the Helium release is that user can build on-demand combinations of components and features for OpenDaylight.  This is done by Apache Karaf which is a small OSGi (Open Service Gateway initiative) based run time lightweight container where different components and applications can be deployed.  The best feature in my opinion is the ability to check for component dependencies.  Remember the days how we install packages onto a Linux system before apt-get or yum?

2. Integration with OpenStack

I believe for OpenDaylight to have more integration with OpenStack will entice more commercial IT vendors to embrace OpenDaylight.  Both VMware and Cisco announced integration with OpenStack and there are quite a few companies such as Rackspace, Metacloud, Mirantis, Cloudscaling, IBM and Red Hat that provide value added and easy installation for the Open Source OpenStack.

Work is done for the OVSDB (Open vSwitch Database) driver to provide features such as:

• Distributed L3 Forwarding
• Distributed ARP handling
• Security Group
• Load Balancing as a Service
• Firewall as a Service

This makes OpenDaylight an attractive choice as a OpenStack Neutron back end.  Also, there is a new feature to provide VLAN networking in addition to the tunnel-based networking option when a virtual network is created in OpenStack Neutron.

Interface with OpenStack with Keystone via the OpenDaylight AAA project is a big step forward between OpenDaylight and OpenStack integration.

3. Security

In the Hydrogen release, there is the Defense4All project for mitigating Distributed DoS attacks.  In the Helium there are 2 new projects for security:

1. Authentication, Authorization and Accounting (AAA)
2. Secure Network Bootstrapping Infrastructure (SNBi) project.

In this article, author Sean Michael Kerner stated that “Security is a particular area of focus in the Helium release”.

Authentication, Authorization and Accounting

AAA has been around for some time and is a popular and widely used security architecture where user’s credential is authenticated and based on the outcome of the authentication process, access for resources are granted/authorized while accounting will record this process so as to provide an audit trail.

According to a Red Hat blog, AAA project provides:

1. The ability to provide fine-grained permissions for resource usage
2. The ability to share an external identity service with other platforms

In our case as mentioned on the previous section, the external identity service will be OpenStack Keystone.

Secure Network Bootstrapping Infrastructure

This feature helps to solve the problem of having to manually distribute keys for the different networking device to communicate with each other. 

This page has more information about how this works.

Conclusion:

Besides, OpenStack integration and security both High Availability and clustering are important feature for the enterprise. OpenDaylight Helium is a big step forward from the Hydrogen release and hopefully more vendors will embrace OpenDaylight and provide this as an alternative to 

• Cisco - Extensible Network Controller
• HP - Virtual Application Networks (VAN) Controller
• NEC - ProgrammableFlow PF6800 Controller
• Nuage Networks - Virtualized Services Controller  
• VMware - NSX Controller