[aodvv2-discuss] Re: Questions - Multicast RREP

  • From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
  • To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Thu, 30 Apr 2015 16:32:43 +0100

Hi Charlie,

Comments in-line:

On Fri, Apr 17, 2015 at 2:13 AM, Charlie Perkins <
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:


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 agree with 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.

I don't see how to easily fix this.

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? 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?

Multicast RREP would not allow AckReq.


So disabling adjacency monitoring should be part of the Multicast RREP
specification.

Regards,
Vicky.



Regards,
Charlie P.


Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 04-2015