On Wed, Sep 8, 2010 at 1:25 PM, Sven Eckelmann sven.eckelmann@gmx.de wrote:
* Does it allow to append extra header information to the packet? * Does it allow fragmentation of packets (not real fragmentation, but more single split)?
I'm assuming that both of these questions are for tunneling. Open vSwitch currently supports a few different L2 over L3 tunneling mechanisms and has a tunnel library that makes adding additional protocols easy. It probably can't do exactly what you need right now, but it should be fairly easy to extend.
Hm, low overhead tunneling is one of the main parts, but if you think that it is easy to extend then fine.
I understand that tunneling needs to go in the kernel. However, as I said, several tunneling mechanisms already exist in Open vSwitch (maybe one of them even already meets your needs) and adding another one would certainly be less code than the approximately 9000 lines that this patch entails.
* Does it allow to define outgoing patterns (on which attached interface goes the thing out again) on packet number or incoming device (the real hardware device it was coming in)?
I'm not sure what you mean by "packet number". It does allow you to specify the output interface based on a number of factors, include the input device.
It would mean that for example 5 packets goes over device 1, the next 5 packets goes over
I'm assuming that those packets are from different higher level flows, right? Otherwise you will have significant reordering issues. Assuming that is the case, then yes, this is possible and is how Open vSwitch implements bonding purely in userspace.
- directly influence the traffic flow, i.e., ARQ for broadcasts,
Could you please comment on that one (taken from Mareks mail). Think about that one: * A Broadcast packet must be send over wifi (adhoc) * This packet is probably dropped due to some interferences. So each node must transmit the broadcast more than one time to be (with a good chance successful). This is quite essential on l2 based adhoc wifi mesh networks (as tests showed - but please ask Marek for the actual test setups)
This isn't something that Open vSwitch currently has support for since it expects the properties of Ethernet, which is best effort, and assumes the upper layers will do any retransmission if desired. However, I know that for lossy wireless networks sometimes this is not sufficient. Open vSwitch has a virtual port abstraction in the kernel that works well for this type of application specific code and is where I would expect you to put your tunneling protocol. I suspect that this may fit in there as well. Again, I understand that there are some areas where the existing Open vSwitch does not exactly fit all of your needs. However, I think that you will find that the parts of the kernel that require extension are actually quite small and well abstracted.