A primer on software defined networking (SDN) and OpenFlow standard


software defined network and openflow standard

Continuous innovation and the need to adapt to the constraints of conventional networking has made software defined networking (SDN) pretty popular. It is an approach that disassembles the network’s control plane and data plane. This allows network administrators to program directly without having to worry about the hardware specifications.

OpenFlow, the first SDN standard, is a communication protocol in software defined networking (SDN). It is managed by the Open Networking Foundation (ONF). The SDN controller or the ‘brain’ interacts with the forwarding (data) plane of the networking devices like routers and switches via OpenFlow APIs. It empowers the network controllers to decide the path of network packets over a network of switches. The OpenFlow protocol is required to move network control out of exclusive network switches and into control programming that is open source and privately overseen.

Software-defined networking uses southbound APIs and northbound APIs. The former are used to hand over information to the switches and routers. OpenFlow is the first southbound API. Applications use the northbound APIs to interact.

Porting an OpenFlow switch in ns-3

The OpenFlow 1.3 module for ns-3, widely known as the OFSwitch13 module, was intended to boost the ns-3 network simulator with SDN technology. An OpenFlow switch is a package that routes packets in the SDN environment. The data plane is referred to as the switch and the control plane is referred to as the controller. The OpenFlow switch interacts with the controller and the switch is managed by the controller via the OpenFlow protocol.

The fundamental components of the OpenFlow switch (as shown in Figure 2) incorporate at least one flow table, a meter table, a group table and an OpenFlow channel to an exterior controller. The flow tables and group table perform the packet scanning and forwarding function based on the flow entries configured by the controller. The routing decisions made by the controller are deployed in the switch’s flow table. The meter table is used for the measurement and control of the rate of packets.

Figure 1: Traditional network architecture vs SDN architecture
Figure 2: OpenFlow switch components

Configuring the SDN OFSwitch

In this article, we have incorporated the OFSwitch13 (version 1.3) with ns-3. To benefit from the features of OFSwitch13, an ofsoftswitch13 library is used. All the commands given below have been tested on Ubuntu 16.04 and might change for other versions or distributions.

Before that, there are a few bundles to be introduced on the system:

$ sudo apt-get install build-essential gcc g++ python git mercurial unzip cmake

$ sudo apt-get install libpcap-dev libxerces-c-dev libpcre3-dev flex bison

$ sudo apt-get install pkg-config autoconf libtool libboost-dev

In order to utilise ofsoftswitch13 as a static library, you need to introduce the Netbee library, as the ofsoftswitch13 library code relies upon it.

$ wget https://bitbucket.org/ljerezchaves/ofswitch13-module/downloads/nbeesrc.zip

$ unzip nbeesrc.zip (for unzipping)

$ cd netbee/src/

$ cmake .

$ make

$ sudo cp ../bin/libn*.so /usr/local/lib

$ sudo ldconfig

$ sudo cp -R ../include/* /usr/include/

Now, clone the repository of the ofsoftwsitch13 library, as follows:

$ git clone https://github.com/ljerezchaves/ofsoftswitch13

$ cd ofsoftswitch13

$ ./boot.sh

$ ./configure –enable-ns3-lib

$ make

Figure 3: Network topology

Integrating OFSwitch with ns-3

To install ns-3.26, use the following command:

$ hg clone http://code.nsnam.org/ns-3.26

In the ns-3.26 directory, download the repository of OFSwitch13, as follows:

$ hg clone https://bitbucket.org/ljerezchaves/ofswitch13-module src/ofswitch13

$ cd src/ofswitch13

$ hg update 3.1.0

$ cd ../..

$ patch -p1 < src/ofswitch13/utils/ofswitch13-src-3_26.patch

$ patch -p1 < src/ofswitch13/utils/ofswitch13-doc-3_26.patch

The file ofswitch13-src-3_26.patch will allow OFSwitch to get raw packets from nodes (devices). To do this, it will create a new OpenFlow receive callback at CsmaNetDevice and virtualNetDevice. The file ofswitch13-doc-3_26.patch is optional but preferable.

After successful installation, configure the module, as follows:

$ ./waf configure --with-ofswitch13=path/to/ofsoftswitch13

$ ./waf configure --enable-examples --enable-tests

Now, we’re all set. Just build the simulator using the following command:

$ ./waf

Enjoy the ns3.26 simulator with the power of SDN, i.e., OFSwitch 1.3.

Figure 4: Output of ofswitch13-modify.cc
Figure 5: Output of the log file

Simulating the basic network topology with SDN based OFSwitch

In this section of the article, we’ll simulate a basic network topology with three hosts, a switch and a controller.

Figure 3 demonstrates the topology of the network that we want to create. It includes three hosts, one switch and one controller.

Here, host2 pings the other two hosts—host1 and host3. Whenever either of the hosts makes a ping request, it is forwarded to the switch. This is indicated by arrows shown in blue. As this is the first request, the switch’s flow table will not contain any entry. This is known as a table miss. Thus, the request will be forwarded to the controller.

The controller will instruct the switch with respect to the routing decision to be made and to also modify the flow table in the switch. This is shown by the arrows in green. The request will then be forwarded by the switch to the appropriate destination, i.e., to host1 and host3.

The next time the same request is forwarded to the switch, the switch’s flow table will contain an entry for that request and, thus, the switch itself will make routing decisions based on that entry, without the controller in action.

The explanation for the code to simulate the above topology is given below. Only the required extracts of the code are given. The accompanying lines of code demonstrate the extra header documents required for re-enacting wired systems.



The following lines of code create an object called ‘hosts’ of class NodeContainer common to all the other nodes. Here, three hosts are created.

NodeContainer hosts;

hosts.Create (3);

Ptr<Node> switchNode = CreateObject<Node> ();

//to create node for switch

CsmaHelper csmaHelper;

NetDeviceContainer hostDevices;

NetDeviceContainer switchPorts;

for(size_t i = 0;i<hosts.GetN();i++) //linking between hosts and switch


NodeContainer pair (hosts.Get (i), switchNode);

NetDeviceContainer link = csmaHelper.Install (pair);

hostDevices.Add (link.Get (0)); //two way linking

switchPorts.Add (link.Get (1));


Ptr<Node> controllerNode = CreateObject<Node> ();

//to create node for controller

Here, ofswitch13 domain comes into action.

Ptr<OFSwitch13InternalHelper> of13Helper=CreateObject<OFSwitch13InternalHelper>();

of13Helper->InstallController (controllerNode);

//to install controller on node

of13Helper->InstallSwitch (switchNode, switchPorts);

//to install OFSwitch

of13Helper->CreateOpenFlowChannels ();

//for creating channels between Switch and controller

Ipv4AddressHelper ipv4helpr; //set IPv4 addresses

Ipv4InterfaceContainer hostIpIfaces;

ipv4helpr.SetBase (“”, “”);

//IPv4 range starts from

hostIpIfaces = ipv4helpr.Assign (hostDevices);

Below lines will configure ping applications between hosts-

V4PingHelper pingHelper = V4PingHelper (hostIpIfaces.GetAddress (1));

pingHelper.SetAttribute (“Verbose”, BooleanValue (true));

ApplicationContainer pingApps1= pingHelper.Install (hosts.Get (0));

pingApps1.Start (Seconds (1));

ApplicationContainer pingApps2 = pingHelper.Install (hosts.Get (0));

pingApps2.Start (Seconds (1));

Here, two hosts and one object of class ApplicationContainer called pingApps is created.

Now the code for simulator to work-

Simulator::Stop (Seconds (10)); //simulation time is 10 seconds

Simulator::Run ();

Simulator::Destroy ();

It is recommended that you save ofswitch13-modify.cc at this path (ns-dev/scratch/).

To run the program, use the following command:

$ ./waf --run ofswitch13-modify

The output is given in Figure 4.

As shown in the figure, the host with the IP address pings the other two hosts, and the ping is successful with nine packets being transmitted. The time statistics are also shown.

In the program’s code, to view the log file, set trace=true. This will generate switch-stats-1.log in the ns-dev folder.

Figure 6: Position of hosts in NetAnim
Figure 7: Packet flow in NetAnim

Visualising the basic working of the controller switch using Net Animator

Network Animator, also known as NetAnim, is used to graphically portray projects in ns-3. It is an offline animator, which animates the XML file generated during the simulation program in ns-3. ns-2 has many default animators for use but ns-3 is furnished with no default animator. So, we have to integrate NetAnim with ns-3. NetAnim version 3.107 is used for visualising.

To visualise the above program code (ofswitch13-modify.cc) in NetAnim, take the following steps.

Add the following few lines of code:

#include <ns3/netanim-module.h>

// extra header file for Network Animator in ns3

AnimationInterface::SetConstantPosition (hosts.Get(0),50,50);

AnimationInterface::SetConstantPosition (hosts.Get(1),10,60);

AnimationInterface::SetConstantPosition (hosts.Get (240, 25);

AnimationInterface anim (“ofs13-modify.xml”);

The above four lines of code will set the position of the hosts (nodes) at the given coordinates on the X-Y plane (refer to the screenshot in Figure 6), and then generate the ofs13-modify.xml file for the ofswitch13-modify.cc.

In Figure 6, the node with the IP address 10.100.1 (the upper left corner) represents OFSwitch with SDN controller. The other three nodes are the created hosts.

  • Node 0:
  • Node 1:
  • Node 2:

Figure 7 is a screenshot of the generated XML file with graphical simulation in NetAnim.



Please enter your comment!
Please enter your name here