(OK) NS-3 - Emulation Overview - FdNetDevice - TapBridge

https://www.nsnam.org/docs/models/html/emulation-overview.html

ns-3 has been designed for integration into testbed and virtual machineenvironments. 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 hostsystem, different capabilities can be provided. For instance, theFdNetDevice can be associated with an underlying packet socket to provideemulation capabilities. This allows ns-3 simulationsto send data on a “real” network. The second kind, called a TapBridgeNetDevice allows a “real” host to participate in an ns-3 simulation as ifit were one of the simulated nodes. An ns-3 simulation may be constructed withany combination of simulated or emulated devices.

Note: Prior to ns-3.17, the emulation capability was provided by aspecial device called an Emu NetDevice; the Emu NetDevice hasbeen replaced by the FdNetDevice.

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

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 realhardware provided by the testbed. This allows ns-3 applications and protocolstacks attached to a simulation node to communicate over real hardware.

We expect the primary use for this configuration will be to generate repeatableexperimental results in a real-world network environment that includes all ofthe 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 anns-3 simulation. This allows for the simulation of large networks connected toa real machine, and also enables virtualization. A simulation of this kind isshown in the following figure:

Implementation overview of emulated channel.

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

There are also two virtual machines shown at the far left and far right of thefigure. 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-modehandler for the Tap device is instantiated in the simulation and attached to aproxy node that represents the native VM in the simulation. These handlers allowthe Tap devices on the native VMs to behave as if they were ns-3 net devices inthe simulation VM. This, in turn, allows the native software and protocol suitesin the native VMs to believe that they are connected to the simulated ns-3channel.

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

For more details:

• FdNetDevice chapter.
• TapBridge chapter.