[Olsr-dev] broadcast packet filtering

[Hannes Gredler]

erik,

isn't it fair to say that the encaspulation of the data-plane
traffic is done within the same process that runs the
control-plane ?

/hannes

On Tue, May 06, 2008 at 02:09:51PM +0200, Erik Tromp wrote:
| 
| 
| > its not bashing. - i was just expressing common insights in 
| > router design that any scheme that mixes up forwarding-plane 
| > with control-plane have an inherent risk of destabilizing the 
| > control-plane of the system.
| 
| Your assumption is wrong, and thus all that follows - "Ex falsus
| quod libet" :-) . Bmf does not mix up the forwarding plane
| with the control plane. Bmf uses encapsulation, which is a modern-day
| technology. Bmf does this in order to: 
| 1. prevent multiple copies of the same IP packet from being received
|    by the application software
| 2. prevent the need for putting network interfaces into promiscuous
|    mode, as is done in other MPR-based flooding/forwarding mechanisms.
| 
| For more information, read the README_BMF.txt file, especially
| paragraph 5.
| 
| Bmf *does* perform the forwarding in user-space. In Linux-based
| systems, it would be nicer (i.e. more elegant and maybe better
| performing) to have the forwarding done in kernel-space. However,
| current linux-kernels do not offer an implementation that filters
| out the forwarding of recently seen packets. Maybe a kernel
| module can be written for iptables to implement this, but that would
| introduce the dependency on an external software component, which is
| not my preference.
| 
| Another option is to guarantee that each packet gets forwarded to
| a downstream node by at most one upstream node. This is the assumed
| way of working in current Linux-kernel multicast forwarding
| implemenations. This requires building of a forwarding tree, which
| reduces redundancy to zero (each branch in the tree is a single point
| of failure), and is not consistent with the MPR-based redundant
| mechanism used in OLSR.
| 
| > not vague opinions, more experience of building and 
| > supporting routers for 10+ years :-).
| 
| Same for me ;)
| 
| Thanks for the URLs!
| 
| Erik
| 
|