Software

Networking simulators and emulators are particularly useful because they allows testing new networking protocols and algorithms or changes to existing ones in a controlled and reproducible environment. Moreover, compared to the cost and time involved in setting up an entire test bed containing multiple networked computers, routers and data links, network simulators are relatively fast and inexpensive.

Hybrid Simulator-Emulator Platform (HySEP)

Hybrid Simulated-Emulated Platform (HySEP) is a tool which integrates simulated and emulated networks, enabling simultaneously tests of wireless access technologies through simulations, and transmission of real traffic flows from/to real hosts. HySEP is composed of three main elements as shown in Figure 1:

  • Simulated Access Networks (SANs), implemented in PC1, is composed of mobile terminals and base stations, simulated using Network Simulator 3 (ns-3);
  • Emulated Core Network (ECN), implemented in PC2, is composed of a network of virtual machines (VMs). Each core network node implements the Differentiated Service (DiffServ) as a Quality of Service (QoS) solution;
  • Real Remote Host, implemented in PC2, communicates with the simulated nodes inside the ns-3 simulation. It is an end point for the up-link traffic flows generated by the simulated nodes, and collects and displays different statistics about these flows.


Figure 1: HySEP structure.

The interconnection between simulated and emulated networks is based on the use of virtual bridges and virtual interfaces (tun/tap) which can be configured to connect the ns-3 simulation in the user space of PC1 and the kernel space of PC1 where is located the Ethernet interface used to connect PC1 with PC2. Moreover a particular ns-3 simulated node, called Ghost Node, is necessary: it acts as an alias of a tap inside the simulated network. Its task is to forward real packets from the emulated network to the simulation and simulated packets from the simulation to the emulated network. To connect simulated and real nodes it is necessary to use ns-3 in real time mode to schedule the events in real time and to keep the synchronization with the real network.


Figure 2: Reference scenario for HySEP.

The reference scenario is represented in Figure 2: it is composed of two heterogeneous wireless access networks: LTE (green) and Wi-Fi (red). These two networks are connected to a Core Network. Two Edge Routers (ERs) are located at the frontiers of this domain: one communicates with LTE and Wi-Fi networks and the other is connected to a remote host. Three different terminals are included in this scenario: i) Wi-Fi terminals, called Station (STA) nodes; ii) LTE terminals, called User Equipments (UEs); iii) multimodal terminals, each of them equipped with both network interfaces. Each multimodal terminal is able to execute vertical handover while is transmitting a file of arbitrary type and dimension, using TCP or UDP.

 

Network Simulator 3 - Full DTN Protocol Stack

 

Network Simulator 3 (NS3) is an open source discrete-event network simulator. This software implements protocols, algorithms, traffic flow applications and all other functionalities necessary to fully simulate the behaviour of a network. Unfortunately, NS3 does not officially implement the Delay Tolerant Networking (DTN) paradigm (at least up to version 3.27), which can be useful to simulate all types of networks whose links suffer from high delays or disruptions (expected or not), such as Wireless Sensor Networks and Satellite Networks.
Our need was to have a tool which allows us to simulate a Nanosatellite-DTN network.
We have developed a module which includes:

  • a Scenario module: it allows setting different network parameters in order to simulate different scenarios;
  • a DTN module: it implements the characteristics of the DTN paradigm needed to perform a communication in this DTN-Nanosatellite network. It includes store and forward mechanism, a personalized and light version of the Bundle Protocol, and the developed routing algorithms;
  • a LEO nanosatellite constellation module: it computes and updates the position of each nanosatellite during the simulation time.

Figure 1: DTN stack implemented in our module.

 

Beacon-Mininet - ReRouting Module


Mininet is a free and open-source software for network emulation which allows to create a network composed by virtual hosts, switches, controllers and links running on a single Linux machine. Mininet uses lightweight virtualization in order to make a single system act like a complete network. Mininet is the most used emulator for SDN testing as it can provide a fully compliant SDN topology consisting of multiple instances of Open vSwitches, which support OpenFlow protocol and can therefore interact with a dedicated SDN controller.

A powerful software controller is Beacon, which is a Java-based SDN controller fully supporting OpenFlow protocol. Beacon architecture is based on OSGi Framework, consisting of several bundles with specific functionalities interacting together by means of the Spring Framework.

Figure 1: Mininet

We are developing custom bundles dedicated to collect flow, queue, and port statistics from network switches, compute performance parameters and decide queueing strategy upon specific metrics. The chosen strategy is then implemented by installing ad hoc rules inside the switches by means of Flow Modification commands.

Figure 2: Beacon

The aim of these modules is to support Quality of Service using basic tools offered by OpenFlow protocol. When the offered load to a switch grows too much, our modules are able to detect the critical condition and take decisions accordingly in order to avoid packet loss. The queueing strategy allows therefore to avoid upcoming congestion based on the computed metrics.

 

Ryu-Mininet - IDS Module

  

Mininet is a free and open-source software for network emulation which allows to create a network composed by virtual hosts, switches, controllers and links running on a single Linux machine. Mininet uses lightweight virtualization in order to make a single system act like a complete network. Mininet is the most used emulator for SDN testing as it can provide a fully compliant SDN topology consisting of multiple instances of Open vSwitches, which support OpenFlow protocol and can therefore interact with a dedicated SDN controller.

Ryu is a component-based software defined networking framework. Ryu provides software components with well defined API that make it easy for developers to create new network management and control applications. Ryu supports various protocols for managing network devices, such as OpenFlow, Netconf, OF-config, etc. About OpenFlow, Ryu supports fully 1.0, 1.2, 1.3, 1.4, 1.5 and Nicira Extensions. All of the code is freely available under the Apache 2.0 license.

Figure 1: Mininet

We are developing custom application dedicated to collect flow statistics from network switches, compute some features and decide if the considered flow is affected by malware or not.

Figure 2: SF-IDS

The aim of these modules is to support malware detection using basic tools offered by OpenFlow protocol.

Satellite-Radio Network Emulator (ACE)

 

The aim of the ACE system is to emulate a network environment composed by a set of earth stations that communicate through a satellite platform. Every station may act as router and consequently may interconnect different networks.
Furthermore, in order to achieve the data communication through the satellite network, a satellite modem is included within each station. In more the modem may be an independent hardware entity connected to other units by means of a cable or also a network adapter card plugged into a unit (e.g. the router itself or a PC). In practice, it can be though as a data link layer of an overall protocol stack.

It is possible to identify, in a real satellite system, the following main parts:

      • a modem with an interface towards the upper layers (namely the network layer);
      • a channel characterized by its own peculiarities;
      • a data link protocol over the satellite channel and a satellite with its on-board switching capabilities.


Fig. 1 Overall Emulator Architecture and Real System.

The reference architecture of the emulator is shown in Fig. 1, along with one possible system to be emulated enclosed in the cloud (a GEO satellite system has been depicted in this case). Different units called Gateways (GTW) operate as interface among the emulator and the external PCs.
Each GTW is composed of a PC with two network interfaces: one towards the external world (a 10/100 Mbit/s Ethernet card), the other towards the emulator. An Elaboration Unit (EU), which has a powerful elaboration capacity, carries out most of the emulation, as the decision about the "destiny" of each PDU.
The interface towards the external world concerns the GTWs; the loss, delay and any statistics of each PDU regards the EU; the real transport of the information PDU through the network concerns the input GTW and the output GTW.

The various components are connected via a 100 Mbits/s network, completely isolated, by a full-duplex switch. In such way, the emulator has an available bandwidth much wider than the real system to be emulated, which should not overcome a maximum overall bandwidth of 10/20 Mbits/s.


Fig. 2 Emulator vs. Real System

In more detail, Fig. 2 shows how the different parts of the real system (modem, data link protocol, channel and switching system, as mentioned in the previous sub-section) are mapped onto the different components of the emulator.
It is clear in Fig. 2 that, the architecture of the emulator is not exactly correspondent to the real system. The earth station, identified by the grey rectangle, is divided, in the emulator, into two parts (GTW and EU). The network layer, the network interface towards the external world and the interface between the network layer and the satellite modem are contained in the Gateway (GTW).
The other parts of the modem (i.e. the data link layer, protocol and encapsulation), the overall transmission characteristics (e.g. bit error ratio, channel fading, lost and delayed packets), the on-board switching architecture as well as the queuing strategies are contained in the Elaboration Unit (EU).