Doing Software-Defined Networking(SDN) Simulation under ns-3

The default ns-3 will contain OpenFlow extension module. But to use that module, we have to install a suitable version of OpenFlow switch library (as an external library) and have to enable it while configuring ns-3 with the OpenFlow extension. After that, only the ns-3 will get compiled successfully with OpenFlow module. The default ns-3 version of OpenFlow module only has limited support.

So, for advanced SDN simulations, we will need to install an entirely new OpenFlow switch module version 1.3 called as ‘OFSwitch13″ (-libns3ofswitch13.a) and have to install the suitable ns-3 extension code ofswitch13, to use that library to do SDN simulations.

Before starting to do the SDN simulations, first we may try to understand what is really an SDN.

Software-Defined Networking–Is it fully a Software Entity?

When I first heard the word “SDN” – the Software-Defined Networking, idiotically, I thought of it as a complete software entity like a virtual machine (VM) or as any other virtual cloud hardware. But definitely, it is not a 100% software-only technology like a VM or a Cloud.

This confusion started only because I tried to understand what is “SDN” while learning SDN under ns-3. Under ns-3 every networking hardware is simulated with a piece of software module. – So it led me to such a silly misunderstanding since all the components of SDN and OpenFlow switches and other things that are available as software entities under the network simulator.

(And even theoretically it is possible to simulate a 100 virtual SDN only through virtualization of every aspect of SDN – but in a practical SDN, it contains both hardware and software.)

So, from the same idiotic point of view, What is a software-defined network or networking?

In simple terms, if a network composed of some networking hardware, such as switches and routers, can be dynamically configured and controlled with some software, then we can call it an SDN. (Another idiotic question in my mind: I can configure my two-decade-old router from a remote terminal window – can I now call my network as SDN? )

Ok. Can we make an SDN out of the old switches and routers that you have in your garbage? — certainly not – because such old devices could not understand the language of SDN called ‘OpenFlow’.

So to make a network as a modern ‘software-defined network” the hardware components of that network should be intelligent enough to understand OpenFlow protocol and should have some software entities inside them to make it work.

Software-Defined Networking

Software-Defined Networking is a network architecture approach that enables the network to be intelligently and centrally controlled, or ‘programmed,’ using software applications. This helps operators manage the entire network consistently and holistically, regardless of the underlying network technology[1].

Now we are having a clear definition of SDN. So, to form an SDN, the hardware should be intelligent enough to understand the SDN protocols.

OpenFlow

OpenFlow is a programmable network protocol for SDN environment, which is used for communication between OpenFlow ‘capable’ switches and controllers. OpenFlow separates the programming of the network device from the underlying hardware and offers a standardized way of delivering a centralized, programmable network that can quickly adapt to changing network requirements[2].

So, practically, an SDN is possible only with the hardware that can understand and act according to OpenFlow protocol.

The following diagram from[2] shows the hardware and software entities/components of a typical SDN.

OpenFlow and SDN Simulation under ns-3

Since all the hardware, as well as software entities of a typical network, are simulated only with software modules, under ns-3, all the hardware and software components of a typical SDN are just software entities in a typical simulation. So one should understand the fine difference between the simulated hardware and software components of an SDN under ns-3.

OpenFlow Simulation Support in ns-3

With the default installation, ns-3 has support to simulate OpenFlow switches – but it provides support only for an old, outdated OpenFlow protocol. For using new features of the protocol, we have to install the latest version of OpenFlow ns-3 module.

The OpenFlow 1.3 module for ns-3, also known as the OFSwitch13 module, was designed to enhance the ns-3 Network Simulator with Software-Defined Networking (SDN) technology support[3].

The following diagram from[3] shows the overview of this ns-3 module

Procedure for installing a suitable ns-3.

Before installing OpenFlow, first, we should install a suitable version of ns-3. One may follow the installation procedure presented in the following link, or follow any other installation procedure for installing the preferred version of ns-3.

Installing ns3.35 in Debian 11 (Bullseye)

For a chroot-jail based installation procedure, one may follow this link[4].

Generally, the procedures that you find on the internet for installing OpenFlow 1.3 support module (OFSwitch13) may fail on latest Linux Operating systems because of the new conventions and standards that are found in the default versions of compilers found in them. This article provides a way to successfully compile ns-3 with OFSwitch13 module.

The following step-by-step procedure explains the way of installing OpenFlow 1.3.

Installing OFSwitch13 and doing SDN Simulation under ns-3

But, keep in mind that, even though, step 5 of the above procedure get compiled correctly and end up with the final binary libns3ofswitch13.a , while compiling ns-3 with this libns3ofswitch13.a, you may face waf compilation failure while using the latest version of GCC compiler that was commonly found on the latest Linux distributions. That above article also explains an important technique to compile libns3ofswitch13.a in such a way to make it get working along with ns-3 while using the latest gcc compilers.

The following screenshot shows the successful compile operation. In the final screen output of the compile process, we can see the newly added module OFSwitch13 in the list of modules as shown below:

Finally, we have compiled ns-3 with OFSwitch13 support. Now, the newly compiled ns-3 contains the new OpenFlow 1.3 capabilities.

Testing the installation of OFSwitch13 ns-3 module

Now we can run an example simulation to test the good working of our installation.

Run an example simulation as follows:

$ ./waf –run ofswitch13-first

If you did the OFSwitch13 installation correctly and your ns-3 is really having installed with that extension, then the example simulation will run successfully and will produce the following output.