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

[Tom Henderson]

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

Tom