Opened 7 years ago

Last modified 4 years ago

#16 new enhancement

The Reactive Protocol Duplicate Suppression Table

Reported by: abdussalambaryun@… Owned by: Abdussalam Baryun
Priority: major Milestone:
Component: dymo Version:
Severity: Active WG Document Keywords: Message suppression
Cc:

Description

I agree with the proposed to add RREPs in table as RREQ for suppression as below message, however, will need to discuss if there are side affects

http://www.ietf.org/mail-archive/web/manet/current/msg14472.html

Change History (3)

comment:1 Changed 6 years ago by charliep@…

The changes for proper handling of Duplicate Suppression have been made. Insofar as the base protocol specifies unicast RREP, the need for suppressing duplicate RREPs has been moved into the specification for that optional behavior.

comment:2 Changed 5 years ago by charliep@…

On 2/20/2013 4:10 PM, Abdussalam Baryun wrote:

I agree, but why there is not much attention in the WG for unidirectional links? Regarding RREP it can be optional, but I prefer one table for duplicate RteMsg?,

On 2/20/13, Charles E. Perkins <charliep@…> wrote:

There was a revision of AODVv2 that included RREPs in the duplicate suppression table. It did have the effect of making the description more difficult to understand without additional benefit in the typical case where RREPs are unicast. For multicast RREP, there would be quite a bit more benefit, but the use case for multicast RREP involves networks with unidirectional links, which have not seen much attention lately in the working group. Moreover, the duplicate suppression table itself would need to distinguish between RREQ and RREP messages if they were combined in the same table, so logically speaking the table could still be viewed as two separate tables.

If there is interest, handling multicast RREPs in a similar table could be more explicitly specified in the document.

comment:3 Changed 4 years ago by charliep@…

This change will be incorporated into the upcoming new revision of the specification. The cost is adding one more field to the table, which is now to be called the Multicast RteMsg table. The other changes to the specification are straightforward with little or no complications other than making sure that the relevant language in the specification has all been checked. If this is satisfactory, then upon review of the revised text the issue can be closed.

Note: See TracTickets for help on using tickets.