Traditionally network elements are composed of two main functional parts, a “control” part that determines the policy of data flow, and a “flow” part that does the actual work of data routing. Usually, “control” part does the operation using tools such as Access Control Lists. These modules are propriety, and control commands used are vendor specific, therefore these are not inter operable and devices from different vendors should be configured separately. A diagram of a traditional network device may be seen below. Here typically both parts, including a ‘management’ part providing user interface, are embedded in the device itself


OpenFlow aims to be an open communication platform between “control” and “flow” parts of network elements, enabling a unified interface to “flow” parts of various vendors.

OpenFlow standardization is handled by Open Network Foundation (https://www.opennetworking.org/). Project site (https://www.opennetworking.org/sdn-resources/onf-specifications/openflow/) contains the latest requirements that an OpenFlow switch should have, and Control Application that uses OpenFlow interface. OpenFlow specification is a step through Software Defined Networking (http://en.wikipedia.org/wiki/Software-defined_networking).

As start of 2015, there are three main open controllers available. Project Floodlight (http://www.projectfloodlight.org/) is maintained by Big Switch Networks. OpenDayLight project (http://www.opendaylight.org/) is managed mainly by Cisco. ONOS, maintained by Open Networking Lab of Stanford University and supported by AT&T (http://onosproject.org/).

A good start on subject may be investigating OpenFlow whitepaper (https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf). In this document, purpose of Software Defined Networking is clearly stated as decoupling Control and Data planes. Data plane handles underlying network infrastructure and is controlled by Control Plane that implements network intelligence and state logic which enables custom programming due to actual needs, and flexible solutions of business requirements.

Traditional client-server structures have network traffic signature mainly from server to client, whereas, today data to be served is usually not static, but dynamically changing . The rise of cloud services, desire to have on-demand availability of business applications and corresponding infrastructure requires more rapid control of network elements. This should be similar to technical perspective of just-in-time strategy of modern business model.


Decoupling the interface enables rapid development of products by third parties.  End users have ability to configure their hardware due to their business model and changing needs, without depending on hardware manufacturers custom interfaces.