From: Herman Elfrink <hidden> Date: 2006-05-23 14:07:50
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.
From: Stephen Hemminger <hidden> Date: 2006-05-23 14:39:03
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.
From: Simon Oosthoek <hidden> Date: 2006-05-23 14:41:50
Alan Cox wrote:
On Maw, 2006-05-23 at 16:07 +0200, Herman Elfrink wrote:
quoted
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
From: Simon Oosthoek <hidden> Date: 2006-05-23 14:51:16
Stephen Hemminger wrote:
O
quoted
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 ;-)
From: Erik Mouw <hidden> Date: 2006-05-23 14:55:53
On Tue, May 23, 2006 at 04:41:48PM +0200, Simon Oosthoek wrote:
Alan Cox wrote:
quoted
On Maw, 2006-05-23 at 16:07 +0200, Herman Elfrink wrote:
quoted
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
From: Simon Oosthoek <hidden> Date: 2006-05-23 15:00:42
Erik Mouw wrote:
On Tue, May 23, 2006 at 04:41:48PM +0200, Simon Oosthoek wrote:
quoted
Alan Cox wrote:
quoted
On Maw, 2006-05-23 at 16:07 +0200, Herman Elfrink wrote:
quoted
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/
On Maw, 2006-05-23 at 16:55 +0200, Erik Mouw wrote:
quoted
quoted
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:
quoted
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.
From: Steven Rostedt <rostedt@goodmis.org> Date: 2006-05-23 15:09:41
On Tue, 2006-05-23 at 16:51 +0200, Simon Oosthoek wrote:
quoted
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
From: Stephen Hemminger <hidden> Date: 2006-05-23 16:43:29
On Tue, 23 May 2006 16:07:47 +0200
Herman Elfrink [off-list ref] 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.
From: Simon Oosthoek <hidden> Date: 2006-05-23 17:42:49
Stephen Hemminger wrote:
On Tue, 23 May 2006 16:07:47 +0200
Herman Elfrink [off-list ref] wrote:
quoted
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.
On Tue, 2006-23-05 at 19:43 +0200, Simon Oosthoek wrote:
Stephen Hemminger wrote:
quoted
On Tue, 23 May 2006 16:07:47 +0200
Herman Elfrink [off-list ref] wrote:
quoted
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
From: Pavel Machek <hidden> Date: 2006-05-24 20:50:49
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.
From: Simon Oosthoek <hidden> Date: 2006-05-25 09:36:32
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!
quoted
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
From: Simon Oosthoek <hidden> Date: 2006-05-25 10:53:14
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
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
From: Herman Elfrink <hidden> Date: 2006-05-30 06:42:07
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:
quoted
quoted
quoted
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
From: Herman Elfrink <hidden> Date: 2006-05-30 07:01:52
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.
From: Herman Elfrink <hidden> Date: 2006-05-30 08:29:55
Pavel Machek wrote:
Hi!
quoted
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.
From: Herman Elfrink <hidden> Date: 2006-05-30 08:43:40
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:
quoted
On Maw, 2006-05-23 at 16:55 +0200, Erik Mouw wrote:
quoted
quoted
quoted
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