[MLB-WIRELESS] more important issues <aka: guerilla radio is by ninjas, for ninjas. Worked for global IP's development!>

[David Arnold]

-->"Drew" == Drew  <drew at wirelessanarchy.com> writes:

  >> IP addressing - lots of work needed here to make sure scalability
  >> and flexibility (roaming clients, distributed
  >> administration/delegation, access parameters standard, etc)

i like the seattlewireless folks plans here.  they're planning
basically a 4-layer hierarchy, with Ax, Bx, and Cx nodes forming the
infrastructure with varying degrees of interconnectedness.

    http://www.seattlewireless.net/index.cgi/BxNode

client nodes then connect to their nearest infrastructure node.

they're using the 10/8 address space, with Bx and Cx nodes
basically reflecting the old B and C-class (/16 and /24) address
spaces and Ax nodes being very-well-connected Bx ndoes.

client nodes (ie. you have a single antenna connected to a
neighbourhood/suburb access point) connect to a *x node.  Cx ndoes are
limited to 254 clients.  using DHCP, i doubt that's going to be a
problem -- you'd need multiple channels/cards to support that number
of simultaneous clients anyway.

you've then got 255 Bx nodes above that, giving possible a total of
64k sites forming the infrastructure.

this seems a little more complete than the scheme described in the
M:D&W RFC.

i'd actually prefer to use IPv6 and try to get a real allocation
rather than NATing all over the place, but the last time i suggested
this most people were opposed :-(

for some possible approaches, see the brismesh address allocation
policy docs

    http://www.itee.uq.edu.au/~mesh/db2/address.html


  >> DNS hierachy to bring some workable order and structure to the
  >> chaos

the M:D&W RFC proposes a new "wan" TLD, and a "mlbwire" 2nd-level
entry to be subdivided by suburb name and optional distinguishing
number.

i also wonder about using the geographical location attributes to
support automated support for mobile handover, etc.  see

    http://rfc/net/rfc1876.txt


  >> Infrastructure - who? where? how?

there's a bunch of potential infrastructure that could be useful.
links and routing are the basic level, DNS probably next.  

sites that are prepared to act as local aggregators will need at least
one "upstream" link.  more would be better, giving some resilience.
this will mean multiple antennae (omni for connection of local clients
and possibly downstream links plus a directional for the upstream
link(s)), and probably multiple cards (if for no other reason than to
use different channels for the different links).

DHCP for pure client nodes seems sensible?

support for mobile nodes would be interesting, and might benefit from
some infrastructure services.


  Drew> the RFC has been up for comment/modifications/whatever for
  Drew> months, but nobody has done any of the above.

  Drew> http://melbwireless.dyndns.org/rfc/

i guess since there are few links actually operational, no-one's had
the need to question it so far?

as the backbone nodes start to have more than one interface, we're
going to need a dynamic routing protocol.  anyone had any thoughts in
this direction?





d

--
To unsubscribe, send mail to minordomo at melbwireless.dyndns.org with a subject of 'unsubscribe melbwireless'  
Archive of the Entire mailinst list at:
http://melbwireless.dyndns.org/cgi-bin/minorweb.pl?A=LIST&L=melbwireless