Hello Vicky,
It's known how to do this, because DSR did it :-)
I agree that we should leave it until later.
Here's what I remember:
Both RREQ and RREP are multicast, and source routes collected.
When the destination multicasts the RREP, it also *includes* the
source route from the origination. So, when the origination gets
the multicast RREP, it knows which path to take to get the the
destination.
This isn't enough, however. The origination has to include the
source route in data packets until it gets confirmation that every
intermediate router in both directions has at least a functional
unidirectional route.
So, we're looking at a lot of routing overhead for this scenario.
Regards,
Charlie P.
On 4/30/2015 8:32 AM, Victoria Mercieca wrote:
Hi Charlie,
Comments in-line:
On Fri, Apr 17, 2015 at 2:13 AM, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
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:
I agree with this.
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.
I don't see how to easily fix this.
* 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.
Well I had a crazy idea that we'd need to echo information around a bit more. e.g. RREQ goes out, and Metric gets updated hop by hop, as usual. In the RREP we send both the final metric from the RREQ, plus another field to accumulate the return path cost. Then when RREQ_Gen gets the RREP, it stores the cost for the path the RREQ took, and sends some sort of "Route Confirm" type message with the final metric for the path the RREP took.
I dont think this is something we should be focusing on right now though. Could we separate it out to another draft and reference it? And update that draft at a later date? We could then leave the RteMsg table sections unchanged.
* How does this impact the bidirectionality check? WouldMulticast RREP would not allow AckReq.
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?
So disabling adjacency monitoring should be part of the Multicast RREP specification.
Regards,
Vicky.
Regards,
Charlie P.
