[MLB-WIRELESS] So how does this routing bit work?

[Ben Anderson]

> ben> That "knowing" is done by the ARP cache of ethernet MAC's.  A
> ben> router and a
> ben> bridge are different technologies.  One does the
> ben> re-transmission decision at
> ben> the data-link layer (layer 2 OSI), and the other does the
> ben> re-transmission at
> ben> the network layer (layer 3 OSI).  The retransmission done at layer 2
> ben> effectivly makes that look like everything is part of the same
network
> ben> segment to layer 3 and above, whereas when the layer 3 routing
> ben> occurs, it's
> ben> only layer 4 and above that appears to be part of the same network.
>
> OSI?? I thought we were talking TCP/IP. The models are totally different
and
> there is no correlation between the 7 layer OSI model and the 4 layer
TCP/IP
> model.

TCP/IP can be mapped onto the OSI model...  TCP/IP has no data-link or
physical layers, yet for it to work, such concepts are necessary if you want
to do anything more than bounce packets over a loopback device :)
So...
1.  Physical <-- network hardware that actually does the transceiving
2.  Data-link <--  Medium sharing strategy, ppp, hdlc, ethernet MAC are all
examples of protocols that fit here
3.  Network <-- This is where IP fits in
4.  Transport <--  This is where TCP fits in.
5.  Session <--  Session state variables are kept at this layer
6.  Presentation <-- unpacking, conversion, encryption/decryption, etc is
what this layers defined to incorporate
7.  Application <-- this is where ftp, telnet, http, etc sit.

If we, for example, threw out the network layer (which we could think about
say on an unrouted ethernet cloud), we could still make everything work by
getting packets around just by MAC address...  My point is we can keep the
IP layer, but use layer 2 to keep the majority of the smarts in routing
packets around the wireless mesh (I still think looking at layer 3 and 4
state information will be useful in layer 2's routing strategy, but it
shouldn't need to modify data, just listen to it)

> <snip>
>
> ben>
> ben> Unless there's repeating done, it never will.  Most of the
discussions
> ben> previously have been about getting this done at layer 3 OSI.
> ben> I'm designing a method that should either shim, or replace
> ben> layer2/3 OSI....
> ben> And hopefully this solution should solve a lot of the issues you
point
> ben> out...  Certainly, it's not finished, and it's not a short
> ben> term project.
>
> This is a massive project, and I foresee the need to have firmware written
> to drive this concept, not just some application layer stuff. That implies
> cooperation from the RF card manufacturers!!

How did you manage to get layer 2/3 OSI to map onto the applicaiton layer?
I've never been talking application layer to solve this problem.
In terms of the long term future, I want a generic radio interface with a
dsp and a big-honkin fpga sititng behind it.  Such a device is probably
going to have a hard time getting past standards bodies, since it allows
'breaking the law' easily...  But it should be awesome for anyone with a HAM
licence (which aren't hard to get thesedays).

> <snip>
>
> ben>
> ben> Not really a big problem.  Any network card with a diversity
> ben> antenna could
> ben> for example have two antennas off the one device, when the one device
> ben> transmits, both antennas get the signal (rx is turned off)..
>
> ??? Diversity is a method of using multiple antennas to improve QoS in a
> poor signal situation, particularly when fading occurs. I don't understand
> what you are attempting to do with the two antennas.

Exactly what you said...  Diversity antennas basically multiplex two
antennas onto one receiver, and it switchs to the antenna with the best
signal/noise ratio at the time...   It gets rid of the duplex issue when you
run multiple cards.  No loops, etc, since tx & rx can't occur simultaneously
using this method, which I believe solves the point you brought up initially
in this little thread.


> ben> badda bing, it
> ben> works.
> ben> Alternativly, if there is actually 2 real nodes, just have it
> ben> so that they
> ben> can't see each other, either by having a different hopping
> ben> sequence on the
> ben> same channel, or just using a different channel, then there's
> ben> no risk of a
> ben> loop as they're not receiving each others transmissions  (well...
they
> ben> could interfere, depending on the quality of hte bandpass
> ben> filters in the
> ben> device, but due to the different hop sequences, it won't do
> ben> anything but
> ben> make traffic on the other interface harder to hear)
>
> With more than 15 yrs experience in radio systems I remain totally
> unconvinced.

What you just did is called an "appeal to authority" and is a fallacy in
logic.  What radio systems have you worked with, why are you still
unconvinced?


> ben> Hopefully my comments sort this out for you...
>
> eerrrrr no. You may think I'm just sceptical, but I have serious doubts
that
> this is the right approach. I think the groups would be much better off
> utilising an "out of box" solution. Shouldn't we be looking to the US and
> Europe for working systems that we can leverage?

You find a solution that solves the problems I want to solve, and I'll use
it.  I don't believe it exists, which is why I'm looking at engineering a
solution.  American and Europe, for all they've contributed, aren't the only
source of innovation.
Short term, out of the box makes sense.  Long term, a better out of the box
solution makes sense.  It's this better solution that I'm trying to get
built.

Ben.