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

[Gustavo Carneiro]

2008/7/5 Tom Henderson <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).

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.

Regards.

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