[Goat] routing

[Benoit Grégoire]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 24 April 2004 08:42 pm, ww at parc.styx.org wrote:
> some ideas re: dynamic routing in the mesh.
>
>  1. globally unique addresses are desireable.
>    a. RFC1918 addresses don't fit the bill 'cause
>       people are already using them. addressing
>       conflicts are a pain.
>    b. using an unallocated block (or defunct
>       allocation) is better, but these addresses
>       may be used in the future. it is also at
>       odds with the policies of the RIRs and
>       traditional best practices.

There have been unsuccessfull attempts in the past by wireless umbrella 
organisations to get a block of adresses allocated officially for wireless 
networks.  This has resulted in the creation of WIANA 
http://www.wiana.org/faq.php and efforts by freenetworks to keep everyone 
coordinated 
http://www.freenetworks.org/moin/index.cgi/NetworkAddressAllocations.  So 
established best practices isn't an argument not to do it, as the 
establishment refused to cooperate.

>    c. it is possible to be allocated ipv4 blocks
>       in the usual way.
>       i. this brings the burden of either getting
>          someone to announce these addresses on
>          behalf of the mesh or also obtaining an
>          ASN and making peering arrangements if
>          direct connectivity to the Internet is
>          desired.
>       ii. these addresses are scarce and expensive
>          to obtain.

That's unrealistic for a free network.

>    d. ipv6 addresses are plentiful and readily
>       available.
>       i. using RFC3056 (stf or 6to4 addresses),
>          a single ipv4 address maps into 65536
>          subnets of stadard /64 size.

I have to admit RFC3056 is quite tempting, but we can't just get rid of ipv4 
entirely for now.

>       ii. it has been pointed out that ipv6 is
>          percieved as "hard" for end-users.
>          perhaps a hybrid approach is in order?

Indeed, it would be interesting to run an ipv6 and an ipv4 network on the mesh 
in paralel, especially since part of it's purpose is to be a research 
network. How hard that would be in practice I don't know.  

>  2. hybrid addressing.
>    a. obtain one static ipv4 address that is not
>       likely to change at any point in the forseeable
>       future (since renumbering is a pain no matter
>       what the addressing scheme).
>    b. build the backbone of the mesh using these
>       numbers.
>    c. at each node that provides service to end users,
>       RFC1918 addresses that need not be unique are
>       used.
>       i. the node will run a caching nameserver,
>          BIND9, that listens on its ipv4 address and
>          forwards queries over ipv6 to authoritative
>          nameservers and external gateways.
>       ii. the node will run squid, or a similar proxy,
>          likewise listening on the ipv4 address and
>          forwarding requests over ipv6.
>       iii. using a similar strategy, for other tcp
>          services, application layer proxying can be
>          configured.

All that requires central planning and administration and heavyweight software 
to run on each nodes that will be very hard to fit in an embeeded platform on 
top of an antenna mast.  But most importantly, the network won't be Free, as 
it will require explicit application level proxying to run ipv4 services.

>    d. of course the end users are also allocated an
>       ipv6 address. these addresses are routed natively
>       and so have no need for proxies.
>    e. so done this way the mesh is a native ipv6
>       network providing limited but functional support
>       for legacy devices that only speak ipv4.

That won't do, it doesn't allow clients to use ipv4 software over the mesh.  
Remember, the primary purpose of the mesh is to communicate with other mesh 
nodes, not to get traffic out of the mesh (even if that is one possible 
application)

>  3. routing protocols.
>    a. all of the routing protocols mentioned on the
>       wiki page have three inter-related drawbacks.
>       i. support for operating systems other than linux
>          is very limited.

Not really true of AODV and OLSR.  However it's quite true of RoofNet, which  
we are also very seriously considering, but isn't really focussed on in the 
page.

>       ii. support for what would be called "areas" with
>          ospf is very limited.

I don't see that as a problem, none of the protocols we are considering need 
to build a complete map of the network.    And you still need only one node 
capable of mesh routing to serve a wired subnet.

>       iii. support for interaction in a predictable way
>          with other protocols (i.e. rip, ospf, bgp) is
>          limited -- i.e. there is no support for these
>          in zebra/quagga or gated.

Well, that would be an interestion projet to get them to work together.  But 
in any case the interaction isn't very complicated.  Whatever protocol is 
chosen would need to answer queries to adresses advertised (or implied by) 
the RIP, OSPF or BGP, for which it is a gateway.  All the other protocol need 
to know is the existence of the gateway, capable of reaching the entire 
adress space chosen for the mesh. 

>    b. what do these specialized routing protocols give us
>       that say, ospf with equal-cost or weighted-cost
>       multipath routing does not?

- -No need to contact anyone to get on the network (except for reserving IP 
space)
- -No centralised network management.
- -Automatic routing around dead nodes.
- -Does not assume that connection is bidirectionnal.
- -Does not need to maintain a routing table covering the whole network.

>       i. support for equal-cost multipath exists in
>          linux and (limitedly) in netbsd as well as
>          ios and junos.
>       ii. zebra/quagga supports equal-cost multipath.
>       iii. an implementation of weighted-cost multipath
>          would not be too hard but would require some
>          kernel hacking as well as modification of
>          zebra/quagga.

The problem is mesuring equal cost.  The reason I am pushing for RoofNet is 
that on a wireless network you cannot assume over many hops that the fastest 
route is the shortest one, nor can you know the bandwith you have with each 
of your peers without continuous mesurements.   

This paper explain a lot of the isues and possible solutions, I very much 
encourage everyone to read it:  
http://www.pdos.lcs.mit.edu/papers/grid:mobicom03/paper.pdf

> thoughts?

I'm happy finally someone else stepped up to challenge my vision of the 
MESH ;)
- -- 
Benoit Grégoire, http://step.polymtl.ca/~bock/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAjAp7mZ6zzPlLuwMRAlERAKDShPD9Y8cQ3RnMdn9qwlTcW6YY5gCfYNPq
Z4GLYSaUj4Pvb0EePu/ZibE=
=m4pd
-----END PGP SIGNATURE-----

_______________________________________________
Goat mailing list
Goat at isf.waglo.com
http://isf.waglo.com/mailman/listinfo/goat_isf.waglo.com