[MLB-WIRELESS] [TECH] Dipole antennas, and melbwireless structure

[Ben Anderson]

I'm fully aware of that.

How does OSPF split the network up into managable areas?  That's right, it's
done manually, isn't it.  So who's going to manage this splitting, and where
are the boundaries going to be where this occurs.  Oh, and guess what, that
means that one router in that whole area is going to be the gateway for the
traffic for that area...  Guess what, the network no longer scales as you
add nodes.  Or that means, as nodes get added to the system, you have to
shrink the AS'.  How do you deal with a node moving fast through AS' (the
laptop in a car)?
OSPF just isn't designed for a hetrogeneous, mesh-like, broadcast based
network.

And also, no method for getting the network to scale socially.

both are good reasons to discuss this.
If you can solve my concerns with OSPF please provide details.

I'm only talking in 'rough terms' because I don't want to finalise the
design until I know why I'm finalising it, so I hopefully have a nice solid,
reliable basis for the design.  Rather than the abortion that TCP/IP is.
Hell, relying on a magic number, unencrypted, for authentication, what kind
of fore thought did that take.  (yeah, I know, it was a reasonable tradeoff
for the day...  They should have built a migration path in at least...)

Ben.



> <quote> Yes, though being able to limit the zone of this discovery to a
> couple of
> >hops, and not the entire network, is going to be an absolutly massive
> >advantage in scaling this to large networks.</quote>
>
> <quote> Well, this is where we can experiment.  We also need to know in
> rough terms
> which directions are best for sending to certain destinations (here's
> where
> the lat/long might be useful), based on previous "experience") for
> longer
> paths.</quote>
>
> umm.. these 2 things are what a routing protocol does. OSPF (for
> example) breaks the network up into managable AREAs and only swaps
> pertinent information between them (route summarizations, etc.)
> and (nearly) any routing protocol will be able to weigh up a metrics for
> different routes, and not in "rough terms" ;) directions and lat/long
> will have no real bearing, things like delay, bandwidth, load, hops are
> more important when choosing a route.
>
> J.
>
> -----Original Message-----
> From: Tony Langdon, VK3JED [mailto:vk3jed at optushome.com.au]
> Sent: Tuesday, 19 March 2002 8:13 PM
> To: Ben Anderson; Tony Langdon; melbwireless at wireless.org.au
> Subject: Re: [MLB-WIRELESS] [TECH] Dipole antennas, and melbwireless
> structure
>
>
> At 07:25 PM 19/03/2002 +1100, Ben Anderson wrote:
>
> >I think it's do-able, just not trivial :)  It should work, just with
> minor
> >interruption - this isn't a major concern to me, the scalability issues
> are
> >much more interesting...
>
> I might wanna run tram mobile on a Windows box LOL  (ppl who know me
> would
> believe this :) ).
>
> > > We must support tunneling, as it is the most feasible way to rapidly
> link
> > > segments right now, until more wireless links take over.
> >
> >Yep, shortcutting the mesh is going to be *very* important to the
> overall
> >scalability of the network.
>
> And these routes can be statically specified.
>
> >Yes, though being able to limit the zone of this discovery to a couple
> of
> >hops, and not the entire network, is going to be an absolutly massive
> >advantage in scaling this to large networks.
>
> Well, this is where we can experiment.  We also need to know in rough
> terms
> which directions are best for sending to certain destinations (here's
> where
> the lat/long might be useful), based on previous "experience") for
> longer
> paths.
>
> > > Again, this suggests that a _LOT_ more than lat/long information is
> > > needed.  For example, here, the best route to a node north of me is
> likely
> > > to be _away_ from it, to the south! :)  So we're back to some sort
> of
> >route
> > > discovery mechanism. :)
> >
> >The lat/long thing should _work_ -- it might not be optimal, but it
> should
> >guarantee a reasonable method exists...  Plus, because the network is
> >effectilvy source routed, with broadcast auto source-route discovery,
> there
> >could be an interface for the originating station to define more
> optimal
> >routes...  For example, static-shortcut lists could be propegated to
> all
> >nodes on a daily, or weekly basis for example without being a
> significant
> >overhead -- and that way the originating node could calculate how to
> most
> >effectilvy use the shortcuts to mimise the mojo cost for a particular
> >connection, or minimise the latency regardless the cost of mojo -- that
> >decisoion is a 'originating stations' choice...
>
> Static routing can be cached easily, as long as there exists a mechanism
> to
> advertise the loss of a static route as well (i.e. a node is turned off
> in
> a controlled fashion).
>
> >And it gets worse...  I don't know if there's even an interface to
> getting
> >network layer access to windows network stack...  And if there's not,
> >getting raw ethernet access, and then trying to find a way to get
> transport
> >layer access back to the operating system...  Arrrgh, my brains
> hurting...
> ><back to thinking about scaling ;)>
>
> Apparently, it can be done, though not by a MS provided API.  But
> Windows
> will need support by _someone_.
>
> > > One of those restrictions is that the equipment needs to be type
> approved
> > > for the purpose by the ACA, AFAIK.
> >
> >Yep, but if we can get generic type approved radio interfaces, and then
> wire
> >up the ADC/DAC backend...
>
> Hrm, maybe...  Dunno, I'm not a lawyer. :)
>
> 73 de Tony, VK3JED
> http://vk3jed.vk.irlp.net
>
> --
> 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
>


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