Open networking standards and the road to agility, part 6: OVSDB

Posted by admin May 21, 2015
Open networking standards and the road to agility, part 6: OVSDB

For the next entry in our series on open networking standards, we'll turn to the Open vSwitch Database Management Protocol, also known as OVSDB. A previous post covered Open vSwitch more generally, touching upon its features as a multi-layered switch. From an SDN perspective, you can think of Open vSwitch as the most popular open source implementation of OpenFlow, the protocol that enables flow- rather than destination- based networking, while specifying a centralized controller that runs in software (i.e., for SDN automation and orchestration). So what does OVSDB in particular accomplish?

Open vSwitch Database Management Protocol's place within open source networking
As Mike Cohen recently explained in a guest post for TechCrunch, OVSDB was originally conceived as a handler for tasks not covered under the design of OpenFlow. Its relationship with OpenFlow, as well as its prominence within the OpenDaylight software project and Open vSwitch itself make it a good subject to cover as we continue this education series.

Imagine a typical Open vSwitch implementation, with communications between a switch's daemon and a database server. In this setup, OVSDB supplies important information to the database server and, like OpenFlow, acts as a programmatic extension of Open vSwitch. With switches receiving instructions from various network managers and controllers, OVSDB allows for granular management of the switch's configuration such as bridges, ports and tunnels.

"Using the OVSDB Protocol, managers can specify the number of individual virtual bridges within an Open vSwitch implementation and create, configure and delete ports and tunnels from a bridge," explained David Jacobs of The Jacobs Group in a 2013 post for TechTarget. "A manager can also create, configure and delete queues."

Moreover, it forms a powerful arrangement alongside OpenFlow. The latter governs the direct packet flows while OVSDB takes cares of the ports and tunnels they traverse, making SDN possible.

This interplay is critical. Much of the discussion about SDN is about how it implements forwarding control especially via OpenFlow (though it's not the only protocol for this purpose), which is undeniably a big change from legacy networking. However, the contribution of OVSDB is arguably just as important, as University of Kentucky network engineer Brent Salisbury pointed out in remarks to TechTarget.  

Open vSwitch Database Management Protocol and OpenDaylight
OVSDB is used in Open vSwitch, OpenDaylight and some physical switches. For example, in OpenDaylight, there can be southbound configuration of Open vSwitch nodes via OVSDB alongside the usage of northbound APIs for interfacing with OpenStack Neutron, which we covered in our series entry on OpenStack and its components.

Overall, OVSDB can facilitate a certain consistency in the management of OpenFlow-enabled switches. At the same time, it contributes to the vendor-neutral, interoperable ideal of SDN orchestration across today's infrastructure.

"Beyond orchestration, OVSDB integration into OpenDaylight broadens the possibilities for vSwitch implementation and standardizes management across environments," observed Rivka Gewirtz Little, senior site editor for TechTarget. "The controller will be able to direct and manage any implementation of an Open vSwitch environment, regardless of vendor or orchestration strategy."

That said, OVSDB isn't without its critics. Cisco for instance cited the protocol's limited capabilities in exposing "vendor innovations" in making a case for OpFlex, the protocol that the networking giant has developed and pushed into the OpenDaylight ecosystem. Like OpenFlow, OVSDB is synonymous with open source and centrally controlled SDN, but it remains to be seen if that vision can overcome the intentions of some of the industry's largest incumbents.

The takeaway: The Open vSwitch Database Management Protocol is an open source protocol that supplements and works alongside OpenFlow toward the end of SDN orchestration. More specifically, it handles the configuration of the ports and bridges that OpenFlow packets pass through. An important cog in the open networking community, its relationship with OpenDaylight and that project's members highlights how SDN is changing both the technical and business sides of networking.