[Ns-developers] NS-3 promiscuous mode for NetDevice

[Gustavo Carneiro]

2008/7/5 Tom Henderson <tomh at tomh.org>:

> Gustavo Carneiro wrote:
>
>>
>>
>> 2008/7/5 Tom Henderson <tomh at tomh.org <mailto:tomh at tomh.org>>:
>>
>>
>>    Mathieu Lacage wrote:
>>
>>        hi,
>>
>>        To summarize a lengthy discussion on irc, gustavo and I agreed
>>        that we
>>        might need to add couple of features to the NetDevice base class to
>>        support that use-case:
>>         - allow the specification of a from address when sending a
>>        packet to a
>>        NetDevice
>>         - allow the listener of a NetDevice to get the source and
>>        destination
>>        address of an incoming packet
>>         - allow a NetDevice to be put into promiscuous mode
>>
>>        The details of the API needed to support that are not very
>>        complicated
>>        but they all depend on making a couple of decisions on API
>>        stability: it
>>        is possible to add the above features without breaking existing
>>        API by
>>        adding new methods but doing so would duplicate nearly-similar
>>        existing
>>        methods so, it is also possible to break the existing API and
>>        methods to
>>        make them handle this new case. Gustavo does not want to break
>>        the API
>>        because he does not want to make it harder to migrate from ns-3.1
>> to
>>        newer versions. I want to break it because I don't want to
>> introduce
>>        cruft in our APIs. Tom, craig, opinions ?
>>
>>
>>    I agree with Gustavo's point to look at the specifics, maybe
>>    side-by-side.  In general, I care about long term sanity of the APIs
>>    and I probably am less concerned at this moment about stability of
>>    an API that is public but may be practically internal from a user
>>    script level.  Also, I have less heartburn over an API change where
>>    the fix just requires user to look at the documentation and figure
>>    out why it didn't compile, rather than one that changes behavior
>> subtly.
>>
>>    In this case, I was surprised to look at Gustavo's code and see the
>>    bridge functionality implemented within a special bridge device
>>    rather than on top of our usual devices.  Could we instead implement
>>    bridging as a function on top of existing devices, and would that
>>    avoid the need to break current API?
>>
>>
>> What do you mean by bridge functionality?  If you mean the SendFrom API
>> and promiscuous mode, then I don't think it is possible to put it on top of
>> NetDevices.  If you mean the bridging logic itself (MAC frame forwarding) it
>> _is_ already on top of existing NetDevices: BridgeNetDevice is on top of
>> each NetDevice (called "bridge ports" in this context).
>>
>
> Sorry, I misread your csma-bridge.cc example as connecting to the
> terminals.  I agree with the overall approach.
>
>
>> As I explained already, I am doing a BridgeNetDevice because:
>>
>>  1- Linux bridging does it (see
>> http://www.linuxfoundation.org/en/Net:Bridge);
>>
>>  2- It is a more natural way to define how a bridge interacts with a local
>> IPv4 stack.
>>
>>    I also think that while we are on this exercise, it would be helpful
>>    to architecturally plan for how we are going to deal with adding
>>    VLANs and MPLS.
>>
>>
>> Actually my colleague Pedro Fortuna is currently looking at implementing
>> MPLS (data plane only) functionality in NS-3.  But I'm afraid he's a bit shy
>> and does not like to get involved in ns-developers discussions until things
>> are ready :)  Also it is not clear yet what portion of our MPLS code will be
>> generic enough for inclusion in NS-3, since we're integrating it with a very
>> specific research scenario.
>>
>> But it's like I mentioned when I started this thread.  We are working in a
>> research scenario that is hard to explain, involving ethernet bridging,
>> encapsulation, and MPLS.  Instead I am implementing a Learning Bridge
>> because it exercises most of the missing functionality in NS-3 and is a well
>> known problem and easy to explain.
>>
>
> It would be nice if we can morph your design at some point to also include
> a tun interface type.  (I'm not asking you to do work on it, but rather that
> it would be nice to develop rough ideas of how tunnel, VLANs, etc. are going
> to work and whether our NetDevice and Node API is complete enough, during
> this release cycle).


I already did L2 tunneling (L2-over-IP) long before ns-3.1, and submitted
the VirtualNetDevice, which is like a "tap" interface.  I don't really have
a use case for a "tun" (IP-over-IP) interface yet.  Presumably it would be
used by mobile IP, but I don't know for sure.  Personally I have no interest
in pursuing "tun" interfaces in the foreseeable future, but I agree it would
be an interesting and useful project for someone to tackle.

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