OpenFlow and SDN Adoption

OpenFlow is an existing technology derived from the academic labs. Its origins can be traced back to 2006, when Martin Casado as part of the “Clean Slate” program developed Ethane. They were trying to figure out ways to manage network state via a centrally managed global policy. The idea that networks are dynamic and non-symmetrical pose challenges in how to keep track of their state to enforce programmability. The program has now stopped, but produced several follow-up programs, including OpenFlow and SDN.

OpenFlow is not something that is revolutionary new. Similar ideas have been available in the past and prior projects tried to solve the same problems OpenFlow is trying to solve today. Besides the central viewpoint use case, whatever you can do with OpenFlow today is possible with Policy Based Routing (PBR) and ACL. The problem is that these tools are clumsy and do not scale well.


SDN architectures and OpenFlow

SDN architectures and OpenFlow offer a number of advantages. You can influence traffic forwarding behavior at a more granular flow level. A holistic view instead of a partial view of distributed devices simplifies the network. Traffic engineering with SDN becomes easier to implement when you have a centralized view and this is how Google implemented SDN. Google has two network backbones; Internet facing and data centre backbone. They were noticing that the cost/bit was not decreasing as the network grew. It was actually doing the opposite. Their solution was to implement a centralized controller and manage the WAN as a fabric and not as a collection of individual nodes.

SDN architectures allow networks to move from loosely coupled systems to a virtual switching fabric. One big flat virtualized network that appears and can be managed as a single switch has many operational advantages. The switch fabric still consists of multiple physical nodes, but it behaves like one big switch. For example, a port on any of the underlying switch fabric nodes or virtual switch appears as a port to the single switching fabric. The entire data plane becomes an abstraction. By employing this architecture, we manage the data plane as a whole entity, opposed to a set of loosely coupled connected devices.


If we study existing networks, the control plane and data plane are distributed to the exact same locations. There is no central point controlling individual nodes, resulting in complex cross-network interactions.




Open Shortest Path First (OSPF) calculates a shortest-path tree from each node to every other node. Each OSPF neighbor must establish an adjacency, build, and synchronize the link-state databases (LSB) with each other. The complexity can be reduced by designing OSPF areas with ABR’s, but by sacrificing some precision of route informationImagine that every node reports and synchronize its LSB to a central controller with an OSPF SDN application, instead of individual nodes. The controller can then perform the Shortest Path First (SPF) calculation and update the forwarding information base (FIB) of each node directly. The network now becomes programmable. While it does bring advantages, the laws of physics have not changed. OpenFlow does not decrease latency or let you push more bits through a link. It does, however, let you manage and control your network better. It removes the box by box mentality, introduces automation and programmability.


SDN central


OpenFlow has come up against some market adoption barriers, such as silicon-challenges and numerous vendor specific extensions. The lack of conformance tests has led to some inconsistencies. Do you think OpenFlow will be derailed?

It depends on how you define it. In order to define it you need to know what it is not. It is not a controller or a forwarding switch, but a means of communication between the two. It has a distinct place in the SDN architecture and does not run anywhere except between the control (controller) and the data plane (switch infrastructure). OpenFlow is also not alone in this space and other technologies exists providing control and data plane communications, such as BGP, Open vSwitch Database Management Protocol (OVSDB), NETCONF and Extensible Message and Presence Protocol (XMPP). Juniper’s OpenContrail uses XMPP.


It is at evolving stages and emerging technologies are sometimes slow to adopt. For example, in the early days of Novell networks, there were 4-frame types. OpenFlow is changing and adapting as time progresses. The original version of OpenFlow did not have multiple flow tables; now, versions 1.3 and 1.4 have multiple tables with multiple actions and lots of additional features.


Will it be used for program forwarding paths instead of BGP?

Probably not but it will be used to augment BGP and other traditional technologies. It is not strictly a YES or NO answer as the SDN adoption falls into two buckets: one with OpenFlow and one without. Take the IPv6 adaptations as the IPv4 “replacement”. There was a “D” day of IPv4 address exhaustion, but IPv4 is still widely used. New “transition” mechanisms such as 6to4 and NAT64 are still widely deployed. It is the same with SDN and OpenFlow. There will be ways to make traditional networks communicate with SDN and OpenFlow. BGP was invented as an EBGP but people are using EBGP Internal to their network. BGP is also used as an SDN control plane. It will be the case that you have controllers that provide automation and a holistic view but can speak BGP or OSPF to program the forwarding devices. SDN migrations will come incrementally, similar to what we see with IPv4 and IPv6.





The progress in OpenFlow has been limited by the lack of clarity in the controller space. But; now the controller market is consolidating, which gives users a clear path forward. This emergence is a good thing and will move OpenFlow forward. To maintain SDN applications on different controllers is a dead-end but now that OpenDaylight is emerging we have controller unity. A market with numerous open source controllers would make SDN application development difficult. There will always be business drivers for proprietary controllers that serve a particular niche and corner case problem that the open community did not invest in. Even today when you look at open Linux, there is still specialized UNIX platforms. Similarly, this flow of technology adoption will be evident for OpenFlow controllers.


About Matt Conran

Matt Conran has created 184 entries.

Leave a Reply