Re: [Autoconf] aspects of multi-hop wireless communication

["Breno Jacinto" <[e-mail]>]

Hello,

     That's a very interesting discussion, indeed. I didnt see anyone
mentioning related work about underlay networking (meaning: routing
below IP), and there has been some interesting work in academia, as
well as some practical efforts to prove the concept. Since this is my
line of research currently, let me cite some of the related work:

- 802.1D bridging: as Alexandru cited, that is an already available
implementation, stable and functional and can do bridging and create
an illusion for IP that there is a simple Ethernet network below it.
Now, as Teco mentioned, I also could NOT make it work with 802.11 in
*AD-HOC* mode (Alexandru, I'd be glad to know how you managed to do it
without any special patch or tweak on the drivers, using just the
standard). Other people tried with AP mode and it works (and this is
expected, as the popular APs such as WRT54G do it for Ethernet and
802.11 networks).

- 802.11s (http://en.wikipedia.org/wiki/IEEE_802.11s): nobody cited
it, but this standard is supposed to implement multi-hopping at layer
2, instead of layer 3 as all Ad Hoc protocols do (OLSR, AODV etc...).
As everyone knows, 802.11 b/g standard does not support multi-hop for
real.

- AWDS (http://awds.berlios.de/) - Ad Hoc Wireless Distribution
System. This project is quite stable and functional implementation a
layer 2 protocol for doing multi-hop communication over ordinary
802.11 b/g cards. Now, to me this is pretty much what 802.11s is
attempting to do, but does it now. It works, and it is being tested in
test-beds today. It is a very active project, but it seems it hasnt
got very popular up to now.

- Ana4 Framework (http://ana4.citi.insa-lyon.fr/): An academic
initiative with the intention of transparent connecting heterogeneous
networks at the underlay, i.e., at a virtual 2.5 layer. It is supposed
to work with any link-layer, including Bluetooth, but actually they
just implemented for Ethernet and 802.11 ad hoc networks. I tested it,
and it works. It's like bridging, but it actually does real routing in
a virtual network (and I could interconnect an Ethernet and 802.11 ad
hoc network).

- MIT RoofNet (http://pdos.csail.mit.edu/roofnet/) and B.A.T.M.A.N
(http://en.wikipedia.org/wiki/B.A.T.M.A.N.),  are, as far as I can
tell, implemented as a layer 2.5 protocol. Unfortunately I could not
study them deeply enough to confirm this, maybe someone on the list
can.


     Now, going back to this draft, which I believe to be of utmost
importance, I think some questions must be answered as well:

- Should Mult-hop communications happen at the IP layer, really? I
think that this decision was taken just because 802.11 b/g standard
become popular and could not do multi-hop at layer 2. So, everyone
thought, let's do it at layer 3, because it is possible to emulate
multi-hop then.

- If multi-hopping is done at layer 2, isn't that a good thing? I
mean, you can deal with problems specific to the link layer (including
the aforementioned hidden node problem, or whatever
next-popular-link-layer for multi-hop become available in the future)
and make IP more neutral. I think that would conserve the initial aim
of IP, which is simply to glue heterogeneous networks, not fixing a
particular link-layer problem as it is being done with 802.11 b/g.

- Now, if we could assume that multi-hop is done at layer 2; to layer
3 (such as IP), a broadcast should reach (be flooded to) everyone in
the network. Now, IP sees the network as a single broadcast domain and
issues in the "real" network should be dealt there. We may then shift
to the problem of connecting multiple ad hoc networks at the IP layer,
doing inter-domain routing etc..

    I'm sorry for so many observations: I hope to contribute for the
discussion and show some of the research that's been done in the last
years in ad hoc networking (and not everyone is aware of, I think).

regards,
-- 
-- 
:: Breno Jacinto ::
:: breno - at - gprt.ufpe.br ::
:: FingerPrint ::
   2F15 8A61 F566 E442 8581
   E3C0 EFF4 E202 74B7 7484
:: Persistir no difícil é a única maneira de torná-lo fácil algum dia.  ::



2008/12/20 Teco Boot <[e-mail]>:
> |> Try it, and you will see it will fail.
> |> OK, you can modify the code if you have a C compiler nearby, and some
> |> sources to modify.
> |
> |I'm not meaning to modify any code.  It's existing software doing
> |bridging between two interfaces as it always did.
>
> No, you are prohibited to add a 802.11 IBSS interface to a bridge.
>
> OK, you can do it without warnings, but the 802.11 mechanisms will not
> operate as they should. There are problems with address fields, the NIC
> cannot send CTS or ACK to the sender, because the transmitter MAC address is
> missing in the RTS or DATA MAC header.
> You could disable RTS-CTS and send unicast frames until retry limit, but is
> this the behavior that you suggest?
>
>
> |> But that is no longer wifi.
> |
> |Well, it's two 802.11a/b interfaces, running as before.  I could put
> |both interfaces in ad-hoc mode with iwconfig.  There's probably a
> |misunderstanding between what the IEEE standard documents mean by
> |"ad-hoc" and what iwconfig and related implementations mean by "ad-hoc"
> |but I'm sure it works, by experience.
>
> I am not aware with problems with iwconfig. It should configure the NIC in
> IBSS mode.
>
>
> |Or I could set up both to act as access points, it's the same.  (the
> |only visible difference  between AP mode and ad-hoc modes in
> |implementation is the MAC address of the essid... in AP mode it's the
> |real MAC address of the interface doing AP, in ad-hoc mode it's some
> |random 48bit).  The resolution between this 48bit number and essid ascii
> |name is done by 802.11 link-layer exchanges (probe req/reply IIRC).
>
> There are lots of other differences between IBSS and BSS.
>
> On (R1, R2, A):
> What if A is STA and R1 and R2 are APs? Assume APs cannot communicate with
> each other (no DS). Assume some kind of disaster.
>
> One could deploy dense APs and a (to be standardized) form of mesh MANET
> protocol. This could be disaster^2!
> (think of beacon-rain and probe-response-storms, and melt downs due to
> collisions)
>
>
> |> You could enable routing, and you are done!
> |
> |Why doing routing when I could do bridging, simpler, widely available
> |software.
>
> Try and you will see lots of shortcomings with bridging and 802.11 IBSS.
> I am not saying it cannot be solved at a shim layer, but please accept this
> is not supported by current wifi standards.
>
> And provide evidence if I am wrong. I will ask errata on the IEEE 802
> standards if you come up with it.
>
>
> |> Play a little with it, and check your (false) assumptions.
> |
> |I'm not sure which assumption you think I made false?  The fact that I
> |could build a bridge with brctl and two wifi interfaces?
>
> I explained above your assumption is false. I analyzed your suggestions
> before and my conclusion 802.1D bridging is indeed not allowed with 802.11
> IBSS.
>
>
> By the way, there is code around that improves 802.11 IBSS mode, so bridging
> is allowed. Ask Ronald In't Velt for details. This could be very useful if
> you want to connect a 802.11 IBSS bridge to a router (split devices) or just
> connect a couple of hosts to an ad hoc bridge.
>
>
> Teco.
>
>
> _______________________________________________
> Autoconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/autoconf
>
_______________________________________________
Autoconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/autoconf