Hello Vicky,
Unless I am missing something, multicast RREP is broken and can't be easily
fixed. If anyone has a suggestion, please don't hesitate to make a
proposal.
The feature has been a holdover from DSR when there were source routes
affixed
to the RREQ and RREP. In order to fix multicast RREP, I reckon we would
have to
put the source routes back in as well as create more protocol. I don't
think we
have the time to do that.
Moreover, if we get rid of multicast RREP, there's no reason to provide for
the feature in the multicast suppression table (RteMsg table), so it
could be
reverted to being the RREQ suppression table.
Please accept my sincere regrets for not catching this years ago...
Relatively useless follow-up below...
On 4/16/2015 7:03 AM, Victoria Mercieca wrote:
These are some notes on the optional feature of multicast RREP (Section 12.3 in Version 9a or Section 10.3 in Version 9b):
* This extension could have implications for the msg_hop_limit field
in the RREP. It might not be appropriate to set it to the hopcount
from the RREQ. If we are looking at bidirectional links then its
fine - the route found for the RREP might be better than the path
the RREQ took, but at worst it will be the RREQ path in reverse.
If links are not bidirectional (and I suppose we dont need to
address this at the current time) then the hop limit should be
MAX_HOPCOUNT.
* Metrics will be learned in reverse. i.e. the target will learn the
hopcount of the path the RREQ took, which is cost from Orig to
Targ, and the originator will learn the hopcount of the path the
RREP took which is actually the cost from Targ to Orig.
* How does this impact the bidirectionality check? Would routers on
the RREP path still do AckReq when the RREP is
multicast? Intermediate nodes on the RREQ path won't know if the
links are bidirectional - does it matter if links are
bidirectional though, if the return path is different?
