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.
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.
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.
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
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 ;-)
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 -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
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
[email protected]
http://www.ti-wmc.nl/
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
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.
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
On Tue, 23 May 2006 16:07:47 +0200
Herman Elfrink <[email protected]> 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
Stephen Hemminger wrote:
> On Tue, 23 May 2006 16:07:47 +0200
> Herman Elfrink <[email protected]> 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
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.