Fundamentals of OpenFlow

Fundamentals of OpenFlow

Conventionally networks are hierarchical, built with tiers of Ethernet switches arranged in a tree structure. This design created sense once client-server computing was dominant, however, such a static design is ill-suited to the dynamic computing and storage desires of today’s enterprise campuses, carrier environments data centers. Delivering network agility has become the prime objective for any organizations to meet fast growing business needs. Some trends igniting these changes are IT Consumerization, cloud services, data center traffic pattern and bandwidth.

Current Challenges before Network Managers

Existing network architectures were not designed to meet the requirements of today’s users, enterprises, and carriers; few of the important challenges which bring constraints before the network architects are:

  • Network Complexity & Virtualization: It includes a set of challenges due to multiple protocols, link speeds, fixed topologies and multiple touch points in the network. This very nature of network makes it static and does not complement server virtualization.
  • Mega Scalability: Oversubscription has become the bottleneck for large data centers, because of various reasons including dynamic traffic patterns. Google, Yahoo!, and Facebook employ large scale parallel processing algorithms & hyper-scale networks that can provide high-performance, low-cost connectivity among thousands of physical servers. Such scaling cannot be done with manual configuration.
  • Vendor Dependency: Lack of standard, open interfaces limits the ability of network operators to tailor the network to their individual environments. This mismatch brought industry to the tipping point and force industry to go towards software-defined networking architecture.

Software-defined Networking (SDN) is an emerging framework where network control plane is decoupled from forwarding and is directly programmable. Network intelligence is (logically) centralized in software-based SDN controllers,that maintain a global view of the network.

The OpenFlow protocol uses a consistent instruction set, which implies that any OpenFlow controller can send a standard set of instructions to any OpenFlow-enabled switch, in spite of vendor. The OpenFlow protocol is implemented on either side of the interface between network infrastructure devices and also the SDN controller software/appliance. OpenFlow uses the construct of flows to spot network traffic supported pre-defined match rules that may be statically or dynamically programmed by the SDN management software.

OpenFlow Approach & Components

  • OpenFlow Configuration Protocol It establishes the relationship between controllers and switches, enabling a standard configuration and management method for switches. Currently, there is work underway on two configuration and management protocols for OpenFlow switches: OpenFlow Management and Configuration Protocol (OF-Config) and Open vSwitch Database Management Protocol.
  • OF-Config is being developed under the Open Networking Foundation and was designed to apply to all OpenFlow implementations and on both physical and virtual switches.
  • OVSDB is a component of the open source Open vSwitch that was designed specifically to manage Open vSwitch implementations. Other switch vendors who want to adopt OVSDB would need to modify their switch’s configuration database and implement JSON and JSON-RPC.
  • OpenFlow Capable Switch
  • OpenFlow Controllers



OpenFlow version 1.1 Packet Flow



OpenFlow-based SDN technologies enable IT to address the high-bandwidth, dynamic nature of today’s applications, adapt the network to ever-changing business needs, and significantly reduce operations and management complexity.

Open daylight Applications

The key thing that OpenDaylight aspires to provide an application developer is independence from device specifications. For a developer, it would be invaluable to be able to focus only on the application logic and business problems rather than focusing on how a particular device behaves and what mechanism is used to interact with it.

Network devices talk to the OpenDaylight controller through their respective protocol modules. The protocol plugins, in turn, communicate with the SAL layer’s exposed API. SAL converts the language spoken by the protocol plugins into application-specific APIs – all the while upholding the functionality required by the application’s business logic. An application for OpenDaylight Platform can be developed using two broad methodologies:

  • RESTful API: RESTful APIs can be provided by any plugin integrated into the OpenDaylight platform as part of their northbound interfaces. Though almost all the APIs provide the RESTful XML Schema for data interaction, some of the APIs may as well support the JSON structure. Few RESTful API exposed by ODL plugin are Flow Programmer, Static Routing, Topology, Subnets, User & Switch Manager & Statistics etc.
  • Open Service Gateway Interface (OSGi): An OpenDaylight application using OSGi Interfaces is effectively a northbound plugin, developed and embedded into the framework as a bundle. Each plugin essentially defines a list of services, which it provides and consumes.


The application developer can choose from Model Driven or API-driven API methodology.  The model-driven methodology focuses on developing an OpenDaylight plugin through the use of YANG based models for internal and external APIs. Whereas, application-driven methodology focuses on the development of a standalone service consumer, consuming services produced by basic or domain-specific service plugins. Kindly refer to an article on MD-API for more details on this topic.

Add to Favorites