Subject: Re: [manet] New OLSR draft

From: [email-masked]
Date: Mon, 05 Aug 2002 15:10:35 -0700

Philippe,

> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Sunday, July 14, 2002 5:05 PM
> Subject: Re: [manet] New OLSR draft
> 
> 
> >
> > The new OLSR parameter TC_REDUNDANCY results in additional
> > topology information being reported (up to the full topology).
> > Since TBRPF already allowed additional topology information
> > to be reported, I'm glad to see that INRIA agrees with us.
> >
> Not really. As far as I understand TBRPF, an extra link is known by a remote
> known only if there exists a chain of nodes from this link to the remote
> node where all nodes agree adding this extra link in their respective
> reported link sets.  In absence of a specified consensus protocol this may
> be difficult to implement. In OLSR only the node which owns the link needs
> to decide to advertize it or not. Adding extra links in the TC may be
> triggered by local considerations such as:
> -    willingness to act as a router
> -    unreliable links needing back-up links
> In the limit, the nodes can advertize their full neighborhood leading to
> full topology knowledge in the network as with OSPF. The TC are greater and
> similar to OSPF LSA, but the bandwidth is still saved since only MPRs
> forward the information. The credits for this nice idea are to Joe Macker.

I am just saying that TBRPF already included the option to report
additional topology information, including the full topology,
and now OLSR has added the option to report additional topology
information, including the full topology.  So we clearly agree
on this point!

The difference that you mention is a natural result of the 
difference that already existed between OLSR and TBRPF:
in OLSR each generated topology update is flooded to all nodes, whereas
in TBRPF a given update reaches only nodes that are potentially 
affected by the update (which is one of the properties that makes 
TBRPF efficient).  

A consensus protocol is not needed.  If all nodes are configured to 
report the full topology, then each topology update will reach all nodes.
If only some nodes are configured to report the full topology, then 
intermediate nodes that do not report the full topology may not
relay all information that is received.  This is not a problem:
each node is still provided with sufficient information to compute
shortest paths to all destinations.  

> > However, I do not see an *efficient* method for reporting
> > sufficient topology information to provide each node with
> > two disjoint paths to each destination (without providing
> > each node with the full topology).  Setting MPR_COVERAGE
> > to 2 does provide each node with two disjoint paths to each
> > destination (if such paths exist), but not only does it
> > double the number of links flooded, it also doubles the
> > number of MPRs that need to forward each TC message,
> > which seems to multiply the TC overhead by 4.
> > (In TBRPF, the factor is 2 since the number of nodes
> > reporting each update does not increase.)
> > Since our ns-2 simulations show that OLSR generates more than
> > twice as much overhead as TBRPF, this would likely give TBRPF
> > an even bigger advantage in overhead.
> >
> Not exactly. The MPR_COVERAGE parameter is about the broadcast reliability
> over MPRs. If the links to your MPRs are not reliable enough, then you may
> need redundant MPR sets. The problem may be more critical for TBRPF since
> you have less flexibility in parent selection (always select the node with
> the smallest ID). Maybe it can be solved by selecting the k-smallest ID node
> as parent, with k=MPR_COVERAGE.

I considered the possibility of selecting multiple parents in TBRPF.
But I found that the redundancy provided by multiple parents 
does not increase robustness as much as the redundancy provided by
reporting additional links (without providing multiple parents).
If the link to a parent is not reliable enough (or fails), then
the additional links will provide an alternate path while a new parent
is selected.  

Also keep in mind that TBRPF can use hysteresis similar to OLSR, and in 
addition can compute shortest paths with respect to link quality metrics.
Therefore, TBRPF uses minimum ID only as a tie breaker, and will select 
a neighbor as parent only if the link to that neighbor is good.

It is not hard to modify OLSR to achieve the goal of providing
two disjoint paths without increasing the number of MPRs.
Each node can select primary MPRs and backup MPRs.  
TC messages can include links corresponding to *both* primary MPRs 
and backup MPRs, while only primary MPRs forward TC messages.
(I discussed this idea in an email I sent you over a year ago, on 6/11/01.)

Regards,
Richard

> Thank you for your interesting comment.
> 
> Regards,
> 
> Philippe
> 
> 
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: [email-masked]
Date: Mon, 05 Aug 2002 15:10:35 -0700

Philippe,

Regards,
Richard