[WLANware] GSoC 2010: Project IP/UDP encapsulation Kernel module

[marco bonola]

Hi Mitar,

>Our proposal is to make on a node one virtual network device you
>configure (with ioctl for example) with unlimited number of other
>nodes (ip:port pairs) and kernel module makes a switch to all those
>nodes. So it still does IPinUDP but we generalize the idea to multiple
>nodes on other side. And we need bridge logic to not duplicate traffic
>too much (only for broadcast data this would be the case then, like
>OLSR traffic).

this is what I was thinking of. From my GSoC proposal:

"One or more virtual interfaces can be export to user-space so that packets
routed through them will be intercepted by IP/UDP_send() function (as for
other
encapsulation modules, e.g.: IP/IP, IP/GRE) and encapsulated. Encapsulation
 header fields are retrieved in 2 ways: (A) Fixed: each virtual iface has a
fixed
IP/UDP encapsulation header; (B) Dynamic: the encapsulation header is
retrieved
 from a forwarding table implemented as a hash table..."

What I mean with "Dynamic virtual interface" is a iface for which I can
dinamically
configure a set of different encapsulating/forwarding rules in a table.
In this way if we have 50 peers we are communicating with (and thus 50
different
IP/UDP tunnels), we don't need 50 virtual ifaces.

The configuration will be performed by NETLINK socket. From my GSoC:
"Advanced ad-hoc configuration (tunnel registration and parameters
configuration,
forwarding table management, etc...) will be provided by a generic NETLINK
socket.
Moreover, integration with standard configuration tools (e.g: ip, ifconfig)
is possible."

Does this support your idea?

Marco

On Thu, Apr 15, 2010 at 2:14 AM, Mitar <mmitar at gmail.com> wrote:

> Hi!
>
> On Tue, Apr 6, 2010 at 11:28 PM, ZioPRoTo (Saverio Proto)
> <zioproto at gmail.com> wrote:
> > So instead of sticking people to a gateway inside the mesh, just make
> > all the traffic to Internet be tunneled to a fast server and then from
> > there all the traffic exits with the same IP address.
> > Users see more bandwidth (especially in upload) and they exploit for
> > the better an eventual route flap :)
>
> This is exactly what we are doing in wlan ljubljana. We have a lot of
> fiber connections and we make use of them a lot. Currently we are
> using OpenVPN to connect to central server but this have big
> drawbacks: our connections are mostly CPU limited and central server
> is what is then single point of failure.
>
> We were discussing this idea and we really started to like it. I think
> this is something wonderful. But as we have quite a lot of experience
> with practical deployment of such network combined with WiFi and OLSR
> I would like to propose an enhancement to original idea. It makes it a
> little bit more complicated but what you get is something great.
>
> Our proposal is to make on a node one virtual network device you
> configure (with ioctl for example) with unlimited number of other
> nodes (ip:port pairs) and kernel module makes a switch to all those
> nodes. So it still does IPinUDP but we generalize the idea to multiple
> nodes on other side. And we need bridge logic to not duplicate traffic
> too much (only for broadcast data this would be the case then, like
> OLSR traffic).
>
> So on one extreme you could add all known other nodes to the list of
> other sides to virtual network device on every node. Some of those
> connections would work, some of them would not, but this would then
> OLSR on top of all this recognize and set routes properly.
>
> Of course this extreme would not be useful for big meshes but having
> this possibility some higher logic (from userspace) could take a
> subset of all nodes and just those configure on network device. But
> having this generalization would be really useful.
>
> So this would make topology completely decentralized and also traffic
> which would go between nodes could go directly and not over the
> central server.
>
> In this way our networks would really become link-level independent.
> Whatever we use, all would work.
>
>
> Mitar
> _______________________________________________
> WLANware mailing list
> WLANware at freifunk.net
> Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlanware
>
> Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung
> unter http://freifunk.net/mailinglisten
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.freifunk.net/pipermail/wlanware-freifunk.net/attachments/20100415/eb59d858/attachment.html>