[Ns-developers] emulation use cases

[Tom Henderson]

Gustavo Carneiro wrote:
> 
> 
> 2009/1/15 Tom Henderson <tomh at tomh.org <mailto:tomh at tomh.org>>
> 
>     Craig is working on Tap device support for emulation, and some
>     questions have arisen about use cases and requirements to support,
>     so I thought I'd raise the issue on the list for any input people
>     might have.
> 
>     Presently, we have an emulation mode documented here:
>     http://www.nsnam.org/docs/manual.html#SEC59
>     it runs the simulator in real-time and allows nodes in a simulation
>     to emit packets that are bridged onto a physical device on the host
>     machine.  ns-3 packets are therefore emitted onto real links.  The
>     ns-3 device must be hand-configured with mac address and does not
>     presently support DHCP configuration of the address.
> 
>     I've suggested that the next priority would be to invert the
>     picture, to allow real hosts to emit packets onto ns-3 links.  The
>     main use case I have in mind is to allow users to interconnect
>     virtual machines such as OpenVZ containers over ns-3 links (mainly,
>     WiFi is of immediate interest).  It would also be possible to use
>     the simulator as a "black box" such as a "simulator in the loop"
>     testbed between real nodes or test equipment.
> 
>     To accomplish this, what is needed is to create tap devices on the
>     ns-3 host machine, and bridge these tap devices to some new kind of
>     ns-3 NetDevice that reads and writes from the tap device.
>      Essentially, this new ns-3 NetDevice would be receiving fully
>     formed layer-2 frames and bridging them onto our existing ns-3
>     NetDevice types.
> 
>     In this model, the ns-3 node that does this bridging would be kind
>     of like a ghost node, possibly with an Internet stack (maybe not).
>      It may be the case that a simulation/emulation would involve a mix
>     of ns-3 nodes and these special ghost nodes that exist for the
>     purpose only of hosting the virtual machine; in such a case, I would
>     envision that IP-level and above configuration of the mixed
>     environment would have to be done separately.
> 
>     I think that a framework to try to configure all of this from a
>     bird's eye view of both simulation and emulation portions is
>     possible, but would be a later phase of the effort (possibly a GSOC
>     project).
> 
>     Are there other suggestions for the above type of use case, or other
>     use cases for emulation that people would like to see prioritized?
> 
> 
> I was looking at this again (the manual), and I realize that I am 
> confused about something.
> 
> As far as I can tell, "tap" devices can be used to allow a userspace 
> simulation interact with applications running on the same kernel that 
> runs the simulator.  In this scenario no virtualization needs to be 
> employed at all.
> 
> On the other hand, in a virtualized environment I would expect the 
> virtualization environment to already provide the tools to create and 
> interconnect virtual devices to allow communication between guests or 
> between host and guests.  In this case I think NS-3 should not need to 
> create any tap device, and instead should just send/receive packets to 
> an existing device.  Therefore, what we need to use is just EmuNetDevice 
> again, not Tap.
> 
> However, the manual explicitly mentions a virtualization scenario as 
> motivation for Tap devices, which I think may work but EmuNetDevice may 
> also work and simpler, more efficient.
>  
> Am I missing something?

The scenario I'm interested in supporting is virtual machines such as 
OpenVz containers being interconnected by ns-3 networks, such that the 
packet coming to/from the container is sent/received from the ns-3 
NetDevice.  The container sends a packet out of its virtual device, 
which can be bound to a host's tap device, and ns-3 can be on the other 
end of the tap device, and the ns-3 NetDevice treats the packets as if 
they came from an ns-3 internet stack.

I can add some description in the manual to this to avoid future confusion.

- Tom