[Ns-developers] Request for Design Review -- Emulated Net Device (ns-3.3 new feature)

[Mathieu Lacage]

hi craig,

I also wanted to record somewhere random thoughts about the matter so,
here they are.

On Thu, 2008-10-30 at 16:30 -0700, craigdo at ee.washington.edu wrote:

> Tom has two scenarios he is interested in supporting with respect to
> integration of ns-3 with real hardware.  The emulated net device is designed
> to support integration with testbeds, the first of his scenarios.  In this
> case, ns-3 simulations are used to drive real network hardware talking over
> the testbed.  Here's some ASCII "art" (set fixed font):
> 
>      +--------+     +--------+     +--------+     +--------+
>      |  Host  |     |  Host  |     |  Host  |     |  Host  |
>      | ------ |     | ------ |     | ------ |     | ------ |
>      |  ns-3  |     |  ns-3  |     |  ns-3  |     |  ns-3  |
>      |  sim   |     |  sim   |     |  sim   |     |  sim   |
>      | ------ |     | ------ |     | ------ |     | ------ |
>      |  emu   |     |  emu   |     |  emu   |     |  emu   |
>      |  net   |     |  net   |     |  net   |     |  net   |
>      | device |     | device |     | device |     | device |
>      | ------ |     | ------ |     | ------ |     | ------ |
>      |  real  |     |  real  |     |  real  |     |  real  |
>      | device |     | device |     | device |     | device |
>      +--------+     +--------+     +--------+     +--------+
>          ||             ||             ||             ||    
>      +-----------------------------------------------------+
>      |                                                     |
>      |         Testbed network (can you say ORBIT)         |
>      |                                                     |
>      +-----------------------------------------------------+
> 
> The other scenario, which Mathieu's tap device is really much closer to, is
> basically the inverse of this case.  Here's a sneak preview.  We want to
> take real nodes and connect them together through ns-3 simulated channels.
> Here's some more ASCII art:
> 
>      +--------+
> +--------+
>      |  Host  |                                                          |
> Host  |
>      |   VM   |                                                          |
> VM   |
>      | ------ |                                                          |
> ------ |
>      |  apps  |                                                          |
> apps  |
>      | ------ |                                                          |
> ------ |
>      |  stack |      +----------+     +----------+     +----------+      |
> stack | 
>      | ------ |      |   node   |     |   node   |     |   node   |      |
> ------ | 
>      |  tap   |      | -------- |     | -------- |     | -------- |      |
> tap   |
>      | device | <--> |   tap    |     |   ns-3   |     |   tap    | <--> |
> device |
>      +--------+      | handler  |     |   apps   |     | handler  |
> +--------+ 
>                      | -------- |     | -------- |     | -------- |
>                      |   ns-3   |     |   ns-3   |     |   ns-3   |
>                      |   net    |     |   net    |     |   net    |
>                      |  device  |     |  device  |     |  device  |
>                      +----------+     +----------+     +----------+
>                           ||               ||               ||
>                      +--------------------------------------------+
>                      |        ns-3 channel (can you say wifi)     |
>                      +--------------------------------------------+

The above definitely looks like a good summary of the scenarios we want
to support. I can see 2 big challenges beyond the emu/tap stuff:

1) while I can see how the current emu and tap devices handle a single
simulation running as part of a larger (small) network, the real issue,
I think, is related to how we are going to ensure full ip-level
connectivity across simulation/real-world boundaries to allow the
simulation to reach any real-world network node and to allow real-world
network nodes to reach any simulation node.

So, we need some sort of global view of the system to figure out how to
correctly configure every node, assign ip addresses and subnets, etc.

2) The second issue is how we setup such a large experiment: ideally,
from a user perspective, we would be able to describe the global
topology in a single file or a set of closely related files which all
work together (and thus allow you to have the global view needed to
solve (1) above). The challenge, though, is that the deployment process
varies a lot across testbeds both because each testbed has different
capabilities and also because each testbed tends to use a different
language to describe the experiment configuration. 

In a perfect world, we would be able to build a small
testbed-independent scenario-description system which we can use to
abstract the testbed deployment tools and which we can use to integrate
with ns-3's own scenario description. From a 10000-feet perspective, if
I were to try to make this work, I would go with python as a glue
language both because we have ns-3 bindings, but also because planetlab
and emulab have xmlrpc interfaces (and xmlrpc is trivial to use with
python). orbit and some of our own local testbeds do not support python
which would be an issue but I believe that we could wrap them in a
python API.

anyhow, these are my crazy thoughts on the topic: emulab probably has
something to teach us about (1). (2) is very important also from my
perspective and both of them have a major impact on how we are going to
build/use our low-level emu/tap facilities.

Mathieu