[OLSR-users] Host vs. Network route propagation with OLSR

[Val Schmidt]

Thanks Andreas!

Now that I see your explanation its beginning to make sense. I'll  
configure HNA entries for the non-meshed networks and see how that goes.

I'm not sure I understand all of your second paragraph. It seems to  
me you're suggesting that each link between two WRT nodes have it's  
own small subnet shared between the two nodes.  If so, you might have  
a look at http://sssg1.whoi.edu/swap. We combined a collection of  
open source software to do just that but used ospf as the routing  
engine. A daemon called aladin (from sown.org) dynamically configured  
an IP address and 4-address subnet to network interfaces on either  
side of the link when a new link was detected.  It works well most of  
the time, but quagga's ospf daemon has been problematic in removing  
routes when links are lost.

Thanks again,

Val



On Jul 20, 2006, at 3:58 PM, Andreas Tønnesen wrote:

> Hi Val,
>
> I understand your confusion!
> In an ad-hoc network _every_ node is a router, but the nodes are  
> usually
> part of the same subnet. Aggregated routing is based on the assumption
> that a subnet is reachable on a network segment(on-the-wire). The  
> problem
> with MANETs is that all nodes are not reachable by one layer2-hop and
> therefore host routing is nessecarry.
> So the assumption from traditional routing that we can add an  
> aggregated
> route to a routers subnet fails. However, it is possible to build
> something similar to what you describe using HNA(host/network
> association). Nodes can announce external connectivity as subnets by
> sending HNA messages.
>
> On a sidenote I've been playing with the idea of making a olsrd  
> version
> that only uses propagated routes. Say you have a network consisting of
> only the good ol' WRTs. Then every WRT is assigned a small subnet.  
> The WRT
> then uses normal ethernet/WLAN operation towards its clients(DHCP  
> etc) but
> does not (need to) do any NAT.
> In such a network only aggregated routes would be needed in the  
> MANET as
> well. In addittion you would probably want a mechanism to build host
> routes for maintainenc etc. but that wouldn't be too hard.
> Ofcause then you would turn olsrd in to a "backbone routing  
> protocol" but
> so what :) Hosts could still connect if they were assigned a subnet  
> upon
> joining the network.
>
> Anyways, I hope the explanation made senese (even is my last
> thinking-out-loud section might not have) :)
>
>
> - Andreas
>
>> Hello,
>>
>> I'm new to OLSR and am finding the learning curve steep. I'd like to
>> make several comments to clarify things in my mind and I'd be
>> terribly grateful to hear your comments and corrections.
>>
>> It appears to me that there is a huge misconception between the
>> designers of OLSR and much of the current user base (myself included,
>> actually maybe I'm the only one with the misconception).
>>
>> As best I can tell, OLSR is fundamentally different than OSPF or RIP
>> in that it propagates routes for HOSTS rather than networks - by
>> default. I suppose this makes sense as many ad-hoc mesh networks may
>> be comprised of "sensor nodes" in which each node both "does
>> something" (measures the temperature maybe) and is also a router.  In
>> this way, each sensor is a possible path for data transmission, and
>> since each node is a router, one need only route directly to
>> interfaces and not to networks.
>>
>> However, this is very different from the model that many people are
>> used to in which an ad-hoc mesh of nodes provide routing services
>> between networks to which other clients can connect. For example, a
>> community wireless project in which each node in a network provides
>> both a local AP functionality for client computers and a wireless
>> link to other nodes. In this scenario OLSR might be chosen so that
>> non-persistent nodes installed on busses or ferries or whatever are
>> handled gracefully.  Here, OLSR is meant to provide routing between
>> NETWORKS rather than just the network interfaces of the node. This is
>> much more like a mobile meshed LAN providing dynamic networking for
>> client machines rather than a mesh sensor network.
>>
>> When you set up OLSR and configure the "interfaces" entry in
>> olrsd.conf, you propagate routes to those interfaces through the
>> network. But you don't propagate routes to the networks those
>> interfaces are attached to, and so clients on those networks are
>> unreachable. This fact was and is very confusing to me, as a very
>> similar entry in ospfd.conf will propagate routes to the networks
>> those interfaces are connected to, rather than just the interface
>> itself.  A review of this list archives seems to show that it is
>> confusing to many others too.
>>
>> I'm probably missing something, but I cannot see a reason why an
>> "interface" entry in olrsd.conf should not simply propagate a network
>> address rather than a host address. It seems to me the more general
>> case of a network address would serve to provide a route to both the
>> network interface and other addresses on that network - in much the
>> same way as other common routing protocols.
>>
>> Thanks for listening - this wasn't meant to be a rant. I look forward
>> to your comments.
>>
>> -Val
>>
>>
>>
>>
>> ------------------------------------------------------
>> Val Schmidt
>> CCOM/JHC
>> University of New Hampshire
>> Chase Ocean Engineering Lab
>> 24 Colovos Road
>> Durham, NH 03824
>> e: vschmidt [AT] ccom.unh.edu
>> m: 614.286.3726
>>
>>
>> _______________________________________________
>> olsr-users mailing list
>> (spam-protected)
>> https://www.olsr.org/mailman/listinfo/olsr-users
>>
>
>
>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users

------------------------------------------------------
Val Schmidt
CCOM/JHC
University of New Hampshire
Chase Ocean Engineering Lab
24 Colovos Road
Durham, NH 03824
e: vschmidt [AT] ccom.unh.edu
m: 614.286.3726


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20060720/c3864ae0/attachment.html>