Re: [manet] DYMO and other routing protocols

[Alexandru Petrescu <alexandru.petrescu at gmail.com>]

Dearlove, Christopher (UK) wrote:
> > OLSRv2 document says it's proactive but I think an OLSRv2 
> > implementation must be able to obtain a route if it receives a app
> >  packet whose dst it doesn't know, and if it doesn't have a default
> >  route.
>
> Not in that way.
>
> Using the protocol as to be standardised, if an OLSR (v1 or v2) node 
> receives a packet from destination it doesn't know, it does nothing 
> to find that route.

Maybe we have a misunderstanding.

I meant that an OLSR router, when it receives a packet from a host
permanently attached to that router, a packet that that OLSR router
should forward, packet whose dst address that OLSR router doesn't know -
the OLSR router should try to discover the route.

It's not a packet that the app on that OLSR router receives, and whose
dst that router doesn't know.

> There is allowed to be responsiveness (a term we use as say 
> reactiveness would be confusing) in the protocol at the signalling 
> level. If an OLSR (v1 or v2) node receives a HELLO message containing
>  information about a neighbour it's never heard of, it doesn't have 
> to maintain its current fixed schedule to send a HELLO message 
> containing this extra information, but can do so early. This will 
> accelerate what you want here, and may even look reactive. But it's 
> more than just subtly different. A node that wants to find node X 
> can't make that happen, it has to wait for node X to inform it 
> (directly or, more usually, via other nodes).

I think I understand that in the MANET network the route propagation can
happen only with HELLOs advertised on link scope.

I also understand that very frequent HELLOs may in the end look as
routes are created immediately prior to an e2e application needing it.

However, as the efficiency of MANET networks should be taken into
account one deployer has to have the option of either rely on periodic
advertisements or immediate requested responses.  This is exactly as
periodic RAs and RS/RA, or as periodic RIP advertisements and Triggered RIP.

> > Similary, DYMO says it's on-demand but it should advertise RREP (or
> >  RREQs) periodically if it needs to maintain up to date information
> >  at all times.
>
> But maintaining up to date information about all destinations at all 
> times is not necessarily desirable. (Talk to 6LoWPAN people about 
> this, for example.)

I agree not desirable.

I wanted to mean that both tools should be in one spec (both the
periodic advertisements _and_ the immediately-answered directed
requests) and that deployers should be able to use whichever mechanism
independently or tuned for ege 6LowPAN.

Alex


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


_______________________________________________
manet mailing list
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet