[Goat] routing

Benoit Grégoire bock at step.polymtl.ca
Lun 26 Avr 10:17:29 EDT 2004 

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

On Monday 26 April 2004 01:56 am, William Waites wrote:
> On Sun, Apr 25, 2004 at 10:10:08PM -0400, Benoit Grégoire wrote:
> > >       \|/  ...  \|/             \|/  ...  \|/
> > >
> > >      +---+     +---+   +---+   +---+     +---+
> > >
> > >      | A |     | B |---| C |---| D |     | E |
> > >
> > >      +---+     +---+   +---+   +---+     +---+
> >
> > 1- Run the same routing protocol on nodes B, C and D as the rest of the
> > mesh. Note that that does not imply that it's the only routing protocol
> > that is run on those three nodes, only that the protocols do not talk to
> > each other. "Node" C  only hears two other nodes (B and D), but with very
> > high speed and reliability.
> >
> > 2- We don't want to bother with the problem, and simply add a VPN (or
> > PPPoE, or  whatever) between  B and  D, making  the two  of  them
> > broadcast reachable.
>
> What happens if C is plugged into a hub with some servers that
> don't participate in the protocol? 1 doesn't work because there's
> no way to tell the other nodes about those servers "care of" this
> gateway, 2 doesn't work because C doesn't exist.

Off course it works, as long as C knows that B and D are gateways to the 
address space of the mesh.  Neither 1 and nor 2 removes the need for basic 
network configuration.  However both 1 and 2 assume that the mesh protocol 
knows something about subnets.

> > 3- We make the wired and wireless protocols talk to each other.
>
> 	[...]
>
> > Indeed, I don't see much benefit in cross connecting the protocols.
>
> We must if we want servers like people's home linux boxes
> to be reachable from other sites on the network. This is not
> possible with SrcRR alone.
>
> > Well, the case I was discussing is if someone were to connect
> > an existing LAN  to the MESH.  The wireless protocol would be
> > wastefull inside the LAN,
>
> Of course. But ScRR deals with reachability within the
> MESH (or sub-mesh) not reachability to outside destinations
> like the LAN.
>
> SrcRR is a very good layer 2 protocol. But the other MESH
> nodes have to know about the subnet that lives on the LAN.
> ScRR doesn't solve this. The RoofNet guys solve it with NAT,
> which just ignores the problem (because they're concerned
> with giving people Internet access)

The RoofNet guys don't solve it at all.  But RoofNet just "happens" to use IP 
adresses for routing, but you can use anything.  My idea was to use the 
network number of the subnets the router is responsable for, but it just 
flashed me that I have absolutely no Idea how to make that work for more than 
one gateway.

I suppose the gateway could have multiple adresses on RoofNet (one for each 
possible IP in it's subnet(s), but that doesn't solve the multiple gateway 
problem either.  

I didn't check if OSLR or AODV have any support for this.
  
> > Now for small lan, it will be much simpler to simply run the wireless
> > routing  protocol everywhere and be done with it.
>
> What address do you give the computers on the LAN?

Same ones as in the Mesh obviously, otherwise you need NAT.

> > > > - -No centralised network management.
> > >
> > > this is not required with ospf or bgp either -- all
> > > that is required is for you to get your neighbours
> > > to talk to you.
> >
> > In the trivial case, I'll grant you that.
>
> Are you saying that interdomain routing is centralized?
> The degree of centralization lies with how "domain" is
> defined. Each autonomous system is just that: autonomous.
> Without changing BGP at all, there are 65k autonomous
> system numbers, with a population of 3,000,000 that's
> one for every 45 people with no operational centralization.

Can we argue that in person? We are obviously lost in semantics here.

> > Ok, perhaps I worded that badly.  Radio links can have
> > a whole range of intermitent falures and packet loss.
> > It was my understanding that OSPF and similar routing
> > protocols can take up to several minutes to detect link
> > state change.
>
> True, although tuneable somewhat with the timers. The
> tradeoff is rigidity (response time to failures) vs.
> scalability. BGP scales very well but requires very
> reliable links. OSPF scales badly and requires
> mostly reliable links. ScRR scales badly (it uses
> Dijkstra like OSPF so has the same scaling properties)
> but can deal with inconsistently lossy links.
>
> Covering the island with SrcRR won't work. Connecting
> a bunch of SrcRR networks with OSPF and BGP might work.
> OSPF can then run over SrcRR so that the routers at the
> edge of ScRR clouds know about next hop reachability.
> BGP can isolate OSPF clouds to the degree of autonomy
> required for sociological as well as scalability reasons.

Covering the whole island with a grid of nodes spaced by 1000 meters on 
average would require only less than a thousand nodes.  Is scaling to 1000 
nodes a problem for Dijkstra's algorithm?  

> This works because SrcRR makes the wireless meshes
> look reliable to OSPF. I'd like to test this out,
> perhaps at the next hack night.

Defining clouds, and thus cloud edges in the MESH may be extremely 
challenging.  Some nodes at the edges may see very far, while other will have 
very narrow coverage.  But it's worth discussing. 

> The one crucial thing that has to be solved and that
> SrcRR provides no immediate answer to is how to make
> subnets that are not part of the wireless stuff
> addressable directly over the wireless stuff. RoofNet
> tries to solve it with NAT, which is not an option.
>
> Once it is solved, we can figure out how to minimize
> the configuration so that people that aren't interested
> in knowing much about the nuts and bolts of the routing
> can participate.

Well, it's quite likely that none of the Routing protocols will fill be 100% 
of the requirements without modifications.  In fact my shoping list is:

- -the EAX (or similar) metric algorithm
- -Support for IP subnets
- -A reactive protocol if the MIT paper's findings against proactive protocols 
hold.

and isn't directly met by any protocol that I know of. 
- -- 
Benoit Grégoire, http://step.polymtl.ca/~bock/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAjRn5mZ6zzPlLuwMRAixSAJ98DxUHcA07Hyq2VIXpnb+SJ3bJwACgp2a3
HLcgAGjdMMCsFPdgWFYyhJI=
=o5B+
-----END PGP SIGNATURE-----

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

More information about the Mesh mailing list