Hello Vicky,
Yes, definitely remove Multicast RREP.
Regards,
Charlie P.
On 5/7/2015 3:36 AM, Victoria Mercieca wrote:
Hi Charlie,
Since Multicast RREP is broken at the moment, I'd like to remove it. If you want, we can separate it out to another draft and reference it, like we do for iRREP? And the separate multicast RREP draft can be worked on at some point in future? I dont think we should have broken stuff in this AODVv2 draft.
Kind regards,
Vicky.
On Thu, Apr 30, 2015 at 8:06 PM, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
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.
