[MLB-WIRELESS] Re: [fn-tech] Wireless network structure v1.3-PRE.1

[Cliff Skolnick]

To be honest I think you are looking at wireless as an extension of wired
networks, but hey we know wired networks.  Your stuff is a collection of
standard best practises for wired networks, not really anything new.
Revolutionary, and even evolutionary, wireless networks will have a whole
new set of problems and need new solutions.

I think it is a shame to assume that every node can reach some central
server for IP address allocation.  This can be because you are really trying
to link in a wired network of 5 systems that will have to go through a
wireless router to get on the network.  Is everyone that wants to hook up 2
systems going to run software to become a full fledge internal router in
your setup?  Or will all of them need to directly connect to the wireless
network's internal router?  Or are you going to hack stuff with dhcp relays
and proxy arp to glue stuff together in your network?  Or will this box be a
simple bridge in this case?  How about an example connecting an etherneted
network of machines to the wireless network?

My vision is a community network user should be able to plug a box into a
network on machines, a whole LAN, and have the thing take care of all
machines.  I disklike the vision of a user being only one computer, and much
prefer the idea that this box is a gateway for n users.  A dynamic mesh can
deal with this easily, but at a cost of gobling up lots of IPs.  NAT,
although evil, is my friend.

Comments:


1) Hierarchical structure does not work for mesh networks, varients of
   mesh are the future.  OSPF will not be used for mesh networks, mesh
   protocols will be.  Your definitions don't fit well with mesh networks
   since everyone is a node and a router.

2) OSPF not RSPF, RSPF handles radio links better.

3) Dynamic configuration depends on a central authority, well this
   sort of is related to #1 but is important enough to mention in it's
   own right.  Frankly IP allocation in a mesh network is a bit more
   difficult and attempting to use networks to reflect locality (what
   I am attempting) results in sparse address space usage to allow
   route aggregation to avoid routing table overload.  And there is
   no central authority in the network, just loose cooperation at
   nodes that link the various meshes to each other.

4) IP allocation depends on agreement of all groups which will not scale
   since we're generally a bunch of anarchists.  NAT will save us, but this
   will require globally unique IP name space that is much larger that the
   RFC 1918 blocks.  Fortunately we have the internet assigned IPs for that,
   even though we may route those IPs over wireless.

5) It is dangerous to depend on RFC 1918 addresses routing outside their
   immediate control.  Frankly the backbone/mesh network I am working on
   will use the whole 10.x.x.x/8 space, sparsely.  These IPs were
   allocated to do this type of thing, and frankly depending on anything
   else is abusing the RFC IMHO.  Did I mention those addresses were
   intended to be completely under local control?  Did I also mention
   that the backbone nodes will be eating a good chunk of the 192.168.x.x/16
   space negotiating unique links dynamically?

Cliff

On Mon, 18 Feb 2002, Simon J Mudd wrote:

> Hello all,
>
> I've made several changes to the original document I announced a few weeks
> ago which tries to give guidelines for building wireless networks.
>
> I've made a large number of changes to this versión and hopefully it
> should now make a little more sense.
>
> You can find this at:
>
> http://pobox.com/~sjmudd/wireless/network-structure/test/
>
> I'd appreciate any final comments before finalising this version.
>
> Thanks and regards,
>
> Simon
>

-- 
   | Cliff Skolnick          | "They that can give up essential liberty to |
   | Steam Tunnel Operations |  obtain a little temporary safety deserve   |
   | cliff at steam.com         |  neither liberty nor safety."               |
   | http://www.steam.com/   |                  -- Benjamin Franklin, 1759 |


--
To unsubscribe, send mail to minordomo at wireless.org.au with a subject of 'unsubscribe melbwireless'  
Archive at: http://www.wireless.org.au/cgi-bin/minorweb.pl?A=LIST&L=melbwireless
IRC at: au.austnet.org #melb-wireless