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

[Dan Flett]

Hi David,

Thanks for the info (and thanks Bryan too).  I'm afraid I don't know too
much about the internal workings of Quagga to know what's really possible
right now - but I suppose if I can convince someone to port ETX to Linux
Quagga I guess I got get them to make it work with BGP. :)

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.

I'm investigating the use of BGP for the Melbourne Wireless network.  A
number of wireless groups use it - WAFreeNet in Perth uses it quite
successfully.  Here is a live BGP map of their network:
http://planetaxis.sytes.net/current/bgpmap.cgi

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.

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.  Most of the
node-owners aren't network engineers, nor should they be required to be.

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.  The only change
that needs to happen is when two ASNs connect - they simply specify each
other as neighbors in their config files and away they go.  And I'm looking
at ways to automate this using DHCP.  Whilst ASNs are designed to cover
multiple routers and multiple subnets, WAFreeNet proves that you can get
away with a single ASN per router and it's single subnet.

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.

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

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...

Cheers,

Dan

-----Original Message-----
From: cu-wireless-dev-bounces at lists.cuwireless.net
[mailto:cu-wireless-dev-bounces at lists.cuwireless.net] On Behalf Of David
Young
Sent: Wednesday, 8 June 2005 3:57 PM
To: cu-wireless-dev at cuwireless.net
Subject: Re: [CUWiN-Dev] ETX metric in Quagga on Linux

On Wed, Jun 08, 2005 at 03:02:05PM +1000, Dan Flett wrote:
> Hi all,
> 
> I like the idea of the ETX metric a lot, and I'm wondering - how easy 
> would it be to port to Linux to integrate it with the Linux version of
Quagga?
> >From a casual look through the CU-Wireless CVS I note that ETX seems 
> >to
> reference HSLS stuff a lot - can ETX be used with other routing protocols?
> I'd like to try using it with BGP.

Dan,

Our ETX messages piggyback on HSLS Hellos.  I cannot think of any reason you
cannot easily peel ETX apart from HSLS.

I don't know whether the Quagga BGP daemon provides an API for setting
metrics or "piggybacking" information on the BGP Hellos, do you?

Just curious, why have you picked BGP for your network?

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933
_______________________________________________
CU-Wireless-Dev mailing list
CU-Wireless-Dev at lists.cuwireless.net
http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev