[CUWiN-Dev] Wireless BGP, was: ETX metric in Quagga on Linux

[David Young]

On Thu, Jun 09, 2005 at 10:09:25AM +1000, Dan Flett wrote:
> I notice that your ETX is copyrighted.  I'm guessing if I port it I still
> must credit CUWiN and keep the original copyright notice attached.

That's correct.  All of our code is copyright its respective authors
and the Urbana-Champaign Independent Media Center.

> Melbourne Wireless currently uses OSPF, and our network structure more
> resembles a traditional fixed wired network than it does a mesh-style
> wireless network.  Distances between routing nodes are usually greater than
> 1.5km (1 mile) and are often longer than that still.  We generally use
> client-to-AP connections with the clients using directional antennas and the
> AP's with Omni or sector antennas.  Most routing nodes have two or more
> radios - usually one AP and one or more client radios.  Of course this is a
> more expensive way to go than to run a single-radio meshing node.  But the
> node density in our city doesn't seem high enough to allow meshing to work
> properly.  We are trying to create a purely wireless network across a
> low-to-medium density city of 3 million people - we need to cover a lot of
> ground so we believe our network needs a traditional hierarchical structure
> based around a fixed backbone.

I should tell you that I hate the word "mesh." :-) I try not to use
that word for the CUWiN routing.  The word "mesh" does not have a
precise meaning.

The CUWiN routing is autonomous, scalable link-state routing for IPv4
and IPv6 networks.  It is media-agnostic, but radio-aware; radio-aware,
but antenna-agnostic.  It works equally well on a router with two or
three or more interfaces as it works on a router with just one interface.

The design of the CUWiN routing software comes from both OSPF's actual
and anticipated "misbehavior" on a wireless network, and my desire for
the network to run itself.

> Using OSPF at the moment is causing some headaches.  We are using OSPF Areas
> based around theoretical areas of good connectivity.  The problem is,
> reality isn't panning out the way the Area boundaries say they should.
> Nodes within one area are not directly connecting but are instead using the
> backbone to connect, and OSPF doesn't like that.  I believe using OSPF Areas
> on a network like ours is an administrative nightmare.

Is there any empirical reason that you cannot use just one area?

> Most of the
> node-owners aren't network engineers, nor should they be required to be.

This is my philosophy, too.  Also: they should be able to build a
network, anyway.  We can put the networking smarts in the router.

> So we can't use widespread meshing and we can't use OSPF.  What can we do?
> I believe BGP is the answer.  It doesn't care about network topology. Any
> ASN can connect to any other ASN in any way, at any time.

This also describes the point-to-multipoint mode in OSPF.

You may be disappointed if you try to auto-configure your BGP network
using ISC DHCP.

> I've plugged some numbers into the formula on this page:
> http://www.freesoft.org/CIE/RFC/1774/5.htm, and if our network was to grow
> to a size of 1000 ASNs, with one IPv4 /28 subnet per ASN, our routers would
> need roughly 12Mb of RAM.  The WRT54GS has 16Mb of RAM so this isn't a
> problem.  My understanding is that mesh routing is not so much RAM hungry as
> it is CPU hungry as you increase the node-count.  I have read that an OLSR
> network (Friefunk.net in Berlin) with 30 nodes causes a CPU load of 30% on a
> WRT54GS.  I'm not sure how this would scale to 1000 nodes.  I'm sorry but I
> haven't investigated as to wether HSLS is also CPU intensive in the same
> way.

I believe HSLS limited dissemination will help hold down the CPU load
(there will be fewer packets to process), but the high CPU utilization
may be an implementation problem.

> If the node density in Melbourne was higher, I'd certainly be pushing for
> people to use a CUWiN-based solution.

Can you explain how or why "density" influences your choice?

> In fact, I believe there's
> opportunity for a bunch of mesh networks to hang off our BGP-based
> fixed-wireless backbone.  But I have been unable to convince node-owners to
> purchase small-form-factor x86-based router hardware in any great quantity.
> People here simply won't spend the money.  We need something that will fit
> on a WRT54GS - 8Mb Flash memory, 16Mb Ram, 200MHz Mips-el processor,
> AUS$130.  At the moment I'm looking at creating a specialised firmware based
> on OpenWRT - with auto-neighbor-discovering BGP built-in.

People will not spend the money here, either.  That is why I started
looking for sub-$100 routers.  Unfortunately, the WRT will not support
our development agenda.  There's no reason you cannot port hslsd to run
on it, though.

> I'm telling you all this because you guys have obviously thought about these
> issues a lot, and in a lot of detail.  I don't like having to re-invent the
> wheel, especially since the CUWiN software seems to be one of the best
> designed "wheels" I've seen.  But different geographical and regulatory
> factors call for different solutions in our case.  I'd appreciate your
> insights on these issues...

There are two parts to the CUWiN solution, the hardware and the software.
We tailor the hardware for the local environment.  The software is much
more versatile.

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933