search

USNavalResearchLaboratory / mgen

Multi-Generator (MGEN) traffic generation tool
https://www.nrl.navy.mil/itd/ncs/products/mgen
Other
83 stars 25 forks source link

EMANE and MGEN Broadcast/Multicast clarification questions #46

Closed vivianchiong closed 1 year ago

vivianchiong commented 1 year ago

Hi!

I am using mgen to generate traffic within an EMANE+ETCE environment. I want all of the traffic generated to be broadcast. I'd like to clarify my understanding on how to achieve this:

Currently I am using mgen scripts for all the nodes having "JOIN INTERFACE bmf0" and then sending and receiving to/from that address. This seems to be working great.

I found that EMANE's Virtual transport has broadcast mode though, so I was wondering if setting this parameter to true would make a difference to the above setup, or if broadcast from the Virtual Transport's point of view is different.

mgen also has a broadcast option (which the documentation says is on by default). My understanding is that this definition of broadcast just means that we are in a wireless setting where packets traveling across the medium will be sent out to all nodes but whether those packets will be received and processed by nodes depends on "if 1) MGEN is LISTENing on that port, and 2) either they are destined for that node via unicast, or the node has JOINed the multicast" #19

Please let me know if some of my understanding is erroneous or if you have any suggestions or insights.

Thank you so much for your help!

weston-nrl commented 1 year ago

EMANE's virtual transport mode has more to do with the internals of EMANE. I don't believe it should have any effect here.

I am not clear on what you mean by, "I want all of the traffic generated to be broadcast." Do you mean IP broadcast, as in sending specifically to 192.168.1.255 in a 192.168.1.0/24 network? Or do you just mean "broadcast" as a general term of "I want all nodes to hear this packet?" In the latter case, multicast is probably what you want and may be what you are already using.

In all cases (IP broadcast and multicast), whether a node receives the packet in a wireless environment will (in addition to the things you listed) also depend on whether the node is in range of the sender, so for a multi-hop mesh/MANET network, you may need additional multicast forwarding/routing functionality (e.g. SMF), and additional factors can come into play including flow TTL, system sysctl settings, etc.

vivianchiong commented 1 year ago

Thank you so much for your quick response!

The latter - I want all nodes in my scenario to hear packets they are each sending.

For multicast forwarding/routing functionality, I believe I am taking that into account by using OLSRD's BMF plugin. This seems to be the same functionality as SMF. Are you familiar with OLSRD's BMF, and if so, how do they compare? I'm actually having issues with OLSRD's BMF in EMANE - would it be possible to use SMF instead in the same EMANE environment?

I'll keep those other factors in mind. Thanks again!

weston-nrl commented 1 year ago

I have not used BMF, but it looks like it provides similar functionality. SMF works in an EMANE network as well as a real network. It requires communication with another process in order to get the information needed to more efficiently flood multicast traffic (NRLOLSR can be used to calculate similar S-MPR relay sets, or other more general, non-source-specific algorithms such as ECDS), but it can operate by itself to provide "classical flooding" (all nodes forward each packet once) if you don't want/need to run a unicast routing protocol. It can also be controlled by other methods to turn flooding on/off per-node if you are able to calculate a more efficient relay set by other means.

vivianchiong commented 1 year ago

Interesting, I'll take note of that and maybe use that in the future based on my use case. Thank you so much for your insight! This issue can be closed.