Subject: fixed wireless mesh

From: S Woodside <[email-masked]>
Date: Wed, 6 Aug 2003 17:02:35 -0400

Hi,

The MANET group is not chartered to look at fixed wireless mesh 
topologies. But the IEEE 802.16 group is now looking at this explicitly:

     http://www.ieee802.org/16/meetings/mtg25/agenda.html "Mesh Ad Hoc 
Committee"
     http://www.ieee802.org/16/meetings/mtg25/docs.html "Mesh Ad Hoc 
Documents"

It would not be so great if the attention is fixed at layer 2.

simon

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 6 Aug 2003 15:41:51 -0600 (MDT)

> From: S Woodside <[email-masked]>

> It would not be so great if the attention is fixed at layer 2.

Why not, other than in standards committee turf war concerns?

Exactly what in http://www.ieee802.org/16/docs/03/C80216-03_07.pdf
could possibly be a reasonable topic for the IETF to consider?

Vernon Schryver    [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 Aug 2003 00:17:56 +0200

On woensdag, aug 6, 2003, at 23:41 Europe/Amsterdam, Vernon Schryver 
wrote:

> xactly what in http://www.ieee802.org/16/docs/03/C80216-03_07.pdf

I look forward to seeing the IEEE reinvent the network layer and put it 
_below_ the link layer. This should be fun.

(What else than a network layer would you call something that resolves 
"end-to-end" addresses into next hop addresses, which is necessary to 
navigate across the mesh. This would also need some sort of routing 
protocol and a hop limit field.)

Obviously having wireless mesh nodes route IP would be much too simple.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 6 Aug 2003 16:40:16 -0600 (MDT)

> From: Iljitsch van Beijnum <[email-masked]>

> _below_ the link layer. This should be fun.

How is the IEEE reinventing the network layer this time?  They really
have tried in some previous efforts, but I don't see that this time.

ARQ and FEC can be quite desirable in some link layers, particularly
those that would otherwise have error rates higher than the quite
low error rates that TCP readily tolerates.

> navigate across the mesh. 

What end-to-end addresses in the IP sense are you talking about?

>                           This would also need some sort of routing 

I agree they'll need some sort of routing protocol, but despite my
religious affliation with the Churches of RIP and IP, I do not see
that a "hop limit field" is a requirement.  They will need to prevent
or deal with loops, but IP-style decrementing TTL or RIP-style
incrementing metric fields are not the only way.  For example, perhaps
they could make timestamps work.  Or perhaps they can somehow guarantee
that loops are impossible.

Do you really think that the rest a path through the Internet would
benefit from the route flapping and apparently random decrementing
of the IP TTL field if they were to use the IP TTL field to deal
with loops?

Regardless of the technical issues, do you really think that only the
IETF is allowed to think about routing protocols?  It's decades late
to worry about the IEEE crossing the trade union lines by looking at
routing given the existence of link layer routing protocols including
Spanning Tree.

Do you think that the IETF should be in charge of add-drop protocols
for link layers that have those?  After all, those protocols involve
addresses and a kind of routing and those link layers often carry IP
packets.

> Obviously having wireless mesh nodes route IP would be much too simple.

That statement is not obvious to me, except in standards committee
turf war terms.  My intuition does suggest that none of RIP, IGRP,
EGP, BGP, HELO, or any other IP routing protocol would work well for
what they're trying to do.

Besides, could it be that they want to carry data that don't look
like IP packets?  Do you think the IETF should outlaw such heresies?

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Aug 2003 16:44:41 -0700

> _below_ the link layer. This should be fun.

No worse than the IETF reinventing the link layer and putting it over the
network layer (XOT, L2TP, MPLS, iSCSI, ...).

Tony

---

From: S Woodside <[email-masked]>
Date: Thu, 7 Aug 2003 00:05:34 -0400

> what they're trying to do.

Errr... what about AODV???

As I said before, MANET is chartered for MOBILE applications and not 
fixed ad-hoc mesh as is the case with 802.16 with the new IEEE 
activities. Correct me if I'm wrong, the IETF doesn't have any 
activities looking at the fixed mesh case.

simon

--
simonwoodside.com -- openict.net -- 99% Devil, 1% Angel

---

From: S Woodside <[email-masked]>
Date: Thu, 7 Aug 2003 00:08:05 -0400

Well .... that is their domain after all. What do you expect them to do 
;-)

simon

On Wednesday, August 6, 2003, at 06:17 PM, Iljitsch van Beijnum wrote:

> I look forward to seeing the IEEE reinvent the network layer and put 
> it _below_ the link layer. This should be fun.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2003 12:02:49 +0200

S Woodside wrote:
> Correct me if I'm wrong, the IETF doesn't have any activities looking
>  at the fixed mesh case.

I haven't read the IEEE docs you've sent.

Could the "fixed mesh" case match something like "micro-mobility" or
"local mobility"?

If you were to look into fixed meshes, how would you approach the
problem definition and what tools would you use?  My approach to it
would be to use address autoconfiguration coupled with routing protocol
exchanges.  The deployment space would be rather limited, say no larger
than 50 vertices for the mesh.

Alex
GBU

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 Aug 2003 11:59:45 +0200

On donderdag, aug 7, 2003, at 00:40 Europe/Amsterdam, Vernon Schryver 
wrote:

>> it

> have tried in some previous efforts, but I don't see that this time.

I think they have to in order to make this work transparently to 
everything above the link layer.

> What end-to-end addresses in the IP sense are you talking about?

If you have a link layer with a bunch of nodes where the reachability 
between some nodes is provided by intermediate nodes, the MAC address 
starts to exhibit end-to-end properties. (Hm, I guess we have this in 
ethernet switching today as well.)

> that loops are impossible.

HL is the cheapest way to do it. Try running spanning tree (which bends 
over backwards to avoid temporary loops) in a non-trivial topology and 
you'll agree.

> of the IP TTL field if they were to use the IP TTL field to deal

I certainly wouldn't presume the answer is "no" although it might be.

> IETF is allowed to think about routing protocols?

Of course not. All the best IGPs were invented outside the IETF.  :-)

> like IP packets?  Do you think the IETF should outlaw such heresies?

There are no easy answers here. The only thing I know is that the 
number of supposedly available bits on the medium not used for payload 
is steadily increasing.

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 07 Aug 2003 08:50:18 -0700

Hello folks,

In fact, AODV (RFC 3561) would work for the fixed mesh case
also.  Some of the features for preventing loops in dynamic topologies
would not do much, but then they would not get in the way either.
The lifetimes for active routes "should" be configured to be longer
than in the case of mobile devices, but that isn't hard to do.  Moreover,
even "fixed" wireless mesh topologies probably undergo changes now
and then, so that a wireless routing protocol would be useful even after
the first few minutes of operation.  Plus, we have a specification to
show how the fixed mesh could be hooked up to an Internet Gateway.

Regards,
Charlie P.

---

From: S Woodside <[email-masked]>
Date: Thu, 7 Aug 2003 15:00:07 -0400

> than 50 vertices for the mesh.

I would not want to lock into address autoconfiguration, assigned IP 
address should be possible as well. 50 nodes is a little low, it would 
be nice to have hundreds, maybe thousands, at the "metropolitan" level. 
Hundreds to start with would suffice, if later improvements would show 
promise to scale that up. AODV breaks down over a few hundred IIRC.

It seems to me that gateways to the internet are important. Ideally , 
there would be an autoconfiguration option, a multihoming option (e.g. 
the mesh is multihomed) and a relatively simple managed option.  I 
would like to see a situation where an ad-hoc mesh can also have ad-hoc 
gateways to the internet. After all the fixed mesh is not just for 
contacting other mesh nodes, but to get to the internet too ;-)

simon