[ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Herman Elfrink]

 
FLAME stands for "Forwarding Layer for Meshing"

FLAME provides an intermediate layer between the network layer (e.g. 
IPv4/IPv6) and the link (MAC) layer, providing L2.5 meshing. Both 
network layer and MAC layer can be used unchanged: to the network layer 
FLAME appears as a normal Ethernet-type MAC layer, and the underlying 
`real' MAC layer will see it as just another type of network layer.

URL (http://www.ti-wmc.nl/flame/)

FLAME uses an unofficial protocol number (0x4040), any tips on how to 
get an official IANA number would be highly appreciated.

Please send your feedback to the FLAME mailinglist: 
flame<at>www<dot>ti<dash>wmc<dot>nl.


README:
-----------------------------------------------------------
General:
========
FLAME implements an intermediate layer between IP an MAC, providing
MAC-level forwarding. It is used to solve mesh networking below the
networking layer (L2.5 meshing).
Using FLAME, the meshed net is represented to the network layer as a normal
ethernet-type subnet, so, unlike L3 mesh solutions like OLSR and AODV, all
standard IP mechanisms (routing, addressing, broadcast/multicast, neighbor
discovery) work as expected.
FLAME is independent of and can be used under each type of network layer
(IP, IPv6, etc).
For more information: see the documentation in the /doc directory.
FLAME is provided as a kernel module for linux 2.4 and 2.6.
MACINFO is an additional module that is used to store the cost value related
to nodes (identified by MAC addresses) in the FLAME network. These cost
values can be retrieved by user programs and could be used to make
routing decisions.

Requirements
============
In order to compile flame, the kernel source for the currently running
kernel should be available via the symbolic link: /lib/modules/`uname 
-r`/build
Use Makefile-2.4 for compiling with 2.4.x linux kernels and Makefile for
2.6.x(.x) kernels.

Installation
============
- Extract the tarball
- Compile and install the code (requires kernel source):
    make
    make install

Configuration
=============
Invent a name () for each FLAME device you want to use
(e.g. 'flm0'), and create an interface configuration entry for
each device (e.g. on Mandriva: /etc/sysconfig/network-scripts/ifcfg-flm0)
For all MAC devices to be used under a FLAME device: if IP is configured
for a MAC device, its prefix should differ from the IP prefix for the 
FLAME device.

Usage
=====
- Load module:
    modprobe flame [debuglevel=]  [flm_topo_timer=]
      : debug level, default: 1
      : topology check timer (in seconds), default: 5
- Open/close a device with:
    echo "up   []" > /proc/net/flame/cmd
    echo "down " > /proc/net/flame/cmd
      : name of FLAME device, e.g. flm0
      : comma-separated list of MAC devices (at least one) that are
      used below the FLAME device. All of these must be up.
    : comma-separated list of MAC addresses of devices
      for which traffic should be ignored; each MAC address should
      be a semicolon-separated list of 6 hex-pairs
- Get current forwarding info from FLAME:
    cat /proc/net/flame/fwd
- Get nodes/cost information from MACINFO:
    cat /proc/net/macinfo

Bugs
====
Should you find any bugs (and preferably fix them ;-) please let us know via
the mailinglist.
subject: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

FLAME stands for "Forwarding Layer for Meshing"

FLAME provides an intermediate layer between the network layer (e.g. 
IPv4/IPv6) and the link (MAC) layer, providing L2.5 meshing. Both 
network layer and MAC layer can be used unchanged: to the network layer 
FLAME appears as a normal Ethernet-type MAC layer, and the underlying 
`real' MAC layer will see it as just another type of network layer.

URL (http://www.ti-wmc.nl/flame/)

FLAME uses an unofficial protocol number (0x4040), any tips on how to 
get an official IANA number would be highly appreciated.

Please send your feedback to the FLAME mailinglist: 
flame<at>www<dot>ti<dash>wmc<dot>nl.


<include: readme>
------------------

General:
========
FLAME implements an intermediate layer between IP an MAC, providing
MAC-level forwarding. It is used to solve mesh networking below the
networking layer (L2.5 meshing).
Using FLAME, the meshed net is represented to the network layer as a normal
ethernet-type subnet, so, unlike L3 mesh solutions like OLSR and AODV, all
standard IP mechanisms (routing, addressing, broadcast/multicast, neighbor
discovery) work as expected.
FLAME is independent of and can be used under each type of network layer
(IP, IPv6, etc).
For more information: see the documentation in the /doc directory.
FLAME is provided as a kernel module for linux 2.4 and 2.6.
MACINFO is an additional module that is used to store the cost value related
to nodes (identified by MAC addresses) in the FLAME network. These cost
values can be retrieved by user programs and could be used to make
routing decisions.

Requirements
============
In order to compile flame, the kernel source for the currently running
kernel should be available via the symbolic link: /lib/modules/`uname 
-r`/build
Use Makefile-2.4 for compiling with 2.4.x linux kernels and Makefile for
2.6.x(.x) kernels.

Installation
============
- Extract the tarball
- Compile and install the code (requires kernel source):
    make
    make install

Configuration
=============
Invent a name () for each FLAME device you want to use
(e.g. 'flm0'), and create an interface configuration entry for
each device (e.g. on Mandriva: /etc/sysconfig/network-scripts/ifcfg-flm0)
For all MAC devices to be used under a FLAME device: if IP is configured
for a MAC device, its prefix should differ from the IP prefix for the 
FLAME device.

Usage
=====
- Load module:
    modprobe flame [debuglevel=]  [flm_topo_timer=]
      : debug level, default: 1
      : topology check timer (in seconds), default: 5
- Open/close a device with:
    echo "up   []" > /proc/net/flame/cmd
    echo "down " > /proc/net/flame/cmd
      : name of FLAME device, e.g. flm0
      : comma-separated list of MAC devices (at least one) that are
      used below the FLAME device. All of these must be up.
    : comma-separated list of MAC addresses of devices
      for which traffic should be ignored; each MAC address should
      be a semicolon-separated list of 6 hex-pairs
- Get current forwarding info from FLAME:
    cat /proc/net/flame/fwd
- Get nodes/cost information from MACINFO:
    cat /proc/net/macinfo

Bugs
====
Should you find any bugs (and preferably fix them ;-) please let us know via
the mailinglist.

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Stephen Hemminger]

O
> Usage
> =====
> - Load module:
>     modprobe flame [debuglevel=]  [flm_topo_timer=]
>       : debug level, default: 1
>       : topology check timer (in seconds), default: 5
> - Open/close a device with:
>     echo "up   []" > /proc/net/flame/cmd
>     echo "down " > /proc/net/flame/cmd
>       : name of FLAME device, e.g. flm0
>       : comma-separated list of MAC devices (at least one) that are
>       used below the FLAME device. All of these must be up.
>     : comma-separated list of MAC addresses of devices
>       for which traffic should be ignored; each MAC address should
>       be a semicolon-separated list of 6 hex-pairs
> - Get current forwarding info from FLAME:
>     cat /proc/net/flame/fwd
> - Get nodes/cost information from MACINFO:
>     cat /proc/net/macinfo


Use of /proc for an API is no longer desirable. Please rewrite.

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Simon Oosthoek]

Stephen Hemminger wrote:
> O
>> Usage
>> =====
>> - Load module:
>>     modprobe flame [debuglevel=]  [flm_topo_timer=]
>>       : debug level, default: 1
>>       : topology check timer (in seconds), default: 5
>> - Open/close a device with:
>>     echo "up   []" > /proc/net/flame/cmd
>>     echo "down " > /proc/net/flame/cmd
>>       : name of FLAME device, e.g. flm0
>>       : comma-separated list of MAC devices (at least one) that are
>>       used below the FLAME device. All of these must be up.
>>     : comma-separated list of MAC addresses of devices
>>       for which traffic should be ignored; each MAC address should
>>       be a semicolon-separated list of 6 hex-pairs
>> - Get current forwarding info from FLAME:
>>     cat /proc/net/flame/fwd
>> - Get nodes/cost information from MACINFO:
>>     cat /proc/net/macinfo
> 
> 
> Use of /proc for an API is no longer desirable. Please rewrite.
> -

hmm, ok, I'm not sure this will happen anytime soon (being a rather low 
priority thing, which is also the reason it's not submitted as patch to 
the kernel and not signed off), but what is currently the desirable method?

Cheers

Simon

PS, I'm replying for my colleague, who will see this Monday at the 
earliest ;-)

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Steven Rostedt]

On Tue, 2006-05-23 at 16:51 +0200, Simon Oosthoek wrote:

> > Use of /proc for an API is no longer desirable. Please rewrite.
> > -
> 
> hmm, ok, I'm not sure this will happen anytime soon (being a rather low 
> priority thing, which is also the reason it's not submitted as patch to 
> the kernel and not signed off), but what is currently the desirable method?
> 

 sysfs is the new interface into the kernel.  /proc is for processes
only (besides the old stuff).

Read up on:
 Documentation/filesystems/sysfs.txt and Documentation/kobject.txt

-- Steve

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Alan Cox]

On Maw, 2006-05-23 at 16:51 +0200, Simon Oosthoek wrote:
> > Use of /proc for an API is no longer desirable. Please rewrite.
> > -
> 
> hmm, ok, I'm not sure this will happen anytime soon (being a rather low 
> priority thing, which is also the reason it's not submitted as patch to 
> the kernel and not signed off), but what is currently the desirable method?

sysfs will let you provide the same information in a much more
structured manner, and it will do most of the hard work for you as well.

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Alan Cox]

On Maw, 2006-05-23 at 16:07 +0200, Herman Elfrink wrote:
> FLAME uses an unofficial protocol number (0x4040), any tips on how to 
> get an official IANA number would be highly appreciated.
> 

Ethernet protocol number I assume you mean. If so this at least used to
be handled by the IEEE, along with ethernet mac address ranges.

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Simon Oosthoek]

Alan Cox wrote:
> On Maw, 2006-05-23 at 16:07 +0200, Herman Elfrink wrote:
>> FLAME uses an unofficial protocol number (0x4040), any tips on how to 
>> get an official IANA number would be highly appreciated.
>>
> 
> Ethernet protocol number I assume you mean. If so this at least used to
> be handled by the IEEE, along with ethernet mac address ranges.
> 

Yes ethernet protocol (it's below IP level), I didn't realise that IEEE 
also handled the portnumbers. I'll check the ieee website to see how it 
works, tnx!

/Simon

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Erik Mouw]

On Tue, May 23, 2006 at 04:41:48PM +0200, Simon Oosthoek wrote:
> Alan Cox wrote:
> >On Maw, 2006-05-23 at 16:07 +0200, Herman Elfrink wrote:
> >>FLAME uses an unofficial protocol number (0x4040), any tips on how to 
> >>get an official IANA number would be highly appreciated.
> >>
> >
> >Ethernet protocol number I assume you mean. If so this at least used to
> >be handled by the IEEE, along with ethernet mac address ranges.
> >
> 
> Yes ethernet protocol (it's below IP level), I didn't realise that IEEE 
> also handled the portnumbers. I'll check the ieee website to see how it 
> works, tnx!

IEEE doesn't handle port numbers. Port numbers are for whatever is
layered on top of ethernet, so you need to register those with the
appropriate authorities (IANA for IP).


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Simon Oosthoek]

Erik Mouw wrote:
> On Tue, May 23, 2006 at 04:41:48PM +0200, Simon Oosthoek wrote:
>> Alan Cox wrote:
>>> On Maw, 2006-05-23 at 16:07 +0200, Herman Elfrink wrote:
>>>> FLAME uses an unofficial protocol number (0x4040), any tips on how to 
>>>> get an official IANA number would be highly appreciated.
>>>>
>>> Ethernet protocol number I assume you mean. If so this at least used to
>>> be handled by the IEEE, along with ethernet mac address ranges.
>>>
>> Yes ethernet protocol (it's below IP level), I didn't realise that IEEE 
>> also handled the portnumbers. I'll check the ieee website to see how it 
>> works, tnx!
> 
> IEEE doesn't handle port numbers. Port numbers are for whatever is
> layered on top of ethernet, so you need to register those with the
> appropriate authorities (IANA for IP).
> 

Sorry, that was a typo and a thinko, I usually think above IP, my 
colleague is more used to under IP ;-)

/Simon

-- 
phone:(+31|0)53 4810319
fax:  (+31|0)53 4810333
simon.oosthoek@ti-wmc.nl
http://www.ti-wmc.nl/

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Alan Cox]

On Maw, 2006-05-23 at 16:55 +0200, Erik Mouw wrote:
> > >Ethernet protocol number I assume you mean. If so this at least used to
> > >be handled by the IEEE, along with ethernet mac address ranges.
> > >
> > 
> > Yes ethernet protocol (it's below IP level), I didn't realise that IEEE 
> > also handled the portnumbers. I'll check the ieee website to see how it 
> > works, tnx!
> 
> IEEE doesn't handle port numbers. Port numbers are for whatever is
> layered on top of ethernet, so you need to register those with the
> appropriate authorities (IANA for IP).

No no no

There are several sets of numbers here

Each ethernet DIX frame has a "protocol" (its the bits used for length
in 802.*). IEEE at least used to handle the assignment of those. On top
of that you have IP, IPX, etc with their own numbering agency.

As he said "ethernet protocol (it's below IP level)", those are the
protocol numbering bodies he wants, or to whomever it was delegated.

Alan

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Herman Elfrink]

An attempt to clear up the confusion that seems to have occurred:
FLAME is an intermediate layer between existing MAC and network (IP) layers.
 From MAC layer point of view FLAME is another network layer protocol 
(besides IP, IPX etc.), so the FLAME protocol ID we are taking about is 
a network layer (IANA) protocol number.
 From IP point of view FLAME behaves like a 'normal' ethernet-type MAC 
layer; no need for new IEEE protocol number.

Regards,

Herman Elfrink.

Alan Cox wrote:

>On Maw, 2006-05-23 at 16:55 +0200, Erik Mouw wrote:
>  
>
>>>>Ethernet protocol number I assume you mean. If so this at least used to
>>>>be handled by the IEEE, along with ethernet mac address ranges.
>>>>
>>>>        
>>>>
>>>Yes ethernet protocol (it's below IP level), I didn't realise that IEEE 
>>>also handled the portnumbers. I'll check the ieee website to see how it 
>>>works, tnx!
>>>      
>>>
>>IEEE doesn't handle port numbers. Port numbers are for whatever is
>>layered on top of ethernet, so you need to register those with the
>>appropriate authorities (IANA for IP).
>>    
>>
>
>No no no
>
>There are several sets of numbers here
>
>Each ethernet DIX frame has a "protocol" (its the bits used for length
>in 802.*). IEEE at least used to handle the assignment of those. On top
>of that you have IP, IPX, etc with their own numbering agency.
>
>As he said "ethernet protocol (it's below IP level)", those are the
>protocol numbering bodies he wants, or to whomever it was delegated.
>
>Alan
>
>
>  
>

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Herman Elfrink]

Hi,

Seems that instead of clearing the confusion I was confused myself.
What we are talking about here is the protocol ID carried in the 
ethernet header, which ethernet uses to identify the network layer (as 
defined in the file <linux/if_ether.h>).
So its indeed IEEE to address for this, and not IANA.

Thanks for your help on this issue.

Herman.

Herman Elfrink wrote:

> An attempt to clear up the confusion that seems to have occurred:
> FLAME is an intermediate layer between existing MAC and network (IP) 
> layers.
> From MAC layer point of view FLAME is another network layer protocol 
> (besides IP, IPX etc.), so the FLAME protocol ID we are taking about 
> is a network layer (IANA) protocol number.
> From IP point of view FLAME behaves like a 'normal' ethernet-type MAC 
> layer; no need for new IEEE protocol number.
>
> Regards,
>
> Herman Elfrink.
>
> Alan Cox wrote:
>
>> On Maw, 2006-05-23 at 16:55 +0200, Erik Mouw wrote:
>>  
>>
>>>>> Ethernet protocol number I assume you mean. If so this at least 
>>>>> used to
>>>>> be handled by the IEEE, along with ethernet mac address ranges.
>>>>>
>>>>>       
>>>>
>>>> Yes ethernet protocol (it's below IP level), I didn't realise that 
>>>> IEEE also handled the portnumbers. I'll check the ieee website to 
>>>> see how it works, tnx!
>>>>     
>>>
>>> IEEE doesn't handle port numbers. Port numbers are for whatever is
>>> layered on top of ethernet, so you need to register those with the
>>> appropriate authorities (IANA for IP).
>>>   
>>
>>
>> No no no
>>
>> There are several sets of numbers here
>>
>> Each ethernet DIX frame has a "protocol" (its the bits used for length
>> in 802.*). IEEE at least used to handle the assignment of those. On top
>> of that you have IP, IPX, etc with their own numbering agency.
>>
>> As he said "ethernet protocol (it's below IP level)", those are the
>> protocol numbering bodies he wants, or to whomever it was delegated.
>>
>> Alan
>>
>>
>>  
>>
>
>

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Stephen Hemminger]

On Tue, 23 May 2006 16:07:47 +0200
Herman Elfrink <herman.elfrink@ti-wmc.nl> wrote:

>  
> FLAME stands for "Forwarding Layer for Meshing"
> 
> FLAME provides an intermediate layer between the network layer (e.g. 
> IPv4/IPv6) and the link (MAC) layer, providing L2.5 meshing. Both 
> network layer and MAC layer can be used unchanged: to the network layer 
> FLAME appears as a normal Ethernet-type MAC layer, and the underlying 
> `real' MAC layer will see it as just another type of network layer.
> 

Didn't you just reinvent 802.1d bridging? and/or WDS?

As far as the Ethernet protocol field. Getting a real assigned number
would have to come out of the IEEE 802. 

You would need
	http://standards.ieee.org/regauth/ethertype/forms/index.html

It is cheaper (free vs $2500) to get a LLC sap assigned, but then
you would have to change the protocol.
	http://standards.ieee.org/regauth/llc/index.html

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Simon Oosthoek]

Stephen Hemminger wrote:
> On Tue, 23 May 2006 16:07:47 +0200
> Herman Elfrink <herman.elfrink@ti-wmc.nl> wrote:
> 
>>  
>> FLAME stands for "Forwarding Layer for Meshing"
>>
> 
> Didn't you just reinvent 802.1d bridging? and/or WDS?

I wouldn't say "reinvent", but the difference is small but significant. 
FLAME could be seen as ad hoc WDS, I think. It doesn't need to know 
about the other "base-stations", which I think WDS does.

> As far as the Ethernet protocol field. Getting a real assigned number
> would have to come out of the IEEE 802. 
> 
> You would need
> 	http://standards.ieee.org/regauth/ethertype/forms/index.html
> 
> It is cheaper (free vs $2500) to get a LLC sap assigned, but then
> you would have to change the protocol.
> 	http://standards.ieee.org/regauth/llc/index.html

Wow, thanks, $2500 is a bit steep for a useful experiment ;-)
The free option could be interesting though...

Cheers

Simon

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[jamal]

On Tue, 2006-23-05 at 19:43 +0200, Simon Oosthoek wrote:
> Stephen Hemminger wrote:
> > On Tue, 23 May 2006 16:07:47 +0200
> > Herman Elfrink <herman.elfrink@ti-wmc.nl> wrote:
> > 
> >>  
> >> FLAME stands for "Forwarding Layer for Meshing"
> >>
> > 
> > Didn't you just reinvent 802.1d bridging? and/or WDS?
> 
> I wouldn't say "reinvent", but the difference is small but significant. 
> FLAME could be seen as ad hoc WDS, I think. It doesn't need to know 
> about the other "base-stations", which I think WDS does.
> 

Essentially you are extending the broadcast domain i.e a bridge within
on top of a bridge. I would question the scalability of such a beast
in the presence of many nodes. Also take a look at some of the work
Radia Perlman (who invented bridging really) is up to these days.

cheers,
jamal

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Simon Oosthoek]

jamal wrote:
> Essentially you are extending the broadcast domain i.e a bridge within
> on top of a bridge. I would question the scalability of such a beast
> in the presence of many nodes. Also take a look at some of the work
> Radia Perlman (who invented bridging really) is up to these days.
>
>   

Hi Jamal

I agree with your analysis, and recently I read an interesting interview 
with her (I think it was linked from slashdot, an interview with the 
"mother of the Internet ;-) I'm not sure her work (I don't exactly 
recall the specifics) is applicable to our problem though.

Regarding the scalability, I think it rather depends on the number of 
hops how usable FLAME is. I don't think it would scale well to a campus 
or city wide network, but in the case of a few mobile nodes, it has very 
little overhead both in bandwidth and delay.

Cheers

Simon

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[jamal]

On Thu, 2006-25-05 at 12:53 +0200, Simon Oosthoek wrote:

> 
> I agree with your analysis, and recently I read an interesting interview 
> with her (I think it was linked from slashdot, an interview with the 
> "mother of the Internet ;-) I'm not sure her work (I don't exactly 
> recall the specifics) is applicable to our problem though.
> 

Look at her effort ion rbridges, i think youll find theres a lot in
common.

> Regarding the scalability, I think it rather depends on the number of 
> hops how usable FLAME is. I don't think it would scale well to a campus 
> or city wide network, but in the case of a few mobile nodes, it has very 
> little overhead both in bandwidth and delay.

You should mention this limitation in the paper.   
BTW, something else: You ability to create loops of broadcast storms is
highly probable. Eventually you may have to go to L3 (TTL is of value
there) ;->


cheers,
jamal

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Herman Elfrink]

Stephen Hemminger wrote:

>Didn't you just reinvent 802.1d bridging? and/or WDS?
>
>  
>

Hi Stephen,

Yes, more or less, but with a twist.
802.1D does not allow retransmitting over the same interface  (which is 
what basically happens in mesh networks), and WDS uses static 
configuration of neighbouring hops (we want to support dynamically 
changing configurations).

Regards,

Herman.

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Pavel Machek]

Hi!

> FLAME stands for "Forwarding Layer for Meshing"
> 
> FLAME provides an intermediate layer between the network 
> layer (e.g. IPv4/IPv6) and the link (MAC) layer, 
> providing L2.5 meshing. Both network layer and MAC layer 

What is wrong with meshing on L3?

(It is called flame so lets at least have nice flamewar :-)
							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Simon Oosthoek]

Hi Pavel

(I've removed linux-kernel from CC, this is only network related and 
added Herman to the CC, since he's not subscribed)

Pavel Machek wrote:
> Hi!
> 
>> FLAME stands for "Forwarding Layer for Meshing"
>>
>> FLAME provides an intermediate layer between the network 
>> layer (e.g. IPv4/IPv6) and the link (MAC) layer, 
>> providing L2.5 meshing. Both network layer and MAC layer 
> 
> What is wrong with meshing on L3?
> 

Well, I think mostly that L3 meshing is not quite ready to be usable, 
especially if you want to mix IPv4 and IPv6 stacks in the same network 
(dual-stack).

L3 meshing is better for mixing multiple different link layers, but you 
still need to solve address assignment problems and routing, which can 
become quite complicated at L3. In our case, we use dual-stack in a 
hopping network behind a mobile router (which delegates a mobile network 
prefix, NEMO: rfc 3963). In a short-range hopping network (e.g. a PAN) 
using 802.xxx type network interfaces, FLAME is much faster and easier 
to implement than trying to solve it at L3 (twice; dual-stack).

We are of course also interested in good L3 solutions, but so far, we 
haven't come across a good one ;-)

> (It is called flame so lets at least have nice flamewar :-)
> 							Pavel

flamewars are highly overrated IMHO ;-)

Cheers

Simon

Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing

[Herman Elfrink]

Pavel Machek wrote:

>Hi!
>
>  
>
>>FLAME stands for "Forwarding Layer for Meshing"
>>
>>FLAME provides an intermediate layer between the network 
>>layer (e.g. IPv4/IPv6) and the link (MAC) layer, 
>>providing L2.5 meshing. Both network layer and MAC layer 
>>    
>>
>
>What is wrong with meshing on L3?
>
>(It is called flame so lets at least have nice flamewar :-)
>							Pavel
>  
>

Hi Pavel,

I basically have two arguments against L3 meshing, which, for me, were 
strong enough to turn to "below IP" meshing as a better solution for the 
problems I was facing.

The first one comes from my experimental setup where I want to use a ad 
hoc IPv6 network that has one or more Internet access gateways. With ad 
hoc I mean in this context that nodes can be plugged into and taken out 
of the network at any moment in time. If one would do this on a normal 
wired ethernet subnet, this works fine, thanks to the IPv6 
autoconfiguration capabilities: the Internet gateways transmit Router 
Advertisements, which are used by all other nodes to autoconfigure their 
own (global) IPv6 addresses.
When replacing the fixed ethernet by a meshed ad hoc wireless net, I 
would like this to work just the same.
Unfortunately, and here's the argument: basic L3 meshing does not allow 
that. It creates a routing domain instead of a subnet, and IPv6 
autoconfiguration does not work through routers. Similar problems occurs 
with broad- and multicast.
One way to solve this is to re-invent autoconfiguration specifically for 
L3 meshing, which is non-trivial, and which is exactly what is happening 
now in IETF, given the large amount of RFCs on this and related subjects.
Another solution is meshing below IP. Then your mesh network, from 
IP/IPv6 point of view, behaves like a normal subnet again, so all 
standard IP/IPv6 mechanism work as expected.
I've explored both solutions, spent several months on trying (and 
failing) to get OLSR to do what I wanted, and then spent a couple of 
weeks to create FLAME.

The second argument is that in the future meshing is going to be built 
into the relevant MAC layers (see 802.11s and corresponding efforts for 
e.g. Wimax and Zigbee),
so "below IP" seems the natural place to solve this.

Regards,

Herman.