13. Emulation Overview

ns-3 has been designed for integration into testbed and virtual machine environments. We have addressed this need by providing two kinds of net devices. The first kind of device is a file descriptor net device (FdNetDevice), which is a generic device type that can read and write from a file descriptor. By associating this file descriptor with different things on the host system, different capabilities can be provided. For instance, the FdNetDevice can be associated with an underlying packet socket to provide emulation capabilities. This allows ns-3 simulations to send data on a “real” network. The second kind, called a TapBridge NetDevice allows a “real” host to participate in an ns-3 simulation as if it were one of the simulated nodes. An ns-3 simulation may be constructed with any combination of simulated or emulated devices.

Note: Prior to ns-3.17, the emulation capability was provided by a special device called an Emu NetDevice; the Emu NetDevice has been replaced by the FdNetDevice.

One of the use-cases we want to support is that of a testbed. A concrete example of an environment of this kind is the ORBIT testbed. ORBIT is a laboratory emulator/field trial network arranged as a two dimensional grid of 400 802.11 radio nodes. We integrate with ORBIT by using their “imaging” process to load and run ns-3 simulations on the ORBIT array. We can use our EmuFdNetDevice to drive the hardware in the testbed and we can accumulate results either using the ns-3 tracing and logging functions, or the native ORBIT data gathering techniques. See http://www.orbit-lab.org/ for details on the ORBIT testbed.

A simulation of this kind is shown in the following figure:

Example Implementation of Testbed Emulation.

You can see that there are separate hosts, each running a subset of a “global” simulation. Instead of an ns-3 channel connecting the hosts, we use real hardware provided by the testbed. This allows ns-3 applications and protocol stacks attached to a simulation node to communicate over real hardware.

We expect the primary use for this configuration will be to generate repeatable experimental results in a real-world network environment that includes all of the ns-3 tracing, logging, visualization and statistics gathering tools.

In what can be viewed as essentially an inverse configuration, we allow “real” machines running native applications and protocol stacks to integrate with an ns-3 simulation. This allows for the simulation of large networks connected to a real machine, and also enables virtualization. A simulation of this kind is shown in the following figure:

Implementation overview of emulated channel.

Here, you will see that there is a single host with a number of virtual machines running on it. An ns-3 simulation is shown running in the virtual machine shown in the center of the figure. This simulation has a number of nodes with associated ns-3 applications and protocol stacks that are talking to an ns-3 channel through native simulated ns-3 net devices.

There are also two virtual machines shown at the far left and far right of the figure. These VMs are running native (Linux) applications and protocol stacks. The VM is connected into the simulation by a Linux Tap net device. The user-mode handler for the Tap device is instantiated in the simulation and attached to a proxy node that represents the native VM in the simulation. These handlers allow the Tap devices on the native VMs to behave as if they were ns-3 net devices in the simulation VM. This, in turn, allows the native software and protocol suites in the native VMs to believe that they are connected to the simulated ns-3 channel.

We expect the typical use case for this environment will be to analyze the behavior of native applications and protocol suites in the presence of large simulated ns-3 networks.

The basic testbed mode of emulation uses raw sockets. Two other variants (netmap-based and DPDK-based emulation) have been recently added; these make use of more recent network interface cards that make use of directly-mapped memory capabilities to improve packet processing efficiency.

For more details:

• 13.1. File Descriptor NetDevice
  • 13.1.1. Model Description
    • 13.1.1.1. Design
    • 13.1.1.2. Scope and Limitations
  • 13.1.2. Usage
    • 13.1.2.1. Helpers
      • 13.1.2.1.1. EmuFdNetDeviceHelper
      • 13.1.2.1.2. TapFdNetDeviceHelper
    • 13.1.2.2. Attributes
    • 13.1.2.3. Output
    • 13.1.2.4. Examples
• 13.2. Netmap NetDevice
  • 13.2.1. Model Description
    • 13.2.1.1. Design
    • 13.2.1.2. Scope and Limitations
  • 13.2.2. Usage
    • 13.2.2.1. Helpers
    • 13.2.2.2. Attributes
    • 13.2.2.3. Output
    • 13.2.2.4. Examples
• 13.3. DPDK NetDevice
  • 13.3.1. Model Description
    • 13.3.1.1. Design
      • 13.3.1.1.1. Initialization
      • 13.3.1.1.2. Packet Transfer
      • 13.3.1.1.3. Termination
    • 13.3.1.2. Scope and Limitations
  • 13.3.2. DPDK Installation
    • 13.3.2.1. Is my NIC supported by DPDK?
    • 13.3.2.2. Not supported? Use Virtual Machine instead
    • 13.3.2.3. Install DPDK on Ubuntu
    • 13.3.2.4. Compile from Source
      • 13.3.2.4.1. 1. Download the source
      • 13.3.2.4.2. 2. Configure DPDK as a shared library
      • 13.3.2.4.3. 3. Install the source
      • 13.3.2.4.4. 4. Export DPDK Environment variables
    • 13.3.2.5. Load DPDK Drivers to kernel
    • 13.3.2.6. Configure hugepages
  • 13.3.3. Usage
    • 13.3.3.1. Attributes
    • 13.3.3.2. Output
    • 13.3.3.3. Examples
• 13.4. Tap NetDevice
  • 13.4.1. TapBridge Model Overview
    • 13.4.1.1. TapBridge ConfigureLocal Mode
    • 13.4.1.2. TapBridge UseLocal Mode
    • 13.4.1.3. TapBridge UseBridge Mode
    • 13.4.1.4. TapBridge ConfigureLocal Operation
    • 13.4.1.5. TapBridge UseLocal Mode Operation
    • 13.4.1.6. TapBridge UseBridge Operation
  • 13.4.2. Tap Bridge Channel Model
  • 13.4.3. Tap Bridge Tracing Model
  • 13.4.4. Using the TapBridge