[Ns-developers] emulation use cases

[Gustavo Carneiro]

2009/2/11 Tom Henderson <tomh at tomh.org>

> 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.


OK, maybe this is something OpenVz specific.  But I have worked with
vmware-server, in the past, and it creates a virtual device, with
representations in both the guest and host.  When the guest sends a packet,
it is transmitted by the virtual device / guest-side part, and is then
received by the virtual-device host-part, and vice versa.  In this case you
do not need a tap device, only a packet socket (EmuNetDevice).

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


I think the basic description should be simply that NS-3 provides a wrapper
around tap netdevices.  Then the documentation can include example use
cases.  Virtualization with OpenVz can be one.  But IMHO the use case that
will be more readily recognisable is a scenario where the simulator
interacts with local/real applications, when no virtualization is involved
at all.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert